Programming - Naming Things Is Easy

[@R.Daneel]

The pair of scissors example is both bad and perfectly demonstrates the underlying complaint that English sucks as a technical language. A pair of scissors is a pair. Half of a pair of scissors is a scissor. That doesn't sound right because English has changed. Scissor is the same root as incisor (like your teeth) and incision (like a scalpel). A cutter. A pair of cutters. We lost that, but kept "pair of" and forgot why. So arguing "what do we call half of a pair of scissors" is both wrong and oh, so right in context.

[@guilhempelissier9653]

Thanks, I'm not a native speaker and I was like "what do you mean how do you call half a pair of scissors, isn't that just a scissor?"

[@paclarap]

Exactly, the main problem is that English is taught as is aka: "Swallow it. Don't ask why we say it like that, just do it too." And on top of that it is frowned upon to just add back in some logic or be that bit more verbose that actually helps to clearly distinct parts of a concept. Simple example, i prefix my Singletons with "the", a value retrieved randomly from a given set with "any", a temporary instance/object/value generated/crafted in a scope is prefixed with "one"+Singular of the array/set/collection/class etc. which is always plural-"s". And so on. I am laughed at for decades by using this "childish" verbosity, but it helps create a meta-layer that even is programmatically accessible. Same goes for using concise and compact but specific descriptions for function-names in a fixed order, to not rely on vague simple verbs. Another keypoint is using words that have a fixed length, to create another meta-layer allowing easily to identify the type of underlying design-pattern, datatype, etc. as i classify these that way while still allowing to be verbose (there are many words meaning almost the same and in many cases have the same length as those that are in relation to the others needed in a specific context) - allows for very fast "reading" of the structure and data- and control- flow of the code and also to prototype with a "this is what will happen and needs to be done" without commenting on top. That combined with nesting/dot-syntax where possible allows to create complete contexts upfront just by naming them and have an immediate todo-list which can be worked out manually or even automated.

[@sizur]

@@paclarapHey, I like this. Adopting the/any/one singular/plural. Got more?

[@QuotePilgrim]

So is half a pair of pants just a pant? 😆

[@ttt69420]

I don't understand why you're explaining something we all know without being prompted to do so? You're also incorrect. English is the best technical language in the world, by far, because of it's large vocabulary and nuance. At least 10 times larger than Chinese, for instance. The issue isn't the language, it's people.

[@davidmurphy563]

Got it. Call everything abstractBaseMonadHandler Thanks!

[@L.Mandrake]

You forgot about FactorySingleton

[@oscarfriberg7661]

”Solve the problem you actually have, not the problem you think you might have in the future” These are words to live by. I’ve encountered this many times. Some programmer writes overly complicated code in expectation of a future problem. That future problem rarely happens. And if that future problem happens, it’s often the wrong solution. So now the code is more difficult to work with for no reason at all.

[@rycona9878]

This, oh so very much. My bias is that I'm a bit more ad hoc when it comes to building my own projects, and the lack of more detailed planning leads to such anxiety - which leads to the pendulum swinging back the other way towards over- and unnecessary abstraction - which leads to the dark side (and another project in purgatory). The thing I have with more detailed planning is that most of the time I end up throwing out a good chunk of the plan anyway, and sure, that's probably because I'm not the best planner (my life reflects). There's merit to planning, because at least, the plan may still act as a guide, but I'm not convinced on any general change in productivity for myself in terms of planning and changing vs. more ad-hoc and changing as I go. With changing in either case, the on-the-fly naming/abstraction work persists, so more time with more detailed planning (or at least my approach to it) generally seems more wasteful in the scope of the size of my projects. For larger projects with many, many people - I couldn't imagine not having more detailed planning. My ire there gets more into quality of documentation of a system during/after implementation, if there's much of any at all. At my last job, we had little bandwidth for most internal documentation of a build -- outside of if code comments happened to be made, if there's something that happened to be specifically referenced in work ticket data (or having to search for related tickets), or some piece of something lingering into history in some Team chat exchange and none of that chat's participants held a pointer in their brain to reference it.

[@DeveloperChris]

I used to tell my customers (retired now), don't try to jump that hurdle until you get there. Too many would worry about future issues that may never arise. This in turn would slow down the design phase, and thus the project.

[@nihil2501]

i actually have a feeling that as long as the hypothesized abstraction is easy to nuke, wrong hypotheses about the concepts being inteoduced is actually a critical way to code well

[@PretendCoding]

This applies to most things in life as well. A lot of people, myself foremost, spend time planning for what might happen instead of dealing with what's happening right now.

[@JohnDoe-vr4et]

I enjoyed this presentation because it gave me new insight as a programmer of over 20 years, was concise and clear, without clickbait, presented in a calm way. Great for watching with your morning coffee. Thank you.

[@yosarianalter4537]

That one guy on your team that just knows better...

[@zulupox]

This is a gem. I love things that challenge long known truths. Gone through the “write spaghetti and don’t comment at all”-phase , “comment everything”-phase, “Let the code speak for itself, don’t comment”-phase. And now you point out that comments and variable names suffer from the same problem. Thank you!

[@lenickramone]

7:45 definitely not. You put like in the case of the function 'mapQuoteToBestSubQuote()' you dont have the code, which is not true. So basically on one side you have a loop, which manipulates some variables and some data structure, and yeah, if you read it you will understand this manipulation, but you will not have any CONTEXT of the WHY that manipulation is happening. On the other side you have the same code (i.e. declaring some variables, some if, checking here and there, populating a list) PLUS the name 'mapQuoteToBestSubQuote(). So now you KNOW what is the intent of that function. It's like saying for guitar players: - Play the first string fret 2; second string fret 3; third string fret 2, fourth string loose Anyone understand this. Or you can say 'Play a D chord' You're stating that 'Play a D chord' people will not know exactly what D chord this is.... well, if you want to see exactly what D chord it is, then you go to the function and see it.

[@NabekenProG87]

Names describe intent, code describes itself. Names are bad at describing technical details. Thats the point

[@paulembleton1733]

