Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Donkey code

einarwh.wordpress.com

Post reply on HN
Print view View original

31–40 of 64 posts

Re: Donkey code

#31

Post by Rayhem »

DeathArrow wrote: post #18

The problem is not with naming, the problem is with OOP, specifically inheritance and encapsulation. You could have separate entities for horses, donkeys, mules, zebras and functions that work on them. Maybe less code reuse but state is kept separately, code is very easy to understand, modify and implement. And also is faster to implement. If you have too many ifs in some functions you have to ask yourself if you arc…

I'm no fan of inheritance either, but I'm not sure it's that cut-and-dry. As a rust example, it's not uncommon to see

    struct Horse {...}

    enum Quadruped {
        Horse(Horse),
        ...
    };
possibly alongside a Horse or Horse-like trait (perhaps `HorseImpl`, in which case you'd see `impl HorseImpl for Horse` which, at best, parses...strangely to human beings. "The implementation of the HorseImpl(ementation) for Horses" -- what??). Then, to what `Horse` do you refer when you say the word without a ton of heavy formality?

Re: Donkey code

#32

Post by InitialLastName »

gnulinux wrote: post #14
kbenson wrote: post #11

Earlier quoted context omitted.

The next thing you know your using joe[1] to write joe[2] in joe[3]. At work we have an app called "directly", and an app called "indirectly". Ask me if I ever have to clarify by asking "you mean in an indirect way, in the app indirectly or in the app directly?" (the answer is ALL THE TIME) 1: the editor 2: a service you created 3: Joe-E the language

Just use less common names like Brice or Werner or Rubin?

My favorite thing is when names that I often have to communicate verbally for written use have ambiguous alternative spellings.

Re: Donkey code

#33

Post by d--b »

> The point of this example is that it takes very little for software development to get crippled by complexity without precise language

Ah I was wondering where this was headed. It’s a bit disappointing to be honest. Such a build up for such an obvious conclusion.

Otherwise it feels like the real world. Start with ifs and refactor when you have too many of them…

Re: Donkey code

#34

Post by FooBarBizBazz »

gnulinux wrote: post #8

This is why I'm a big fan of "name it Steve" philosophy. When we create a new service many people are inclined to call it something like "rhombus keyboard fibriculator" or "octatonic runner". Usually it's of the form "{verb}er" or "{noun} {verb}er" or "{adj} {noun} {verb}er" or whatever. It's never accurate, and it's super confusing because chances are there is some other "{x} {y} {verb}er" with the same "verb". Not…

Names like "Steve" and "Pluto" take too long to type. Since the meanings are arbitrary anyway, you should just use A, B, C, etc.

If you have a need for more than 26 names, you can start to also use letter pairs.

For increased efficiency, a nightly job can compute the use-count of each referenced object, and assign it a new name according to an alphabetic Huffman code. This will minimize the amount of typing that developers have to waste their time doing.

Many languages also do allow Unicode, including emojis, so this opens up additional options which may stand out better visually.

I'm joking obviously. I think you should make an effort to give descriptive names to things, and that, as code changes, you should judiciously refactor and rename. An important purpose of code is to be read and to be understood.

However, unnecessary and impenetrable jargon can be useful for protecting a niche in an organization, just as languages incomprehensible to outsiders (say, Gaelic) can be useful in nationalist projects. When the hammer of Management comes down to say Thou Shalt Write it in Java, it is like L'Academie Francaise stamping out some dialect in the Pyrenees, or extending its influence over Algeria. So that can be a reason for choosing special names known only within your team, or for writing it in Haskell or Rust.

Re: Donkey code

#35

Post by lizmat »

librasteve wrote: post #24

A beautifully written piece with lovely images. At some stage in my (ongoing) OO enlightenment, I got to appreciate that in a healthy OO codebase, there should be constant refactoring and code movement in order to adapt to small and large changes (and that there is a lot of judgement in when to opt for a big change when requirements are only incrementally arriving.) While I agree with much of the sentiment about clea…

Please note that in Raku, you can also use a role as a class without having to create a class, through a process called auto-punning.

https://docs.raku.org/language/typesystem#Auto-punning

Re: Donkey code

#36

Post by aldanor »

xanderlewis wrote: post #27
gnulinux wrote: post #8

This is why I'm a big fan of "name it Steve" philosophy. When we create a new service many people are inclined to call it something like "rhombus keyboard fibriculator" or "octatonic runner". Usually it's of the form "{verb}er" or "{noun} {verb}er" or "{adj} {noun} {verb}er" or whatever. It's never accurate, and it's super confusing because chances are there is some other "{x} {y} {verb}er" with the same "verb". Not…

You think ‘Galois field’ is better than ‘finite field’?

Both are arguably better than 'potato field'

Re: Donkey code

#38

Post by RHSeeger »

DeathArrow wrote: post #18

The problem is not with naming, the problem is with OOP, specifically inheritance and encapsulation. You could have separate entities for horses, donkeys, mules, zebras and functions that work on them. Maybe less code reuse but state is kept separately, code is very easy to understand, modify and implement. And also is faster to implement. If you have too many ifs in some functions you have to ask yourself if you arc…

The problem is definitely with naming. Regardless of whether you have

    function neigh() { ... }
or

    class horse {
        method neigh() { ... }
You still wind up with "add functionality for this _slightly different case_" and the code gets modified in exactly the same way. It's not until you clear up that you're dealing with different things, with different names, that you can start to make the code clearer. Because you need to be able to talk about the things in the code.

Re: Donkey code

#39

Post by robbles »

gnulinux wrote: post #8

This is why I'm a big fan of "name it Steve" philosophy. When we create a new service many people are inclined to call it something like "rhombus keyboard fibriculator" or "octatonic runner". Usually it's of the form "{verb}er" or "{noun} {verb}er" or "{adj} {noun} {verb}er" or whatever. It's never accurate, and it's super confusing because chances are there is some other "{x} {y} {verb}er" with the same "verb". Not…

I once inherited a codebase that did this, and it was a nightmare to learn. All the classes were named after types of alcohol for some reason. Naming things clearly is really hard, but this approach is just giving up completely.
Post reply on HN