Live data from Hacker News

Correctness – A paradigm for sustainable software development

nonullpointers.com

41–50 of 186 posts

Re: Correctness – A paradigm for sustainable software development

#41
post #14

>The thing you need to look at if you’re using say, a dynamic language, or object oriented design, is that in the long term, what is the language and mindset of “objects” with dynamic dispatch providing you apart from an endless stream of bugs that seem to keep reoccurring everytime you try an evolve the software to introduce a new requirement? I am sick and tired of the arrogant, willfully ignorant developers toutin…

OOP is great if all you are doing is OO and if your solution to a problem is running a simulation (what OOP was invented for).

But you are not staying in your pure OO-world nowadays. There's always the boundary issue where you are giving up your careful encapsulation and where state needs to be transferred instead of being hidden away in some object (like exporting to JSON). Poof, your encapsulation is gone.

Furthermore, may OOP languages don't deal with ownership at all. If I'm a constructor and someone passes me an object A or worse, a list of As. Can I hold onto that list? Should I make a shallow copy? Should I make a deep copy, because I need the A objects in the state they are currently in?

What if I have to work with 3rd party libraries? What assumptions do they make about that?

Can I call methods on objects from multiple threads? I need to rely on the documentation to figure that out or provide synchronization myself just to make sure I'm not breaking things.

Also, it is no accident that refactoring tools have become so popular in the OO world. If you need to design OO with 'change' in mind, you need to employ lots and lots patterns that make your code looks like new FactoryBuilderPatternVisitorImpl().

But with refactoring, hey, I can easily change my classes thanks to my IDE, yay! Too bad if someone then passes me data that only fits the old classes and too bad if consumers of my library are getting nasty surprises.

It is with everything in software: use the appropriate tool for the job.

Re: Correctness – A paradigm for sustainable software development

#42
post #12

Earlier quoted context omitted.

You're not wrong about unpredictability (to an extent), but the idea that Haskell is 'slow' has really got to go. Compared to languages commonly in use today, Python, Ruby, etc, Haskell goes like lightning with basic optimization (the kind C and C++ programmers are used to). The fact is that, for the vast majority of workloads, which are not heavily algorithm dependent, idiomatic Haskell is going to be much faster th…

> idiomatic Haskell is going to be much faster than what most people are using. I am not trying to be pedantic, but your point is moot if you consider what "most people" are using are not dynamically typed interpreted languages like Python Ruby or PHP, but rather statically typed, compiled languages like Java, C#, and C++. Java by itself dwarfs Python and Ruby combined.

IME, Haskell and Java are about on par, especially for basic things like http serving. Actually, Haskell is typically faster, because it compiles into much better machine code. That's just my experience as a professional Haskell developer. This is a combination of the fact that Haskell often compiles to really good machine code, and that Haskell is better at parallelization and multi-core workloads (async by default, for example).

Here are some benchmarks: https://github.com/jakubkulhan/hit-server-bench. As you can see, warp is on par, if not better than, many of the common JVM based options.

I'm not arguing Haskell is necessarily better than Java in all benchmarks (or C#). Merely that IME, most people dismiss Haskell as slow because it's a functional language, despite increasing evidence to the contrary. It is certainly capable of standing on its own against popular languages.

Re: Correctness – A paradigm for sustainable software development

#43
post #41
post #14

>The thing you need to look at if you’re using say, a dynamic language, or object oriented design, is that in the long term, what is the language and mindset of “objects” with dynamic dispatch providing you apart from an endless stream of bugs that seem to keep reoccurring everytime you try an evolve the software to introduce a new requirement? I am sick and tired of the arrogant, willfully ignorant developers toutin…

OOP is great if all you are doing is OO and if your solution to a problem is running a simulation (what OOP was invented for). But you are not staying in your pure OO-world nowadays. There's always the boundary issue where you are giving up your careful encapsulation and where state needs to be transferred instead of being hidden away in some object (like exporting to JSON). Poof, your encapsulation is gone. Furtherm…

> OOP is great if all you are doing is OO and if your solution to a problem is running a simulation (what OOP was invented for).

And even for simulation-like code (or really any other case of "very-high-level" code featuring "object"-like entities linked by complex, non-trivial relationships) ECS systems work a lot better than plain old OOP, while preserving the wide variety of advantages that you rightly point out. Especially since ECS works as a reasonably-thin layer over the usual sort of data-oriented programming.

Re: Correctness – A paradigm for sustainable software development

#44
post #14

>The thing you need to look at if you’re using say, a dynamic language, or object oriented design, is that in the long term, what is the language and mindset of “objects” with dynamic dispatch providing you apart from an endless stream of bugs that seem to keep reoccurring everytime you try an evolve the software to introduce a new requirement? I am sick and tired of the arrogant, willfully ignorant developers toutin…

I've gotten a new appreciation for OOP (and TDD) after reading "Growing Object-Oriented Programs Guided By Tests."

It's made me start thinking of programs more as multicellular organisms, or communities, where each part is responsible for a particular task. I think this is the core genius of OOP. It's not about classes or (Java) interfaces, it's about programs being communities of cohesive individuals with well-defined communication protocols.

edit to add: I think another key difference is in increasing the level of abstraction that you think about your program. You want to build a layer where you just say what should happen (the "declarative layer"), and keep that separate from the idea of how it should happen (the "implementation layer").

