5 ms·

> I remember a project a long time ago that used Objective-C to implemente a genetic solver. It was unusable due to just how slow it was. I re-coded it in C. Q

> I remember a project a long time ago that used Objective-C to implemente a genetic solver. It was unusable due to just how slow it was. I re-coded it in C. Quick question. Why would you do such a thing? How can you square this with your claim that switching languages is never the answer? I agree with you that a good development process is essential. The thing is, some languages make for a worse development process, because they inhibit automation of important steps in code review. I expect you wouldn't trust the weaker type systems of Forth or BLISS, or the unstructured control flow of COBOL, for a job where you could use C instead. If there are analysis phases that C can automate and these other languages can't, isn't it obvious (given only a moment's thought) that there could be other languages that improve on C?

robomartin 4y ago
> Why would you do such a thing? You mean use Objective-C? Because that was the only way to write iOS apps. It sucks. It's unnecessary. And yet you could not avoid it for a good portion of an iOS app. > you wouldn't trust the weaker type systems of Forth I used Forth professionally for many years. I can't think of a single end-product issue caused by Forth. The range of applications I wrote went from device drivers and low level robotics code to full console-based applications, like specialized text editors. > isn't it obvious (given only a moment's thought) that there could be other languages that improve on C At the core, as I said before, these things only exist for the benefit of the programmer and generally don't exist in what I am going to call the real world inside the processor. Here's an example: A bytes() object in Python and MicroPython is not mutable. It also happens to be one of the lightest data structures you can use if doing communications work. In a recent MicroPython project we needed to manipulate the data in bytes() objects without causing reallocation of new objects. I wrote a set of routines in ARM assembler to do this just. For example, take a bytes() buffer, calculate a CRC-16 of the data, add it to the end and modify values in the front based on this CRC calculation. In other words: There is no such thing as a non-mutable data type. I think the simplest way I can put this is: Bad code is the result of bad programming, not a consequence of the chosen language. I should make it clear that I don't have a problem using any language (I have, many) or someone choosing to use whatever they like. My argument is that this idea of blaming solid, reliable, battle-tested languages like C for problems that are, in reality, the consequence of bad programming is dishonest.
- Hemospectrum 4y ago
  > Bad code is the result of bad programming, not a consequence of the chosen language. You've repeated this many times now. What I haven't seen you talk about is how to fix all this programmer badness. Do you think bad programmers should all be fired and blacklisted from the whole industry? Who will replace them? How do we make sure their replacements aren't just as bad as the ones who were fired? How do we even identify the bad ones before they write bad code? What if they want to become better programmers instead of getting fired? How do they figure out whether they're sufficiently good? The value proposition of a new language is not measured strictly by how fast it lets you write new code. It also needs to be a medium for communication between programmers. Communicating the intent behind your code helps identify the ways it could be improved. If your intent can be codified in a way that even the computer can understand, that process speeds up dramatically. Proponents of new languages are winning the debate over how to fix systemic problems in the software industry. The reason they are winning is because their opponents in this debate do not have a coherent solution. If you can suggest one, maybe you'll change everything.
  - robomartin 4y ago
    > What I haven't seen you talk about is how to fix all this programmer badness. Well, that wasn't part of the conversation until now. In a sense, I have hinted at this. There are two elements, education and experience. I firmly believe good programmers come from having a solid foundation built on low level code. That means a good progression might be assembler, Forth and then C. If I ask someone to explain how a list is stored and manipulated in memory in a language like Python, I expect at least a plausible explanation rather than a shrug. For me it doesn't even have to be be absolutely correct to show me they have gotten their hands dirty with low level code. Forth is interesting not only because of the RPN paradigm; one can learn a lot from implementing it from scratch on any microprocessor. From there you go on to actually turning that into a useful console-based computer. For example, implement all the peripheral drivers, a file system, file manager, text/code editor, etc. I would not have anyone touch C until they have completed the prior work. There's a reason for which companies like Google have seemingly crazy hiring processes for software developers: Our schools seem to be doing a crap job of training them. If that were not the case, there would be no need for such tests. A degree with a decent GPA would be enough. > Do you think bad programmers should all be fired and blacklisted from the whole industry? I am assuming that's not a serious question. There are bad doctors, attorneys, cops, teachers and carpenters. There is no such thing as equality of outcomes in anything. Hopefully the natural process in each domain expunges incompetence over time. That's the best we can hope for. Other than that, I can't tell you what we should do. I have to go back to my premise (flipping it around a bit): A different programming language isn't going to magically turn a bad programmer into a good one; much like a $4000 computerized welder wasn't going to make me a better welder. At the extremes, if someone doesn't know how to solve problems computationally, there's no language you can throw at them that will turn them into CS problem solvers. > Proponents of new languages are winning the debate over how to fix systemic problems in the software industry. The reason they are winning is because their opponents in this debate do not have a coherent solution. If you can suggest one, maybe you'll change everything. No. That's not correct. The reasons we keep taking crazy rides up and down a bunch of languages is that developers are coming out of schools with skills that require them to start at that level. As I said in another comment, the first thing every recent grad reaches for is a complex object structure. Because that's all the know. They don't actually know we were doing things like sending people to the moon without any of that stuff. They think it's necessary. And so, they develop tools and frameworks "in their image", if you will. Which means that the entire thing is a self-fulfilling prophecy. I remember one of the most impactful examples my son (a recent MS CS grad) experienced while working with me on a project. He needed a serial communications library for a robotics system we were building. He reached for a library and used it. The thing did not perform well and was giving us problems. That's when I became involved. The library consisted of, I don't know, two to four pages of classes, methods, etc. After understanding what it was doing I re-wrote what we needed in something like ten lines of procedural code. The unnecessary bloat in various programming languages ecosystems is something that should make anyone take pause. I mean, you see things like someone creating an entire object hierarchy with methods and properties for what amounts to managing a few thousand bytes of data in an array in memory. Instead of a raw close-to-the-machine for loop iterating through the data you end-up with a dozen objects instantiated, copious properties, layers of methods and...well, you get the point (I hope).

robomartin 4y ago

> Why would you do such a thing? You mean use Objective-C? Because that was the only way to write iOS apps. It sucks. It's unnecessary. And yet you could not avoid it for a good portion of an iOS app. > you wouldn't trust the weaker type systems of Forth I used Forth professionally for many years. I can't think of a single end-product issue caused by Forth. The range of applications I wrote went from device drivers and low level robotics code to full console-based applications, like specialized text editors. > isn't it obvious (given only a moment's thought) that there could be other languages that improve on C At the core, as I said before, these things only exist for the benefit of the programmer and generally don't exist in what I am going to call the real world inside the processor. Here's an example: A bytes() object in Python and MicroPython is not mutable. It also happens to be one of the lightest data structures you can use if doing communications work. In a recent MicroPython project we needed to manipulate the data in bytes() objects without causing reallocation of new objects. I wrote a set of routines in ARM assembler to do this just. For example, take a bytes() buffer, calculate a CRC-16 of the data, add it to the end and modify values in the front based on this CRC calculation. In other words: There is no such thing as a non-mutable data type. I think the simplest way I can put this is: Bad code is the result of bad programming, not a consequence of the chosen language. I should make it clear that I don't have a problem using any language (I have, many) or someone choosing to use whatever they like. My argument is that this idea of blaming solid, reliable, battle-tested languages like C for problems that are, in reality, the consequence of bad programming is dishonest.

Hemospectrum 4y ago
> Bad code is the result of bad programming, not a consequence of the chosen language. You've repeated this many times now. What I haven't seen you talk about is how to fix all this programmer badness. Do you think bad programmers should all be fired and blacklisted from the whole industry? Who will replace them? How do we make sure their replacements aren't just as bad as the ones who were fired? How do we even identify the bad ones before they write bad code? What if they want to become better programmers instead of getting fired? How do they figure out whether they're sufficiently good? The value proposition of a new language is not measured strictly by how fast it lets you write new code. It also needs to be a medium for communication between programmers. Communicating the intent behind your code helps identify the ways it could be improved. If your intent can be codified in a way that even the computer can understand, that process speeds up dramatically. Proponents of new languages are winning the debate over how to fix systemic problems in the software industry. The reason they are winning is because their opponents in this debate do not have a coherent solution. If you can suggest one, maybe you'll change everything.
- robomartin 4y ago
  > What I haven't seen you talk about is how to fix all this programmer badness. Well, that wasn't part of the conversation until now. In a sense, I have hinted at this. There are two elements, education and experience. I firmly believe good programmers come from having a solid foundation built on low level code. That means a good progression might be assembler, Forth and then C. If I ask someone to explain how a list is stored and manipulated in memory in a language like Python, I expect at least a plausible explanation rather than a shrug. For me it doesn't even have to be be absolutely correct to show me they have gotten their hands dirty with low level code. Forth is interesting not only because of the RPN paradigm; one can learn a lot from implementing it from scratch on any microprocessor. From there you go on to actually turning that into a useful console-based computer. For example, implement all the peripheral drivers, a file system, file manager, text/code editor, etc. I would not have anyone touch C until they have completed the prior work. There's a reason for which companies like Google have seemingly crazy hiring processes for software developers: Our schools seem to be doing a crap job of training them. If that were not the case, there would be no need for such tests. A degree with a decent GPA would be enough. > Do you think bad programmers should all be fired and blacklisted from the whole industry? I am assuming that's not a serious question. There are bad doctors, attorneys, cops, teachers and carpenters. There is no such thing as equality of outcomes in anything. Hopefully the natural process in each domain expunges incompetence over time. That's the best we can hope for. Other than that, I can't tell you what we should do. I have to go back to my premise (flipping it around a bit): A different programming language isn't going to magically turn a bad programmer into a good one; much like a $4000 computerized welder wasn't going to make me a better welder. At the extremes, if someone doesn't know how to solve problems computationally, there's no language you can throw at them that will turn them into CS problem solvers. > Proponents of new languages are winning the debate over how to fix systemic problems in the software industry. The reason they are winning is because their opponents in this debate do not have a coherent solution. If you can suggest one, maybe you'll change everything. No. That's not correct. The reasons we keep taking crazy rides up and down a bunch of languages is that developers are coming out of schools with skills that require them to start at that level. As I said in another comment, the first thing every recent grad reaches for is a complex object structure. Because that's all the know. They don't actually know we were doing things like sending people to the moon without any of that stuff. They think it's necessary. And so, they develop tools and frameworks "in their image", if you will. Which means that the entire thing is a self-fulfilling prophecy. I remember one of the most impactful examples my son (a recent MS CS grad) experienced while working with me on a project. He needed a serial communications library for a robotics system we were building. He reached for a library and used it. The thing did not perform well and was giving us problems. That's when I became involved. The library consisted of, I don't know, two to four pages of classes, methods, etc. After understanding what it was doing I re-wrote what we needed in something like ten lines of procedural code. The unnecessary bloat in various programming languages ecosystems is something that should make anyone take pause. I mean, you see things like someone creating an entire object hierarchy with methods and properties for what amounts to managing a few thousand bytes of data in an array in memory. Instead of a raw close-to-the-machine for loop iterating through the data you end-up with a dozen objects instantiated, copious properties, layers of methods and...well, you get the point (I hope).