Post by GourWHile browsing modula-2.net site I've noticed that Team some additional
members [...]
In any case, let's hope there will be additional members in not so
distant future...
One thing that sets our project apart is that we used the old-fashioned approach: Do a thorough design first and get it right, then implement. However, good language designs don't come from large groups. Wirth has written about that and Rick and I had our own personal experience from participating in the ISO M2 working group. Nevertheless, we have had many collaborators during our design phase who peer reviewed our work and provided invaluable feedback.
Now that we have embarked on implementation, we need a different kind of collaboration and we are actively recruiting. To this end, it is important to divide the work in such a way that people can work mostly independently. Another challenge is that many people, even with excellent skills, often think building a compiler is a kind of rocket science and they won't be able to contribute anything because it must be over their heads. In reality, this isn't really as hard as many imagine it is, especially not with the recursive descent parsing method we chose. High efficiency code optimisers are hard to do, but there are frameworks for that such as LLVM, and then again it is not strictly necessary. If I am not mistaken, most if not all of Wirth's compilers have been non-optimising.
Nevertheless, there are a few more folks interested in joining. However, the important milestone here will be the bootstrap. Even limited to a subset, once we have a self-hosting compiler that people can download, build and play with, we can expect a larger number of volunteers joining the effort.
Post by GourOtoh, there are noble goals mentioned in http://modula-2.net/m2r10/pmwiki.php?n=Project.Goals andI hope all of them will be accomplished with success...
One of the folks commenting in this group -- even though usually in an obnoxious and negative way -- has made an interesting observation in that once universities teach Python to their undergraduate students, the latter become addicted and all hope to teach them proper engineering is then lost.
There is a lot of truth to that. The ideal is to have an appealing notation that is also founded on proper engineering principles. While these objectives are often contradictory and thus hard to design in a single package, it is not impossible to do. Steve Jobs said "You need to start with the user experience and then work your way back to the technology". A lot of what makes programming languages appealing has to do with user experience, and in particular with convenience.
Thus, the choice is often "do we give them the convenience or do we make it safe and reliable?" The kind of designer who designs languages such as Python and Ruby generally chooses convenience over safety and reliability. OTOH, when you want to design a type safe language you are often inclined to choose safety over convenience, but in many cases it does not have to be an either-or proposition. Work a little harder at your design and you will find that you can very often accomplish safety, reliability and convenience. Very often you can have your cake and eat it too. You must not give up too easily.
When you accomplish that for a large part of your design, you will have something that is both pleasant to use but also founded on engineering principles. Then even people who do not yet know to appreciate the engineering foundation will at first notice the convenience and like the tool for that. Later on, they will get to realise the value of the engineering foundation, too. And those who know that in case of a conflict between convenience and safety, convenience must be sacrificed will come to realise that they do not necessarily need to make that sacrifice as often as they have come to accept. They too will come to like the tool for it gives them the safety they don't want to compromise together with the convenience they have previously had to do without.
This is why we believe we have a very good chance of successfully broadening the reach of our project.
To name a few examples where we managed to do both convenience and safety ...
(1) variadic functions
C practitioners often use variadic functions, they can be of great utility and thus convenience. Think of inserting an arbitrary number of key/value pairs into a tree, if only for initialisation:
insert(tree, key1, value1);
insert(tree, key2, value2);
insert(tree, key3, value3);
etc etc etc
versus
insert(tree, key1, value2, key2, value2, key3, value3, etc etc etc);
Unfortunately, though, in C variadic functions are done such that they are dangerous. Variadic parameters are entirely untyped, crashes are almost guaranteed.
That doesn't mean you couldn't do it right. In our revision we have designed fully type checked variadic parameters, thus combining safety and utility/convenience.
(2) string concatenation
Languages like Python and Ruby permit infix expression concatenation of strings, not only string literals, but runtime strings as well, or a mix of runtime strings and string literals. Working with strings without infix concatenation can be extremely inconvenient and significantly increase clutter and opportunity for error in source code. Yet when it is done by way of what is known as duck typing, the facility is not safe. Here again it seems that the choice is either convenience or safety, not both.
Our revision provides infix concatenation of non-rigid arrays (including ARRAY OF CHAR and ARRAY OF UNICHAR) but type safe.
A non-rigid array is an array whose number of components is not fixed (within limits). Even statically allocated arrays may be non-rigid. NUL terminated character arrays and Pascal strings are examples of non-rigid arrays that can be statically allocated.
Some languages call them open arrays but this usually only applies to dynamically allocated arrays. Our terminology includes both statically and dynamically allocated arrays.
(3) array slicing
Python and some other languages offer array slicing which is of immense utility and convenience, but again due to the means by which it is implemented (duck typing) it is unsafe.
Our revision provides both L-value and R-value slicing for non-rigid arrays and lists, again, type-safe.
target := source[m..n];
target[p..] := source;
target[p..q] := source;
target[p..q] := source[m..n];
and with concatenation
foo := bar[m..n] & baz[p..q] & bam;
all indices are bounds checked, all component types must satisfy strict name equivalence.
There are other instances where we have married utility with safety. In fact we did not compromise safety anywhere. We are confident that the aforementioned addiction effect that reportedly occurs when teaching undergraduates Python, will work in our favour and thus in favour of safety and engineering principles, since convenience doesn't mean abandoning the latter.
IOW, to promote engineering principles, you have to wrap it in a convenience package or it won't fly. We worked very hard to heed that lesson.
I am thus confident that we will not have any issues recruiting volunteers for the project. However, as mentioned, the important milestone to achieve first is the bootstrap. That is going to be key.