4 ms·

That's a fine list, and when said like that it might even be fun to implement and relatively easy to accomplish, but there's a bigger battle before you can writ

by tinco 14y ago

That's a fine list, and when said like that it might even be fun to implement and relatively easy to accomplish, but there's a bigger battle before you can write any of the software systems you mention. You need all those things _and_ interoperability with existing libraries that are written in C and C++, preferably both ways. That is a lot less fun to implement. Another thing is that implicit in the 'realtime' part of your requirement is that you don't want a runtime system, and that bugs a whole bunch of your earlier wishes. It also makes the language less interesting as many of the cool features of modern languages depend on runtimes (it's why we can't use Rust or Go!) Whoever designs the new language needs to have a lot of restraint, knowing all the fancy things modern languages have, and picking only those that can be implemented whilst satisfying the needs that those core applications have.

Scramblejams 14y ago
Oh, I forgot interoperability! I've grown so accustomed to connecting my Erlang programs to C++ libraries through the simplicity of ports that I erred. Thanks for adding to my list -- the more the merrier. :-) It would be interesting to make the runtime optional, to see how close together the two runtimey and runtimeless subsets could get. Or, perhaps it would be possible to mark a section of code as runtime-free. IIRC some work's been done on that but I don't think it's ever been practical.
- ihnorton 14y ago
  Does Erlang do something special to make C++ interfacing easy? Any info/links would be appreciated - I have only found info about calling C-exported code with ports.
  - Scramblejams 14y ago
    No, not particularly. I've just settled on writing some shim C/C++ and using msgpack or protobuf over the port to do the interfacing. I prefer it because it feels the simplest to me. Obviously it could get complicated with some applications, though that would be the case with just about any other method of interfacing. Oh, and did I mention my dream language has a great REPL, compiles nearly instantly and can run interpreted, too?
- cpeterso 14y ago
  A runtime-less subset of Rust is being considered and is being developed incrementally. Most of the Rust compiler and runtime is written in Rust itself, so the runtime may be able to be loaded dynamically. https://github.com/mozilla/rust/issues/3608 https://github.com/mozilla/rust/issues/3608
Scramblejams 14y ago
tinco, as with most programming language dilettantes I have a wishlist for my ultimate language, but I've never actually implemented one. Where would you suggest I start? And where should I go after that?
- tinco 14y ago
  The first part is always making the list of features you want to have, these are the ones you value most and don't want to compromise on. You should write them down maybe hang them on your wall to remind yourself. Go through the list and try to find out if no features conflict with each other. That a language exists that has both features is usually a good sign. After that comes designing a grammar. How do you want to express the features? This is a fun part. I start by selecting a small program I think should be easy to implement in my language, for example a coffee machine, a small web application, a mathematical algorithm (like fibonacci). Find some you think should be written in your language, and then just do it. Be very careful in that everything you want to express is actually expressed in an unambiguous way. When you think you got the idea of your language down, now you write it down formally. This is where it gets a little complex so I'm not going to fully explain it (you can mail me when you're at that point @tinco.nl) but the basic idea is that you learn EBNF, and pick a lexer/parser generator (there's multiple in every language, even javascript). Depending on what features your language has this can be very hard, Ruby for example can only be parsed and lexed at the same time so it requires much hand tweaking. Depending on the particulars of the language it doesn't really matter in which language the compiler is written, pick one as highlevel as you can. Compilation speed is only important once you have a reference implementation. Then a rather difficult step, the code generator. It takes your AST and turns it into executable code. For CoffeeScript this means turning it into Javascript. For C# it means turning it into CLR bytecode, for C it means turning it into x86 machine code. I recommend that as a target language you pick a language that is as close to your desired feature set as possible without conflicting with any of your features. A conflict here means either a lot of work to implement, or incurring a too big performance loss. Pick a low level one like LLVM or CLR bytecode if you need good performance. And then you're done. Now you have a reference implementation you can focus on making it run fast (by selecting a lower level target language / implementing optimizations) and on making a standard library.

by tinco 14y ago

Scramblejams 14y ago

Oh, I forgot interoperability! I've grown so accustomed to connecting my Erlang programs to C++ libraries through the simplicity of ports that I erred. Thanks for adding to my list -- the more the merrier. :-) It would be interesting to make the runtime optional, to see how close together the two runtimey and runtimeless subsets could get. Or, perhaps it would be possible to mark a section of code as runtime-free. IIRC some work's been done on that but I don't think it's ever been practical.

ihnorton 14y ago
Does Erlang do something special to make C++ interfacing easy? Any info/links would be appreciated - I have only found info about calling C-exported code with ports.
- Scramblejams 14y ago
  No, not particularly. I've just settled on writing some shim C/C++ and using msgpack or protobuf over the port to do the interfacing. I prefer it because it feels the simplest to me. Obviously it could get complicated with some applications, though that would be the case with just about any other method of interfacing. Oh, and did I mention my dream language has a great REPL, compiles nearly instantly and can run interpreted, too?
cpeterso 14y ago
A runtime-less subset of Rust is being considered and is being developed incrementally. Most of the Rust compiler and runtime is written in Rust itself, so the runtime may be able to be loaded dynamically. https://github.com/mozilla/rust/issues/3608 https://github.com/mozilla/rust/issues/3608

Scramblejams 14y ago

tinco, as with most programming language dilettantes I have a wishlist for my ultimate language, but I've never actually implemented one. Where would you suggest I start? And where should I go after that?

tinco 14y ago
The first part is always making the list of features you want to have, these are the ones you value most and don't want to compromise on. You should write them down maybe hang them on your wall to remind yourself. Go through the list and try to find out if no features conflict with each other. That a language exists that has both features is usually a good sign. After that comes designing a grammar. How do you want to express the features? This is a fun part. I start by selecting a small program I think should be easy to implement in my language, for example a coffee machine, a small web application, a mathematical algorithm (like fibonacci). Find some you think should be written in your language, and then just do it. Be very careful in that everything you want to express is actually expressed in an unambiguous way. When you think you got the idea of your language down, now you write it down formally. This is where it gets a little complex so I'm not going to fully explain it (you can mail me when you're at that point @tinco.nl) but the basic idea is that you learn EBNF, and pick a lexer/parser generator (there's multiple in every language, even javascript). Depending on what features your language has this can be very hard, Ruby for example can only be parsed and lexed at the same time so it requires much hand tweaking. Depending on the particulars of the language it doesn't really matter in which language the compiler is written, pick one as highlevel as you can. Compilation speed is only important once you have a reference implementation. Then a rather difficult step, the code generator. It takes your AST and turns it into executable code. For CoffeeScript this means turning it into Javascript. For C# it means turning it into CLR bytecode, for C it means turning it into x86 machine code. I recommend that as a target language you pick a language that is as close to your desired feature set as possible without conflicting with any of your features. A conflict here means either a lot of work to implement, or incurring a too big performance loss. Pick a low level one like LLVM or CLR bytecode if you need good performance. And then you're done. Now you have a reference implementation you can focus on making it run fast (by selecting a lower level target language / implementing optimizations) and on making a standard library.