⁠@@NabekenProG87not sure that is the point - novices aside it’s obvious that names should state intent rather than how. It seems more an argument against using names, or I don’t understand the point at all. Names serve as a double-check that the intent and implementation match. To take the guitar chord analogy, if someone says I’m playing D but their fingers are positioned for a C chord, then we know they made a mistake either with the name or the implementation. But if they just play the chord.

[@ttt69420]

@@NabekenProG87 That isn't the point. English is an amazing describer. It has a more dense vocabulary than any language in the world. You're just bad at it (the actual point of the video)

[@NabekenProG87]

@@ttt69420 Woah, seems I stepped into a landmine and an elitist sprung up. Thx for the missing argument, generalization and insult, appreciate it

[@NabekenProG87]

@@paulembleton1733 Is the last sentence cut off? I think names are good, but I think the video reminds me of cases where names were poorly chosen, because someone didn't take their time. The video talks about taking an approach of avoiding this problem. The double checking of names with code only works if the name is descriptive, which heavily depends on the codebase. Even worse if you have years of tribal knowledge built up and then bring in someone new. I'm not saying that the idea of this video is good, but the more complex the function, the less helpful the name of it is. Only in a perfect world can we ALWAYS use the name for double checking

[@MukweLaif]

This channel is gravely underated and it has been for a while. Even these videos, that are 4 years old as I watch them, are well made and very insightful.

[@moonbiscuit8742]

Great talk. Wondeful to see purposeful pushback against dogmas.

[@puzzlinggamedev]

Pedantic note: scissors' halves are not mirror-reflected, they have the same shape (except when one has a bigger handle for the thumb)

[@ttt69420]

You clearly don't understand what mirrored means.

[@Wilker_uwu]

a lot of scissors are fully symmetrical

[@ttt69420]

@@Wilker_uwu No, they aren't. No pair of scissors are fully symmetrical because that's a physical impossibility.

[@Wilker_uwu]

@@ttt69420 rotationally symmetrical on the Y axis, and reflectively symmetrical, assuming Y axis is up and the tip of the scissors are pointing upwards

[@shadyacr]

​@@ttt69420i might argue that flipped != mirrored

[@IvanToshkov]

There are many things that I disagree with in this video. Names aren't comments, They may be text, but they serve different purposes. The name should represent what the thing is/what it does, while the comment should clarify things like how to use it, how it works, etc. I keep seeing this "hate" for the DRY principle. And the examples are often very stupid, like the scissors example or the cat/chair one. The DRY principle is more like a guideline than an actual rule. It doesn't say "you should never repeat code." It says "whenever you're repeating some code, think if it makes sense to create an abstraction out of it." But some people think that "WYRSCTIIMSTCAAOOI" is not a good acronym so "DRY" won. The argument that "if you can read the code you can generally understand it" is problematic in the context of this video. The reason that you can understand it is that it contains names, which represent well understood concepts. Imagine if you inline all the named code and then try to read it. Or try to read the machine code produced by the compiler, which has no names at all. Are these easier to understand? I think not. Overall, even the good advise in this video is too prescriptive. It suffers from the same kind of problem as DRY if you take it literally. E.g. the literal treatment of "prioritize fewer names over better abstraction" would directly lead to writing machine code (not even Assembly, as it has names). A better way of saying this is to just use Occam's razor: "Entities must not be multiplied beyond necessity." The intent is clear and it still leaves the final decision to the developer.

[@antonuramer]

Names being worse than comments at 7:00 makes no sense as a point. At least names are actually a part of the program, e. g. you are required to reliably reference the same thing by the same name. They are also much more likely to be kept up-to-date as they are part of the code that's compiled/interpreted, so they are forced to be changed sometimes. While comments are just arbitrary English text with zero mandated connection to anything the code does. That's why people talk about self-documenting code, not because naming things is easy, but because keeping names in check is somewhat easier than keeping comments relevant.

[@antonuramer]

Also hard disagree on comments not being used to describe future functionality at 17:15 . That might not be the way people do it in "management-driven" environments, but in "programmer-driven" environments it's often that code is the main source of truth for long term planning, and describing long-term design decisions and goals is the perfect use case for comments. Obviously that's only relevant for large projects, which most people don't participate in, but for small projects more or less anything works fine.

[@Soluna7]

I too was surprised when I heard that in the video. In practice, what I tend to use is a mix of the two. I'm working on asteonomical calculations at the moment, and I have a variable called "Obliquity" with a comment next to it saying "Axial tilt of the body, in degrees." But even with a small program like this, I've forgotten to update comments, so honestly I don't agree with the disdain for "good code is self documenting," because ideally it should be, or as close to that as possible.

[@user-tk2jy8xr8b]

There is a perfect solution: point-free programming. De Bruijn index will also do the job. Imagine a program without a single nat-lang word, just indexes, oh what a joy

[@ChristopherSalcido]

Thank you for this video. I've been telling my coworkers for years about how the DRY principle should not be applied wherever you see duplicate code or need similar functionality. Ten years ago I had a coworker who wrote (using your example) "HouseObjectWith4Legs" before writing "Cat" and "Chair" because he knew they needed duplicate functionality. The two features "Cat" and "Chair" however, were just that, two separate features. It soon became a pain to deal with either of these features because their requirements diverged. We had many functions that accepted the objects of the base class "HouseObjectWith4Legs", but the functions had to do things differently for each derived type and therefore had to determine which derived type it had and split their logic accordingly. This led to so much maintenance whenever either feature's requirements changed because all the helper functions also had to change and not break the other feature. The code cohesion became very low and code coupling very high. Because of this, I always tell my coworkers do not share code between things that are not the same, even if the logic appears to be the same. Think ahead to what would happen if the logic of one needs to change and the other does not. If the logic can still easily be changed for one without affecting the other, then the DRY principle applies, otherwise it does not. In the end, it's much easier in the future of your code to abstract copy/pasted code into a shared module or diverge their logic than it is to separate shared modules into separate modules with diverging logic, so take the path of least resistance. Apply the YAGNI (You Aren't Going To Need It) principle first to the DRY principle *until you do need it*.

