Hacker News Reader

Hacker News

Comment by sklogic | Hacker News Reader

Parent Full thread

sklogic

> more accessible and easily searchable

Have not seen more easily searchable documentation than the DEC HELP system.

> Many programmers have never bought or own a book related to programming

And it's very sad.

> - they learned from all online sources.

Did they really learn anything? Without the books? Or they are simply trained to repeat few simple tricks over and over again?

> But it's so much more convenient.

I said needless layers. They're annoyance, not convenience.

> In the old days you had to learn all about your graphics card

We had OpenGL in the old days too. Pretty much straight from the beginning of the GPUs.

> your printer,

We had hardware PostScript back then. No drivers required.

> Now everything is abstracted and easy to use

There are piles of layers well above the device drivers now. With 90% of them being totally unnecessary.

View on HN

Honestly, I spend a about the same amount of time figuring out how to get the abstracted library/api/someone else's code to do what I actually need it to but it doesn't quite want to do the way I need it as I did writing it in the first place.

In the end, it's still 40 hours a week and the pay is still good :)

> We had OpenGL in the old days too. Pretty much straight from the beginning of the GPUs.

Someone missed out on the early PC days ;-) An example of what I'm thinking: Standardized-ish PC hardware (CGA, EGA, VGA, et al) might be abstracted by the programming language's libraries, but devs often reached below the abstraction, manually twiddling registers in the hardware. There weren't really standardized "drivers" for a lot of the available hardware.

OpenGL was opened in 1992, but it was only toward the late 90s that any (consumer-level) GPUs actually implemented it.

My apologies if you're mostly talking about non-consumer hardware.

> Someone missed out on the early PC days

I ignored PCs altogether. They were useless toys back then.

We had SGIs, so who cared about PCs?

> devs often reached below the abstraction, manually twiddling registers in the hardware

And we're still doing it, nothing changed. Want performance and control - go low level. Want uniform APIs - use what your vendors are trying to feed you with.

> you're mostly talking about non-consumer hardware

An SGI station is still a kind of a "consumer" hardware.

> We had SGIs, so who cared about PCs?

Who's "we"? If you mean that they existed, then OK, I can't argue that. I've never known anyone that had one, but hundreds who had PC-level hardware.

>And we're still doing it, nothing changed. Want performance and control - go low level.

Low-level has changed significantly in meaning. Now maybe someone would try to go through the driver instead of the higher-level API, but no one's going to do direct register writes. Modern hardware isn't usable at that level.

> An SGI station is still a kind of a "consumer" hardware.

Not a mainstream one by most measures, which is what I was trying to get at.

> Who's "we"?

We as an industry in general.

> Low-level has changed significantly in meaning

Not that much, actually, just shifted to the other domains.

> but no one's going to do direct register writes.

You'd be surprised. People even do bit-banging now (could you imagine bit-banging a VGA port directly in the past?).

> Modern hardware isn't usable at that level.

Is something like VC4 GPU modern enough? People do work with it on a very low level, thanks to the open specs. See this for example: https://github.com/mn416/QPULib

Actually, all the modern GPUs are getting simpler and more unifirm, so it's getting easier to hack them on a low level.

If you think those layers are unnecessary, then don't use them. Create your application using assembly and syscalls. Don't forget though, version 1 needs to be done in 3 weeks...

Good luck bypassing the unnecessary layers if your code have to run in a browser. Which is exactly an example of such an unnecessary layer (dozens of layers, actually).

And JVM is not any better.

No, the browser is a very necessary layer; it provides very effective security isolation between the internet and the windowing system.

The mainframe days assumed that software was installed by the privileged admin and that users were the threat. It's now the other way round: most computers have only one user, but need to run all sorts of software that needs to be kept isolated from the system and each other.

Browser as it is now is a stupid and unnecessary abstraction. Even a humble Tcl interpreter running in a sandbox would have been many times better than all that thick client browsers.

This was one of the intended use-cases of rebol, IIRC. I know that code/program distribution over the network was, I believe isolation was a part of that (little time to research and confirm) or was intended to be at some stage.

Sort of interesting to think about this now, in the context of web apps and the recent Android instant apps.

> No, the browser is a very necessary layer

Effective security isolation is a necessary layer. Browsers are one option to provide that, but there are others. They also provide ways to fetch, run, and interface with cross-platform, highly-efficient code from all over the world. That's both a blessing and a curse.

When I think about the volume of other people's software that we run while doing things online, I wonder how much of it is actually directly related to whatever I'm trying to do, and how much is incidental, unnecessary overhead.

Reply on news.ycombinator.com