Welcome to the Grace language blog. We are starting to post our preliminary idea on teh design of Grace, and hope that you will contribute to the discussion.
You can get an RSS feed for this blog — there is a link at the bottom on this page. We also have an email list that you can sign up for: go to https://mailhost.cecs.pdx.edu/mailman/listinfo/grace-interest
The Alice research project did lots of work on program language syntax for novice learners. Here are some of their findings that I can remember:
* ignore capitalisation.
* syntax directed editors can help a huge amount.
* 1/2=0.5 (more semantics, but very important)
Hmm. We’re not really going after he same design point as Alice – or especially as scratch. I learnt to program with a syntax directed editor (ZX-81) but were being old fashioned: starting out by designing a language, rather that an IDE – we hope there will be IDEs for Grace, and we certainly don’t want to do anything that would preclude IDE suporting syntax directed editing.
I’m not sure what you mean by 1/2=0.5 ?
I think the “1/2 = 0.5” is suggesting that the natural language way of writing fractions as “1/2” should result in a float value of “0.5” rather than an integer value of “0”.
I think the insight that novice programmers often don’t distinguish between various number forms is important. But it depends on the goal of the language. If Grace is aimed as a language to teach people to becoming programmers then making the common distinction between integers and floats is important if the students are expected to move to other traditional languages. However, if the goal of Grace is to expose people to a taste of what programming is/teaching logical task description then the Alice approach of more semantics and structured IDE becomes important.
“1/2″ should result in a float value of “0.5″ rather than an integer value of “0″.
Sure. We are trying to minimise the number of core types that programmers (especially students) must learn, or that the language must implement. In fact, that should be the topic of the next post in a couple of days.
I strongly support the distinction between const, var, field, method (and the single namespace). This will (a) remove some unnecessary confusion, and (b) make it much easier to explain the differences – having keywords in the language for important conceptual distinctions helps to communicate those distinctions, and continually reinforces the distinctions in the students’ minds. (the loss of “procedure” and “type” keywords when moving from pascal to java had a significant effect).
There are details about the set_x(..) and x:= that need to be worked through.
Although I support the “One True Message Send” principle, and I think it will make understanding simpler, I don’t like casting it in terms of “messages” since that is not the true semantics – a message passes information, but not control. If we wanted to talk about messages, then we should use a proper message passing semantics (as is done in Scratch broadcast messages). But the proposal is not talking about messages between actors, it is talking about “method calling”. The title could be “One True Method Call”.
I like the ability to use curly brackets (braces) and/or indentation, but I think that it is essential that if a programmer uses both braces and indentation, then it should be a syntax error for them to be inconsistent. If there are braces, it is OK to have no indentation (all on one line, or all starting at the beginning of the line), but if there is any indentation at all, it must be consistent with the braces. (Of course, there could be editor support for making the indentation consistent with the braces, or making braces consistent with the indentation, but inconsistency should be an error). Otherwise students will trip up when debugging because they will interpret the code according to one of them, while the computer is interpreting the code according to the other.
I think that Peter is correct that historically, when Smalltalk adopted the “message send” terminology, it took only part of what actors had meant by message send — Smalltalk objects shared the same thread of control instead of each having it’s own thread. Still, this (miss) use of Message send is firmly embedded in the O-O culture, as is the term method.
The reason that I refuse to use the term “call” for messaging objects is that it makes students think that invoking a method is just like calling a function. The vitally important idea — that the choice of which code to run is made by the receiver, not by the sender, gets lost.
I don’t know of a better term than “send” — but am open to suggestions!
If we keep the distinction between temporary variables and fields, are there any suggestions on what to call constant fields?
And I totally agree that if there are both curly braces and layout, then they have to be consistent. Otherwise, as I suggested previously, we might allow curly braces only in the absence of layout.