3 ms·

1. Instead of the ability to directly call and be called by C/C++, include a really kick-ass Foreign Function Interface that can JIT the hookups and wrappers.

1. Instead of the ability to directly call and be called by C/C++, include a really kick-ass Foreign Function Interface that can JIT the hookups and wrappers. And more important than call compatibility IMO is C++ object ABI compatibility. (I realize there is no universal C++ ABI; just pick one and be compatible with it.) If you can declare a struct or class in the language and make its layout match a C or C++ class/struct to the point of being able to pass them back and forth, that's the important feature. The other important thing is some C API's use callback functions, without passing a user object that you can use to implement a closure out of it. A language with the ability to dynamically emit new functions (built in JIT) would be able to build a new C function just for one object to receive a callback. 2. Fuck the C preprocesser. An architecture based on #include files is a joke; you will never make something better than C++ if you stick with that compilation model, you'll only make another C++ (corollary to the phrase, those who don't understand Unix are doomed to re-implement it poorly). Here's an idea: sandbox the god damn shit preprocessor and parse its output to provide input to the FFI (foreign function interface) JIT compiler. Under no circumstances allow macros defined in an #include to spill into the language proper. This is not negotiable. 3. No, mark-sweep garbage collection can be made to coexist with C++-style memory management. 4. If you aren't going to include built-in threading or some better form of concurrency, why bother? Unless you have a time machine and intend to go back to 1980 to introduce your language there. 5. I don't think it's that clear cut (about requiring (or not) a standard library) but I won't argue this point. 6. I think you're right in the sense that if you do include dynamic typing it is going to lead to creating something completely different than the stated goal. I'd say it would be a better language, but it would not be the correct language for replacing a statically typed one. 7. I think exceptions are an important language advance, but I can't dispute that they can cause a mess of problems when it comes to cross-language (or cross-thread) boundaries. 8. If you look at C, it is not too verbose for coding the types of concepts which it supports (function calls with a small number of control-flow statements). But it does not allow you to define new concepts. Of course C is terse for calling functions: those are C's atoms, it's fundamental language element! So IMO comparing to C code based on how easy it is to call a function is the wrong thing to think about. True improvements would come at the macro scale from better organization of groups of functions (e.g. into classes) or at a semantic level, by not needing to specify a function explicitly at all (e.g. operator overloading).

Nitramp 16y ago
I think exceptions are an important language advance, but I can't dispute that they can cause a mess of problems when it comes to cross-language (or cross-thread) boundaries. Exceptions are not completely problem-free, but there is no alternative. If you don't have exceptions, every single line of code: doSomething(); Becomes: int result = doSomething(); if (result != OK) return result; ... and that is the simple case, without memory management, an actual result to return, unfortunate interactions with your other control flow statements, and so on. And you still end up with your application helpfully saying "ERR: -1923876". This is simply doesn't work. And few people programming C/C++ appear do it correctly; I'd imagine that many security flaws come from improperly proceeding code that should have checked a return code.
- grogers 16y ago
  Exceptions aren't the only solution though. Conditions/restarts in common lisp seem to be a more powerful but similar alternative. One problem with exceptions is that they can only be one deep. Ie. if you are executing the code invoked by handling an exception, what should happen if another exception gets thrown. Java says forget about the old exception (ie. lose information), C++ says crash. Maybe there is something in between? With or without exceptions, being error-safe is still really hard. I find you have to think "transactionally". For every operation you perform you have to think about what you need to clean up if it fails, so you focus on specifying what you want to do, not how you want to do it.
- supersillyus 16y ago
  I prefer return values over exceptions in languages that make it safe and easy. Haskell does a pretty good job, I think. With Maybe or Either, you have to check it to extract your value, but if you are doing a lot of things that will result in/use the results of Maybe/Either, you can just operate in a Monad that makes them the default. Similarly, languages with multiple return values make you explicitly ignore the return value. Exceptions have their benefits, but I have a personal preference for return values because they make it explicit in the interface. Also, I find that it makes more sense to handle various success and failure scenarios in the same bit of code instead of writing a best-case flow and assuming that exceptions will be thrown and errors will be dealt with somehow. Exceptions are great if you can't continue due to programmer error, but most cases where people use exceptions are just expected execution paths that (in my view) make no sense to handle via non-local control flow.

Nitramp 16y ago

I think exceptions are an important language advance, but I can't dispute that they can cause a mess of problems when it comes to cross-language (or cross-thread) boundaries. Exceptions are not completely problem-free, but there is no alternative. If you don't have exceptions, every single line of code: doSomething(); Becomes: int result = doSomething(); if (result != OK) return result; ... and that is the simple case, without memory management, an actual result to return, unfortunate interactions with your other control flow statements, and so on. And you still end up with your application helpfully saying "ERR: -1923876". This is simply doesn't work. And few people programming C/C++ appear do it correctly; I'd imagine that many security flaws come from improperly proceeding code that should have checked a return code.

grogers 16y ago
Exceptions aren't the only solution though. Conditions/restarts in common lisp seem to be a more powerful but similar alternative. One problem with exceptions is that they can only be one deep. Ie. if you are executing the code invoked by handling an exception, what should happen if another exception gets thrown. Java says forget about the old exception (ie. lose information), C++ says crash. Maybe there is something in between? With or without exceptions, being error-safe is still really hard. I find you have to think "transactionally". For every operation you perform you have to think about what you need to clean up if it fails, so you focus on specifying what you want to do, not how you want to do it.
supersillyus 16y ago
I prefer return values over exceptions in languages that make it safe and easy. Haskell does a pretty good job, I think. With Maybe or Either, you have to check it to extract your value, but if you are doing a lot of things that will result in/use the results of Maybe/Either, you can just operate in a Monad that makes them the default. Similarly, languages with multiple return values make you explicitly ignore the return value. Exceptions have their benefits, but I have a personal preference for return values because they make it explicit in the interface. Also, I find that it makes more sense to handle various success and failure scenarios in the same bit of code instead of writing a best-case flow and assuming that exceptions will be thrown and errors will be dealt with somehow. Exceptions are great if you can't continue due to programmer error, but most cases where people use exceptions are just expected execution paths that (in my view) make no sense to handle via non-local control flow.