2 ms·

The exception I'll take with regards to my "today's programmers" comment is that, again, in my opinion, things are not getting better. The simplest example of

The exception I'll take with regards to my "today's programmers" comment is that, again, in my opinion, things are not getting better. The simplest example of this I have is iOS. I wrote an app years ago that required me to implement a genetic solver. Simple enough. Well, not so. Objective-C is so thick and heavy that this thing was a complete dog. This was back in the iPhone 3 days. I needed this solver to produce results in real time, defined as "as quickly as a user could touch a button". This thing was at least an order of magnitude slower than what the app required. So, I re-coded the thing in plain procedural C++, not OO. Clean, simple fast code. With that change the code ran faster than real time, to the point that I could then add features. Anyone trained in languages like Objective-C, Python, etc. sees the world through a single OO lens and "programs" by threading together libraries and really chunky slow code. They lack the benefit of understanding the same or more can be achieved by leaving that baggage behind. This is how we end-up with machines operating at GHz that actually slow down despite having massive amounts of memory and resources. I am not anti-OO, but OO seems to be an inextricable part of bloated code these days.

dalke 7y ago
While I don't believe it's getting worse. Objective-C dates from the 1980s, and I'm surprised you needed anything from C++ which wasn't available in the C that Objective C supports. Python doesn't encourage a single OO lens. I've been working with Python since the 1990s, and don't use OO that much. When I teach Python to computational chemists, I deliberately don't touch on "class" or other OO aspects because it doesn't seem that useful for what most people need to do. I double-checked using the text of "Automate the Boring Stuff" at https://automatetheboringstuff.com/ https://automatetheboringstuff.com/ , which is also for beginners. I found no description of making classes. So I do not accept the idea that Python programmers "[see] the world through a single OO lens". Certainly there are people with bad habits. I wrote about one of these in a scientific methods paper published just a couple of weeks ago, at https://jcheminf.biomedcentral.com/articles/10.1186/s13321-019-0398-8 https://jcheminf.biomedcentral.com/articles/10.1186/s13321-0... : > Many search implementations interpret Eq. 1 literally, and represent fingerprints using a set data type and compute the Tanimoto using set operations. This approach often uses a large number of temporary set instances. By comparison, an implementation which represents a fingerprint as a byte string or sequence of machine words uses less memory, has less memory management overhead, and can implement Eq. 2 with a handful of fast bit and arithmetic operations. But it's not specific to this generation, because I read essentially the same complaints - scratching off "OO" - back around 1991 or so (either in CACM or Dr. Dobbs'). Looking now, I found https://www.drdobbs.com/are-the-emperors-new-clothes-object-orie/184408251 https://www.drdobbs.com/are-the-emperors-new-clothes-object-... complaining about the slowness of OO software back in 1989. And "threading together libraries" is, you certainly know, the goal of software re-use. Consider Jon Bentley's classic 1986 paper where Donald Knuth and Doug McIlroy write short program, at https://dl.acm.org/citation.cfm?id=315654 https://dl.acm.org/citation.cfm?id=315654 . > Read a file of text, determine the n most frequently used words, and print out a sorted list of those words along with their frequencies. As McIlroy comments, "A wise engineering solution would produce—or better, exploit—reusable parts. ... The simple pipeline given above will suffice to get answers right now, not next week or next month. It could well be enough to finish the job. But even for a production project, say for the Library of Congress, it would make a handsome down payment, useful for testing the value of the answers and for smoking out follow-on questions."

dalke 7y ago

While I don't believe it's getting worse. Objective-C dates from the 1980s, and I'm surprised you needed anything from C++ which wasn't available in the C that Objective C supports. Python doesn't encourage a single OO lens. I've been working with Python since the 1990s, and don't use OO that much. When I teach Python to computational chemists, I deliberately don't touch on "class" or other OO aspects because it doesn't seem that useful for what most people need to do. I double-checked using the text of "Automate the Boring Stuff" at https://automatetheboringstuff.com/ https://automatetheboringstuff.com/ , which is also for beginners. I found no description of making classes. So I do not accept the idea that Python programmers "[see] the world through a single OO lens". Certainly there are people with bad habits. I wrote about one of these in a scientific methods paper published just a couple of weeks ago, at https://jcheminf.biomedcentral.com/articles/10.1186/s13321-019-0398-8 https://jcheminf.biomedcentral.com/articles/10.1186/s13321-0... : > Many search implementations interpret Eq. 1 literally, and represent fingerprints using a set data type and compute the Tanimoto using set operations. This approach often uses a large number of temporary set instances. By comparison, an implementation which represents a fingerprint as a byte string or sequence of machine words uses less memory, has less memory management overhead, and can implement Eq. 2 with a handful of fast bit and arithmetic operations. But it's not specific to this generation, because I read essentially the same complaints - scratching off "OO" - back around 1991 or so (either in CACM or Dr. Dobbs'). Looking now, I found https://www.drdobbs.com/are-the-emperors-new-clothes-object-orie/184408251 https://www.drdobbs.com/are-the-emperors-new-clothes-object-... complaining about the slowness of OO software back in 1989. And "threading together libraries" is, you certainly know, the goal of software re-use. Consider Jon Bentley's classic 1986 paper where Donald Knuth and Doug McIlroy write short program, at https://dl.acm.org/citation.cfm?id=315654 https://dl.acm.org/citation.cfm?id=315654 . > Read a file of text, determine the n most frequently used words, and print out a sorted list of those words along with their frequencies. As McIlroy comments, "A wise engineering solution would produce—or better, exploit—reusable parts. ... The simple pipeline given above will suffice to get answers right now, not next week or next month. It could well be enough to finish the job. But even for a production project, say for the Library of Congress, it would make a handsome down payment, useful for testing the value of the answers and for smoking out follow-on questions."