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

641–647 of 647 posts

Re: Please do not attempt to simplify this code

#641

Post by cannabis_sam »

yawaramin wrote: post #634
mrgriffin wrote: post #515

Earlier quoted context omitted.

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.

Like your link says: doesn’t lambda lifting solve that problem?

That’s what I always do if I want to move an auxillary function to the top-level for reusing elsewhere.

Re: Please do not attempt to simplify this code

#642

Post by neeleshs »

StreamBright wrote: post #416
neeleshs wrote: post #306

Earlier quoted context omitted.

In my experience, Kafka has been relatively painless. Sure, it needs zookeeper. But zk has turned out to be start it and forget it kind of infrastructure for us.

Util one day ZK fails in the most spectacular way and nobody knows the internals of it and you lose data. Just because is something fine for a time does not mean that it is reliable. Without telling us how many nodes you are running ZK/Kafka on this information is useless. Others were not so lucky: https://issues.apache.org/jira/browse/ZOOKEEPER-801

I'm not claiming it's perfect. Our cluster of > 15 Kafka nodes and 3 node zk ensemble has had no major issues in over 4 years in production. That's something. And from the bug - "GC logging/tuning is clearly where I dropped the ball, just using the defaults;"

Re: Please do not attempt to simplify this code

#643

Post by tapland »

vonseel wrote: post #554
tapland wrote: post #531

Earlier quoted context omitted.

> unless one is willing to spend hours of archaeological examination Currently the only person in-office over Christmas on my first software dev job. Debugging a 50k LOC COBOL beast that digs into three other beast programs and ends up in a final 20k LOC uncommented piece where things are supposed to happen and be returned back. Nothing is commented, the programs are huge and one can only debug one program at a time,…

my first software dev job. Debugging a 50k LOC COBOL beast We found the real MVP. tapland, what were you thinking when taking this job!?

Heard about COBOL for ages, always been into retro computing and setting up z/OS on the Hercules emulator at home I was offered COBOL-training from a company and two years of guaranteed employment (with pay even if they decide I'm not needed) to join a team that force-retired 40% of their developers this year.

I have no real previous development experience, only some Java and Python, since I chose an industrial engineering program at uni, and I got the offer the semester before my CS-classes (my chosen specialization) started.

Changed my university classes to equivalent distance-classes and took six months of school to get into training and a job.

Re: Please do not attempt to simplify this code

#644

Post by yawaramin »

cannabis_sam wrote: post #641
yawaramin wrote: post #634

Earlier quoted context omitted.

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.

Like your link says: doesn’t lambda lifting solve that problem? That’s what I always do if I want to move an auxillary function to the top-level for reusing elsewhere.

Indeed, I also prefer lifting, especially internally inside a module. It jives with the idea of loose coupling, strong cohesion.

Re: Please do not attempt to simplify this code

#646

Post by thdespou »

lmm wrote: post #154
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…

> Meanwhile, people with simpler languages like Go just get stuff done that is useful and makes people happy. Kubernetes' reputation is just the opposite: that far from being a simple and useful thing, it's an overengineered, overcomplicated solution to a self-inflicted problem (deploying a distributed monolith). > But the closest I ever came to using a functionally developed product was RabbitMQ (written in Erlang).…

> Kubernetes' reputation is just the opposite: that far from being a simple and useful thing, it's an overengineered, overcomplicated solution to a self-inflicted problem (deploying a distributed monolith).

Thats why companies pay the buck to get 24/7 support. Because its that good!

Re: Please do not attempt to simplify this code

#647

Post by ptttr »

kyberias wrote: post #614
nickharr wrote: post #224

Having spent 25+ years writing, viewing, commenting on and reviewing code in a multitude of languages, this is good stuff to see - regardless of the 'style' of programming (or the language broadly-speaking). Stepping back and whilst we can all overlook it, good code comments can make an enormous difference in productivity - both for an individual, a team and indeed a business. It aids repository knowledge (something…

I think you're giving very bad advice. > On a basic level, comments should: inform, educate, outline and help others understand the sometimes complex routines and functions that we all create and often under an enormous amount of pressure. Take the time to simplify the complex routines, clean them up and make them readable and don't waste your precious time in writing "good comments". > Code can become complex, awkwa…

The worst part about comments is that they just add a cognitive load of reading and parsing extra lines of text.

What if the underlying logic changes? Do I need to update the original witty comment as well?

How do I know if the comment is still relevant? No compiler nor tests will tell me that and now I'm left with a task of parsing a language with much more degrees of freedom (English), without any support from the IDE. It becomes even harder in international teams.

Post reply on HN