6 ms·

> If written correctly Therefore, there are ways to write bad code. Do you think it's reasonable there may be better tools that prevent writing some cases of b

> If written correctly Therefore, there are ways to write bad code. Do you think it's reasonable there may be better tools that prevent writing some cases of bad code? I mean, I think we all can agree that, in general, a codebase with significant test coverage hass less bugs than a similar codebase without test coverage. So, I don't think it's crazy to require, potentially via a tool, some degree of test coverage. Yes, some people will cheat by constructing some bad tests, but, in general, I think we should expect some level of quality improvement. Rust adds another tool that, on average, should improve quality. Again, this is not a solution. This is not a silver bullet. Neither is depending on the programmer to write correct code.

robomartin 4y ago
> Therefore, there are ways to write bad code. Do you think it's reasonable there may be better tools that prevent writing some cases of bad code? Bad code is written every day in every language. The root causes for bad code do not include the chosen programming language. If language was a root cause, every codebase using language <x> would have problem. Clearly that isn't an issue. Why do we write bad code then? - Unintended errors - Bad design - Not understanding the problem being solved - Not understanding the constraints - Not understanding the hardware/environment - Lack of skill - Lack of knowledge - Limited experience with the tools, frameworks, libraries, domain, etc. - No understanding of lower-level concepts - Lack of education (formal or self-taught, does not matter) - Not having a full grasp of fundamentals - Not being thorough or detail-oriented - Etc. There are a lot of reasons for which bad code is written. Language choice isn't one of them. It's an excuse. If baseline languages like C and C++ were so impossible to use properly Linux would be an unmitigated disaster. It is not. In the end, the language isn't the problem, at all, it's bad software developers. Don't take my word for it, Linus Torvalds [0] has been quite vocal about this very issue. In fact, he recoils at C++. And, frankly, having seen what comes out of, as he put it, substandard programmers, I could not agree more. I believe part of the problem is how we've been teaching programming. The first thing anyone coming out of school reaches for are complex class hierarchies, complex data types and layers of unnecessary crud. 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. It ran about 400 times faster on the same iPhone hardware. The first was the result of lazy uninformed programming. The new version was simple, to the point, performant and had no bugs. Not to mention it used massively less memory. Here's something everyone needs to internalize: The processor --the hardware executing the code-- has no concept of object-oriented anything. No polymorphism, inheritance, complex data types, etc. When all the smoke and bullshit clears out, all it knows is a set of very simple and efficient operations we can weave together to do useful things. That's it. All the abstractions provided by languages are for the benefit of the programmer and have nothing whatsoever to do with code quality, correctness, bug content or suitability for a purpose. Which means most, if not all of that, isn't necessary. Modern programmers probably have no clue about the range an scale of projects that were completed without any issues while not having access to things like TDD, objects, massive libraries, complex data types, decorators, etc. I mean, we have written operating systems, sent people to the moon, saved lives with medical equipment, developed consumer and industrial products and more. Funny how all of that was possible and people today go on about needing to use a better language. In my opinion, there's only one area that can justify a new language. Everything else is well covered with C and, if one must C++. That is, AI. And no modern language fits the bill yet. It is hard to define what an AI-first language might look like. Being that I used APL professionally for nearly a decade, I happen to think that a language based on a notation developed for AI might be the best idea. The reasons are similar to the reasons for which musical and mathematical notation allow for rich expression of ideas. In other words, the justification isn't "I need it to write better code", but rather that, as the field advances, we might very well need better ways to describe what we want the computer to do. [0] http://harmful.cat-v.org/software/c++/linus http://harmful.cat-v.org/software/c++/linus
- javcasas 4y ago
  > Bad code is written every day in every language. The root causes for bad code do not include the chosen programming language. If language was a root cause, every codebase using language <x> would have problem. Clearly that isn't an issue. Every programming language has its own style of bad code. Java has enterprise OO overengineering. Haskell has monad obsession. C++ has enterprise OO template shenanigans. C has pointer crazyness. You should pick the programming language thinking on minimizing issues for the task at hand. That means C is good for the stuff for which is good (obviously) but not for everything but AI. Yes, C can cover everything. Now go write a web frontend in C, and you will see that, even though you somewhat can, it is a huge pain. And don't mistake me: I agree with you on OO huge frameworks being terrible, but I disagree with you at C being the pinnacle of programming for everything but AI. BTW: the Rust borrow checker just ensures that you have properly made your mind about what pieces of code own what data (and by owning, I mean who has the responsibility on writing and calling free on it). I think a piece of software ensuring that is a fair improvement. Worst case, the good programmers will just explain ot to the compiler via type annotations and just continue with their lifes. But they were going to do that already, wouldn't they?
  - robomartin 4y ago
    Por of this is what I would describe as a self-fulfilling prophecy effect. C is hard. You can't use it without thought or you'll create code that is excellent at crashing entire systems. Given that current CS instruction graduates "OO-first" high-level-of-abstraction developers, it is only natural that the tools and frameworks they create start at that level, rather than a lower level that requires more work, design and planning. One of my professors used to pound this idea that you should not write one line of code until you have devoted enough time to structural design and, more importantly, data representation. Of course, I am going back to a time when none of the modern languages existed. My choices at the time were assembler, Forth, C or APL. I won't even mention COBOL or FORTRAN as they were never part of my reality. Today people think nothing of having functions create and pass entire objects, dictionaries and other complex data structures that consume memory, time and energy (in very real terms, Python requires nearly 80 times more energy to do the same thing when compared to C). As this "contagion" doesn't seem to have an end in sight, CS reality today and in the future will move away from fast, space, time and energy efficient languages like C. The energy component is something I have been more aware of over time as we start to become more concerned with carbon neutrality and related issues of climate change. While Python is great for what I am going to call "lazy" programming (you don't have to give it any of the thought required in C or C++) it is objectively terrible in terms of execution time, memory footprint and energy consumption. Do we want a world dominated by Python applications? At a large scale you would need more computers --lots more-- energy and resources to do the same things that could be done with more efficient options. How many CS graduates come out of school with almost a Python-first education? Not to go too far, my own son, MS CS, spent nearly no time at all with assembler, Forth, C and C++ in school. It was crap like Java and utility like Python. Everything is worth learning, of course, but, give me a break. Thankfully he chose to listen to me and invested time and effort getting good at low-level programming. His first job out of school working for a very good company was C/C++ centric and he did great. Most of his school friends could not have landed that job. To be clear. I am not opposed to reaching for a variety of languages. I have. I still do. What I do not do is blame a language for problems of design, logic and engineering I create. The language isn't the problem. It never is. I am the problem. To beat it to death: It's like blaming a welding machine for making bad welds. So long as you don't have a truly horrible machine, someone with proper welding skills can make good welds. I learned this one the hard way actually. I have a Miller 130XP MIG welder. It's a very basic entry-level 120 VAC MIG welder. I could not make a good weld to save my life. Believe me, I tried. I watched videos, practiced, even got some instruction. I sucked. When I built my solar array I had to weld a number of custom brackets for the ground mount structure. Not trusting my capabilities I asked a professional welder I knew to do the welding. When he came over he saw my 130XP there and say "I'll just use your machine". He had monster machines in his truck. He proceeded to make stunningly good welds with a machine I was convinced was total crap. I could not believe my eyes. I eventually took college-level classes on welding and got massively better. I can make good welds with that little machine now, because I know what I am doing. And, yes, I later bought a more efficient modern inverter-based ESAB machine. The new machine wasn't going to make me a good welder. Blaming the machine was the wrong mental framework.

robomartin 4y ago

> Therefore, there are ways to write bad code. Do you think it's reasonable there may be better tools that prevent writing some cases of bad code? Bad code is written every day in every language. The root causes for bad code do not include the chosen programming language. If language was a root cause, every codebase using language <x> would have problem. Clearly that isn't an issue. Why do we write bad code then? - Unintended errors - Bad design - Not understanding the problem being solved - Not understanding the constraints - Not understanding the hardware/environment - Lack of skill - Lack of knowledge - Limited experience with the tools, frameworks, libraries, domain, etc. - No understanding of lower-level concepts - Lack of education (formal or self-taught, does not matter) - Not having a full grasp of fundamentals - Not being thorough or detail-oriented - Etc. There are a lot of reasons for which bad code is written. Language choice isn't one of them. It's an excuse. If baseline languages like C and C++ were so impossible to use properly Linux would be an unmitigated disaster. It is not. In the end, the language isn't the problem, at all, it's bad software developers. Don't take my word for it, Linus Torvalds [0] has been quite vocal about this very issue. In fact, he recoils at C++. And, frankly, having seen what comes out of, as he put it, substandard programmers, I could not agree more. I believe part of the problem is how we've been teaching programming. The first thing anyone coming out of school reaches for are complex class hierarchies, complex data types and layers of unnecessary crud. 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. It ran about 400 times faster on the same iPhone hardware. The first was the result of lazy uninformed programming. The new version was simple, to the point, performant and had no bugs. Not to mention it used massively less memory. Here's something everyone needs to internalize: The processor --the hardware executing the code-- has no concept of object-oriented anything. No polymorphism, inheritance, complex data types, etc. When all the smoke and bullshit clears out, all it knows is a set of very simple and efficient operations we can weave together to do useful things. That's it. All the abstractions provided by languages are for the benefit of the programmer and have nothing whatsoever to do with code quality, correctness, bug content or suitability for a purpose. Which means most, if not all of that, isn't necessary. Modern programmers probably have no clue about the range an scale of projects that were completed without any issues while not having access to things like TDD, objects, massive libraries, complex data types, decorators, etc. I mean, we have written operating systems, sent people to the moon, saved lives with medical equipment, developed consumer and industrial products and more. Funny how all of that was possible and people today go on about needing to use a better language. In my opinion, there's only one area that can justify a new language. Everything else is well covered with C and, if one must C++. That is, AI. And no modern language fits the bill yet. It is hard to define what an AI-first language might look like. Being that I used APL professionally for nearly a decade, I happen to think that a language based on a notation developed for AI might be the best idea. The reasons are similar to the reasons for which musical and mathematical notation allow for rich expression of ideas. In other words, the justification isn't "I need it to write better code", but rather that, as the field advances, we might very well need better ways to describe what we want the computer to do. [0] http://harmful.cat-v.org/software/c++/linus http://harmful.cat-v.org/software/c++/linus

javcasas 4y ago
> Bad code is written every day in every language. The root causes for bad code do not include the chosen programming language. If language was a root cause, every codebase using language <x> would have problem. Clearly that isn't an issue. Every programming language has its own style of bad code. Java has enterprise OO overengineering. Haskell has monad obsession. C++ has enterprise OO template shenanigans. C has pointer crazyness. You should pick the programming language thinking on minimizing issues for the task at hand. That means C is good for the stuff for which is good (obviously) but not for everything but AI. Yes, C can cover everything. Now go write a web frontend in C, and you will see that, even though you somewhat can, it is a huge pain. And don't mistake me: I agree with you on OO huge frameworks being terrible, but I disagree with you at C being the pinnacle of programming for everything but AI. BTW: the Rust borrow checker just ensures that you have properly made your mind about what pieces of code own what data (and by owning, I mean who has the responsibility on writing and calling free on it). I think a piece of software ensuring that is a fair improvement. Worst case, the good programmers will just explain ot to the compiler via type annotations and just continue with their lifes. But they were going to do that already, wouldn't they?
- robomartin 4y ago
  Por of this is what I would describe as a self-fulfilling prophecy effect. C is hard. You can't use it without thought or you'll create code that is excellent at crashing entire systems. Given that current CS instruction graduates "OO-first" high-level-of-abstraction developers, it is only natural that the tools and frameworks they create start at that level, rather than a lower level that requires more work, design and planning. One of my professors used to pound this idea that you should not write one line of code until you have devoted enough time to structural design and, more importantly, data representation. Of course, I am going back to a time when none of the modern languages existed. My choices at the time were assembler, Forth, C or APL. I won't even mention COBOL or FORTRAN as they were never part of my reality. Today people think nothing of having functions create and pass entire objects, dictionaries and other complex data structures that consume memory, time and energy (in very real terms, Python requires nearly 80 times more energy to do the same thing when compared to C). As this "contagion" doesn't seem to have an end in sight, CS reality today and in the future will move away from fast, space, time and energy efficient languages like C. The energy component is something I have been more aware of over time as we start to become more concerned with carbon neutrality and related issues of climate change. While Python is great for what I am going to call "lazy" programming (you don't have to give it any of the thought required in C or C++) it is objectively terrible in terms of execution time, memory footprint and energy consumption. Do we want a world dominated by Python applications? At a large scale you would need more computers --lots more-- energy and resources to do the same things that could be done with more efficient options. How many CS graduates come out of school with almost a Python-first education? Not to go too far, my own son, MS CS, spent nearly no time at all with assembler, Forth, C and C++ in school. It was crap like Java and utility like Python. Everything is worth learning, of course, but, give me a break. Thankfully he chose to listen to me and invested time and effort getting good at low-level programming. His first job out of school working for a very good company was C/C++ centric and he did great. Most of his school friends could not have landed that job. To be clear. I am not opposed to reaching for a variety of languages. I have. I still do. What I do not do is blame a language for problems of design, logic and engineering I create. The language isn't the problem. It never is. I am the problem. To beat it to death: It's like blaming a welding machine for making bad welds. So long as you don't have a truly horrible machine, someone with proper welding skills can make good welds. I learned this one the hard way actually. I have a Miller 130XP MIG welder. It's a very basic entry-level 120 VAC MIG welder. I could not make a good weld to save my life. Believe me, I tried. I watched videos, practiced, even got some instruction. I sucked. When I built my solar array I had to weld a number of custom brackets for the ground mount structure. Not trusting my capabilities I asked a professional welder I knew to do the welding. When he came over he saw my 130XP there and say "I'll just use your machine". He had monster machines in his truck. He proceeded to make stunningly good welds with a machine I was convinced was total crap. I could not believe my eyes. I eventually took college-level classes on welding and got massively better. I can make good welds with that little machine now, because I know what I am doing. And, yes, I later bought a more efficient modern inverter-based ESAB machine. The new machine wasn't going to make me a good welder. Blaming the machine was the wrong mental framework.