Earlier quoted context omitted.
> psychopathic scammers like Robert Martin That is a pretty wild take. Would you like to elaborate on that?
have you read any of the arrant nonsense he comes out with?
[deleted]
It's hard to write code for computers, but it's harder to write code for humans
11–20 of 147 posts
Re: It's hard to write code for computers, but it's harder to write code for humans
#12On a side note, I have wondered if LLMs work more effectively with code that is well-structured and easy for humans to read than they do with spaghetti. Has anybody researched this?
Re: It's hard to write code for computers, but it's harder to write code for humans
#13A nice read, but I think there is a contradiction here that needs to be cleared up: 1) On one hand, the author says that humans learn from examples, not core concepts. 2) On the other hand, the author emphasises the importance of reducing "conceptual overload", by reducing the number of concepts while maintaining their expressiveness. So it is not that core concepts are not important for learning. Rather, it is essen…
I didn't find it contradictory. The first one is about how to start learning about something more easily and the second one about how to organize it all so that it's easier to use and understand as a whole. That may also help with getting started too.
I personally agree that examples are a very efficient way to get started and you can learn the details incrementally in a top-down fashion. Some text books during my studies took the bottom-up approach (even explicitly mentioned it) and I never quite liked it.
If the core concepts are simple and not too many, then it probably doesn't matter that much. The point is to get started easily.
Re: It's hard to write code for computers, but it's harder to write code for humans
#14If humans understand how computers work, then you just have to write code for computers and can ignore the human element.
Unfortunately the last few decades we decided that software engineers don't need to know how computers work anymore.
Re: It's hard to write code for computers, but it's harder to write code for humans
#15If humans understand how computers work, then you just have to write code for computers and can ignore the human element. Unfortunately the last few decades we decided that software engineers don't need to know how computers work anymore.
Obfuscated C contest seems to be challenging your view. Or Brainfuck.
Intentional coding-trolling aside, if whatever is happening in the head of the original developer is muddled, the resulting code is likely to be confusing even for people who know computers from the inside out.
Re: It's hard to write code for computers, but it's harder to write code for humans
#16Earlier quoted context omitted.
> psychopathic scammers like Robert Martin That is a pretty wild take. Would you like to elaborate on that?
have you read any of the arrant nonsense he comes out with?
Right, but "psychopathic scammer" dials the criticism up a few notches, possibly to unreasonable levels - which i suspect is the point being made here.
(That's certainly the point I'd have been making if I'd written the post you replied to.)
Re: It's hard to write code for computers, but it's harder to write code for humans
#17Bit of a side issue for me: I was working on my Unity game the other day and thought to myself, have IDE's really not progressed all that much in the last 10-20 years? Default intellisense has definitely gotten a lot better, but apart from that and a few other minor things the whole concept of coding feels pretty much the same today as back then. The biggest positive change for me is outside of the editor, it has bec…
Visual Basic in VS has aggressive autocomplete and it gets pretty annoying. You often want to write things in a different order and end up having to delete the auto-inserted endif/quotes/brackets/variable names (if it's not yet declared, it changes it to become something else that is), etc.
Re: It's hard to write code for computers, but it's harder to write code for humans
#18Bit of a side issue for me: I was working on my Unity game the other day and thought to myself, have IDE's really not progressed all that much in the last 10-20 years? Default intellisense has definitely gotten a lot better, but apart from that and a few other minor things the whole concept of coding feels pretty much the same today as back then. The biggest positive change for me is outside of the editor, it has bec…
I agree about auto-complete, but already the editor Brief for MS-DOS, at least some 35 years ago, allowed you to define arbitrary templates for auto-completion.
For example, when writing a C program you could choose to have "f" expanded to "for (=; ;}" or whatever indentation you preferred.
There are many modern programming editors that allow a similar customization, though unfortunately for many of them this requires a more complicated procedure than in the far past.
For any programming language with a verbose syntax, I consider necessary to take your time and define in your editor templates that would allow the fast writing of any program structure with a minimum number of key presses.
Re: It's hard to write code for computers, but it's harder to write code for humans
#19Bit of a side issue for me: I was working on my Unity game the other day and thought to myself, have IDE's really not progressed all that much in the last 10-20 years? Default intellisense has definitely gotten a lot better, but apart from that and a few other minor things the whole concept of coding feels pretty much the same today as back then. The biggest positive change for me is outside of the editor, it has bec…
About the first item on your wishlist: If by "brackets" you mean {} (in C-like languages), there are IDEs that can be configured to create pairs of them every time you hit return after an expression that can take them. The downside (if you care) is that, if you wanted to write an if, while, or for with only one line, and therefore no scope delimiters, it will force you to create the scope anyway. You may not care.
If by "brackets", you mean [], to access an element of an array or vector or map or whatever, yes, it could do that as soon as you gave it the name of an array or vector or map or whatever. But then if you wanted to deal with the array or vector or map as a whole (which you want to do sometimes), the brackets have to go. I would estimate that 30% of the time I want to deal with the array as a whole, so such a feature would be annoying and in my way 1/3 of the time.
Terminators are a win more of the time. But when they're not, I meant to be continuing one line of code across two lines of file. If it auto-added a terminator (semicolon, say) at the end of the first line as it opened the second, I might not even notice until compile time. That would be highly annoying.
Public and private I don't want determined by a tool auto-determining the "most efficient" set. I want them determined by my sense of what the class is, and therefore what the public interface should be. Some of the things that are private are less efficient, but are private because they're implementation details and I don't want callers able to fiddle with them.
So, that's my whiny personal take on some things on your list. Maybe I've adapted myself to the existing tools. But I personally think that many of your items, if you implement them, you will find that you don't really like how they work out.
Re: It's hard to write code for computers, but it's harder to write code for humans
#20As Spolsky said a long time ago:
> It’s harder to read code than to write it.