News for hackers. Stuff that matters.
Re:On anthropomorphism in science (1985) by chickenfries on Tuesday May 30, 2017 @09:26PM (#14449872)
I think your language metaphor works here, but I won't try to extend it for fear of misleading you with anthropomorphism :)

Anthropomorphized code reads like someone reading off a gigantic checklist that keeps getting longer and longer. Each time a new problem comes up, we solve it by adding another "If A then B" except it's something like this

    if foo.bar.baz[0][1]['value']
      if (foo.bar.baz[0][1]['value'] == 'undocumented business rule')
        globalVariable = false # why? who knows
      else
        globalVariable = true

      globalVaraiable = foo.bar.baz[0][1]['value']
Relying on “If A then B” quickly get out of hand. The number of possible paths that your code can take grows quickly, even exponentially depending on the structure of your program. I don't want to be dogmatic, but always be asking yourself if you can structure your code as to avoid relying heavily on conditionals, especially nested ones.

Focus on the problem you're trying to solve, not the operational details of the language or other tools you're using. However, keep exposing yourself to more languages, that are different from each other in semantics, run-times. Learn about different programming paradigms: declarative, imperative, functional, etc, focusing on semantics and not syntax.

Re:On anthropomorphism in science (1985) by Houshalter on Tuesday May 30, 2017 @09:50PM (#14449949)
Re:On anthropomorphism in science (1985) by Jtsummers on Tuesday May 30, 2017 @10:23PM (#14450055)
Dear god, I think this would be what would drive coders mad if some Lovecraftian old one were a coder. I have a colleague that writes code like that last one. I know he won't change, but I wish he'd at least use a damned switch statement.
Re:On anthropomorphism in science (1985) by adrianratnapala on Wednesday May 31, 2017 @06:58PM (#14456596)
Actually the first example looks perfectly reasonable to me. I would have used changes of "if () return" instead of a huge OR, but the result would have been the same.

The second example I can't judge. Probalby the variable name is bad, but not extraordinarily so. It's a lookup table, I can't tell if it is a good or bad idea without know what is being looked up.

Re:On anthropomorphism in science (1985) by Houshalter on Wednesday May 31, 2017 @08:20PM (#14456964)
Would could possibly be the advantage of hard coding divisibility checks against every prime number? There's so many problems with this. The simplest thing would be to just make an array of primes and iterate through it. There's also faster algorithms to check for primality.
Re:On anthropomorphism in science (1985) by adrianratnapala on Tuesday June 06, 2017 @09:03PM (#14502935)
That code is making an array of primes and iterating through it. It's just that the array is stored in instruction memory, and there is no explicit fiddling with indices or pointers.

As for more advanced primality testing methods, I guess it depends on where the the fancier algorithms begin to pay off. It would not surprise me if this simple algorithm was the fastest for any input small enough to be stored in a single machine word.

Re:On anthropomorphism in science (1985) by chickenfries on Wednesday May 31, 2017 @07:57PM (#14456858)
I think in the second one, a simple list of values that correspond to true would be more reasonable than putting this in your source code, if you just need a look up table. The way the comments are structured though, I wonder if each row an option map, (annotated by the comments along the top)
Re:On anthropomorphism in science (1985) by Houshalter on Wednesday May 31, 2017 @08:15PM (#14456941)
The second example was a 15 line switch statement that they replaced with a lookup because they thought it would be faster.
Re:On anthropomorphism in science (1985) by chickenfries on Wednesday May 31, 2017 @10:51AM (#14452953)
These are great, I need to start a collection like this.

Here's something from this codebase, with names and variables altered but for the most part left alone. Note the hardcoded `ajax_max` variable.

https://gist.github.com/anonymous/2d06bd45222999647d99df54fb...