Hacker News Reader

Comment by bediger4000 | Hacker News Reader

This is good to hear.

There's something like a cognitive bias that makes me leary of genetics (in any language). Once you have some cross cutting feature, generics or object orientation, or in functional programming, those functions of type 'a->'a, or assembly language address modes, people get bogged down by trying to make everything in their work generic or object oriented or "orthogonal". Lemire's example is relevant to his topic, but it could be a poster child if someone else did it. They need to sum an array of int. So they spend 4 days getting a function and a generic type that can sum every numerical type, rather than 15 minutes to sum int arrays.

What's this called?

View on HN

> They need to sum an array of int. So they spend 4 days getting a function and a generic type that can sum every numerical type, rather than 15 minutes to sum int arrays.

More likely they install a 3rd party generic sum function and don't have to write their own at all. Well, in the case of a sum function it's probably only 15 minutes to write to generic version, and there may even be one in the standard library. But consider something like a concurrent hash map. In Rust, You just `cargo add dashmap` and you have one that works with any type that works with a regular hashmap. This isn't possible without generics.

The sum example is simple, but very often have I seen people write general solutions for business logic or whatnot that you can't just get from a 3rd party package, when it wasn't at all clear that's needed. I have done this myself too.

>> They need to sum an array of int. So they spend 4 days getting a function and a generic type that can sum every numerical type, rather than 15 minutes to sum int arrays

> More likely they install a 3rd party generic sum function and don't have to write their own at all. Well, in the case of a sum function it's probably only 15 minutes to write to generic version

I'm not sure "sum over an array of int" is a great "simple" example - how do you guarantee that the result can fit in an int?

This is (one reason) why Julia implemented a full, scheme-style, numeric tower right in the core language.

Sure there are some examples where you can sum N Mbit numbers into an Mbit number, and either want overflow, or is somehow "confident" things will fit. But in general it's just lazy "no one will ever have such a large shopping cart"-design...

> This is (one reason) why Julia implemented a full, scheme-style, numeric tower right in the core language.

What's the result of adding two i32 then? Is it an i64? Doesn't the accumulator need to get wider on some additions, since adding an i64 to an i32 might also overflow an i64?

Actually, the default is overflow I now realize. But there is also automatic promotion, so:

    0 + typemax(UInt8)+ typemax(UInt8)
    510

While adding UInt8 first, then an implicit Int64 causes overflow:

    typemax(UInt8)+ typemax(UInt8)
    254

(ie: 255 overflows to 254 - or is promoted and sums to 510)

See: https://docs.julialang.org/en/v1/manual/integers-and-floatin...

Try: https://julialang.org/learning/tryjulia/

> What's this called?

The blub paradox https://wiki.c2.com/?BlubParadox

I don't think that's what the blub paradox is. I think the parent comment is arguing the opposite. People who believe in the blub paradox are usually so smug and full of themselves that they don't pursue simple solutions.

The parent commenter is dismissing generics, and various other features, as something that "bogs people down" and makes them write worse code.

This is the essence of the blub paradox, thinking that people who use a feature are simply misusing it, after all in blub you don't have generics and things are fine. They're just making things more complicated than they need to be.

The blub programmer isn't necessarily smug, they just make excuses to dismiss more powerful language features that they are not sufficiently familiar with.

Same thing happens in the other direction too e.g. Rust coders trying to use Python without familiarity with dynamic scripting languages and dismisses the whole language as a footgun (despite Rust’s learning curve being harder, for instance).

The problem with the blub argument is that it heavily relies on the existence of an undisputed power hierarchy among programming languages. Only s/he who is an expert in the most powerful language is in a position to pass judgement on all other languages.

I don't know how to resolve disputes over the relative power of programming languages on that basis. Are dynamic languages more or less powerful than static languages with advanced type systems? I don't know. What's the definition of power?

But I think what we can take from blub is that familiarity with one language or set of features is an insufficient basis for dismissing other, unfamiliar, languages or features.

Having used trait-based generics, I think that trying to piece together what's going on in typenum, the GAT stabilization process, https://hirrolot.github.io/posts/rust-is-hard-or-the-misery-..., num-traits, and variance and https://github.com/rust-lang/rust/issues/25860 is absolutely bogging me down. I feel (and observe as people try modeling contracts in traits) that trying to build code which plays well with open-ended type parameters is inherently more difficult than building a correct solution for a single type. Generally I'd prefer a more focused less generic solution which corresponds to a single function in the generated machine code (modulo inlining), except in cases where generics (over a small or open set of types) provide a clear benefit (collections are a clear example, IMO point-free .iter().map().sum() style is usually a regression in readability).

I'm not dismissing generics or object orientation or orthogonal addressing modes or 'a x 'a -> 'a functions. I am observing that there's a trap that a lot of people fall into, where they spend inordinate amounts of time making everything as generic as possible at the expense of time-to-market, and understandablity.

A good class or generic is hard to beat. Unfortunately the understanding of the details that make something a good class requires experience and experiments. Maybe I am talking about premature optimization, writ larger, or in design.

This was just discussed here in another front page post “Why DRY is the most over-rated programming principle” https://news.ycombinator.com/item?id=32010699

Writing a generic function to sum an array of any numbers type is trivial in C++. There's no 4 day research period, even if you're new to templates.

    template<class T>
    T sum(T* x, size_t size)
    {
        T acc = 0;
        for(size_t i = 0; i < size; ++i)
            acc += x[i];
        return acc;
    }

Isn't acc and the xs same width here? So you risk overflow?

Yes, obviously calculating the sum of fixed-width integers may result in overflow.

https://play.rust-lang.org/?version=stable&mode=debug&editio...

Took me five minutes, not four days…

> those functions of type 'a->'a

Polymorphism. But note that there is only one function of type 'a->'a for all 'a, and that's the identity function.

Not quite. This also has the type ‘a -> ‘a:

def nitpick(x): throw “foo”

You're right, and foo x = foo x also qualifies as 'a -> 'a. The only function that always terminates is the identity function, then.

We could throw some unsafePerformIO in there and do anything else as well, but if course we would have a function in the mathematical sense anymore.

A function in the mathematical sense is total (always terminates).

that's not a function (in the pedantic sense).

technically a partial function, or you could say that every function is really of the type A -> Exception \/ A

But you should not be writing functions that make you think about the fact that Hask is not really a category.

    func sum[Number](nums: openArray[Number]): Number =
      for num in nums:
        result += num

Took about a minute.

Premature abstraction?

'Premature Abstractulation'

I'm sorry. I had to do it. Ban me.

I'll allow it

Reply on news.ycombinator.com