61–70 of 182 posts
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…
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…
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, transactions sound similar in a way.
I want to write a program that has no mention of concurrency and runs efficiently on clusters anyway. So no threads, fibres, processes, actors, atomic, mutex, channels, queues, coroutines. Not in the language nor in a library. Push the concurrency and distribution machinery into the language runtime. Developer can neither see nor influence it. Program just runs faster when put on more parallel hardware. The price app…
This is completely unworkable. It's based on the assumption that nodes have zero failure rate and networks have zero latency and packet loss and infinite bandwidth.
Distributed system programming is hard because you want to control the failure modes of your system as closely as possible. The opposite of hiding it.
- No linters. Code is auto-formatted.
- No modules. Includes can be namespaced/aliased.
- No package manager. Include by Git URL with tags.
- No type annotations. Automatic type-checking.
- No user-defined types. A few good types is better.
- No null. Set membership with maps is better.
- No exceptions.
- No loops. List and map comprehensions.
- No general recusion. Only tractable transitive closures (ala Datalog).
- No higher-order functions.
- Terminating. All programs terminate. Turing completeness is not desirable for most domains, but predictable semantics is.
- Safe. No undefined behavior. No crashes.
- Persistent, the runtime is also the database. The language is the database.
I'm working on a language with exactly this set of features. Email me if you're interested.
It sort of sounds like Scala though, but I would probably settle for a weaker type system but with constraints (like JML or Clojure’s spec) that are tried to be proven at compile time but will fall-back to be checked at runtime in debug mode (and if marked so, even in prod). Also, would probably make Clojure’s atom/ref/etc concurrency primitives the “most first-class”, so other than the possibly mutable method implementations, everything would be safe+ concurrency-wise.
It is pretty much a mix between Scala and Clojure, or a non-lisp clojure with some types, so not really original..
Oh, and Haskell’s target typing for number literals, I honestly don’t understand why don’t we use that everywhere.
+ AFAIK, deadlocks can’t be statically guaranteed
1. Compile time execution which opens the way for invaluable tooling that can be built/used directly.
2. Memory allocation strategy as a global/context functionality. Strong correlation between data structure layout and resulting memory layout.
3. Strong meta-programming/introspection focus.
4. Ease of compilation, ease of creating static binaries.
- One executable that is the runtime, accepting one argument: the source code file. - No linters. Code is auto-formatted. - No modules. Includes can be namespaced/aliased. - No package manager. Include by Git URL with tags. - No type annotations. Automatic type-checking. - No user-defined types. A few good types is better. - No null. Set membership with maps is better. - No exceptions. - No loops. List and map compre…
How are you side stepping an NP-hard issue like the halting problem?
Firstly it would be persistent - so you'd never need to write SQL or file handling code again. Want to save a map or list or object of some kind? Just reference it from the root object (can be indirectly) and it is magically there the next time you start your program. Secondly, it would be as easy to program in as Python but have some way to be more efficient when that was strictly necessary. Might be JIT or the abil…
I want to write a program that has no mention of concurrency and runs efficiently on clusters anyway. So no threads, fibres, processes, actors, atomic, mutex, channels, queues, coroutines. Not in the language nor in a library. Push the concurrency and distribution machinery into the language runtime. Developer can neither see nor influence it. Program just runs faster when put on more parallel hardware. The price app…
> Push the concurrency and distribution machinery into the language runtime. Developer can neither see nor influence it. This is completely unworkable. It's based on the assumption that nodes have zero failure rate and networks have zero latency and packet loss and infinite bandwidth. Distributed system programming is hard because you want to control the failure modes of your system as closely as possible. The opposi…
It's also assuming that the runtime can make a good enough guess at when the ratio of data size to compute time for a task makes distribution profitable.
Distributed systems programming is indeed hard. That's why I want it pushed out of my applications.
I want to write a program that has no mention of concurrency and runs efficiently on clusters anyway. So no threads, fibres, processes, actors, atomic, mutex, channels, queues, coroutines. Not in the language nor in a library. Push the concurrency and distribution machinery into the language runtime. Developer can neither see nor influence it. Program just runs faster when put on more parallel hardware. The price app…
NodeJS sounds pretty close to that. Just ‘await’ anything in parallel and your code appears synchronous. Parallel code would need to be a new node process, so it’s not quite so amazing, but pretty close.