Live data from Hacker News

Which programming paradigm had the most impact on you as an engineer and why?

news.ycombinator.com

71–80 of 91 posts

Re: Which programming paradigm had the most impact on you as an engineer and why?

#71
I think it would have to be machine language, assembly language, and C used to program machines at the hardware level. This was on an Atari 8-bit except C being cross compiling to M86k. In all cases I was programming to hardware interfaces video games and laser printer firmware. What it taught me was as sense of 'you can understand it all down to the metal'. That hardly seems valuable now, but what that means is that I've always had the curiosity and desire to know how things work which leads to deeper understanding in our field.

Learning recursive programming was an eye-opener because it clearly illustrated the correspondence of programming and math (proof by induction). [Dynamic programming was meh when I learned it--memoization seems a more fitting term--as I expected to be learning metaprogramming.]

The thing I wish I'd been taught or learned much earlier is functional programming. And maybe data-oriented design if that's a name of the thing that prioritizes data schema and layers operations on them. I'm always surprised by coding-first developers not able to put fields at the appropriate place considering cardinalities, or never even think that it's important to get this right.

Re: Which programming paradigm had the most impact on you as an engineer and why?

#72
post #13

Fail fast. Adding assertions everywhere helped me write software which does less unexpected stuff and is more reliable.

Thats what I am planning to do as well. Do you have any kind of strategies you have developed? Do you write tests for the order of assertions (entering temporal logic)?

Honestly I don’t write that many tests these days other than integration and functional tests. The assertions are incredibly good at breaking those if anything goes wrong so you need less (unit) test cases. The test cases are always brittle too.

As for strategies, I pepper asserts on inputs and outputs of functions to remove any assumptions about scale and state which are not enforceable by the contract at compile time. Additionally I will tend to assert conditions which need to be in place within the functions. Rarely does anything need any more than that.

Assertions are left in production and any identifiable errors or throws are turned into defects and resolved as priority 1 cases.

Re: Which programming paradigm had the most impact on you as an engineer and why?

#74

Earlier quoted context omitted.

What languages specifically do you have in mind?

Scala as a mainstream language probably comes closest, but it lacks a bit on the dependent types part. Idris or F* would be languages that fully support both but they are rather academic.

Idris isn't very far from Haskell.

Perhaps that's already pretty far for practical purposes for a lot of people.

Idris does actually try to be a programming language and not just a proof system.

F* tries to be like Standard ML with proofs. It really is ergonomic for an ML. But if you haven't written Standard ML (or OCaml), this feels very much like you're a mathematician trying to prove facts about programs rather than run programs.

Re: Which programming paradigm had the most impact on you as an engineer and why?

#75
post #4

Functional programming. I learned OOP in school, and always thought it overcomplicates things, why can't this comparison operator in one page of Java just be a function, I thought. How can you make the state of objects manageable, especially if it's private, how do you test, without opening up too much of the API, couldn't we just make this a set of functions with an explicit state so it's easier to understand? How d…

I feel the same way for OOP paradigm but I found it's usually hard to argue against it because it seems to be so ingrained into people's minds. After all that's what we are taught in universities and presented as a first go-to toolbox so it's no wonder. I'm guilty of that defending attitude too but after probably several hundreds kLoC of OOP style and utilization of whatnot design patterns I've came to realization th…

The problem, I think, is that OOP is teach with lots of inheritance. And people think is all about inheritance, and is the only valid tool. Correctly (sparingly) used is ok, but 99% of the time is over used. That is the "All has to inherit from something" illness. Another thing that is overused is hiding: all has to be private, all accessed through getters/setters, all so deeply hidden as possible...

OOP has good ideas, but they have their place. They are way way way to much overused.

Re: Which programming paradigm had the most impact on you as an engineer and why?

#76
post #4

Functional programming. I learned OOP in school, and always thought it overcomplicates things, why can't this comparison operator in one page of Java just be a function, I thought. How can you make the state of objects manageable, especially if it's private, how do you test, without opening up too much of the API, couldn't we just make this a set of functions with an explicit state so it's easier to understand? How d…

By order of impact, not chronological introduction:

0) Macro programming: I learned TCL as a kid, so that made the impact stronger; writing programs that write programs is insanely powerful. Learning macro programming via TCL incidentally let me skip learning FP at the same time, which I would've with a Lisp.

1) Functional programming: correctness and beauty. Standard ML, Haskell.

