141–150 of 182 posts
Maybe a simpler subset of the language with it's most common usage, like STL containers, string, etc.
And a similar syntax, I don't want want exotic things like in rust.
By the way I wonder why it's not possible to deprecate things in C++, and compile different part of a code base with either an old or a new part of the language. C++ really needs to break off backward compatibility.
I would be all in Clojure if it had compile time type checking, something like Elm.
C++ without the old bad things it carries for the sake of backwards compatibility. Maybe a simpler subset of the language with it's most common usage, like STL containers, string, etc. And a similar syntax, I don't want want exotic things like in rust. By the way I wonder why it's not possible to deprecate things in C++, and compile different part of a code base with either an old or a new part of the language. C++ r…
Earlier quoted context omitted.
> No package manager. Include by Git URL with tags. Go does exactly this (`go.mod`), and it turns out it still needs a package manager, just simpler. One of the reasons: diamond dependency problem.
The diamond dependency problem is easy to avoid: Only allow namespaced/qualified includes, no shared libraries. There is no need for a package manager if the runtime does the work of resolving all includes, and these references have some kind of cryptographic integrity. This can be completely transparent to the user. There's no need to have a separate program do dependency resolution when dependencies are referenced…
Earlier quoted context omitted.
You wouldn't. Not every language has to be a general purpose language.
Right, but embedded systems are what I do, so a language that requires termination would not be perfect for me ...
I guess you wouldn't be able to use it to build a machine that is supposed to display Pi or Fibinocci?
I would want something like C++/Typescript/C#/Python, but only the good parts. - Multiparadigm, that means traditional OOP, but also first class functions (well first class everything) - Compiles to native code, runs relatively fast - Designed from the ground up for async/await - No undefined behavior - Statically typed, but with the feeling that the compiler is helping and not punishing you. I get that feeling from…
Why async/await? As go and soon java with loom shows it is quite a misfeature, if anything. Otherwise, I like your idea on checked exceptions, I think they are a very good feature, but somehow got a bad name and thus not experimented with as often. Your last point sounds quite macro-ish, so I guess the LISP-fanatics will come in in droves and tell you that they already have that in their language :D But relatedly, tr…
Yeah the last idea came when I added undo/redo to an app. I had to go mechanically through everything and make every change to my model go through a "Command" subclass. When I encounter something like this I think "why can't the compiler do this for me?". Probably solvable by LISP macros, or transactions as you said.
I would want something like C++/Typescript/C#/Python, but only the good parts. - Multiparadigm, that means traditional OOP, but also first class functions (well first class everything) - Compiles to native code, runs relatively fast - Designed from the ground up for async/await - No undefined behavior - Statically typed, but with the feeling that the compiler is helping and not punishing you. I get that feeling from…
You described Nim.
My main criticism is that it feels like a large language with all kinds of weird features and you can write very clever and dangerous code. A tiny bit Go-like restraint and it would be perfect.
Earlier quoted context omitted.
The diamond dependency problem is easy to avoid: Only allow namespaced/qualified includes, no shared libraries. There is no need for a package manager if the runtime does the work of resolving all includes, and these references have some kind of cryptographic integrity. This can be completely transparent to the user. There's no need to have a separate program do dependency resolution when dependencies are referenced…
If you are not doing shared dependencies, count me out.
To be clear the lack of “shared” dependencies does not necessitate code duplication. By shared dependencies I’m talking about languages (Haskell for example) where only one version of a library can be used, which results in the diamond dependency problem (predictably so!).
Let’s say file A references file B and C, and files B and C both reference D. D doesn’t need to be duplicated.
If all includes are qualified/namespaced there is no diamond dependency problem, and the compiler/runtime can reuse the same code for multiple references to the same file.