The first feature that really jumped out at me were the scoped mixins. From the docs:
You can swap out mixins for the span of a single source file. Example: you could give all strings a "backwards" method. But just for the code inside your test.pn script.
This would let you monkey patch in a safer fashion.
> I don't like significant whitespace, personally ... (one of ideas is an) elimination of line noise*
Yay to that.
If you think about it, very few programming languages had legibility (readability) of the code as one of their design goals. Not through the natural language verbosity, but rather by reducing or eliminating the code needed to please the compiler and otherwise not related to the actual application logic.
D makes a good step forward in this direction (compared to C++), and so does Python. Java is close, but still pretty "noisy". Petrovich is the best there is, but it's not very practical.
This is an interesting subject, so if anyone has any thoughts on the matter, please post below.
I think at the end of the day, what is noise for one application domain is signal for another.
Have you heard of Concept programming? http://mozart-dev.sourceforge.net/cp.html I think the basic idea is that it somehow separates the domain-specific code from the code that pleases the compiler.
Python was designed with readability as a goal. That was the reason for significant white space rather than {}. On some European keyboards the braces had to be typed as triples. I don't find Java particularly readable even though I code in it every day.
a.equals(b) vs a == b
The antithesis of readability is APL, which is nothing but line noise. When it came out, you had to get a special printhead just to type it. You could make some unbelievable one-liners though.
It's interesting that there are no classes, and that there are only Objects, where you just mix everything in.
As I understand it, javascript objects are like this, except you only add in methods one at a time, instead of mixing in and out modules.
It doesn't look like there are inheritance trees. I'm not sure what you'd do to prevent namespace clashes when mixing in different modules or if/how modules share and work on object attribute data, but so far in Ruby, that hasn't been too much of a problem.
I think you'll have a "well, duh" reaction if you implement an OO system in pure C. It is basically just a bunch of structs (data) with a bunch of functions which take a struct pointer as their first argument. Mixins just let you randomly add or remove these functions without any extra shenanigans, which you can also easily do in our pure C OO system.
