edejong

I think there is an important difference between anticipating abstractions and actually abstracting.

In your example, you were actually implementing an abstraction and anticipating a future use. That is something completely different.

What I am trying to bring across is: there are multiple 'simplest' solutions. It helps to know how, in the future, you are expecting to abstract away from that solution to newer 'simplest' solutions.

For example, one might want to use a FP-ish approach, because simplest solutions within that space tend to abstract better than an OOP approach. Or in the recipe example, we could have modeled the steps as objects with dependencies. Given the right programming language, that solution might be as simple as the OP, but provide many more extension points.

That's exactly the point I want to bring across. As simple as possible, but not simpler. However, solving one problem, but causing dozens down the line is not engineering, even though your problem is 'the simplest'.

You see, in the 'problem solution lattice' there are multiple bottoms [1] (most simple solution). Knowing which 'simplest solution' is the best, depends on your knowledge of the problem, your anticipation on how the problem might be extended in the future, your array of possible solutions, etc. etc.

For example, the original solution to the recipe problem in OP uses a very sequential and object oriented approach. That solution is one of the infinite number of solutions that fixes the problem. The extension of the problem (an extra recipe) plots a graph upwards through the latice towards another solution that fixes both the original problem, as well as the new problem. The number of steps required (the distance) is dependent on choice of the original solution. And since there are multiple bottoms, we could have a solution that is not able to be further simplified, even though there is a parallel bottom, that has a much shorter distance to the second solution.

[1] https://en.wikipedia.org/wiki/Lattice_(order)

Well, that’s programming: it’s not about proving one point. It’s about proving every possible point. The level of ability to abstract should be much higher than the ability to add an extra recipe.

I tend to think people underestimate the hidden complexity of sequential programming. Each statement has a potential, opaque effect on the complete state.

To prove anything in the OP solution would be extremely complex. To extract new knowledge and abstract the solution in the future would be nearly impossible without a complete rewrite.

For example: what if we need logging? Timing of the steps taken? A list of dish washing tasks generated? Parallelism in the tasks, given an extra cook? Exception control? Unit testing of the dough?

Adding an extra recipe is not the only possible new requirement you can have. Anticipating and preparing the right abstractions, that’s what good software engineering is about.

Although I’ve seen numerous examples of hubris by creating accidental complexity, I actually think category theory is an exercise in minimalism. But the realization only happens when understanding the complexity of ‘normal’ imperative and object oriented programming.

The problem with category theory, as I see it, happens due to a mismatch with our mode of creating. We tend to converge in our solutions from chaos to order. Formal systems don’t provide space to be chaotic in. We need to be right the first time.

We need languages and IDEs that will help us find abstractions. Static analysis saying: “this thing here is like all those other things if only you see it like so. Perhaps you want to structure it like those other things as well?”

Is the paper "NN-sort: Neural Network based Data Distribution-aware Sorting" [1] not a year prior to the cited paper? It seems to discuss the same approach.

[1] NN-sort: Neural Network based Data Distribution-aware Sorting: https://arxiv.org/pdf/1907.08817.pdf

I’m sorry to say so, but I find these kind of conditions discriminating to those who have a family.

The most redeeming feature is that normal cloud providers have a zero friction onboarding funnel whereas IBM seems to make you want to meet as many “sales engineers” as possible.

dx of points over time.

Bit late to the game. Only when the company is in existential crisis it knows how to act. First step: restore trust with potential customers after gambling it all away with dirty sales tactics.

After a long search, we found two workable 'office neutral' solutions: Virbela and its successor FrameVR. I'll be online on FrameVR in my own personal frame at: https://framevr.io/testerdetest Please use headphones, because the echo-cancelation is a bit iffy.

Wow, do you get paid for being on call during the weekends?

I guess the HN audience has voted. The result is: hacking around Excel stupidities is itself a stupid idea.

If you want Excel to understand your output, perhaps use a library which can write xlsx files.

Excel devs, do you hear me? Repent for your sins! Go back to Microsoft and fix those problems. The cost of Excel mishandling numbers and dates must be many orders of magnitude higher than your lifetime salary.

Thank you.

Yes, we've all used that abstraction. And it is a lousy one. For starters, the novice interpretation of a PC are peripherals (mouse, screen, keyboard, wifi) with a GUI and then down from there. Your abstraction starts without a screen, without a terminal even.

It's a bad interpretation because the abstraction level is arbitrary. GUI applications? No. Terminal, yes, but we need to automate. Wifi? No, we virtualize the network. DNS? Depends, in k8s it is used for service discovery. Tooling? Package manager: yes. Network Center? No. Firewalls? I don't think so.

So, what constitutes a 'fresh linux install'? Why are there different distros (archlinux, ubuntu, alpine)?

What are the contracts for such a Docker image? Should it be secured? How is input and output arranged on the Docker image? What if I want to use a smarter way for logging (using UDP packets to a discoverable logging provider), can I tell all my Docker images to start using that?

