Re: [fonc] On inventing the computing microscope/telescope for the dynamic semantic web
On Fri, Oct 8, 2010 at 8:28 PM, John Zabroski johnzabro...@gmail.com wrote: Why are we stuck with such poor architecture? A bad language attracts bad code. ;) Bye, Waldemar -- Django on App Engine, MongoDB, ...? Browser-side Python? It's open-source: http://www.allbuttonspressed.com/blog/django ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Avoiding math precedence ambiguities
Hi Yoshiki, On Dec 13, 2007 8:11 PM, Yoshiki Ohshima [EMAIL PROTECTED] wrote: On Dec 12, 2007 8:00 AM, Yoshiki Ohshima [EMAIL PROTECTED] wrote: It is good to know there are a handful! If we move even higher description, such places should be rarer, I think. Could you and Ian please clarify the official position on this topic (you two had contradicting opinions in your emails)? In a post while ago, I wrote: --- My opinion doesn't necessary reflect my employer's and colleagues, BTW. -- This makes me wonder: Who is the official voice in this project? Ian? Alan? You all together (after you've agreed on something)? Etoys already has very strange precedence rules (right-to-left). Do you plan for the Etoys-like system to have math precedence? The precedence rule in the newer (but not so new) Etoys for OLPC follows the one you seem to like. (* / // \\ are stronger than + and -, and min: and max: are weaker than + and -.) I think this is a good idea for that audience. Great. I guess this means that your Etoys variant will have similar rules? :) As I wrote, I'd anticipate there aren't too many of expressions with conflicts. I think this means that we don't really have to make everything right from the beginning. Agreed. Getting the basics right is critical, but I hope that with some form of help you can create a more usable product right from the beginning. Bye, Waldemar Kornewald ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] patterns/research for newbie PLs
Hi, here are some other interesting articles. The first one has a nice table with frequent bugs at the end. The second one summarizes various studies. * An Analysis of the Errors Made by Novice Programmers http://www.sacla.org.za/SACLA2006/Papers/RP01%20Pillay%20Programming%20Errors.pdf * An Exploratory Study of Novice Programming Experiences and Errors http://gild.cs.uvic.ca/docs/summary/SuzanneThompsonThesis.pdf * Studying the language and structure in non-programmers' solutions to programming problems http://web.cs.cmu.edu/~pane/ftp/PaneRatanamahatanaMyers2001.pdf You might also want to take a look at the Natural Programming Project: http://www.cs.cmu.edu/~NatProg/ They have lots of interesting papers. * A development study of cognitive problems in learning to program http://www.ppig.org/papers/15th-tucker.pdf * Cognitive strategies and looping constructs: an empirical study http://cq-pan.cqu.edu.au/david-jones/Teaching/Innovation/Lit_Review/p853-soloway.pdf * Visualizing Roles of Variables to Novice Programmers http://www.ppig.org/papers/14th-sajaniemi.pdf * The Roles Beacons Play in Comprehension for Novice and Expert Programmers http://www.ppig.org/papers/14th-crosby.pdf * From Procedures to Objects: What Have We (Not) Done? http://www.ppig.org/papers/19th-Sajaniemi.pdf -- I think we'll have to summarize all articles (if they aren't already summaries) to have a practitioner's takeaway for this project. I could really need some help here. This topic is overwhelmingly large. If somebody is interested, I've looked through the PL learning/novice articles PPIG 2007-2000 (http://www.ppig.org), so you don't need to duplicate this effort (unless you find something I overlooked ;). John Pane seems to have other interesting papers: http://www.cs.cmu.edu/~pane/publications.html The Natural Language Project has more publications: http://www.cs.cmu.edu/~NatProg/publications.html Then, there's a site collecting articles about visual PLs: http://web.engr.oregonstate.edu/~burnett/vpl.html So, please help with summarizing and suggesting interesting articles. Bye, Waldemar Kornewald ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Avoiding math precedence ambiguities
Hi, On Dec 12, 2007 8:00 AM, Yoshiki Ohshima [EMAIL PROTECTED] wrote: It is good to know there are a handful! If we move even higher description, such places should be rarer, I think. Could you and Ian please clarify the official position on this topic (you two had contradicting opinions in your emails)? Do you plan for Coke to have math precedence? I guess no. It doesn't matter to me as long as the Etoys-like system is planned to become a fully practical programming system that could compete with Smalltalk, for example, and at the same time focuses on ease of use. Etoys already has very strange precedence rules (right-to-left). Do you plan for the Etoys-like system to have math precedence? Do your goals for ease of use align with what the Natural Programming guys are doing? Bye, Waldemar Kornewald ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Avoiding math precedence ambiguities
On Dec 13, 2007 4:18 PM, Steven H. Rogers [EMAIL PROTECTED] wrote: Right to left precedence is very easy to get used to. It makes for a natural left to right reading of expressions. At least this is natural for those who are used to reading human languages left to right. Crazy. But I think I got it. %-) ;;;) Bye, Waldemar Kornewald ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] patterns/research for newbie PLs
Hi Jason, On Dec 11, 2007 10:49 PM, Jason Johnson [EMAIL PROTECTED] wrote: This is a good article. Thanks for that. I'm currently trying to find more articles that could be of use to this project. The Psychology of Programming Interest Group (http://www.ppig.org) has a lot of articles and I want to filter out the most interesting usability-related ones. It would be nice to have a wiki where we could collect bibliography and write down ideas, RFCs, and important findings of usability studies. Did you notice this part? Yep, I did, and I actually expected that you would quickly find it. :) I read this to mean what we were saying before: most users expect math to evaluate as written, not by switching to a difference precedence. The article didn't explicitly mention arithmetic operators and as has been said on this list many programming languages have very confusing rules for other operators, so this might be what the authors actually wanted to prevent. In order to end the confusion, I've sent out mails to profs who taught Smalltalk and a few scientists who made studies of common programming bugs, including the authors of that article. Bye, Waldemar Kornewald ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] patterns/research for newbie PLs
Hi, maybe this is of interest to you (probably the VPRI members already know it, though): http://www-2.cs.cmu.edu/~pane/cmu-cs-96-132.html It's a collection of empirical studies and expert opinions about programming language usability for novices. It also mentions visual languages. The paper might at least be useful for Next Etoys, but I hope it'll also be interesting for other (to be invented) languages. Bye, Waldemar Kornewald ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] patterns/research for newbie PLs
Hello Kim, On Dec 11, 2007 11:06 PM, Kim Rose [EMAIL PROTECTED] wrote: fyi... Our team worked closely with Jim Spohrer while at Apple Computer. He remains a good friend and colleague. Could you please give me his email address or ask him whether his studies showed that math operator precedence makes a language easier to learn and whether not having math precedence (as in Smalltalk) results in more bugs? Thank you! Bye, Waldemar Kornewald ___ 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 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 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
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
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] goal clarifications
On Nov 26, 2007 2:32 PM, Steven H. Rogers [EMAIL PROTECTED] wrote: The VPRI goals are certainly open ended and will need to gain focus to show useful results, but just as lack of focus can dilute efforts, too much focus too early in a research project can channel the work into non-productive areas. Having open-ended goals doesn't mean being unfocused. Imagine someone suggests that the programming language should have static type checking. We should be able to point to the goals (e..g, dynamic, reflective environment), so it's obvious that this suggestion doesn't fit. What I'm missing is: * crisp mission statement * ordered list of the first few milestones (can be open-ended) * priority-ordered list of non-ambiguous goals for each milestone That information should be prominently visible on the front page of the website. Instead of reading about the traditions and history (What is Viewpoints Research Institute?) visitors foremost want to know What are you creating?. Well, I'll *try* to improve the front page and post an example (this will take some time), but it will not list any goals because I don't really know them. Bye, Waldemar Kornewald ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goal clarifications (was: goals)
On Nov 25, 2007 6:50 PM, Bert Freudenberg [EMAIL PROTECTED] wrote: Did you actually read the NSF proposal and its secondary literature? I read everything that didn't smell like implementation, but I think I didn't really understand it. I had the impression that, put very bluntly, it's about teaching children how to code in an innovative programming language and using that to teach them science and analytical thinking. The programming environment would at the same time be a general-purpose computing system (OS?), maybe similar to Croquet/Squeak, so you can do everything in it, but you have to be an expert which is no problem because you get taught everything at school. I definitely haven't yet understood it and of course this mail is full of irony. I'm trying hard to not picture an army of little programmers and scientists. :) Bye, Waldemar Kornewald ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goal clarifications
Hi, On Nov 26, 2007 3:13 AM, Steven H. Rogers [EMAIL PROTECTED] wrote: I think the VPRI teaching goals are only indirectly related to the FONC project. The latter seems to be a reexamination of the programming process with the goal of developing a unified programming model that works for OS kernels, device drivers, web servers, distributed databases, office applications, econometrics models, air traffic control system, gene sequencing, etc. [...]*snip* Yes, that's probably the obvious part of it because they explicitly mention a cool programming environment and Alan writes about teaching kids, but I think there is more. One of the other projects is powerful ideas content and how to represent it. That's very interesting, but this part hasn't been clarified, yet. It seems to target not only children, but also adults. How far will this go? Is it only about knowledge in the sense of Wikipedia or is it about any kind of information (e.g., project management data)? Could this be important for companies (knowledge management)? The goals aren't clearly stated, so I don't know where it stops. The front page makes the goals sound very open-ended. It starts with teaching children and later it mentions computer revolution (though, learning always seems to have the focus). Bye, Waldemar Kornewald ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