[@QuotePilgrim]

a^2 + b^2 = c^2 is not enough to describe the Pythagorean theorem though. You NEED the plain English description to even understand what that formula is. The formula alone doesn't tell you that it's at all related to a right triangle, nor does it tell you what a right triangle even is. It doesn't tell you that "a" and "b" are the legs of the triangle and "c" is the hypotenuse; it doesn't explain what legs in a right triangle are, or what a hypotenuse is. You cannot understand, and therefore cannot use, that formula without knowing all of that information, which has to be communicated via a language a human understands, such as English. Without the description the formula cannot be understood, or even exist for that matter. On a side note, half a pair of scissors is a just a scissor, that is literally a no-brainer. Any other name shows you don't understand why it's called a pair of scissors nor how plurals work.

[@ladyravendale1]

The example of the Pythagorean theorem assumes you already know algebra, just like self-documenting code assumes you already know that coding language. You can’t learn algebra/a coding language without first using English, but once you know the new language it’s better to describe everything in it instead of English. That’s the point of this video.

[@redpepper74]

“Scissor” isn’t really a standalone concept in English, I would call it “scissor blade” to clarify that you are _actually_ talking about half a pair instead of the full pair

[@ttt69420]

His premise is incorrect. English is the greatest technical language in the world by a large margin. The point he's trying to make is a good one, just not supported correctly.

[@QuotePilgrim]

@@ladyravendale1 His point is that abstracting too much is a bad idea, and the formula "a^2 + b^2 = c^2" is not only an abstraction of the Pythagorean theorem, it is built on top of several other abstractions, such as the concept of exponentiation, addition, equality, and the fact that you can name variables. By his own argument the plain English description of the theorem is better than the formula used to represent it because it abstracts a lot less.

[@QuotePilgrim]

@@redpepper74 I mean sure, but if you think about why we call it "a pair of scissors" for like two seconds you should be able to realize that it's because it is made of two pieces, each being one scissor (even if the concept of "one scissor" is somewhat alien to English). That's pretty self-evident.

[@constantinhirsch7200]

There are some points I agree with and some I don't. Agree: Having fewer things in your code is good. Avoid premature abstraction. Name things as what they are, not what they could be in the future. I particularly enjoyed seeing "avoid premature abstraction" being derived from "names are hard". Disagree: 1. Actively avoiding to give a name to something that already exists in my opinion is harmful in the same way that not commenting it would be. E.g. we can do a lot of things in one line with filters, map etc. Once these expressions grow large, it is almost always a good idea to break them up, just to give the intermediate result a name. Especially names with a narrow scope (e.g. inside a function) should be embraced and not avoided. 2. If a function becomes too long but you don't want to split it because that would introduce too many names, you should introduce a new scope for these names to go without bothering any of the existing code files. Large blocks of code *are* inherently bad because "local" variables have a way too big scope in that scenario. It's bad when some iterator variable from the start of a 100-line function is still visible long after becoming invalid. The solution is to create a new code file and make all the new function names private in there, only exposing the original name to the caller. This still guarantees that the new pieces won't be put together in wrong ways because it's all encapsulated in one place and they can't be called from the outside. 3. Calling code "self-documenting" and having many good names in that code is not "ironic" or contradictory. The code becomes self-documenting *because of* the names. Names and comments are similar (which you also said in your video) and great use of one alleviates the pressure to make great use of the other. The best variant is of course to have both, without repeating yourself.

[@skillfulfighter23]

Thank you for sharing, this is useful insight

[@paulkanja]

You do offer some good points bu here are some counter arguments: 1. Long complex lines of code are a different problem and naming is the lowest concern here 2. Functions actually tend to self-manage if you split them up by their actual functionality. If one gets too long, its most like trying to achieve an extremely abstract concept and probably should be split into more concrete components. 3. Having good names isn't bad. Having too many names is bad. The more the names, the more to keep track of. Besides, a "good name" is subjective. Java standard library names are descriptive, to a fault. C standard library names are often not, to a fault. TLDR: the best argument for naming is just: Be reasonable and be consistent

[@software_development_os]

"Calling code "self-documenting" and having many good names in that code is not "ironic" or contradictory. The code becomes self-documenting because of the names." In theory I totally agree, but I never saw such a thing, ever. I only saw "very good" names in one project in over 25+ years, but that was a relative small project, so the term "many" is not valid in that case. Where did you see a code-base with MANY good names?

[@y2kaoz]

TL;DW; Write spaghetti code in long functions full of undescriptive primitive types and magic numbers so you don't have to "name things".

[@NukeCloudstalker]

Better than abstraction hell.

[@oli_dev]

It aint spagetti code if its all self-contained inside one function. Generally spagetti code is when you have crazy dependencies between modules, with crazy coupling

[@NukeCloudstalker]

@@oli_dev Ironically, if you trace the code-paths of what a lot of people call "best practice" (and SOLID in particular), you get an absolute nightmare of spaghetti codepaths. Code reuse and abstraction being the main culprits behind that. And it really should go without saying, but experience tells me it is best to state it upfront: I am obviously not speaking against those things, only pointing to their often understated and underestimated costs)

[@IvanToshkov]

@@oli_dev This is not true. You can have spaghetti code in a single function. Just use lots of loops, ifs, breaks and gotos, if your language still supports it and you can cook yourself a good spaghetti in no time. The reason that you don't see it is because most people don't write this way anymore. But structured programming was an attempt to address exactly this coding "style."

[@kagreen2k]

I have been a developer for over 35 years. This is a fabulous video. Not too many people care about software craftsmanship like this any more.

[@nicbarkeragain]

Thank you, I really appreciate that. I made this talk when I was still very inexperienced in summarising and delivering my thoughts, but I really believe that simplicity in software is the core aim and should always be the north star 🙂

[@obvious_humor]

The problem isn't the names. The problem is the lack of context.

[@lordofthe6string]

I was watching Jon Blow the other day and he had a variable named something like last_known_position_of_character_so_camera_has_something_to_look_at_after_character_disappears I found it both hilarious and profound.

[@InkLore-p3h]

