|
I understand why it's attractive to integrate more and more into the language proper, but I don't like it. Almost all tools which still embrace the unix way of doing things are written in C, and it's not just because that community is conservative. C feels like unix, because it's one of the only languages that abides by that philosophy. C-the-language is only part of the experience of programming in C. Programming in C includes DSLs and code generation and makefiles. Even what we consider C-the-language can be decomposed into preprocessor code and actual C. That said, C needs to be improved, but I think it should be done via the build system, adding layers on top of C, in a tasteful, thought-out way. Some ideas below: If we're expanding on C by adding build system complexity, Makefiles need to be improved. Make is a great tool, but it's unityped, like shell scripts. And it's essentially a preprocessor over shell, which leads to a mess of sigils. Maybe redesigning make as an embedded language in some lisp would do it. Additionally we could unify the notion of linking to a library and importing code into the makefile to allow dependencies to specify build steps. This could make some of the added build complexity implicit. Namespaces could probably be implemeneted as a preprocessor, taking module declarations and import statements and converting all identifiers into they prefix qualified equivalents, emiting warnings when there would be a collision (like if module "foo" declared "bar_baz" and module "foo_bar" declared "baz"). Rust-style syntax-case macros can be implemented as a preprocessor. Go-style defer statements could be implemented in a preprocessor, and avoid the somewhat verbose goto-style error handling. As I said, this approach requires a lot of care to avoid adding a huge amount of complexity to the language. |