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.

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.

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.

Interesting. I thought the Ruby community generally prefers shorter code, e.g. `to_s` instead of `to_string`, and yet that type signature is very verbose: `sig {params(x: Integer).returns(String)}`

You are right, but I don't think companies care about accessibility. Facebook using the divs is already breaking screen reader.

I read it somewhere that Chinese websites are taking this kind of obfuscations to the next level. The simple ones are randomly ordered divs re-layouted by JS at runtime. The complicated ones include custom font files which characters and glyph don't match, so for example <div style="font-family:custom-font">abc</div> would look like "123".

It's especially bad on mobile. On my iPhone SE, the top is a banner promoting their native app, then a top navigation bar and their logo. The bottom is an ad for the paid membership, a dialog for Do Not Track info. The tiny space that's visible behind all these craps is.... the irrelevant hero image. I can't even read the title!

The article and all the comments seem to assume work and creative projects are mutual exclusive, that we have to find a balance. I am wondering if it is possible to have a job that allows people to be creative? Like, as happy as doing side project? If no, what kind of experience did you have that suggest it is not possible?

There is an opensource OS for Pebble as well! https://github.com/ginge/FreeRTOS-Pebble

I think culture helps to keep the house price low as well.

1. They don't like secondhand homes, they rather rebuild it[1]. So houses are not a good investment vehicles.

2. They values good business practices in housing. (I don't have any data to support). Few months ago I was finding a room in Tokyo, the agent told me people usually live in the same place for years without rent increased. It's not usual to raise the price because it's considered rude and it's something the yakuzas do. It's an entirely different story in Hong Kong where I came from. HK people almost always increase the price so much that people are forced to move every 2 years. AFAIK there is no rent control in both HK and Tokyo.

[1]: "the ratio of used homes circulating in the entire housing market remains below 15 percent, substantially smaller than in the United States and European countries." https://www.japantimes.co.jp/news/2017/12/26/national/japans...

I see it the other way round. The people and community who chose electron at this point probably don't care about performance as much as we do. Improving performance would probably make us (people who care about performance, capable of writing lower level code) happy, but that's not their target user. Their community are people who write web apps, who don't want to learn native but want to make something.

I think it absolutely makes sense in business, making low quality product is fine especially when users are nontechnical, they just don't know which app is slow. Though as a developer, I cannot be proud of myself for making low quality electron apps, there is no craftsmanship to be proud of.

Moreover, if the argument of "it is slower but it costs less to make so it's ok" makes sense, then will people start mining bitcoin with client's computation power because it's "cheaper"?

I am having issue with my google drive as well, they calculated the wrong storage usage and I simply cannot upload more files. I spent weeks to convince the support it is their bug that clearing cache is not solving the problem. They said they're going to follow up but nothing happened. I then just cancelled the plan, now gmail is complaining not enough space and will stop receiving email. I told the support my situation, and they gave me extra storage for a month while they're dealing with the problem. Though the problem is never resolved, and I now have to send an email to extend that extra storage every month.

Seems like a proper way to get support from big companies in 2017 is to post on hackernews.

If I have to choose a language for programming, I would suggest Esperanto. An artificial language that is easy to learn, and more consistent than English.

I wonder how does it compare with Purescript + Pux. My experience with Pux has been pretty good. As a beginner, I find it more comfortable when the FFI is thin, the compiled JS is kind of readable, so in case if I am stuck, I can still go back to my familiar Javascript.

It reminds me of Funciton, https://esolangs.org/wiki/Funciton

I've worked with companies making apps with electron/nw.js, what strike me most was not the performance or the product itself, but the reason they decided to use electron. The argument is always about development efficiency, while ignoring the user experience sacrificed. I find it lack of craftsmanship, just kind of sad.

Though, it is true that nontechnical users are unlikely to realise the difference, they probably don't know an app with not many functionality costs hundred megabytes. Maybe I am just getting old and grumpy, maybe that's how assembly programmers see C programmers.

I do. But it doesn't happen very often, and I don't hate it.

The clearest memory I have, is when I was 15, debugging some hacky PHP codes for days still unable to find a solution. I dreamed that piece of code and suddenly wake up with a fix, it was a pretty nice feeling.

Also an year ago I started learning Haskell, despite reading a lot of tutorials I wasn't able to understand what a monad is. One day I woke up and find myself understood the concept. I don't remember the content of the dream, but it was a sweet dream and I slept longer than usual.

I am not sure if I have OCD, but I like coding so dreaming code is not an issue for me.