Re: Correctness – A paradigm for sustainable software development

#45

I had a thread on twitter about this problem of "musicians nerding over gear." In our metaphor it was about mountain climbers. The programming language and its paradigms chosen may have some effect on how you scale the mountain but the real problem is the mountain. Whether you use functional programming or dynamic typing it only affects small, local problems in the practice of climbing mountains. The problem of effic…

Interesting point. I think I've been feeling this lately as a desire to have, basically, smarter compilers. It's actually incredible to me when I think about how many minutes of human thought are wasted among myself and my peers to informally verify facts about our programs.

Obviously, types and tests help. But it's astonishing how much incidental complexity creeps into one's everyday work with our current tools. Under most circumstances telling a computer to do something shouldn't be that much harder than telling a human to do it (assuming a concrete grammar and shared vocabulary).

Re: Correctness – A paradigm for sustainable software development

#46

I had a thread on twitter about this problem of "musicians nerding over gear." In our metaphor it was about mountain climbers. The programming language and its paradigms chosen may have some effect on how you scale the mountain but the real problem is the mountain. Whether you use functional programming or dynamic typing it only affects small, local problems in the practice of climbing mountains. The problem of effic…

One problem with your metaphor about mountain climbers and mountain climbing is that the most efficient way to scale a mountain is probably to just take a helicopter to the top. Mountain climbing, like lots of other things, _must_ be constrained, in some way, to be _meaningful_, and the constraints _chosen_ reflect the _purpose_ of the endeavor. But then, specific constraints, e.g. the tools and methods 'allowed', become their own 'thing' (while continuing to interact with and evolve with other related things).

Re: Correctness – A paradigm for sustainable software development

#47
post #45

I had a thread on twitter about this problem of "musicians nerding over gear." In our metaphor it was about mountain climbers. The programming language and its paradigms chosen may have some effect on how you scale the mountain but the real problem is the mountain. Whether you use functional programming or dynamic typing it only affects small, local problems in the practice of climbing mountains. The problem of effic…

Interesting point. I think I've been feeling this lately as a desire to have, basically, smarter compilers. It's actually incredible to me when I think about how many minutes of human thought are wasted among myself and my peers to informally verify facts about our programs. Obviously, types and tests help. But it's astonishing how much incidental complexity creeps into one's everyday work with our current tools. Und…

I find it helpful to think of it as teaching a computer to do something rather than telling it to.

Re: Correctness – A paradigm for sustainable software development

#48
post #38

Earlier quoted context omitted.

> 1. OOP is a higher-level paradigm than FP , so people comparing them directly usually are missing the point to begin with. [emphasis added] How so?

Not the OP, but I might have some context. I think of OOP as a message passing paradigm . It's concerned with how messages are passed from one part of the system to another. It is not particularly concerned with how those messages are implemented under the hood. In that sense it's a higher level paradigm because OOP is all about building abstractions ("objects") and defining how they communicate, rather than wiring c…

When viewed that way, you're not dealing with most mainstream OO languages anymore. But it is the intent of the originators of OO and I prefer the same view. Especially because at that point it becomes orthogonal to imperative/functional approaches.

Message passing can be used with a functional language (Erlang) or an imperative language (Go) to great effect. It can also be added onto (as a library) most other languages.

However, I want to know if the original author meant it that way. And I still don't see how message passing is a higher level paradigm than functional programming. It's an orthogonal paradigm, neither subsumes the other, and both benefit when used with the other.

Re: Correctness – A paradigm for sustainable software development

#49
post #7
post #6

The biggest problem is communication and setting expectations. I constantly hear/see people saying "oh that will be quick!" without any real evaluation of the work. Simply saying "this is hard, it will take some time" makes focusing on correctness a hell of a lot easier. In no uncertain terms: don't be a pushover. If it can't be done well in the amount of time you suggest, don't say that it can be. You're just diggin…

This is easy to say and not unheard of, but in organizations it is common (in my experience at least) that if you say too often "this is hard and might take some time", people will just start to bypass you (and/or your input/judgement) in order to get stuff done quickly but less correctly.

If you explain why they're less likely to. And if they push back, just say "okay, then I need your okay to rush on this so we can get it done—keep in mind that it may have flaws and I'd need you to take responsibility for those."

Re: Correctness – A paradigm for sustainable software development

#50

Earlier quoted context omitted.

This is a bit like the "Islam is a religion of peace" discourse. I'm sure it is, but: OOP as actually implemented and found in the wild isn't about Smalltalk or message passing. It's about transforming functions into methods by unnecessarily wrapping behaviour in classes, as an example of cargo-cult programming. OOP the idea is great. How do you actually find it in the world?

If functional programming were implemented as widely and abused as much as OOP is, would it really fare any better?

You can already see examples of this.

Take callback hell. Opaque callbacks are the functional equivalent of goto statements.

Also, many functional programmers, particularly Haskell programmers, seem not to care about readability and maintainability. They're focused on maximizing their own productivity as an individual coder, and writing cool concise and abstracted code that might not actually be easy for another engineer to understand and modify.

The difference though is that good functional programming is still quite common whereas good object oriented programming seems to be rare (the one exception being microservices).

Post reply on HN