Fighting Complexity in Software Development • Hacker News Board

Re: Fighting Complexity in Software Development

#101

Post by tabtab » Fri, Jul 05, 2019, 8:03 PM UTC

pjmlp wrote: post #88

Chyzwar wrote: post #8

In mature OOP you have ways to write nice models and have good validations. https://guides.rubyonrails.org/active_record_validations.htm... I will argue that the complexity of software development is not because of OOP vs Functional. Tooling, documentation, quality of libraries and people are what matter most. Ruby was a massive success is largely attributed to above. We are humans, we can understand and deal with a…

The irony is that Smalltalk already offered many FP patterns. In the end multi-paradim languages will win. What many FP advocates fail to acknowledge is that all FP languages that got some kind of mainstream adoption, might be FP first, but they are actually multi-paradigm.

No FP language has gotten mainstream adoption. Mainstream languages may have had FP features added, but that's different.

I confess I don't "get" the benefits of FP for the type of applications I work on. Most examples are for a domain completely different, make unrealistic assumptions about domain patterns of change that I actually see, or fill in for weaknesses of a given language's OOP model.

Re: Fighting Complexity in Software Development

#102

Post by tabtab » Fri, Jul 05, 2019, 8:09 PM UTC

yogthos wrote: post #95

In my experience, one of the best ways to fight complexity is by reducing the amount of things you have to keep in your head. In practical terms this translates into being able to do local reasoning about your code. I find that imperative OO style naturally leads to complexity. Passing references to mutable data all over the place creates tight coupling across your entire application. This makes it impossible to guar…

Much of the time the "big picture" isn't local. That's just the nature of the big picture by definition. I find it better to put "big picture" stuff in the RDBMS, including UI issues (see "Table-Oriented" nearby), and keep only local details in code.

For example, the menus and navigation can almost all be tracked and managed in the RDBMS. It's easier to query and study the structure that way because I can sort, search, group, and filter it by any way --I-- please for any given need; I don't want to be stuck with YOUR single grouping; I want to be the Grouping God when studying the app. File-centric code can't do that (at least not without an IDE that reinvents a database). Therefore, don't do it. Use code where code is best, and RDBMS where RDBMS is best.

Code sucks at the big-picture and FP won't change that.

Re: Fighting Complexity in Software Development

#103

Post by pjmlp » Fri, Jul 05, 2019, 8:53 PM UTC

tabtab wrote: post #101

pjmlp wrote: post #88

Earlier quoted context omitted.

The irony is that Smalltalk already offered many FP patterns. In the end multi-paradim languages will win. What many FP advocates fail to acknowledge is that all FP languages that got some kind of mainstream adoption, might be FP first, but they are actually multi-paradigm.

No FP language has gotten mainstream adoption. Mainstream languages may have had FP features added, but that's different. I confess I don't "get" the benefits of FP for the type of applications I work on. Most examples are for a domain completely different, make unrealistic assumptions about domain patterns of change that I actually see, or fill in for weaknesses of a given language's OOP model.

I mean those FP languages that enjoy some commercial use like Common Lisp, Clojure, Scala, F#, OCaml and Haskell.

All of them also expose OOP concepts.

Re: Fighting Complexity in Software Development

#104

Post by tabtab » Fri, Jul 05, 2019, 9:37 PM UTC

pjmlp wrote: post #103

tabtab wrote: post #101

Earlier quoted context omitted.

No FP language has gotten mainstream adoption. Mainstream languages may have had FP features added, but that's different. I confess I don't "get" the benefits of FP for the type of applications I work on. Most examples are for a domain completely different, make unrealistic assumptions about domain patterns of change that I actually see, or fill in for weaknesses of a given language's OOP model.

I mean those FP languages that enjoy some commercial use like Common Lisp, Clojure, Scala, F#, OCaml and Haskell. All of them also expose OOP concepts.

Lisp is flexible enough to be just about every paradigm. Too much flexibly can be a problem in some circumstances, but I don't want to get into yet another "Lisp fight" here about that. There are hundreds on the internet already.

Re: Fighting Complexity in Software Development

#105

Post by apta » Sat, Jul 06, 2019, 12:31 AM UTC

Chyzwar wrote: post #8

In mature OOP you have ways to write nice models and have good validations. https://guides.rubyonrails.org/active_record_validations.htm... I will argue that the complexity of software development is not because of OOP vs Functional. Tooling, documentation, quality of libraries and people are what matter most. Ruby was a massive success is largely attributed to above. We are humans, we can understand and deal with a…

This is already achievable using annotations in Java or attributes in C#, in a less verbose way. You just tag your method parameter with `@Valid` or `[Valid]` or what have you, and the framework you're using automatically ensures that the validations you specified on the data model are valid at that point in time.

