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

541–550 of 647 posts

Re: Please do not attempt to simplify this code

#541

Post by asadkn »

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…

Agreed.

One of my pet peeves is JS projects. I am not sure why but the front-end developers refuse to add any comments at all. This trend, oddly enough, started with ES6. Pre-ES6, JSDoc style comments at least, were quite common.

Just because some popular Javascript project doesn't have comments doesn't mean yours shouldn't. Straight-forward code may not need comments but most of these projects definitely need to explain why or how are things supposed to work or why things are done a certain way.

Re: Please do not attempt to simplify this code

#543

Post by weberc2 »

dajonker wrote: post #16

"it became clear that we needed to ensure that every single condition was handled and accounted for in the code" This is a feature of several (mostly functional) programming languages, e.g. Haskell. Fun to see that often people figure out that these types of concepts are a smart way to write your code. Too bad it usually means many people reinvent the wheel instead of learning about computer science history and other…

Is it possible that there are other criteria besides ADTs which factor into choosing a programming language?

Re: Please do not attempt to simplify this code

#544

Post by Antonio123123 »

rzzzt wrote: post #97
aerovistae wrote: post #57

Earlier quoted context omitted.

What is that language? edit: seems to be a custom language designed for the purpose. .agc file extension corresponds to apollo guidance computer. https://en.wikipedia.org/wiki/Apollo_Guidance_Computer

Yup, AGC assembly: https://www.ibiblio.org/apollo/assembly_language_manual.html

Restoring original Apollo AGC

https://www.youtube.com/watch?v=2KSahAoOLdU&index=1&list=PL-...

Re: Please do not attempt to simplify this code

#545

Post by fogetti »

boomlinde wrote: post #542

// 1. Every 'if' statement has a matching 'else' (exception: simple error // checks for a client API call) Comment rot? The code is filled currently with else-less if statements, not only for error checking.

Obviously there are many people on HN that consider that to be a good thing. I personally agree, this is the typical comment got. Only obviously blinded people wouldn't see this.

Re: Please do not attempt to simplify this code

#546

Post by AstralStorm »

isp wrote: post #485
dfox wrote: post #263

Earlier quoted context omitted.

There are few linux drivers for particularly buggy hardware that are written in this style. Although OTOH what I think of is hme.ko, where the comments are more on the hillariously funny side than descriptive.

I wasn't familiar with hme.ko comments, so looked it up. https://github.com/torvalds/linux/blob/master/drivers/net/et...

The kernel code is nowhere near ideal nor "space-shuttle" code. It has a ton of single use functions which is essentially the opposite.

Magic numbers and timing without explanation why. Rarely used technical descriptions such as "Lance mode". Tons of unchecked assertions on lock when kernel provides a lockdep check for this. Custom logging macros. Flies in the face of kernel "goto error" error handling convention in a few places. XXX with obvious bugs mentioned, unfixed.

And more...

Splitting it into more files wouldn't help at all.

Re: Please do not attempt to simplify this code

#547

Post by weberc2 »

Tehnix wrote: post #421
bb88 wrote: post #132

Earlier quoted context omitted.

> So yes, just because you use a functional programming language won't help you sell your widgets or make a great product. And you can spend lots of time fucking around with it for its own sake and still not sell widgets or make a great product. 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…

> 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…

Even experiences FP folks complain about how difficult it is to program in Haskell due to its purity. Further, the high barrier to entry you describe is an even bigger deal to organizations than to individuals. It’s a cost that needs to be paid for every employee. And it’s not just the language features, but FP languages tend to have issues like poor documentation, poor editor integrations, multiple standard libraries, multiple build tools, multiple string types, home-grown project file syntax, multiple preludes, many extensions, etc. All of these boost the learning curve in addition to the issues with the language itself.

Re: Please do not attempt to simplify this code

#548

Post by siculars »

3pt14159 wrote: post #277
dragonwriter wrote: post #232

Earlier quoted context omitted.

> 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. I kind of see it as the opposite: “space shuttle style” is code that adheres to heavyweight rules that most software development has abandoned in favor of a more improvisational style. But in either case it illustrates that co…

I've had this latent thought for a while that I'm finally putting to words: The complexity goes somewhere. It's either into lots tests, or it's into something like shuttle style with lots of comments, or it's into a huge QA department, or it's into the type system / DB schema. It could even be going into the org structure! But something, somewhere is handling the complexity and it is doing so as a partial function to…

This^

Re: Please do not attempt to simplify this code

#549

Post by lmm »

AstralStorm wrote: post #524
lmm wrote: post #446

Earlier quoted context omitted.

A language that spends its complexity budget well can save complexity from a lot of programs. E.g. if you look at https://philipnilsson.github.io/Badness10k/escaping-hell-wit... , language A could offer all 5 of those ad-hoc solutions (making it a very complex language) and language B could just offer monads (making it a relatively simple language), but both languages would be just as effective in alleviating the com…

And then language C(++) just skips unnecessary monads which are syntactic salt and uses exceptions, while providing the optional type for where you really, really want this behavior. Tradeoffs of course, but these were considered. The main problem here with this "solution" is that any monad looks like every other monad. You can easily lose context and have to rely on naming conventions, which is quite terrible. You c…

> And then language C(++) just skips unnecessary monads which are syntactic salt and uses exceptions

Exceptions are an ad-hoc solution to a sixth problem. You still have the other five. (Ok, it's possible to use exceptions to replace null. But that still leaves the other four).

C does not have exceptions, or any solution to error-checking hell at all. C++ is a notoriously non-simple language. Neither is at all convincing as a counterargument.

> Code that does very different things should look different, not identical.

In a language with monads, code that does things that are specific to error-handling still looks very different from code that does things that are specific to async I/O. But code that does a thing that is fundamentally the same (parametric), such as composition, looks the same. This is the very essence of programming (and indeed of mathematics): "2 + 2" does something that is, on the surface, very different from "3 + 5", yet there is an important underlying commonality. Code that sorts a list of integers is doing something that is, on the surface, very different from sorting a list of strings, but there's an important underlying commonality. Monads just take the same thing one level higher.

Re: Please do not attempt to simplify this code

#550

Post by lmm »

barrkel wrote: post #521
lmm wrote: post #458

Earlier quoted context omitted.

> That is inherently complicated. There is of course an open argument of language choice, but I think there’s something to learn from the lack of software built in $BETTER_LANGUAGE. Sometimes the best software is no software. Kubernetes exists to solve problems that people using better languages don't generally have. > It’s also an open source project, so if anyone wanted to throw up a branch with an example of simpl…

> Kubernetes exists to solve problems that people using better languages don't generally have This statement doesn't make sense, and the arrogant tone just stinks of ignorance. Kubernetes isn't perfect, but if there's better provider-agnostic language-agnostic way to dynamically scale an application written in heterogeneous languages across a cluster or on a competitive choice of cloud platforms with dynamic provisio…

In my experience the costs of language agnosticism outweigh the benefits even without considering deployment. Good languages are general-purpose; a language that is drastically unsuited to some particular thing is probably not worth using at all, and if you're using a language that is decent at most things then the overhead of switching languages is higher than the benefit of using a language that gives a small advantage in some specialised area.
Post reply on HN