lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On 10/30/07, steve donovan <> 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

- every developer would spend eons designing his own gratuitous dialect of the language instead of being productive

- 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.

- 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.

- 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).

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.?

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.