b123400

Not exactly Clojure-related, but I wonder how acceptable is it for a programmer to suggest a technical decision by one’s own passion over company’s interest.

> The business case for Go is very strong now. Sh*t.

It sounded like a negative news for Suzi as she wanted to promote Clojure, but it’s positive for the company, as Go is a more suitable choice in this case. If a programmer is asked to make a technical decision, comes up if a solution based mostly on passion, isn’t it misleading? I’ve seen a Haskeller claiming “this thing can be better expressed in a custom DSL” and started to write a parser, which in retrospect absolutely unnecessary, the passion was so strong that decisions got irrational. Shouldn’t a programmer be honest and say “this is not the best tool, but it’s my favorite, using it makes me happy”?

I have to echo your point on inconsistency.

Our company uses Haskell and the Haskell team love to define their own solutions which make things even more inconstant. For error handling they end up using an extensible type-level-list containing possible error types, embedded in an extensible effect monad. We also have list, array, vector, and our own collection types in the same place.

It feels like everyone want to make things better by using/making something new, instead of making them consistent.

I got into my school's network when I was 10, people were furious for my hacking, nobody questioned why was there a security issue so obvious that even a 10-years-old could break in. Few years later I accidentally found another way to get in. I sent an email to the school's IT department, got ignored. I sent it to the headmaster, he said "Thanks, will fix it". Except it was never fixed.

Maybe fixing the child is easier than fixing the software.

I see a lot of people making the argument of “a bigger car is safer when crashing with other cars”, but that’s not very sustainable when everybody thinks the same. A US truck is small when everyone is driving a monster truck to protect themselves from “normal” trucks

As far as I know, there isn't a limit of power / speed for kei car category. In the old days Suzuki made a kei car that was "too powerful", the government "communicated" with them, and they settled with 64hps. Since then all the manufactures self-imposed the 64hps limit, but it's still legal for someone to power up their own car.

Smart K is another non-Japanese kei car that's more powerful.

I live in Tokyo and drive an old kei car. Despite being not very powerful, it does provide me whatever I need. Driving it on highway (about 100km/h) feels alright, of course it’s not as quiet or comfortable as bigger cars, but not unacceptable. I am sure newer models are much improved. Many car parks here have height/size limit, or even kei-car-only space, and it’s just easier to park even for regular places. I find myself feeling more responsible by driving a small car, when I stop at the side of a road, it occupies at most half of the lane, so another kei car can bypass easily. Maybe it’s a Japanese thing, but unlike SUV’s “getting higher up to see more”, I am more like “I am as small as everyone else so I don’t block people’s view”.

I bought a pro mouse 2 years ago and used it until few months ago. The biggest reason for giving up this nice looking thing is that, people no longer create UI that are one-button-friendly, especially when it comes to scrolling.

If this turns out to be an effective lesson on security, systems should implement their own meow to protect their users.

E.g. A database That intentionally removes itself if the default password/an insecure password is used, with an easy-to-follow guide in error log on how to properly configure it.

While I agree that many things can be simplified into functions, I would like to point out functional languages don't necessary means you are going to have cleaner code automatically.

I write Haskell for a company that it seems people here like to experiment with extensible-effects-interpreters-whatever pattern, that we end up with some 81 "effects-model-repository-handlers-command-query" packages in a project, the FactoryCommandQueryEffectContextGeneratorRepositoryHandlers type is not limited to Java.

The main reason behind this kind of code seems to be "what if you need <insert a property here>?". As other comments pointed out, using a class over function can help caching the result, save / restore the state, share the state and so on, but do we need these properties? The author is talking about a homework, it's not a piece of code that you run on some very important production servers, there's no need to cache / save / restore or whatever. What if you need it in the future? Update the code.

I somehow start to think maybe this kind of mindset is inevitable in a project's lifetime, until people are confident enough to say "If we need this need code to be cachable / restorable / whatever, give me time, and I can update the code."

Few years ago I spent quite some time learning Haskell, failing to understand the concept of Monad. One day I just woke up, with the concept understood. It was like magic.

Me too! Especially when we know most services will eventually die, no matter it's Google+ or any trendy startup that will be acquired at some point.

Years ago a company similarly contacted me for some "emergency" tasks. I flied all the way to Japan and realise they haven't got the tasks ready, more than half of the time I wasn't doing anything. I honestly (stupidly?) charged them with my actual working hours, they seems surprised. A lesson learnt and the next time it'll be a different story.