_8jmg

Was about to type the same thing, am also pianist. Using small muscles to do repetitive things is exactly how you get RSI. Don't do stuff with small muscles that you can do with large ones.

Unfortunately, even in the piano community, this knowledge is not that widespread. Really common to see repetitive motion injuries from very finger heavy technique.

You shouldn't swallow errors like that in FP either. You can trap the error in an effect type and throw it at the top level of your app when your effect type gets run after all of the code that processes that error value has a chance to recover. See something like Zio for an example, though you can do similar things without Zio.

What's the best way to contact you?

More or less, yes.

> It’s definitely hard to explain an idea like SVM, it’s applications, and how it works/what it does without a background in some linear algebra.

I don't actually think this is the case. The basic idea is that you can represent data as points in n-dimensional space and draw decision boundaries in that space. I think most people should at least be able to understand this geometrically for n=2/3 and then accept that it possibly extrapolates to n > 3.

I agree that in a vacuum, zero sum games aren't necessarily a bad thing. However, in our hypothetical economy, the actors obviously aren't at parity for their level of skill at playing the game. In a zero-sum economy, consolidation is inevitable. At least in the presence of growth, the avoidance of consolidation is a possibility.

> Suppose every year Farmer Joe has to borrow money to buy seeds and pay workers to plant, grow and harvest the crops. Then after harvest he sells the crops and uses the money to pay back the loan. Every year it's the same, every year he starts and ends the year with the same amount of money, there is no economic growth, but the lender is still earning interest on the loan every year.

> Meanwhile the lender is your 401K, so it makes money over time which you then spend down in your retirement and die with the same amount of money in real terms as your parents did, and so on indefinitely.

I feel like you're making the assumption that the agents in this system don't make an attempt to consolidate (and obviously if and when they do, they will have varying levels of skill at doing so.)

Completely agree with the last paragraph. The economy is tilted way too far towards incentivizing value extraction instead of incentivizing value creation.

Don't know that I agree with some of the previous stuff though. Even if we assume a steady state population, if the economy doesn't grow every year, we're playing a zero or negative sum game literally by definition.

RE your second paragraph, I both agree and disagree. As far as I can see (at least the US system) is predicated on ~4-7% economic growth being the way that people systematically grow relatively small savings into a large nest egg for retirement (not that this appears to be working particularly well, see your comments on pie stealing.) If we assumed a steady state for the population and economy, I don't see how people working for average salaries can set enough aside for retirement (without pushing themselves to a pretty low standard of living) without the benefit of ~4-7% compounding.

I have a developer's salary, so I could probably put away a couple million cash before my retirement even without the benefit of compound interest paid by economic growth. That's not the norm, or even the average though. Participating in society/the economy has to be an attractive enough proposition to incentivize people to do it, or bad social problems start popping up. In a steady state system, I don't see how we can make an offer more attractive than "Enjoy your subsistence lifestyle up to retirement, so you can have barely enough to have a subsistence level lifestyle in retirement."

I used to think this, but I've come around somewhat. The economy as a basic premise is expected to grow at least 3% a year or bad stuff starts happening. Obviously no kind of exponential growth is sustainable, even at a low rate. The best minds are getting sucked into this at least partly because the work is necessary to keep the economic wheels spinning. If we give up on having an average % of yearly growth, we're committing to living in an economy that's a zero or negative sum game.

So yes, we are stagnating scientifically, but it's not necessarily for no reason. The longer we keep running the economy as is, the more smart people are going to have to be allocated to figuring out how to keep up with the exponential growth our system demands. Unfortunately, no one seems to have cracked steady-state economics, so it looks like we'll be doing this for the foreseeable future...

Additionally, I don't know how we're supposed to keep up with this absurd need for exponential growth without leaning hard on technology (at least if we presume we don't want to wreck the planet more.) I feel like big tech is actually doing something important with regard to growing the economy disproportionately with the physical resources they consume.

You can be nouns first and still be anti-OOP. I think the objection anti-OOP people have with OOP is the business of folding your verbs up with your nouns, not being "noun oriented."

I don't know. I've been slinging Haskell on the side for the better part of a decade and do most of my day to day in RoR (trying to start moving clients over to Elixir/Phoenix.)

Haskell is an amazing language. I would totally buy that Haskell teams probably win in the medium to long-term as the wins you get in terms of support/maintenance/extensibility are pretty obvious.

However, anecdotally, Haskell forces me (and I imagine other programmers) to invest a lot more time up-front into getting your design in order. Haskell punishes an "oh I'll just hack that out" attitude pretty badly. Which, as I said above I would completely believe leads to wins in the medium to long-term. If I need to bang out an MVP over the weekend, I'm probably not choosing Haskell unless it's well-trodden Haskell territory.

Additionally, while the language itself is amazing, the ecosystem has issues (enumerated in the article.) Tooling sucks, there aren't enough examples of people doing normal things, there are frequently not libraries for basic things, obviously integrations with popular services are lacking, and the list goes on.

When Haskell has a decently mature and actively developed web framework that has reasonable docs, examples, and a not pathetic ecosystem (by the standard of modern web frameworks) I'll happily jump into using Haskell in production. Unfortunately, these aren't things enough of the community seems interested in to have significant movement on.

Servant looks very interesting with regards to what I'm looking for, but I'd be lying if I said I understood the types.

Was going to say exactly this. Major common misunderstanding about even Haskell. Mutable state has to eventually be a part of basically every program that does something useful. The Haskell philosophy is more about having an explicit and predictable boundary between the pure and effectful parts of your code/system.

Though you'd be surprised at how much you can do while forgoing mutable state entirely.

Skill-wise, absolutely. Demand-wise, absolutely not. I'm a freelance developer now, but before I was a senior engineer at an international software company. I've considered several times pivoting to productized Wordpress consulting because of how easy it is and relatively scalable vs other kinds of software development. The level of demand for basic Wordpress setup/configuration is really pretty astounding.

I suppose it's all relative, but at least in Rails, while I suppose it's trivial in an absolute sense, it's much harder than doing stuff "the rails way."

I didn't mean to say that SPAs were easier at all. They're not. I think they're under most circumstances much harder than traditional webapps. That being said, my experience is that users and in my case clients are starting to expect SPA features and it's harder to try and coax extensive SPA functionality out of a traditional web app than it is to just write a SPA.

It's been probably 2 years since I've seen a front-end dev listing that doesn't list experience with a SPA framework as mandatory. I'm not going to question that hybrid and traditional apps exist in the wild. I maintain some myself. That being said, I think it's pretty clear that at the very least the world is moving on. We are asking for more out of the web than what it was designed for, and it's difficult to meet the expectations of modern users without modern tooling.

By way of example, I do a lot of freelancing and have quite a lot of clients that I think would be better served by a traditional web app (much faster to develop, though not nearly as rich interactions dollar for dollar. Also a lower infra bill generally.) Many of them refuse though because they've been conditioned to expect the kinds of features that SPA's provide.

I write a lot of business automation sorts of apps for SMBs. Something I see requested a lot is wizard style workflows (on a web app.) This is trivial in a SPA and a major annoyance at best in the context of a traditional app framework. I totally agree that the world might not have moved on yet, but I think it's pretty clear which way the wind is blowing. Users are expecting rich SPA interactions as the new normal.