Re: Fighting Complexity in Software Development

#106

Post by taeric » Sat, Jul 06, 2019, 3:05 AM UTC

jes5199 wrote: post #42

taeric wrote: post #39

Earlier quoted context omitted.

Have you maintained anything after the first year where that wasn't the case? Especially if you had a high degree of churn on the developers. I'll grant that it is easier in more stable API environments. But we are our own worst enemies in that race.

if I pick up an old Java project, it might be a mess, but I'll be able to rename methods, refactor classes, and upgrade libraries until it gets into shape - and I'll have a fair amount of confidence that it'll keep working while I do that, because metaprogramming is rare, APIs are fairly stable, and the IDE will mostly be able to understand what the code is doing. In a ruby project - especially in a Rails project - y…

Apologies for the slow response.

I honestly can't compare to a rails app, as I don't have the experience. I can say that modern dev practices worry me with the constant upgrade train on api standards. On the one side, progress is quite nice. On the flipside, what you describe in "all your dependencies have completely changed their APIs" is just as annoying in Java as it is in any language. More so if someone has helpfully split your codebase into as many supposedly independent parts as they can.

More than that, it is amusing that many of the refactoring tools that you reference actually began in more dynamic languages. I've seen that folks that rely on their IDE to be able to refactor have a habit of making codebases that they have to use an IDE to refactor. I grant it could just be confirmation bias.

Re: Fighting Complexity in Software Development

#107

Post by yogthos » Sat, Jul 06, 2019, 3:09 AM UTC

petra wrote: post #97

yogthos wrote: post #95

In my experience, one of the best ways to fight complexity is by reducing the amount of things you have to keep in your head. In practical terms this translates into being able to do local reasoning about your code. I find that imperative OO style naturally leads to complexity. Passing references to mutable data all over the place creates tight coupling across your entire application. This makes it impossible to guar…

Reasoning locally, means maintenance on FP software should be easy. So beginners could solve simple bugs and add simple features to FP applications. Yet it's not a common thing. Why ?

My team regularly hires co-op students who have no trouble solving all kinds of problems, as well as implementing features. I'm not sure where you get the notion that it's not a common thing?

Re: Fighting Complexity in Software Development

#108

Post by yogthos » Sat, Jul 06, 2019, 3:11 AM UTC

tabtab wrote: post #102

yogthos wrote: post #95

In my experience, one of the best ways to fight complexity is by reducing the amount of things you have to keep in your head. In practical terms this translates into being able to do local reasoning about your code. I find that imperative OO style naturally leads to complexity. Passing references to mutable data all over the place creates tight coupling across your entire application. This makes it impossible to guar…

Much of the time the "big picture" isn't local. That's just the nature of the big picture by definition. I find it better to put "big picture" stuff in the RDBMS, including UI issues (see "Table-Oriented" nearby), and keep only local details in code. For example, the menus and navigation can almost all be tracked and managed in the RDBMS. It's easier to query and study the structure that way because I can sort, searc…

I honestly have no idea what you're talking about.

Re: Fighting Complexity in Software Development

#109

Post by james_s_tayler » Sat, Jul 06, 2019, 5:51 AM UTC

wayoutthere wrote: post #83

jaequery wrote: post #46

Earlier quoted context omitted.

30M. Well there’s your problem. I can just imagine the premature optimizations and the bloated abstraction that went in the planning phases.

Yeah, welcome to enterprise development (regardless of programming language). Every VP fancies themselves as the next Steve Jobs and like to be uncompromising about delivering their vision. Which ironically ends up as design by committee when you have that many assholes in a room unwilling to back down but also needing to save face. And to be fair, most of the premature optimization and bloated abstractions are just…

It's not even about programming languages at this point. It's Peopleware. People are the number 1 cause of all problems in software.

Re: Fighting Complexity in Software Development

#110

Post by james_s_tayler » Sat, Jul 06, 2019, 6:09 AM UTC

eloff wrote: post #7

austincheney wrote: post #3

Perhaps the best way to take this seriously is to ensure developers RTFC (Read The Fucking Code). While that sounds like a given it’s taken for granted that developers actually do that before forming all manners of biased or incomplete assumptions.

That's necessary, but the aim of good software practice should be to make it as easy as possible for the reader of the code to follow and understand it. Including skipping over well named functions which should not nest unintuitive behavior.

This. All day long.

On the current code base I work on I swear every single one of my pull requests contains large amounts of variable and method renaming to make it easier for the next person because if it takes me half a day to compute an understanding of what "var result = apiTotal - total" is actually doing then it isn't named nearly clearly enough.