hotBacteria's comments

I don't have much hope regarding this issue.

Researchers work a lot on their own time, so the millions mentionned in the article don't directly impact the institutions employing them. They are alone in this fight.

The petition (https://www.change.org/p/simplify-manuscript-submissions-in-...) linked in the article barely received 100 signatures in a month.

What is demonstrated here is that if you understand well the different parts of some code, you can recombine them in more efficient ways.

This is something very good to have in mind, but it must be applied strategically. Avoiding "clean code" everywhere won't always provide huge performances win and will surely hurt maintainability.

This twitter thread from the author provides insight about how it was made: https://twitter.com/LodsDorian/status/1349291334759288832

I like the shapes problem because I actually encountered it and it made me think.

I'm not sure about the switch approach described in the post:

  function area(shape)
    switch shape.type
      case "square": return shape.side ** 2
      case "circle": return 2 * PI * shape.radius
      case "triangle": return ... 
      case "segment": return 0
      case "polygon": return ...
      ...
      case "oval": return ...

You can have a lot of cases, some of them requiring non trivial code... Eventually you write a function for each case and it's more work than adding a method for each shape because you still need to write the switch...

Classes seem work better than structures here.

But then you want to handle intersections

The switch approach doesn't seem realistic:

  function intersection(shapeA, shapeB)
    if(shapeA.type == "circle" AND shapeB.type == "circle")...
    if(shapeA.type == "circle" AND shapeB.type == "square")...
    if(shapeA.type == "square" AND shapeB.type == "circle")...
    ...//uh oh you have nShapes**2 cases to handle

But java classes or not better: where do you define Circle-Square intersection? In Circle? In Square?

Even with multiple dispatch the solution is not ideal. You now have some things related to Circle (area, perimeter...) in the Circle.blub file, and intersection(Circle, Circle) wich only works with Circles is now in intersections.blub...

I don't see a good solution and sometimes I feel like the problem is more with our tools (code in text files) rather than programming paradigms

Two points not mentionned:

1- The question of access: A theorical exhaustive map of the brain would be easier to access than an actual brain.

2- Tools: A map is not a piece of paper anymore. A 1:1 map of Earth doesn't seem absurd, as long as we can navigate it with levels of details

You can write it without resorting to one-line conditionals:

  if(cond1){
   myVar = 1;
  }
  else if(cond2 && cond3){
   myVar = 10;
  }
  else if(cond2 && !cond3){
   myVar = 100;
  }
  else {
   myVar = 4;
  }

But when I encounter this kind of situations I have other problems than code formatting anyway:

with 3 conditions you have 2^3 possibilities to check: are you really really sure (!cond1 && !cond2 && cond3) should give you defaultValue ? Do you really want 1 even if !cond2 ? etc...

When possible these conditions should be avoided in the first place (depending on context of course)

Just to add a bit of context, this article was written more than six years ago: http://thecleancoder.blogspot.fr/2010/08/why-clojure.html

I found this document : https://github.com/kriskowal/q/tree/v1/design very helpful to understand how promises work behind the scene Also liked being able to access the author's reasoning and the motivations behind his design decisions

Don't be stupid, be slow [1]

We take shortcuts when we feel the proper solution takes too long to implement If you purposely take a shortcut, write why you take it, how you take it and how to turn back in case of troubles.

Slowing down also allows you to share your problem with your team, your friends or your rubber duck Again, don't forget to write somewhere what your rubber duck told you, don't waste his time asking him the same questions over and over again.

[1] https://ventrellathing.wordpress.com/2013/06/18/the-case-for...

The story ends well because the project was actually simpler than what it looked at first. Unfortunately, more than often, things happen to be a lot harder than expected

What happens when, after 2 months of scribbling and playing space invaders, Charles realizes the project actually requires 3500 lines of code? He wants the project to succeed but now he doesn't have enough time, and he fears to ask for help because he knows he is labeled as a lazy and arrogant guy.

So he works long hours to fix the situation, then he burns out.

Source? This is somehow happened to me. Several times.

This story can be true, people like Charles and simple projects exist, but these are exceptions, not the rule. It's easy for a beginner to believe he is that guy and then experience a death march [1] Things can go wrong for Alan, but he has a team to support him and his managers know he is working at something complicated.

I'd like to be Charles one day, but for now I'm Alan.

[1] https://en.wikipedia.org/wiki/Death_march_(project_managemen...