7 ms·

In what way were people able to introspect into their computing devices for learning? By being able to poke around OS details or the filesystem? Doesn't it sou

In what way were people able to introspect into their computing devices for learning? By being able to poke around OS details or the filesystem? Doesn't it sound more important to have an IDE + fluid building so people don't have to care about the details?

saagarjha 8y ago
It’s often useful to be able to know what goes on behind the scenes, but the hardware/software of today makes this increasingly difficult to ascertain.
TheOtherHobbes 8y ago
There's no such thing as "don't have to care about the details." This is the biggest difference between then and now. In the 70s and 80s computing was all about details, all the way down to the hardware, which most developers understood at the register level. 8-bit amateurs grew up with simple toy machines. They learned enough detail to allow a natural transition to professional development on mainframes and minis - far more detail and more complexity, more of an OS to deal with, but with a recognisably similar outline. Now most development is more like LEGO - clip moving parts to other moving parts in a slightly precarious way and hope nothing breaks. It's a completely different way of thinking about computing - kit and cookbook based, with less space for original creation and problem solving. This is partly because the details are hidden and can't be changed, but also because the ethic of experimentation and creativity based on deep domain knowledge driven by curiosity isn't the same.
- wilsonnb3 8y ago
  > There's no such thing as "don't have to care about the details." The whole point of the many abstractions between the user and the hardware is so they don’t have to care about the details.
  - dkersten 8y ago
    Not caring about the details leaves us with people who can't fix simple issues and with applications that use way too much cpu, memory or energy than they really should. Sure, a lot of people don't care and just want to do the thing, but if you at all care that your computer that is 1000x as powerful as the one you had years ago, but doesn't really do a lot more, then you have to care. If you care about the users of your application and don't simply pass your lower development effort on to them in terms of performance cost, then you have to care. If you want to be able to fix your own issues, then you have to care. Yes, the abstractions mean people can do more without caring, which in turn means more people can use them, but it comes at a cost too.
    - goldfeld 8y ago
      Every user application doesn't have to be written in C.
      - dkersten 8y ago
        Of course not, but from reading HN, I’m not the only one frustrated with the performance state of many applications. They don’t have to be written in C to perform well. For example, I quite like using Qutebrowser, a minimalistic keyboard-centric browser that’s more lightweight than Chrome or Firefox, yet its written in Python (well, I guess the actual browser engine is C++/Qt)
        goldfeld 8y ago
        I'm reading this (late) in qutebrowser! Mine has so many tabs open but doesn't hang (until it does), which is a fresh change from luakit (and Chrome but not Firefox, alas mine has many many more tabs open so that I don't open it anymore.) And I'm using because it's written in Python (and so easily scriptable from my own Python program.)
    - askafriend 8y ago
      Performance is a business decision. It doesn’t come for free and ultimately other things might be more important.
  - monocasa 8y ago
    Abstractions are, almost by definition, always imperfect. A perfect abstraction sort of ceases to be an abstraction and is simply "the way things are".
II2II 8y ago
Whether you are talking about old or new, it depends upon what you are trying to accomplish as well as how you go about it. Think back to the computers of the early 1980's. It was quite easy for someone to pick up BASIC and create simple programs. Their understanding of programming will be basic and their understanding of the machine will reflect that. That is quite similar to today. Someone who whetted their appetite will move on to more advanced concepts. With early computers, that typically meant learning about the hardware or learning about algorithms. You either had to squeeze more performance out of your software or you needed to extend your reach beyond the language (and libraries). Today's programmer is, more likely than not, going to dive more deeply into libraries or learn more about their programming language. Yes, there will be exceptions based upon the domain that interests them or what they wish to gain from their learning. Let's say that they decide to dive deeper into how the computer works. In the case of an early personal computer, the task was relatively easy. From a programmer's perspective, almost everything can be viewed sequentially and shuffling data across a bus. If they were more interested in electronics, it was relatively easy to see what was going on by looking at a circuit diagram or the board itself coupled with reading (admittedly more difficult to obtain) datasheets. With that knowledge, it was possible to modify the existing hardware and practical to build new hardware. The notion that we are abstracting our understanding further and further from the workings of the machine while letting that limited understanding decide how what we can do with it isn't exactly a new one. My first real encounter with that idea was from one of the pioneers of digital computers, who described the machine as fundamentally physical and analog. In other words, making the physical world digital is in some sense and abstraction in its own right. Granted, the article's author had relatively little to say on the fronts of programming and electronics design. It was more of a critique about younger people using software with very little understanding of its features or how it works, the sort of thing that can get you into trouble when things are not working as expected. While I disagree that this problem is specific to this generation, it is a solid reminder that the stereotype that younger people are better with technology is just plain wrong.

saagarjha 8y ago

It’s often useful to be able to know what goes on behind the scenes, but the hardware/software of today makes this increasingly difficult to ascertain.

TheOtherHobbes 8y ago

There's no such thing as "don't have to care about the details." This is the biggest difference between then and now. In the 70s and 80s computing was all about details, all the way down to the hardware, which most developers understood at the register level. 8-bit amateurs grew up with simple toy machines. They learned enough detail to allow a natural transition to professional development on mainframes and minis - far more detail and more complexity, more of an OS to deal with, but with a recognisably similar outline. Now most development is more like LEGO - clip moving parts to other moving parts in a slightly precarious way and hope nothing breaks. It's a completely different way of thinking about computing - kit and cookbook based, with less space for original creation and problem solving. This is partly because the details are hidden and can't be changed, but also because the ethic of experimentation and creativity based on deep domain knowledge driven by curiosity isn't the same.

wilsonnb3 8y ago
> There's no such thing as "don't have to care about the details." The whole point of the many abstractions between the user and the hardware is so they don’t have to care about the details.
- dkersten 8y ago
  Not caring about the details leaves us with people who can't fix simple issues and with applications that use way too much cpu, memory or energy than they really should. Sure, a lot of people don't care and just want to do the thing, but if you at all care that your computer that is 1000x as powerful as the one you had years ago, but doesn't really do a lot more, then you have to care. If you care about the users of your application and don't simply pass your lower development effort on to them in terms of performance cost, then you have to care. If you want to be able to fix your own issues, then you have to care. Yes, the abstractions mean people can do more without caring, which in turn means more people can use them, but it comes at a cost too.
  - goldfeld 8y ago
    Every user application doesn't have to be written in C.
    - dkersten 8y ago
      Of course not, but from reading HN, I’m not the only one frustrated with the performance state of many applications. They don’t have to be written in C to perform well. For example, I quite like using Qutebrowser, a minimalistic keyboard-centric browser that’s more lightweight than Chrome or Firefox, yet its written in Python (well, I guess the actual browser engine is C++/Qt)
      - goldfeld 8y ago
        I'm reading this (late) in qutebrowser! Mine has so many tabs open but doesn't hang (until it does), which is a fresh change from luakit (and Chrome but not Firefox, alas mine has many many more tabs open so that I don't open it anymore.) And I'm using because it's written in Python (and so easily scriptable from my own Python program.)
  - askafriend 8y ago
    Performance is a business decision. It doesn’t come for free and ultimately other things might be more important.
- monocasa 8y ago
  Abstractions are, almost by definition, always imperfect. A perfect abstraction sort of ceases to be an abstraction and is simply "the way things are".

II2II 8y ago

Whether you are talking about old or new, it depends upon what you are trying to accomplish as well as how you go about it. Think back to the computers of the early 1980's. It was quite easy for someone to pick up BASIC and create simple programs. Their understanding of programming will be basic and their understanding of the machine will reflect that. That is quite similar to today. Someone who whetted their appetite will move on to more advanced concepts. With early computers, that typically meant learning about the hardware or learning about algorithms. You either had to squeeze more performance out of your software or you needed to extend your reach beyond the language (and libraries). Today's programmer is, more likely than not, going to dive more deeply into libraries or learn more about their programming language. Yes, there will be exceptions based upon the domain that interests them or what they wish to gain from their learning. Let's say that they decide to dive deeper into how the computer works. In the case of an early personal computer, the task was relatively easy. From a programmer's perspective, almost everything can be viewed sequentially and shuffling data across a bus. If they were more interested in electronics, it was relatively easy to see what was going on by looking at a circuit diagram or the board itself coupled with reading (admittedly more difficult to obtain) datasheets. With that knowledge, it was possible to modify the existing hardware and practical to build new hardware. The notion that we are abstracting our understanding further and further from the workings of the machine while letting that limited understanding decide how what we can do with it isn't exactly a new one. My first real encounter with that idea was from one of the pioneers of digital computers, who described the machine as fundamentally physical and analog. In other words, making the physical world digital is in some sense and abstraction in its own right. Granted, the article's author had relatively little to say on the fronts of programming and electronics design. It was more of a critique about younger people using software with very little understanding of its features or how it works, the sort of thing that can get you into trouble when things are not working as expected. While I disagree that this problem is specific to this generation, it is a solid reminder that the stereotype that younger people are better with technology is just plain wrong.