Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fighting Complexity in Software Development

github.com

Post reply on HN
Print view View original

71–80 of 117 posts

Re: Fighting Complexity in Software Development

#71

Post by collyw »

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.

Having recently jumped into a project with MongoDb as the database, I have realized how much easier a schema definition makes understanding the project. It's so much easier to understand a number of create table statements than it is to get that information from code.

Re: Fighting Complexity in Software Development

#73

Post by jorams »

hardwaresofton wrote: post #70

I really support this kind of writing, I don't think this kind of stuff is written about enough, and it's exactly what everyone learns the hard way working on software projects. Skill wise, knowing the kinds of reasoning/techniques that articles like these discuss is the difference between "junior" and "senior" developers (though I very much dislike those terms). One thing I want to point out -- if at all possible do…

> The problem here is that decimal is the wrong type for storing money

Note that the code here is .NET, where decimal is a type explicitly for use in financial calculations[0]. It is still floating point, which means you still need to really watch what you are doing, but it's very high precision.

In general though, if your application allows for it, you should store money using integers representing cents (or the relevant smallest unit for the currency).

[0]: https://docs.microsoft.com/en-us/dotnet/csharp/language-refe... (this is a page for C#, but it is more useful than the general page for Decimal)

Re: Fighting Complexity in Software Development

#74

Post by twhitmore »

Is it just me? I feel this is confused and adding complexity in some areas, not genuinely optimal for simplicity.

I tend to feel that unexpected, unrecoverable exceptions are best treated as just that -- exceptions. Applying a C-style function return value check seems backwards.

And the "Interpreter"?? Proper purpose of Interpreter or DSL is for dynamic (configurable or user-input) code, not to implement basic sequential flow and the 'if' statement which the underlying language already provides.

Re: Fighting Complexity in Software Development

#75

Post by sasmithjr »

avinium wrote: post #36
lacampbell wrote: post #16

Earlier quoted context omitted.

Hi, thanks for the open minded response. It's an issue I enjoy discussing. You could use Fable to transpile F# to Javascript, keeping a single language That seems like another explosion of complexity. Source maps, mapping F# to a JS constructs when debugging, niche tooling, wrapping other JS libraries in a nicely typed F# package... IME it's best to avoid transpiling anything more exotic than typescript. FSI is avail…

I think these usually end up with two people agreeing to disagree :) Yes, you do lose source maps by transpiling, but in my (albeit fairly limited experience), the type checking means I have drastically less debugging to do in the first place. You're right, though, the tooling leaves a lot to be desired (and this is also on the assumption you have TS definitions for third party libraries - I agree it becomes a lot mo…

I'm able to use FSI with the core-sdk 2.2.300, but I believe FSI is still in preview regardless of which SDK you're using.

Re: Fighting Complexity in Software Development

#76

Post by fnordsensei »

cottsak wrote: post #28
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…

Agree. You can write terse, maintainable, well encapsulated, testable and readable code in most any language. The problem is about the humans not the language they select. But yes, complexity is also a major problem.

On the other hand, it seems a bit wild to propose that tools don’t have inherent affordances of their own.

What complicates assessment is that for many attributes, it’s impossible to assess the tool and the user in isolation. This is not unique to programming languages.

Re: Fighting Complexity in Software Development

#77

Post by joe_fishfish »

agumonkey wrote: post #65
gitgud wrote: post #56

Earlier quoted context omitted.

I attribute this almost entirely to sum types (Rust enums), a better type system, an unforgiving compiler, async/await, a better module system, lifetime checking... This seems like an example of a language effectively abstracting common complexities and pain points, which were probably discovered in earlier languages...

I think it's fair to say that rust is the first mainstream languages bringing these notions out of the woods. Who on earth knows about ML or cyclone ? 0.0001% of the programming crowd maybe. World operates in spirals. We branch off trying things and then go back to old forgotten ideas, etc etc

Kotlin has sealed classes which are basically the same as Rust's enums. It also has async / await in the form of coroutines and a decent module system. It also doesn't need manual memory management, which while unsuitable for many applications does remove another potential class of bugs.

Re: Fighting Complexity in Software Development

#78

Post by tomp »

pytester wrote: post #62
alkonaut wrote: post #58

Earlier quoted context omitted.

What I have learned is that what makes a language (or platform, or tool) "good" isn't how easy it is to write good code, but how hard it is to write bad code. Does a beginner following the path of least resistence, on a tight schedule, end up with maintainable code or not? I'd argue that this is the weakness with (the traditional) OO languages. An experienced developer with plenty of time can write good software with…

>isn't how easy it is to write good code, but how hard it is to write bad code In many languages they make it harder to write bad code but they do so at the expense of delivering functionality quickly. There's a clear trade off there - one which is often very project dependent (some projects primarily need to develop functionality quickly; others prioritize stability). The problem of slowing down development becomes…

> some projects primarily need to develop functionality quickly; others prioritize stability

But they get the ballance completely wrong. In Python, I can just write code that returns some object or None (Python equivalent of null). In Java/C/C++ I can't - I have to appease the type system (i.e. declare the return type), but there is also no way to even later tell the compiler that it can't be null!

Re: Fighting Complexity in Software Development

#79

Post by michaelcampbell »

tannhaeuser wrote: post #44
jes5199 wrote: post #42

Earlier quoted context omitted.

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…

> metaprogramming is rare In Java? Not really. Spring has been around since 2003 or so.

Having a framework do metaprogramming, and using that framework is one thing. I think that they mean user-level metaprogramming. This is MUCH more evident in dynamic languages.

Re: Fighting Complexity in Software Development

#80

Post by jshowa3 »

An excellent click bait article for functional programming. For example, the brief talk of validators, why couldn't you just put the validator in the credit card object? The credit card validator should only be used in the credit card object so the discussion about not being able to see it can be accessed by simply navigating to the classes that compose the credit card. Putting it in the constructor or other credit card methods fixes the not being forced aspect (when I look at the FP example, it looks like it's doing just this). And you can use the validator anywhere in the CC object.
Post reply on HN