views:

1004

answers:

16

What is the real benefit of creating a new programming language? It is highly unlikely that you are going to actually use it.

In short, how will the process of creating a new language make you a better programmer?

+31  A: 

You will understand the decisions behind language design and garner a better overall understanding of the compromises made between readability, performance, and reliability.

Your familiarity with concepts such as recursion, closures, garbage collection, reference management, typing, data structures and how these things actually work will increase. Most programmers will utilize resources and language features better.

Similar to the way we learn new ways to code solutions when we use other languages, when we write our own languages, we explore new ways to create solutions. See Metaprogramming. Contrary to the what the question suggests, Domain Specific Languages are used in many environments.

If you're writing a compiler, you'll learn more about how computers work than you ever did before. (Depending on your goal, perhaps more than you intended to learn)

When I wrote my own sort routines in school, even re-implementations of good ones, it really drove home some of the weaknesses of some of the algorithms.

In short, there's an order of magnitude of difference in a programmer who knows how to use tools, and a programmer who knows how to make tools.

altCognito
i.e. you'll discover it's not as easy as it looked in school.
Paul Tomblin
"Possibly more than you ever wanted to know" :) Not sure about that :P
Aiden Bell
I liked saying - "theory, simulation and practice are very different things".
sybreon
More: that could be really cool. I don't think the language is just a Tool, actually I really enjoy programing. When I start something like that (create a lang or compiler) peaple come to me and ask: Why your are doing it? Are you trying to re-invent the wheel?Well, sometimes you have to see by yourself. Even that is just for fun.
Eduardo Cobuci
@Eduardo ... I get the "why re-invent the wheel" thing alot ... If we didn't then we would still be wooden-spoke carts! That saying is the sign of someone lacking a logical argument. Wheels are round but come in many forms due to reinvention. What is wrong with saying ... this is different, this is cool, im doing it?
Aiden Bell
@Eduardo - And the best mistakes are the ones you learn yourself. Learning being the key :) I agree.
Aiden Bell
"Contrary to the what the question suggests..." i was talking about a general purpose language, not a DSL.
Pranav
@Pranav , Java and Erlang are both general purpose. Both highly different.
Aiden Bell
@Pranav True, but I'd consider arguing that creating a _good_ DSL is requires even MORE forethought and knowledge of language theory than just a general purpose language. Perhaps not, I'm just thinking that DSLs tend to have very interesting semantics and rules because well, they are so specific to the problem at hand :)
altCognito
+1  A: 

Writing a compiler or interpreter requires a very firm understanding in computer science theory. And if you're compiling to machine code instead of to another language, it requires a firm understanding in hardware design as well.

In addition to that, knowing how to design a compiler means you will have a better understanding of languages in general, and the languages you work with specifically. You will have a better appreciation for syntax and trade-offs the language designers took when they wrote their specification.

It's not that writing compilers makes you a better programmer. It's the deep understanding of language theory and compiler design that makes you better.

Welbog
-1: You don't necessarily need to know anything about hardware to write a compiler / interpreter. I agree that writing one furthers ones education though :-)
Jon Cage
@Jon Cage: I take it you're referring to languages that compile to other languages? Fair enough.
Welbog
The original was not worth a -1 IMHO. But regardless whether the compiler targets hardware or some sort of virtual byte code like LLVM, Java bytecode, MSIL just to name a few, you will need to have a 'firm understanding' of the target to write a backend. In one case its hardware, in another case its a 'virtual hardware' if you will. A lot of details to know either way.
Brian Ensink
A: 

Mostly you do this for fun or to broaden your comprehension of a subject.

I disagree that creating new language influences performance - performance of what? IMHO execution speed should not depend on the language constructs but what the language is translated to - which is something different: like creating a syntax for a language and writting a compiler/virtual machine for it.

Marcin Cylke
+2  A: 

For the same reason that taking a Compiler Construction course at university will benefit you even if you never write a single compiler in your whole life. It's a look under the hood, if you may.

Stefan Thyberg
+1  A: 

In addition to what altCognito said, which is a theoretical/academic perspective, some highly specialized languages are created to solve specific problems efficiently when existing "general-purpose" languages are either extremely inefficient for your task or there just isn't an easy-to-use existing alternative.

Granted, that such cases tend to be rare and if your first instinct on encountering a problem is "I need a new language for this.", then it is most likely you're missing something. There needs to be a fairly substantial gap in "available" tech and and your needs to warrant such an undertaking.

Adnan
+12  A: 

I can speak from experience here ...

Fun, Domain specific problem solving, Complexity in context

I love creating new languages for fun, and for tackling domain specific problems. A very simple example might be Wikipedia markup or something as complex as Erlang which specializes in concurrent processing.

