Ask HN: What would your ideal programming language be like?

[appcypher]

I'm a language designer. I know I love writing compilers and interpreters, but I always had this constant problem of fitting the languages I create into a niche. I always aim for the ultimate swiss-knife kind of language or I always end up doing that. However, many people have told me, I'm wasting my time creating general-purpose languages, instead I should focus on a niche. Now I'm looking for the niche.

So I'm directing this question to you coders, old and young. What do you think a new programming language should have and not be considered a waste of time? What features or environment do expect from a new programming language? Why do you think current languages cannot have those features? In short, what areas do you think current languages suck in and would be a good starting point for a new programming language? Or should I just give up on language design and compilers and get a life. Bjarne seems to think that.

It helps if you can describe your ideal programming language in respect to your field and why you think it will work there.

Thanks.

[JamesLeonis]

For what it's worth, Clojure is my favorite language. One of it's core principles is a symbiotic relationship with it's host platform. Today it compiles to Java, Javascript, and C# runtimes. There's also a growing native runtime for C[1].

What draws me to Clojure is the sense of "conversation" I have with my runtime, state, and the code I'm writing. I start with some data, and transform it slowly with added functions until I arrive at my desired result. I often have a commented out "scratchpad" in my code left over from those development conversations[2]. I honestly wish more programmers experienced this phenomenon, and I wish it was in more languages/runtimes.

1: https://github.com/schani/clojurec

2: https://github.com/jamesleonis/bencode-cljc/blob/master/src/...

[borplk]

I think the next game-changing evolution in programming languages is moving beyond plaintext.

Our basic building blocks of programming has not changed essentially since the beginning of programming.

We still treat programs as nothing but a bunch of files and folders edited with the same tools that writers use to write romance novels (yeah yeah "intellisense" is not so intelli at the end of the day).

We don't create beautiful images by writing RGB values in a text editor. We shouldn't be creating highly complex software systems with them either.

We need model based editing environments that will allow us to have a much richer set of software building blocks.

We have to allow software to be more than just characters in files. Software "source" is not a book. It's the blueprint for a system that has metadata and constraints attached to it. It can't comfortably and forever exist in a flat plaintext structure for human consumption.

If you are interested go dig up my old comments I have written more elaborate rants about it before.

And yes I'm ready for the inevitable and customary "NO IT AINT GON WORK WE TRIED BEFORE AND IT AINT WORTH TRYIN EVER EVER AGAIN" replies.

Also relevant:

https://www.reddit.com/r/nosyntax/

(I actually somewhat accidentally and indirectly caused the creation of the subreddit as a result of a discussion here on HN before)

https://isomorf.io/

https://en.wikipedia.org/wiki/Structure_editor

https://en.wikipedia.org/wiki/Intentional_programming

https://www.youtube.com/watch?v=PUv66718DII

[gt_]

“We’ve tried it before” is a poor excuse, of course. The theory angle holds both some better excuses for not getting our hopes up and possibly some clues on how to get there.

We’ve got to avoid taking text for granted. Basically put, the adaptability, precision, fastidiousness, accessibility, etc. of the written word makes the modern world possible. Phonetic type is far and wide the greatest communication interface known to man.

I work with a lot of node-based softwares doing CGI and post-production work. A few of the daily softwares I use have a small editor in the bottom corner of the GUI. The node interfaces are very useful and hard to live without. I agree that, when doing visually-based work, it feels very off to have to stop what I’m doing and so scripting. It feels like a vastly different mode of the mind. But, as I’ve gotten better at scripting, (still not great) I have noticed that when I have a visual idea with no implementation, it can be a good time to start building it with a script. I have roughed put some 3D scenes in scripts from the start and found this to be a totally different experience than the stop and change modes issue. I can’t argue for it’s productivity level, and I don’t know what the value of this observation is, but I honestly enjoy working this way when I do it. It’s as if my visual sensory system is relaxed and my imagination is utilized more. The ideas are parameterized rather than experienced. This does not happen with node interfaces, which actually introduce an extra visual experience. I am just babbling at this point, but these observations feel relevant. I do not, however, know what kinds of conclusions to draw from them.

[AnimalMuppet]

I don't think you're going to design a great language that way. I think great languages get designed when you discover that with existing languages, it's difficult to do things that you want to do. If you don't know why you want to create a new language, it's not likely to scratch other peoples' itches either. (However, asking others for their pain points is a reasonable substitute.)

That said, here's an idea or two:

