As Ruby grows, how many more desirable features will have to be hacked in with new syntax? How much more foresight does the present syntax lack? How many syntax rules can a programmer be expected to remember? Saying "there's more than one way to do it" doesn't fly here. You'd have to say instead, "you're going to have to learn how to do this a different way later, if you want to use the nice features."
...
The answer to this one is basically XML, or, to the initiated, S-expressions.
— Joseph Miklojcik, Growth, Syntax, Ruby 1.9, and That Bad Smell You Smell
My imp of the perverse took particular pride in immediately summoning to mind a quote from the preface of SICP. Recite with me:
Thus, programs must be written for people to read, and only incidentally for machines to execute.
Until hand-written S-expressions or hand-written XML become something other than unshockingly unpopular for communication even between programmers, I'll continue to believe that syntax matters and that maybe making parsers smarter is a worthwhile goal in programming language research.
I have great respect for your opinions, and your scheme on parrot inspired my interest in the project.
However I have come to disagree quite strongly with complex semantics in syntax for programming languages. It only makes meta-programming harder.
I have yet to see the meta-programming power of lisp macros come out of a semantic rich syntax in a programming language.
I often wonder at the mystery of why the parens are a put-off. They were for me initially, but now that I am used to them I find them to be the true secret sauce of lisp.
It's hard to advocate lisp without sounding elitist (another mystery), but after a long valiant battle against the popular programming languages to achieve something elegant, concise, correct, with all the repetitive idioms coded in a library instead of the application, you find lisp.
Syntax ? something the parser turns into AST. Semantics ? something I either get from a library or write myself (except special forms) ideally.
I am working on a parser compiler in lisp. I needed delayed binding of productions for right recursion. No problem, a few lines. I wanted persistent lexical closures stored in a variable. No problem, the macro was ~30 lines.
The intermediate code generator is now working, but I don't like how the logic is represented. Even though it's working, it's not intuitive: it requires reading the generator code. I will likely implement a mini logic language so I can make the transformation rules for compiling parser functions more intuitive, which means correctness will be easier to verify.
Since the syntax is just syntax my only thought is what kind of logic language I want, the language itself (lisp) is a non-issue in my design, except that it would be a issue if I didn't use lisp.
A meta-language is the ultimate expression of "There is more than one way to do it".
If programmers find it difficult to understand or communicate ideas through lisp because of the parentheses, it is because they are paying to much attention to the language, and skimming over what the programmer is actually trying to "say" in it.
When I have asked for code review I often perceive from the comments that the reviewer did not even try and comprehend the structure and design of the program. They simply look for the "considered harmful" idioms of the language, and what they consider good practice in the language. Not worth much more than -Wall. This is a huge indicator of how fixating on the language ignores the program.
A rich algorithmic vocabulary in the programmer would help alot more than a semantic rich syntax in the programming language. The almost illiterate quality of most comments in code is strong support for the argument that most programmers implement a program before they can articulate it on a abstract level, even to themselves.
As to a complex parser being a good thing I cannot agree with that. Great dividends are paid in development by throwing away unnecessary complexity before it makes code which is innately complex, totally hairy.
It is sad to watch the brilliant perl6 developers struggle with nasty CFG complexity, hairy backtrack optimizations, and all of the other jazz that goes with a hairy grammar.
Where would perl6 be if the grammar was simplified with prefix instead of infix ? if it was possible to express in a PEG ? maybe it would even be here already, one can only speculate.
I offer these comments out of respect for your talent, to give a honest opinion of the comment posted, since by it's posting you invited discussion.
I will surmise my perspective as this:
If programmers focused on improving their ability to communicate at a higher level of abstraction, reading and writing programs at an algorithmic level, instead of simulating code like a meat CPU as "communication" - then parentheses, curly braces, or whatever else let's the parser build AST, wouldn't really matter anymore.
The language doesn't help communicate complex ideas, it's just a vehicle to delineate essential structure so that ideas can be composed effectively.
The real power is in the vocabulary, which is why difficult professions create their own language, usually in english. The real problem is agreeing on clear definitions of what words mean, and how their combination shades or expands meaning.
blaming the parentheses is a scapegoat. When the language is louder than the program while reading code, that speaks of the programmer, not the language.
If this strikes you as rude or condescending my advance apologies, I did not communicate well. I hold your comments in an esteem worthy of a honest response.
Re:the old parentheses issue
Aristotle on 2008-02-06T14:52:57
I have yet to see the meta-programming power of lisp macros come out of a semantic rich syntax in a programming language.
Has anyone even tried? Perl 6 is the first serious attempt I know of. We’ll see what comes of that.
Where would perl6 be if the grammar was simplified with prefix instead of infix ? if it was possible to express in a PEG ? maybe it would even be here already, one can only speculate.
Except it would be Lisp, not Perl. It would probably be as successful as Lisp, too.
Re:the old parentheses issue
codermattie on 2008-02-06T16:26:40
The death of lisp has been greatly exaggerated, along with similar claims for the death of perl. UNIX was dead too. Yet it seems that not only are all present and accounted for, but they are all growing too.
If perl has a major advantage over lisp for production work it is the single implementation of perl. I don't think anyone was willing to write a perl lexer just to make their own dialect
:) Considering that Industry practice drives at cheapening labor by lowering the bar with dumbed down languages and best practices in leu of judgment and experience, a language assumed "dead" by virtue of it's plasticity or expressiveness is an indicator that the language likely considers the creativity of the programmer an asset rather than a limitation.
Both lisp and perl are often called unreadable. Both lisp and perl celebrate creativity and innovation. Both languages typically integrate documentation facilities directly into the language. I don't think this is a coincidence.
As long as the languages we enjoy continue to prefer creativity over conformity they will always be "dead" and unreadable to the mainstream.
If parrot does succeed we can mix our dead languages to our hearts content, and I at least welcome this new underworld. M-expression or S-expression, the essential piece and hard part is parrot. The rest is a personal estimation of taste.
Re:the old parentheses issue
Aristotle on 2008-02-06T21:27:03
Who said Lisp is dead? Not me; I wouldn’t say a silly thing like that. What I said is that Perl has been vastly more successful than Lisp. Do you dispute that?
Re:the old parentheses issue
codermattie on 2008-02-07T02:00:36
In trying to write a response, lost in thought, I realize that I could bounce this back and forth in my head for days, considering various angles.
very good question !
If you find this discussion truly interesting I am willing to continue the discussion, but in e-mail, considering that it has rapidly progressed to what in programming should be considered a timeless question.
I will think it over though. I really like the question. If we do continue I pose a counter-question indicating my current line of thought. Is Perl timeless ?
Re:the old parentheses issue
Aristotle on 2008-02-07T02:15:33
Lisp is timeless like mathematics. Perl is timeless like language.
Re:the old parentheses issue
codermattie on 2008-02-10T01:07:20
an interesting reply. I haven't had the time yet to noodle on this as I have been coding.
To try and fold this tangent back into the tack of the original reply I think that languages like Lisp and Perl with powerful meta-programming facilities allow the abstraction level to be raised significantly by making both very specific and very general semantics easy to implement.
When the language or the specifics of a problem domain have been leveraged to clarify the code, understanding the code requires a background in that domain, as the general language semantics have been superseded by a representation with a greater local convenience.
When the language is a vehicle for integrating the notations and semantics of various domains it becomes very important to have a very good documentation facility - the language itself is no longer the sole interpreter of the language presented, merely the default.
I am very interested in the idea of building support into emacs for a documentation facility that would stop just short of a literate programming facility. Some sort of latex mode for comments where you can toggle between the rendered form and the source form.
With mathematical quality type-setting, good citation support, and the other odds and ends of latex I think it's possible to set a higher bar in documentation quality, particularly important for macros.
If the documentation is really good then maybe the minor aspects of a language such as parentheses can take a back-seat in the programmer's mind.
