Hacker News Reader

Hacker News

Comment by carapace | Hacker News Reader

Parent Full thread

carapace

FWIW, Frank Atanassow, "Some words of advice on language design"

http://lambda-the-ultimate.org/node/687#comment-18074

> Before you go off inventing new programming languages, please ask yourself these questions:

> 1. What problem does this language solve? How can I make it precise?

> 2. How can I show it solves this problem? How can I make it precise?

> 3. Is there another solution? Do other languages solve this problem? How? What are the advantages of my solution? of their solution? What are the disadvantages of my solution? of their solution?

> 4. How can I show that my solution cannot be expressed in some other language? That is, what is the unique property of my language which is lacking in others which enables a solution?

> 5. What parts of my language are essential to that unique property?

View on HN

This post has always irked me. It reads as straight up gate-keeping, especially when what follows these questions are a litany of negativity ("go home" "no one cares" "you are kidding yourself" and "you are wrong."). This is especially frustrating as the author later admits he himself cannot answer these questions honestly and yet persists in designing his own language. He certainly hasn't "gone home" so why should anyone else?

Here's my advice: Want to invent a new programming language? Dive in. It doesn't matter if someone invented it before. It doesn't matter if you can't formalize it in mathematical notation at the outset (or ever). It doesn't matter if your language could be implemented in a library of another language. It doesn't matter if you can't articulate the precise benefits of your language. It doesn't matter if there are any benefits at all. It doesn't matter if you can't answer a single of the above questions. Have at it. You are guaranteed to a) learn a lot, and b) have fun. Maybe you do something completely derivative and that's fine. Maybe no one will appreciate what you do and that's fine. Maybe it will go nowhere, maybe it will never compile. Maybe you will be the only user. Maybe some guy on the internet will tell you to go home and no one cares. So what?

I can see both points of view. Of course, if you enjoy making a new language do it, lots will be learned and you can always remember back to that language you made.

On the other hand, if your intention is to make a new language that does something distinctly different and for some purposes better, then answering those questions will save you from spending time on things that don't deeply matter. Now if we're not in a circle of language design researchers, things that matter can be syntax.

I can see what's being attempted and I appreciate it. I myself have wanted a kind of 'referential transparency' when it comes to lazy values in an otherwise strict language. Or in this case async ones executing concurrently. You can use the result of the expression without the ceremony. I'm not particular to the syntax and would have liked to see it added to a popular language. Making a whole new language is scratching an itch, which is also great for what it is.

I wish I had been given this advice many years ago, but I got some negativity that trigger a cascade of depression ( https://news.ycombinator.com/item?id=226480 ). I was very young, and I didn't ask for feedback. It was not great waking up to a HN post. In a way, I was not prepared to accept honest criticism for something that I was building.

Granted, it was a bad idea to build a non-tech business on a new programming language in a region which could not hire people to fix the language, so it was the right call to give into the depression and move away from my language. However, it probably took me a decade to try again recently.

When I reflect on history and how things could have unfolded, I realize I was onto something and I was at the wrong place to exploit my ideas. As an example, if I had persisted, then my language could have been what Hack & HHVM is today. However, I was in the mid-west operating on my own.

This time, I'm swinging hard with my new language, and I hope to redefine a portion of the computing landscape. Or, at least, improve it within my myopic universe. I haven't published much, but I have a novel language at the moment which is enabling me to do things that are hard to imagine.

I don't see it that way. There are thousands of languages now. It's wise counsel to people (like me!) who hope to introduce a language that actually gets used. If you can't "check those boxes" on this handy checklist, well, maybe you gotta spend more time at the drawing board.

For those of us that are going to do it anyway, with no expectation of becoming popular and widely-used, I would treat it a stimulating challenge rather than a slammed door.

I think there's something to be said for going through the exercise even if the answer to every question actually does indicate the language shouldn't be written. What happens when you come up with an idea that actually does have a place? It's better to start with the background of having done it before than try to create a dream project with no experience in making some toys.

I think this is good advice under one assumption: your intent is to create a practical language that other people will adopt for real products.

Reasons you might make a language that isn't bound by the above questions:

- For learning

- For fun

- To explore a concept

- For sheer novelty

- To make a point

"for learning" + "to explore a concept"

-> to understand why things are (or were) done a certain way

-> to test the boundaries of what's possible

Surely no one thinks that current languages are the most efficient or effective possible way of doing things? That we've even come close to enumerating all useful methods of expressing program execution? (Take a look at what Racket is doing for example.)

- To have a language you like, even if nobody else in the world cares for it

To put an even finer point on it:

- to indulge in syntax design

The author of this advice explicitly calls out syntax design as pointless. As if Java, Lisp, Python, Haskell are the end-all of syntax design. Haskell in particular is notorious for indulgent syntax design.

One thing I've noticed about my students (undergrads) is the first thing they are interested in playing with when it comes to language design is syntax. They have ideas about syntax they want to try out, and it gets them interested in parser design. Probably because it's the most tangible thing they have access to and experience with. When they try out their syntax ideas it opens up new pathways for them and they eventually move on to greener pastures.

But the idea that syntax is done and solved and there is no more room there for innovation is completely foreign to me. What about syntax in other (natural) languages? Languages written from left to right? Top to bottom? Languages with a non-roman character set? What about syntax with emojis? There are entire programming languages written with emojis now (https://esolangs.org/wiki/Emoji). Did the author of this consider them in 2006?

Don't forget languages written in the form of a bitmap :)

https://en.wikipedia.org/wiki/Esoteric_programming_language#...

You're preaching to the choir my friend. (^_^)

Here's mine: https://joypy.osdn.io

> Thun is dialect of Joy written in Python.

> Joy is a programming language created by Manfred von Thun that is easy to use and understand and has many other nice properties. This Python package implements an interpreter for a dialect of Joy that attempts to stay very close to the spirit of Joy but does not precisely match the behaviour of the original version(s) written in C. The main difference between Thun and the originals, other than being written in Python, is that it works by the “Continuation-Passing Style”.

All very good questions. However there is missing one question, that perhaps overrides them all:

- By doing this will I gain a deeper appreciation of the art? Will it help others to see this too?

Designing a good language is very very hard, harder maybe than a typeface, or a cathedral. But the rewards, in the terms of that question, can be inestimable.

There is a lot of truth to this. I'm in the process of designing a language with integrated SQL where I "code-generate" the in-memory tables, and beyond appreciating language I also appreciate relational tables for what they do.

What I am finding really nice is that I don't even have maps in my language since I can just use tables and get the benefits of maps along with indexing and all the fancy stuff.

I don't know if I wholly agree.

These are good questions with regards to language design.

But for some people there is a massive learning experience that comes from designing and implementing a programming language and it's compiler even if it never becomes a successful or popular language.

I feel this learning experience is has plenty of value even if the end resulting language does not.

Anders Heljiberg wrote Turbo Pascal, J++, and Delphi, before moving on to things more widely accepted as successful like C# and Typescript. Yes Turbo Pascal and Delphi had some large followings

Likely his experience from previous programming languages allowed to him be successful later.

Reply on news.ycombinator.com