How about monitoring and reliability? What constitutes a failed docker image? How do I detect it?

An abstraction is only good when it covers 99% of the underlying complexity. This abstraction is so leaky, it is more of a burden. Especially to beginners, who now are tasked with understanding Docker and understanding the limits of the abstraction.

Good technologies are explainable through solid abstractions. They are not 'leaky'. For me, Docker and k8s are so complicated because they are based on leaky abstractions and not hiding the underlying complexity sufficiently.

Edsger Wybe Dijkstra in 1982 on "users" [1] (please read the rest of the EWD as it is too much to paste here):

"The computer “user” isn’t a real person of flesh and blood, with passions and brains. No, he is a mythical figure, and not a very pleasant one either. A kind of mongrel with money but without taste, an ugly caricature that is very uninspiring to work for. He is, as a matter of fact, such an uninspiring idiot that his stupidity alone is a sufficient explanation for the ugliness of most computer systems. And oh! Is he uneducated! That is perhaps his most depressing characteristic. He is equally education-resistant as another equally mythical bore, “the average programmer”, whose solid stupidity is the greatest barrier to progress in programming. "

[1] https://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/E...

At the time it was quite sensible. Many in the target audience were computer illiterate or beginners. The context menu is not discoverable and is counter intuitive to the point and touch metaphor. In addition, most of the right mouse button actions can be replaced by a two click alternative. Finally, the modifier keys can be used for power users.

Related question: what would be the best way to store such a value? A float would only use the mantissa-bits, so it would be rather inefficient. Perhaps as a uint16 with a representation of uint16 / (2^16)?

I don’t know about bemmu, but I was. Ended up being a creator there.

Library dependencies, such as managed by Conda or Pip (from PyPI). Any change in the expected interface from a dependency to your depickled objects will create an error.

I author package "FooBar". FooBar creates objects of type "Baz" which will later be serialized by you, the FooBar user. Within the FooBar package: "def show(baz)" taking a Baz and displaying it. When I decide at one point to add an extra attribute to my "Baz" objects, I cannot (or should be extra careful) to use that attribute within that method if I expect the "Baz" objects to be pickled. This situation can be unpredictable and cause hard to track errors.

Pickle's greatest flaw is the complete lack of forward and backward compatibility. The compatibility is not guaranteed between when upgrading any of the dependencies. Dependencies should stay the same over releases, halting forward progress in the development process.

I just have to reply because of that last sentence. I totally forgot that feeling until now. Each rendered frame, the side scrolling, the pixelated sprites (not rectangular, but smoothed due to the CRT). Ignorance is bliss...

Really nice! Just got a chance to watch it. Such a nice explanation and he gives very nice examples of how intonation is a puzzle and a bit of an art, even for choirs.

Oh yes, sometimes you actually notice this, often when approaching a certain note from above and below. Depending on the harmonic function, the major seconds are not always the same size and you end up singing out of tune.

So, one always tries to understand the harmonic function of the choir as a whole in relationship with the structure of the piece. For example, if tension is needed, one can sing even more towards a dissonant diminished fifth. Close harmony is all about that.

Which is why I once sang in a choir for a couple of years. Nothing beats perfect harmony.

Similarly, I was once convinced everyone in our jazz-rock band was out of tune after I had experimented with alternative tunings at home the whole day. Yeah, equal temperament is really quite a bit out of tune, but somehow we seem to manage just fine.

A piano is ever so slightly inharmonic. This is due to the rigidity of the strings. Only a massless, 100% flexible string has perfect overtones.

And the remaining 0.1% actually read some UX design textbooks from the 90's:

1. Incomprehensible icons

2. No use of color to indicate the most likely new action

3. Weird and inconsistent transitions and dialogs

4. Many different fonts, font-sizes and text decorations.

5. Flat design makes it difficult to know what to click on.

The list goes on, and on, and on. It seems the team did no UX testing at all.

Actually, Skype was designed from the start to use e2e p2p communication. First thing after the Microsoft acquisition was to remove e2e and introduce dozens of new features no-one actually asked for.

In addition, they turned the UI into a dumpster fire and allowed Chinese, Russian and United States law enforcement agencies to eavesdrop on any Skype conversation without intervention of a judge.

As long as each single project keeps reinventing their own Lego stubs, we won't be going forward with reuse.

With Haskell and Scala's type-system we seem to come closer to universal Lego. Still, like Lego, it can be hard to combine larger scale composites.

That quote is misattributed and I also think it is not something Dijkstra would have said. Quite the opposite actually. However, I think this quote from him is much more beautiful:

In their capacity as a tool, computers will be but a ripple on the surface of our culture. In their capacity as intellectual challenge, they are without precedent in the cultural history of mankind.

(Turing award lecture, 1972)