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

Please do not attempt to simplify this code

github.com

Post reply on HN
Print view View original

631–640 of 647 posts

Re: Please do not attempt to simplify this code

#631

Post by pas »

Dylan16807 wrote: post #218
TeMPOraL wrote: post #111

Earlier quoted context omitted.

> It's certainly not that McDonald's makes better (or "simpler") hamburgers At the risk of derailing the thread, that would be the lesson I wish people would take away from that example. Criticizing fast food like that is dumb signalling IMO; McDonald's!hamburger != homemade!hamburger. It's an entirely different product sharing the same name and some of the ingredients. It tastes different, and has a different form f…

Plenty of places can get me a significantly better burger in under a minute. McDonald's is not high up inside its category .

Among my circle of friends it is. People either like it or not, and if they like let's say the BigMac they either want that or not, but wouldn't really substitute it with a Burger King Whopper or a KFC Grander. They usually like that too (more or less, depending on the individual), but that's then a conscious decision to okay, let's eat something different. Even if the burger is in the name.

Re: Please do not attempt to simplify this code

#632

Post by pas »

coldtea wrote: post #116
endymi0n wrote: post #50

Earlier quoted context omitted.

I know a business coach who regularly asks his audience "Who here makes better burgers than McDonalds?". When half the audience raises their hand, he asks them why they don't outsell this giant company. Functional programming advocats, especially for the "pure" ones like Haskell, always strike me as odd. It seems that all the beauty of those languages make people obsess over that beauty and purity while keeping them…

> But the closest I ever came to using a functionally developed product was RabbitMQ (written in Erlang). That one was _such_ a pain to use and operate — must have been the developers still dreaming in the purity of its code instead of writing some installation docs. I moved on to Kafka later and didn't regret it a minute. Err, RabbitMQ is one of the easiest to setup and stabler queues/messaging systems. And I'm no u…

I found Kafka easier to set up. RabbitMQ is a bit finicky when it comes to config, monitoring, administration, but it's pretty okay, and works well enough if you really need AMQP semantics (selective ack of messages).

Re: Please do not attempt to simplify this code

#634

Post by yawaramin »

mrgriffin wrote: post #515
usrusr wrote: post #174

Earlier quoted context omitted.

Java (like many other languages of that generation) suffers from a lack of idiomatic 1:1 visibility. Whenever you split something up in Java it litters a namespace that is much bigger than necessary. Even private is too big when the class is full of tiny methods most of which most will never be meaningful to any of their peers except for that one call site. Sure, you can create inner function objects and with 8+ it's…

One of my favorite features of Haskell is that I can use where to write the auxiliary function definitions after the code that use them, but keep them scoped inside of a single function. A relatively bad example here: https://wiki.haskell.org/Worker_wrapper#Hiding_the_worker

Bindings in the `where` clause can still access names in the main binding: https://wiki.haskell.org/Let_vs._Where#Advantages_of_where

This runs the risk of strongly coupling them to the main binding and making them less reusable. IMHO strong coupling where two bindings are aware of each others' internals should be avoided.

Re: Please do not attempt to simplify this code

#635

Post by nickharr »

pas wrote: post #627
xixixao wrote: post #494

Earlier quoted context omitted.

Here’s a great practice: 1. Write some piece of code 2. Now write a comment about it 3. Is the comment adding more information, making the code more clear? If Yes: Put that information into the code. Rename variables. Pull out code into subroutines. If No: Delete the comment. You’ll be amazed at how often this practice works. Doing it all the time will make your code more readable. We have a second, enforced practice…

There are concerns and aspects of software engineering that are important to document but don't sit well in code, but they become important when reading / maintaining that code. Design decisions (implementation details), specification details, other design or engineering constraints. And of course business modeling fundamentals and constraints. Sure, in theory, you can do everything in code, but I find that usually t…

I would never suggest documentation in code alone... Your point is very much noted, echoed and a hat-tip to you here. Yes, documentation is incredibly important, and it should be used as an driver/accompaniment along with comments.

Re: Please do not attempt to simplify this code

#636

Post by erikpukinskis »

