kmicklas

Nowadays it's really easy enough to use real Haskell in the browser with GHCJS, and FRP libraries like Reflex provide a much more complete experience than Elm's restricted form.

They give you all that stuff to some degree to cover over how toxic the culture and job is otherwise. Leaving Google was the best decision I ever made despite the fact that I now get none of those things and make significantly less money.

I left Google for very many of the reasons mentioned in the article and I'm a white male. So I can only imagine how hard it must be for minorities.

Thankfully I had the opportunity to make this change early in my career, although my financial situation is suffering dearly for it. And it's hard to swallow when everyone you know is making 2x your salary and just about all of them have a bunch of family money as well. (I grew up thinking I was upper middle class and somehow was the poorest person in pretty much all my social circles when I was at Google. The tech bubble is real.)

Keeping perspective and realizing that even if you leave toxic tech and take a pay cut you'll probably still be in the upper echelons of the world inequality distribution is hard but super important. And you'll realize that rich people are on average way shittier and probably not worth hanging out with anyway.

Why is it on AMD to support TensorFlow? Pretty sure it is on the machine learning people to use the standard APIs like OpenCL or Vulkan etc instead of CUDA...

I don't fundamentally disagree with the article but this is ridiculous:

> People sometimes ask me, “What is the most important concept in political economy?” The answer is easy, but subtle: permissionless innovation, a strong presumption in favor of allowing experimentation with new technologies and with new business platforms that use those technologies.

Surely the ideas of capital, labor, markets, property, etc. are more important concepts in political economy?

CS education will have to improve dramatically both in reach and quality for that to be possible. Doesn't seem likely for many decades.

This is really well written and seems to agree with the traditional FP lore. I'm curious what led Alan Kay then to OOP in Smalltalk.

Rich people have done an absolutely astounding job of convincing poor conservatives that this nonsense makes sense.

Study Suggests Malnutrition Can Be Fixed With Food, Not Crop Hoarding

This is an interesting line of thought. The spread of capitalism was fueled by the new technology of the Industrial Revolution. Perhaps the next mode of production will be fueled by this 'Internet/Computer/Robot/AI Revolution'. Maybe the important change is this "trivially scalable output irrespective of capital" property, but no one really seems to know what this will lead to.

Private property and personal property are not the same thing.

You don't think good old fashioned bugs are a problem?

> will be permanently successful

Surely you don't mean actually permanent. So what time scale do you think they will last?

Off by one errors basically don't exist if you use modern languages and practices.

> Anyone is perfectly capable of implementing a Maybe/Option/whatever type in C

C doesn't even have parametric polymorphism, I'm not sure how you're imagining this can be done.

What have I misunderstood?

> I don’t think I understand the reference. Reflex is a library, used to create applications.

Yes, but typical uses would be mobile apps and web apps, pretty "high level" stuff.

> The actual application code doesn’t seem to adhere to any type of functor-oriented programming, as far as I can see: http://docs.reflex-frp.org/en/latest/architecture.html

https://hackage.haskell.org/package/reflex-0.4.0/docs/Reflex...

The entire library abstracts over its implementation via the "Reflex" class. This is not _exactly_ the style advocated in the original post, but it's basically the same spirit.

The reason this is an implicit principle of the Unix philosophy is because the Unix philosophy is to be as lazy as possible as the tool-creator and push all complexity onto the tool-user. Thus we get things like Go, regular expressions, and null pointers.

People outside this school of thought don't finish their projects because their projects actually try to solve the underlying problems in computing, which are inevitably hard.

This style is plenty useful in "higher level" stuff. Consider Reflex: http://docs.reflex-frp.org/en/latest/

Obviously there are bad things about North Korea but the amount of Americans running around in circles and screaming about it as if there are no comparable human rights violations in capitalist countries will never cease to amaze me.

"1994 to 1998"

Why would Democrats be afraid of IDs being required for voting if everyone got one? I thought the whole Republican opposition to voting rights stuff from the Democrats was because they know there's a bunch of poor would-be-Democrats who don't currently have the required IDs.

The problem with tree editors has always been the lack of standardization, not any kind of conceptual or UI problem. Generally authors take one of two roots:

1) Provide a tree based editing UI layer on top of text files since text still rules. In my opinion this is almost like the worst of both worlds, though it can be successful. Paredit is probably the best example of this (and many lispers swear by it).

2) Create a Grand Integrated Vision of How to Fix Every Programming Problem Ever Created. This can make a nice demo, but of course never turns into a practical product any time soon.

Until we have a standardized tree or graph interchange format that is designed to satisfy the common denominator of the full range of languages, protocols, etc., as text does today, all structured editors will be fighting an uphill battle.

It amazes me that someone could write down that principle and then design an untyped programming language.

Agreed. Though this is really a problem with text based editing (which obscures the tree structure), not Haskell.

> In order to afford to own a home I'd likely have to live in Pennsylvania and commute 2+ hours--not much different than in SF.

Why do you want to own a home so badly? Most people in NYC are perfectly happy to rent. But if you plan on staying in the city long term and have a tech salary you can definitely buy and save money eventually.

> Plus, my understanding is that back east, tech is what companies use rather than what companies make, so at most companies you'll be in a supporting role rather than building the products.

The first part is definitely kind of true, the second part depends. If you're really passionate about tech as an industry then yes you might like SF more, but if you care about products that provide value to everyday people and not Uber for X then maybe you'd like NYC companies more.

Probably the poster children of verification:

* http://compcert.inria.fr/

* https://sel4.systems/

> But it's inadequate for the larger problem, of whether the operation is the correct one.

Huh? Types (of the sufficiently advanced kind) are one way of specifying behavior in the same sense as TLA+ and other models. The difference is that type theory provides a coherent story for how to form entire systems like this in a composable manner. Traditional modeling/spec languages, not so much.

Disappointing to see such a long article and no mention of type theory, or any other work from the "correct by construction" school of formal methods. It's all normie model checking, TLA+ etc.

What is unique about it besides having the name of the language as a substring?