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. |
DeXecipher wrote: |
---|
"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 |
|
|
mlpnkobji wrote: |
---|
"This, for example, it's bullshit if you're not developing an OS." |
mlpnkobji wrote: |
---|
"Also, even if something is easier through libraries/new languages/etc." |
mlpnkobji wrote: |
---|
"It's about knowing what you're doing." |
Framework wrote: |
---|
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. |
Catfish2 wrote: |
---|
"They're "easier" because it helps deal with ever greater complexity." |
Catfish2 wrote: |
---|
"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." |
Cubbi wrote: |
---|
"Higher level languages allow a whole lot more, in my opinion - there's simply more concepts to work with." |
Cubbi wrote: |
---|
"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. |
Catfish2 wrote: |
---|
"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 |
Cubbi wrote: |
---|
"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 different parts of the circuitry. Each of these is a different model of the watch. Different models will be appropriate for different tasks: there is no single correct model. Rather, each model exposes different dimensions of the system, allowing us to explore many aspects of the design space of a system, and to trade off different factors in the performance of a system. The primary theme of this course will be to learn about different methods for building modules out of primitives, and of building different 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. |