“A squared plus B squared equals C squared” is already an English sentence. The operators and glyphs we add don’t overrule the underlying language, otherwise none of our concepts would have spoken forms. Same with code-I could in fact read out each character the same way as I can in English. You’re not avoiding the naming problem, just abstracting it-these mathematical languages are themselves abstraction overheads.

[@za1ruc]

Yea, I get that. But I think he was just trying to get a point accross

[@JohnSmith-fz1ih]

But the point is wrong… his example was using many abstractions, yet he was presenting it as though the formula was the direct represent and not an abstraction.

[@JohnSmith-fz1ih]

The point he inadvertently made was “If you can use domain language that is already established, mature, and understood by anyone reading your code, that allows you to use a high-level abstraction that is much more concise and easily understood than spelling everything out”. But if I recall that part of the video correctly, he was saying the formula was more direct and not abstracted.

[@za1ruc]

@@JohnSmith-fz1ih let's look at it this way, even if the notation is replaced with words, it's still clearer and much shorter than the English paragraph. Even if we try and use fewer english words, there is a loss of clarity and risk of miscommunication. Edit: I do agree with you about the domain specific language being a big added cost

[@JohnSmith-fz1ih]

@@za1ruc The reason the formula is a more concise representation is because of the abstractions it is built on. These include 1) that in math you can use variables to represent an unknown 2) what a superscript 2 means 3) what a hypotenuse is 4) what a right angle is 5) what the other sides are (the two sides that aren’t the hypotenuse, I can’t remember their name). I’m sure there are more (including what equals sign represents, and what multiplication is). I get that a lot of this is stuff we’re all so familiar with that we take it as a given. But that’s only because we have been taught it. We understand the language of the domain that the representation is in (in this case, the mathematical notation) and it is this that allows us to communicate at a much higher level. Details like “a superscript 2 means you take the base value and multiply it by itself” is abstracted away. It’s been a couple of days since I watched the video, but my recollection was his point was “look at how much clearer it is using this direct representation of the problem, instead of using abstractions that hide the detail”. That view is wrong. He is inadvertently using an example that is built on many abstractions and saying how much easier that representation is. Yes, yes it is. Because of the abstractions it is built on.

[@RGD2k]

"The root of all Evil is Early Optimisation" - RMS (IIRC). The rule of thumb goes: don't factor it until you've got at least more than three copy-paste copies. Also remember: Beauty is in the eye of the beholder: This means that only the technicall savvy can appreciate the beauty that might exist in an apparent rats nest of spagetti-wiring. Yet it might be there: The complexity on display might actually be simplicity because its presentation allows the understanding engineer to simply trace visually how everything is actually connected. It may appear at first glance incomprehensible, but it might just be a byproduct honestly showing exactly what it is. When I have something I need to trouble-shoot, I much rather prefer something which is 'as simple as possible, but no simpler' to the 'obviously more beautiful' presentation that hides the crucial 'devil's-details' under covers.

[@JakoTheWacko]

The "don't alias things" point seems strange to me. Often, I find I have complex types composed of simpler ones that isn't clear without aliasing eg. Map is much less clear than Map where PersonID = Int Pos = Pair

[@Action2me]

12:55 I used to hate in-line code when I was new. It made code hard to read. As I’ve gotten more experienced, I use in-line code way more. For example, with CSS, it’s actually harder to have 8-12 different classes for each situation where I need a row. Just throw a “display: flex” in the style attribute and be done with it. It’s so much harder to hunt down the code in a style sheet.

[@IvanToshkov]

You're bringing CSS to a programming language fight :D

[@IterationFunk]

Loved seeing point 16 on here (Do repeat yourself). A good interview question is to ask the candidate to rank the most common programming principles. And if they put DRY over KISS I would see it as a bit of a red flag. A lot of junior programmers get stuck in merging code and creating abstractions in the name of DRY, and fail to see how costly the added complexity actually was. I hope more programmers internalize this knowledge so DRY is prefaced with a lot of words of caution when taught in schools in the future.

[@KnightMirkoYo]

I would really appreciate some more examples, especially if the leaky abstraction name from the last point

[@Desi-qw9fc]

14:45 should have a caveat. If you are transforming the value in any way, it should absolutely have a different name (e.g. itemPrice vs itemPriceInCents). It is easier to trace the evolution of an object when its name changes through the code.

[@lializ_666]

And that's also a good rule of thumb of when you're transforming like that, you probably should do it in another function or method, and return it (unless it's a really simple transformation)

[@JohnSmith-fz1ih]

At 13:00 “code is always much easier to read and understand than the name is”. Hard disagree from me. I frequently break lines of code out into their own function just so I get to name that block of code. Those lines of code are at least somewhat hard to understand, often they are very non-obvious. I can’t be the only person to frequently come across a block of code (even something of only a few lines) and have to step through it only to figure out it’s doing something simple to understand (conceptually). Those “Oh, all it’s doing is ” code blocks are what I take and move to a “doWhatever()” function. I personally prefer long names (like getCustomerIDsFromArray()) over shorter names because naming things is hard, and I prefer long descriptive names over shorter ones that may not tell the whole story or might be misleading. But the exact name is far less important than the principle of getting those non-obvious code blocks out into their own named functions. Leaving them in a large function just adds mental load. I don’t want to scroll through a code block and have to keep in my short-term memory that “that for loop just gets IDs from the customers array”, “that chunk of code just formats the time according to the local timezone”. I’d much rather have a far shorter function with a few other function calls within it such as getCustomerIDsFromArray() and formatToLocalTime(). I find it so much easier to skim read the original function that way. If I’m looking for the code that deals with customer IDs my mind can very quickly skip past the formatToLocalTime() function because I know that’s nothing to do with what I want. And when I see the call to getCustomerIDsFromArray() I know I’m in the right area. I even break out one-liners into their own functions sometimes. If it’s non-obvious what the one-liner does… if I have to use mental cycles before going “oh, that’s just doing ” then my preference is to break it out so I can name it. Code re-use is a benefit of this way of working (along with others). But it’s not the primary reason I do it. I do it so I can skim read my code and know what’s going on.

[@redpepper74]

Great presentation - I don’t agree with all of your points, but it definitely has made me think differently about how my codebase works, and I think there’s a lot of good bits of knowledge that you’ve shared here :)

