Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Worse is Better seems to be an ongoing theme in the programming industry. (Pascal was much more readable and safe than C, and about the same speed - e.g., I could cobble up pointer arithmetic in TP if I have to with the address-of operator and increment/sizeof pseudo-functions)

First it was shitty C code in the 90s, and now the Java language. At least I'm not totally burned out on Javascript yet :-)



Very. Gabriel might go back and forth but I was sold on the concept first read of paper. Let's take Turbo Pascal or even Delphi. People were griping at one point about all C's problems and C++'s similar + new problems. They wanted a more productive, safer, easier-to-integrate systems language. I cited Wirth already built half a dozen and Borland industrialized them. Hell, even industrial BASIC's had less problems that C development with similar safety, readability, and dev speed.

What's the market do? Push all effort into C and C++. Results of that are still with us. (sighs) Go and Rust give me some hope in that they're first mainstream languages that solve some problems. On non-mainstream, Julia is an awesome development that might be re-applied to systems programming. Not to mention Racket's metaprogramming combined with C or assembler generation for a high-level use of low-level, fast language. Ivory language does that with Haskell, for example.

So, not as Worse as usual. Still true overall.


> What's the market do? Push all effort into C and C++. Results of that are still with us.

Not to mention the amount of money spent writing band aids for them., in form of static and memory analysers and more recently CPU instructions (Intel MPX).

Which not everyone uses, because either it isn't available on their platform, or they choose not to use them anyway.

Just like coders that despite C++ safety improvements over C, use it as C with C++ compiler.


Yeah the band aids add up. We'd need things such as static analysers anyway for spotting problems, optimizing, etc. However, an extra problem with C/C++ is that the languages are so complex to analyse that people get friggin' PhD's for certifying or formalizing even a subset of them. And the average programmer working against the clock is supposed to make something robust with such a tool? That's ridiculous.

" because either it isn't available on their platform"

I tried to solve that with my tools (lang X) using X-to-C compiler w/ seemless FFI for 3rd party code. Encouraged other languages to do that with many having done it before I got on the scene: Modula, Oberon, Ada, LISP/Scheme, and so on. Let them use good language with hardware/OS of choosing. Ignored it as you said.

"Just like coders that despite C++ safety improvements over C, use it as C with C++ compiler."

David Thornley brought this up on Schneier's blog when he said he was distrusting about those who mentioned "C/C++" as if they're same thing. That using modern C++ prevents many C issues if it's used correctly. Now, I abandoned C++ as anything but a compiler target after all the 90's empirical evaluations showed it was garbage. I think my critique that it lets you shoot yourself in foot easily and is hard to analyse probably still applies like it did when I cited them together. It's why I do.

Nonetheless, I honestly don't know how modern C++ developers code when they're doing it "right" with style guides, newer language features, peer review, etc. I think it would be fair in these discussions to do some new, empirical studies comparing proper C++ to Free Pascal, Go, Rust, Ada, etc in various attributes like was done in 90's. Critical that it's used as pro's say it should be so as not to mislead readers about effectiveness (i.e. C++ used like C didn't work). You know any resources I could use to catch up on topic that capture most or all of how pro's do C++ with modern features? Not necessarily most recent standard but what has been used at least past 5 years maybe 10.


Modern C++ can be safe by making use of:

- type safe enums (enum class)

- STL collections instead of plain C like types

- references for out parameters

- RAII

- smart pointers

- values types over heap allocations everywhere

- warnings as errors

The problem is making sure there aren't some guys in the team doing C style coding.

Nowadays C++ is still my language to go when I need to step out of Java and .NET.

The problems faced by Turbo Pascal and other languages to keep up with the OS vendors SDKs teached me to only invest on first class languages for production code.

Effective Modern C++, Tour of C++, Elements of Programming and From Mathematics to Generic Programming are all good books, where safe modern C++ is used.


"Modern C++ can be safe by making use of:"

Thanks for the summary and references. Will be helpful if another honest language comparison is done of C++ against safe, systems languages. Or C++ developers against others on realistic, example programs.

"The problems faced by Turbo Pascal and other languages to keep up with the OS vendors SDKs teached me to only invest on first class languages for production code."

It makes sense. My solution was a auto-generating that from a better language and wrapping their libraries. That does take some serious tooling support, though.


Obligatory:

https://www.gnu.org/fun/jokes/unix-hoax.html

Even a professional and fan of C once admitted that this was great because it could've been true. Ain't that something. ;)


The funny thing is, I have actually come to like Unix, compared to the alternative. But C is NOT an applications programming language - it really is just portable assembler.

So much programming machismo:

* Bounds checking is a little slower, so safeties off!

* Multiprocessing with explicit IPC is slightly slower than thread pools, so safeties off!

* Parameters and explicit return values to functions are a little slower than DATA-DIVISION / instance variable mutation whack-a-mole code, so safeties off!


It's a portable assembler plus a structure for programs. LLVM IR is a portable assembler. I like your examples of their machismo, though. The machismo concept particularly: "Real programmers don't need all those safety mechanisms! Get out of here kid and take your training wheels with you!"

Funny part is they say this even when alternative languages or libraries implement safety tricks without a performance penalty. Then we see clearly that their resistence isn't technical. ;)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: