I think it's a great question coming from a 15 year old. That's a kid who wants to know and do everything. He'll go places.

It is a pretty good question - I was involved on a forum about operating system development and we would get so many people coming with no experience and asking questions in exactly the opposite way.

Pretty much people would say, "I know [VB6|Python|Javascript|HTML] and I want to make an OS. Tell me how"... Like compiler design, building a kernel is one of the most complicated types programming, and none of them had anywhere near the coding skill or experience to do it (or the patience usually - coding an OS for the most part is far less exciting than it sounds - the breakthroughs are great but they usually take intense debugging and reading great deals of the Intel and AMD manuals).

This guy has actually done some research (including reading books!), which was unheard of from most newbies there, so he's doing far better. But if he doesn't know how libraries are made, he should get some experience doing that in C or C++, and will need a good grasp of Assembler if he's going to do code generation.

NAND to Tetris

http://www1.idc.ac.il/tecs/

Watch this video:

http://video.google.com/videoplay?docid=7654043762021156507#

Does the idea of a self-hosting language implementation ever stop seeming slightly magical?

Eh, you work on one for long enough and you start to take it for granted.

Yeah it does, until you realize that most of our infrastructure is self-hosting. What I mean by this is that we use certain tools such as lathes, to make better lathes, which in turn produce better lathes.

Barely anyone knows how to make a lathe from scratch. A lathe might not be a particularly good example but if you look at society as a whole you can see that a lot of our infrastructure depends on existing infrastructure to make improvements, and that we don't have documents to show how to go from subsistence farming to modern civilization as a bunch of things that we used to need can no longer be made.

IIRC, there is an 'open source' project to create this so that countries can bootstrap themselves out of their developmental quandaries. The idea is that you can build modern society from a few simple machines you can make by hand.

Self-hosting is the nature of the universe, it's only via consumerism that we find this processing unnatural.

think about how a meta-circular virtual maschine works and the self-hosting compiler gest mutch easier.

The better (and maybe more interesting) question would be is why people create new languages, i.e. what aspects of existing languages bugged them and/or how do they discover deficiencies which motivate them to create a new language.

Your looking at a new or ill developed paradigm and think you have an interesting take on it. Maybe you look at the current languages and it really does fit your mental model of how you want to solve problems.

It could also be that they just want to learn more about how what they work with functions. I have a hobby operating system that I'm working on (that doesn't do much of anything at the moment :), but I'm not creating it because I think other OS's are deficient or to fix something that bugs me. I just want to better understand how an OS works at the lowest levels and I learn best by experimenting.

For me it was a big case of Not Invented Here syndrome that caused me to make my own compilers and languages. It is a great way to learn deep stuff about how languages work, and helps me debug issues that others can't fix.

As someone who has to endure the results of NIH, I want to say that such thinking is a poison to the industry.

I wish that, if someone is overcome by the vapors of the NIH disease, such a person would confine their reinvention of the wheel to their personal time and not introduce such silliness to the workplace.

Of course, I wish for lots of things.

I got the impression from bartwe's post that the NIH symptoms were confined to personal/learning time.

Issues such as?

for example: C has a bunch of undefined expressions which give you different results on different compilers (as an example, j = i++ + ++i;)

Now, this makes perfect sense if you understand the concept of sequence points, but you wouldnt see that explanation in most books.

hmm... j = i++ + ++i; ....

To me, it seems like that would be evaluated by operator precedence...

++ has a higher precedence than +

So let i=1. The expression then becomes:

  j = i++ + ++i;
  j = {1}++ + ++{1};
  j = 1 + 2; OR, j = 1 + 3;

Aha. And that's the undefined behavior.

Ew. That seems like the type of problem which shouldn't have to be debugged, because the code shouldn't have been written like that to begin with.

Heck, it seems like the compiler shouldn't even allow that code to compile in the first place... But I guess there are technical problems with disallowing that? (Not the least of which is, it would break existing code.)

The issue comes from some vagueness in the wording from the C standard. The expression is valid from a literal interpretation of the rules, but to eliminate it would require a much more convoluted set of rules. Remember that C historically was a single-pass compiler ...

And if you want to get even funkier, try this in other languages (python yields 2, bash yields 4)

    $ python -V
    Python 2.6.1

    $ python -c 'x=1;y=x++ + ++x; print y'
    2

    $ x=1; echo $((x++ + ++x))
    4