[@nicbarkeragain]

Thanks, and I really appreciate you politely mentioning that you disagree 🙂

[@kayakMike1000]

LeggedHouseObject would include tables, stools, cats, humans, even lamps... Though the Legged house object factory can't always be Ikea.

[@hbasm3271]

Thank you for the fresh air that helped me to think more clearly!

[@FadkinsDiet]

He cracked a smile at 11:27 "one of those sub objects". Still, i wish I could be as poker faced as him when I'm giving a ridiculous presentation praising management's latest insane mandate.

[@ske2004]

what i found throughout my experience is, if you are thinking of a good word to describe something, stop. you'll often end up having empty names that have "State", "Type", "Manager", "Operation", "Object", "Config", "Info", e.t.c. try to name whatever you're naming in the most concrete way possible, don't be afraid to expose it's implementation details.

[@JohnSmith-fz1ih]

I think it depends where you are using it. If you’re inside a function that implements the functionality then I agree concrete names are the way to go. But if you’re working at a higher level it’s usually best to avoid the concrete names that are tied to implementation details and instead using a higher-level concept name for what the thing is, not how it works. Which is just another way of saying “Names of classes (and variables of that class type) should be abstractions, private variables within that class should be concrete”.

[@ske2004]

@JohnSmith-fz1ih i mean for classes. the rationale is that more generic names eventually lead to pointless abstractions.

[@JohnSmith-fz1ih]

@@ske2004 I see. I wonder if that’s true. (Sincerely. I don’t know). Because another option is that the abstraction is a good one done at the right layer, but the name given to it is vague. Perhaps a better name exists, but the author didn’t think of it. But I tend to think you are correct, if the author can’t think of a good name, it may well be because the thing they are trying to abstract away is a vague concept.

[@MortenBendiksen]

Naming is not hard because English is bad for it. It's hard because naming things is hard. It's only because you have English to draw from, that you are even able to name anything at all.

[@SamualN]

are you saying that naming things is hard because naming things is hard?

[@lenickramone]

12:13 No man, just call it Scissor.... The problem there was not because Abstracting is Bad, it's due inserting complexity where it's not necessary. It looks like you're just pushing out some small pills of truth, but you're actually missing the context.

[@JohnSmith-fz1ih]

Yeah, that and some other points felt very contrived. Not just overlooking the most obvious name for one of the two blades, but the whole example. A pair of scissors is an atomic unit. Dealing with the individual components of a pair of scissors is something we practically never do. I can think of lots of things I might want to do with scissors in software (mostly related to inventory). But outside of a scissor manufacturing company, I can’t think of a single example of where code would care about individual parts that make up a pair of scissors. It’s a contrived example. I’ve worked with some programmers that did some very strange things, but I’ve never met anyone who would encounter the concept of scissors in software and think “I’d better make some sub-classes here for the individual blades”. It’s such a dumb example that the only lesson I came away with is “Doing incredibly dumb things for no reason whatsoever is dumb”. Some real-world examples showing the problem he’s seeing in practice and examples of how he would have reduced complexity would have helped a lot.

[@matterhart]

Looks like the algo is giving you another shot 4 years later. Good luck sir!

[@locobob]

I must be in the extreme minority here because I mostly disagree with your presentation. First of all, what human spoken language is actually better as a technical language? People love to hate on English but I’ve coded in “Spanish” and the same problems exist. Second, when you name functions and variables, the trouble arises because you’re trying to condense the meaning and functionality of several lines of code into 5 - 10 characters. Any spoken language will suffer at this because it’s unnatural. That’s what documentation and standards are for. Standards create that snap visual recognition while documentation provide context for those who will actually work with the code. It’s not supposed to be instantly recognizable by anyone in the world, even though that would be ideal. Now, there certainly are good and bad ways to name things and there should be thought out into the names, sure. But I don’t see “not naming things” as a good rule of thumb.

[@JohnSmith-fz1ih]

I’m glad to read this, because I felt exactly the same. He said part-way through (13:00) that “code is much easier to read and understand than a name is”. This is a fundamental issue I disagree with. I consider it such a bad take that I don’t even believe he thinks it’s true. Function calls are names, so someone that actually believed in this principle would do the “much easier” thing and avoid functions wherever possible and just have massive slabs of code. Apparently with no comments either, according to what he says here. I don’t for a second think he codes this way. It would be an absurd way to code, completely unmaintainable and the cognitive load to read through it would be huge.

[@JohnSmith-fz1ih]

Re using 5-10 chars to name a function - I agree that can’t work. But it’s a needless rule. I personally prefer long, descriptive names. Actually that’s not quite true; I prefer extremely accurate, concise, clear names that convey all meaning necessary, don’t suggest anything that’s not true etc etc. But like you said, that’s very hard. I out time into doing that for class names, common functions etc. But I will often extract a sub-block of code into its own function. The new function will only ever get called from this one place (I’m only extracting to reduce complexity in the original code block, and to get a name for the block in extracting out to make my code more readable). And for these, I don’t consider it worth coming up with the perfect, concise name so I go for something descriptive instead. Something like getCustomerIDsFromArray(). I usually dislike these names… they feel bad, I dislike the lack of brevity etc. But they’ve achieved their job of reducing complexity in the original code block and getting a name that even a non-coder could usually get the gist of what is going on. And if a non-coder can get the gist of it, then a programmer is likely to need very little cognitive load to read my code and understand what is going on.

[@armanmasangkay6513]

I'm curious, Which one is harder to read? 1. if status == 5: message.text("Some text") 2. MESSAGE_SENT = 5 if status == MESSAGE_SENT: message.text("Some text")

[@nicbarkeragain]

I see what you're implying, but this talk isn't about whether or not to use enums 😅 The main gist is to avoid creating new abstractions unless you have to. In the example you've given, the "status" int has already been created and exists whether or not you decide to give it a name via an enum. Anonymous functions / lambdas create the same kind of problem.

