![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png) simont |
Fri 2013-07-12 12:36 |
- Multi-paradigm is good, Do Everything My One True Way is bad. Some things are OO-shaped, some functional-shaped, some plain procedural, and you want to be able to switch back and forth within different parts of the same program without undue faff.
- Compile to nice fast native code, or at the very least, don't design any language so that you can't sensibly do that. Requiring users to wait for Moore's Law is a mug's game.
- Complete and correct bindings to all OS APIs. This is a major thing that keeps me using C and occasionally C++ in spite of their many flaws: whenever you use a different language, you sooner or later end up having to do some OS interaction that that language's abstraction didn't bother to include. But it's not really a language feature as such; I think what I really want is for all OS maintainers to publish cross-language specs for their APIs so that every language can auto-process them into its own appropriate form.
- Define the language semantics better than C/C++. Undefined behaviour can bite you in so many different ways, and you have to know all the gotchas to reliably avoid it. Each language feature should be safely usable without having to be an expert in the rest of the language first.
- Check as much as possible at compile time; in Python it's really annoying to find a code path your tests didn't encounter crashing in the field due to a typo or type-o that static type checking would have picked up instantly.
- Make it possible to extend the language in a metaprogramming-type way, but try to do better than C++ at making the simple things simple, and try to avoid the need for puzzle games (which C++ is no better at doing than C – the CRTP is a good example).
- Managed languages (GC, bounds checking etc) versus non-managed (C/C++ with feet firmly in the line of fire at all times) I'm not sure about; sometimes I think what I'd really like is a hybrid (e.g. GC with an optional explicit free operation which causes an allocated thing to become instantly invalid, so that refs from it become GCable in turn and refs to it throw a StalePointerException, and also I want a feature to let me conveniently treat a big byte array as an unmanaged sandbox), and other times what I think I'd really like is a means of writing unmanaged code which includes a static compile-time proof that you don't overrun any array etc. Probably neither is actually feasible.
- I'm vaguely intrigued by aspect-oriented programming, in that it seems to be a reaction to a thing that's annoyed me a lot, but I've never actually tried it so who knows if it would work well in practice. I think ideally I'd just want a metaprogramming facility strong enough to let me do it myself if I happened to feel like it in a particular program.
- Extending 'define the semantics clearly' above, a slightly silly idea that I can't quite convince myself is actually wrong would be to specify that all intermediate values in integer arithmetic expressions have the semantics of true mathematical integers, to the extent that the runtime will link in GMP or equivalent if it really has to (which I wanted available anyway, since arbitrary-precision integers are a really nice facility to have available and the best thing about Python is that it provides them as a native type). Narrowing should occur only as a result of an assignment or explicit cast. If you need speed, you can request a compiler warning when the expression you've written requires GMP to code-generate, and then manually insert casts to eliminate the need; then you'll be in control of where the casts go and won't be startled by them.
- My biggest blue-sky wish is that I'd like a built-in language feature to construct pieces of code on the fly and JIT them into native code, so you could implement all sorts of user-scripting of things in a way that was actually reasonably efficient, and also increase the use of the approach "first laboriously work out exactly what you want to do, and then do it in a loop a zillion times really fast".
- AND A PONY. There, see what I mean?
|
|