OT: on IDEs and code writing on steroids

[Yigal Chripun]

Andrei Alexandrescu wrote:
> Yigal Chripun wrote:
>> Nick Sabalausky wrote:
>>> I suppose that might make reverse-engineering easier which MS might 
>>> not like, but I'm not suggesting this as something that MS should 
>>> like or should even do, but rather suggesting it as (business issues 
>>> completely aside) something that would possibly gain the benefits of 
>>> both styles.
>>>
>>
>> that's the exact opposite of a good solution.
>> I already mentioned several times before the language Nemerle which 
>> provide the correct solution.
>> important fact - Nemerle is a .NET language and it does _NOT_ need to 
>> modify the underlining system.
>>
>> The way it works in Nemerle is pretty simple:
>> the language has a syntax to compose/decompose AST.
>> a Macro in nemerle is just a plain old function that uses the same 
>> syntax you'd use at run-time and this "function" can use APIs to 
>> access the compiler's internal data structures (the AST) and 
>> manipulate it.
>> you "connect" it to your regular code by either just calling it like a 
>> regular function or by using attributes.
>>
>> let's compare to see the benefits:
>> in D:
>> tango.io.Stdout("Hello World").newline; // prints at run-time
>> pragma(msg, "Hello World"); // prints at compile-time
>>
>> in Nemerle:
>> macro m () {
>>   Nemerle.IO.printf ("compile-time\n");
>>   <[ Nemerle.IO.printf ("run-time\n") ]>;
>> }
>> // and you call it like this:
>> m();
>> Nemerle.IO.printf ("run-time\n");
>>
>> notice how both use the same code, the same printf function?
>> the only change is that the second line inside the macro is enclosed 
>> inside <[ ]> which means output (return) the AST for this code instead 
>> of actually running the code and returning the result of the call.
>>
>> Macros in Nemerle need to be compiled since they are regular Nemerle 
>> code and they need to be loaded by the compiler (added to the command 
>> line) in order to compile the code the calls the macros.
>>
>> essentially these are just plugins for the compiler.
>>
>> compared to the elegance of this solution, templates are just a crude 
>> copy-paste mechanism implemented inside the compiler.
> 
> Nemerle's interesting, but it has its own issues. The largest one is 
> that it will have to beat history: languages with configurable syntax 
> have failed in droves in the 1970s.
> 
> Before I got into D, I was working on Enki. Enki was my own programming 
> language and of course made D look like a piece of crap. In Enki, you 
> had only very few primitives related to macro expansion, and you could 
> construct all language elements - if, while, for, structures, classes, 
> exceptions, you name it, from those primitive elements.
> 
> There were two elements that convinced me to quit Enki. One was that I'd 
> got word of a language called IMP72. IMP72 embedded the very same ideas 
> Enki had, with two exceptions: (1) it was created in 1972, and (2) 
> nobody gave a damn ever since. IMP72 (and there were others too around 
> that time) started with essentially one primitive and then generated 
> itself with a bootstrap routine, notion that completely wowed me and I 
> erroneously thought would have the world wowed too.
> 
> The second reason was that I've had many coffees and some beers with 
> Walter and he convinced me that configurable syntax is an idea that 
> people just don't like. Thinking a bit more, I realized that humans 
> don't operate well with configurable syntax. To use the hackneyed 
> comparison, no natural language or similar concoction has configurable 
> syntax. Not even musical notation or whatnot. There's one syntax for 
> every human language. I speculated that humans can learn one syntax for 
> a language and then wire their brains to just pattern match semantics 
> using it. Configurable syntax just messes with that approach, and 
> besides makes any program hugely context-dependent and consequently any 
> large program a pile of crap.
> 
> That being said, I have no idea whether or not Nemerle will be 
> successful. I just speculate it has an uphill battle to win.
> 
> 
> Andrei

I didn't talk about configurable syntax at all above.
Yes, Nemerle has this feature as part of their Macro system but that's 
just one rather small aspect about the system that can be removed. I 
also don't see the bigger problem with it as you describe since this is 
limited in Nemerle to specific things.

I'm also unsure as to what you define as syntax and what you define as 
semantics. for example, Smalltalk has only 5 keywords and it's 
implemented entirely as a collection of libraries. "if" "else" "switch" 
"while" are all implemented as methods of objects and therefore are 
configurable. Is that also wrong in your opinion?

I agree with dsimcha -
the language needs to provide simple intuitive defaults, that's why I 
think LISP didn't succeed. it is very powerful but the need to write 
your own macro just so you can say "4 + 5" instead of (+ 4 5) shows this 
point.

I think Nemerle provies this - the constructs in Nemerle for the Macro 
system are very simple and intuitive. you only have one extra syntax 
feature, the <[ ]>. think of D's CTFE only much more extended in scope - 
you write a CTFE function and compile it. (that's the Nemerle Macro 
equivalent) than you just call it in a different file and the compiler 
will execute this function at compile time.
Nemerle does not need an interpreter for this since these functions are 
compiled just like the rest of the code. Nemerle also provides compiler 
APIs so these functions could work on AST to add/alter/remove types and 
other constructs.

Last thing, basing your arguments on history is flawed. the Micro-Kernel 
idea got the same treatment after the failures in the 80's (Mach and 
co.) but nowadays this idea was revived and there are already several 
million cellphones that run an OS built on the L4 micro-kernel so it's 
even a commercial success.