Ask HN: If you designed a new programming language, what would its features be?
71 comments
>could design the programming language [...], without any compromises,
That goal isn't possible because designing syntax to make certain tasks "easy & simple" inevitably means you're making some other task hard & complicated.
That's why there isn't a One True Programming Language to end all other languages because you can't design perfect syntax to handle everything from low-level embedded all the way up to 4GL and scripting.
So a language designer would have to know upfront what the technical compromises will be even when starting from scratch with a clean sheet for a brand new language.
That goal isn't possible because designing syntax to make certain tasks "easy & simple" inevitably means you're making some other task hard & complicated.
That's why there isn't a One True Programming Language to end all other languages because you can't design perfect syntax to handle everything from low-level embedded all the way up to 4GL and scripting.
So a language designer would have to know upfront what the technical compromises will be even when starting from scratch with a clean sheet for a brand new language.
[deleted]
[deleted]
I would like a language with real-world data types, with units and automatic unit conversion and checking. Along with Ada-style-ish value limitations (e.g. variable must be positive, or between 0 and 100, etc.)
> length i = 12 inches
> length h = 1 foot
> i * h
area 1 square_foot
> square_inches(ih)
area 144 square_inches
> hours(ih)
error: type mismatch
Time and money, as well (currency conversion not required)
> length i = 12 inches
> length h = 1 foot
> i * h
area 1 square_foot
> square_inches(ih)
area 144 square_inches
> hours(ih)
error: type mismatch
Time and money, as well (currency conversion not required)
You can already implement this in any language with strong typing, like C++ or Rust or OCaml or Haskell. I guess the syntax might be more verbose, so you would have to write inches(12) rather than 12 inches.
C++ has user defined literals, so you could write 12_inch.
The formal term for the Ada-ish constraints on acceptable values is dependent types.
Wait no, it's close but not as strong as dependent types. I was thinking of Agda.
* Types that can actually restrict values. I think Haskell does this, but you should be able to express something like "X is an integer whose value is always greater than 1" and have the compiler implicitly perform a check when you cast to X.
* Enumerated errors. Some part of the tooling should be able to tell me all the errors that a function could raise. I don't know why this isn't more common, but sometimes errors are not of the type that I would have expected for the failure, or I don't know what type the error might have (i.e. there isn't usually a stdlib error for an HTTP 503 in a client).
* Optional static typing or a "loose syntax mode". Even if they don't behave exactly the same, it would be great to be able to do rough prototyping and production-ready work in the same ecosystem. Imagine if Python and Go or Python and Rust used the same ecosystem, and libraries were usable in either. You prototype in the loose Python syntax, and tighten it up to the Rust syntax when you're happy with the prototype.
* Macros. I don't think any language is ever perfect, and macros give you a means to work around warts in the language. They're complicated to write and maintain, but I still think it's often better than dealing with the nasty side of a language.
* Enumerated errors. Some part of the tooling should be able to tell me all the errors that a function could raise. I don't know why this isn't more common, but sometimes errors are not of the type that I would have expected for the failure, or I don't know what type the error might have (i.e. there isn't usually a stdlib error for an HTTP 503 in a client).
* Optional static typing or a "loose syntax mode". Even if they don't behave exactly the same, it would be great to be able to do rough prototyping and production-ready work in the same ecosystem. Imagine if Python and Go or Python and Rust used the same ecosystem, and libraries were usable in either. You prototype in the loose Python syntax, and tighten it up to the Rust syntax when you're happy with the prototype.
* Macros. I don't think any language is ever perfect, and macros give you a means to work around warts in the language. They're complicated to write and maintain, but I still think it's often better than dealing with the nasty side of a language.
> Types that can actually restrict values
Do you mean run-time checks? If yes then all you need is a normal oop class with an `assert` in your constructor. If you mean compile-time checks then that's a much much harder problem.
> Enumerated errors
If you have sum types/enums then enumerated errors are just a normal enum. Like
Do you mean run-time checks? If yes then all you need is a normal oop class with an `assert` in your constructor. If you mean compile-time checks then that's a much much harder problem.
> Enumerated errors
If you have sum types/enums then enumerated errors are just a normal enum. Like
type err = FileDoesntExist | PermissionError | NoDiskSpace
type result = Ok file | Err errI believe he means compile-time checks. Th formal term for this is dependent types. Some languages offer it. Haskell is working on making it ergonomic. It's already quite ergonomic in Idris.
> Optional static typing or a "loose syntax mode".
This sounds like what TypeScript offers with the `any` type: you can use it to shut down the type system at a given point and then gradually replace loose types with stricter types (hence the phrase "gradually typed")
This sounds like what TypeScript offers with the `any` type: you can use it to shut down the type system at a given point and then gradually replace loose types with stricter types (hence the phrase "gradually typed")
> Enumerated errors. Some part of the tooling should be able to tell me all the errors that a function could raise.
I don't know if I'm missing the mark here, but aren't you describing Checked Exceptions?
I don't know if I'm missing the mark here, but aren't you describing Checked Exceptions?
Let's do one for everything, everyone, and all time. We'll call it E. For Everything/Everyone. And it's two letters ahead of C.
Because it's for everyone, it has to be idiot proof. It'll be strongly typed. It'll use curly brackets, not indentations. It'll give a build error when you do bad practice stuff like have functions that do too many things or name classes on anything that isn't a noun. It's 2021. It'll have AI that checks for bad practices, trained on Uncle Rob's Code Clean.
One of the distinguishing features will be plugins. You don't like the rules that E came in? Make your own!
Instead of writing binary searches, or setting up network functions and unit tests, everything will just be prebuilt. We have eQuery that simplifies everything.
Better yet, we can decentralise that so that everyone can share E code. You can do everything from padding to blockchain with a single import. epm will manage packages and dependencies for you!
What if you think E is too restrictive? Maybe you work best with weak typing. Or you think the dates should be yyyy-dd-mm format instead? Or that the prebuilt grey_500 should be gray_550. Then there's TypeFreE, an unopinionated version.
Apple doesn't support it? That's fine, just use E Native, which ports everything perfectly on all platforms.
Do you worry E is too powerful and may used for evil? That's okay, the whole thing is being maintained by the OpenE Foundation, whose goal is to make sure that E is usable by everyone but restricts access to those who they deem not evil.
Because it's for everyone, it has to be idiot proof. It'll be strongly typed. It'll use curly brackets, not indentations. It'll give a build error when you do bad practice stuff like have functions that do too many things or name classes on anything that isn't a noun. It's 2021. It'll have AI that checks for bad practices, trained on Uncle Rob's Code Clean.
One of the distinguishing features will be plugins. You don't like the rules that E came in? Make your own!
Instead of writing binary searches, or setting up network functions and unit tests, everything will just be prebuilt. We have eQuery that simplifies everything.
Better yet, we can decentralise that so that everyone can share E code. You can do everything from padding to blockchain with a single import. epm will manage packages and dependencies for you!
What if you think E is too restrictive? Maybe you work best with weak typing. Or you think the dates should be yyyy-dd-mm format instead? Or that the prebuilt grey_500 should be gray_550. Then there's TypeFreE, an unopinionated version.
Apple doesn't support it? That's fine, just use E Native, which ports everything perfectly on all platforms.
Do you worry E is too powerful and may used for evil? That's okay, the whole thing is being maintained by the OpenE Foundation, whose goal is to make sure that E is usable by everyone but restricts access to those who they deem not evil.
Make it small, simple and consistent - few features, simple syntax, and useful library. (Don't provide things as language features, put them in the library or not at all.)
Then don't add to it - avoid the "which python" problem. (Python does need any of the recent features, and few will use them, but they'll confuse many and add many bugs.)
Then don't add to it - avoid the "which python" problem. (Python does need any of the recent features, and few will use them, but they'll confuse many and add many bugs.)
Is that not Scheme? I don't know what libs it has, but surely that's only a matter of creating them.
Isn't scheme's 2to3 moment the R6RS schism?
Type system for primitive values that carries meaning. Meters shouldn't be added to feet, ID of one entity can't be used as ID of another etc.
I know some languages implement such features, but these aren't mainstream ones.
I know some languages implement such features, but these aren't mainstream ones.
This would be tremendously powerful if primitive “colors” automatically label (or poison) any data structures they are placed into, and one can guard against certain colors being used in specific places. And casting to override this requires specific keywords that can be caught in audits.
For instance, a password can never leak to logging or a client response. An unescaped user input can never leak to a client response unless explicitly casted - and user provided data from a database counts this way too!
For instance, a password can never leak to logging or a client response. An unescaped user input can never leak to a client response unless explicitly casted - and user provided data from a database counts this way too!
There are multiple C++ libraries for just that. Search "c++ units".
You can build such library in any language with operator overloading, but the point is, it's optional library. It isn't built into language, therefore randomly picked library just won't support it.
You can submit a paper to ISO WG21 concerning adoption of your favorite units library, but it won't ever be baked into the language, because it can be done as a library.
Meanwhile a randomly picked library can either roll its own solution or pick a suitable one. Presumably Boost Units is all but standard.
Meanwhile a randomly picked library can either roll its own solution or pick a suitable one. Presumably Boost Units is all but standard.
Third option: not use anything like that, because own solution is ugly and people dislike "unneeded" dependencies, especially Boost has a very split reputation.
I like the optional garbage collection of D, the fine-grained control over memory layout and metaprogramming abilities of Jai, the goroutines of Go, the content-based dependency management of Unison, and the memory safety and general ergonomics of Rust.
My ideal language would combine these in some way, but with some changes, e.g. garbage collection should be scoped instead of on/off and newtypes should be first-class.
It's difficult to have this much functionality without going overboard on complexity like C++ has done, so careful thought would need to be put into how to harmonize all these features and what compromises need to be made.
The most important thing would be to adopt an edition system like Rust has, not just for the language but also for the standard library. This would allow breaking changes to fix inevitable design mistakes.
My ideal language would combine these in some way, but with some changes, e.g. garbage collection should be scoped instead of on/off and newtypes should be first-class.
It's difficult to have this much functionality without going overboard on complexity like C++ has done, so careful thought would need to be put into how to harmonize all these features and what compromises need to be made.
The most important thing would be to adopt an edition system like Rust has, not just for the language but also for the standard library. This would allow breaking changes to fix inevitable design mistakes.
Something that would be used by 90% of the companies worldwide for both back end and front end and everything else so that new programmers have to learn just one language and master it so that their skills are something people hire for and not the skill set of languages and toolset.
Is that not just what C++ aims to be?
I find C++ and Rust hard to grasp quickly. I like Go since I come from C but I haven’t looked at any frondtend in Go. I would say some kind of Rust + Go mashup with some kind of good frontend framework (especially something that translates for mobile devices) could do the trick. But I find that every time I interview for a company the tech stack is always a different combination and a learning curve for newcomers.
> I find C++ and Rust hard to grasp quickly.
That's a direct consequence of them aiming to be usable for anything.
That's a direct consequence of them aiming to be usable for anything.
i think you mean node and javascript, or c# and blazor, or dart, or rust and web assembly.....
I think most of those languages need a GC, excluding them from some niches. Rust is probably closest to C++ in this respect. Most notable difference is that Rust restricts the programmer to ensure correctness, whereas in C++ anything that can be correct should compile.
I'd like something like Clojure, but with static typing and native compilation.
[deleted]
Isn’t that Racket?
No, it's common lisp
CL is dynamically typed, no? As far as I can tell, Racket is the only (mainstream) static-typed Lisp.
There are of course so many lisps that I’m sure some other ones also have static typing.
There are of course so many lisps that I’m sure some other ones also have static typing.
> As far as I can tell, Racket is the only (mainstream) static-typed Lisp.
Racket is dynamically typed.
Typed Racket is gradually typed, but that's a different language, implemented in Racket (there's something like a half-dozen other typed lisps bundled with the Racket distribution, too.)
Racket is dynamically typed.
Typed Racket is gradually typed, but that's a different language, implemented in Racket (there's something like a half-dozen other typed lisps bundled with the Racket distribution, too.)
SBCL uses type declarations and type inference for compile-time type checking.
That’s cool, I didn’t realise! I must deepen my lisp-fu.
I wouldn't design a new language, but would use the unlimited money and time to boost Common Lisp as the ultimate language to rule them all...
And maybe while you’re at it you could lint away some of its crusty bits.
I really like the language, but you can tell it’s evolved for half a century while maintaining backward compatibility.
I really like the language, but you can tell it’s evolved for half a century while maintaining backward compatibility.
Something dead simple.
I want code that's easy to write and easy to read. No fancy tricks. No decorators, no hundred-character lines for a print statement, no manual memory management or custom operators. A child should be able to use it.
I want code that's easy to maintain and deploy. Never worry about language/tooling versions again. No gcc, no g++, no rbenv, no Maven, no venv/pipenv/poetry whatever.
My target audience is anyone that doesn't have a computer science degree. A language for accountants and office workers. For school teachers and twelve-year-olds.
Throw out the foobar tutorials and Tower of Hanoi logic puzzles.
"Here's how you can download all your students' submissions from Blackboard in one button click."
"Here's how you automatically format a spreadsheet without having to click on every columns."
"Here's how to make your computer wiggle its mouse so you can skip the mandatory attendance checks for your online classes."
I want code that's easy to write and easy to read. No fancy tricks. No decorators, no hundred-character lines for a print statement, no manual memory management or custom operators. A child should be able to use it.
I want code that's easy to maintain and deploy. Never worry about language/tooling versions again. No gcc, no g++, no rbenv, no Maven, no venv/pipenv/poetry whatever.
My target audience is anyone that doesn't have a computer science degree. A language for accountants and office workers. For school teachers and twelve-year-olds.
Throw out the foobar tutorials and Tower of Hanoi logic puzzles.
"Here's how you can download all your students' submissions from Blackboard in one button click."
"Here's how you automatically format a spreadsheet without having to click on every columns."
"Here's how to make your computer wiggle its mouse so you can skip the mandatory attendance checks for your online classes."
Many of your design aims sound a lot like what Java was supposed to be. In particular:
> Something dead simple.
> I want code that's easy to write and easy to read. No fancy tricks. -- no manual memory management or custom operators. A child should be able to use it.
> I want code that's easy to maintain and deploy.
> A language for accountants and office workers. For school teachers and twelve-year-olds.
> Something dead simple.
> I want code that's easy to write and easy to read. No fancy tricks. -- no manual memory management or custom operators. A child should be able to use it.
> I want code that's easy to maintain and deploy.
> A language for accountants and office workers. For school teachers and twelve-year-olds.
I'd like a Lisp with some type declaration and inference; essentially, a more-strongly typed Clojure. Immutable data structures by default. I'd like it to create stand-alone executables (not JVM bytecode), but still have a full REPL. I'd like great error messages and developer affordances (like Elm and Elixir).
dependent types, effect system (with effect handlers able to be implemented in the language or as some sort of plugin/extension to the runtime), maybe play around with goal-directed execution from Icon? I've long been fascinated by Icon's weird ergonomics but am not really sure what lessons to take from it.
Not sure if you're familiar, but Koka feels like the future to me: https://koka-lang.github.io/koka/doc/index.html
it and unison are both really exciting!
Python, but fast -- so learning Nim, which looks like Python with variable declarations, is on my to-do list.
Also notable that Nim's new(ish) ORC collector combines reference counting to free memory relatively eagerly (just like python has) with an implementation of the Recycler algorithm to collect cycles (python handles this with occasional mark+sweep which is effective but not nearly as efficient as Recycler ... or, frankly, nearly as cool ;).
I would want to see language versioning baked into the language. Something like being able to tag a class or module with a specific version of the language. So that if the language introduces a breaking change, I can just tag that module with a version, and then continue developing with the new version.
Another interesting idea might be introducing architectural layers as a language concept wherein you can specify which layers can interact with one another and then provide some enforcement mechanism in the compiler to prevent layers from interacting
Another interesting idea might be introducing architectural layers as a language concept wherein you can specify which layers can interact with one another and then provide some enforcement mechanism in the compiler to prevent layers from interacting
I'm on it, except the lack of resources!
https://tablam.org
Is based on the relational model (+spiced with multidimensional-array capabilities like kdb+/pandas), and allow to have universal query/crud capabilities to anything (files, vectors, btrees, hashmaps, rdbms access(not yet!)), etc.
In other words, it has in-built linq-like capabilities:
---
I'm now trying several things that I wish to make it work:
* Loss-less parsing and high-quality errors
* Type inferencing relational operators (like a JOIN b JOIN c JOIN d SELECT a, b) because type this manually is not ergonomic
* Making a way to the user to create relational operators (like with generators on python) that fit well with query optimizations. In other words, I wish to have a simplified way to do compiler optimizations but for the query/array operators, that I bet will dominate all.
With this I wish to get into version 1.
---
And moving further in the dream: I wish to build a access/foxpro/excel tool, so it also means an improved language with a UI toolkit across platforms. And maybe even a in-built rdbms (using sqlite? from scratch?). For this, is where manpower and money is needed.
Anyway, I think get the lang to be enough for my scripting needs is feasible, so I only limited to how much far I can go. But living the dream!
https://tablam.org
Is based on the relational model (+spiced with multidimensional-array capabilities like kdb+/pandas), and allow to have universal query/crud capabilities to anything (files, vectors, btrees, hashmaps, rdbms access(not yet!)), etc.
In other words, it has in-built linq-like capabilities:
-- A column, aka: Vectors...
let qty := [10.5, 4.0, 3.0]
-- Like APL/kdb+ operations apply to more than scalars
prices * 16.0
-- The ? (query) operator allow to do SQL-like queries to anything
let doubled := qty ?select #0 * 2.0
let products := open("products.csv")
-- like files!
for p in products ?where #price > 0.0 do
print(p)
end
--so, we can do joins between anything:
for p in cross(products, qty) ?limit 10 do
print(p.products.price * p.qty)
end
---
I'm now trying several things that I wish to make it work:
* Loss-less parsing and high-quality errors
* Type inferencing relational operators (like a JOIN b JOIN c JOIN d SELECT a, b) because type this manually is not ergonomic
* Making a way to the user to create relational operators (like with generators on python) that fit well with query optimizations. In other words, I wish to have a simplified way to do compiler optimizations but for the query/array operators, that I bet will dominate all.
With this I wish to get into version 1.
---
And moving further in the dream: I wish to build a access/foxpro/excel tool, so it also means an improved language with a UI toolkit across platforms. And maybe even a in-built rdbms (using sqlite? from scratch?). For this, is where manpower and money is needed.
Anyway, I think get the lang to be enough for my scripting needs is feasible, so I only limited to how much far I can go. But living the dream!
immutable/transactional data, straightforward concurrency, simplified syntax, tail call optimization, first-class functions, probably byte-code/jit compiled, GC options. portable.
From the top of my head I would do 2 features no other language (to wit) has:
- request reordering arguments to find a match for when you don't remember the right order. I think this is better than named parameters and other hacks.
- The very opposite of Python: non-printing characters are skipped and won't affect anything. This requires dedicating a character to the separation of tokens. I think comma could be used. I would also use parentheses for grouping tokens.
Edit: Forgot that HN wants empty line to respect '\n'.
- request reordering arguments to find a match for when you don't remember the right order. I think this is better than named parameters and other hacks.
- The very opposite of Python: non-printing characters are skipped and won't affect anything. This requires dedicating a character to the separation of tokens. I think comma could be used. I would also use parentheses for grouping tokens.
Edit: Forgot that HN wants empty line to respect '\n'.
> find a match for when you don't remember the right order
How would it distinguish between two parameters of the same time? For instance, atan2 is often in the order (y, x), even though in pretty much every other circumstance, coordinates are given in the order (x, y). Would your feature be able to handle that?
How would it distinguish between two parameters of the same time? For instance, atan2 is often in the order (y, x), even though in pretty much every other circumstance, coordinates are given in the order (x, y). Would your feature be able to handle that?
I would either disallow using it when two parameters have same type, or assume that their order is irrelevant: using the feature promises that it won't make a difference.
Edit: Found terser expression.
Edit: Found terser expression.
I guess it should try all possibilities until it finds the Right Answer?
> - request reordering arguments to find a match for when you don't remember the right order. I think this is better than named parameters and other hacks.
It should be implemented at tooling (IDE) level. Otherwise, it would be just source of confusion.
It should be implemented at tooling (IDE) level. Otherwise, it would be just source of confusion.
Of course it should have distinctive look compared to a call where order matters, but I actually like your idea as it would require reordering just once. I think the order should be fixed in the source code too.
A language that uses machine learning, interactive editing/debugging, and maybe even mind-reading, so that you basically think of a computer program and it's there.
kind of what I started with https://github.com/dorianmariefr/template
hashes can written as `id: 1, name: "Dorian"`
js-deconstruction like `{ id, name }` and `{ id, name } = user`
comments in hashes like json5, e.g.
typescript style types, e.g. optionals, mostly deduced
interpreter and compile to binary options for fast iteration and fast production code
compatibility with web assembly
compiles to javascript
all the meta-programming of ruby like define_method, method_missing etc.
autoload like what rails does
a prettier-style formatter
and mostly ruby for the rest
and a sane dependency manager like rubygems/bundler
hashes can written as `id: 1, name: "Dorian"`
js-deconstruction like `{ id, name }` and `{ id, name } = user`
comments in hashes like json5, e.g.
id: 1 # first user
name: Dorian # me
typescript style types, e.g. optionals, mostly deduced
interpreter and compile to binary options for fast iteration and fast production code
compatibility with web assembly
compiles to javascript
all the meta-programming of ruby like define_method, method_missing etc.
autoload like what rails does
a prettier-style formatter
and mostly ruby for the rest
and a sane dependency manager like rubygems/bundler
I would borrow the ‘where’ clause from Haskell, reducing the need for assignments in imperative code. I can imagine it as a postfix operator on its preceding expression (its code, not just its value).
It would be Go without the garbage collector.
With static memory management like Rust or manual like C?
I guess both, like C++ does it.
I think the fist thing I would do is peruse comp.compilers and see what the replies to similar questions were.
Yep, that's bit of "what's the best pizza recipe" type of question.
In addition to comp.compilers -
https://www.reddit.com/r/ProgrammingLanguages and their fairly active Discord https://discord.com/invite/yqWzmkV
http://lambda-the-ultimate.org/faq
In addition to comp.compilers -
https://www.reddit.com/r/ProgrammingLanguages and their fairly active Discord https://discord.com/invite/yqWzmkV
http://lambda-the-ultimate.org/faq
I would probably design PureScript (not that I could)
easy reusability and ability to scale complexity easily
Now that it's unlimited resources... Here's several random fictional languages:
1. A dependent type language with superior IDE, so that the people could write a signature (specification) and leave the implementation to the computer (similar to Copilot, but it derives from types. If we could combine dependent type and Copilot it would be really powerful). Also, people could write specs and try to auto-complete proofs of the same system.
2. Or another language similar to Erlang, but statically typed. Since Erlang feels like an OS, the language is going to BE the OS, the experience would be very integrated like Smalltalk and Pharo, or Elisp and Emacs. It would not use plain text for everything like Unix, but structured data of the language itself. The key of the language/OS would be the lightweight processes and fast context switching. It could also be installed on bare metal, making it an ideal server-side language. Like Erlang or Kubernetes, it can form a cluster very easily - it lets you treat a cluster just like a single machine transparently, because a single machine is a collection of processes, a cluster is also a collection of processes as well. So there would be no difference between code for a single machine and a cluster. If major cloud providers support this language/OS, the ops part would be extremely easy because there would be no *nix, Kubernetes, and Docker, instead, there would be GenServers, Supervisors, and Registries which are just application code from developers (instead of ops/devOps).
3. Or another more practical language would support a superior range of platforms, like JavaScript but much better. JavaScript already dominated the browser, the desktop, and sometimes the mobile and backend. But the desktop and mobile experience is not the best, and there's not much about system programming. If we take a look at languages like Nim, it's a system programming language with a compact syntax that feels like scripting language. So assume a language that 1) feels like a scripting language for faster development 2) not only reach all platforms support JavaScript, but also for system programming, and game programming, etc 3) very fast so there could be better alternatives for Electron and React Native. It seems possible to build such language on WASM, it just requires a lot of work. The thing with a WASM language is it also should be a language with a very small core, and very extensible, or the binary would be large and waste time for download.
Well, in case if the three fictional languages happen to be the same it would be even better...
Other concrete features I would like to have is:
4. Symbolic programming (from time to time I wish the language I'm using supports it)
5. Built-in logic programming sub-language (so that it's easier to query things)
5. Other than the language IS the OS, the idea of language IS the database is also very useful. Instead of writing server talk to DB, we write code on the DB cluster so there's less inconsistency (because the logic and data are in-place) and less back and forth. There are many DB support stored procedures or Lua scripts, but if the language is a more full-sized general-purpose language that runs on WASM would be great.
1. A dependent type language with superior IDE, so that the people could write a signature (specification) and leave the implementation to the computer (similar to Copilot, but it derives from types. If we could combine dependent type and Copilot it would be really powerful). Also, people could write specs and try to auto-complete proofs of the same system.
2. Or another language similar to Erlang, but statically typed. Since Erlang feels like an OS, the language is going to BE the OS, the experience would be very integrated like Smalltalk and Pharo, or Elisp and Emacs. It would not use plain text for everything like Unix, but structured data of the language itself. The key of the language/OS would be the lightweight processes and fast context switching. It could also be installed on bare metal, making it an ideal server-side language. Like Erlang or Kubernetes, it can form a cluster very easily - it lets you treat a cluster just like a single machine transparently, because a single machine is a collection of processes, a cluster is also a collection of processes as well. So there would be no difference between code for a single machine and a cluster. If major cloud providers support this language/OS, the ops part would be extremely easy because there would be no *nix, Kubernetes, and Docker, instead, there would be GenServers, Supervisors, and Registries which are just application code from developers (instead of ops/devOps).
3. Or another more practical language would support a superior range of platforms, like JavaScript but much better. JavaScript already dominated the browser, the desktop, and sometimes the mobile and backend. But the desktop and mobile experience is not the best, and there's not much about system programming. If we take a look at languages like Nim, it's a system programming language with a compact syntax that feels like scripting language. So assume a language that 1) feels like a scripting language for faster development 2) not only reach all platforms support JavaScript, but also for system programming, and game programming, etc 3) very fast so there could be better alternatives for Electron and React Native. It seems possible to build such language on WASM, it just requires a lot of work. The thing with a WASM language is it also should be a language with a very small core, and very extensible, or the binary would be large and waste time for download.
Well, in case if the three fictional languages happen to be the same it would be even better...
Other concrete features I would like to have is:
4. Symbolic programming (from time to time I wish the language I'm using supports it)
5. Built-in logic programming sub-language (so that it's easier to query things)
5. Other than the language IS the OS, the idea of language IS the database is also very useful. Instead of writing server talk to DB, we write code on the DB cluster so there's less inconsistency (because the logic and data are in-place) and less back and forth. There are many DB support stored procedures or Lua scripts, but if the language is a more full-sized general-purpose language that runs on WASM would be great.
As of now, I personally feel that development of new programming languages rests on incremental paradigms. I see scope for a lot more innovation. Following are some thoughts:
Have various computer science algorithms (graphs, trees, parsing, et al) tightly integrated into the language. (I know the popular opinion is to have these in libraries, however, I think having built-in data structures and algorithms would lead to further innovation.) The tooling should aware of run-time complexities of various algorithms and steps and thereby reason about the same. (E.g., "Warning: You have declared 'xyz' to be a graph, however, a tree is sufficient here.") Tooling should be able to say that while the programmer thought the implementation is Big-O[N^3], it's actually exponential.
I wonder if programming languages can start making native use of machine learning advancements. Copilot et al already would have some internal representation as embeddings, so instead of just generating code as text, there should be value in using those representations as a part of the build tool-chain too.
Better representation of 'is-a' relationships between various types. E.g., I should be able to pass a tree to a graph algorithm without writing any extra code or having run-time performance overheads.
Get rid of overflows or precision constraints fundamentally from the language (and the the underlying hardware; over the time). I would like the tooling to automatically reason about which type is the best fit for the implementation during compilation -- byte, unsigned int 32, big-int, etc., via analysis of the program, and tell me what it chose and why. It may chose to typecast automatically for specific calculations when intermediary calculations need larger bit widths.
Likewise, I would like innovation on how null references can be fundamentally dealt with as opposed to how each new programming language tries to work around the same in various ways.
The fact that we use monospace fonts for programming seems to me to be a weakness of programming languages. We often need some alignment between adjacent lines of code to see the semantics of the code well. I would like to see a programming language which works well with variable-width fonts, without causing readability issues. Why you may ask? I think this should be explored as this would lead to innovation on how to make semantics come out independently of font width and text alignment.
Having an 'alias' at many places would be super helpful. E.g. a base class may be generic method named such, whereas a derived class (more specific) may use the very same method implementation, while choosing a better name for the method. This is syntactic sugar only as this is readily doable now by having a new method that calls the base method as it is. This may be handy for example when the is-a relationship is handled between a tree and a graph in the example above.
Language-native integration of units and dimensional analysis.
Finally, I am a big fan of symbolic computation abilities like seen in Wolfram Language. The tooling can reason about the expressions/code, and figure an optimal strategy whether at compile-time or run-time.
Have various computer science algorithms (graphs, trees, parsing, et al) tightly integrated into the language. (I know the popular opinion is to have these in libraries, however, I think having built-in data structures and algorithms would lead to further innovation.) The tooling should aware of run-time complexities of various algorithms and steps and thereby reason about the same. (E.g., "Warning: You have declared 'xyz' to be a graph, however, a tree is sufficient here.") Tooling should be able to say that while the programmer thought the implementation is Big-O[N^3], it's actually exponential.
I wonder if programming languages can start making native use of machine learning advancements. Copilot et al already would have some internal representation as embeddings, so instead of just generating code as text, there should be value in using those representations as a part of the build tool-chain too.
Better representation of 'is-a' relationships between various types. E.g., I should be able to pass a tree to a graph algorithm without writing any extra code or having run-time performance overheads.
Get rid of overflows or precision constraints fundamentally from the language (and the the underlying hardware; over the time). I would like the tooling to automatically reason about which type is the best fit for the implementation during compilation -- byte, unsigned int 32, big-int, etc., via analysis of the program, and tell me what it chose and why. It may chose to typecast automatically for specific calculations when intermediary calculations need larger bit widths.
Likewise, I would like innovation on how null references can be fundamentally dealt with as opposed to how each new programming language tries to work around the same in various ways.
The fact that we use monospace fonts for programming seems to me to be a weakness of programming languages. We often need some alignment between adjacent lines of code to see the semantics of the code well. I would like to see a programming language which works well with variable-width fonts, without causing readability issues. Why you may ask? I think this should be explored as this would lead to innovation on how to make semantics come out independently of font width and text alignment.
Having an 'alias' at many places would be super helpful. E.g. a base class may be generic method named such, whereas a derived class (more specific) may use the very same method implementation, while choosing a better name for the method. This is syntactic sugar only as this is readily doable now by having a new method that calls the base method as it is. This may be handy for example when the is-a relationship is handled between a tree and a graph in the example above.
Language-native integration of units and dimensional analysis.
Finally, I am a big fan of symbolic computation abilities like seen in Wolfram Language. The tooling can reason about the expressions/code, and figure an optimal strategy whether at compile-time or run-time.
Funny you ask that, because I am making a programming language!
(1) Structured concurrency, best explained at [1], [2], [3], and [4]. More on this later.
(2) Extensibility. Most people think that this means macros. It doesn't. However it's done, as curryst said, languages are not perfect, and extending a language is important. See "Growing a Language" by Guy Steele, Jr. [5] More on this later.
(3) Like many other posts, having real-world units like feet, meters, pounds, kilograms, etc., for calculations and type checking, but the default number type should also be a BigRational.
(4) Ranged types, like Ada, allowing programmers to explicitly limit the range a type can be, eliminating errors. For example, a type that is used in the denominator of a division could be restricted to being not zero, and you don't need to worry about divide-by-zero for those divisions.
(5) Consistency, a massively underrated feature. The use of something in the language should be the same everywhere. This simplifies learning and makes it easier to understand features you haven't seen yet.
(6) Design-by-Contract and other formal methods "in the small". It should be possible to use formal methods on little pieces of code. Even if you can't go so far as to prove them correct, it should be easy to increase your confidence that they are.
(7) Conditions and restarts instead of exceptions. Conditions and restarts come from Lisp, and it is one of the greatest ideas in computer science that almost nobody knows about.
(8) Composition, not inheritance. I think that most programmers have agreed on this.
(9) A way to solve the Expression Problem. This can be multi-methods or some other way.
(10) Dependent types. This will help with formal methods, but they are also powerful outside of that context.
There's definitely more, but I'm starting to feel lazy.
About (2), as implied, it is possible to make a language extensible without macros. This is done by fully defining the internals of the compiler and allowing the language access to them. In fact, you get 99% of the way by not even defining everything, but by just defining the IR and allowing the programmers to add keywords with functions to parse after them. In fact, I would argue that defining keywords gets you 100% of the way that macros do because macros are, in essence, keywords themselves.
As an example, say a programmer builds a build system in my language and call it "awesomebuild". They can define the keyword "target" for making a target to build, and others can use it, like so:
Structured concurrency will be, I think, amazing, but I have had an idea recently that I think would make it even better.
Structured concurrency, as currently defined, turns execution into a tree of threads. But what if we could turn it into a DAG?
It would have these restrictions:
(1) To prevent potential memory cycles (and thus, needing a garbage collector or reference counting), forbid all types from being able to, directly or indirectly, have pointers to themselves.
(2) Some form of RAII with automatic calling of destructors, like C++ or Rust’s Drop trait.
(3) Have structured concurrency as it currently stands.
(4) But add the ability for threads to ask another thread to run code for them.
Number 4 is the magic. What happens is that, when a thread creates data (the “create thread”) that other threads might want to use, it then creates a child thread to run the code it would have run on the data and waits for requests from other threads. Then, when other threads put in requests for the data, instead of getting a pointer to that data and continuing on their merry way, requiring reference counting for the data, each thread sends a function to the create thread, from which the create thread spawns another child thread that has access to the data it created, which would give every thread indirect access to the data that it wanted.
Then, every thread that requested the data is paused, waiting, while the execution of the thread it requested runs.
The reason the create thread spawns a child thread instead of just running code on the data itself is two-fold:
* It allows it to respond to requests, and
* It prevents the situation where an already existing child of the create thread requests the data and then the child is dependent on its parent to exit first. If the child of the create thread is dependent on a sibling to exit first, all is well.
In other words, creating the child thread first is what keeps the execution a DAG.
Restriction number 1 is important to get rid of all need of any kind of GC, including borrow checking!
Some may claim that it’s impossible to eliminate cycles, but you can always create a “parent” type that points to all of the child types that could be in a cycle.
For example, to create a linked list, create a parent type that stores an array with data, and alongside the data, it stores handles that it knows how to interpret as the prev and next pointers. The children don’t know how to interpret those handles, but the parent does, and it can do everything you need it to do in order to emulate a linked list.
A programming language that provides these facilities should also have reference counting, like Rust does despite its borrow checker, because sometimes, more complicated things are needed. However, if a programmer decides to program with these restrictions, they would have these benefits:
* No memory leaks.
* No use-after-free.
* No memory safety issues.
* No borrow checker to explode compilation times.
* Memory allocation that could be entirely done with bump allocators, except for data that may need to grow, such as resizable arrays or maps. Even dynamically-allocated stuff that knows what size it needs, but doesn’t need to change its size after allocation, could use the bump allocator.
While there are some details (a compiler would need to figure out when an item escapes a function), I think these ideas could be pretty useful.
As for escape analysis, we could make it easy and say that the compiler should just error if a value escapes. I personally would prefer something more sophisticated, where we ensure that a value does not escape to global variables. If a value escapes by being returned, the compiler should just treat that as though the caller has responsibility for it, and it already knows what to do in those cases (nothing in the callee, and call the destructor in the caller, unless it escapes, etc.).
[1]: https://250bpm.com/blog:71/
[2]: https://250bpm.com/blog:137/
[3]: https://vorpus.org/blog/notes-on-structured-concurrency-or-g...
[4]: https://gavinhoward.com/2019/12/structured-concurrency-defin...
[5]: https://www.youtube.com/watch?v=lw6TaiXzHAE
[6]: https://lobste.rs/s/8msejg/notes_on_structured_concurrency_g...
(1) Structured concurrency, best explained at [1], [2], [3], and [4]. More on this later.
(2) Extensibility. Most people think that this means macros. It doesn't. However it's done, as curryst said, languages are not perfect, and extending a language is important. See "Growing a Language" by Guy Steele, Jr. [5] More on this later.
(3) Like many other posts, having real-world units like feet, meters, pounds, kilograms, etc., for calculations and type checking, but the default number type should also be a BigRational.
(4) Ranged types, like Ada, allowing programmers to explicitly limit the range a type can be, eliminating errors. For example, a type that is used in the denominator of a division could be restricted to being not zero, and you don't need to worry about divide-by-zero for those divisions.
(5) Consistency, a massively underrated feature. The use of something in the language should be the same everywhere. This simplifies learning and makes it easier to understand features you haven't seen yet.
(6) Design-by-Contract and other formal methods "in the small". It should be possible to use formal methods on little pieces of code. Even if you can't go so far as to prove them correct, it should be easy to increase your confidence that they are.
(7) Conditions and restarts instead of exceptions. Conditions and restarts come from Lisp, and it is one of the greatest ideas in computer science that almost nobody knows about.
(8) Composition, not inheritance. I think that most programmers have agreed on this.
(9) A way to solve the Expression Problem. This can be multi-methods or some other way.
(10) Dependent types. This will help with formal methods, but they are also powerful outside of that context.
There's definitely more, but I'm starting to feel lazy.
About (2), as implied, it is possible to make a language extensible without macros. This is done by fully defining the internals of the compiler and allowing the language access to them. In fact, you get 99% of the way by not even defining everything, but by just defining the IR and allowing the programmers to add keywords with functions to parse after them. In fact, I would argue that defining keywords gets you 100% of the way that macros do because macros are, in essence, keywords themselves.
As an example, say a programmer builds a build system in my language and call it "awesomebuild". They can define the keyword "target" for making a target to build, and others can use it, like so:
import awesomebuild
awesomebuild.target program_name: prereq1, prereq2 {
// `$` Means run the following as a command.
$ compiler -o program_name prereq1 prereq2
}
Structured concurrency will be, I think, amazing, but I have had an idea recently that I think would make it even better.
Structured concurrency, as currently defined, turns execution into a tree of threads. But what if we could turn it into a DAG?
It would have these restrictions:
(1) To prevent potential memory cycles (and thus, needing a garbage collector or reference counting), forbid all types from being able to, directly or indirectly, have pointers to themselves.
(2) Some form of RAII with automatic calling of destructors, like C++ or Rust’s Drop trait.
(3) Have structured concurrency as it currently stands.
(4) But add the ability for threads to ask another thread to run code for them.
Number 4 is the magic. What happens is that, when a thread creates data (the “create thread”) that other threads might want to use, it then creates a child thread to run the code it would have run on the data and waits for requests from other threads. Then, when other threads put in requests for the data, instead of getting a pointer to that data and continuing on their merry way, requiring reference counting for the data, each thread sends a function to the create thread, from which the create thread spawns another child thread that has access to the data it created, which would give every thread indirect access to the data that it wanted.
Then, every thread that requested the data is paused, waiting, while the execution of the thread it requested runs.
The reason the create thread spawns a child thread instead of just running code on the data itself is two-fold:
* It allows it to respond to requests, and
* It prevents the situation where an already existing child of the create thread requests the data and then the child is dependent on its parent to exit first. If the child of the create thread is dependent on a sibling to exit first, all is well.
In other words, creating the child thread first is what keeps the execution a DAG.
Restriction number 1 is important to get rid of all need of any kind of GC, including borrow checking!
Some may claim that it’s impossible to eliminate cycles, but you can always create a “parent” type that points to all of the child types that could be in a cycle.
For example, to create a linked list, create a parent type that stores an array with data, and alongside the data, it stores handles that it knows how to interpret as the prev and next pointers. The children don’t know how to interpret those handles, but the parent does, and it can do everything you need it to do in order to emulate a linked list.
A programming language that provides these facilities should also have reference counting, like Rust does despite its borrow checker, because sometimes, more complicated things are needed. However, if a programmer decides to program with these restrictions, they would have these benefits:
* No memory leaks.
* No use-after-free.
* No memory safety issues.
* No borrow checker to explode compilation times.
* Memory allocation that could be entirely done with bump allocators, except for data that may need to grow, such as resizable arrays or maps. Even dynamically-allocated stuff that knows what size it needs, but doesn’t need to change its size after allocation, could use the bump allocator.
While there are some details (a compiler would need to figure out when an item escapes a function), I think these ideas could be pretty useful.
As for escape analysis, we could make it easy and say that the compiler should just error if a value escapes. I personally would prefer something more sophisticated, where we ensure that a value does not escape to global variables. If a value escapes by being returned, the compiler should just treat that as though the caller has responsibility for it, and it already knows what to do in those cases (nothing in the callee, and call the destructor in the caller, unless it escapes, etc.).
[1]: https://250bpm.com/blog:71/
[2]: https://250bpm.com/blog:137/
[3]: https://vorpus.org/blog/notes-on-structured-concurrency-or-g...
[4]: https://gavinhoward.com/2019/12/structured-concurrency-defin...
[5]: https://www.youtube.com/watch?v=lw6TaiXzHAE
[6]: https://lobste.rs/s/8msejg/notes_on_structured_concurrency_g...
You can pick and choose features from existing languages, create entirely new features, real or fictional ones even, that we might not even be able to actually construct today!