[@chudchadanstud]

1 is easier to read, 2 gives you context

[@asagiai4965]

Both are easier to read. The only problem here is the context. Like why status have a number? If you already have sent the message why does it have message.text again? Things like that

[@JohnSmith-fz1ih]

@@nicbarkeragainI feel like you dodged this question. Yes, the status of 5 already exists either way. The question isn’t about whether or not to use enums. The question being asked is whether or not naming it is valuable. I don’t think it’s a particularly good examples as I doubt you’d advocate for using magic numbers, but given the code as stated I think it’s very valuable to name the 5. And I’m not sure whether or not you agree as I felt examples would have helped me a lot in your presentation to understand what precisely you are proposing. So I’m interested in your answer to the question.

[@hitmusicworldwide]

I'm my programming journey I've often thought about how imprecise English, colloquial English can be. As opposed to Navajo where one word can be packed with precise descriptors that would require multiple words in English to render accurately, making declarations economical.

[@Sparagas]

Everyone knows that a half scissor is called a great knife

[@Spiritusp]

Great talk. One disagreement: Too long functions are hard to reason about. They don't fit in my brain L1 cache. It does make sense to find a sub-functionality and extract it out.

[@nicbarkeragain]

Thanks, and yes of course it's not an iron clad rule. After all, most functions that are huge end up being two or three separate tasks anyway. The two extremes are: "every function should be less than 10 lines" and "The whole codebase is 5 x 10,000 line functions". As with most things the sweet spot is somewhere in the middle 🙂

[@oscarfriberg7661]

@@Spiritusp I don’t think long functions are the problem. For example, if all lines in a function only depend on the line above, then the function is straightforward to read. It’s like reading an English text. But if all lines depend on each other in a tangled mess, then it’s going to be difficult to read. You have to constantly read back and forth to piece everything together. We want to minimize this back and forth reading.

[@milepanika9107]

That's some great advice! If you're writing software about commonalities between cats and chairs, or a warehouse for scissor parts. And always, always repeat yourself, because who doesn't enjoy fixing the same bug in 100 different places? And never, never split your functions, especially if they are 5 screens or longer, that really boosts your productivity and eases the cognitive load. And if you follow my advice, you'll most definitely want to run your code through an obfuscator before committing, that will recude the cognitive load so much, because hey, the compiler only cares that the symbols are the same. You gain so much productivity by not introducing new names and concepts, makes you wonder how these fake OOP guys have gotten away with it for the past 40-50 years?

[@JoelGarcia-ml9jx]

I feel like this is the gateway out of tutorial hell, this is the biggest issue I have had when starting my own projects. Thank you!

[@orbik_fin]

15:52 What do you mean? I absolutely write comments about what a function should do in the future.

[@f0kes32]

Good code is self explainatory. But it works in the opposite way too - with good enough documentation we don't actually need to know the implementation. As the saying goes "A problem well stated is half solved."

[@JohnSmith-fz1ih]

This gets at the heart of it to me. This is why naming things is important. If I move some code out into its own function then I get to name it. When I’m reading through the original function I now just see the name of the new function I made. If the change I need to make is unrelated to that function name I can mentally skip that line of code. The cost (in cognitive load) to know that I can skip that call to the function is very close to zero. Even for an imperfectly named function thematic cognitive load cost is low. Much, much lower than having to read through a block of inline code and potentially step through it in my head to understand what it is trying to achieve.

[@instance.select]

Hey, its the Clay guy! I like naming things. I started a project called clipdirstructer, or clipdirstructor. I made both. -or is build with clay, with buttons, and -er is a quick cli

[@redpepper74]

you’re sick 😭

[@instance.select]

@redpepper74 by made i mean worked on for like 2 hrs then got distracted cuz I got other projects going on q.q

[@redpepper74]

@@instance.select oh ok lol. The naming scheme is still unforgivable though

[@mehtubbhai9709]

Wish the google algorithm had found this channel sooner for me. @Nic Are you working on any other topics in the pipeline? You mentioned SIMD and parallelism in a previous video.

[@nicbarkeragain]

I have a video on allocators coming out in the next day or two, then over the next few weeks after christmas there will be a few more things like that 🙂 A proper video on parallelism is a little while off because it's a monster of a topic, and very hard to get the educational side of it right.

[@mehtubbhai9709]

@nicbarkeragain Thanks Nic. I really appreciate your videos👍

[@tmbarral664]

Slide 17 : YAGNI principle. in other words, dont make noise, it'll obfuscate the message.

[@platypusboi]

It's interesting that you said you use Rust mainly where I find it to be the language that is always allowing and encouraging more naming, more types. You can very easily get caught up in writing the best possible abstractions trying to leverage the type system. How do you avoid that?

[@nicbarkeragain]

Funnily enough, when I made this video quite some time ago, I was playing with Rust quite a lot, but now I write almost everything in C 🙂 But yes, I've seen exactly the same problem - people spending months building incredibly complex systems of type inference in typescript, that are very difficult for others to understand. All to avoid a small handful of very cheap runtime checks. As with all things it's about balance, but I really believe simplicity is a virtue.

[@jamesnewman9547]

Names are a reference that are enforced to be consistent throughout their usage. This is far different than comments. While I also think that names and abstractions should be used sparingly, much of this is just nonsense. What do you _mean_ model a pair of scissors in code? Since you're talking about half, and orientation - I assume you mean the 3D representation? So you think it would be better to code out the 3d model entirely than doing half and mirror? Copy paste all of that data and manually change it? Start to think about these examples in terms of something that might actually be done, and not some mental exercise, and everything changes. In reality, if we need to discuss a scissor (half) - then we need to create a word that we can all use to reference that. I guarantee you the people who work on scissor(s) talk about the halves - it's kinda important in their production. If we do _not_ need to, then avoid it.

[@boukew]

wow I never heard it articulated so well. I have always felt this name presence, which disconnects you from the underlying code and makes it harder to reason about the code. But if you keep reducing names, which fundamentally don't do anything, what would be the minimal form? As of now I managed to only use them for variables, function, files and directories. The codebase becomes tiny because of it. Awesome!

