On 10/30/07, Asko Kauppi <askok@dnainternet.net> wrote:
- every library written in a different 'skin' ==> you'll never grow mature, interoperable libraries
Libraries would need to provide their skin modules with them.
In practice, I bet that "skins" would grow some subtle warts, which will make it harder and harder to interoperate two stuffs using different dialects. It's already an issue with Lisp, where proficient developers try to avoid gratuitous macros. Look at LaTeX packages to see what happens when a somewhat skinnable language is left in the hands of non-developers.
- every developer would spend eons designing his own gratuitous dialect of the language instead of being productive
True. But, that's what we already do with classes etc.?
What we're doing isn't perfect; among others, standardizing class-based OO would avoid to get a hard time making two libs with different OO implementations cohabitate nicely. That's not a reason to make things worse.
- code written in those (generally poorly designed) lingoes would be hard for a new developer to take on and maintain. Remember that unless your program is of no interest to anyone, the critical part of its lifecycle will be maintenance, not the alpha-version design.
Maybe. Yet nothing new here. C macros and Lua metamethods are already risking (utilizing) this.
There are many way to poorly use these indeed, and C's preprocessor is quite largely regarded as not worth the troubles (many C++ features are intended to get rid of it; the only part that remains necessary is conditional compilation). Again, that's no reason to introduce new traps if we know beforehand that they'll cause more trouble than productivity boost.
- in addition to maintaining your piece of software, you'll have to maintain your variant of the parser. And it's rather hard to correctly design a parser.
No. Just the skin. Skins are like plugin modules for the extensible parser.
Still, skins can make grammars ambiguous, make some stuff unwritable or unreadable, etc. The balance between the problems they introduce and their actual usefulness when it comes to shipping usable software seems not worth it.
And don't forget that in a compiler, what's hard is not to parse correct entries: it is to produce accurate, usable diagnostics when a source file can't compile. Think about tracking C preprocessor or LaTeX bugs: that's what happens when your error reporting system isn't well designed.
OTOH what would be the matching benefits? Is anyone in the world interested by hiring developers who can't even adapt themselves to type "end" rather than "}"? Is their any hope to get such people to work in teams, to be able to focus on issues that matter, to put themselves in their users' shoes, etc.?
The benefits would be having modular solutions to about 90% of the now-patch-requiring issues.
I.e. Lanes could utilize this to add subtle parallel-aware syntax into the language (Lua).
Concurrency certainly is a semantic addition: if something introduces a new way of thinking about your programs, then syntactical support might not be superfluous (but remains harder than it seems to get right). I'm obviously biased towawrd metalua here, but it seems to me that source parsing can always be taken out of the critical optimization path, so it ought to be dealt with in Lua rather than in portable assembler, if it is intended to be tweaked by users. C maintenance costs are much higher than lua's, so it makes sense to patch the VM, but not the compiler IMO.
[bitching against superficial syntax bitching]
I think it was meant with a grain a salt? The new era is near, and human curiosity cannot be stopped.
I hope so, and my rant was somewhat tongue-in-cheek as well. But it remains that developers tend to underestimate the cost of gratuitously plastic syntaxes, because more generally, they overestimate the importance of first version, single developer design (the funniest part) over maintenance, code reuse, teamwork, developer interchangeability etc.
The term "skinning" is especially a red herring, as it is reminiscent of winamp or X11 WM's skins: stuff that waste screen real estate, generally display a very poor taste, provide no functional added value, and on which users can lose hours tweaking the system for no benefit.
