Re: [fonc] goals
- Original Message - From: K. K. Subramaniam subb...@gmail.com To: fonc@vpri.org Cc: BGB cr88...@hotmail.com Sent: Tuesday, July 13, 2010 9:47 PM Subject: Re: [fonc] goals On Wednesday 14 Jul 2010 9:25:11 am BGB wrote: there is much emphasis on people understanding an entire system, whereas often a programmer does not need to have such comprehensive understanding. I like the way Dan Ingalls introduced his design principles in the article quoted earlier: The purpose of the Smalltalk project is to provide computer support for the creative spirit in everyone As you point out, most of the daily grind requires only a superficial understanding of concepts. But creative endeavors involve grand leaps of thought that require a much greater depth of understanding - one that cuts across subjects and looks beyond vocabulary. The current generation of computing is sufficient for the first set of tasks. I hope FONC is geared for the latter. BTW, the use of metaphors like deep or grand leap do have a basis in wirings in our brain. See references to long-distance connectivity in: http://www.scientificamerican.com/article.cfm?id=idle-minds-intelligence hmm, thinking here... not sure how this relates to the article, but seems to me about right. well, a further distinction can be made: low volume deep thinking; vs high-volume superficial thinking. like, a person skilled in low-volume deep thinking would tend to notice many subtleties, and maybe make a lot of deeper connections, but may easily bog down in other situations (like, say, they have to mentally keep track of the behaviors of a large number of people, or respond to lots of questions and jump between several different conversations, and quickly change between performing multiple tasks possibly at the same time). a person more skilled in high-volume thinking will do these types of tasks easily, but may be easily defeated by a task involving only a small number of items with non-trivial interactions (or may feel cramped and frustrated being expected to sit in one place and think about a single task for more than a short period of time...). or, in analogy to art: a person can spend many days working on a single piece of artwork, examining and adjusting many little details for maximum aesthetic affect; another person can produce many pieces of artwork in a single day, examining and adjusting many little details of their process for maximum efficiency and volume. even though both are artists, they would have notably different abilities and skillsets, and neither could likely effectively do the job of the other. the low-volume artist would likely feel bewildered if expected to produce, say, 25 images in an 8 hour shift; the high-volume artist would likely feel lost in trying to make an image that looked like much more than something out of a comic book... one might try to draw a person posing by some vines and a lamp-post, putting much effort into the reflections on the glass and metal, and on the shimmer of the water on the lake in the background. the other might try to draw a person right in the middle of being blown apart by machine-gun fire from a large robot with chunks partly detached and in the (implied) process of flying off. their idea then of improving the aesthetics is to start putting sparks on the ground and spent bullet casings on the ground near the robot, and then they lose direction after approx 30 minutes or so... something sort of like this could also matter WRT programming language preferences as well... then again, it could also be related to psychology as well (not sure, like where people in different tempermants and using different cognitive functions would likely fall on these sorts of scales). or such... ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goals (beyond the pleasure trap?)
On 14 July 2010 10:49, Antoine van Gelder anto...@g7.org.za wrote: Questions such as how do we define a downward trajectory? or which direction is simple in? or even how can we even possibly hope to measure simple?! There is nothing hard about simplification per se. I don't think I've made a significant contribution to any software project that hasn't been net negative in LOC. The problem is that this often doesn't make a significant dent in the overall size (and hence, usually, complexity) of the project. However, you're quite right to point to the difficulties of measuring complexity. What one can intuitively recognise and fix is not necessarily easy to measure. I can imagine automatic measurements of several things that are easy to measure, but I've never seen tools for: average length of function in LOC, average number of function calls per function, number of callees, number of callers. But things can get complicated. For example, a long function with few calls might seem like a classic case of bad programming...or it might be the sort of what I call narrative code that is typical in initialisation and shut-down routines, and sometimes pops up elsewhere. In either case, it is unlikely to be complex *in itself* (in the absence of gotos), but if it should have been decomposed, then it's imposing complexity elsewhere. The classic case of a little complexity imposed everywhere is the code base that is too little abstracted. I spent a couple of years working on a proprietary application that consisted of a core of about 30 kLOC, with a plethora of application modules written on top that totalled about 1 MLOC. Reading and writing application code made my head hurt, because doing simple things was hard, but none of the code was actually that complex (the system was basically a database with lots of customised forms). But improving an application was a very small win, as it only improved that one module. My three main efforts over the time I worked on that system were first to make the core portable, largely just a matter of removing #ifdefs and relying on the fact that the systems on which it built had all started supporting the same standards since the code was first written, secondly, to remove dead code (e.g. an old version of a reporting system, because although the new version was an optional extra that customers paid for, it was itself almost obsolete, and company records showed that all current customers paid for it), and thirdly to write a scripting language skin for the application system, to make it possible to write applications in much less code (very ill-advised, as it turned out, as I was never given the resources to train other programmers in its use, so when I left the company had not only a useless scripting system with extra build- and run-time dependencies for our system, but an important application (which I wrote) written in a language that no-one else at the company knew). Insufficient abstraction may be an extreme example of complexity thati's hard to measure, but even kinds like duplicate code are tricky. I recently found, by inspection, a duplicate function that has been lurking in a code base of ~10 kLOC that I've been rewriting for years (the text editor GNU Zile; it started off at ~20 kLOC). It is really only because I'm currently translating the entire application into another language (from C to Lua) that I was a) reading the code and b) had enough context in my head to realise that the code I was looking at was redundant. In fact, I've managed to remove hundreds of lines of C code during this translation project, and that is despite the fact that I had already spent probably months trying refactoring and simplifying the existing code. It is interesting to speculate whether I would have found these simplifications had I not been actually translating rather than simply reading the code. ps. Make no mistake. Paul is right on the money. Even if no-one wants to 'fess up most of us _are_ being measured (implicitly) on SLOC. This seems right. In my case, this was expressed as concern that I was not producing enough application code (my assigned work) and was instead spending my time re-engineering the code (what the company actually needed, in my view, but then my view was biased as it was far more interesting). This despite the fact that more than one of my bits of re-engineering saved serious corporate bacon. However, the underlying cause is that the company was directly earning revenue from developments to the product (new applications). I theorise that even sticking with SLOC as a primary productivity measure, had they actually been able to measure my effect on the other programmers' productivity, I might've got away with doing what I did. Our customers had the same problem: easy to say we need a new app that does this; much harder to say we need to improve the way we do that. The cultural factors at work are all too obvious. Since there's an obvious link between new
Re: [fonc] goals
On 14 July 2010 00:01, John Zabroski johnzabro...@gmail.com wrote: [1] http://www.cs.stir.ac.uk/~kjt/techreps/pdf/TR141.pdf FOR FUN: Where is the bug here? The authors claim they are measuring the *economic* expressiveness of languages. I think I don't really follow you here (you seem in a slightly whimsical mood), but I just thought I'd point out that the authors claim no such thing. The word economic does not appear in the paper. Economically appears once, and the context is: Halstead’s claim is that the higher the mean language level the more powerful the language is. We prefer instead to say ‘more expressive’ by which we mean that the same algorithm can be expressed more economically. That is, the authors are talking about economy, i.e. brevity, of expression, and not about economics. If by the reference to cargo cults, you mean a sort of inverse cargo cult in which the shorter the program, the simpler it's supposed to be, I say hear hear! while distancing myself from the concordant cheers of the APL-haters. -- http://rrt.sc3d.org ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goals
Well, you're right. The way I phrased it isn't at all proper. I meant the authors were using economy of expression [1] as their metric. In programming languages lingo, the phrase more expressive the authors use is co-opting the meaning of expressive as defined by Felleisen's expressiveness framework [2] or Hewitt and Patterson's Comparative Schematology [3] [4]. I am asking a general question: Why is economy of expression deceitful? [1] http://c2.com/cgi/wiki?EconomyOfExpression [2] http://www.ccs.neu.edu/scheme/pubs/scp91-*felleisen*.ps.gz [3] http://dspace.mit.edu/handle/1721.1/6291 [4] http://dspace.mit.edu/handle/1721.1/5849 On Wed, Jul 14, 2010 at 6:59 AM, Reuben Thomas r...@sc3d.org wrote: On 14 July 2010 00:01, John Zabroski johnzabro...@gmail.com wrote: [1] http://www.cs.stir.ac.uk/~kjt/techreps/pdf/TR141.pdfhttp://www.cs.stir.ac.uk/%7Ekjt/techreps/pdf/TR141.pdf FOR FUN: Where is the bug here? The authors claim they are measuring the *economic* expressiveness of languages. I think I don't really follow you here (you seem in a slightly whimsical mood), but I just thought I'd point out that the authors claim no such thing. The word economic does not appear in the paper. Economically appears once, and the context is: Halstead’s claim is that the higher the mean language level the more powerful the language is. We prefer instead to say ‘more expressive’ by which we mean that the same algorithm can be expressed more economically. That is, the authors are talking about economy, i.e. brevity, of expression, and not about economics. If by the reference to cargo cults, you mean a sort of inverse cargo cult in which the shorter the program, the simpler it's supposed to be, I say hear hear! while distancing myself from the concordant cheers of the APL-haters. -- 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] goals
On 13/07/2010, at 10:29 PM, Jecel Assumpcao Jr. wrote: The lack of scalability that I was talking about is where a system becomes too much for any person to understand. Though lines of code is very simplistic, Alan has compared code sizes of various projects with different kinds of books in a few of his talks. There are texts that almost anybody can read and there are others that nobody ever will. Certainly you can't understand something you have not read. So that is one bottleneck. I bet there are others - even in a system that is reasonably short there might be too many combinations of elements to understand: http://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html -- Jecel This is extremely interesting to me, because I could ask you very simply: Do you understand the basic relationship between planets? Also... of how animal (including our) bodies inter-relate? Also... of how biological cells interact with each other? Do you see what my point is? Perhaps if one introduces scale properly, there is no limit to what one can understand. Julian. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goals
yes. there is much emphasis on people understanding an entire system, whereas often a programmer does not need to have such comprehensive understanding. in a large codebase, for example, parts of the project will come into view as one works on them, and when one moves elsewhere they may pass away from memory. with an abstracted system, pretty much the entire system may be viewed essentially as a black-box, with people looking at the externals but paying no attention to what happens on the inside. a person working within this system may in-turn see the system in terms of so many black-boxes, and at the same time view what happens externally as a sort of black box (or, as outside of the current scope). of course, this sort of thinking generally requires a fair level of standardization at the interfaces between these systems, such that what goes on inside the box does not break what is outside and vice versa. so, often, one may define their APIs and/or data representations before actually having code in place on either side of the boundary (a non-existant app working against a non-existant library). but, OTOH, this strategy does seem to scale fairly well, as with multi-million line projects, it is unlikely much of anyone will really look over the whole thing. however, in these cases, it is fairly important that these boxes also be open (as in, the internals of a complex system are left where programmers can access them), since a black monolith is in turn of limited utility. so, some of this is tradeoffs. - Original Message - From: Julian Leviston To: Fundamentals of New Computing Sent: Tuesday, July 13, 2010 7:33 PM Subject: Re: [fonc] goals On 13/07/2010, at 10:29 PM, Jecel Assumpcao Jr. wrote: The lack of scalability that I was talking about is where a system becomes too much for any person to understand. Though lines of code is very simplistic, Alan has compared code sizes of various projects with different kinds of books in a few of his talks. There are texts that almost anybody can read and there are others that nobody ever will. Certainly you can't understand something you have not read. So that is one bottleneck. I bet there are others - even in a system that is reasonably short there might be too many combinations of elements to understand: http://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html -- Jecel This is extremely interesting to me, because I could ask you very simply: Do you understand the basic relationship between planets? Also... of how animal (including our) bodies inter-relate? Also... of how biological cells interact with each other? Do you see what my point is? Perhaps if one introduces scale properly, there is no limit to what one can understand. Julian. -- ___ 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] goals
On 14/07/2010, at 1:55 PM, BGB wrote: yes. there is much emphasis on people understanding an entire system, whereas often a programmer does not need to have such comprehensive understanding. in a large codebase, for example, parts of the project will come into view as one works on them, and when one moves elsewhere they may pass away from memory. with an abstracted system, pretty much the entire system may be viewed essentially as a black-box, with people looking at the externals but paying no attention to what happens on the inside. a person working within this system may in-turn see the system in terms of so many black-boxes, and at the same time view what happens externally as a sort of black box (or, as outside of the current scope). of course, this sort of thinking generally requires a fair level of standardization at the interfaces between these systems, such that what goes on inside the box does not break what is outside and vice versa. so, often, one may define their APIs and/or data representations before actually having code in place on either side of the boundary (a non-existant app working against a non-existant library). but, OTOH, this strategy does seem to scale fairly well, as with multi-million line projects, it is unlikely much of anyone will really look over the whole thing. however, in these cases, it is fairly important that these boxes also be open (as in, the internals of a complex system are left where programmers can access them), since a black monolith is in turn of limited utility. so, some of this is tradeoffs. Yes, that's exactly what I was saying. I believe it's called Encapsulation :P Having an interface and passing messages is incredibly mis-understood generally amongst programmers, it seems to me. It's impossible to scale well without an interface to objects. In exactly the same way that cells have cellular walls, animal bodies have skins or planets have atmospheres, objects need interfaces... My interest lies in tiny objects... because small amounts of things are usually more understandable for us humans, and because perhaps there is such a thing as a planck feature meaning the smallest size one can get to and still call it a feature (or object). For example, if I'm considering a certain scale where oranges are distinct objects from other fruits, then perhaps one or ten oranges interacting with each other is very understandable. Two hundred thousand objects interacting is less understandable for humans. But if you look at the scale of orange juice factories, perhaps 200,000 oranges (relabelled as raw product quantity) is easy to comprehend because it means something different in that context of scale. Mental visualisation is inherently useful when it comes to comprehensibility of systems. Better than mental visualisation, is EXPLICIT graphic visualisation. If we could come to a system that inherently understands context of scale and allows us to present things graphically with relation to this, we'd really have something worth some value for the entirety of humanity IMHO. Put simply, our systems only seem to represent ONE context of scale and don't allow comprehensive illustration of where we're looking on a general (ie they lack an awareness of scale-context). Hopefully all of this is understandable. Julian.___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goals
Steve Dekorte wrote on Sat, 10 Jul 2010 03:22:29 -0700 On 2010-07-10, at 12:25 AM, Hans-Martin Mosner wrote: For quite some time I've been pondering the duality of the class/instance and method/context relations. In some sense, a context is an object created by instantiating its method, much like a normal object is instantiated from its class... Self does just that: http://labs.oracle.com/self/language.html Io (following Self's example) does as well. In this recent video: http://www.infoq.com/interviews/johnson-armstrong-oop Indeed, but these two languages are, perhaps, even better examples: http://www.daimi.au.dk/~beta/ http://www.erights.org/elang/index.html Ralph Johnson talks about how long it takes for computing culture to absorb new ideas (in his example, things like OO, garbage collection and dynamic message passing) despite them being obvious next steps in retrospect. I think prototypes could also be an example of this. It seems as if each computing culture fails to establish a measure for it's own goals which leaves it with no means of critically analyzing it's assumptions resulting in the technical equivalent of religious dogma. From this perspective, new technical cultures are more like religious reform movements than new scientific theories which are measured by agreement with experiment. e.g. had the Smalltalk community said if it can reduce the overall code X without a performance cost Y it's better, perhaps prototypes would have been adopted long ago. When I think about the issue of FONC goals, I always remember Alan's supersized dog house vs Empire State Building illustration. It isn't about making it smaller (though I also love that - ColorForth is one of my favorite systems) but making it understandable so it can be built by humans in such a way that it can become vast. Like the Internet. The other day I saw on the local news a three story building collapse as if it had been imploded on purpose. The people who built it had initially made just one floor, and it worked great. Then they added a second floor, and it was nice. Now they were shocked that having a third floor, which looked exactly like the original two, brought down the whole thing. Neither architecture nor engineering were part of this story, as far as I could tell. But this could be said of essentially all programmers, computer scientists and software engineers that I know. Weinberg's Second Law: If builders built buildings the way programmers write programs, then the first woodpecker that came along would destroy civilization. -- Jecel ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goals
Steve, Something pointed out to me by Microsoft Silverlight -and- Expression Blend architect John Gossman [1] is that eventually these issues get resolved, but the process is pretty ugly. He linked this book as a reference point http://www.amazon.com/Strangest-Man-Quantum-Genius-Farmelo/dp/0571222781 One of Alan's goals is figuring out how we can compress the timespan for going through this process; read the NSF stuff about from nothing bootstrapping as an example. [1] John is widely respected inside Redmond, because he is so good at taking complex formulations of ideas and distilling them down into simple formalisms. On Sat, Jul 10, 2010 at 6:22 AM, Steve Dekorte st...@dekorte.com wrote: On 2010-07-10, at 12:25 AM, Hans-Martin Mosner wrote: For quite some time I've been pondering the duality of the class/instance and method/context relations. In some sense, a context is an object created by instantiating its method, much like a normal object is instantiated from its class... Self does just that: http://labs.oracle.com/self/language.html Io (following Self's example) does as well. In this recent video: http://www.infoq.com/interviews/johnson-armstrong-oop Ralph Johnson talks about how long it takes for computing culture to absorb new ideas (in his example, things like OO, garbage collection and dynamic message passing) despite them being obvious next steps in retrospect. I think prototypes could also be an example of this. It seems as if each computing culture fails to establish a measure for it's own goals which leaves it with no means of critically analyzing it's assumptions resulting in the technical equivalent of religious dogma. From this perspective, new technical cultures are more like religious reform movements than new scientific theories which are measured by agreement with experiment. e.g. had the Smalltalk community said if it can reduce the overall code X without a performance cost Y it's better, perhaps prototypes would have been adopted long ago. - Steve ___ 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] goals
Am 10.07.2010 01:24, schrieb Alan Kay: ... a hobby was finding much more compact ways to do Lisp (it can really be shrunk down from John's version) and amounts really to being able to say what it means to send a message from one context to another For quite some time I've been pondering the duality of the class/instance and method/context relations. In some sense, a context is an object created by instantiating its method, much like a normal object is instantiated from its class. Simula's classes and methods looked very much like this. I think that this might be a direction in which simplification can be found. In some spare time I've tried to realize this as a language Nest which looks very much like Newspeak (implicit receivers, classes as modules) but emphasizes on being able to arbitrarily nest classes and methods. It's not really fleshed out yet (I have a compiler and emulator in Squeak+OMeta) and I already see some shortcomings. I have to pick it up and work on it again to get it into a state where people could look at it... Cheers, Hans-Martin ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goals
On 2010-07-10, at 12:25 AM, Hans-Martin Mosner wrote: For quite some time I've been pondering the duality of the class/instance and method/context relations. In some sense, a context is an object created by instantiating its method, much like a normal object is instantiated from its class... Self does just that: http://labs.oracle.com/self/language.html Io (following Self's example) does as well. In this recent video: http://www.infoq.com/interviews/johnson-armstrong-oop Ralph Johnson talks about how long it takes for computing culture to absorb new ideas (in his example, things like OO, garbage collection and dynamic message passing) despite them being obvious next steps in retrospect. I think prototypes could also be an example of this. It seems as if each computing culture fails to establish a measure for it's own goals which leaves it with no means of critically analyzing it's assumptions resulting in the technical equivalent of religious dogma. From this perspective, new technical cultures are more like religious reform movements than new scientific theories which are measured by agreement with experiment. e.g. had the Smalltalk community said if it can reduce the overall code X without a performance cost Y it's better, perhaps prototypes would have been adopted long ago. - Steve ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goals
Or multi-methods / multiple dispatch? On Sat, Jul 10, 2010 at 3:22 AM, Steve Dekorte st...@dekorte.com wrote: It seems as if each computing culture fails to establish a measure for it's own goals which leaves it with no means of critically analyzing it's assumptions resulting in the technical equivalent of religious dogma. From this perspective, new technical cultures are more like religious reform movements than new scientific theories which are measured by agreement with experiment. e.g. had the Smalltalk community said if it can reduce the overall code X without a performance cost Y it's better, perhaps prototypes would have been adopted long ago. -- -Brian T. Rice ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goals
On Thu, 8 Jul 2010 18:01:36 -0700 (PDT) Alan Kay alan.n...@yahoo.com wrote: ...seeing if very compact runable maths could be invented and built to model... Isn't this a good definition of Lisp? Denis vit esse estrany ☣ spir.wikidot.com ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goals
On 2010-07-08, at 9:21 PM, Steve Dekorte wrote: Thanks for the response. That kind of sounds like the goal is fewer lines of code (and presumably less labor) per unit of function (increasing productivity). Is that correct? Well, I don't speak for Alan, but I have to think it's a bit more than that. The biggest problem we have in computing is that we're terrible at it. Just the other day I remarked to a colleague that the system we were working on had about 10x too much code for what it did, and he agreed. So yes, less code for the same functionality might (might!) be higher productivity, but it's also a rough measure of quality. Writers seek economy of words, athletes seek economy of motion, we seek economy of code. Colin ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goals
On 2010-07-09, at 12:56 AM, Colin Putney wrote: On 2010-07-08, at 9:21 PM, Steve Dekorte wrote: Thanks for the response. That kind of sounds like the goal is fewer lines of code (and presumably less labor) per unit of function (increasing productivity). Is that correct? Well, I don't speak for Alan, but I have to think it's a bit more than that. The biggest problem we have in computing is that we're terrible at it. Just the other day I remarked to a colleague that the system we were working on had about 10x too much code for what it did, and he agreed. So yes, less code for the same functionality might (might!) be higher productivity, but it's also a rough measure of quality. Writers seek economy of words, athletes seek economy of motion, we seek economy of code. I agree that labor including maintenance (which may include understandability, extendability, etc) is a better end measure but that code length (or maybe keystrokes, etc) can be a reasonable starting point for measuring it. Btw, this discussion may sound trivial, but consider the question: Is computing technique X is better than Y? We need to know by what measure it's better for the question to be meaningful. And without a measure that matches one's goals, decisions made on their basis may be counterproductive. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goals
yeah. I guess a lot depends on other factors though. for example, is a lot of this added code because: the programmer has little idea what he was doing, and so just wildly copy-pasted everywhere and made a big mess?... has lots of code which is actually beneficial, such as doing error checking and building abstractions. similarly, is a piece of code smaller because: the programmer is good at getting work done in less code? or because the code is essentially a tangled mess of hacks? these may matter more in many cases than the total code size. like, if the app is only 10 or 15 kloc, but most of it is composed of if(...) goto ... and ugly use of bit-twiddling and pointer operations (say, you see things like ((int *)(((void **)p)[i+5]))[16]+*(int *)(*(void **)q) pretty much every-other line), and the programmer couldn't be bothered to use more than 3 or 4 characters for most of their function names, this is not necessarily a good thing. a similar app which is maybe 20-25 kloc, but consists of code which may be understood (and doesn't blow up in ones' face as soon as it is fed bad data), may be a little better. but, then again, sometimes an app may benefit from being smaller, for simple sake that ordinary humans can work on it (without having to go up a steep learning curve and having to become experts on the thing before being able to do much of anything). for example, a 350 kloc app may be better, even if it does a little less, than a 5 or 10 Mloc app, if it means that the programmers can more easily understand the thing in its entirety. feature bloat is also a problem. features may be good, but too many features may not be a benefit to ones' purpose, and sometimes a piece of code which is smaller and only does a few things well, may be better than a larger piece of code trying to do everything adequately... (sometimes, we don't need some unified one true implementation). but, a lot comes down to abstraction as well: a much larger codebase with much better abstractions may still be much easier to work on than a smaller codebase with few or poorly-chosen abstractions (for example, if the codebase is relatively well organized, and its code relatively self-explaining, then one can more easily get things done without having to keep as much in-mind, but if changing something one place means they have to fix something somewhere else which breaks as a result, this is a problem...). but, there are many factors involved. or such... - Original Message - From: Colin Putney cput...@wiresong.ca To: Fundamentals of New Computing fonc@vpri.org Sent: Friday, July 09, 2010 12:56 AM Subject: Re: [fonc] goals On 2010-07-08, at 9:21 PM, Steve Dekorte wrote: Thanks for the response. That kind of sounds like the goal is fewer lines of code (and presumably less labor) per unit of function (increasing productivity). Is that correct? Well, I don't speak for Alan, but I have to think it's a bit more than that. The biggest problem we have in computing is that we're terrible at it. Just the other day I remarked to a colleague that the system we were working on had about 10x too much code for what it did, and he agreed. So yes, less code for the same functionality might (might!) be higher productivity, but it's also a rough measure of quality. Writers seek economy of words, athletes seek economy of motion, we seek economy of code. Colin ___ 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] goals
for example, is a lot of this added code because: the programmer has little idea what he was doing, and so just wildly copy-pasted everywhere and made a big mess?... has lots of code which is actually beneficial, such as doing error checking and building abstractions. similarly, is a piece of code smaller because: the programmer is good at getting work done in less code? or because the code is essentially a tangled mess of hacks? It isn't that the programmer has little idea of what he is doing. Things just take time to be transformed into an optimal form. There is a good example from the history from math, and physics that illustrates the point. Maxwells equations originally applied to a set of eight equations published by Maxwell in 1865. After that the number of equations escalated to twenty equations in twenty unknowns as people struggled with the implications. Maxwell wrestled with recasting the equations in quaternion form. Time passed. It was all very ugly. Finally In 1884 Oliver Heaviside recast Maxwell's math from the then cumbersome form to its modern vector calculus notation, thereby reducing the twenty equations in twenty unknowns down to the four differential equations in two unknowns that we all love and call Maxwells equations. Heaviside invented the modern notation giving us the tools to make sense of something very profound and useful. Good work on hard things takes time plus a lot of good people that care. cheers, -David Leibs ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
RE: [fonc] goals
From: fonc-boun...@vpri.org [mailto:fonc-boun...@vpri.org] On Behalf Of David Leibs Sent: Friday, July 09, 2010 1:33 PM To: Fundamentals of New Computing Subject: Re: [fonc] goals It isn't that the programmer has little idea of what he is doing. Things just take time to be transformed into an optimal form. The programmer must also be given permission to take that time. I can remember only once in 23 years of software development when my employer actually told everyone to stop and clean up the code for 2 weeks. No new features, just make the code better. I was astonished, and very pleased. This sort of thing should be done as a matter of course. Alan and Co. seem to me to be trying to make up for decades of our industry refusing to clean up the code. What is 20 million lines of code can be 20 thousand. If you can apply the 80/20 rule to this in the sense that you can provide people with a lever that does 80 percent of what you need, and if the system is tractable for motivated casual coders so that they can provide the other 20 percent then you have something really valuable. Early home computers provided some of this quality in spite of their shortcomings. The machines and languages were simple enough so that anyone with enough attention span to read a 250 page book could bend the computer to his will. That's a vision of personal computing. I think this idea is lost in our popular culture. -Carl Gundel Psyche Systems ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goals
Just to be clear, The foremost experts and definitive source on software metrics -- Fenton and Pfleeger [1] -- do not really support SLOC/day/programmer as a good metric for productivity. It seems to me (from hearing reports by others) that most people do not actually read books on metrics and instead gravitate towards the simplest ones, regardless of effectiveness. Usually SLOC/day/programmer is a good way, though, to convince your boss that a project predicted to be 300,000 lines of brute force coding cannot be done in a weekend. The argument being you literally cannot type that fast. Cheers, Z-Bo [1] http://www.amazon.com/Software-Metrics-Norman-E-Fenton/dp/0534956009 On Fri, Jul 9, 2010 at 2:47 PM, Max OrHai max.or...@gmail.com wrote: Just to clarify, I'm a bit uncomfortable with productivity talk here because it seems too narrow and ill-defined. Productivity of what exactly? By whom? For whom? To what end? To a specific manager of a specific project in a specific development phase, these questions may have specific, meaningful answers. When it comes to fundamentally rethinking basic tools and practices, I'm not so sure. Of course, core values must be somewhat vague, to allow them to mesh with constantly changing circumstances. Personally, I'd rather strive for quality than productivity. I'm generally suspicious of premature quantification: just because you can measure something doesn't make it meaningful! It seems to me that, as crufty, haphazard, hidebound, etc. as software engineering is today, software engineering management (with its productivity metrics such as source lines of code per programmer per day) are even worse. We all know code quality varies wildly between programmers using the exact same sets of tools. Talent and training contribute enormously. However, I imagine that everyone on this list can agree that the tools themselves matter too, even if it's difficult to quantify that difference precisely. Keep it simple is a widely applicable and successful heuristic. I see this project as (largely) an experiment in applying that heuristic to the fairly well-defined category of creating the personal computing experience, with a depth and breadth impossible in the productivity/profit-bound world of commercial software, and a consistency and quality level impossible in the the traditional open-source project. It's just an experiment, though. It's *research* (or, if you prefer, intellectual masturbation). If we already knew the outcome, it wouldn't be research, would it? -- Max On Fri, Jul 9, 2010 at 10:33 AM, David Leibs david.le...@oracle.comwrote: for example, is a lot of this added code because: the programmer has little idea what he was doing, and so just wildly copy-pasted everywhere and made a big mess?... has lots of code which is actually beneficial, such as doing error checking and building abstractions. similarly, is a piece of code smaller because: the programmer is good at getting work done in less code? or because the code is essentially a tangled mess of hacks? It isn't that the programmer has little idea of what he is doing. Things just take time to be transformed into an optimal form. There is a good example from the history from math, and physics that illustrates the point. Maxwells equations originally applied to a set of eight equations published by Maxwell in 1865. After that the number of equations escalated to twenty equations in twenty unknowns as people struggled with the implications. Maxwell wrestled with recasting the equations in quaternion form. Time passed. It was all very ugly. Finally In 1884 Oliver Heaviside recast Maxwell's math from the then cumbersome form to its modern v http://en.wikipedia.org/wiki/Vector_%28geometric%29ector calculus notation, thereby reducing the twenty equations in twenty unknowns down to the four differential equations in two unknowns that we all love and call Maxwells equations. Heaviside invented the modern notation giving us the tools to make sense of something very profound and useful. Good work on hard things takes time plus a lot of good people that care. cheers, -David Leibs ___ 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
Re: [fonc] goals
I am somewhat dyslexic and I don't always read things in the right order so I read SLOC/day/programmer as SHLOCK/day/programmer it fits in a negative metric kinda way. Maybe it is a meme we should unleash on our overlings. -djl On Jul 9, 2010, at 12:16 PM, John Zabroski wrote: Just to be clear, The foremost experts and definitive source on software metrics -- Fenton and Pfleeger [1] -- do not really support SLOC/day/programmer as a good metric for productivity. It seems to me (from hearing reports by others) that most people do not actually read books on metrics and instead gravitate towards the simplest ones, regardless of effectiveness. Usually SLOC/day/programmer is a good way, though, to convince your boss that a project predicted to be 300,000 lines of brute force coding cannot be done in a weekend. The argument being you literally cannot type that fast. Cheers, Z-Bo [1] http://www.amazon.com/Software-Metrics-Norman-E-Fenton/dp/0534956009 On Fri, Jul 9, 2010 at 2:47 PM, Max OrHai max.or...@gmail.com wrote: Just to clarify, I'm a bit uncomfortable with productivity talk here because it seems too narrow and ill-defined. Productivity of what exactly? By whom? For whom? To what end? To a specific manager of a specific project in a specific development phase, these questions may have specific, meaningful answers. When it comes to fundamentally rethinking basic tools and practices, I'm not so sure. Of course, core values must be somewhat vague, to allow them to mesh with constantly changing circumstances. Personally, I'd rather strive for quality than productivity. I'm generally suspicious of premature quantification: just because you can measure something doesn't make it meaningful! It seems to me that, as crufty, haphazard, hidebound, etc. as software engineering is today, software engineering management (with its productivity metrics such as source lines of code per programmer per day) are even worse. We all know code quality varies wildly between programmers using the exact same sets of tools. Talent and training contribute enormously. However, I imagine that everyone on this list can agree that the tools themselves matter too, even if it's difficult to quantify that difference precisely. Keep it simple is a widely applicable and successful heuristic. I see this project as (largely) an experiment in applying that heuristic to the fairly well-defined category of creating the personal computing experience, with a depth and breadth impossible in the productivity/profit-bound world of commercial software, and a consistency and quality level impossible in the the traditional open- source project. It's just an experiment, though. It's research (or, if you prefer, intellectual masturbation). If we already knew the outcome, it wouldn't be research, would it? -- Max On Fri, Jul 9, 2010 at 10:33 AM, David Leibs david.le...@oracle.com wrote: for example, is a lot of this added code because: the programmer has little idea what he was doing, and so just wildly copy-pasted everywhere and made a big mess?... has lots of code which is actually beneficial, such as doing error checking and building abstractions. similarly, is a piece of code smaller because: the programmer is good at getting work done in less code? or because the code is essentially a tangled mess of hacks? It isn't that the programmer has little idea of what he is doing. Things just take time to be transformed into an optimal form. There is a good example from the history from math, and physics that illustrates the point. Maxwells equations originally applied to a set of eight equations published by Maxwell in 1865. After that the number of equations escalated to twenty equations in twenty unknowns as people struggled with the implications. Maxwell wrestled with recasting the equations in quaternion form. Time passed. It was all very ugly. Finally In 1884 Oliver Heaviside recast Maxwell's math from the then cumbersome form to its modern vector calculus notation, thereby reducing the twenty equations in twenty unknowns down to the four differential equations in two unknowns that we all love and call Maxwells equations. Heaviside invented the modern notation giving us the tools to make sense of something very profound and useful. Good work on hard things takes time plus a lot of good people that care. cheers, -David Leibs ___ 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 ___ fonc mailing list fonc@vpri.org
Re: [fonc] goals
Just wondering... when did that metaphor get started at VPRI? The first time I had heart you reference the t-shirt metaphor was October 2009 [1]. I remember joking about it on Lambda the Ultimate in April of 2009 [2], and my joke was actually based on a presentation given by the head operations physicist of the Relativistic Heavy Ion Collider project at BNL, Todd Satogata [3]. He gave a talk about how you can buy a t-shirt with Maxwell's Equations on it and it pretty much describes the whole universe. But he said his goal was to unify the strong force and weak force and come up with a new t-shirt, and make millions of dollars and become famous. When I heard that you were interested in Maxwell's Equations for Computer Science, I immediately made the connection to Todd Satogata's BNL speech (I've heard him give roughly the same pitch in other speeches many times), so that is why I made the joke about printing Maxwell's Equations for Computer Science on a t-shirt. [1] http://media.cs.uiuc.edu/seminars/StateFarm-Kay-2009-10-22a.asx [2] http://lambda-the-ultimate.org/node/3265#comment-48129 [3] http://toddsatogata.net/ On Fri, Jul 9, 2010 at 1:44 PM, Alan Kay alan.n...@yahoo.com wrote: One of my all time favorite metaphors and examples for part of what we are trying to do in this T-shirt programming project. Cheers, Alan -- *From:* David Leibs david.le...@oracle.com *To:* Fundamentals of New Computing fonc@vpri.org *Sent:* Fri, July 9, 2010 10:33:04 AM *Subject:* Re: [fonc] goals for example, is a lot of this added code because: the programmer has little idea what he was doing, and so just wildly copy-pasted everywhere and made a big mess?... has lots of code which is actually beneficial, such as doing error checking and building abstractions. similarly, is a piece of code smaller because: the programmer is good at getting work done in less code? or because the code is essentially a tangled mess of hacks? It isn't that the programmer has little idea of what he is doing. Things just take time to be transformed into an optimal form. There is a good example from the history from math, and physics that illustrates the point. Maxwells equations originally applied to a set of eight equations published by Maxwell in 1865. After that the number of equations escalated to twenty equations in twenty unknowns as people struggled with the implications. Maxwell wrestled with recasting the equations in quaternion form. Time passed. It was all very ugly. Finally In 1884 Oliver Heaviside recast Maxwell's math from the then cumbersome form to its modern v http://en.wikipedia.org/wiki/Vector_%28geometric%29ector calculus notation, thereby reducing the twenty equations in twenty unknowns down to the four differential equations in two unknowns that we all love and call Maxwells equations. Heaviside invented the modern notation giving us the tools to make sense of something very profound and useful. Good work on hard things takes time plus a lot of good people that care. cheers, -David Leibs ___ 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] goals
The metaphor happened to me in grad school in the 60s when I finally took the trouble to trace McCarthy's Lisp in itself and realized just how powerful and comprehensive he had made it in such a compact way. It was not so much the Turing aspect but the slope of the power from nothing. I said to myself this is the Maxwell's Equations of computing. I think I recounted this in the Early History of Smalltalk. And as a science and math major as an undergraduate, I knew the story that David told about how Heaviside had collapsed the difficult to understand partial differential equations form into the vectorized-operatorized t-shirt size we know. As a post-doc I had some fun working in McCarthy's lab at Stanford and a hobby was finding much more compact ways to do Lisp (it can really be shrunk down from John's version) and amounts really to being able to say what it means to send a message from one context to another Cheers, Alan From: John Zabroski johnzabro...@gmail.com To: Fundamentals of New Computing fonc@vpri.org Sent: Fri, July 9, 2010 2:48:27 PM Subject: Re: [fonc] goals Just wondering... when did that metaphor get started at VPRI? The first time I had heart you reference the t-shirt metaphor was October 2009 [1]. I remember joking about it on Lambda the Ultimate in April of 2009 [2], and my joke was actually based on a presentation given by the head operations physicist of the Relativistic Heavy Ion Collider project at BNL, Todd Satogata [3]. He gave a talk about how you can buy a t-shirt with Maxwell's Equations on it and it pretty much describes the whole universe. But he said his goal was to unify the strong force and weak force and come up with a new t-shirt, and make millions of dollars and become famous. When I heard that you were interested in Maxwell's Equations for Computer Science, I immediately made the connection to Todd Satogata's BNL speech (I've heard him give roughly the same pitch in other speeches many times), so that is why I made the joke about printing Maxwell's Equations for Computer Science on a t-shirt. [1] http://media.cs.uiuc.edu/seminars/StateFarm-Kay-2009-10-22a.asx [2] http://lambda-the-ultimate.org/node/3265#comment-48129 [3] http://toddsatogata.net/ On Fri, Jul 9, 2010 at 1:44 PM, Alan Kay alan.n...@yahoo.com wrote: One of my all time favorite metaphors and examples for part of what we are trying to do in this T-shirt programming project. Cheers, Alan From: David Leibs david.le...@oracle.com To: Fundamentals of New Computing fonc@vpri.org Sent: Fri, July 9, 2010 10:33:04 AM Subject: Re: [fonc] goals for example, is a lot of this added code because: the programmer has little idea what he was doing, and so just wildly copy-pasted everywhere and made a big mess?... has lots of code which is actually beneficial, such as doing error checking and building abstractions. similarly, is a piece of code smaller because: the programmer is good at getting work done in less code? or because the code is essentially a tangled mess of hacks? It isn't that the programmer has little idea of what he is doing. Things just take time to be transformed into an optimal form. There is a good example from the history from math, and physics that illustrates the point. Maxwells equations originally applied to a set of eight equations published by Maxwell in 1865. After that the number of equations escalated to twenty equations in twenty unknowns as people struggled with the implications. Maxwell wrestled with recasting the equations in quaternion form. Time passed. It was all very ugly. Finally In 1884 Oliver Heaviside recast Maxwell's math from the then cumbersome form to its modern vector calculus notation, thereby reducing the twenty equations in twenty unknowns down to the four differential equations in two unknowns that we all love and call Maxwells equations. Heaviside invented the modern notation giving us the tools to make sense of something very profound and useful. Good work on hard things takes time plus a lot of good people that care. cheers, -David Leibs ___ 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] goals
I know that part. I meant extending the metaphor to the joke about printing t-shirts. David mentioned collapsing this, and I mentioned how I brought up the joke on LtU about doing this for computer science. I've read your Maxwell's Equations for Computer Science before, such as the NSF 2007 report, but never read the t-shirt joke before the talk I linked below. I first heard this joke from Todd Satogata, who wants to keep Maxwell's Equations as simple as a cool t-shirt, but increase its expressive power by unifying the strong and weak forces -- it just shows even physicists don't give up shrinking the size of the core theory that defines their field. Have a good weekend! Z-Bo On Fri, Jul 9, 2010 at 7:24 PM, Alan Kay alan.n...@yahoo.com wrote: The metaphor happened to me in grad school in the 60s when I finally took the trouble to trace McCarthy's Lisp in itself and realized just how powerful and comprehensive he had made it in such a compact way. It was not so much the Turing aspect but the slope of the power from nothing. I said to myself this is the Maxwell's Equations of computing. I think I recounted this in the Early History of Smalltalk. And as a science and math major as an undergraduate, I knew the story that David told about how Heaviside had collapsed the difficult to understand partial differential equations form into the vectorized-operatorized t-shirt size we know. As a post-doc I had some fun working in McCarthy's lab at Stanford and a hobby was finding much more compact ways to do Lisp (it can really be shrunk down from John's version) and amounts really to being able to say what it means to send a message from one context to another Cheers, Alan -- *From:* John Zabroski johnzabro...@gmail.com *To:* Fundamentals of New Computing fonc@vpri.org *Sent:* Fri, July 9, 2010 2:48:27 PM *Subject:* Re: [fonc] goals Just wondering... when did that metaphor get started at VPRI? The first time I had heart you reference the t-shirt metaphor was October 2009 [1]. I remember joking about it on Lambda the Ultimate in April of 2009 [2], and my joke was actually based on a presentation given by the head operations physicist of the Relativistic Heavy Ion Collider project at BNL, Todd Satogata [3]. He gave a talk about how you can buy a t-shirt with Maxwell's Equations on it and it pretty much describes the whole universe. But he said his goal was to unify the strong force and weak force and come up with a new t-shirt, and make millions of dollars and become famous. When I heard that you were interested in Maxwell's Equations for Computer Science, I immediately made the connection to Todd Satogata's BNL speech (I've heard him give roughly the same pitch in other speeches many times), so that is why I made the joke about printing Maxwell's Equations for Computer Science on a t-shirt. [1] http://media.cs.uiuc.edu/seminars/StateFarm-Kay-2009-10-22a.asx [2] http://lambda-the-ultimate.org/node/3265#comment-48129 [3] http://toddsatogata.net/ On Fri, Jul 9, 2010 at 1:44 PM, Alan Kay alan.n...@yahoo.com wrote: One of my all time favorite metaphors and examples for part of what we are trying to do in this T-shirt programming project. Cheers, Alan -- *From:* David Leibs david.le...@oracle.com *To:* Fundamentals of New Computing fonc@vpri.org *Sent:* Fri, July 9, 2010 10:33:04 AM *Subject:* Re: [fonc] goals for example, is a lot of this added code because: the programmer has little idea what he was doing, and so just wildly copy-pasted everywhere and made a big mess?... has lots of code which is actually beneficial, such as doing error checking and building abstractions. similarly, is a piece of code smaller because: the programmer is good at getting work done in less code? or because the code is essentially a tangled mess of hacks? It isn't that the programmer has little idea of what he is doing. Things just take time to be transformed into an optimal form. There is a good example from the history from math, and physics that illustrates the point. Maxwells equations originally applied to a set of eight equations published by Maxwell in 1865. After that the number of equations escalated to twenty equations in twenty unknowns as people struggled with the implications. Maxwell wrestled with recasting the equations in quaternion form. Time passed. It was all very ugly. Finally In 1884 Oliver Heaviside recast Maxwell's math from the then cumbersome form to its modern v http://en.wikipedia.org/wiki/Vector_%28geometric%29ector calculus notation, thereby reducing the twenty equations in twenty unknowns down to the four differential equations in two unknowns that we all love and call Maxwells equations. Heaviside invented the modern notation giving us the tools to make sense of something very profound and useful. Good work on hard things takes time
Re: [fonc] goals
Max, You mention software engineering management which reminds me of Tom Gilb's book Principles of Software Engineering Management which is still a favorite of mine despite that he replaced it with his more recent Competitive Engineering. He begins any management exercise by defining six to ten measurable goals, and specifying how the numbers shall be calculated. These are usually quality goals with specific numbers attached. If easily learned is a chosen goal, it is accompanied by selected training and testing procedures to find the numbers which measure progress toward that goal. Inventing ways to meet multiple goals is what he means by the term engineering. Lines of code is a number all right, but it's not often a useful number for the stakeholders paying for the effort. Minutes to complete a specified task after a day of training and practice might more likely be a useful target. Perhaps you'd like to have a few of those quality goals. It often seems that the only real goal for software projects is delivery date since the others all give way in the effort to meet that one. I hate it when that happens. No time to do it well, but always time to do it over is a frequent complaint. Richard On Fri, Jul 9, 2010 at 11:47 AM, Max OrHai max.or...@gmail.com wrote: Just to clarify, I'm a bit uncomfortable with productivity talk here because it seems too narrow and ill-defined. Productivity of what exactly? By whom? For whom? To what end? To a specific manager of a specific project in a specific development phase, these questions may have specific, meaningful answers. When it comes to fundamentally rethinking basic tools and practices, I'm not so sure. Of course, core values must be somewhat vague, to allow them to mesh with constantly changing circumstances. Personally, I'd rather strive for quality than productivity. I'm generally suspicious of premature quantification: just because you can measure something doesn't make it meaningful! It seems to me that, as crufty, haphazard, hidebound, etc. as software engineering is today, software engineering management (with its productivity metrics such as source lines of code per programmer per day) are even worse. We all know code quality varies wildly between programmers using the exact same sets of tools. Talent and training contribute enormously. However, I imagine that everyone on this list can agree that the tools themselves matter too, even if it's difficult to quantify that difference precisely. Keep it simple is a widely applicable and successful heuristic. I see this project as (largely) an experiment in applying that heuristic to the fairly well-defined category of creating the personal computing experience, with a depth and breadth impossible in the productivity/profit-bound world of commercial software, and a consistency and quality level impossible in the the traditional open-source project. It's just an experiment, though. It's *research* (or, if you prefer, intellectual masturbation). If we already knew the outcome, it wouldn't be research, would it? -- Max On Fri, Jul 9, 2010 at 10:33 AM, David Leibs david.le...@oracle.comwrote: for example, is a lot of this added code because: the programmer has little idea what he was doing, and so just wildly copy-pasted everywhere and made a big mess?... has lots of code which is actually beneficial, such as doing error checking and building abstractions. similarly, is a piece of code smaller because: the programmer is good at getting work done in less code? or because the code is essentially a tangled mess of hacks? It isn't that the programmer has little idea of what he is doing. Things just take time to be transformed into an optimal form. There is a good example from the history from math, and physics that illustrates the point. Maxwells equations originally applied to a set of eight equations published by Maxwell in 1865. After that the number of equations escalated to twenty equations in twenty unknowns as people struggled with the implications. Maxwell wrestled with recasting the equations in quaternion form. Time passed. It was all very ugly. Finally In 1884 Oliver Heaviside recast Maxwell's math from the then cumbersome form to its modern v http://en.wikipedia.org/wiki/Vector_(geometric)ector calculus notation, thereby reducing the twenty equations in twenty unknowns down to the four differential equations in two unknowns that we all love and call Maxwells equations. Heaviside invented the modern notation giving us the tools to make sense of something very profound and useful. Good work on hard things takes time plus a lot of good people that care. cheers, -David Leibs ___ 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] goals
(pardon the top-post) granted, I probably don't speak for others here, who may have differing opinions, I just speak for myself... I am not formally involved with the project in question here, but work on some of my own stuff in a similar domain (VM and compiler technology). well, that is the question sometimes... but, anyways, being useful is the real eventual goal in anything. otherwise, what does it amount to besides mental masturbation and people congratulating their own ego / intellect (I have seen this before, mostly in math and physics circles, like lacking any real value in what they are doing, they praise themselves over how intelligent or insightful they are vs everyone else... IMO, this is distasteful and serves no real purpose...). granted, one congratulating their own efforts isn't much better... essentially, it is like one bowing before an idol made by their own hands. (it is at least meaningful if one can do something and admit openly that it is all a big pile of crap...). now, as for useful to who?... maybe that is another part of the question. maybe if my stuff is at least useful to myself, that is a starting point, but even this is a difficult matter sometimes. if something can be useful to others, this is better, or generally improving matters as a whole, that is better still. personally though, I see little need to reinvent the world, more just a matter of fixing all these little problems that keep popping up, and maybe adding a few more tools to the toolbox. it is notable how much even seemingly trivial matters, like having a tool to automatically write ones' C C++ headers for them, ... can make to the overall programming experience. like, before, there is this seemingly endless annoyance of having to add prototypes for any new functions into their headers, and a simple tool (of maybe 500 loc), can cause this matter to almost entirely disappear. some big elaborate solution may really do little against these problems, as what we have is not so much monumental problems, so much as they are monuments of pebbles. some grand scheme will not necessarily move such a mountain, but something as simple as a shovel might just do the job. and with some amount of shoveling, one may just end up moving a mountain... much like the annoyance of how people say things are impossible, when really, they are far from being impossible, but maybe they are a little bit of effort. it is like, doing dynamic compilation (like, eval and similar) in C, or adding many reflection type features. there is no magic algorithm to make this work, but an ugly mess of code pulls it all off fairly well. likewise goes for more established technologies, like GC, dynamic types, and lexical closures. as can be said, just do it or, at least, this is just my opinion on the matter... others may feel free to disagree or offer alternate opinions... - Original Message - From: Steve Dekorte st...@dekorte.com To: Fundamentals of New Computing fonc@vpri.org Sent: Thursday, July 08, 2010 1:34 AM Subject: [fonc] goals What do the folks here see as the goals of new computing? Is it to find ways to use technology to help people be more productive? Is it more about education? Is it about maximizing MIPS/Watt? Something else entirely? My impression (which may be wrong) is that most of we think of in retrospect as the really great stuff (PARC, Sutherland and Doug Engelbart's group) was born from environments with goals of increasing productivity of real labor. ___ 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] goals
I would imagine that the goals align with the task of augmenting human intellect, to borrow Engelbart's phrase. The STEPS project, in particular, seems concerned with compact representations that approach the entropies of the systems being simulated. Computing, to me, anyway, is very closely linked to simulation. A compact representation is (hopefully) easier understand, thus making it suitable for educational purposes. However, it should also be more computationally efficient, as well as enabling greater productivity. I think it's also about regaining control of our technology. A modern computer system is composed of layer upon layer of ad hoc mechanics, short on architecture and long on details. There are few people who have a truly good understanding of the complete system from firmware to UI, including all the details in between, and it's not because the details are fundamentally complex - they simply involve huge amounts of rote learning. Something like Linux has grown somewhat organically, without any of the robustness that organic growth might imply. Given concerns about security and privacy - not to mention demonstrable correctness of operation - an easily decomposable, understandable system is hugely desirable. There should be bonus side effects, such as running well on lightweight mobile devices. I hope to see computing systems becoming vehicles for training intelligent agents that assist human endeavours - by automating menial tasks, freeing humans to concentrate on more interesting problems, while also leveraging the abilities that are trivial for computers, but hard for humans (large scale data processing, correlation and statistical analysis, particle simulation, etc.). I also hope to see more of the abilities that have traditionally been described as A.I. entering mainstream computation (goal-seeking behaviour, probabilistic reasoning). Disclaimer: http://www.peralex.com/disclaimer.html ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goals
I personally do not believe technology actually improves lives. Usually, it is the opposite. Technology creates instant gratification and addiction to it thereof, and the primary reason we are so addicted to technology is because we have become so empty inside. For me, new computing is about putting yourself directly in the pathway of the consequences of your actions. Do not invent technology if you are unwilling to do this. Otherwise, you will ultimately influence, but never produce, anything worth getting truly excited about. You'll just end up making society more empty than it already is. Cheers, Z-Bo ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goals
Thoreau said We become the tools of our tools; McLuhan: We become what we behold. Both are scary, but the latter one has some hope in it, if we could make something that by beholding it we would become better. And technology literally means anything that humans make so ideas count here also as part of the double edged sword collection. The tradeoffs are both exquisite and excruciating with regard to the invention and playing of musical instruments . Cheers, Alan From: John Zabroski johnzabro...@gmail.com To: Fundamentals of New Computing fonc@vpri.org Sent: Thu, July 8, 2010 8:44:05 AM Subject: Re: [fonc] goals I personally do not believe technology actually improves lives. Usually, it is the opposite. Technology creates instant gratification and addiction to it thereof, and the primary reason we are so addicted to technology is because we have become so empty inside. For me, new computing is about putting yourself directly in the pathway of the consequences of your actions. Do not invent technology if you are unwilling to do this. Otherwise, you will ultimately influence, but never produce, anything worth getting truly excited about. You'll just end up making society more empty than it already is. Cheers, Z-Bo ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goals
I think Ryan has best articulated what it's all about for me anyway: regaining control of our technology. Simplicity and clarity are, to some extent, their own imperative. That's nothing new: Occam's Razor has long been the dominant aesthetic in mathematics and the natural sciences at least. In a world such as ours where all human endeavors are increasingly influenced (often unintentionally) by technological concerns, I feel it as a moral imperative as well. A computer is a necessary tool for engaging with the modern world of human knowledge and culture. A truly personal computer should be fully understandable and extensible, inside and out, by its individual users, without the users having to devote a disproportionate amount of effort to this understanding. If these users thereby become more productive, that's great too, but I don't think that's the major goal. -- Max On Thu, Jul 8, 2010 at 3:35 AM, Ryan Mitchley r...@peralex.com wrote: I would imagine that the goals align with the task of augmenting human intellect, to borrow Engelbart's phrase. The STEPS project, in particular, seems concerned with compact representations that approach the entropies of the systems being simulated. Computing, to me, anyway, is very closely linked to simulation. A compact representation is (hopefully) easier understand, thus making it suitable for educational purposes. However, it should also be more computationally efficient, as well as enabling greater productivity. I think it's also about regaining control of our technology. A modern computer system is composed of layer upon layer of ad hoc mechanics, short on architecture and long on details. There are few people who have a truly good understanding of the complete system from firmware to UI, including all the details in between, and it's not because the details are fundamentally complex - they simply involve huge amounts of rote learning. Something like Linux has grown somewhat organically, without any of the robustness that organic growth might imply. Given concerns about security and privacy - not to mention demonstrable correctness of operation - an easily decomposable, understandable system is hugely desirable. There should be bonus side effects, such as running well on lightweight mobile devices. I hope to see computing systems becoming vehicles for training intelligent agents that assist human endeavours - by automating menial tasks, freeing humans to concentrate on more interesting problems, while also leveraging the abilities that are trivial for computers, but hard for humans (large scale data processing, correlation and statistical analysis, particle simulation, etc.). I also hope to see more of the abilities that have traditionally been described as A.I. entering mainstream computation (goal-seeking behaviour, probabilistic reasoning). Disclaimer: http://www.peralex.com/disclaimer.html ___ 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] goals
Alan Kay wrote: McLuhan: We become what we behold. We don't see things as they are, we see things as we are. - Anais Nin (just to add some recursive futility to the mix) Disclaimer: http://www.peralex.com/disclaimer.html ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goals
- Original Message - From: John Zabroski To: Fundamentals of New Computing Sent: Thursday, July 08, 2010 8:44 AM Subject: Re: [fonc] goals I personally do not believe technology actually improves lives. Usually, it is the opposite. Technology creates instant gratification and addiction to it thereof, and the primary reason we are so addicted to technology is because we have become so empty inside. For me, new computing is about putting yourself directly in the pathway of the consequences of your actions. Do not invent technology if you are unwilling to do this. Otherwise, you will ultimately influence, but never produce, anything worth getting truly excited about. You'll just end up making society more empty than it already is. hmm, I would have thought technology would have been more about things like productivity, ... rather than the emotional status of its users. it is like, one can measure productivity in various ways: getting products to market; speed at which tasks can be performed; the net profits of a company; ... subjective concerns are much more difficult to measure, and typically much more fluid in nature, and so would likely normally be assumed not to exist (well, unless you are in marketting or similar, at which point it is about giving society the emotion you want them to have: the desire to buy this new and shiny product...). really, in some sense, emotions are not too much different than the products being sold, like sell the product, and sell these feelings associated with the product. then make more and sell them later, and the consumers remain happy (and probably the corporate higher-ups as well, assuming profits remain good, ...). although one can just ignore the matter of whether or not feelings actually exist, and what (if anything) they are, and for the most part one is not really any worse off. like, if the world was without feeling, but in nearly all other ways the same (assume no dystopic goverments or other such changes), what would be the likely effect? maybe no one would notice or care, business as usual, although it might impact interpersonal interactions/... I don't really know though. in terms of measures of productivity, technology has likely notably improved society vs in the past. this can be inferred partly from the fact that technology actually rose to dominance, whereas if it were not useful in this regard, likely it would not have done so. similarly the lifespan and quality of living tends to be higher in 1st-world nations than in 3rd-world nations, ... however, morals, ... would seem to be degraded in industrialized nations (note the widespread prevelance of promiscuity, gays, gangs and violence, ...), so this may be a cost associated with industrialization (although there is not any obvious reason why one would lead to the other). this may also be a cost of urbanization though, I don't know. or such... ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goals
Not to put down Anais Nin, but this saying is written in the Talmud and attributed to Buddha (great minds) Kim On Jul 8, 2010, at 9:40 AM, Ryan Mitchley wrote: Alan Kay wrote: McLuhan: We become what we behold. We don't see things as they are, we see things as we are. - Anais Nin (just to add some recursive futility to the mix) Disclaimer: http://www.peralex.com/disclaimer.html ___ 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] goals
On Thu, 8 Jul 2010 09:10:12 -0700 Max OrHai max.or...@gmail.com wrote: A computer is a necessary tool for engaging with the modern world of human knowledge and culture. A truly personal computer should be fully understandable and extensible, inside and out, by its individual users, without the users having to devote a disproportionate amount of effort to this understanding. If these users thereby become more productive, that's great too, but I don't think that's the major goal. (devil's advocate) That's precisely why I wash my clothes by hand. (my competence in mechanics, electrotechnics thermodynamics is far too limited to fully master a washing machine -- not to speak of embedded digital control systems) Denis vit esse estrany ☣ spir.wikidot.com ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goals
On 08 Jul 2010, at 10:34 , Steve Dekorte wrote: What do the folks here see as the goals of new computing? Is it to find ways to use technology to help people be more productive? Is it more about education? Is it about maximizing MIPS/Watt? Something else entirely? My impression (which may be wrong) is that most of we think of in retrospect as the really great stuff (PARC, Sutherland and Doug Engelbart's group) was born from environments with goals of increasing productivity of real labor. From what I have read Doug Engelbart was interested more in using computers to enable folk to think smarter than any increase in labor productivity :) I like how it is phrased on the Doug Engelbart Institute website: As he saw it, both the rate and the scale of change are increasing very rapidly worldwide, and we as a people must get that much faster and smarter at anticipating, assessing, and responding to important challenges collectively if we are to stay ahead of the curve, and thrive as a planet. In other words, we must get faster and smarter at boosting our Collective IQ. -- http://dougengelbart.org/ - antoine ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goals
Actually, Nin got her quote from the Talmud From: Ryan Mitchley r...@peralex.com To: Fundamentals of New Computing fonc@vpri.org Sent: Thu, July 8, 2010 9:40:45 AM Subject: Re: [fonc] goals Alan Kay wrote: McLuhan: We become what we behold. We don't see things as they are, we see things as we are. - Anais Nin (just to add some recursive futility to the mix) Disclaimer: http://www.peralex.com/disclaimer.html ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goals
- Original Message - From: Julian Leviston jul...@leviston.net To: Fundamentals of New Computing fonc@vpri.org Sent: Thursday, July 08, 2010 9:11 AM Subject: Re: [fonc] goals On 09/07/2010, at 1:44 AM, John Zabroski wrote: I personally do not believe technology actually improves lives. Usually, it is the opposite. Technology creates instant gratification and addiction to it thereof, and the primary reason we are so addicted to technology is because we have become so empty inside. For me, new computing is about putting yourself directly in the pathway of the consequences of your actions. Do not invent technology if you are unwilling to do this. Otherwise, you will ultimately influence, but never produce, anything worth getting truly excited about. You'll just end up making society more empty than it already is. Cheers, Z-Bo -- One of the primarily useful things that technology does for me is the dissemination of knowledge. Without this dissemination, I'd find it very hard to get the information I enjoy using and consuming regularly. snip, cooking So I put it to you that knowledge and information dissemination through technology is an incredibly powerful and useful thing. I'd dare to say it improves lives. It has improved my life immeasurably. -- agreed. something as trivial as being able to look stuff up on Wikipedia, or do Web searches via Google, does make things a lot easier. computers also make it a lot easier to externalize a lot of ones' memory, so one need not remember everything, but can instead re-fetch information as it is needed, and then know things, or at least until they forget them again. granted though, maybe there is a cost here, like there is reason one should go and memorize lots of stuff, but it is easier to leave them in an external form, and usually one is not adversely effected. -- However... (and this is a big however) your post made me quite agitated for a few minutes, andI think that this was mostly because people do not take the time to learn (at least) one skill very very well and this is a point I think you're trying to make here... the addiction to information technology can happen at a young age. I was only allowed two or three hours of computer usage per week until I was 14 years old. This meant that I maximised my computing use in the time I had to use. I'm incredibly proficient at using computers, but I do so from a wealth of knowledge of being. I don't get lost in computers. I rather use them to focus and propel my efforts. I do tend to think that perhaps this part of my story isn't all that common these days, irrespective of whether we're talking about computers or not. -- agreed... I went into a slight bit of a rant on this one. but, yeah, I have been using computers fairly intensively since I was fairly young (10 or so...). if I were not so much into computers, who would I have ended up being?... maybe I would have been someone other than some computer nerd who never really gets anything useful done (like learning how to drive or operate independently, or getting a job, ...), or would maybe find a girlfriend or similar (yep, no dating in around 8 years now...). but, alas, I don't know... maybe all would have been the same, and I would have just pursued some of my other past interests (like math or science or similar), but then again, I have seen the egotism and pretension of many of these people, so maybe it is a good thing that I am a programmer. then again, I have also noted how terribly poor my math skills are (if around people who are actually skilled at math), so maybe in such a world I would have been like oh well, whatever and gone and just done something else. -- But I also think that technology is inescapably important in terms of the improvements to accelerating quantities and improving efficiencies that are possible when it comes to learning things; especially when it comes to minimising frustration. I know that frustration is a useful quality every now and then especially when it comes to growing in some skill, but I don't see why we need hamper ourselves from achieving whatever it is we'd like to achieve. -- agreed... -- For example, I'd really like to learn to speak and understand at least twenty human languages. My plan is to build systems that allow the accelerated learning of these languages. Perhaps I'm insane. I hope not. I know what I want to achieve is difficult, but I also can see a path towards it, so hopefully it's achievable. In the process, I also hope to build a system which allows its own transcendence in terms of facilitating all kinds of learning, because I really hope that our current methods of learning things aren't all we have... they totally suck. -- dunno. never really been much into languages personally. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goals
I agree with the whole mental masturbation thing. Unless something is produced and actually increases productivity then it's been a waste of time. Frankly, I don't see anything substantial every coming out of this project. It's just an academic exercise. Sorry for the harshness. On Thu, Jul 8, 2010 at 4:52 AM, BGB cr88...@hotmail.com wrote: (pardon the top-post) granted, I probably don't speak for others here, who may have differing opinions, I just speak for myself... I am not formally involved with the project in question here, but work on some of my own stuff in a similar domain (VM and compiler technology). well, that is the question sometimes... but, anyways, being useful is the real eventual goal in anything. otherwise, what does it amount to besides mental masturbation and people congratulating their own ego / intellect (I have seen this before, mostly in math and physics circles, like lacking any real value in what they are doing, they praise themselves over how intelligent or insightful they are vs everyone else... IMO, this is distasteful and serves no real purpose...). granted, one congratulating their own efforts isn't much better... essentially, it is like one bowing before an idol made by their own hands. (it is at least meaningful if one can do something and admit openly that it is all a big pile of crap...). now, as for useful to who?... maybe that is another part of the question. maybe if my stuff is at least useful to myself, that is a starting point, but even this is a difficult matter sometimes. if something can be useful to others, this is better, or generally improving matters as a whole, that is better still. personally though, I see little need to reinvent the world, more just a matter of fixing all these little problems that keep popping up, and maybe adding a few more tools to the toolbox. it is notable how much even seemingly trivial matters, like having a tool to automatically write ones' C C++ headers for them, ... can make to the overall programming experience. like, before, there is this seemingly endless annoyance of having to add prototypes for any new functions into their headers, and a simple tool (of maybe 500 loc), can cause this matter to almost entirely disappear. some big elaborate solution may really do little against these problems, as what we have is not so much monumental problems, so much as they are monuments of pebbles. some grand scheme will not necessarily move such a mountain, but something as simple as a shovel might just do the job. and with some amount of shoveling, one may just end up moving a mountain... much like the annoyance of how people say things are impossible, when really, they are far from being impossible, but maybe they are a little bit of effort. it is like, doing dynamic compilation (like, eval and similar) in C, or adding many reflection type features. there is no magic algorithm to make this work, but an ugly mess of code pulls it all off fairly well. likewise goes for more established technologies, like GC, dynamic types, and lexical closures. as can be said, just do it or, at least, this is just my opinion on the matter... others may feel free to disagree or offer alternate opinions... - Original Message - From: Steve Dekorte st...@dekorte.com To: Fundamentals of New Computing fonc@vpri.org Sent: Thursday, July 08, 2010 1:34 AM Subject: [fonc] goals What do the folks here see as the goals of new computing? Is it to find ways to use technology to help people be more productive? Is it more about education? Is it about maximizing MIPS/Watt? Something else entirely? My impression (which may be wrong) is that most of we think of in retrospect as the really great stuff (PARC, Sutherland and Doug Engelbart's group) was born from environments with goals of increasing productivity of real labor. ___ 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
Re: [fonc] goals
On 8 July 2010 17:40, BGB cr88...@hotmail.com wrote: however, morals, ... would seem to be degraded in industrialized nations (note the widespread prevelance of promiscuity, gays, gangs and violence, ...), so this may be a cost associated with industrialization (although there is not any obvious reason why one would lead to the other). this may also be a cost of urbanization though, I don't know. Whoa there, going off topic a bit I know, but I take offence to the suggestion that homosexuality is evidence of moral degradation. Indeed as an unashamed european lefty I would argue that discrimination against gays, minorities, etc is actually greater evidence of moral degradation and this is thankfully becoming less common in the industrialised world. And I would suggest you have a word with a Rwandan, Zimbabwean or Afghan (to name but a few) about whether gangs and violence are worst in the industrialised nations or non-industrialised. Or if you wish to argue against urbanisation I am pretty sure that my own country (england) had some pretty nasty violence before large scale urbanisation - civil wars, violence of landowners against those living on their land, persecution of catholics/protestants (depending on whether catholics or protestants were in charge at the time), burning folks at the stake for unsubstantiated accusations of witch craft, etc. A change in the prevailing moral code does not imply a degradation. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goals
People, I really think this isn't the right mailing list for this kind of discussion. On Thu, Jul 8, 2010 at 3:11 PM, chris mills chrmi...@gmail.com wrote: On 8 July 2010 17:40, BGB cr88...@hotmail.com wrote: however, morals, ... would seem to be degraded in industrialized nations (note the widespread prevelance of promiscuity, gays, gangs and violence, ...), so this may be a cost associated with industrialization (although there is not any obvious reason why one would lead to the other). this may also be a cost of urbanization though, I don't know. Whoa there, going off topic a bit I know, but I take offence to the suggestion that homosexuality is evidence of moral degradation. Indeed as an unashamed european lefty I would argue that discrimination against gays, minorities, etc is actually greater evidence of moral degradation and this is thankfully becoming less common in the industrialised world. And I would suggest you have a word with a Rwandan, Zimbabwean or Afghan (to name but a few) about whether gangs and violence are worst in the industrialised nations or non-industrialised. Or if you wish to argue against urbanisation I am pretty sure that my own country (england) had some pretty nasty violence before large scale urbanisation - civil wars, violence of landowners against those living on their land, persecution of catholics/protestants (depending on whether catholics or protestants were in charge at the time), burning folks at the stake for unsubstantiated accusations of witch craft, etc. A change in the prevailing moral code does not imply a degradation. ___ 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] goals
Agreed. Apologies folks, it was a knee jerk reaction to a statement I found offensive. ChrisM On 8 July 2010 19:17, Alex Abate Biral abatebi...@gmail.com wrote: People, I really think this isn't the right mailing list for this kind of discussion. On Thu, Jul 8, 2010 at 3:11 PM, chris mills chrmi...@gmail.com wrote: On 8 July 2010 17:40, BGB cr88...@hotmail.com wrote: however, morals, ... would seem to be degraded in industrialized nations (note the widespread prevelance of promiscuity, gays, gangs and violence, ...), so this may be a cost associated with industrialization (although there is not any obvious reason why one would lead to the other). this may also be a cost of urbanization though, I don't know. Whoa there, going off topic a bit I know, but I take offence to the suggestion that homosexuality is evidence of moral degradation. Indeed as an unashamed european lefty I would argue that discrimination against gays, minorities, etc is actually greater evidence of moral degradation and this is thankfully becoming less common in the industrialised world. And I would suggest you have a word with a Rwandan, Zimbabwean or Afghan (to name but a few) about whether gangs and violence are worst in the industrialised nations or non-industrialised. Or if you wish to argue against urbanisation I am pretty sure that my own country (england) had some pretty nasty violence before large scale urbanisation - civil wars, violence of landowners against those living on their land, persecution of catholics/protestants (depending on whether catholics or protestants were in charge at the time), burning folks at the stake for unsubstantiated accusations of witch craft, etc. A change in the prevailing moral code does not imply a degradation. ___ 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
Re: [fonc] goals
I understand (and I hope the other people in this list do so too), but I really think that there should be a separate list for arguing about the project's philosophy (which is as important, if not more, as this list). On Thu, Jul 8, 2010 at 3:20 PM, chris mills chrmi...@gmail.com wrote: Agreed. Apologies folks, it was a knee jerk reaction to a statement I found offensive. ChrisM On 8 July 2010 19:17, Alex Abate Biral abatebi...@gmail.com wrote: People, I really think this isn't the right mailing list for this kind of discussion. On Thu, Jul 8, 2010 at 3:11 PM, chris mills chrmi...@gmail.com wrote: On 8 July 2010 17:40, BGB cr88...@hotmail.com wrote: however, morals, ... would seem to be degraded in industrialized nations (note the widespread prevelance of promiscuity, gays, gangs and violence, ...), so this may be a cost associated with industrialization (although there is not any obvious reason why one would lead to the other). this may also be a cost of urbanization though, I don't know. Whoa there, going off topic a bit I know, but I take offence to the suggestion that homosexuality is evidence of moral degradation. Indeed as an unashamed european lefty I would argue that discrimination against gays, minorities, etc is actually greater evidence of moral degradation and this is thankfully becoming less common in the industrialised world. And I would suggest you have a word with a Rwandan, Zimbabwean or Afghan (to name but a few) about whether gangs and violence are worst in the industrialised nations or non-industrialised. Or if you wish to argue against urbanisation I am pretty sure that my own country (england) had some pretty nasty violence before large scale urbanisation - civil wars, violence of landowners against those living on their land, persecution of catholics/protestants (depending on whether catholics or protestants were in charge at the time), burning folks at the stake for unsubstantiated accusations of witch craft, etc. A change in the prevailing moral code does not imply a degradation. ___ 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 ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goals
(pardon this thread's continued existence...). well, each generation has to have come from somewhere... but, yeah (prior to the big ethics issue), the general point I tried to make is that it is generally much more a matter of pragmatics (what people can get from technology or use it to accomplish), rather than peoples' feelings about technology per-se. in general, I think I was being positive, since in all we see a lot more benefit than harm in this world, and probably, as a whole, the world is better now than it once was. now, whether a person wants to view things like posessions as a form of transferrable happiness, or conclude that maybe, happiness doesn't actually exist in the first place (and is thus likely an irrelevant consideration in matters of technology), this is up to them... like, maybe, it really doesn't matter if a person is happy or not?... either way, they still have their job and any life stuff that needs to be done. technology can at least help a person get done those things they want or need to get done, regardless of whether or not the object has any real beneficial effect on their mood. hell, maybe even the net emotional effect is good, as people who otherwise might be sitting off in the corner somewhere in isolation, being all depressed and similar due to their lack of friends (and awaiting the day when their life will end, maybe wondering if life even really exists in the first place, or if it is merely some pattern of emergence due to so many particle interations simply masquerading as some greater order, ...), can now find some semblance of a social life posting about how depressed they are and how dismal and hopeless life is and whatever onto online forums, and then go and distract themselves by racking up kills in online games (like Counter Strike or Unreal Tournament or similar...). so, in this sense, happiness flows over wires and is emitted from computer and TV screens... or such... - Original Message - From: Steve Dekorte st...@dekorte.com To: Fundamentals of New Computing fonc@vpri.org Sent: Thursday, July 08, 2010 3:46 PM Subject: Re: [fonc] goals It's been said that each generation thinks that it invented sex. Could the same be said of depression? On 2010-07-08, at 08:44 AM, John Zabroski wrote: I personally do not believe technology actually improves lives. Usually, it is the opposite. Technology creates instant gratification and addiction to it thereof, and the primary reason we are so addicted to technology is because we have become so empty inside. ___ 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] goals
Once a project gets going it usually winds up with a few more goals than those that got it started -- partly because the individual researchers bring their own perspectives to the mix. But the original goals of STEPS were pretty simple and longstanding. They came from thinking that the size of many large systems in terms of amount of code written seemed very far out of balance -- by many orders of magnitude -- with intuitions about their actual mathematical content. This led to a science of the artificial approach of taking the phenomena of already produced artifacts in the general area of personal computing, and seeing if very compact runable maths could be invented and built to model very similar behaviors. If this could be done, then some of the approaches in the new models would represent better ways to design and program to complex behaviors -- which could be very illuminating about systems designs and representations -- and some of these would likely be advances in programming in general. I think of this as scientific exploration via coevolving mathematics and engineering. Cheers, Alan ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goals
much agreed. pardon my likely inelegant extension: seemingly, nearly any problem can be abstracted, and a set of more elegant solutions can be devised to long-standing problems. for example, to abstract over the HW, there was the CPU instruction set; to abstract over the instruction set, there was the assembler; to abstract over assembler, there are compilers (in this context, I will define low-level languages and many earlier HLL's); to abstract further, there are modern HLL's and OOP; to abstract over HLL's, there may be DSL's and specialized code-generating tools; ... AFAICT, most modern compilers involve at least 2 major translation stages getting from the HLL to the level of ASM: the input HLL is processed, usually to some compiler specific IL or IR; this IL or IR is further processed, and the target ASM code is emitted (sometimes an ASM post-optimizer is used as well); ... in terms of using these systems, each level is (usually) a little nicer and a little cleaner than the ones' which follow after it. granted, there is a cost: usually the total cost (in terms of system complexity) is larger with these facilities available (for example, an apps ASM + app ASM code is larger than a binary-coded app by itself, and a compiler is often far from being a small or simple piece of code). but, in the larger sense, it is a good tradeoff, since a small amount of HLL code is a much smaller price to pay than a mountain of ASM. but, one need also not forget that a lot of work has gone into all these little things which can be almost trivially overlooked: the many man-years which have gone into these operating systems and compiler technologies which one can easily take for granted. it is an interesting idea though, namely what could be the most minimally redundant yet maximally capable system? like if one can increase the overall abstraction of a system while at the same time reducing its overall complexity (vs what it would have been otherwise), although I have my doubts that this could be done in the general case. making an observation from data compression: usually there is a fixed factor between compressed and uncompressed data entropy, and going beyond this factor results in rapidly increasing costs for rapidly diminishing returns, and ultimately hitting a fixed limit (the Shannon Limit). a similar notion could apply to systems complexity: the minimally redundant system being only some margain smaller than typical system, and given programmers tend to be relatively self-compressing, it is possible this margain is fairly small (meaning that, very possibly, the more abstracted system will always be more internally complex than the lower-level system). like, one will always need more logic gates to have a full CPU than to drive an ALU directly via switches and lights. note: none of this is meant to degrade tools research, as there is still plenty of room for reasearch, and for seeing what works and what doesn't. like, I believe in utility, but utility is the goal, not the imperative... often, the thing which seems useless out the outset may turn out to be valuable, and ones' innovative idea may turn out to be useless, so an open mind is needed I think. often, the best strategy may be to try and see, and if it works, it works, and if it doesn't, it doesn't. and, yes, in my case I am well experienced with people casting the opinion that all of what I am doing is useless, and hell, maybe they are right, but at the moment, it isn't too much of a loss. side note: on this front, recently I was beating together an idea-spec for an unusual bytecode design (basically, the idea is that opcode-binding is symbolic, rather than using fixed pre-assigned opcode numbers, and having tables define their own structure), ... if anyone cares I could make it available (like putting it online and posting a link or whatever). (note: the overall structure was largely inspired by IFF, WAD, and MSIL, largely the structure follows fairly straightforwardly from these). granted, as I haven't tried implementing or using the thing yet, I don't really know if the design works (really, it could just be destined for the dustbin of pointless ideas, FWIW...). or such... - Original Message - From: Alan Kay To: Fundamentals of New Computing Sent: Thursday, July 08, 2010 6:01 PM Subject: Re: [fonc] goals Once a project gets going it usually winds up with a few more goals than those that got it started -- partly because the individual researchers bring their own perspectives to the mix. But the original goals of STEPS were pretty simple and longstanding. They came from thinking that the size of many large systems in terms of amount of code written seemed very far out of balance -- by many orders of magnitude -- with intuitions about their actual mathematical content. This led to a science of the artificial approach of taking the phenomena of already
Re: [fonc] goals
Thanks for the response. That kind of sounds like the goal is fewer lines of code (and presumably less labor) per unit of function (increasing productivity). Is that correct? On 2010-07-08, at 06:01 PM, Alan Kay wrote: Once a project gets going it usually winds up with a few more goals than those that got it started -- partly because the individual researchers bring their own perspectives to the mix. But the original goals of STEPS were pretty simple and longstanding. They came from thinking that the size of many large systems in terms of amount of code written seemed very far out of balance -- by many orders of magnitude -- with intuitions about their actual mathematical content. This led to a science of the artificial approach of taking the phenomena of already produced artifacts in the general area of personal computing, and seeing if very compact runable maths could be invented and built to model very similar behaviors. If this could be done, then some of the approaches in the new models would represent better ways to design and program to complex behaviors -- which could be very illuminating about systems designs and representations -- and some of these would likely be advances in programming in general. I think of this as scientific exploration via coevolving mathematics and engineering. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goals
On Dec 9, 2007 4:39 AM, Damien Pollet [EMAIL PROTECTED] wrote: On 09/12/2007, Waldemar Kornewald [EMAIL PROTECTED] wrote: I fully agree and I, too, would like to rethink a few conventions (mostly the UI). I just want that this project results in a *successful* product, not a new niche. Getting out of the niche (or not getting in it in the first place) has more to do with PR than with technical merit. Else NeXT, the Canon Cat, or Smalltalk would be both alive and popular. For PR you want incremental changes and concrete applications, while for innovative stuff you want crazy ideas without bonds to the past, and time to crystallize them. I agree, but I also hope that we can make people switch to innovative stuff. As you indicated, communicating the advantages is critical, but you need to talk to your users in a way that they can easily understand and compare to their own problems/needs. A strange syntax can make this very difficult. If this project is primarily designing for and gets accepted by children (later adults) then I'd not focus so much on acceptance outside that target audience. Still, unless we're reinventing all concepts of the world there is no need to break with conventions that go far beyond programming, so I hope we can find a sensible middle-path. Bye, Waldemar Kornewald ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goals
On Dec 8, 2007 3:05 PM, Waldemar Kornewald [EMAIL PROTECTED] wrote: That's not what we were talking about. You claimed that we'd need *less* developers with a better language, but today we have more than ever. How can you explain that? We do have more then ever, but not of the same kind. Very few of today's programmers will be applicable to tomorrow's programming environment. Though we will probably have more programmers total. Just tell me, why doesn't Lisp or Smalltalk force everyone to advance? Instead, why do languages like Python and Ruby make people advance? I'd really like to know how you explain that. Here I'm not sure what you're talking about, and I'm probably not the only one. In what ways did Python and Ruby advance or make people advance? Ruby's claim to fame is basically a web framework, yet both Lisp and Smalltalk both have more advanced web frameworks. History is pretty clear if you care to look: Lisp and Smalltalk aren't less popular because of syntax, they both existing before C++ was popular or Java existed. They are less popular at the moment because of non-technical issues, like it normally is. I don't care if it has Lisp-like syntax or whatever, but many developers do care. Without them you'll have a hard time building a useful infrastructure and you'll face the same problems as the Reddit guys and anyone else who tries to run a company with an unpopular language. No companies, no developers. Anyone else like Paul Graham who got rich by doing just that? Yes it was, so please do choose your words a bit more careful in future. Are you kidding? Don't tell me how I should choose my words! I didn't tell you how to do anything, I asked you (note the word please) to choose your words a bit more careful as in, don't throw useless snipes in literally every email at things you appear to not even understand. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goals
On Dec 7, 2007 7:22 AM, Jason Johnson [EMAIL PROTECTED] wrote: On Dec 6, 2007 9:34 PM, Waldemar Kornewald [EMAIL PROTECTED] wrote: Your statement sounds like an assembler developer claiming that with C++'s productivity most programmers will become unnecessary. And most assembler programmers did, no? When an advancement comes along you adapt or move on somewhere else. That's not what we were talking about. You claimed that we'd need *less* developers with a better language, but today we have more than ever. How can you explain that? Does that language suddenly make you more creative by a factor of 10? No, probably not. Who will get great ideas for new concepts, then? I don't think a factor of 10 is so hard to hit when going from a restrictive language (e.g. Java, C++) to a flexible one. Again, you're changing topics. I was talking about creativity and ideas, not productivity. But the fact is, these (from both me and you) are simply opinions. When you say ugly and difficult to use there is an implicit for me in there. And so there is your answer, the future will be achieved by people who are capable of learning better languages then we have now. There are very few places where people incapable of advancing can stay relevant. Just tell me, why doesn't Lisp or Smalltalk force everyone to advance? Instead, why do languages like Python and Ruby make people advance? I'd really like to know how you explain that. What I care about is that a high-productivity language finally becomes popular, so we have a real infrastructure with enough developers, companies, and frameworks. I don't care if it has Lisp-like syntax or whatever, but many developers do care. Without them you'll have a hard time building a useful infrastructure and you'll face the same problems as the Reddit guys and anyone else who tries to run a company with an unpopular language. No companies, no developers. Anyway, if the language will be inspired by eToys and also (but not only? :) intended for children then I'm pretty sure its syntax will be more than acceptable, so it's pointless to start a flamewar. Yes it was, so please do choose your words a bit more careful in future. Are you kidding? Don't tell me how I should choose my words! Bye, Waldemar Kornewald ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goals
On Dec 8, 2007 5:28 PM, Jason Johnson [EMAIL PROTECTED] wrote: On Dec 8, 2007 3:05 PM, Waldemar Kornewald [EMAIL PROTECTED] wrote: That's not what we were talking about. You claimed that we'd need *less* developers with a better language, but today we have more than ever. How can you explain that? We do have more then ever, but not of the same kind. Very few of today's programmers will be applicable to tomorrow's programming environment. Though we will probably have more programmers total. So, you're claiming that today's programmers are too stupid or ignorant for developing in tomorrow's programming environments? Do you feel so much superior? How miserable is that? Just tell me, why doesn't Lisp or Smalltalk force everyone to advance? Instead, why do languages like Python and Ruby make people advance? I'd really like to know how you explain that. Here I'm not sure what you're talking about, and I'm probably not the only one. In what ways did Python and Ruby advance or make people advance? Ruby's claim to fame is basically a web framework, yet both Lisp and Smalltalk both have more advanced web frameworks. I'll ask again: why doesn't Lisp or Smalltalk force everyone to advance? Why can an (according to you) inferior web framework based on a slow language with (at that time) small popularity have a much greater impact than those more advanced frameworks and languages? Can you explain that with more than just non-technical issues? I don't care if it has Lisp-like syntax or whatever, but many developers do care. Without them you'll have a hard time building a useful infrastructure and you'll face the same problems as the Reddit guys and anyone else who tries to run a company with an unpopular language. No companies, no developers. Anyone else like Paul Graham who got rich by doing just that? I admit, anyone else is exaggerated, but if you're using a niche language you have more problems finding developers and you're more likely to run into limitations like mediocre platform support or no frameworks that fit your needs. Popular languages don't have this disadvantage and their software range steadily improves. Yes it was, so please do choose your words a bit more careful in future. Are you kidding? Don't tell me how I should choose my words! I didn't tell you how to do anything, I asked you (note the word please) to choose your words a bit more careful as in, don't throw useless snipes in literally every email at things you appear to not even understand. So you understand it all? Then enlighten us. What I understand is that artificially making a language unpopular is stupid. Bye, Waldemar Kornewald ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goals
On Dec 8, 2007 8:32 PM, Waldemar Kornewald [EMAIL PROTECTED] wrote: So, you're claiming that today's programmers are too stupid or ignorant for developing in tomorrow's programming environments? Do you feel so much superior? How miserable is that? I've already explained my position on this. I don't see a point telling you anything since you apparently don't bother to read it. If you treat documentation this way it's small wonder that Lisp and Smalltalk (!!!) were so hard for you. I'll ask again: why doesn't Lisp or Smalltalk force everyone to advance? Why can an (according to you) inferior web framework based on a slow language with (at that time) small popularity have a much greater impact than those more advanced frameworks and languages? The places I have seen Lisp and/or Smalltalk used they have had a lot of impact (e.g. Viaweb, RawDog, my own company with a Smalltalk app that the company has wanted to decom for a decade now but no other languages we use can even provide limited functionality in the time the Smalltalk team is adding new features their clients need). The reason it hasn't had *more* impact? To be frank, largely due to people like yourself. Can you explain that with more than just non-technical issues? I can't but I wont, the information is there, all over the place. And you don't seem to read what I write anyway. So you understand it all? Then enlighten us. It all? What you appear not to understand is the languages you take pot shots at in every single mail. What I understand is that artificially making a language unpopular is stupid. Much better to tie one's self down with extra complexities just so people who have been trained in awful programming languages will feel like they don't have to learn something new so we can achieve the most important goal in all of computer science: being popular. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goals
On Dec 8, 2007 9:12 PM, Jason Johnson [EMAIL PROTECTED] wrote: On Dec 8, 2007 8:32 PM, Waldemar Kornewald [EMAIL PROTECTED] wrote: So, you're claiming that today's programmers are too stupid or ignorant for developing in tomorrow's programming environments? Do you feel so much superior? How miserable is that? I've already explained my position on this. I don't see a point telling you anything since you apparently don't bother to read it. If you treat documentation this way it's small wonder that Lisp and Smalltalk (!!!) were so hard for you. You're not even willing to suggest how to improve the situation. Wonderful, then we can finally close this thread and concentrate on more constructive contributions. Bye, Waldemar Kornewald ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goals
The way I see it, this is an attempt to rethink, and certainly rebuild, (almost) everything from the ground up, because the incremental/evolutionary/not actually changing very much approach to computing just isn't doing much. Shoot for the stars and who knows what you might hit? I mean, imagine if someone today said he was going to devote a few years to writing a computer progam that typeset complicated mathematics (and text) as well or better than the best human experts? Never get funded... So, asking what FONC will find when it explores the unknown - indeed, when it's building the tools for the expedition into the unknown - is unlikely to get a clear answer. jqs ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goals
On Dec 8, 2007 9:53 PM, John Q. Splittist [EMAIL PROTECTED] wrote: The way I see it, this is an attempt to rethink, and certainly rebuild, (almost) everything from the ground up, because the incremental/evolutionary/not actually changing very much approach to computing just isn't doing much. Shoot for the stars and who knows what you might hit? I fully agree and I, too, would like to rethink a few conventions (mostly the UI). I just want that this project results in a *successful* product, not a new niche. So, asking what FONC will find when it explores the unknown - indeed, when it's building the tools for the expedition into the unknown - is unlikely to get a clear answer. I unfortunately expected that some clearer direction would already exist. I'd like to thank everyone who helped me understand the current situation. Bye, Waldemar Kornewald ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goals
Waldemar Kornewald wrote: I unfortunately expected that some clearer direction would already exist. I'd like to thank everyone who helped me understand the current situation. G'day Waldemar: This thread has prompted me to re-read Ian's 'widespread unreasonable behavior' paper. I think that it does provide a clear direction for this project, though it may not be the direction that you want to do. At least, not yet. You're concerned about syntax and programmer productivity. FONC seeks to improve programmer productivity, which may be what attracted your attention, but syntax is a secondary consideration. Once the infrastructure is is sufficiently functional, you can have any syntax you want, as long as someone is willing to write the transformations to an abstract syntax tree that can be fed to the COLA tools. Initial syntaxes look likely to C99 and Smalltalk, but Python shouldn't be difficult with the work being done on the PyPy project. Their Python in Python framework already targets C, Java, JavaScript, Lisp, and LLVM. COLA should be quite feasible, as well. Regards, Steve ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goals
On 09/12/2007, Waldemar Kornewald [EMAIL PROTECTED] wrote: I fully agree and I, too, would like to rethink a few conventions (mostly the UI). I just want that this project results in a *successful* product, not a new niche. Getting out of the niche (or not getting in it in the first place) has more to do with PR than with technical merit. Else NeXT, the Canon Cat, or Smalltalk would be both alive and popular. For PR you want incremental changes and concrete applications, while for innovative stuff you want crazy ideas without bonds to the past, and time to crystallize them. I think both aspects can be addressed at the same time, but certainly not by the same people. -- Damien Pollet type less, do more [ | ] http://typo.cdlm.fasmz.org ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goals
On Dec 7, 2007, at 14:27 , Waldemar Kornewald wrote: Hi Bert, On Dec 6, 2007 9:45 PM, Bert Freudenberg [EMAIL PROTECTED] wrote: On Dec 6, 2007, at 21:28 , Waldemar Kornewald wrote: I think my greatest misconception is about the eToys-like language. Will it be a full-fledged general-purpose language that you could use to build a serious office suite, the software of a car, or a satellite's software (without consulting a second language)? Absolutely. Are there more details about that language somewhere (like the COLA implementation paper)? What I found was pretty vague and heavily referred to the current Etoys system, but I expect them to be quite different, still. We do not know, yet. Otherwise it would not be called research, would it? - Bert - ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goals
On 06/12/2007, Waldemar Kornewald [EMAIL PROTECTED] wrote:
I don't want C. I can use that already. I want a language that is much
more productive (that 20K lines thing, please! :), but with a nice and
math-like syntax for math operations and an overall simple syntax that
doesn't add unnecessary noise and doesn't look like ^#:!$%[{ or
()()())), but is actually readable.
You could take the existing Smalltalk parser and define the syntax you
want for math expressions. If it was me I'd add some kind of new
literal where you could paste LaTeX math code and that would be
translated behind the scenes to the correct operations :)
What bothers me more is that if the lower-level language is based on
Smalltalk syntax then how are the other languages going to easily and
comfortably interface with that syntax? It'll probably have to look
like a mixture, similar to Objective C.
The function language is built exactly like that, and it only looks
like a mixture where the mixture features are actually used. More over
the [receiver message: arg] expressions are just a syntactic facility,
they could be represented as (object receiver message: arg) and it
would make no difference to the end result.
--
Damien Pollet
type less, do more [ | ] http://typo.cdlm.fasmz.org
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goals
On Dec 6, 2007 1:14 AM, Waldemar Kornewald [EMAIL PROTECTED] wrote: Why are you building two unpopular languages on top of each other? Why not just pick Lisp syntax for the foundation and then build a popular syntax on top of that? Why are you so concerned about popularity? If this concept can achieve the productivity gains we all hope then only a small percentage of todays programmers will be needed. I guess you chose eToys because it's less cryptic/problematic than Smalltalk? What does this sentence mean? In what way is Smalltalk problematic? And if you find a language that reads like English cryptic then I don't know what an ideal language would look like for you. Seriously, I can't imagine young children having fun learning the difference between: a b whileTrue: [...] Well, this one's wrong and I think will even produce an error. [a b] whileTrue: [...] Give children more credit. They often have an easier time figuring things out then educated adults. :) ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goals
On Dec 6, 2007, at 2:35 AM, Waldemar Kornewald wrote: On Dec 6, 2007 1:48 AM, Joshua Gargus [EMAIL PROTECTED] wrote: Is it correct that we'll have a Lisp-like syntax at the lowest level and a Smalltalk-like syntax above (with some syntax sugar like in eToys?)? (Leaving aside whether eToys should be considered syntactic sugar on top of Smalltalk, any more than C is syntactic sugar on assembler...) Hehe. :) Since we don't know what the eToys-inspired language will be like I expressed it that way. What purpose will the eToys-inspired language have? Will it be primarily for children or will it be more general-purpose like Smalltalk? Will most of the system be implemented in that eToys-inspired language? In which language will the whole system be implemented such that it'll only be about 20K lines? It will be implemented in a variety of domain-specific languages. For example, the code for networking, graphics, and defining new syntaxes might be written in different languages. If I want to write some fancy peer-to-peer system, Smalltalk or Python are not much better than C. What I really want is something like P2 (http://p2.berkeley.intel-research.net/ ) that reduces the amount of code to write by a factor of 100. As I understand it, one of the big goals of the project is that a Smalltalk-like object can trivially send messages to objects generated- by/coded-in JavaScript. You can use any language that you want, yet still have perfectly convenient access to libraries written in other, more popular, languages. What bothers me more is that if the lower-level language is based on Smalltalk syntax then how are the other languages going to easily and comfortably interface with that syntax? It'll probably have to look like a mixture, similar to Objective C. This statement is untrue, and reveals a misconception that explains your determination to get a solid answer about what the syntax will look like. Once you're past the misconception, you will understand that Bert was not being equivocal when he said we do not pick any particular syntax at this point in time. .NET might provide a useful analogy. You can write an application in many different languages that target the CLR (C#, Python, OCaml), and since they all use the same underlying bytecodes and object representation, you can write code in one language that will send a message to an object written in another language even though the syntax of the two languages have very little in common. Very roughly (sorry Ian), you can think of OLA as .NET without the VM. Ian's papers (particularly http://vpri.org/pdf/colas_wp_RN-2006-001-a.pdf and http://vpri.org/pdf/obj_mod_RN-2006-003-a.pdf) describe clearly how this is implemented. Josh Bye, Waldemar Kornewald ___ 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] goals
On Dec 6, 2007 6:54 PM, Joshua Gargus [EMAIL PROTECTED] wrote: In which language will the whole system be implemented such that it'll only be about 20K lines? It will be implemented in a variety of domain-specific languages. For example, the code for networking, graphics, and defining new syntaxes might be written in different languages. The way I understood it is that there will be DSLs, but they will integrate nicely without forcing you to learn a new syntax unnecessarily (e.g., Python = Lisp). For example, you'd have visual representations, so it's not really some new *syntax*, but rather a visualization concept. What bothers me more is that if the lower-level language is based on Smalltalk syntax then how are the other languages going to easily and comfortably interface with that syntax? It'll probably have to look like a mixture, similar to Objective C. This statement is untrue, and reveals a misconception that explains your determination to get a solid answer about what the syntax will look like. Once you're past the misconception, you will understand that Bert was not being equivocal when he said we do not pick any particular syntax at this point in time. You're right, I have a few misconceptions and I think after having read the website and the COLA paper, again, I understand more about COLA/Coke/Pepsi, now, but it's still not a full picture. I think my greatest misconception is about the eToys-like language. Will it be a full-fledged general-purpose language that you could use to build a serious office suite, the software of a car, or a satellite's software (without consulting a second language)? Or will it be more limited (to education) like eToys? How is it related to Pepsi's Smalltalk-like syntax (actually: its successor)? Isn't that intended to be the official language (ignoring that you can build anything yourself or adjust post-Pepsi to your needs)? Is Coke the language for developers implementing their own COLA? Then, will we have to use a certain amount of Smalltalk syntax in addition to Lisp for the implementation? The Brainfuck example had to use both, too. Bye, Waldemar Kornewald ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goals
Hi, On Nov 28, 2007 12:10 AM, Ian Piumarta [EMAIL PROTECTED] wrote: ? attract many mainstream programmers No. Conducive to creating systems/languages (standard or otherwise) that will attract the mainstream: YES! I think this is where I have the biggest problems understanding what you're trying to achieve. Is it correct that we'll have a Lisp-like syntax at the lowest level and a Smalltalk-like syntax above (with some syntax sugar like in eToys?)? Why are you building two unpopular languages on top of each other? Why not just pick Lisp syntax for the foundation and then build a popular syntax on top of that? What are children supposed to use? The Smalltalk-like unpopular one (how much Smalltalk/eToys-like will it be, anyway?) or something totally different and more attractive to the general public? Did your (VPRI) research show that Children prefer Smalltalk-like syntax over Python-like syntax? Or does the fact that the children get taught (instead of self-taught) and have no syntax choice simply minimize the syntax issue? I guess you chose eToys because it's less cryptic/problematic than Smalltalk? Seriously, I can't imagine young children having fun learning the difference between: a b whileTrue: [...] [a b] whileTrue: [...] Bye, Waldemar Kornewald ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
RE: [fonc] goals
Hi Ian, I was wondering how much your current thoughts on FONC have evolved from the original COLA paper you wrote (pre-VPRI). Could you detail what concepts are the same, and what has evolved? Has the concept of the real thing changed much from your original formulation? (e.g. is jolt just an intermediate step which will eventually be superceded?) Barry Silverman -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Piumarta Sent: Tuesday, November 27, 2007 6:11 PM To: VPRI Fonc Subject: Re: [fonc] goals On Nov 23, 2007, at 5:04 AM, Waldemar Kornewald wrote: wait for Ian to make an official statement. Can I make an officious statement instead? ;) What are the goals for the programming language you are creating? For the language: - minimum 'default' syntax[1] and semantics[1] to satisfy the following bullet points - malleable syntax, semantics and pragmatics (runtime support/ primitives) - completely self-describing (from machine insns to HLLs) and self- hosting - static and dynamic compilation and anything in between - support for static[1] and dynamic[2] typing and anything in between[3] - late-bound implementation that could replace itself completely at runtime[4] [1] minimum needed to (1) understand C header files and generate library glue and check API correctness and (2) for [3] below [2] including multiple dispatch, since the cost is more than amortised by simpler back-end and numeric code [3] e.g., static type annotations that mangle selectors to help create transparent 'dynamic cast' mechanisms between objects and primitive types [4] including function calling conventions, dynamic dispatch mechanisms, etc. For the system (as opposed to the language): As far as I understand the goals for the language are: * increased productivity (20K lines of code) * more correct code (?by using better concepts and automatic checking?) A goal is certainly to create an environment conducive to these. See my previous message about intent vs. optimisation. * ?better performance than Smalltalk? It entirely depends on what you are trying to do. If you stay entirely within the functional part of the language and avoid closures you can expect performance as good as (or even better than) C. If you spend most of your time sending messages, count on them costing 150% to 250% of a static (C-like) function call for one dynamic (single) dispatch. If you build your own inference engine and feed it prolog, your might never even terminate. ;-) What about goals that give this language an identity: ? easy to learn No. Trivial to 'mutate' into a language that is easy to learn: YES! ? minimalistic syntax Yes. ? very readable code No. Conducive to creating languages that attempt to optimise readability: YES! ? free of unnecessary complexity Yes. ? easy and natural to think in No (except for a very particular kind of brain). Conducive to creating systems that are easy and natural: YES! ? attract many mainstream programmers No. Conducive to creating systems/languages (standard or otherwise) that will attract the mainstream: YES! If you say yes to most of them could you (and the other VPRI members) please order them by priority? All of the above. The 2.5 'yes' responses should fall right out of the circular system described at the start of this message. Cheers, Ian PS: Seeing the next message in this thread, I agree with everything Yoshiki said. (He was being way too modest in the last line of his reply.) ___ 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] goals, tutorial
How about a recursive acronym: *S*HINOLA *H*eroically *I*mplements an *N*ew *O*bject *L*ambda *A*rchitecture -Mark On Nov 28, 2007 1:03 AM, Ryan Davis [EMAIL PROTECTED] wrote: On Nov 27, 2007, at 20:17 , Dan Ingalls wrote: PS: COLA, LOLA, , etc. -- these are all fine -- but before anyone gets in the habit of using *OLA, please read up on Shinola. tsk tsk dan... You HAD to go there... I was trying to come up with an acronym for CHOLERA and you brought up shinola... I present to you: Streamlined Holistically INtegrated Object Lambda Architecture Sorry... I really couldn't help it. Tho', I do wish the (all) project(s) could focus on the goals/philosophy and code side of things and not worry about names so much. ___ 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] goals, tutorial
ALSO (abstraction/lambda/silicium/objects) On 29/11/2007, Damien Pollet [EMAIL PROTECTED] wrote: what about MU ? http://en.wikipedia.org/wiki/Mu_%28negative%29 is it object or lambda ? is it a compiler or an interpret ? math or smalltalk precedence ? ;-) On 28/11/2007, Mark Friedman [EMAIL PROTECTED] wrote: How about a recursive acronym: SHINOLA Heroically Implements an New Object Lambda Architecture -Mark On Nov 28, 2007 1:03 AM, Ryan Davis [EMAIL PROTECTED] wrote: On Nov 27, 2007, at 20:17 , Dan Ingalls wrote: PS: COLA, LOLA, , etc. -- these are all fine -- but before anyone gets in the habit of using *OLA, please read up on Shinola. tsk tsk dan... You HAD to go there... I was trying to come up with an acronym for CHOLERA and you brought up shinola... I present to you: Streamlined Holistically INtegrated Object Lambda Architecture Sorry... I really couldn't help it. Tho', I do wish the (all) project(s) could focus on the goals/philosophy and code side of things and not worry about names so much. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc -- Damien Pollet type less, do more [ | ] http://typo.cdlm.fasmz.org -- Damien Pollet type less, do more [ | ] http://typo.cdlm.fasmz.org ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goals
On Nov 23, 2007, at 5:04 AM, Waldemar Kornewald wrote: wait for Ian to make an official statement. Can I make an officious statement instead? ;) What are the goals for the programming language you are creating? For the language: - minimum 'default' syntax[1] and semantics[1] to satisfy the following bullet points - malleable syntax, semantics and pragmatics (runtime support/ primitives) - completely self-describing (from machine insns to HLLs) and self- hosting - static and dynamic compilation and anything in between - support for static[1] and dynamic[2] typing and anything in between[3] - late-bound implementation that could replace itself completely at runtime[4] [1] minimum needed to (1) understand C header files and generate library glue and check API correctness and (2) for [3] below [2] including multiple dispatch, since the cost is more than amortised by simpler back-end and numeric code [3] e.g., static type annotations that mangle selectors to help create transparent 'dynamic cast' mechanisms between objects and primitive types [4] including function calling conventions, dynamic dispatch mechanisms, etc. For the system (as opposed to the language): As far as I understand the goals for the language are: * increased productivity (20K lines of code) * more correct code (?by using better concepts and automatic checking?) A goal is certainly to create an environment conducive to these. See my previous message about intent vs. optimisation. * ?better performance than Smalltalk? It entirely depends on what you are trying to do. If you stay entirely within the functional part of the language and avoid closures you can expect performance as good as (or even better than) C. If you spend most of your time sending messages, count on them costing 150% to 250% of a static (C-like) function call for one dynamic (single) dispatch. If you build your own inference engine and feed it prolog, your might never even terminate. ;-) What about goals that give this language an identity: ? easy to learn No. Trivial to 'mutate' into a language that is easy to learn: YES! ? minimalistic syntax Yes. ? very readable code No. Conducive to creating languages that attempt to optimise readability: YES! ? free of unnecessary complexity Yes. ? easy and natural to think in No (except for a very particular kind of brain). Conducive to creating systems that are easy and natural: YES! ? attract many mainstream programmers No. Conducive to creating systems/languages (standard or otherwise) that will attract the mainstream: YES! If you say yes to most of them could you (and the other VPRI members) please order them by priority? All of the above. The 2.5 'yes' responses should fall right out of the circular system described at the start of this message. Cheers, Ian PS: Seeing the next message in this thread, I agree with everything Yoshiki said. (He was being way too modest in the last line of his reply.) ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goals
Hello, As far as I understand the goals for the language are: I believe that there may not be the language but the system and languages. * increased productivity (20K lines of code) Increased productivity, I think, is not a real goal. Mathematical expressions for describing physics concepts are not there primarily to increase productivity of scientists, but give concise descriptions of what is going on in the world and trys to see how simple it can be. (the productivity will probably increase, but it is not a direct goal.) * more correct code (?by using better concepts and automatic * checking?) Some correctness has to be ultimately judged by human and it would be benefited from shorter and clear descriptions. * ?better performance than Smalltalk? Good performance, yes, but not sure better than Smalltalk. I sure hope that better than existing Smalltalk implementations in practical sense. What about goals that give this language an identity: ? easy to learn ? minimalistic syntax ? very readable code ? free of unnecessary complexity ? easy and natural to think in ? attract many mainstream programmers If you say yes to most of them could you (and the other VPRI members) please order them by priority? This list is clearly yours so prioritizing it may not make sense^^; I'd say that the last one is not a *goal* (while dissemination is mentioned, it is not something a research project pursues in general). Minimalistic syntax has many definition so it is hard to agree on. And, other items sound like paraphrases of the same thing. My opinion doesn't necessary reflect my employer's and colleagues, BTW. -- Yoshiki ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
