Please do not attempt to simplify this code • Hacker News Board

Re: Please do not attempt to simplify this code

#571

Post by szemet » Fri, Dec 28, 2018, 4:45 PM UTC

AstralStorm wrote: post #532

szemet wrote: post #499

Earlier quoted context omitted.

I have read an extreme counter-opinion in some J or APL article. It said that it is a bad pactice to name small and common functions: The example was maybe the average function - and the reasoning was, if I recall correctly: 1. The defintion is shorter then the name average ;) 2. Every praticioning programmer will recognise the definition as a common idiom 3. From the definition it is immediately clear how corner cas…

Allegedly. And then you suddenly want to write a SIMD version of an average or optimize it... Mass search and replace time? That'd bloat the code a lot. Common repeated well defined and mostly immutable code is best left as functions. This is why for example in C strcmp exists instead of everyone writing a two-liner - and the specialized variant gives big performance gains.

I've got your point.

Just for the sake of nitpicking: both your actual examples have been solved by compilers automatically.

SIMD/AVX: https://code.jsoftware.com/wiki/Guides/AVX

JVM generates vectorized string instructions from your simple for cycles - if availabe: http://jcdav.is/2016/09/01/How-the-JVM-compares-your-strings...

edit: my second example link is maybe wrong, but anyway, auto-vectorization is a real thing...

Re: Please do not attempt to simplify this code

#572

Post by hodgesrm » Fri, Dec 28, 2018, 4:51 PM UTC

AlexCoventry wrote: post #286

hodgesrm wrote: post #240

Earlier quoted context omitted.

I really enjoyed the Ousterhout book as well. It's my current user manual for reviewing pull requests. Putting my PR reviewer hat on I would say the code in question would pass muster if it were relatively stable so you would not be constantly redoing the comments. I love nice comments but Golang does not give you much help keeping them in sync. (Weirdly enough I'm working on a PR for persistent volume documentation…

> Golang does not give you much help keeping them in sync. What do you have in mind, here? Something like python's doctest?

Javadoc. It generates warnings if method argument documentation does not line up with the method signature, for example.

Re: Please do not attempt to simplify this code

#573

Post by geodel » Fri, Dec 28, 2018, 4:56 PM UTC

lmm wrote: post #550

barrkel wrote: post #521

Earlier quoted context omitted.

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

What language you have in mind? All the languages I have known or used are drastically unsuited for one or other thing. So they all seem not worth using.

Re: Please do not attempt to simplify this code

#574

Post by BurningFrog » Fri, Dec 28, 2018, 4:57 PM UTC

TeMPOraL wrote: post #336

BurningFrog wrote: post #325

Earlier quoted context omitted.

Sure. In sane code the name of the function should describe what they do well enough that you rarely have to click in to learn how they do it. Or something like that...

That applies recursively to the function you're just reading :). I.e. I wouldn't be inside a particular function of a particular module if I didn't have to know something about its implementation. There's a good chance I need to understand all of it at the level of abstraction of the module (often because I'm supposed to change something about it). Making that less painful leads to better and less bug-inducing experi…

You seem to be arguing against the concept of functions in general here.

That's probably not what you mean to say, but I don't find much to really discuss here.

I do like local functions in Python, but I don't see a huge difference from having the called function right below the calling one.

Re: Please do not attempt to simplify this code

#575

Post by toastking » Fri, Dec 28, 2018, 5:02 PM UTC

This is pretty smart given the nature of open source. It's a good safeguard for someone messing with code that runs like half of cloud deployments now.

Re: Please do not attempt to simplify this code

#576

Post by boomlinde » Fri, Dec 28, 2018, 5:05 PM UTC

fogetti wrote: post #545

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.

I don't think that anyone here believes that comment rot is a good thing, or that they are particularly "blinded". I just think that the fact that the comments lie is a compelling argument against the prose comment-heavy style used in this file. In this case it was not a big one because it's trivial to determine that the comment is not true, but in general I think that no comment is better than the wrong comment.

I have not cared to read the file much further so I can't comment on whether comment rot is really prevalent.

Actual "space shuttle code" is AFAIK built to satisfy a specification, not to serve as a specification in itself. When you find that the specification is lacking or somehow faulty, you get the people responsible for it to revise it, wait for the new revision and adjust the code to match. The key is that they are two separate processes. Someone responsible for the specification doesn't need to be concerned with the exact details of the implementation, and those responsible for the implementation only need to be concerned with satisfying the specification.

When the specification and implementation is all mixed up as prose and code in the same file you don't get to enjoy the benefits of separating those concerns. Changing the spec is the same process as changing the code, and the order of change is indistinguishable. You can change some code, but then you have to find all the references to the code you changed in the prose and adjust that too. You can change the prose, but then you have to adjust the code accordingly and any prose that assumed that the code worked as before. You'll be relying on tests and reviews (reviewers suffering the same drawbacks as the submitter) to enforce this, which IMO isn't not necessarily a bad thing, but not exactly rigorous enough to give a "space shuttle" stamp.

Re: Please do not attempt to simplify this code

#577

Post by pdpi » Fri, Dec 28, 2018, 5:06 PM UTC

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…

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

I think the major point you're missing here is that the whole point of pushing monads as a core abstraction is the way they shift what "different things" means.

Re: Please do not attempt to simplify this code

#578

Post by allemagne » Fri, Dec 28, 2018, 5:11 PM UTC

weberc2 wrote: post #547

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…

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

In my limited experience with functional programming, I've come away with the impression that the problems you're describing are why you don't see a lot of companies that use FP exclusively.

But I think the advantages that OP is lauding are also there, and "space shuttle code" might just be where it shines. Reading that comment in this post made me immediately think of Haskell. The Clojure components at my company fits the "space shuttle" description of importance, and its dependability is striking compared to the rest of our code. Part of it may be that being written in a different language allows its concerns to be separate from the rest of the application too, but I do think the FP paradigm is simply good in this domain.

Re: Please do not attempt to simplify this code

#579

Post by AlexCoventry » Fri, Dec 28, 2018, 5:24 PM UTC

aardvark291 wrote: post #380

punnerud wrote: post #188

Earlier quoted context omitted.

Note to others: 3rd order is not necessarily 10^10^10. It can easily be 10^100^1000.

I hope you mean x (multiplication) rather than ^ (exponentiation). If we're talking about fanout (each of 10 items of has 10 subitems, each of which has 10 subitems), multiplication is the relevant operation. And 10^(10^10) or (10^10)^10 is a hopelessly, uselessly, inconceivably large number. (Exponentiation is not associative; 3^(3^3)=3^9= 19683 while (3^3)^3=9^3=729.)

I took it to mean something fairly vague about potential super-exponential blowup in the complexity of the states you have to reason about, when you have to reason directly about third-order effects in a code base.

Re: Please do not attempt to simplify this code

#580

Post by weberc2 » Fri, Dec 28, 2018, 5:37 PM UTC

allemagne wrote: post #578

weberc2 wrote: post #547

Earlier quoted context omitted.

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

In my limited experience with functional programming, I've come away with the impression that the problems you're describing are why you don't see a lot of companies that use FP exclusively. But I think the advantages that OP is lauding are also there, and "space shuttle code" might just be where it shines. Reading that comment in this post made me immediately think of Haskell. The Clojure components at my company fi…

Sure, but I doubt all of Kubernetes is written in this style, so it’s probably not worth writing everything in Haskell. Note also that there’s nothing about FP that prohibits it from addressing the aforementioned practical problems. Some Haskell-like could swoop in and totally steal Go’s lunch if they would simply prioritize practicality over experimentation.