Optional garbage collection. In a C++ context, if I create an object with new, it's not garbage collected - it goes away when you delete it. But if you create it with some other mechanism (new2?), then it's garbage-collected when no longer referenced. (The problem with this idea is that a garbage-collectable object can still be "live" while referenced from a non-garbage-collectable object, which could be difficult.)

Adjustable need for typing. Personally, I love static typing. I want the compiler to tell me when I'm being stupid; I don't want to find out at runtime. But some people want to prototype/experiment/play with dynamic typing (or, if you prefer, without static types). So you can set a flag to the compiler to tell it not check static types. Then, as the code solidifies, you change the flag to make it a warning if there is not a defined type for a variable, or if a type is used incorrectly. But in this mode, it's just a warning - the code will still run (and crash or whatever when it hits the problem). Finally, for production builds, there's a flag for compiling with full static type checking.

Note that these are just ideas. They aren't my pain points. I'm pretty happy with a mix of C++, Java, and Perl.

[rl3]

Here's some of my recent thoughts on this:

https://news.ycombinator.com/item?id=15481143

I feel that visual programming as it exits now is merely scratching the surface of possibilities. I want to watch my code come alive as I write it.

Granted, I realize this is as much of a tooling problem as it is one of language/compiler design. Then again, I tend to view the blurring of the two as inexorable in such a context.

>Or should I just give up on language design and compilers and get a life.

These don't have to be mutually exclusive. That said, prioritize yourself first.

[bovermyer]

My ideal language would consist of a single word: "do"

When this program is run, it automatically knows exactly what the user is trying to do, and re-arranges reality to achieve that goal.

[kleer001]

Heh, reminds me of my college buddy's futile search for infinite compression. He wanted to be able to compress any file down to a 0 or a 1.

[qbrass]

It optimizes out the part where you try to do anything.

[tytytytytytytyt]

> I'm a language designer. I know I love writing compilers and interpreters, but I always had this constant problem of fitting the languages I create into a niche.

Anything we can see, say on github?

> What do you think a new programming language should have and not be considered a waste of time?

Static typing, so I can refactor large codebases with less fear and have type safety.

> What features or environment do expect from a new programming language?

What could you add/change to make a new language different that existing languages?

[appcypher]

https://github.com/appcypher/astro

[krapp]

I am not a language designer, although I've been fascinated by it for a long time. I couldn't write a compiler to save my life. But I am on the internet and do have opinions, so here is a laundry list of features my ideal language would support, or things I think might be nice to have.

0) Sane package management. What do I mean by sane package management? See how NPM does it? Not that.

1) Metaprogramming - native support for adding grammars, extending the syntax, lexing, etc. These could be distributed as packages and included as dependencies, creating a language that could be extended and improved upon by the community. The core language would probably need to allow raw memory access, pointers, and control down to assembly. In my naive fantasy, it would be possible to, say, "import javascript" then use actual javascript, possibly within a namespace or scope. Or typescript. Or lua. But probably not C++, or any language that's a Lovecraftian incantation.

2) It would support a single, possibly typed JSON-like data structure, but without required quotes for strings (so like Lua tables in that regard) but with bracket notation for arrays. Assignment in general would use the colon and not = for consistency. Or maybe it would just be s-expressions, I don't know.

2.5) Zero indexed arrays, which are the only objectively correct way to index arrays. Whitespace agnostic. If it uses semicolons and braces, they will not be optional. None of this goto fail nonsense in my language thanks.

2.6) Except goto will be supported, because a language that doesn't support unstructured control flow is a babby language.

3) Javascript-style anonymous functions and lambdas, default arguments, function overloading and multiple return values.

4) Operators as types. Any legal variable could be defined as an operator, returned from or passed to a function, etc, and could be overloaded.

I leave the implementation as an exercise for the reader.

[stephen82]

When you are saying "Bjarne", I presume Bjarne Stroustrup of course.

Can you share a link where he mentions such thing? I have a great admiration of him and I would like to read or hear more about his personal concerns.

Thank you.

[appcypher]

http://cppcast.com/2017/05/bjarne-stroustrup/ A podcast. He mentions it at around 42:00.

[psyc]

It would be like "C with classes", with excellent generics, and a compiler that is smart enough to organize data into the most performant contiguous, tabular memory layout.

[telebone_man]

A language that everyone used would be great.

[sunstone]

No curly brackets. No semi-colons.

[billconan]

c++ is close to my ideal language.

what I hope it has is

1. dynamic reflection.

2. cross-platform package manager

3. more intuitive meta programming.