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”?
Maybe this technical choice makes that person happy, but what if it makes ten other developers on the team unhappy, or unable to do their work because they don't know this new technology?
What if that technical choice makes the whole code base unmaintainable in the following months because it gets abandoned, or is just so niche that it's impossible to hire developers familiar with it?
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.
In low crime areas, people don't lock the doors. It is obvious security fault, but in fact, the people walking in and messing with their stuff are in the wrong.
Of course they were furious at your hacking. And of course you should have not done that regardless of what fault the system had. (They would be in the wrong of they tried to impose serious consequences on 10 years old, which I hope did not happened.)
Even in low-crime areas, banks still lock their vaults, military facilities still have fences and guards, etc. Not locking your own door that only has your own stuff behind it is in no way comparable to leaving a system with thousands or millions of users' (students/customers/citizens/whoever) data and property wide open.
"Hacking" isn't the same as "breaking in". Breaking into somewhere is usually destructive, dangerous, can be done b anyone and reveals no poor security (how did they forget to protect their vault door from a drill and plastic explosives??). A DDoS attack falls into this same category - a boring zero-skill brute force attack that can only be interpreted as malicious.
"Real hacking", however, isn't any of those things. If I put on an orange jumper and walk right into the back of my local bank and straight down to the vault without so much as a confused glance from a guard, they will, as they should, be more concerned with firing their guards for dangerous incompetence than prosecuting me for walking past an "employees only" sign. Especially if I, after arriving at the vault, called the bank manager and explained how bad their security is.
The op was not prosecuted. What happened was that adults were angry at 10 years old him. And he finds it unfair that they were angry at him. If 10 years old walks into vault with pretend confused look, it is perfectly ok to be angry at the kid and act like kid done something kid was not supposed to do.
No part of the internet can be considered “low crime” least of all a school system.
If you have an isolated network that is truly airgapped from any other network then and only then is it remotely acceptable to “leave your doors unlocked”. This doesn’t absolve the criminals who deface/destroy/steal your PII/data but rather you’ve got to adapt to the times.
The point is, the person who went through those front doors really don't get to blame owners for not locking the doors. Sometimes the line is fuzzy, yes.
But in situation described above, it sounds like it was not fuzzy at all.
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”.
Kei cars would be great in America and I would fully accept laws supporting them as an effort to reduce dependence on big consumptive engines in our transition to electric mobility.
Kei cars don't have the crash safety required for US roads, speeds and the traffic they need to share the roads with. A crash between a Kei and a US truck at 55 mph would be a bloodbath.
Keis work in Japan because the average speed is much lower and you're more likely to get into an accident with another kei.
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
Better mileage than a Prius without even being a hybrid seems like exactly the sort of reason why someone would want one. And with EVs coming, kei cars/trucks seem like perfect candidates for EV conversions.
Re: crash safety, I wonder if it's possible to retrofit some extra safety measures on these things?
>Re: crash safety, I wonder if it's possible to retrofit some extra safety measures on these things?
That's a good question for any older car. I can think of a number of measures, but it would be interesting to see some real engineering go into retrofits. Besides new/proper seat belts an interesting angle would be a partial roll cage that is safe for a helmetless driver.
I'd love to a have a Kei truck purely for around town (we don't have any traffic lights to give you an idea) in snowy weather. Small = good when the streets shrink due to plowing, small = good for dragging out of a ditch, cheap = good just because it's easy to hurt a car in serious snow.
> Re: crash safety, I wonder if it's possible to retrofit some extra safety measures on these things?
Mass and/or crumple zones help absorb and deflect energy in crashes. There's no room for a crumple zone in a kei car's perimeter. Smart Fourtwo got close, but those are as wide as a normal car.
And perfectly rigid vehicle is dangerous because it transmits the collision forces to the passengers - high G deceleration will destroy your organs
Best selling kei cars are like Honda N-BOX and Suzuki Spacia, both are called "super height wagon", near 1800mm height (higher than RAV4) and eyepoint is also higher than sedans. So it blocks some people's view, but not annoying thanks to very narrow 1475mm width.
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.
You are allowed to judge people for taking far, far too long to do the right thing.
It indicates a pattern of poor judgement, which speaks to trust. You know they are going to let you down each time a new issue comes up.
Faulting people for being cautious around such bad actors (which I'm not saying you're doing, but the response will) speaks to your judgement, not the vendor's.
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.
Wonderful idea! My friends drew some brilliant illustrations on my Macbook Pros ( https://i.imgur.com/O4mGZqZ.jpg ) using marker, directly on the case. Not soon afterward, the anti-reflective coating went bad and I tried to took it to Apple Store and was predictably told it's not possible to repair the screen without swapping out the entire screen. So 4 years later I am still using a never paired machine. I wish I knew about this kind of wrapping earlier.
> 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”?