Hacker News Reader

Comment by samsquire | Hacker News Reader

Finally, a chance to say what I really think about computers!

I feel that the majority of time working with computers is not actually computing numbers (addition, subtraction, multiplication) but LOGISTICS.

Logging into systems, Moving data around in memory and between servers, into registers for a function call, to and from a REST API, installing packages, finding dependencies, chaining together library functions.

View on HN

Your thinking reminds me of the work of a friend of mine. He's an AWS consultant and builds thing like AWS thinks you should. Some of the things he comes up with, chaining services together, with a sprinkle of lambda functions, it's Rube Goldberg machines all the way down.

A user logs in to a javascript app, hosted in an S3 bucket, authentication is handled by Cognito, the user gets a upload form, once their files is uploaded to S3, a lambda triggers an ECS container to spin up, some processing, output is sent to SQS where a service hosted on EKS picks up the processed data .... AND SO ON.

Rube Goldberg machines, all of it.

Exactly the term I had in mind: Rube Goldberg. And it gets so much worse than the examples you've given. Trying to shoehorn all the leaky abstractions together across the dozens or hundreds of pieces of technology I use every day from different vendors and open-source projects, with each interaction having hundreds of arcane failure modes, is absolutely soul-sucking. I'm impressed by the people who still do it, regardless of how much they earn for doing so.

> it's Rube Goldberg machines all the way down

On another context, you have some processed data on the backend, and an infinitely customizable software system on the frontend... How do you keep them both in sync?

And yeah, it is by converting your data into a programing language; parsing it again; resolving incompatibilities; turning it into the presentation language; letting the user interact with the presentation representation; converting it back into the programing language; sending it back into the backend... But then you don't want a round trip on every single interaction, so you convert your backend code into the frontend language, so it deals directly with the presentation code... and it goes on.

Oh, on the backend side you have an application and a data layer, both using different languages and data representation; so you do all that dance again there... Oh, and now we want several independent layers between those too, so be prepared to do all of that again and again.

At some point we decided on the wrong abstractions for our mainstream architectures.

Many developers have this Rube Goldberg syndrome and carry this as a badge of honor.

Modern civilisation is just a giant Rube Goldberg machine made of smaller Rube Goldberg machines which in turn…

100% this. I always dabbled as a dev since becoming fascinated with coding and computing as a kid in the 90s.

Went into a career in audio engineering in my 20s and switched to development about 4 years ago.

People ask how I found the switch and the truth is that it was very simple. The main principle of audio engineering is ‘signal’ flow, replace the word ‘signal’ with ‘data’ and you’re like 90% of the way there.

Follow the data, all we are doing is moving it around and manipulating it here and there. No different to a raw stem from the DI of a guitar passing through a big old analogue console.

> I feel that the majority of time working with computers is not actually computing numbers (addition, subtraction, multiplication) but LOGISTICS.

I think this was figured out in the 50's, when IBM started making mainframes for businesses - made for data processing and management rather than crunching numbers which was the focus of machines made at universities.

Also, in norwegian and I guess other european languages. We call them, directly translated, "data machines" rather than computers.

In Dutch the word is "computer" also, but English is the bastard child between Dutch and French while Dutch is already a bit of a bastard child from German.

¯\_(ツ)_/¯

I was confident that at least the germans would back me here, after all they got words like taschenrechner. But according to my dictionary they call it computer. Danish seems like 30% english nowadays, so I can't count on them. At least swedes call it "dator" which I guess is in the right spirit.

There is the German word "Rechner" for Computer but nowadays it is seldom used.

It's the same origin, just different base language. It's about computation, not data, in both English and German.

It's interesting that Norwegian and Swedish are putting the emphasis on data instead.

Rich Hickey actually has spoken about this on numerous occasions! So much of what we really do in programming is move data around, why not have data as first-class citizen in your programming?

Thank you.

I am working on an idea for programming that the primitive is literally moving things around in a grid. In a spreadsheet the formula is hidden behind a cell. And in most programming languages we write instructions and the state is implied - you don't see the state unless the program writes it out. In this design you see the state and all objects at all times. The idea is that the instruction is generated from the movement.

https://replit.com/@Chronological/DynamicTables

Try clicking "100" and move it into the JSON below.

At the moment I've implemented movement and JSON -> table. You can move things between fields in the JSON. You can rewind states of the top grid by clicking the instruction.

The plan is to put operations and API calls on the screen so you can move things into them, and their results shall go back into the grid.

Oh I see, you will quite literally "move" the data by pointing and clicking / visualizing the transfer of data. That's brilliant!

Isn't that what OOP is? Methods contain code, objects contain code and data, and invocations of code are primarily in reference to data.

Well, in Clojure at least, data is a generic thing you structure your program around, and is not hidden inside a class coupled to behavior. This is safely enabled by immutable values as a default. The standard library and ecosystem consists of generic functions operating on that immutable data. This is very liberating as you do not run into a combinatorial explosion of incompatible types that need to be marshaled to work together.

Generally you have 3 kinds of things in Clojure: associations (maps), sets (uniqueness), and order (lists/vectors).

I think you’re describing FP in general here.

I, too, am a fan, especially in data intense applications, where a clear / decoupled data model and aggressive compiler solve many headaches.

I'd say the opposite - OOP is the paradigm that does the most to hide your data, hiding it within these encapsulated actors where you can't access it directly or even see what and where you have.

I would have thought that encapsulation hides the way data is processed, stored, and moved around. But the data itself is always available in my experience.

Suppose the data is in a private field of an object deep in the object graph. How do you get it? You can't, by design - that object's public interface may expose some aspects of the data, but you're not meant to access the actual raw data.

Not just computers. Life is mostly just moving things around. From the highest levels like shipping and waste management down to the lowest levels like data processing. Once you have what you need in the right place, in most cases, the job is nearly done.

The corollary is that if you get smarter about how you move things around, you can make serious efficiency improvements.

+1. So often we conceptualize in terms of tasks, phases, states, processes. And then ultimately you discover it is all about data flow, an rarely about the algorithm.

Getting up to the point of doing the thing usually takes more time than the thing itself. that’s true in a lot of endeavors. Are you in a physical factory assembling product? The production and assembly time end to end is often a fraction of the time and effort spent putting everything in place to run the assembly.

very much so, and it scales with network and time

i work in a courthouse, they had to use all versions of IE and firefox due to unmaintained application locks

the lack of subtle ergonomics make people do more work on computer than on paper

if you remember the old electronic calculator versus abacus, it's the same logic, or lack thereof, by the time you've changed context (session expired ? how to change app, how to change tab, gathered data from the client, tried filling it 7 times in various forms, your 1960 self is already finished filling in the form with a smile)

there's probably a greenspun variant for this

Yes, there's a reason why software engineers are often compared to plumbers ...

80% of the time spent on construction is moving materials from one place to another

Is that why whenever I see some roadwork or construction getting done in a big city, all the workers are just standing around, chatting? They're waiting for the construction materials to arrive?

These guys are too cheap to bother with JIT logistics.

Any media being seen, watched or heard depends on a lot of computing.

Reply on news.ycombinator.com