Okay.

Go write an operating system and suite of apps with global memory and no protections. Why are we wasting so much time on abstractions like processes and objects? Just let let everyone read and write from the giant turing machine.

▲

jodrellblank 4 days ago | parent | next [-]

> "Why are we wasting so much time on abstractions like .. objects?"

Aside: earlier this year Casey Muratori did a 2.5 hour conference talk on this topic - why we are using objects in the way they are implemented in C++ et al with class hierarchies and inheritance and objects representing individual entities? "The Big OOPs: anatomy of a 35 year mistake"[1].

He traces programming history back to Stroustrup learning from Simula and Kirstan Nygaard, back to C.A.R. Hoare's paper on records, back to the Algol 68 design committee, back to Douglas T. Ross's work in the 1950's. From Ross at MIT in 1960 to Ivan Sutherland working on Sketchpad at MIT in 1963, and both chains influencing Alan Kay and Smalltalk. Where the different ideas in OOP came from, how they came together through which programming languages, who was working on what, and when, and why. It's interesting.

[1] https://www.youtube.com/watch?v=wo84LFzx5nI

	▲	igouy 3 days ago \| parent [-]
		The previous HN comments are interesting. https://news.ycombinator.com/item?id=44612313

▲

jjmarr 4 days ago | parent | prev | next [-]

Embedded systems that EEs code for are like this. I have to explicitly opt into processes and objects in Keil RTX. I also get to control memory layout.

Abstraction layers are terrible when you need to understand 100% of the code at all times. Doesn't mean they're not useful.

Heck, the language for just implementing mathematical rules about system behaviour into code exists. It's called Matlab Simulink.

▲

nec4b 4 days ago | parent [-]

You are comparing a personal computer with a general purpose OS running 100s of processes and 1000s threads with a small micro-controller with a single process compiled together with an OS running at most a couple of threads. My PC has 100s of apps that need to coexist on the same hardware at the same time, your micro-controller only runs 1 designated app for eternity.

▲

vernrVingingIt 4 days ago | parent [-]

Sure. The hang up here is SWEs belief those abstractions must be stored as some syntax they know; C, Python, RoR, Linux, Elixir... whatever.

There is zero obligation to capture the concept of memory safety in traditional software notation. If it was possible to look inside the hardware at runtime no one is going to see Rust syntax.

At runtime it's more appropriate to think of it as geometric functions redrawing electrical state geometrically to avoid collisions. And that's where future chip and system state management are headed.

Away from arbitrary syntax constructs with computational expensive parsing rules of the past towards a more efficient geometric functions abstraction embedded in the machine.

	▲	jcgl 4 days ago \| parent \| next [-]
		> The hang up here is SWEs belief those abstractions must be stored as some syntax they know What does it matter how it's "stored"? I think (hope?) that most SWEs know that that syntax and its semantic aren't how things work on the metal. Storage format of the syntax seems pretty irrelevant. And surely you're not suggesting that SWEs should be using a syntax and semantics that they...don't know. So what's the better, non-traditional-software notation? Your conceptualization does sound genuinely intriguing. However, it seems like it would by necessity be non-portable across architectures (or even architecture revisions). And I take it as given that portable software is a desirable thing.
	▲	baq 3 days ago \| parent \| prev [-]
		> The hang up here is SWEs belief those abstractions must be stored as some syntax they know Contracts need to be written down to be effectively enforced. We don’t like a he said she said in software, right?

▲

vernrVingingIt 4 days ago | parent | prev | next [-]

Easy; endlessly big little numbers. "Endless" until the machine runs out of real memory addresses anyway.

You all really think engineers at Samsung, nVidia, etc whose job it is to generalize software into mathematical models have not considered this?

We need a layer of abstraction, not Ruby, Python, Elixir, Rails, Perl, Linux, Windows, etc, ad nauseum, ad infinitum... each with unique and computationally expensive (energy wasting) parsing, serializing and deserializing rules.

Mitigation of climate change is a general concern for the species. Specific concerns of software developers who will die someday anyway get to take a back seat for a change.

Yes AI uses a lot of electricity but so does traditional SaaS.

Traditional SaaS will eventually be replaced with more efficient automated systems. We're in a transition period.

It's computationally efficient to just use geometry[1], which given enough memory, can be shaped to avoid collisions you are concerned with.

Your only real concern is obvious self selection driven social conservatism. "Don't disrupt me ...of all people... bro!"

[1] https://iopscience.iop.org/article/10.1088/1742-6596/2987/1/...

▲

vlowther 4 days ago | parent | prev | next [-]

DOS, early Windows, and early MacOS worked more or less exactly that way. Somehow, we all survived.

	▲	kalleboo 4 days ago \| parent \| next [-]
		Apple nearly didn't survive until they bought a company that made an OS that didn't work that way.
	▲	baq 3 days ago \| parent \| prev [-]
		MS Word had to be rewritten from ~scratch to get rid of a document losing crash. Yes, we survived, but at what cost?

▲

switchbak 4 days ago | parent | prev [-]

Engineers value different things. It's why I loathe to maintain engineer-written code.

Let the downvotes commence!