What is Grace ?
At ECOOP (European Conference on Object-Oriented Programming) in Maribor in 2010, a need for a new language appeared. About twenty people, mainly teachers and researchers from Universities around the world, gathered and agreed on design principles for a new programming language, Grace. The Grace Programming Language, designed and implemented by Andrew Black, with Kim Bruce, Michael Homer, Tim Jones, and James Noble, is the result of that design process.
The purpose of Grace is to allow novices to discover programming in the simplest possible way. Other famous languages such as Java or Python are widely used by professionals, but may be hard to assimilate for a beginner in programming. That is what the object-oriented Grace language is made for.
Starting with Grace
Where do I run Grace ?
Minigrace is the implementation of Grace and its library being used in teaching. It does not yet implement everything the current draft specification. You can try minigrace online in your web browser (works best in Chrome or Firefox).
A tutorial with examples is available; you can also read the language specification and the standard library documentation there. The examples in the tutorial are “live”; you can edit and run them to see what happens.
A few things to know about Grace
Grace is an object-oriented language, you can define classes and objects as we will see later.
Our goal is to help novices at programming to learn how to write correct and clean code; this is why indentation does matter in Grace. Each new block (delimited by braces { and }) must be indented at one level further than the previous line. Otherwise, all lines must be indented at the same level. Line breaks end statements, so semicolons are unnecessary. The exception is that if you need to continue on the next line, you can do so by indenting the second and subsequent lines of a long statement.
| Accepted | Not Accepted | ||||
|
|
You can check and test all the specificities on Grace in one page
Hi, a little correction above … you say “delimited by semicolons {}” but actually those are not semicolons. Usually they are called curly braces {}.
Thanks! (We fixed it.)
I realise that the overall language design is probably finalised, but if indentation does matter, would there be any ambiguity in removing the need for { and }? I’ve only just started looking at Grace so the answer may become obvious, but as my father always used to say ‘If in doubt, cut it out’.
My worry about { and } is that they are so ‘thin’, and easily (for a beginner) confused with ( and ) or [ and ]. This is why I prefer the Visual Basic End … keywords, e.g.,
class cat
def name = “Felix”
method getName
return name
end method
end class
Hi John that’s a good question – the language design is mostly finalised but we still think about options.
I actually tried out a design based on indentation, and it worked surprisingly well. Where the curly brackets are significant is for blocks, which in Grace are lambda expressions. So ‘(print “x”)’ prints immediately, but ‘{print “X”}’ is delayed until evaluated. That’s how any control structures work in Grace, from “if” on up — Grace is like Smalltalk or Ruby in this.
As to why we went with curly brackets for other structures too — so that Grace would (at first glance) look like other curly bracket languages: Java, JS, C#, C…
May be we should stick to Python since Grace is more or less 98% Pythonic with somethings of 2% or even less.
There are many variation of Python Langauge out there already. Also more people are writing DSL nowadays than ever
You need more review as Python is already in main stream for teaching programming in schools, colleges and HE
Now:
def name = “Felix” def for methods (Functions/procedures). May be change this to keyword –> var
method getName { } //need review. In nested form could lead to many errors since its still requires indentation at sub level
Indentation being significant is a non-starter. Files are transferred; code is written on paper and whiteboards; people talk about it. Significant indentation is a total 100% negative feature, especially for learners who have enough to worry about with the concept of blocks in general. If braces are “thin”, then tabs are completely invisible and users will be face with the task of counting invisible things when trying to copy code from a print out; God help them if it’s not in a monospaced font.
Shame to see such a basic practical error.
I completely agree with Thomas. A better way to lead people to have good programming practices is to issue warnings. Indentation being significant is the only thing I hate in Python. Such indentation is only a useless constraint. Beginners pay too much attention to syntax, so the syntax must be kept stupidly simple (KISS) and a good editor must give clues about syntax so that they can concentrate on the interfaces and relationships between classes, and not on the syntax. Simple syntax also makes it easier to implement a compiler or an interpreter or to automatically convert the code to other languages.
For me, a good language to start with, is a language with a limited syntax, with as few operator signs and syntactic constraints as possible, and that comes with a good IDE. A good IDE should have a good editor with syntax hilighting, would automatically show the parameters of built-in functions and constructs. A view that lists them in a hierarchical way also makes code writing easier (no need to memorize functions or syntax: KISS).