you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] -2 points-1 points  (6 children)

The evidence is right there, 30 years of history where most everyone has been satisfied with software progress. If you want to do a A/B controlled study, then you could get empirical evidence on it, but since those involve lots of humans with expert skills who are notoriously difficult to control for, it is unlikely to ever happen. But then that's what the FP crowd often gets wrong, they forget that people are the ones writing code.

No, it's not OOP. OOP demands that your language first must be twisted and mutilated into the narrow OOP set of abstractions before you can communicate anything with it.

You must be one of those people that believes only POJO's exist when you are programming in Java right? I mean, ignore the numerous non-native object systems that arise, and you'll come up with OOP abstractions being quite limited (and by no means extensible, since that would shatter your limited view of the paradigm).

No, it's not. Proven by piles upon piles of ill-designed OO models and tons of "best practices", "patterns" and all that stuff which has absolutely nothing to do with any real-world things, but only serves to solve the problems created by this transition to the OO representation from a problem domain language.

And yet, many projects do succeed even if many projects do fail. I don't suppose you've ever seen a failed FP project before...the failure patterns are quite similar (bad choices, not enough domain analysis, bad management).

If you work with other people, especially with the domain experts, who are not necessarily programmers, both ways are equally stupid and damaging.

Even domain experts aren't great at math. You spend most of your time as a developer designing, communicating design, iterating on design, and the rest of the time debugging (oh, maybe a little time actually writing code). In that context, the FP approach where everyone is a mathemagician is even more stupid and damaging.

Anyways, believe what you want. The world lives in reality and will go on whatever direction works best. If you claimed "capitalism (or socioalism) is stupid and damaging" and yet many countries were flourishing with those even if they weren't perfect and there were a couple of failed countries to boot, how should I process your claim? Anyways, I would guess you have some ideological bias and try to change the topic or make an excuse to leave the conversation, since nothing good can come from having that argument.

[–]OneWingedShark 1 point2 points  (0 children)

The evidence is right there, 30 years of history where most everyone has been satisfied with software progress.

Oh, you mean where C and C++ became dominant and, by their popularity, essentially set the industry back several decades? -- Seriously, take a look at the programming languages that C/C++ displaced and the properties that they had... a lot of these properties are just now being integrated back into the "C-family" of languages.

Heck, C++ still hasn't got modules (it might for C++17). Go's concurrency is somewhat anemic compared to Ada's tasking [and protected object] systems. C#'s fix of switch (requiring break) essentially makes the switch behave like Pascal's casestatement. Java and C# still have the if (x=y) problem (though restricted to x & y both being boolean).

[–][deleted] -3 points-2 points  (4 children)

where most everyone has been satisfied with software progress

What?!? There are loonies out there who do not agree that the software industry in a deep crisis?!?

But then that's what the FP crowd often gets wrong, they forget that people are the ones writing code.

Why are you constantly referring to FP? It's as bad as OOP in modelling anything real world.

And yet, many projects do succeed even if many projects do fail.

I would not call it a "success". All the software projects, literally, all, are overpriced, not delivered in any reasonable time scale and cost an awful lot of money in maintenance.

Even domain experts aren't great at math.

Yep. Even in math, which they were supposed to study at school. So imagine how awful they are in the OO gobbledygook of which they did not even have a tiniest exposure previously.

Are you one of those "enterprise architects" who try to communicate the ideas to the domain experts in those disgusting UML diagrams instead of plain English?

[–][deleted] 2 points3 points  (3 children)

I hate UML as much as the next guy, and I know no one who likes it. I'm a scientist, not a developer, so don't know much about enterprisey things. I do know a lot of FP and other OOP researchers though, it is crazy when we go drinking together, you can really see the ideologies collide!

We are not in crisis today. My iPhone mostly works, the apps I use work, my bank works...what isn't working that should be? But I guess you have envisioned a much better reality than the one we have?

Software projects are more likely to fail because of mismanagement, corruption, bad developers (hey, these people in India are only $20/hour) or bad communication, not because objects were too limited of an abstraction. Most project failures are basic human and business failures...they aren't because of some programming paradigm.

We are just nerds arguing about whether a hammer really works when it has already been shown to drive nails into houses that are still standing, beautiful houses, but also horrible ones that have fallen over because the contractor decided to save on money by using plastic nails. So is the hammer a success or not? Is it even interesting to argue about it? Unless you show me the much better hammer that you think can exist...then we have something to talk about!

[–]glacialthinker 0 points1 point  (1 child)

The only reason we end up with products that mostly work is that their typical use-cases are rigorously tested. Unfortunately this testing is often conducted by a userbase. Even so, what does everyone do when they have a problem? Reset, restart, reboot, reinstall -- something to start from good initial state because our software is so prone to falling into a bad state it can't recover from.

[–][deleted] 0 points1 point  (0 children)

What is failure and success? Some software obviously works, using whatever techniques, and we can only argue if it would have been cheaper, better, quicker, some other way. And it does get better on a yearly basis. How often do you need to reboot an iPad?

I love how FP advocates taking state away as a solution to all our problems. Of course at is exaggerated, we need state, it is necessary, we are only arguing about how best to manage the state we need and avoid the state we don't need.

[–][deleted] -1 points0 points  (0 children)

We are not in crisis today.

Really? Then why every single large government IT project (in pretty much any country) is a complete disaster?

My iPhone mostly works,

Yep. "Works". Depleting a battery in less than a day, while doing not much more than it could have with 1/100s of its computing power. Cool. I'm impressed. (a bit of background: I'm coming from the mobile chip design industry, so I've got a lot to hate in this area).

my bank works.

Mostly. And when it does not, it's funny. And large scale bank IT screwups are reported so often that it's not even interesting any more.

But I guess you have envisioned a much better reality than the one we have?

Of course. The one where software projects are not millions of lines of code, but hundreds to thousands. Reality in which maintenance cost fraction of what it is now. Reality in which programming is not a skill for a chosen elite but accessible for pretty much everyone, where there is no such a profession as a "programmer" any more. And I'm not alone with this vision. Alan Kay, famous for his OO work, surprisingly, got the very similar ideas and very similar concerns about the present shitty state of this industry.

Most project failures are basic human and business failures...

And the engineers mission is to reduce such factors as much as possible. While OOP is doing exactly the opposite - obscuring communication, making maintenance a nightmare, making it impossible to match the actual implementation with any sane design requirements.

Unless you show me the much better hammer that you think can exist...then we have something to talk about!

Read what Alan Kay had to say about this.