Hacker News Reader

Comment by qikInNdOutReply | Hacker News Reader

So a good language, should not abstract that memory pyramid away, but instead make you painfully aware of it, while developing. Rewarding DOD, punishing OO, but that results in more education time for programers, which no company is willing to pay for.

What instead is needed is a intermediate language, that takes the constructs of object orientation and the instruction flow and allows to rearrange them for maximum memory efficieny. Like, strip those OO-bjects into arrays, or directly pack them into hot-loop structs that have little regard for the Objects they started out with.

Can someone from the old guard tell me, how often we have been here in the language design cycles through the desert?

View on HN

I believe that the direction of a managed language with value types is a good goal.

I especially like Java’s plan of introducing them: according to the latest design iteration, there will be 3 buckets of objects: current identity-having ones, value classes and primitive classes.

The second category would drop identity, but will keep nullability (for example two DateTime instance of the same value will be considered equal on a VM-level, allowing for optimizations like allocating DateTime’s inside an array serially, or stack-allocation. Nullability is important because there is no sane default value choice for for example a DateTime. But this value can be encoded cleverly similarly to what Rust does with optional)

The third category will loose nullability as well and current primitives will be migrated to it. So a ComplexInt “class” will be possible to implement with “zero” overhead.

My point being that there are two ways of improving performance, either showing more knobs to manipulate, or to raise the abstraction level, allowing cleverer optimizations. C# does the former, while Java never went that route, and I think that the latter approach better fits a managed language and can easily push it for like 90% better performance at a fraction of developer complexity.

> that results in more education time for programers, which no company is willing to pay for

That's why you finally stop teaching Java in high schools.

I was going to say OOP aside from the basic animals and calls example, takes years of indoctrination for people to find it the simple default way to do things.

Functional programming is much simpler, but we don't spend years hammering the concept into people's brains.

I program Java to earn my living and any hierarchy deeper than two is a bad smell for me. Not that it cannot have its place, but most of the time you're right, some find so fascinating to inherit everything from everything...

I remember sitting in these lectures thinking, why not just use a function without all the boilerplate? And a decade later the programming world finally came back to some semblance of sanity.

Because for some reason most OO learning material seems to be focused on syntax and language features, not design. It's a real shame.

Ah yes, functional programming is indeed so much simpler.

I'll just use a Kleisli

With helping acquaintances learning programming from 0, I have a sample size of n = 2 that starting with FP got them to grok basic programming within a very short amount of time.

And IME moving from FP to OOP is MUCH easier than the other way around.

Don't really have the knowledge to compare iterative vs functional for a complete beginner, though I suspect that even there moving from FP to iterative is easier.

> Like, strip those OO-bjects into arrays, or directly pack them into hot-loop structs that have little regard for the Objects they started out with.

I think Jonathan Blow's JAI is trying to do something like this. Unfortunately it isn't exactly available yet, or it wasn't last time I looked.

Jai has this as an explicit goal.

Zig has closely aligned goals.

Just allocate the objects in the stack, RAII style.

Reply on news.ycombinator.com