Live data from Hacker News

Want cleaner code? Use the rule of six

davidamos.dev

191–200 of 352 posts

Re: Want cleaner code? Use the rule of six

#191

I don't necessarily agree with the step of putting the code in a separate function; that often works, but just as often makes it so that the code can't be read top-to-bottom anymore which hurts readability. In this case there's, I think, a better alternative; the equivalent-ish code in Ruby for the example code here would be something like this: values = s .partition('?')[-1] .split('&') .map { |key_value| key_value.…

Ruby maps are so ugly.

  .map { |key_value|
  key_value.partition('=')[-1] }
Reading this literally makes me sick to my stomach. Language design is much more important than language popularity, although it will be popularity that wins. (Yay downvotes for pointing out things everyone can see - highschool dynamics)

Re: Want cleaner code? Use the rule of six

#192

Earlier quoted context omitted.

'However, to even begin to understand it you have to read an article from the original writer' - or just know APL? If you know APL, it's clear.

While I'm not going to go collect a bunch of APL programmers to confirm this (where would one even find them?), I highly doubt that claim. Knowing a language doesn't mean dense code is suddenly obvious. This is a silly example, but years ago I wanted to prove that you could write a non-trivial program in python using a single expression (because python's lambda only allows you to use expressions, not statements). And…

That example isn't like APL though because of it's verbosity. Also APL has more universal abstractions to express a lot of this kind of logic.

That lack of verbosity makes it easier to pick out the intention revealing code, which isn't the case here.

Re: Want cleaner code? Use the rule of six

#193
A map lambda example is what I had in mind when reading the article. I'm not a big fan of the temporary variables, though.

Admittedly the example below is not a perfect solution, but that's where I thought the article was heading when splitting that code over multiple lines for readability.

  map(
      lambda x: x.split('=')[1],
      (url
          .split('?')[1]
          .split('&')[-3:]
      )
  )
Is this still too unreadable or more messy?

Re: Want cleaner code? Use the rule of six

#194
post #31

Give mysterious things room. In this case the most mysterious is [-3:]. That, together with the split, should have it's own line or maybe even multiple (function declaration, comment).

> [-3:].

That kind of index notation really isn't mysterious if you write a lot of python in my experience.

Re: Want cleaner code? Use the rule of six

#195
post #191

I don't necessarily agree with the step of putting the code in a separate function; that often works, but just as often makes it so that the code can't be read top-to-bottom anymore which hurts readability. In this case there's, I think, a better alternative; the equivalent-ish code in Ruby for the example code here would be something like this: values = s .partition('?')[-1] .split('&') .map { |key_value| key_value.…

Ruby maps are so ugly. .map { |key_value| key_value.partition('=')[-1] } Reading this literally makes me sick to my stomach. Language design is much more important than language popularity, although it will be popularity that wins. (Yay downvotes for pointing out things everyone can see - highschool dynamics)

Just because it’s a different syntax than you’re used to reading in another language doesn’t make it ugly. If you’re used to reading it and work in the language regularly, it actually looks quite clean.

This sounds like a Windows user who can’t stand macOS because they don’t know where anything is.

Your post downvote edit assumes your opinion here is objective. It isn’t.

Re: Want cleaner code? Use the rule of six

#196

Earlier quoted context omitted.

> I think the comparative rarity of APL compared to every other programming language in existence says a lot That's just the whole "popularity means it must be good" argument, which I disagree with.

I'm not saying popularity = good, what I'm saying is that most people aren't smart or patient enough to use something like APL. Most people have a limit to the amount of density they're willing to deal with.

> Most people have a limit to the amount of density they're willing to deal with.

Why? I believe if you started teaching someone APL who'd never programmed before you'd never hear "this code is too dense!".

Re: Want cleaner code? Use the rule of six

#197
post #75

I enjoyed the article and agreed that working memory places a fundamental limit on the intelligibility of otherwise equivalent pieces of code. As a former psychologist with experience of memory research (though not quite this area), it might be useful to others if I add that: - The size of the short-term store is normally said to be 7 plus or minus 2 (the 'magic' number 7) - The Working Memory model has somewhat over…

Not high priority, but I'd love any references or names / key words I could look into it with. I'm traditional wide comp sci by academic training, but spend my day job as a low-code enabler for non-programmers with varied backgrounds. The working memory model explains and fits well with what I see them get and struggle with in day to day work, and I'd welcome references I could use to optimize my approach.

Check out Anders Ericsson’s book on Deliberate Practice or Barbara Oakley’s A Mind for Numbers.

Re: Want cleaner code? Use the rule of six

#198

Earlier quoted context omitted.

Here's conway's game of life in APL: life ← {⊃1 ⍵ ∨.∧ 3 4 = +/ +⌿ ¯1 0 1 ∘.⊖ ¯1 0 1 ⌽¨ ⊂⍵} Is that shorter than essentially every other language implementation. Yep! However, to even begin to understand it you have to read an article from the original writer: https://aplwiki.com/wiki/John_Scholes%27_Conway%27s_Game_of_... To me, that is objectively , not subjectively, less clear than the longer implementations.

Can you objectively say that familiarity isn't the primary reason APL is less understandable? Put another way, if you had 2 years of APL experience and 2 years of Python experience, would you maintain that the APL code is objectively less clear? Is it really fair to judge languages we aren't familiar with to the extent of the language we are comparing to?

Well, it'd be fairly easy to test: teach a first year coding course, give one group python and the other group APL, and monitor the grades and the drop rate.

I can't prove it, but I'm highly confident that python would win. Because it has a lot of analogies to things people already know:

- In simple cases, you can read it as a set of commands, like a recipe. People are familiar with recipes

- Syntax mostly uses well know words (or abbreviations of well known words), or very simple symbols that you'd pick up in basic math (+,-, *, comma, etc.)

- Variable names make clear what the result of a particular expression maps back to in the real world (ideally)

- The whitespace indented structure of the code is fairly obvious if you've ever written an outline

APL has...

- Unfamiliar symbols

- Terse, confusing names

I mean, look at this example for getting the average from a list of numbers:

    {(+⌿⍵)÷≢⍵}
Since I don't know greek or math particularly well, in my head I read that as "plus minus sign with a slash through it and curly w divided by triple equals curly w with a slash through it". I'm nowhere.

Here's the python code:

    def average(numbers): return sum(numbers) / len(numbers)
I couldn't write that if I didn't know python, but if I had never written a line of code in my life I could give you a decent guess as to what it does. Is it verbose? I guess in character count, but not in any meaningful sense.

You're right, familiarity IS why python is easier to understand. But it's not programming familiarity, it's that almost every aspect of it is more familiar. The only people that (might) find APL more familiar are mathematicians in my opinion, and they could easily understand python.

Re: Want cleaner code? Use the rule of six

#199
post #94

Earlier quoted context omitted.

short names You don't really need short names. I wouldn't advocate going full Java naming but trying to compress names just to save a bit of typing is unnecessary. Your IDE will help you out. Just learn to press tab when you've entered enough of the name instead of typing the whole thing.

Short names are easier to read, because they fit on fewer lines. Doubly so if the statement fits on one line.

Shorter names aren't easier to read if you have several similar names used in close proximity. More characters can reduce the congruence and make it easier to differtiate between names.

I agree about fitting things onto one line though. It's usually better to break things up into to several short one line steps rather than have a long multi line statement.

Re: Want cleaner code? Use the rule of six

#200
The main reason I stopped using the old school for loop in JavaScript is that it's doing too much in a single line. If I can't do for-of, I much prefer a while loop because it does effectively the same job as for-in but each step gets its own line. I find it easier to follow at a glance.
Post reply on HN