3 ms·

Right, and that's exactly the immaturity I'm talking about - you're writing in a language designed by A interpreted by a program written by B in a language desi

by andreyf 17y ago

Right, and that's exactly the immaturity I'm talking about - you're writing in a language designed by A interpreted by a program written by B in a language designed by C compiled to an architecture defined by D, where A B C D are sets of people who have with little or no interest in what the others are doing. Between KDE, X Windows, and the graphics card, how much code complexity and hardware is necessary to do what Ivan Sutherland did nearly half a century ago? Understanding a computer system in its entirety simply isn't possible now. Precisely! But there's absolutely no reason why it can't be, aside from the inelegant, weak, and opaque abstractions we're using.

lmkg 17y ago
But what advantage is there to be gained? On the one hand you're removing accessibility to an underlying layer, but on the other hand you're also removing the need to deal with it, except for a small fraction of edge cases. If I'm writing a document in MS Word, my concern is what the document says and how it looks. Will knowing the specifics of hardware drivers for the hard disk or monitor help me do this in any way?[1] This is the same argument that C won against assembly back in the day, and the same argument that C is losing against yet-higher-level languages in the past decade. The utility you can squeeze out of low-level facilities, past one or two layers of abstraction, is small, especially compared with the level of effort required. You view it as "siloing." Most of us view it as specialization. Programmers get to focus on the novel aspects of their problem space, and the pieces like hard disc drivers that are universal get placed in the hands of specialists whose general solutions are still better than a million people making their own solutions. [1] To be perfectly honest, I do structure write my docs with the compression scheme of .docx files in mind, albeit in very vague general terms. However, this is more vanity than anything else, a word document being a kilobyte bigger or smaller has a vanishingly small chance of having a nonzero impact on anyone's life.
- andreyf 17y ago
  Faster programs. GUI's were possible with early 60's hardware [1]. UX performance hasn't scaled linearly with hardware speed, and I imagine that back abstractions are to blame. 1. http://www.youtube.com/watch?v=mOZqRJzE8xg http://www.youtube.com/watch?v=mOZqRJzE8xg
- andreyf 17y ago
  But what advantage is there to be gained? Faster software, for one. User experience hasn't increased with the same speed as hardware has because we have a lot of inefficient abstractions. I'll quote Bjarne Stroustrup [1], if I may: Complaining about software is a popular pastime, but much software has become better over the last decade, exactly as it improved in previous decades. Unfortunately, the improvements have come at tremendous cost in terms of human effort and computer resources. Basically, we have learned how to build reasonably reliable systems out of unreliable parts by adding endless layers of runtime checks and massive testing. The structure of the code itself has sometimes changed, but not always for the better. Often, the many layers of software and the intricate dependencies common in designs prevent an individual—however competent—from fully understanding a system. This bodes ill for the future: we do not understand and cannot even measure critical aspects of our systems. 1. http://cacm.acm.org/magazines/2010/1/55760-what-should-we-teach-new-software-developers-why/fulltext http://cacm.acm.org/magazines/2010/1/55760-what-should-we-te...
- coliveira 17y ago
  C is not an example, because you can still access assembly if you want (using conditional compilation, integrated assembly), just like every OS does. Word doesn't give you low level access, and that is why it is so despised by technical people. On the other hand, see how latex is so useful exactly because it gives you the option to manipulate the lower level structure of your document. In my point of view there is nothing wrong with specialization, as long as you have the option to go low level if you want/need.
Confusion 17y ago
Precisely! But there's absolutely no reason why it can't be, aside from the inelegant, weak, and opaque abstractions we're using. Interestingly enough, you are talking about these abstractions in a completely abstract way. I wonder: what are these inelegant, weak and opaque abstraction you speak of? Can you give me an example? Show them to me in some fashion? Tell me how they come about and what we can do to replace them with better ones? As far as I can see, your analysis contains no concrete characteristics whatsoever. It doesn't provide anything I can test or reason about. Compare: there is absolutely no reason why there couldn't be world peace, if it weren't for the inelegant, weak and opaque morality people have.
cabalamat 17y ago
> But there's absolutely no reason why it can't be, aside from the inelegant, weak, and opaque abstractions we're using. Would you rather build a web app in assembler or in an "inelegant, weak, and opaque abstraction" such as Django or Rails?
- andreyf 17y ago
  If the choice is "no abstractions" or "bad abstractions", I'll choose the latter. But "good abstractions" are better yet!

