Fabien kirjoitti 30.10.2007 kello 15:33: On 10/30/07, steve donovan <steve.j.donovan@gmail.com> wrote:
Maybe it would be productive to think of programming languages as 'skinnable'?
The cost would be:
- every library written in a different 'skin' ==> you'll never grow mature, interoperable libraries
Libraries would need to provide their skin modules with them.
- 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.?
So the problem is deeper than skin. - 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.
- 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. - in the special case where you disguise a language's surface syntax into another's (here lua into JS), you're actively deceiving your hypothetic users, by introducing a profound mismatch between that syntax (which triggers reflexes in the developer) and the semantics (which would remain Lua's).
Better deceive them so well, they won't notice it? ;)
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). Please stop bitching about the superficial syntax already: the main interest of surface syntax is to help people following compatible coding styles, so that they understand each other's code more easily. Human brains easily cope with terribly complex languages such as English or Chinese, so coping with a programming language's couple of idiosyncrasies is a non-issue for normal people (again I'm talking about surface syntax, not semantics). AFAIK, most people who get endlessly passionate about "{ }" vs. "end" vs. significant indentation focus on these non-issues to avoid focusing on their inability to design real programs.
Tweaking the syntax is hard and dangerous. It's only worth it if the change is intended to support a new semantic construct. It makes sense to introduce additional syntax to support a given OO flavor, or generic programming, or functional programming, in languages that don't support those natively. If you're just substituting a [sequence of] keyword[s] for another, you're not only losing your time, you're designing a sabotaging tool.
I think it was meant with a grain a salt? The new era is near, and human curiosity cannot be stopped. Let us embrace skinning!
-asko
|