2) Erlang: extreme concurrency via message passing. Erlang is functional, too.

3) C: manual memory management: Understanding how programs allocate memory.

After that it gets more obscure. (Prolog, linear type systems, hardware DSLs, etc.)

I feel like TCL made me numb to the Lisp bug. I might go into Clojure at some point.

(Also, OOP can go suck a thumb.)

Re: Which programming paradigm had the most impact on you as an engineer and why?

#77

Earlier quoted context omitted.

I feel the same way for OOP paradigm but I found it's usually hard to argue against it because it seems to be so ingrained into people's minds. After all that's what we are taught in universities and presented as a first go-to toolbox so it's no wonder. I'm guilty of that defending attitude too but after probably several hundreds kLoC of OOP style and utilization of whatnot design patterns I've came to realization th…

I think the problem is that OOP is mostly taught as a separate paradigm, when it should be seen as a convenience layer over procedural imperative programming. It is about bundling procedures together in groups, associating them with mutable state, and protecting and encapsulating that state from other pieces of code.

I see two big problems with OOP:

1) OOP takes credit for a lot of programming concepts by rebranding them. E.g. abstraction.

2) OOP-specific concepts are either over-used or downright broken. E.g. inheritance, encapsulation.

Re: Which programming paradigm had the most impact on you as an engineer and why?

#78
post #74

Earlier quoted context omitted.

Scala as a mainstream language probably comes closest, but it lacks a bit on the dependent types part. Idris or F* would be languages that fully support both but they are rather academic.

Idris isn't very far from Haskell. Perhaps that's already pretty far for practical purposes for a lot of people. Idris does actually try to be a programming language and not just a proof system. F* tries to be like Standard ML with proofs. It really is ergonomic for an ML. But if you haven't written Standard ML (or OCaml), this feels very much like you're a mathematician trying to prove facts about programs rather th…

> Idris isn't very far from Haskell.

From my experience it's very far apart. I know that there is Haskell Liquid but that is still does not make it a real value-dependent type-system, even though in many cases it allows a similar expressiveness. If we talk in the context of programming paradigms, I don't think I would count Haskell in.

Re: Which programming paradigm had the most impact on you as an engineer and why?

#79

Earlier quoted context omitted.

I feel the same way for OOP paradigm but I found it's usually hard to argue against it because it seems to be so ingrained into people's minds. After all that's what we are taught in universities and presented as a first go-to toolbox so it's no wonder. I'm guilty of that defending attitude too but after probably several hundreds kLoC of OOP style and utilization of whatnot design patterns I've came to realization th…

I think the problem is that OOP is mostly taught as a separate paradigm, when it should be seen as a convenience layer over procedural imperative programming. It is about bundling procedures together in groups, associating them with mutable state, and protecting and encapsulating that state from other pieces of code.

Yes, I agree, my experience is also that OOP is taught as something orthogonal over procedural imperative programming whereas it should be taught as an extension to it. But even with that said I honestly cannot think of many examples where OOP provides more elegant solution to the problem. Quite the contrary, any larger and more complex OOP-style codebase is quite an unreadable mess despite all the standard promises about the readability, maintainability, "testability", clean abstractions etc.

I think that the biggest bend in my mind was when I set myself a goal to try to digest "Elements of Programming" by A. Stepanov and "Modern C++ Design" by A. Alexandrescu. Don't let the "modern" in the title trick you, it's a book from 2001.

But irrelevant of the programming language, which in my example happens to be the C++, these two books triggered me to start challenging the tunnel vision I had up until then. It took me some time and a lot of experimentation to basically unlearn the OOP way of approaching the problems and trying to embrace a totally different, I'd say, almost mathematical way of looking at the things. It felt like a relief and it really had a huge impact not only on my code style but the way I think about the problems.

Since then I think I started producing much simpler and, what I think, non over-engineered code of better quality without a lot of unnecessary cruft.

Re: Which programming paradigm had the most impact on you as an engineer and why?

#80
The Turbo Pascal IDE. At first I thought it was stupid to have to compile a program instead of just writing it in BASIC, which was what I was used to. Then I learned to love that almost instant compile and insane speed compared to BASIC.

When I was forced to move to Windows, Delphi was there to make it damned easy to build GUI apps, which was about a similar step in productivity as Turbo Pascal. They used the perfect amount of OOP to get the job done, but not bury you in abstraction.

Post reply on HN