Hacker News Reader

Comment by bluedino | Hacker News Reader

>> but the quality of documentation is abysmal compared to what we used to have

It is, however, more accessible and easily searchable. And also basically free. Many programmers have never bought or own a book related to programming - they learned from all online sources.

>> layers in between hardware and your code. It is annoying.

But it's so much more convenient. In the old days you had to learn all about your graphics card, your printer, your sound card, you'd need a certain driver for your modem or network card... Now everything is abstracted and easy to use.

View on HN

> Many programmers have never bought or own a book related to programming - they learned from all online sources.

I wonder what the effect of this has been on overall quality of code for this subset. I know that while I've learned more from online sources than books (whether physical or electronic), the lessons I have learned from books are overall above the average quality of all my sources.

I highly doubt there is any difference, since the only difference is the medium. If a book is published online, it's still a book.

I think you're missing the point. It's not about electronic book vs physical book (If I misunterstood you, sorry and dismiss this post). It's more about the sources on the internet, I don't know many people who read complete books on the computer but rather just read relevant sections somewhere online. While this isn't bad per se, you often miss important details due to different sources (and therefore different views/reader assumptions, ...).

They tend to be very different kinds of books. A comprehensive, deep printed textbook vs. what is essentially nothing more than a tutorial or a collection of practical recipes.

Does reading _Learn You a Haskell_ online make it any less of a book? My point is that "online sources" is a superset of "books", making them incomparable.

No. However a lot of the things I, anecdata, find when I do a google search aren't books, but blogs and random tutorials and stackoverflow.

Books, due to their published nature, tend to have a greater, more thorough, effort put into them. They are generally well laid out, usually well edited, and because people spent money on them the good ones tended to stay in the market and the bad ones tended to drop out.

There's no fundamental difference (except for me, I do much better at recalling things I read from physical books than ebooks), in the source of online versus offline. But it's hard to ignore the difference in quality that tends to happen.

What would be nice, and this is probably done somewhere, would be a reliable aggregator of good online documentation (whether it's an ebook version of a published text or not). Somewhere we can vet and see vetted quality sources of tutorials, manuals, etc.

This is among very few exceptions. Most of the books are still proper books (no matter if they're also available as e-books). Most of the stuff people use for learning online is far below a book quality.

> If a book is published online, it's still a book. reply

Not really arguing the medium of actual books (which is why I specified in my previous post). More a comparison between topic-specific books and blog posts / StackOverflow.

I can tell you that the two languages I can confidently say I know well - C++ and Common Lisp - are the ones I learned from books. The rest I learned from various on-line tutorials, articles, references and sometimes from half-reading a book - and while I can code with them, I can feel my coding in them is mediocre. Hell, I feel that the generic-coding skills I have I owe mostly to books (and practice). You can't beat a book in terms of depth and undestanding.

(And don't get me started on videotutorials. This is probably the least cost-effective educational medium ever invented.)

> 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.

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.

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.

Reply on news.ycombinator.com