

Letter to a Young PL Enthusiast - vamsee
http://axisofeval.blogspot.com/2010/06/letter-to-young-pl-enthusiast.html

======
jules
> Ignore the siren calls of the virtual machines. You have to be the master of
> your domain. Use C or assembler to implemente your language. The free Unices
> are your friends. Learne about the internals of your operating system, how
> it compiles, links, loads, and runs executables, the fruits of your labor.
> Learn about calling conventions, system calls, and the god-given hierarchy
> of the memory.

Might want to skip the low level stuff and quickly get to business with high
level libraries like the Dynamic Language Runtime.

~~~
pwpwp
Sure. But IME, somewhat paradoxically, the lower you go, the more freedom you
gain. Not to speak of understanding.

~~~
jules
True, but if you have a great idea for a new language you really don't want to
spend _years_ implementing your own code generator, garbage collector, runtime
system and standard library; you want to get a useful language as quickly as
possible.

As an educational experience doing everything yourself from the machine code
layer up is great, but for getting stuff off the ground it's not.

~~~
prog
I agree that the VM can be a lot of work. However, some language features may
need support from the VM. E.g. Scala and Clojure don't have full TCO support
as JVM doesn't support that (yet!). If a languages uses an existing VM, it may
need to work around the VM limitation. I suspect thats the reason Jython is
slower than CPython even though JVM is much faster than the CPython VM.

IMO the big advantage of using a mature existing VM is the library. It should
be possible to have at least a usable GC (say simple mark-and-sweep), code
generator etc. without too much effort.

~~~
Scriptor
It'd be a good idea to decide on what features you want most and whether the
disadvantages of a VM offset its advantages. Although Clojure lacks TCO, it's
already gotten very popular very quickly, maybe more than other lisps. Hard
data for the JVM's role in this is the poll posted not long ago that showed
many Clojure programmers were former Java programmers.

I'm also working on a cross-language compiler and have a question about TCO,
specifically tail recursion. Currently my language compiles a tail-recursed
function's body into a while loop. Don't Scala and Clojure do the same, except
using the actual bytecode?

~~~
prog
> I'm also working on a cross-language compiler and have a question about TCO,
> specifically tail recursion. Currently my language compiles a tail-recursed
> function's body into a while loop. Don't Scala and Clojure do the same,
> except using the actual bytecode?

I know Scala does it at function level (i.e. the function calls itself at tail
position). I think Clojure have a 'recur' keyword to similar effect. The issue
with JVM is that if f() calls g() at tail position and g() calls f() at tail
position, it can't be optimized away (at least not without an undue amount of
work so the advantage is lost). Clojure uses a trampoline[1] based approach to
handle such a situation. I think Scala 2.8 also adds support for that. This
works well with constant space, the only issue is that its a performance hit
as its not done by the VM.

[1] [http://richhickey.github.com/clojure/clojure.core-
api.html#c...](http://richhickey.github.com/clojure/clojure.core-
api.html#clojure.core/trampoline)

~~~
dfox
compiling self-recursive function into loop catches many cases of tail
recursion but certainly not all. Real TCO requires some support from VM to be
efficient (if you don't care about efficiency it is possible to fake it with
exceptions).

------
mdon
Kind of funny that the only negative listed for C# is "(it) hails from the
evil Northwest."

A backhanded way of saying C# is really nice.

~~~
pwpwp
You are right. C# is a cool language, especially v4.0, and originally, I
wanted to add that to the post.

------
speek
This is inspiring to me, as a young computer scientist. Maybe I'll go off to
create my own language and OS.

~~~
nostrademons
Be aware that it is a giant rathole. If you're looking for something
commercially viable that might actually make a difference in the world, you're
better off in a field like information retrieval, machine learning, geo, or
image/audio processing.

There seems to be a siren's call of language/OS/editor development, though. If
you really can't resist it, go do it. At the very least, you'll learn a lot,
and it beats CRUDscreen Web2.0 apps as a mental exercise. But other fields of
CS are much, much, more useful.

~~~
FraaJad
In your opinion, what languages have the best return on investment when it
comes to IR, ML and related data sciences?

~~~
nostrademons
In my opinion, languages don't matter as much as the underlying algorithms.
Learn the math, and then you can implement them in any language.

...but if you had to choose, I'd say to learn Python so you can prototype
quickly, and then C++ so you can make it run fast in production. The two also
have the nice benefit of working quite well together, so that you can push
things into the C++ layer as you understand them better, and keep
experimenting by gluing together those libraries with Python.

~~~
dedward
And we used to say prototype in C++ and then re-implement in C to make it fast
in production.

The math and the algorithms are important - but one shouldn't dismiss a
fundamental understanding of the lower levels of the system - even though
they'll change over time and you probably won't have to "go there". Real-world
software runs on real-world systems, and there is no reason for a budding
computer scientist to deprive himself of at least a cursory understanding of
how things work underneath - you never know when he'll want to break out of
the toolset Vendor X provides him and do something radical and new (like
implement something in hardware, or recognizing there is some feature there he
can use to massive real-world benefit)

------
gruseom
Well now, this gem was unexpected:

 _you must create a programming language, or be enslav'd by another man's._

William Blake allusion FTW!

Nothing at all is lost.

~~~
arethuza
The original is:

"I must Create a System, or be enslav'd by another Man's; I will not Reason
and Compare: my business is to Create"

From "Jerusalem The Emanation of The Giant Albion":

[http://www.blakearchive.org/exist/blake/archive/work.xq?work...](http://www.blakearchive.org/exist/blake/archive/work.xq?workid=jerusalem&java=no)

------
kabdib
Write the debugger first.

You'll need it anyway. And it will provide /much/ insight into your mistakes.

------
thunk
It's odd that he dismisses most existing Lisps, then advises the reader to
create their own. I wasn't sure if he meant it pedagogically or pragmatically
or both.

~~~
pwpwp
Good question. I think that the crux is that if you're enthusiastic about PLs,
you have to create your own or be enslaved by another man's. That's my feeling
at least. And on the way to creating your own PL, you'll also learn to
appreciate the existing PLs and implementations better, and learn to live with
them, warts and all.

~~~
thunk
Gotcha. And an influx of new and experimental Lisps is always welcome.

~~~
pwpwp
Right on :)

------
teaspoon
Question from someone who maybe doesn't spend enough time examining PLs: How
is JavaScript "like assembler with hashtables"? What "messed-up-ness" are
Python and Ruby legendary for?

~~~
pwpwp
First, you should take the whole post with more than a grain of salt. ;)

