3 ms·

Taking the tangent further, you write "one of my pet peeves with today's programmers". As someone who started programming in the 1980s, I've observed both side

by dalke 7y ago

Taking the tangent further, you write "one of my pet peeves with today's programmers". As someone who started programming in the 1980s, I've observed both sides of the issue. When I started, the earlier generation complained that 'today's programmers' didn't know anything about the hardware, like being able to re-write the computer to add new hardware capabilities, or to debug the machine by attaching probes to the bus. And they were right ... and mostly irrelevant, as the hardware complexity and reliability increased. Eg, it's much harder to hand solder surface mount than discrete components. On the other hand, I've had to re-learn programming for modern hardware. I remember when I implemented a string upper-case function like: while (*s) { *s = toupper(*s); s++; } only to find that while (*s) { if (islower(*s)) { *s = toupper(*s); } s++; } was faster for my use case. Someone had to explain to me the difference between read and write performance - on the machines I learned on, they were both one cycle. Similarly, I've had to learn (poorly, in an ad hoc fashion) about instruction pipelining and prefetching. I've therefore concluded that talking about problems with "today's programmers" is more like voicing the age-old complain about "kids these days" then expressing something more fundamental. Regarding APL, I like the comment at https://prog21.dadgum.com/122.html https://prog21.dadgum.com/122.html - "I encourage learning J, if only to make every other language seem easy." Regarding Forth, see http://yosefk.com/blog/my-history-with-forth-stack-machines.html http://yosefk.com/blog/my-history-with-forth-stack-machines.... and commentary at https://news.ycombinator.com/item?id=1680149 https://news.ycombinator.com/item?id=1680149 .

robomartin 7y ago
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."

by dalke 7y ago

robomartin 7y ago

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."