by andreyf 17y ago

lmkg 17y ago

But what advantage is there to be gained? On the one hand you're removing accessibility to an underlying layer, but on the other hand you're also removing the need to deal with it, except for a small fraction of edge cases. If I'm writing a document in MS Word, my concern is what the document says and how it looks. Will knowing the specifics of hardware drivers for the hard disk or monitor help me do this in any way?[1] This is the same argument that C won against assembly back in the day, and the same argument that C is losing against yet-higher-level languages in the past decade. The utility you can squeeze out of low-level facilities, past one or two layers of abstraction, is small, especially compared with the level of effort required. You view it as "siloing." Most of us view it as specialization. Programmers get to focus on the novel aspects of their problem space, and the pieces like hard disc drivers that are universal get placed in the hands of specialists whose general solutions are still better than a million people making their own solutions. [1] To be perfectly honest, I do structure write my docs with the compression scheme of .docx files in mind, albeit in very vague general terms. However, this is more vanity than anything else, a word document being a kilobyte bigger or smaller has a vanishingly small chance of having a nonzero impact on anyone's life.

andreyf 17y ago
Faster programs. GUI's were possible with early 60's hardware [1]. UX performance hasn't scaled linearly with hardware speed, and I imagine that back abstractions are to blame. 1. http://www.youtube.com/watch?v=mOZqRJzE8xg http://www.youtube.com/watch?v=mOZqRJzE8xg
andreyf 17y ago
But what advantage is there to be gained? Faster software, for one. User experience hasn't increased with the same speed as hardware has because we have a lot of inefficient abstractions. I'll quote Bjarne Stroustrup [1], if I may: Complaining about software is a popular pastime, but much software has become better over the last decade, exactly as it improved in previous decades. Unfortunately, the improvements have come at tremendous cost in terms of human effort and computer resources. Basically, we have learned how to build reasonably reliable systems out of unreliable parts by adding endless layers of runtime checks and massive testing. The structure of the code itself has sometimes changed, but not always for the better. Often, the many layers of software and the intricate dependencies common in designs prevent an individual—however competent—from fully understanding a system. This bodes ill for the future: we do not understand and cannot even measure critical aspects of our systems. 1. http://cacm.acm.org/magazines/2010/1/55760-what-should-we-teach-new-software-developers-why/fulltext http://cacm.acm.org/magazines/2010/1/55760-what-should-we-te...
coliveira 17y ago
C is not an example, because you can still access assembly if you want (using conditional compilation, integrated assembly), just like every OS does. Word doesn't give you low level access, and that is why it is so despised by technical people. On the other hand, see how latex is so useful exactly because it gives you the option to manipulate the lower level structure of your document. In my point of view there is nothing wrong with specialization, as long as you have the option to go low level if you want/need.

Confusion 17y ago

Precisely! But there's absolutely no reason why it can't be, aside from the inelegant, weak, and opaque abstractions we're using. Interestingly enough, you are talking about these abstractions in a completely abstract way. I wonder: what are these inelegant, weak and opaque abstraction you speak of? Can you give me an example? Show them to me in some fashion? Tell me how they come about and what we can do to replace them with better ones? As far as I can see, your analysis contains no concrete characteristics whatsoever. It doesn't provide anything I can test or reason about. Compare: there is absolutely no reason why there couldn't be world peace, if it weren't for the inelegant, weak and opaque morality people have.

cabalamat 17y ago

> But there's absolutely no reason why it can't be, aside from the inelegant, weak, and opaque abstractions we're using. Would you rather build a web app in assembler or in an "inelegant, weak, and opaque abstraction" such as Django or Rails?

andreyf 17y ago
If the choice is "no abstractions" or "bad abstractions", I'll choose the latter. But "good abstractions" are better yet!