4 ms·

> This is also why I think we have so much bloated code these days. 'Bloat' is a snarl term. It's meaningless. It literally means nothing, except to express ne

• robomartin 14y ago
  No, it's not a snarl term. It's very real. When dealing win an array is 400 times slower in a "modern OO language" then in raw C, well, the code id fucking bloated. When you can use a simple data structure and some code to solve a problem and, instead, write an object with a pile of properties and methods because, well, that's all you know, that's bloated code. Of course there are lots of places where OO makes absolute sense. And the fat and slow code is the compromise you might have to make. That's the way it goes. With regards to my GA example. No, I had to implement a GA. That's what was required to even attempt to solve the problem at hand. Later on we used it to train a NN, which made the ultimate solution faster. But, the GA was required. There was no way around it and Objective-C was such a an absolute pig at it that it made it unusable. > Simply picking a new language is laziness See, there's the difference. I started programming at a very low level and have experienced programming languages and approaches above that, from C, to C++, Forth, Lisp, APL, Python, Java, etc. I have even done extensive hardware design with reconfigurable hardware like PLD, PLA's and FPGA's using Verilog/VHDL. I have designed my own DDR memory controllers as well as raw-mode driver controllers and written all of the driver software for the required embedded system. My last design was a combination embedded DSP and FPGA that processed high resolution image data in real time at a rate of approximately SIX BILLION bytes per second. So, yes, I am an idiot and make really fucking dumb suggestions. Because of that I would like to think that, if the choice exists --and very often it does not-- I do my best to pick the best tool for the job. More often than not, when it's pedal-to-the-metal time C is the most sensible choice. It used to be that you had to get down to assembler to really optimize things, but these days you can get a way with a lot if C is used smartly.
  • derleth 14y ago
    > When dealing win an array is 400 times slower in a "modern OO language" then in raw C, well, the code id fucking bloated. Social science numbers do not impress me. Besides, what is a "modern OO language"? Haskell? How can you give any numbers without even specifying that detail? > Of course there are lots of places where OO makes absolute sense. And the fat and slow code is the compromise you might have to make. Your idea that "OO = fat and slow" is blown away by actual benchmarks. http://www.haskell.org/haskellwiki/Shootout http://www.haskell.org/haskellwiki/Shootout (And, yes, unless and until you define what "OO" is to you, I'll pick Haskell as a perfectly reasonable OO language. Given than I've seen C called OO by people with better writing skills than you, this is hardly a strange choice in this context.) > So, yes, I am an idiot Again, I did not call you an idiot. The only one calling you an idiot here is you. > More often than not, when it's pedal-to-the-metal time C is the most sensible choice. I agree fully with this. However, I disagree that "pedal-to-the-metal time" is all of the time, or even most of the time. Especially when you're trying to teach programming. Do you teach new drivers in an F1 racecar? Why or why not?