For those that didn't understand, my point with the python example was to emphasize that the same expression (visually) can have different meanings in different languages, and that the parse rules can be different. I am aware that python doesn't parse it in the way that the expression appears to a C programmer :)

Concerning python's lack of pre and post increment, the decision was made primarily because there are a lot of confusing situations, such as the aforementioned, with the increment and decrement operators. However, the decision to allow x++x to be valid, and parsed as x + (+ x) = x + x, is itself terribly confusing and germane to the original discussion

Python is not doing what you expect here, it sees that as:

    y = x + (+(+(+(+x))))

You appear to not understand how Python works. Python has no increment operators; your statement is equivalent to "x + ++++x" or "x + x", using the unary + operator.

I think the simplest answer is that the creation of new programming languages is intrinsically thrilling to someone who is fascinated by computation. A friend once asked "Yeah, but how does a computer know that 5 + 2 is 7?" and to answer the question we built a 4 bit adder out of basic logic gates. We built it because it was exciting to do so.

For most modern languages, you can find a document or interview explaining the motivation.

For example, ruby: http://linuxdevcenter.com/pub/a/linux/2001/11/29/ruby.html

(In this interview he uses the magical phrase "principle of least surprise")

I'm surprised that no one suggested "Structure and Interpretation of Computer Programs". (The "Little Lisper" suggestion is reasonable if SICP didn't exist.)

The concept of Assembly language is not that hard, provided one starts with simpler processors, simple said it's mapping processor codes to 3 letter instructions. Processors nowadays are way more complicated than the ones of yesteryear, my tip is when one really wants to understand is to start with a beast like the 6502, it's a straight forward processor and there is tons of documentation for it, also there are many emulators of the machines that used the 6502/6510. In the process you learn concepts like memory mapped graphics and IO. You can use that knowledge to explore and build on modern day processor concepts like segmented, protected and virtual memory and things like OS/User separation or floating point processing. Compilers are mainly programs that translate higher level languages to Assembly language. A lot of today's languages like Python, Perl or Ruby are not compiled but interpret and bring yet other advanced language concepts like automatic memory allocation and garbage disposal, but also higher up algorithms like sets, dictionaries and collections etc... Start in the recent past like the 80's and work your knowledge towards the present, there is not much use to go further back than the 80's because before that era there were not that many standard solutions for these concepts, only historians want to know about things like mercury delay line memory, crt scanline memory, core memory, programming panels and so on.

And not a single reference to Programming Language Pragmatics.

PLP is pretty good, but I found it didn't live up to the reviews and recommendations. The chapter at the beginning on parsing just flew by too fast to be genuinely useful. The rest of it seemed to follow that trend of breadth rather than depth.

That being said, I found EOPL 3ed also didn't live up to it's reputation. I don't really know what I'm looking for in an introductory PL text, something that could bridge the divide between the end of SICP and the more advanced, serious PL stuff. I don't know if such a text exists.

Have you looked at Programming Languages: Application and Interpretation [1] by Krishnamurthi? It doesn't address your concern about parsing---it's explicitly excluded from the book---but I found it to be a reasonable follow-on to SICP and a relatively enjoyable read to boot.

[1] http://www.cs.brown.edu/~sk/Publications/Books/ProgLangs/

PLAI is on my short list for new reading, but thanks, that's good to know re: parsing.

I actually think that skipping parsing altogether, the way a lot of Lispy texts do is the way to go for intro PL stuff, because you can get to interesting stuff much faster.

My gripe about PLP is that after deciding to cover parsing and scanning, he goes too fast. I might have been happier if he'd skipped it altogether.

I wish my list for new reading was short. Amazon wishlist is near 1000 books now :(

The older EOPLs are much longer then the newer ones. I've found that the 1st edition requires less sophistication than the 3rd and spends more time explaining things. You might want to take a look at it.

There's also "design concepts in programming languages".

Thanks, I'll check them out.

I found all the interesting bits are in the accompanying CD rather than in the book itself, which is far too shallow (IMO). Having to dig out the CD to read the somewhat interesting bits is then a chore.

Two words. Lex and Yacc. These are freely available tools that should (if nothing else) atleast give you solid launching platform into writing your own language.