Why Language Extensibility Matters

[fare]

If you neglect some aspect of computation in designing your programming language, then the people who actually need that aspect will have to spend a lot of time dealing with it by themselves; and if you don't let them do it by extending your language, they'll have to do it with inarticulate barkings rather than civilized sentences.

Comments

Award: Most Worthless Blog Post of the Day

[anonymous]

You scored high for:
* Saying absolutely nothing
* Wasting my time
* Posting when you shouldn't have
* Pretending the old is new again
* Having a fascist comment moderation system
* Repeating tired lisp dogma yet ignoring that any extension to a Lisp system is not easily handled by tools (FYI your tool has to parse Turing complete macros, THAT'S HARD).

Dealing with language extensions

[fare]

It is certainly hard to deal with language extensions, but

Re: Award: Most Worthless Blog Post of the Day

[anonymous]

The most extensible language ever was Forth; Forth gives you the ability to run code at compile time, primitives to steal the source stream from the compiler, suck in your own syntax, and generate your own code. I wrote a PostScript interpreter in a Forth like language and implemented the following code:

Check( Number Number --> Number )

The compiler in this case is named "Check(". Yes, that's right, the paren was part of the compiler's name. It parsed up to the closing paren, and generated Assembly code to validate that two numbers were to be given on the data stack, Checked for stack underflow, and required that a number be left on the data stack by the following code.

I often miss programming in that world, the highly interactive, write only language that Forth can be. Oh well.... THAT kind of extensibility just isn't allowed in modern languages...

[anonymous]

Your language link was interesting (I thought my browser was buggy when half the word was colored as visited), but you should update it to (at least) [python][ruby] not [obsolete-language-whos-name-I-wont-mention][python] as it is now.

Weak argument

[ext_143602]

Extensibility is very important, but you make a very weak argument for macros. Python lacks macros entirely, so shouldn't it suck?

Also, wouldn't it be that much better to alter the parser itself, defining syntax that really matches what you need? Sure, there's more to learn when switching from language to language, but large scale macro systems (such as CLOS) have that problem anyway.

Impedence mismatch

[ext_143602]

Minor nitpick: Python 3.0 didn't introduce the impedance mismatch - it was there all along. The user wants text and the OS only handles bytes. Only if you eliminate the user can you remain blissfully ignorant and only handle bytes.

Python 3.0's defaults simply make having a user much easier.

Other things matter too

[ext_157382]

You're not convincing me with all that rambling :-)

I like the idea of implementing Python in Lisp, using macros behind the scenes, making Python extensible in Lisp and vice versa. That didn't make sense two decades ago when Python was begun... can you imagine writing it in Common Lisp at the time? It would've been an academic curiosity... and I'd still be using C.

Python got where it is by focusing on practical concerns first, with gradual refinements to make it more regular and extensible, more Lisp-like. Python 3.0 finally has sensible lexical scope rules, which Scheme had 30 years ago. Conversely, PLT Scheme 4.0 finally has a module system on par with Python's. It's nice to see both camps learning from one another. Of course, I use Python for real work. Being part of a cohesive community has its benefits.