411–420 of 554 posts
Earlier quoted context omitted.
Probably because you think you're smart AND you write excessively clean code and are excessively anal about it. Whether you actually are smart is a different story.
You have constructed a representation of me in your head that in no way reflects reality. Good luck in life.
Earlier quoted context omitted.
On my Macbook Pro M2, having a browser window on one half of the screen, and my IDE on the other, with a file tree viewer pane and another pane for my LLM tools, a terminal pane at the bottom... I've never been more pressed for real estate for my actual code editing pane. Even 80 chars has me scrolling horizontally. Secondary monitors help but not when you frequently work away from your desk.
Coding on a laptop, even a name-drop-tier status shibboleth, is most of your problem. You write code on a 15" screen when you must for physical/location reasons. You shouldn't ever choose to do it or design your workflow around that constraint. A 42" 4k TV (got it for $2-300 at the start of the pandemic) gives me four 80-90 column text windows on a mid-tier chromebook. You could not pay me enough to do that same work…
Uncle Bob's insistence that functions should be 2-4 lines long is baffling to me. I don't understand how he can be taken seriously. Is there a single application in the entire world with substantial functionality that conforms to this rule?
Yes. This works but only if the functions are pure and using pure function composition. Uncle bob doesn’t mention this. createspecialString(y) = Capitalizefirstletter . MakealllowerCase . AddNumberSuffix . removeLetterA . removeLetterB . ConcatwithWord(x) CapitalizeFirstLetter(a) = a[0].upper() + a[1:] MakeAllLowercase(a) = map(a, (t) => t.lower()) Addnumbersuffix(a) a + 3.toString() RemoveLetterA(t) = filter(t, (s)…
Earlier quoted context omitted.
[flagged]
Then say ugly. "Shitty" can be ambiguous as you see. Most people would classify buggy code as shitty code. > Then you've never been around the smartest people. Likely you've been around smarter then average people. This is essentially using your own belief as proof that your belief is correct. You say I haven't been around the smartest people because I say the smartest people don't do what you claim. You are saying "…
I have quantitative evidence of this. There IQs were above 150.
>Complex is easy. Simple is hard. And yes, some things are inherently more complex than others. But the goal is to hold the important things in your head. Offload as much as you can so you can focus on what matters.
complex is not easy. And simple is not necessarily always hard. The story is obviously more complex then this.
>No. It's not the point you are making.
It is. It was a rhetorical question.
I looked at everything you said. First off I never said anything about strict adeherence to a style. Smart people have there preferences.
>And the rules should be logical and essentially second nature. Like indenting is completely optional in most languages. But proper indenting allows you to better visualize the flow of the code. Nobody reads/writes minified JavaScript.
I've seen smart people who can do this. They don't even really care.
Earlier quoted context omitted.
Function names are limited. E.g. can't provide a circuit diagram of what you're controlling in a function name. But you can do that in a comment (either with ASCII art or an image link).
Agreed. So why not stuff as much as possible into the name before resorting to a comment? Prose looks ugly as a name but the utility is not diminished.
That's not to say embed nothing into the names. I'm quite fond of the "Long Names are Long" blog post[1]: names need to clearly refer to what the named thing does, and precise enough to exclude stuff it doesn't do. Names can certainly get too short, e.g. the C "sprint fast" function `sprintf` is probably too short to be easily understood.
[1] https://journal.stuffwithstuff.com/2016/06/16/long-names-are...
Earlier quoted context omitted.
For some reason in software there seems to be an incredibly large space for non-evidence based thinking and belief systems. I wonder if that's because in a lot of cases (depending on the domain) the space of possible valid/working solutions is near infinite, and if you don't have hard requirements that are backed up by measurements you're free to concieve of any valid system structure and justify it as 'better' witho…
> For some reason in software there seems to be an incredibly large space for non-evidence based thinking and belief systems. The secondary problem is that book authors have become extremely good at inventing pseudo-evidence to support their claims. It most commonly takes the form of “I talked to X companies with Y total number of employees over Z years and therefore I know what works best”. If you cut out all of the…
Which results in the idea of 'good practice', 'best practice' and 'bad practice', and nobody wants to be seen as the person doing things that are considered bad practice, because that would imply that you're a bad developer.
And I almost always hesitate to use the term 'engineer' because as far as I know engineering is considered to be a practice/process that uses measurements and results to drive decision-making, unlike various areas in software. Can you imagine if the same kind of thinking was applied in civil engineering? "This new material has a lot of stars on GitHub and everyone is saying the old materials are bad practice."*
* Which is a thing of course (see: Asbestos) but only in the places with measurable observable outputs.
It still blows my mind how dogmatic some people can be about things like this. I don't understand why anyone takes these things as gospel. Who else has had to deal with idiots who froth at the mouth when you exceed an 80 line character margin? And it's not just programming styles, patterns and idioms. It's arguably even worse when it comes to tech stacks and solution architecture. It's super-frustrating when I'm deal…
Yes, Uncle Bob is certainly capable of being pedantic. A friend of mine, a Smalltalk Consultant, partnered with him for a while. "With Uncle Bob, it's his way or the highway." His clean code work is certainly pretty dogmatic. As I recall, he says that Java is not object oriented. But if my memory serves me correctly, his book about C++ (Designing Object-Oriented C++ Applications Using the Booch Method) has some excel…
Java technically isn't OO in the strictest sense (Smalltalk, Ruby). It is OO in the modern sense (where modern >= 1980s, C++). Though I am not sure if this is what Bob is referring to - I don't have any respect for the man or his ideas, so my biased guess is his definition of OO is shared only between him and his fans.
Earlier quoted context omitted.
It's better credentials and experiential basis than most other programming books. Moreover, it is the students' inexperience which give this text credence --- since it results in their making errors and poor architectural/design choices it affords the chance of correction. I think it is remarkable that the author switched from "modules should be specialized" to "modules should be generalized" (rough paraphrasing, mai…
> It's better credentials and experiential basis than most other programming books. When considering coding advice, I just don't find credentials or the results of a coding experiment matter much, especially if it involves students. I run through the scenarios in my head and pick the option that makes sense given the context and competing priorities. > I think it is remarkable that the author switched from "modules s…
At a quick glance, that book seems to align well with APoSD --- what aspects do you believe run counter to it?
It still blows my mind how dogmatic some people can be about things like this. I don't understand why anyone takes these things as gospel. Who else has had to deal with idiots who froth at the mouth when you exceed an 80 line character margin? And it's not just programming styles, patterns and idioms. It's arguably even worse when it comes to tech stacks and solution architecture. It's super-frustrating when I'm deal…
Yes, Uncle Bob is certainly capable of being pedantic. A friend of mine, a Smalltalk Consultant, partnered with him for a while. "With Uncle Bob, it's his way or the highway." His clean code work is certainly pretty dogmatic. As I recall, he says that Java is not object oriented. But if my memory serves me correctly, his book about C++ (Designing Object-Oriented C++ Applications Using the Booch Method) has some excel…
If my memory serves me correctly, Grady Booch himself had a book with roughly the same title, except that his name would not be in the title, of course, but would be there as the author. I think I read a good amount of it long ago, and liked it.
Edit: I googled, the book is mentioned here under the section Booch method :