Re JavaScript, I'm referring to the lowlevel nature of many of its constructs:

\- its impoverished way to pass parameters (i.e. there are no keyword
parameters; you don't get an error if you pass too many or too few arguments)

\- its impoverished exception handling (i.e. you can't catch exceptions of a
specified type)

\- its impoverished standard library and built-in data structures

\- its lowlevel and complicated OOP system

There's more, see [http://pwpwp.blogspot.com/2009/08/awesome-helma-and-
lacking-...](http://pwpwp.blogspot.com/2009/08/awesome-helma-and-lacking-
javascript.html)

Re Python and Ruby, I'm mostly referring to the fact that both languages
started out with broken lexical scoping, and had to change their scoping rules
repeatedly, which is a huge red warning sign. Additionally, it seems very hard
to implement both languages so that they run fast, another factor. Ruby also
has an array of different kinds of first-class functions (blocks, procs,
lambdas, I lost track), with different capabilities and restrictions, which is
a design failure to me. That said, I think they're acceptable languages, even
if they force you to memorize a lot of irrelevant stuff.

~~~
nostrademons
JavaScript has a certain elegance to the minimalism, though, much like Scheme:

\- You can emulate keyword parameters by passing an 'options' dict, and you
can emulate defaults by 'var myOpt = options.myOpt || default". You can also
define a function, like $.extend, to do this for you.

\- You can catch exceptions of a specified type by checking the type and
rethrowing if it's not appropriate. And you can define a function to do this
for you:

    
    
      function try_catch_if(exc_type, body, exc_handler) {
        try {
          body();
        } catch (e) {
          if (e instanceof exc_type) {
            exc_handler();
          } else {
            throw e;
          }
        }
      }
    

\- You can define your own standard library a la JQuery or YUI, or even modify
the built-in one a la Prototype (though I don't recommend this). And the
built-in data structures aren't all that bad.

\- You can build whatever OOP system you want on top of prototypes, and many
libraries do just that. (In this respect, it's quite similar to Scheme, where
every programmer starts by defining his own incompatible object system).

Most of the sucky parts of JavaScript come from it _introducing_ things that
weren't really thought through, eg. the 'this' keyword nonsense is ridiculous,
as is the lack of argument-checking by default.

~~~
sreque
You can build your own keyword-argument passing style, exception handling,
standard library, and OOP system with assembly as well. Most of would rather
start with a language that got these features right in the first place, rather
than defending languages that didn't.

------
j_baker
This is a decently thought-out article, but it's important to remember that
programming language design is as much an art as any other form of programming
if not moreso.

------
aerique
Funny, I don't understand the only one that sort of applies to me: "Syntax is
the Maya of programming".

~~~
rntz
<http://en.wikipedia.org/wiki/Maya_(illusion)>

I'm not sure which part you didn't understand; this is my best guess. I
believe the author is trying to say that syntax is a superficial appearance,
and not relevant to - indeed, a distraction from - understanding the true
beauty or ugliness, utility or disutility, of the concepts embodied in a
language.

~~~
aerique
At first I didn't understand the whole paragraph (I had just woken up :-) )
and then it was just the Maya part. I didn't understand his use of Maya.

Thanks for the explanation. It seems the author and I have got a similar view
on syntax (how can we not since we both seems to admire Alan Perlis!).