bb88 wrote: post #108
Klathmon wrote: post #21

I love this! It's the "jazz music" of software development. Something which breaks all the "rules" but does so purposefully and explicitly so that it can become better than the "rules" allow. A naive look at this and my head is screaming that this file is way too big, has way too many branches and nested if statements, has a lot of "pointless comments" that just describe what the line or few lines around it is doing,…

> A naive look at this and my head is screaming that this file is way too big, has way too many branches and nested if statements. A naive look at this and my head is screaming that this file is way too big, has way too many branches and nested if statements, has a lot of "pointless comments" that just describe what the line or few lines around it is doing, and has a lot of "logic" in the comments which could quickly…

This is why I prefer older JavaScript to the more recent stuff, with transpiration pipelines and AI-like optimizing compilers that gnaw on giant state trees.

That stuff is lovely and terse when it works. And when it doesn’t you are at a total loss.

The beauty of imperative code is there’s a beginning and an end, and at every step you can easily see what follows and without too much work what came before.

Re: Please do not attempt to simplify this code

#637

Post by nickharr »

pas wrote: post #629
majikandy wrote: post #617

Earlier quoted context omitted.

Well said, I was cringing when I was reading the bad advice and you addressed the points very well. It is so frustrating to hear when someone thinks commenting more and adding humour is somehow cleaning up the code. But to then hear that they are teaching this to juniors just hurts so much. Simpler advice to juniors would be to read Clean Code by Robert C Martin, apply some of those techniques and then politely ignor…

I disagree with nickharr's opinion on humor just as starkly as you, but agree with the need for comments very much. And his/her point still stands regardless of how much you name and group functions. There are concerns and aspects (design/engineering decisions become implementation details that might need rationale) that can't be presented efficiently that way. (Workarounds for issues benefit a lot from links to the…

Point taken, but my point wasn't about adding humor as some form of default - just something that's amusing to come across when you find it as a developer and where others have struggled/suffered. You are reading too much into it, but appreciate I wasn't clear enough in my initial description.

Re: Please do not attempt to simplify this code

#638

Post by yawaramin »

bb88 wrote: post #607
Tehnix wrote: post #421

Earlier quoted context omitted.

> It comes down to trust. You're either fucking with your code in a powerful programming language that lets you do everything, or your fucking with the language restrictions to get your code to compile in the first place. > ...or your fucking with the language restrictions to get your code to compile in the first place I think that's a wrong and outdated view on strong type systems. A good type system is also an ergo…

> I think that's a wrong and outdated view on strong type systems. I wasn't really talking about type systems specifically, I was thinking along the lines of the Rust borrow checker here, and lower level programming like assembly and C. > A good type system is also an ergonomic one. What people start to experience is that the compiler is actually a friend that helps you write code and keep yourself true to your own p…

You don't write the compiler, of course, but you do write or rather design the types that your program uses. The typechecker ensures that they're consistent within the system of logic that they set up.

By your logic, it's not enough to have faith in unit tests because you wrote them; you must also write the test framework and runner.

Re: Please do not attempt to simplify this code

#639

Post by yawaramin »

jamougha wrote: post #522
willtim wrote: post #425

Earlier quoted context omitted.

The lack of "generics" (parametric polymorphism) in Go has certainly made the incidental complexity in Kubenetes much higher: https://medium.com/@arschles/go-experience-report-generics-i... Go and Haskell are really at different ends of a spectrum. Haskell is a very high level language, which makes building and reasoning about very complex software much easier (at the expense of a learning curve and fine control of s…

Ocaml has a GIL. I've worked with people trying to build a distributed system in a language with a GIL and do not recommend it.

OCaml will lose the GIL when multicore lands in ... the next few years I guess :-)

Re: Please do not attempt to simplify this code

#640

Post by yawaramin »

shados wrote: post #284
atrocious wrote: post #84

Earlier quoted context omitted.

Which metrics?

Amount of bugs that end up in production. A reasonably important and easy to measure metric.

Not really that easy. The amount of production bugs that end up getting measured are the ones that got reported, there are an unknown (and unknowable) number of unreported bugs that you never measure.
Post reply on HN