[fonc] Sorting the WWW mess
Right now I'm a bit confused. I saw here 2 aspects of the world wide web that make it a mess. 1. The browser cannot host arbitrary processes. So instead of something simple and general, we have the current html + CSS + Javascript + webGl + whatnot… And of course a huge pile of standards which we have to comply with. 2. The very hyperlink model of networking is broken from the beginning, and is one of the primary cause of the need for big, centralized search engine. I sort of can see how we could solve (1). It doesn't seem so hard to devise a virtual machine that could do sound, vector-based graphics, and user input. At least in the light of the small size of Frank. It should be both simpler than http + Javascript, and much more general. What I _don't_ see is how we could do better than one-way hyperlinks. What kind of sane web could help me find something on the internet without the help of Big Data? I have no Idea. Loup. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Error trying to compile COLA
The same things are at a Very High Level computing (beyond application boundary at enterprise-wide level, and especially beyond enterprise boundary at business eco-systems level). There are BPMN engines, issue trackers, project management systems, document management/workflow systems, etc.. And when you try to perform workflow/process/case execution of something that need to be executed on all this engines mess, you have a huge problems: too many high level execution paradigms (project, process, case management, complex event management, etc.), too few good architectures and tools to do this. I think that scalability should go not only from hardware to application as desktop publishing level but to support of enterprise architecture and beyond (business eco-system architecture with federated enterprises). SOA ideas is definitely not helpful here in its current enterprise bus state. I consider programming, modeling and ontologizing from CPU hardware up to a business eco-system level the same discipline and transfer from programming/modeling/ontologizing-in-the-small to the same-in-the-large as one of urgent needs. We should generalize concept of external execution to preserve it meaning from hardware CPU core to OS/browser/distributed application level to extended enterprise (network of hundreds of enterprises that perform complex industrial projects like nuclear power station design and construction). Best regards, Anatoly Levenchuk From: fonc-boun...@vpri.org [mailto:fonc-boun...@vpri.org] On Behalf Of Alan Kay Sent: Thursday, March 01, 2012 3:10 AM To: Duncan Mak; Fundamentals of New Computing Subject: Re: [fonc] Error trying to compile COLA Hi Duncan The short answers to these questions have already been given a few times on this list. But let me try another direction to approach this. The first thing to notice about the overlapping windows interface personal computer experience is that it is logically independent of the code/processes running underneath. This means (a) you don't have to have a single religion down below (b) the different kinds of things that might be running can be protected from each other using the address space mechanisms of the CPU(s), and (c) you can think about allowing outsiders to do pretty much what they want to create a really scalable really expandable WWW. If you are going to put a browser app on an OS, then the browser has to be a mini-OS, not an app. But standard apps are a bad idea (we thought we'd gotten rid of them in the 70s) because what you really want to do is to integrate functionality visually and operationally using the overlapping windows interface, which can safely get images from the processes and composite them on the screen. (Everything is now kind of super-desktop-publishing.) An app is now just a kind of integration. But the route that was actually taken with the WWW and the browser was in the face of what was already being done. Hypercard existed, and showed what a WYSIWYG authoring system for end-users could do. This was ignored. Postscript existed, and showed that a small interpreter could be moved easily from machine to machine while retaining meaning. This was ignored. And so forth. 19 years later we see various attempts at inventing things that were already around when the WWW was tacked together. But the thing that is amazing to me is that in spite of the almost universal deployment of it, it still can't do what you can do on any of the machines it runs on. And there have been very few complaints about this from the mostly naive end-users (and what seem to be mostly naive computer folks who deal with it). Some of the blame should go to Apple and MS for not making real OSs for personal computers -- or better, going the distance to make something better than the old OS model. In either case both companies blew doing basic protections between processes. On the other hand, the WWW and first browsers were originally done on workstations that had stronger systems underneath -- so why were they so blind? As an aside I should mention that there have been a number of attempts to do something about OS bloat. Unix was always too little too late but its one outstanding feature early on was its tiny kernel with a design that wanted everything else to be done in user-mode-code. Many good things could have come from the later programmers of this system realizing that being careful about dependencies is a top priority. (And you especially do not want to have your dependencies handled by a central monolith, etc.) So, this gradually turned into an awful mess. But Linus went back to square one and redefined a tiny kernel again -- the realization here is that you do have to arbitrate basic resources of memory and process management, but you should allow everyone else to make the systems they need. This really can work well if processes can be small and interprocess communication fast (not
Re: [fonc] Error trying to compile COLA
On 1 March 2012 02:26, Igor Stasenko siguc...@gmail.com wrote: wonderful. so, in 5 years (put less if you want) i can be sure that my app can run on every machine on any browser, and i don't have to put update your browser warning. No, because in 5 years' time you will be wanting to do something different, and there will be a different immature technology to do it that hasn't yet been implemented on every machine. And of course there's a serious chance the browser will be on its way out by then (see how things are done on mobile platforms). 10 years ago we'd've been having the same conversation about Java. Today Java is still very much alive, and lots of people are getting things done with it. 5 years ago Flash might've been mentioned. Ditto. As to me, this language is not good enough to serve at such level. From this point, it is inherently not complete and never will be, and will always stand between you and your goals. If you're sufficiently determined, you'll manage to get nothing done whatever the technology on offer. -- http://rrt.sc3d.org ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Sorting the WWW mess
Loup, I agree that the Web is a mess. The original sin was to assume that people would only want to connect to other computers in order to retrieve a limited set of static documents. I think the reason for this was that everyone sticked to the Unix security model, where everything you run has all the permissions you have. That's why you don't want to run code from untrusted sources. If they had used a capablity-based security model from the start, this concern would probably not have arised. Also, a deeper culprit, in my opinion, is Intellectual Property. There were several great networking protocols before the internet, but they were usually proprietary protocols for proprietary operatinog systems. Don't forget that, for instance, Plan9 was not open sourced until 2000 or 2002. Now there's a lot of talk of open standards, but there was a time when the main source of open standards were half-baked government projects. The main reason why the IBM PC architecture dominates is that Compaq managed to clone it legally. The main reason why Microsoft operating systems got to dominate is that they were ready from the start to run on those cheap and widespread IBM PC clones, both technically and legally. I also think that the internet, with its silly limited IP numbers and DNS servers smack of premature optimization. I mean, configuring a network feels a bit like programming in machine code. There's also the issue of one-way links, which creates the need for complex feedback mechanisms such as RSS, moreover, the fact that regular URLs are so ephemeral, which gave rise to permalinks. Then again, if it were all based on two-way links, maybe we would need a complex system for transparent anonymous linking, some kind of virtual link. That said, I don't see why you have an issue with search engines and search services. Even on your own machine, searching files with complex properties is far from trivial. When outside, untrusted sources are involved, you need someone to tell you what is relevant, what is not, who is lying, and so on. Google got to dominate that niche for the right reasons, namely, being much better than the competition. Best, -Martin ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Error trying to compile COLA
On 1 March 2012 12:30, Reuben Thomas r...@sc3d.org wrote: On 1 March 2012 02:26, Igor Stasenko siguc...@gmail.com wrote: wonderful. so, in 5 years (put less if you want) i can be sure that my app can run on every machine on any browser, and i don't have to put update your browser warning. No, because in 5 years' time you will be wanting to do something different, and there will be a different immature technology to do it that hasn't yet been implemented on every machine. And of course there's a serious chance the browser will be on its way out by then (see how things are done on mobile platforms). 10 years ago we'd've been having the same conversation about Java. Today Java is still very much alive, and lots of people are getting things done with it. 5 years ago Flash might've been mentioned. Ditto. Yeah.. all of the above resembling same cycle: initial stage - small, good and promising, becoming mainstream - growing, trying to fit everyone's needs until eventually turning into walking zombie - buried under tons of requirements and standards and extensions. And i bet that JavaScript will not be an exception. Now if you take things like tcp/ip. How much changes/extensions over the years since first deployment of it you seen? The only noticeable one i know of is introduction of ipv6. As to me, this language is not good enough to serve at such level. From this point, it is inherently not complete and never will be, and will always stand between you and your goals. If you're sufficiently determined, you'll manage to get nothing done whatever the technology on offer. Oh, i am not arguing that we have to rely on what is available. Just wanted to indicate that if www would base on simpler design principles at the very beginning, we would not wait 27 years till javascript will be mature enough to simulate linux on it. -- http://rrt.sc3d.org ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc -- Best regards, Igor Stasenko. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Error trying to compile COLA
On 1 March 2012 12:00, Igor Stasenko siguc...@gmail.com wrote: Now if you take things like tcp/ip. How much changes/extensions over the years since first deployment of it you seen? The only noticeable one i know of is introduction of ipv6. Yes, but you can say the same of HTTP. You're comparing apples with orchards. Just wanted to indicate that if www would base on simpler design principles at the very beginning, we would not wait 27 years till javascript will be mature enough to simulate linux on it. The reason HTTP/HTML won is precisely because they were extremely simple to start with. The reason that Smalltalk, Hypercard et al. didn't is because their inventors didn't take account of what actually makes systems successful socially, rather than popular with individuals. And I fail to see what bemoaning the current state of affairs (or even the tendency of history to repeat itself) achieves. Noticing what goes wrong and trying to fix it is a positive step. The biggest challenge for FONC will not be to achieve good technical results, as it is stuffed with people who have a history of doing great work, and its results to date are already exciting, but to get those results into widespread use; I've seen no evidence that the principals have considered how and why they failed to do this in the past, nor that they've any ideas on how to avoid it this time around. -- http://rrt.sc3d.org ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Sorting the WWW mess
Martin Baldan wrote: That said, I don't see why you have an issue with search engines and search services. Even on your own machine, searching files with complex properties is far from trivial. When outside, untrusted sources are involved, you need someone to tell you what is relevant, what is not, who is lying, and so on. Google got to dominate that niche for the right reasons, namely, being much better than the competition. I wasn't clear. Actually, I didn't want to state my opinion. I can't find the message, but I (incorrectly?) remembered Alan saying that one-way links basically created the need for big search engines. As I couldn't imagine an architecture that could do away with centralized search engines, I wanted to ask about it. That said, I do have issues with Big Data search engines: they are centralized. That alone gives them more power than I'd like them to have. If we could remove the centralization while keeping the good stuff (namely, finding things), that would be really cool. Loup. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Error trying to compile COLA
Is this one of the aims? Julian On 01/03/2012, at 11:42 PM, Reuben Thomas wrote: The biggest challenge for FONC will not be to achieve good technical results, as it is stuffed with people who have a history of doing great work, and its results to date are already exciting, but to get those results into widespread use; I've seen no evidence that the principals have considered how and why they failed to do this in the past, nor that they've any ideas on how to avoid it this time around. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Sorting the WWW mess
Hi Loup Someone else said that about links. Browsing about either knowing where you are (and going) and/or about dealing with a rough max of 100 items. After that search is necessary. However, Ted Nelson said a lot in each of the last 5 decades about what kinds of linking do the most good. (Chase down what he has to say about why one-way links are not what should be done.) He advocated from the beginning that the provenance of links must be preserved (which also means that you cannot copy what is being pointed to without also copying its provenance). This allows a much better way to deal with all manner of usage, embeddings, etc. -- including both fair use and also various forms of micropayments and subscriptions. One way to handle this requirement is via protection mechanisms that real objects can supply. Cheers, Alan From: Loup Vaillant l...@loup-vaillant.fr To: fonc@vpri.org Sent: Thursday, March 1, 2012 6:36 AM Subject: Re: [fonc] Sorting the WWW mess Martin Baldan wrote: That said, I don't see why you have an issue with search engines and search services. Even on your own machine, searching files with complex properties is far from trivial. When outside, untrusted sources are involved, you need someone to tell you what is relevant, what is not, who is lying, and so on. Google got to dominate that niche for the right reasons, namely, being much better than the competition. I wasn't clear. Actually, I didn't want to state my opinion. I can't find the message, but I (incorrectly?) remembered Alan saying that one-way links basically created the need for big search engines. As I couldn't imagine an architecture that could do away with centralized search engines, I wanted to ask about it. That said, I do have issues with Big Data search engines: they are centralized. That alone gives them more power than I'd like them to have. If we could remove the centralization while keeping the good stuff (namely, finding things), that would be really cool. Loup. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] Chrome Penetration
My friend Peter Norvig is the Director of Research at Google. I told him that I had heard of an astounding jump in the penetration of Chrome. He says the best numbers they have at present is that Chrome is 20% to 30% penetrated ... Cheers, Alan ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Chrome Penetration
On Mar 1, 2012 4:11 PM, Alan Kay alan.n...@yahoo.com wrote: My friend Peter Norvig is the Director of Research at Google. I told him that I had heard of an astounding jump in the penetration of Chrome. He says the best numbers they have at present is that Chrome is 20% to 30% penetrated ... Nothing astounding here, likely just a difference in counting methods (e.g. count mobile and Chrome will be higher; count Chromium as Chrome...). The numbers I looked at in news stories showed a steady rise from around 20 to about 40 percent over the last 12 months. Myself, I just switched back to Firefox :) Cheers, Alan ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Chrome Penetration
On Mar 1, 2012, at 11:16, Reuben Thomas r...@sc3d.org wrote: Myself, I just switched back to Firefox :) Me too, for the moment. Old habits... and some dependency on FF plugins. Ken ;-) ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Error trying to compile COLA
On 3/1/2012 8:04 AM, Reuben Thomas wrote: On 1 March 2012 15:02, Julian Levistonjul...@leviston.net wrote: Is this one of the aims? It doesn't seem to be, which is sad, because however brilliant the ideas you can't rely on other people to get them out for you. this is part of why I am personally trying to work more to develop products than doing pure research, and focusing more on trying to improve the situation (by hopefully increasing the number of viable options) rather than remake the world. there is also, at this point, a reasonable lack of industrial strength scripting languages. there are a few major industrial strength languages (C, C++, Java, C#, etc...), and a number of scripting languages (Python, Lua, JavaScript, ...), but not generally anything to bridge the gap (combining the relative dynamic aspects and easy of use of a scripting language, with the power to get stuff done as in a more traditional language). a partial reason I suspect: many script languages don't scale well (WRT either performance or usability); many script languages have jokingly bad FFI's, combined with a lack of good native libraries; ... or such... ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Can semantic programming eliminate the need for Problem-Oriented Language syntaxes?
On Thu, Mar 1, 2012 at 4:25 AM, Martin Baldan martino...@gmail.com wrote: Hi, What got me wondering this was the fact that people, as far as I know, don't use domain-specific languages in natural speech. What they do use is jargon, but the syntax is always the same. What if one could program in something like ACE, specify a jargon and start describing data structures concisely and conveniently in a controlled language? That way, whenever there is a new problem, you would only have to specify what kind of entities you want to use, what properties they can have, and so on. I guess I want something like this: http://en.wikipedia.org/wiki/Semantic-oriented_programming What are your thoughts? I'll need to chew a lot longer on Semantic Oriented Programming before I can form a valid opinion. But with regards to jargons - domain specific language extension is already the role of libraries, and adding specific notations doesn't hurt. I note another thing we don't use in normal speech is parameters. We use adjectives, adverbs, and context. Regards, Dave ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Error trying to compile COLA
BGB wrote: there is also, at this point, a reasonable lack of industrial strength scripting languages. there are a few major industrial strength languages (C, C++, Java, C#, etc...), and a number of scripting languages (Python, Lua, JavaScript, ...), but not generally anything to bridge the gap (combining the relative dynamic aspects and easy of use of a scripting language, with the power to get stuff done as in a more traditional language). What could you possibly mean by industrial strength scripting language? When I hear about an industrial strength tool, I mostly infer that the tool: - spurs low-level code (instead of high-level meaning), - is moderately difficult to learn (or even use), - is extremely difficult to implement, - has paid-for support. If you meant something more positive, I think Lua is a good candidate: - Small (and hopefully reliable) tools. - Fast implementations. - Widely used in the gaming industry. - Good C FFI. - Spurs quite higher-level meaning. Loup. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Can semantic programming eliminate the need for Problem-Oriented Language syntaxes?
Yes, namespaces provide a form of jargon, but that's clearly not enough. If it were, there wouldn't be so many programming languages. You can't use, say, Java imports to turn Java into Smalltalk, or Haskell or Nile. They have different syntax and different semantics. But in the end you describe the syntax and semantics with natural language. I was wondering about using a powerful controlled language, with a backend of, say, OWL-DL, and a suitable syntax defined using some tool like GF (or maybe OMeta?). ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Sorting the WWW mess
On Thu, Mar 1, 2012 at 7:08 AM, Martin Baldan martino...@gmail.com wrote: I think it was Julian, in message: http://vpri.org/mailman/private/fonc/2012/003131.html BTW, I'm having a hard time trying to find who said what in this mailing list. Maybe I'm missing something, I feel a bit silly, but here's the problem: _ Apparently, Google can't search this mailing list, I guess it's because of its private nature. For instance, the query: google site:http://vpri.org/mailman/private/fonc/2012/thread.html shields no results. _ I can search e-mails for keywords in my Gmail account, but when I find one, I don't know what message number it is. I only see the date and time. _ The mailing list web interface lets me arrange messages by date, but it doesn't show me the date of each message in a column. So what should I do? http://www.mail-archive.com/fonc@vpri.org/ As for centralization, I don't think you can avoid some degree of natural centralization of trust. For instance, I tend to trust the VPRI people when it comes to programming-related theory and ideas. Am I giving them too much power? ;) What should be avoided is single points of failure in infrastructure. I should be able to decide whom to trust, without artificial limits imposed by the technology. Best, -Martin ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Sorting the WWW mess
Ah, thanks! :) On Thu, Mar 1, 2012 at 6:26 PM, David Barbour dmbarb...@gmail.com wrote: http://www.mail-archive.com/fonc@vpri.org/ ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Error trying to compile COLA
On 3/1/2012 10:12 AM, Loup Vaillant wrote: BGB wrote: there is also, at this point, a reasonable lack of industrial strength scripting languages. there are a few major industrial strength languages (C, C++, Java, C#, etc...), and a number of scripting languages (Python, Lua, JavaScript, ...), but not generally anything to bridge the gap (combining the relative dynamic aspects and easy of use of a scripting language, with the power to get stuff done as in a more traditional language). What could you possibly mean by industrial strength scripting language? When I hear about an industrial strength tool, I mostly infer that the tool: - spurs low-level code (instead of high-level meaning), - is moderately difficult to learn (or even use), - is extremely difficult to implement, - has paid-for support. expressiveness is a priority (I borrow many features from scripting languages, like JavaScript, Scheme, ...). the language aims to have a high-level of dynamic abilities in most areas as well (it supports dynamic types, prototype OO, lexical closures, scope delegation, ...). learning curve or avoiding implementation complexity were not huge concerns (the main concession I make to learning curve is that it is in many regards fairly similar to current mainstream languages, so if a person knows C++ or C# or similar, they will probably understand most of it easily enough). the main target audience is generally people who already know C and C++ (and who will probably keep using them as well). so, the language is mostly intended to be used mixed with C and C++ codebases. the default syntax is more ActionScript-like, but Java/C# style declaration syntax may also be used (the only significant syntax differences are those related to the language's JavaScript heritage, and the use of as and as! operators for casts in place of C-style cast syntax). generally, its basic design is intended to be a bit less obtuse than C or C++ though (the core syntax is more like that in Java and ActionScript in most regards, and more advanced features are intended mostly for special cases). the VM is intended to be free, and I currently have it under the MIT license, but I don't currently have any explicit plans for support. it is more of a use it if you want proposition, provided as-is, and so on. it is currently given on request via email, mostly due to my server being offline and probably will be for a while (it is currently 1600 miles away, and my parents don't know how to fix it...). but, what I mostly meant was that it is designed in such a way to hopefully deal acceptably well with writing largish code-bases (like, supporting packages/namespaces and importing and so on), and should hopefully be competitive performance-wise with similar-class languages (still needs a bit more work on this front, namely to try to get performance to be more like Java, C#, or C++ and less like Python). as-is, performance is less of a critical failing though, since one can put most performance critical code in C land and work around the weak performance somewhat (and, also, my projects are currently more bound by video-card performance than CPU performance as well). in a few cases, things were done which favored performance over strict ECMA-262 conformance though (most notably, there are currently differences regarding default floating-point precision and similar, due mostly to the VM presently needing to box doubles, and generally double precision being unnecessary, ... however, the VM will use double precision if it is used explicitly). If you meant something more positive, I think Lua is a good candidate: - Small (and hopefully reliable) tools. - Fast implementations. - Widely used in the gaming industry. - Good C FFI. - Spurs quite higher-level meaning. Lua is small, and fairly fast (by scripting language terms). its use in the gaming industry is moderate (it still faces competition against several other languages, namely Python, Scheme, and various engine-specific languages). not everyone (myself included) is entirely fond of its Pascal-ish syntax though. I also have doubts how well it will hold up to large-scale codebases though. its native C FFI is moderate (in that it could be a lot worse), but AFAIK most of its ease of use here comes from the common use of SWIG (since SWIG shaves away most need for manually-written boilerplate). the SWIG strategy though is itself a tradeoff IMO, since it requires some special treatment on the part of the headers, and works by producing intermediate glue code. similarly, it doesn't address the matter of potential semantic mismatches between the languages (so the interfaces tend to be fairly basic). in my case, a similar system to SWIG is directly supported by the VM, does not generally require boilerplate code (but does require any symbols to be DLL exports on Windows), and the FFI is much more tightly
Re: [fonc] Can semantic programming eliminate the need for Problem-Oriented Language syntaxes?
On 3/1/2012 10:25 AM, Martin Baldan wrote: Yes, namespaces provide a form of jargon, but that's clearly not enough. If it were, there wouldn't be so many programming languages. You can't use, say, Java imports to turn Java into Smalltalk, or Haskell or Nile. They have different syntax and different semantics. But in the end you describe the syntax and semantics with natural language. I was wondering about using a powerful controlled language, with a backend of, say, OWL-DL, and a suitable syntax defined using some tool like GF (or maybe OMeta?). as for Java: this is due in large part to Java's lack of flexibility and expressiveness. but, for a language which is a good deal more flexible than Java, why not? I don't think user-defined syntax is strictly necessary, but things would be very sad and terrible if one were stuck with Java's syntax (IMO: as far as C-family languages go, it is probably one of the least expressive). a better example I think was Lisp's syntax, where even if at its core fairly limited, and not particularly customizable (apart from reader macros or similar), still allowed a fair amount of customization via macros. but, anyways, yes, the language problem is still a long way from solved, and so instead it is a constant stream of new languages trying to improve things here and there vs the ones which came before. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Error trying to compile COLA
Below. On Feb 29, 2012, at 5:43 AM, Loup Vaillant l...@loup-vaillant.fr wrote: Yes, I'm aware of that limitation. I have the feeling however that IDEs and debuggers are overrated. When I'm Squeaking, sometimes I find myself modeling classes with the browser but leaving method bodies to 'self break' and then write all of the actual code in the debugger. Doesn't work so well for hacking on the GUI, but, well. I'm curious about 'debuggers are overrated' and 'you shouldn't need one.' Seems odd. Most people I've encountered who don't use the debugger haven't learned one yet. At one company (I'd love to tell you which but I signed a non-disparagement agreement) when I asked why the standard dev build of the product didn't include the debugger module, I was told you don't need it. When I went to install it, I was told not to. I don't work there any more... ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Error trying to compile COLA
On 3/1/2012 2:58 PM, Casey Ransberger wrote: Below. On Feb 29, 2012, at 5:43 AM, Loup Vaillantl...@loup-vaillant.fr wrote: Yes, I'm aware of that limitation. I have the feeling however that IDEs and debuggers are overrated. When I'm Squeaking, sometimes I find myself modeling classes with the browser but leaving method bodies to 'self break' and then write all of the actual code in the debugger. Doesn't work so well for hacking on the GUI, but, well. I'm curious about 'debuggers are overrated' and 'you shouldn't need one.' Seems odd. Most people I've encountered who don't use the debugger haven't learned one yet. agreed. the main reason I can think of why one wouldn't use a debugger is because none are available. however, otherwise, debuggers are a fairly useful piece of software (generally used in combination with debug-logs and unit-tests and similar). sadly, I don't yet have a good debugger in place for my scripting language, as mostly I am currently using the Visual-Studio debugger (which, granted, can't really see into script code). granted, this is less of an immediate issue as most of the project is plain C. At one company (I'd love to tell you which but I signed a non-disparagement agreement) when I asked why the standard dev build of the product didn't include the debugger module, I was told you don't need it. When I went to install it, I was told not to. I don't work there any more... makes sense. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Sorting the WWW mess
On Thu, Mar 1, 2012 at 7:04 AM, Alan Kay alan.n...@yahoo.com wrote: Hi Loup snip However, Ted Nelson said a lot in each of the last 5 decades about what kinds of linking do the most good. (Chase down what he has to say about why one-way links are not what should be done.) He advocated from the beginning that the provenance of links must be preserved (which also means that you cannot copy what is being pointed to without also copying its provenance). This allows a much better way to deal with all manner of usage, embeddings, etc. -- including both fair use and also various forms of micropayments and subscriptions. If only we could find a way to finally deal with all that intertwingularity! One way to handle this requirement is via protection mechanisms that real objects can supply. Cheers, Alan -- *From:* Loup Vaillant l...@loup-vaillant.fr *To:* fonc@vpri.org *Sent:* Thursday, March 1, 2012 6:36 AM *Subject:* Re: [fonc] Sorting the WWW mess Martin Baldan wrote: That said, I don't see why you have an issue with search engines and search services. Even on your own machine, searching files with complex properties is far from trivial. When outside, untrusted sources are involved, you need someone to tell you what is relevant, what is not, who is lying, and so on. Google got to dominate that niche for the right reasons, namely, being much better than the competition. I wasn't clear. Actually, I didn't want to state my opinion. I can't find the message, but I (incorrectly?) remembered Alan saying that one-way links basically created the need for big search engines. As I couldn't imagine an architecture that could do away with centralized search engines, I wanted to ask about it. That said, I do have issues with Big Data search engines: they are centralized. That alone gives them more power than I'd like them to have. If we could remove the centralization while keeping the good stuff (namely, finding things), that would be really cool. Loup. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc -- Casey Ransberger ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Error trying to compile COLA
Le 01/03/2012 22:58, Casey Ransberger a écrit : Below. On Feb 29, 2012, at 5:43 AM, Loup Vaillantl...@loup-vaillant.fr wrote: Yes, I'm aware of that limitation. I have the feeling however that IDEs and debuggers are overrated. When I'm Squeaking, sometimes I find myself modeling classes with the browser but leaving method bodies to 'self break' and then write all of the actual code in the debugger. Doesn't work so well for hacking on the GUI, but, well. Okay I take it back. Your use case sounds positively awesome. I'm curious about 'debuggers are overrated' and 'you shouldn't need one.' Seems odd. Most people I've encountered who don't use the debugger haven't learned one yet. Spot on. The only debugger I have used up until now was a semi-broken version of gdb (it tended to miss stack frames). Loup. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Error trying to compile COLA
On 3/1/2012 3:56 PM, Loup Vaillant wrote: Le 01/03/2012 22:58, Casey Ransberger a écrit : Below. On Feb 29, 2012, at 5:43 AM, Loup Vaillantl...@loup-vaillant.fr wrote: Yes, I'm aware of that limitation. I have the feeling however that IDEs and debuggers are overrated. When I'm Squeaking, sometimes I find myself modeling classes with the browser but leaving method bodies to 'self break' and then write all of the actual code in the debugger. Doesn't work so well for hacking on the GUI, but, well. Okay I take it back. Your use case sounds positively awesome. I'm curious about 'debuggers are overrated' and 'you shouldn't need one.' Seems odd. Most people I've encountered who don't use the debugger haven't learned one yet. Spot on. The only debugger I have used up until now was a semi-broken version of gdb (it tended to miss stack frames). yeah... sadly, apparently the Visual Studio debugger will miss stack frames, since it apparently often doesn't know how to back-trace through code in areas it doesn't have debugging information for, even though presumably pretty much everything is using the EBP-chain convention for 32-bit code (one gets the address, followed by question-marks, and the little message stack frames beyond this point may be invalid). a lot of time this happens in my case in stack frames where the crash has occurred in code which has a call-path going through the BGBScript VM (and the debugger apparently isn't really sure how to back-trace through the generated code). note: although I don't currently have a full/proper JIT, some amount of the execution path often does end up being through generated code (often through piece-wise generate code fragments). ironically, in AMD Code Analyst, this apparently shows up as unknown module, and often accounts for more of the total running time than does the interpreter proper (although typically still only 5-10%, as the bulk of the running time tends to be in my renderer and also in nvogl32.dll and kernel.exe and similar...). or such... ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Error trying to compile COLA
Inline. On Thu, Mar 1, 2012 at 2:56 PM, Loup Vaillant l...@loup-vaillant.fr wrote: Le 01/03/2012 22:58, Casey Ransberger a écrit : Below. On Feb 29, 2012, at 5:43 AM, Loup Vaillantl...@loup-vaillant.fr wrote: Yes, I'm aware of that limitation. I have the feeling however that IDEs and debuggers are overrated. When I'm Squeaking, sometimes I find myself modeling classes with the browser but leaving method bodies to 'self break' and then write all of the actual code in the debugger. Doesn't work so well for hacking on the GUI, but, well. Okay I take it back. Your use case sounds positively awesome. It's fun:) I'm curious about 'debuggers are overrated' and 'you shouldn't need one.' Seems odd. Most people I've encountered who don't use the debugger haven't learned one yet. Spot on. The only debugger I have used up until now was a semi-broken version of gdb (it tended to miss stack frames). Oh, ouch. Missed frames. I hate it when things are ill-framed. I can't say I blame you. GDB is very *NIXy. Not really very friendly to newcomers. Crack open a Squeak image and break something. It's a whole different experience. Where is this nil value coming from? is a question that I can answer more easily in a ST-80 debugger than I can in any other that I've tried (exception of maybe Self.) The button UI on the thing could probably use a bit of modern design love (I'm sure I'm going to be trampled for saying so!) but otherwise I think it's a great study for what the baseline debugging experience ought to be for a HLL (why deal with less awesome when there's more awesome available under the MIT license as a model to work from?) Of course, I'm saying *baseline.* Which is to say that we can probably go a whole lot further with these things in the future. I'm still waiting on that magical OmniDebugger that Alessandro Warth mentioned would be able to deal with multiple OMeta-implemented languages;) Loup. __**_ fonc mailing list fonc@vpri.org http://vpri.org/mailman/**listinfo/fonchttp://vpri.org/mailman/listinfo/fonc -- Casey Ransberger ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Error trying to compile COLA
What if the aim that superseded this was to make it available to the next set of people, who can do something about real fundamental change around this? Perhaps what is needed is to ACTUALLY clear out the cruft. Maybe it's not easy or possible through the old channels... too much work to convince too many people who have so much history of the merits of tearing down the existing systems. Just a thought. Julian On 02/03/2012, at 2:04 AM, Reuben Thomas wrote: On 1 March 2012 15:02, Julian Leviston jul...@leviston.net wrote: Is this one of the aims? It doesn't seem to be, which is sad, because however brilliant the ideas you can't rely on other people to get them out for you. On 01/03/2012, at 11:42 PM, Reuben Thomas wrote: The biggest challenge for FONC will not be to achieve good technical results, as it is stuffed with people who have a history of doing great work, and its results to date are already exciting, but to get those results into widespread use; I've seen no evidence that the principals have considered how and why they failed to do this in the past, nor that they've any ideas on how to avoid it this time around. -- http://rrt.sc3d.org ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Sorting the WWW mess
Nelson's still kicking, you know: see http://gzigzag.sourceforge.net/ for some recent spin-offs. -- Max On Thu, Mar 1, 2012 at 2:56 PM, Casey Ransberger casey.obrie...@gmail.comwrote: On Thu, Mar 1, 2012 at 7:04 AM, Alan Kay alan.n...@yahoo.com wrote: Hi Loup snip However, Ted Nelson said a lot in each of the last 5 decades about what kinds of linking do the most good. (Chase down what he has to say about why one-way links are not what should be done.) He advocated from the beginning that the provenance of links must be preserved (which also means that you cannot copy what is being pointed to without also copying its provenance). This allows a much better way to deal with all manner of usage, embeddings, etc. -- including both fair use and also various forms of micropayments and subscriptions. If only we could find a way to finally deal with all that intertwingularity! One way to handle this requirement is via protection mechanisms that real objects can supply. Cheers, Alan -- *From:* Loup Vaillant l...@loup-vaillant.fr *To:* fonc@vpri.org *Sent:* Thursday, March 1, 2012 6:36 AM *Subject:* Re: [fonc] Sorting the WWW mess Martin Baldan wrote: That said, I don't see why you have an issue with search engines and search services. Even on your own machine, searching files with complex properties is far from trivial. When outside, untrusted sources are involved, you need someone to tell you what is relevant, what is not, who is lying, and so on. Google got to dominate that niche for the right reasons, namely, being much better than the competition. I wasn't clear. Actually, I didn't want to state my opinion. I can't find the message, but I (incorrectly?) remembered Alan saying that one-way links basically created the need for big search engines. As I couldn't imagine an architecture that could do away with centralized search engines, I wanted to ask about it. That said, I do have issues with Big Data search engines: they are centralized. That alone gives them more power than I'd like them to have. If we could remove the centralization while keeping the good stuff (namely, finding things), that would be really cool. Loup. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc -- Casey Ransberger ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Sorting the WWW mess
Right you are. Centralised search seems a bit silly to me. Take object orientedism and apply it to search and you get a thing where each node searches itself when asked... apply this to a local-focussed topology (ie spider web serch out) and utilise intelligent caching (so search the localised caches first) and you get a better thing, no? Why not do it like that? Or am I limited in my thinking about this? Julian On 02/03/2012, at 4:26 AM, David Barbour wrote: On Thu, Mar 1, 2012 at 7:08 AM, Martin Baldan martino...@gmail.com wrote: I think it was Julian, in message: http://vpri.org/mailman/private/fonc/2012/003131.html BTW, I'm having a hard time trying to find who said what in this mailing list. Maybe I'm missing something, I feel a bit silly, but here's the problem: _ Apparently, Google can't search this mailing list, I guess it's because of its private nature. For instance, the query: google site:http://vpri.org/mailman/private/fonc/2012/thread.html shields no results. _ I can search e-mails for keywords in my Gmail account, but when I find one, I don't know what message number it is. I only see the date and time. _ The mailing list web interface lets me arrange messages by date, but it doesn't show me the date of each message in a column. So what should I do? http://www.mail-archive.com/fonc@vpri.org/ As for centralization, I don't think you can avoid some degree of natural centralization of trust. For instance, I tend to trust the VPRI people when it comes to programming-related theory and ideas. Am I giving them too much power? ;) What should be avoided is single points of failure in infrastructure. I should be able to decide whom to trust, without artificial limits imposed by the technology. Best, -Martin ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
