Hacker News Reader

Comment by tejuis | Hacker News Reader

I agree. If you take the tool perspective, it is easy to understand that different tools are needed for different tasks. Don't use hammer for sawing. No single language scales to all corners of programming problems.

Actually I really don't get this endless "silver bullet" discussion. C has its place and for very good reasons. Also the author makes really good points about the integration aspects of C.

View on HN

I read this thought quite often here on hacker news but it is a bit alien to me. To me the charm of programming is the ability to---at least in theory---write anything. This is also embodied in the idea of Turing completeness.

There is a continuum between the possibilities of a programming language and the possibilities of a configuration file. As soon as one says that a programming language is suitable for a particular purpose one has moved a few steps towards the configuration file end of this continuum.

This is, of course, a personal preference but I very much prefer to enjoy the power of programming language as opposed to the lack thereof of configuration files. Therefore, I like programming languages that attempt to be useful for any purpose. My favorite language is still C++ and if I were to switch to something else I would be inclined towards Rust.

A bit of rope is charming because you can build practically anything out of rope. For example, you can build skyscrapers out of bamboo and rope. But if you want that skyscraper to be useful, durable, safe, etc it may be better to use the rope for what rope is best at, and use other materials and tools for what they're best at.

Somehow I was expecting Lisp instead of C++ after all you've said. Any specific reason why you're not using Lisp?

Well, the ability to program anything includes the possibility to do tasks that require high performance. Also, I do like the fact that the compiler guards the type correctness of the program.

If your requirements are only high performance and improved type checking, then you are all set. The only language you need is C++. But the criteria above does not define all programming problems.

C++ is too complicated. "Nobody" writes C++, but a subset of it. Select your subset.

Dynamic typing in Lisp (and the like) is really nice for quick prototyping where program correctness is not key. You are exploring what you want to achieve with the program, be it algorithm level or architecture. C++ is not well suited for that, since type checking and memory worries are slowing you down, too many details to drag along. Hence no "silver bullet".

Sure, C++ is complicated. And the way templates are compiled is positively weird, which in turn sometimes leads to long compilation times. The 'select your subset' thing is often repeated, but I do not see much of that. I am a bit worried, though, that C++ seems to keep growing to the point where it really might get to big and complicated.

Quick prototyping is not something that I do. Nor am I very much interested in it. At my place of work I have seen it done around me after which it was my task to turn the python prototype into C++. The most surprising thing there was how far the prototype turned out to be from what was actually needed, to the point where I very much question whether the prototyping exercise was useful at all. YMMV regarding this, of course.

A python prototype is useful for specifying the correct program behavior. It's useful as a guide for later implementors. Better than a spec in a word document.

Being the language to write UNIX clones, that is all about it.

So by your definition the windows kernel is unix?

Compared to the architecture of an OS targeting, say, hardware with native capability handling, Windows and Unix are virtually indistinguishable. They're both just "that ugly bag of compromises you make to abstract over a register machine that can peek and poke at an unprotected address space, with the OS managing an MMU through CPU-interrupt-triggered context switches to enable a kind of multitasking where each task perceives itself as living on a single core and is unaware of being pre-empted unless it checks for it after the fact."

There are examples of OSes that don't work like that, despite targeting x86. For example, bare-metal Forth.

No, because Windows has plenty of C++ on it and Microsoft Security Team advocates using C#, Rust and constrained C++ (Core Guidelines) as the future of systems programming on Windows.

https://github.com/Microsoft/MSRC-Security-Research/blob/mas...

They are also very clear that C is done on Windows, and compatibility is only to the extent required by ISO C++ and a couple of key FOSS projects.

https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-an...

UNIX is C's platform, there is hardly any reason to use it outside of non-UNIX OSes.

Plenty other languages offer system programming features, with better type safety and equal portability.

Reply on news.ycombinator.com