[@nicbarkeragain]

Yes, I totally agree. It's something I try to just always keep on my radar while I'm programming these days, and I think the software I write is better for it.

[@fennadikketetten1990]

Assembly

[@somerandomguy180]

Really great video, though it had me laughing about the scissors. It's like a pair of trousers, the singular object is trouser (or scissor).

[@platonvin1022]

Vulkan has perfect names. Change my mind

[@puncherinokripperino2500]

but underscore is basically a whitespace

[@bernhardkrickl5197]

An interesting perspective and lots of good advice although I don't agree with everything. The most fundamental thing is that human language is good at expressing concepts and intention and describing a field of business, a domain. By all means, use that power to describe what the code should do for the user. Find names that express this. In a way, variable names, method names, etc are comments. Certainly, for the compiler. But they are much closer to the technical thing than any comment will ever be. They stare you directly in the face. That is important. And you should absolutely not try to summarise the implementation of a method in its name. You should name the method from the view point of the user of the method to express *what* it does, not *how* it does it. (Importantly, the user of the method is a developer. Not the user of the software.) On the surface of the program, names should be chosen from the business domain. The deeper you go down the layers of the implementation, the more technical the names might get. But really, "domain" and "technicality" are not absolutes, they are relative terms. The terms that describe an array are part of the domain language of developers, while to end users of the software that is highly technical. For me as a Java developer, the implementation of arrays in the JVM is technical. The array is my business. So, you always have to think at which level you are to choose a proper name.

[@superoven]

I really disagree with this video. I honestly can't tell whether or not this is an elaborate joke. One can certainly go too far with abstractions and design things that aren't necessary but that's a very different problem than having "too many names".

[@JohnSmith-fz1ih]

Yeah. In response to “some people went too far with abstractions and other ways of trying to clearly explain what a block of code is trying to achieve”, this response appears to be to throw the baby out with the bath water. “Let’s not make any attempt to help the reader of the code understand intent. We’ll just dump all of the individual lines of code together, deliberately taking things that were abstracted away behind a call to a named function and removing that name and instead dumping the code with the rest. The reader can then just read the big blob of code and try to reverse engineer what the intent was”. Maybe if he gave examples of over-abstracted code and showed how he would inline and remove names then I might find I agree. But in the absence of that all we have is the advice to not bother trying to name things and remove things that are already named, and on the face of it that’s brain-dead.

[@PixelOutlaw]

I really hate the concept of DRY. Whomever coined that was not thinking about code properly. Instead of not repeating yourself try proactively spotting and naming common process well. You don't need "DRY" If you know when to name a process duplicated or not. The opposite is a tacit (fixed point) copy paste mess that is resistant to modification.

[@nicbarkeragain]

I agree, like everything it's a balance. Of course you should turn something into a function if it needs to be called in 10+ different places. But I've found that as programmers become more experienced, it's easy to fall into the trap of trying to avoid any and all duplication, which in my experience creates more problems than it solves 🙂

[@bobbycrosby9765]

You can only define a sensible abstraction given a problem you're solving. Trying to apply real life sensibilities to the software you're creating is a trap. Abstractly asking to model 'scissors' makes no sense - abstract them for what purpose?

[@ttt69420]

English is amazing at describing technicality and nuance. It's the best language in the world for that, by a large margin. I understand the point of your video, but the issue is the people speaking, not the language.

[@traal]

Cool ideas, but flawed presentation. At 8:50 you start to talk about solutions, but I didn’t see any solutions, and there were certainly no examples. Can you you see how ironic this is? You try to make the point that code is clearer than English, but you just spent 17 minutes talking vaguely in abstract English, with zero code… You should have shown some contrasting good/bad code samples to illustrate your points. You have PowerPoint - use it! 😊 The end result is, I kind of understand your problem statement in vague terms, but I have no idea what your idea of a solution would look like, or if you even have one. I still find the problems interesting though, so I did like the first half of your talk. 😊

[@JohnSmith-fz1ih]

Ha! Excellent observation. I’ve been critical of this video for the same reasons as you, but it hadn’t dawned on me the irony of him choosing English instead of code when he’s saying the latter is far easier to understand.

[@cloogshicer]

Another fantastic video. Fully agree with you!

[@asagiai4965]

I wonder what happen to 14 and 15. The thing is cat is not object. Wait why do we even call it a pair of scissor, when there is only one? It is just scissor. And the problem here is we don't have technical term for everything. #18 is weird and can be contradicting. So what happens when the names in the API changes? #19 listWordsWithNoSButPluralFormSIsAllowed. I think your video is ok for the most part, but still doesn't give a solution to the naming problem. The naming problem in programming is a long standing problem for a reason. It is not really solvable, naming things is not easy. The only thing we can do is lessen the problem.

[@chukwukamorka5055]

Nice video. I really learnt a lot!

[@JasonWelch]

I would also like to assert that using uncommon words should be avoided, even if they perfectly describe something. Unless you're inventing something new, which most of us aren't, you should be using words that most English speakers are going to be familiar with. Forcing someone to google a definition (and understand how it fits in the context) is counterproductive. This is especially important if you're working with non-native English speakers.

[@dimlylitcorners]

… Forth…name all the things :D

[@software_development_os]

Good video! Much more people should watch your videos, although I am biased, because I agree with almost everything in this video (only nuances on one or two things), But to adhere to the default KZbin comments, I should also point out a negative thing (:->). I missed the fact that people, and I estimate 80-90% of the software-developers (me included), are very very bad in naming things in their code! And that enforces your stance that more names almost by definition is worse than less names. I looked in very large code-bases and at some point names always tend to go to something like this ... : DoActionBandNotActionC , DoActionCbutNotActionB, DoNotActionBButActionA DoActionAAndNotActionB, etc.. (check the differences ...)

[@JohnSmith-fz1ih]

