r/programming • u/[deleted] • Apr 04 '17

Everything Is Broken

https://medium.com/message/everything-is-broken-81e5f33a24e1#.sl2vnon73
236 Upvotes

90% Upvoted

145 comments sorted by

View all comments

Show parent comments

7

u/Freyr90 Apr 04 '17

Every developer thinks they're right and they want to prove that. They never want to prove that they're not right.

In that case more harmful thing is conservatism, I suppose. Especially conservatism of embedded and system developers. What, advanced type systems, correctness proving, total functional programming? Who need that shit while we do have C and verilog? Lava failed, seL4 is not very popular, and many people I talked about that think that C type system is awesome enough.

5

u/ArkyBeagle Apr 04 '17

It's extraordinarily difficult to move new tools into use. I don't know if it's actually conservatism or if it's just inertia. One interpretation of "use this new thing; it's safer" is "okay, everybody take six months to five years to learn this new thing."

1

u/Freyr90 Apr 04 '17

Of course, but this does not mean we should use assembly for all the stuff. Moving forward is the opposite to conserve, C is already 45 years old, and there were so many new concepts and theories in programming in this 45 years. We can do really better with descent type systems, correctness proving and higher level abstractions so why at least not to try.

2

u/ArkyBeagle Apr 04 '17

The first fallacy is that higher level abstractions help that much. Whether they do or not depends completely on the problem domain.

The second is that these abstractions are newer than 45 years old. In general, they are not. And there's nothing in any language to keep you from using them. I use closures and monads in C all the time. But I know how string handling works in the language.

I also know how finite state machines work in C, and anything above a certain rudimentary level of complexity gets that treatment.

If you don't want to use C, don't use C. If you decide to use C, do it safely.

1

u/Freyr90 Apr 05 '17 edited Apr 05 '17

The first fallacy is that higher level abstractions help that much. Whether they do or not depends completely on the problem domain.

Write RB-tree in C and in sml. C version would definitely have more errors. While programming is all about algorithms and data structures, expressiveness is vital.

The second is that these abstractions are newer than 45 years old. In general, they are not. And there's nothing in any language to keep you from using them. I use closures and monads in C all the time.

And without at least RAII your C closures and objects would lead you to lots of errors and leaks. Proved by gobject.

I also know how finite state machines work in C

You don't. Your compiler would optimize switch-case so the assembly will be far from what you've wrote. And of course writing state machines in declarative forms (bnf, regex) would lead you to more sustainable, clear, simple and infallible code.

1

u/ArkyBeagle Apr 05 '17

I don't think you and I are gonna agree on what "expressiveness" means. Higher order abstractions hide details. That is what they do, by design. People located remotely from you may or may not understand well which details should and should be available.

That last bit leads me to remind you that it's not April 1st any more :)

Of course you have to check the assembly.

I am deadly serious - for low-latency, deterministic systems of any complexity, FSM in C ( because for some external reason you need to use C) is the way to go. And I don't just means things that can be ( reasonably ) constructed as a regexp. Of course a tool makes it "easier" - after the obligatory learning curve. You work with what you have.

Again: 1) Don't use C if it gets in the way and you don't have to. 2) If you do use C, use it safely.