Many general purpose languages are similar, because they are general purpose. Sometimes you need a more accurate abstraction of the mechanics of the problem you are solving. Another example would be the M4 macro language.

Remember a language is not magic, it is just a collection of defined grammatical structures with implied semantics. SQL is a good example of a language for a purpose, with that purpose defined in it's syntax and semantics.

Learning how languages work, what makes a language parsable, what makes semantics sensible and the implementation of this, I think can make you a better programmer.

compilers embody alot of theory that underpins computer science:

Translation, abstraction, interpretation, data structures, state .... the list goes on. Learning these things will make you understand the implications of your program and what goes on under the hood. You can of course learn things independently but compilers are a great context to learn complex topics such as DFA/NDFA automata, stack-based parsers, abstract syntax trees ....

compilers are beautiful machines I think :)

Aiden Bell
+3  A: 

Creating Domain Specific Languages is very valuable. Instead of thinking only about general purpose languages, consider creating so-called "little languages" that clearly express abstractions in your project.

For example, in a recent project I decided to use a Command Pattern to drive a Service Layer. I found some repetition in my command code, so I wrote a little compiler that accepts a simple language that expresses commands and emits command implementations in the "underlying" language.

Greg Mattes
+2  A: 

I think there are really two conceptually different answers to this. First, you gain an understanding of how compilers transform your code into executable code. This can help you make better decisions about how to structure your code to optimize (or allow it to be optimized) better. If, for instance, you knew that a certain construct would prohibit the compiler from inlining a code block or unrolling a loop, then you could avoid that if performance became a real concern.

Second, all current languages were invented (or derived) at some point in history. For each one of these, the likelihood that it would actually be used was potentially small, yet here they are. They all found their reason for being in the fact that someone wanted to do something that wasn't possible or easy to do in an existing language and decided to do something about it. Laziness (or the desire to let the computer do the work for you) is the mother of invention.

tvanfosson
+1  A: 

how will the process of creating a new language make you a better programmer?

You're right, you may or may not use the language, but at the least the experience you will gain from doing it will benefit you to understand the implementation of programming languages and of certain things that you will be able to apply to future computation problems that you run into.

TStamper
+5  A: 

I think Jeff Attwood answers this well in this Coding Horror post -- though he's talking about a more general issue (why create any new library, framework, etc, when other artifacts in the same design space already exist), I suspect that exactly said broader viewpoint gives him a different and interesting perspective.

Alex Martelli
+1 Great post by Jeff.
Pranav
+2  A: 

Just for fun... and then you'll realize that you cannot make anything better than all the languages that you thought they sucked xD (so you stop complaining about them).

fortran
"so you stop complaining about them" - not really :)
Pranav
I think creating your own language is sometimes like trying to make a perfect-suit ... but you are not a tailor; But you will get that suit.
Aiden Bell
A: 

Because a talking frog is pretty neat.

plinth
A: 

I for one don't care about how compilers work, don't care about learning new languages, and don't care about using scripting languages like perl and javascript. I'm much more interested in the ways big programs are constructed (or should be constructed). There are still no good solutions for making LARGE software as easy to use as prototyped code. Programming languages are not helping with that. They solve trivial problems like sorting and memory deallocation, and leave you struggling alone with problems that really matter (that keep you or your firm from losing money).

AareP
+3  A: 
Norman Ramsey
"if you give your language a static type system and you then prove that a well-type program is guaranteed to be memory-safe" Wow! i have no idea how I would approach this problem. Any books you can suggest? Thanks.
Pranav
@Pranav: I've edited my answer to link to a couple of good books.
Norman Ramsey
A: 

I want a managed language that permits tinkering with its internals as standard practice. Kind of like Ruby's duck punching on a wider scale.

I should, as the client of a library, be able to swap out library functions that don't do what I want.

That's what drives me crazy with .NET. There are bugs in the framework Microsoft will not fix and thanks to GAC signing I cannot. And even if it were not for GAC signing, hotpatching a global library is a bad idea (might break some other application).

Joshua
+3  A: 

Multiple reasons:

  • bragging rights
  • economic incentives
  • extreme boredom
  • dissatisfaction with the hundreds of existing languages
  • untreated insanity
  • desire to implement language that facilitates new design concepts (like languages that make design patterns more straightforward to incorporate)
  • other reasons, perhaps
Garrett
economic incentives?? like what?
Pranav
+1 Extreme Boredom
Dario
For me it's the dissatisfaction (or maybe I'm just insane).
Zifre
@Pranav: Presumably, Sun created Java for commercial gain. Microsoft created the .net platform (I realize that's not a language per se) for commercial gain as well. How the creation of a language confers economic gain depends on the situation.
Garrett