I actually think the premise that because naming things is hard, we should avoid using names is flawed. Is naming things and code good? Yes. A very clear, accurate name massively increases the ease of reading and understanding code. Be coming up with clear, concise, and accurate names is very difficult. The less clear, the less concise, and the less accurate a name is the less value it provides. The solution is to put thought into the language of the domain and to try our best to come up with a clear, concise, and accurate set of names. A name that does not even exist, provides zero assistance in understanding the code. So the idea that naming is hard, therefore we should avoid using names wherever possible is another way of saying that because we can’t be perfect, we should instead avoid being as good as possible, and instead provide zero assistance to the reader of the code. “Here’s all the raw code, you figure it out. Good luck with that, I’m not going to help you by letting you know what the intent of any given block of code is. You just have to read what the individual lines are and figure that out for yourself”. I see a massive downside in this approach, and almost no upside.

[@software_development_os]

@@JohnSmith-fz1ih But that is not the approach being suggested.

[@JohnSmith-fz1ih]

@software_development_os You summarized his stance as “more names is almost by definition worse than less names”. That is the view I am saying is flawed.

[@software_development_os]

@@JohnSmith-fz1ih OK, then at least I understand your interpretation, maybe I phrased it a bit weird, but it was not meant that way. The words "almost" and "less" are very important in the sentence such that it should not be taken as an absolute. Maybe it was better to also add "at some point" in that sentence, that would have made it less unclear.

[@lellyparker]

The two hardest things in software engineering are cash invalidation, naming things and off by one errors.

[@chudchadanstud]

2 blanks = 1 pair of scissors, A blank is made out of a blade, shank and bow. You can get tripple bladed scissors. The thing is most things do have a name. You just need some time to think, now we have AI.

[@Sean_neaS]

This is getting a algo push since it's 4 years and in my feed and lots of 1 day comments. If you redo it, I'd focus in inline vs breaking out long functions and provide some good real world code examples. The Object Oriented stuff and Polymorphism i agree with for the most part. I'd like to see more evidence that inliing is easier to read and maintain. I'm generally curious if that pans out. I know notebooks have shown some new promise in top down code without functions, but I go back and forth on the best way to maintain them over time.

[@turolretar]

I think I’ll keep doing what I already do, this really isn’t convincing

[@JohnSmith-fz1ih]

I found it hard judging whether I agreed with his points due to the really bad examples. Who looks at chairs and cats and says “Aha! These have something in common so it makes sense to group these together”? Is people doing this an actual problem that exists? Same with the scissors example - scissors are a unit. In almost all contexts it makes no sense to break them down into their individual components. What is a real-world example of someone taking something like a pair of scissors and, in code, breaking them down into their component pieces when the code itself doesn’t ever deal with those component pieces? I can’t think of any time I’ve seen that. I’m not saying there is no such example - I’m saying if he gave actual examples instead of analogies then I could judge. My suspicion is for any real-world example I’d say “That’s really, really dumb. I’ve never seen anyone do anything like that in practice. This guy isn’t solving a common problem, he’s pointing to something incredibly dumb done by someone who has absolutely no idea”. That doesn’t help me get onboard with his points. I already don’t do these incredibly dumb things, and no-one I’ve worked with ever has either. There is no learning I can do from that, there is nothing I need to change.

[@turolretar]

Scissors are at least 4 parts, the handles are separate and are not identical. Scissor blade and handle for left and right sides. Not complicated

[@dirkschiller9060]

❤

[@windowsxseven]

garbage

[@raccoons_stole_my_account]

houseobjectwith4legs aka manager aka abstract factory. 12:20 is very true and also the reason modern software is a sad joke. 16:58 and this is the core problem. I belive you are trying to, but I know for sure that most developers do not. It's an emotional problem that the industry is pretending does not exist. If all of us tried our best to keep code simple, software development would look very very different. Easiest explanation tends to be true - and easiest explanation is many devs are lying about making things as simple as possible. Because job security, also because ego. I don't know what the solution to this is tbh.

[@JohnSmith-fz1ih]

The problem isn’t that people don’t want to keep things simple. The problem is that we don’t agree on what simple is. Given there are lots of people on both sides of this debate, that tells me there is no one right answer. There are just differing opinions based on experience and context. And that makes complete sense. If your daily experience is working on a million line or more system with many, many moving parts, subsystems, lots of stakeholders, departments etc etc then the idea of inlining everything and removing the domain language you’ve carefully crafted and just avoiding using that language is a nightmare. So is the idea of not abstracting away behavior and intent, as the other developers that need to touch your code later need to be able to quickly understand what is going on and shouldn’t have to parse the code to figure that out. Function names are great for that. For someone working as a solo developer on a relatively small system, they are likely to have the opposite opinion. Jumping through layers to get to the actual code will just get on their way.

[@asagiai4965]

mapQuoteToBestSubQuote . It can be understood, but first, what do you mean by quote? Why does it have a map and a sub?

[@ske2004]

Map means transform, SubQuote is meant to be a single noun. The most confusing thing here is "Best", that can mean anything.

[@asagiai4965]

@skejeton true, I see. Ok, I guess my interpretation is wrong. I thought it transformed the quote to a single noun (best) Like the one word liner for a quote, something like that

[@JohnSmith-fz1ih]

I found it hard judging whether I agreed with his points due to the really bad examples. Who looks at chairs and cats and says “Aha! These have something in common so it makes sense to group these together”? Is people doing this an actual problem that exists? Same with the scissors example - scissors are a unit. In almost all contexts it makes no sense to break them down into their individual components. What is a real-world example of someone taking something like a pair of scissors and, in code, breaking them down into their component pieces when the code itself doesn’t ever deal with those component pieces? I can’t think of any time I’ve seen that. I’m not saying there is no such example - I’m saying if he gave actual examples instead of analogies then I could judge. My suspicion is for any real-world example I’d say “That’s really, really dumb. I’ve never seen anyone do anything like that in practice. This guy isn’t solving a common problem, he’s pointing to something incredibly dumb done by someone who has absolutely no idea”. That doesn’t help me get onboard with his points. I already don’t do these incredibly dumb things, and no-one I’ve worked with ever has either. There is no learning I can do from that, there is nothing I need to change.