|Linus Torvalds wrote:|
|"It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it."|
|Linus Torvalds wrote:|
|"In other words, the only way to do good, efficient, and system-level and |
portable C++ ends up to limit yourself to all the things that are
basically available in C."
|Linus Torvalds wrote:|
|"And limiting your project to C means that people don't screw that up, and also means that you get a lot of programmers that do actually understand low-level issues and don't screw things up..."|
|taking six hundred pictures of your converse shoes through the sepia filter on your iphone makes you a photographer artist like microwaving cup ramen makes me a gourmet chef.|
|"also why drift away from c++ if you know how ::operator new/delete works?"|
I've noticed that every language that's released is making the programming field become more, and more easier
|"This, for example, it's bullshit if you're not developing an OS."|
|"Also, even if something is easier through libraries/new languages/etc."|
|"It's about knowing what you're doing."|
|Is programming still considered an art in your eyes?|
|despite that fact that most languages now do almost everything for you?|
|I'll say it as it is: I don't like languages that do things implicitly (such as garbage collection). I'm starting to drift away from C++, and back to C because of this.|
|I've noticed that every language that's released is making the programming field become more, and more easier, to the point where it's no longer considered an art.|
|By the way, C++11's lambada expressions are terrible, but that's my opinion.|
|"They're "easier" because it helps deal with ever greater complexity."|
|"And in my opinion, it's not "an art" having to deal with details that aren't part of the problem you're solving. Even if it's about optimization: optimize the algorithm. That's where the art is at."|
|"Higher level languages allow a whole lot more, in my opinion - there's simply more concepts to work with."|
|"It's just as fluid as C++."|
|It's that "making things easier for the programmer" is what draws substandard programmers. That's the sort of thing that needs to stop.|
|"So what is this about? The fact that truly knowing the machine inside out isn't a requirement anymore? Why is that a bad thing?"|
|If we only used C for programming projects, the majority (if not all) of substandard programmers wouldn't be eligible to work on the project|
It's that "making things easier for the programmer" is what draws substandard programmers. That's the sort of thing that needs to stop. If we only used C for programming projects, the majority (if not all) of substandard programmers wouldn't be eligible to work on the project, and only the ones who actually know what their on about will be eligible
|"while in fact it requires far greater discipline and attention to detail than any other production language"|
|Working on a low-level requires a lot more knowledge than programming on a high-level.|
|Whether proving a theorem by building up from lemmas to basic theorems to more specialized |
results, or designing a circuit by building up from components to modules to complex processors,
or designing a software system by building up from generic procedures to classes to class libraries,
humans deal with complexity by exploiting the power of abstraction and modularity. Without
such tools, a single person would be overwhelmed by the complexity of a system, as there is only
so much detail that a single person can consciously manage at a time.
Modularity is the idea of building components that can be re-used; and abstraction is the idea that
after constructing a module (be it software or circuits or gears), most of the details of the module
construction can be ignored and a simpler description used for module interaction (the module
computes the square root, or doubles the voltage, or changes the direction of motion).
Given basic modules, one can move up a level of abstraction and construct a new module by
putting together several previously-built modules, thinking only of their abstract descriptions,
and not their implementations. And, of course, this process can be repeated over many stages.
This process gives one the ability to construct systems with complexity far beyond what would be
possible if it were necessary to understand each component in detail.
Any module can be described in a large number of ways. We might describe the circuitry in a
digital watch in terms of how it behaves as a clock and a stopwatch, or in terms of voltages and
currents within the circuit, or in terms of the heat produced at diﬀerent parts of the circuitry. Each
of these is a diﬀerent model of the watch. Diﬀerent models will be appropriate for diﬀerent tasks:
there is no single correct model. Rather, each model exposes diﬀerent dimensions of the system,
allowing us to explore many aspects of the design space of a system, and to trade oﬀ diﬀerent
factors in the performance of a system.
The primary theme of this course will be to learn about diﬀerent methods for building modules
out of primitives, and of building diﬀerent abstract models of them, so that we can analyze or
predict their behavior, and so we can recombine them into even more complex systems. The same
fundamental principles will apply to software, to control systems, and to circuits.