joshlemer

Why's that? What has changed that makes selling nicknacks on Ebay less worth it?

I'm a little bit unclear about this, will Google's changes here also affect other android distributions like LineageOS, OxygenOS, etc? If not, then I could see that Google locking down their Android Distributions like this could breath a lot of life into some alternative distribution(s). If yes, then perhaps forks of Android or even competitors to android altogether.

Well, a union is a form of cartel, it's an anti competitive organization of market participants who are colluding to set prices and extract other concessions from labour buyers. They therefor undermine the ability of markets to maximize value for all participants.

When a company makes a profit, that doesn't necessarily mean they made anyone else worse off. In general, when in a competitive environment, and dealing with customers who are responsible adults (which both hold in the case of the restaurant industry), we should presume that everyone is being made better off by the transactions, that it's a win-win situation.

Well, I don't particularly enjoy ads on Reddit, Gmail, and, when I used them, Tiktok, Facebook, etc but I wasn't particularly pissed off by them either. On YT it seems just so in your way and in your face and egregious. It's like every couple minutes there's an other ad. You can't even chromecast videos to your tv to play in the background because you have to constantly babysit it or else it will load up an ad that goes on forever or 10 minutes until you come back to skip it.

For those who haven't ever gotten into microtonal and other non-standard tuned music before, it's a really interesting space. I would highly recommend checking out Kyle Gann's album Hyperchromatica (https://www.youtube.com/watch?v=gbT9oRbu3h8&list=PL1IsImnKxK...), which has a pretty wide variety of pieces/genres, showing the potential of nonstandard tuning. It takes a bit to get used to it but there are brand new colours and emotions that open up here IMO. Definitely worth checking out!

> they're building a product for people who can write JavaScript event handlers but somehow can't 'npx create-react-app'

There's an enormous gap in complexity, required skill, etc between creating these Scrappy applications and building the whole app in React, and then getting it deployed, complete with real time syncing, authorization (as they've implemented with their "frames" and everything. It's at least an order of magnitude greater in effort.

> software, unlike a meal or a home-made sweater, comes with an implicit support contract that lasts forever

I don't think it always has to. It tends to be that way because so far, the lift to create a functioning cross-device multi user application has been high enough that the economics of it requires centralized teams of specialists to build an application for many hundreds of people.

If you lower the stakes really low to the point where the app is as serious as a spreadsheet, then compare it to spreadsheets. Almost everyone has dozens of really casual spreadsheets, many households have shared google sheets for particular, short-lived or casual or constantly changing use-cases. When you slap together a spreadsheet with your partner, you aren't making a promise about long term support and compatibility with the spreadsheet.

Or an other similar thing would just be paper and pen and tape, up on a whiteboard. All kinds of little "hand made" "applications" like this exist in households and in offices. Kanban boards are an example of this but there's and endless different kinds of "board-based physical apps" like chore charts and weekly meal plans. When someone writes on their fridge a list of chores and starts tallying who does what, that is not an eternal promise to maintain the piece of paper with chores and tally marks protocol/system.

The comments about being a SAAS, walled garden, and about the specific implementation here wrt where data's stored etc, this is just a prototype. A POC.

I agree. I feel pretty discouraged from investing the amount of time it would take to get really involved and proficient in a game, if that game is ultimately not owned by me fully and can be paywalled. There's something more satisfying and timeless about a game like Chess or Go which partly I feel is due to them being owned by everyone/nobody (I mean, yes they're also centuries/millenia old but still).

I agree, these are highly experimental projects, more like POC's and not something to actually use for important work. I don't know why people are so often recommending all these myriad different Clojure/Script runtimes/interpreters, many of which are not fully baked.

But they don't support the full Clojure language, they're more like alternative dialects.

Well I mean, in Canada, Europe and the US these would be illegal if they're able to go more than 32, 25, and 40 km/h respectively. That doesn't mean there aren't illegal ebikes out there but I think the vast majority of e-bikes on the road comply with the legal limits.

It really is so obviously reasonable it makes you wonder why this isn't already in place. For instance e-bikes are all speed and power limited, why aren't cars?

In some countries like Canada you basically don’t have an option.

Their pricing is absolutely out of this world though. Their BASIC plan is $2990 USD per year, the pro plan is $9990/year. https://carlo.app/pricing

Aren't all the labels on the buttons facing the wrong way? They're facing outwards in the direction of the screen viewer, rather than inwards towards the person operating the thing.

What happens if it looks freshly wiped?

Classic deflection and whataboutism.

It benefits the poor by allocating resources as efficiently as possible. If there is someone who is poor enough that they need help from society/the government, it would be much more effective to transfer money directly to the, rather than very very poorly (probably regressively in fact) target that help by having the public subsidize parking on their block.

They would rather have the $100 in efficient redistribution rather than the government spend $100 so that they can benefit by $1.

The solution, as Donald Shoup advocated, is to raise (or in some cases, lower, and in general, have it be dynamic) parking rates to market-clearing prices for parking spots such that there are is always one (but not too much more) free spot available on the block.

Laravel and Django didn't bring fundamentally new ideas above and beyond Rails.

I mean, I don't find that working with IntelliJ makes it any "heavier" than other languages in terms of prototyping. I use PHP Storm for Laravel development and I never say to my self, "if only I wasn't using an IDE, maybe I could get this site put together faster". Quite the opposite, Intellij makes me super productive.

I think all of these frameworks - Laravel, Rails, Django, Next.js, Spring - require deep familiarity to get the best out of them.

> Honestly I struggle to see how they could've done it without making the compiler and build tool much faster

Well, Lightbend literally was the owner of Play, SBT, and Scalac. They were in a perfect position to make the build tool and compiler much faster. Or even if SBT can't be made much faster, ditch it and make integration with gradle and/or maven really great.

> Slick

Totally agreed, Slick is definitely not a good way to access the database. It massively over complicates things and was a massive oil spill that destroyed the maintainability of many codebases. But that's not really Play, specifically, just a library that lots of people used with Play. I personally was always more a fan of https://scalikejdbc.org/, if not just plain JDBC

> It was in state of semi-abandonment for several years

Yes, this is my main complaint. I remember on the front page for like 5 years after TypeSafe Activator had been totally removed from the internet, the Play website was still showing Activator commands. To this day, the Play site still hasn't removed their line about how they support CoffeeScript and Less.

> Guice (in 2.4 afaik) was a terrible mistake, completely unnecessary and at odds with the Scala philosophy > Play-JSON depends on Jackson > Standard library Futures are not so nice

Well, it turned out that the Scala Philosophy wasn't the be-all and end-all anyways, and was always changing (at some point DSL's were in, then they were out. The way people encode TypeClasses changed over the years, selectDynamic/applyDynamic were in and then they were out, symbols were everywhere and then deprecated, implicit conversions were in and then "best practice" switched to Converters) and there was always at least 2 camps who had very different philosophies. Guice is probably the most popular DI tool in the JVM world so seems to make sense to use it.

The Jackson dependency and Scala Future's shortcomings might be annoying to many, but I don't think they really hindered adoption. Even in your case, what happened? At your company they're ripping out Play and replacing it with Spring, which uses DI very similar to Guice, probably depending on Jackson, and using java Futures (if they're doing async at all).

What is so bad specifically about play?

I disagree, productivity and ergonomics drives plenty of popular tools - React, Laravel, Rails, React Native, etc.

Yes. Java, Python.

> Scala Play webapp

I feel like the biggest misstep that the Scala ecosystem and Typesafe/Lightbend did was that they didn't invest more in Play Framework. 10 or 12 years ago, Play had a lot of energy and momentum, and it's a kind of thing that has broad enterprise/start up appeal. But focus was always more on Akka and what seemed like really niche architecture astronaut stuff like Actors and Actor System Clusters and Event Sourcing etc, rather than getting the basics to be super ergonomic or productive.

If they had keep just making Play Framework better and better and focusing on the practical problems that every web service faces, they could be in a similar great position as Laravel is in today or any of the many Rails/Laravel consultancies.

The thing I always get stuck on with these techniques is, how do you handle transactions which perform validations/enforce invariants on data when you’re just writing writes to a log and computing materialized views down the line? How can you do essentially, an “add item to shopping cart” if for example, users can only have max 10 items and so you need to validate that there aren’t already 10 items in the cart?

The claim that we are disagreeing with is that Bitcoin is meaningfully different from any other investment in a way that makes it a Ponzi Scheme. I'm not trying to persuade anyone that it's a good investment, just that it isn't a ponzi scheme any more than gold, oil, real estate etc is.

The fact that there are other ways to work around previous limitations to accomplish something doesn't render the use-case invalid. The GP was asking for a usecase outside of currency and one was provided. If a valid use-case for electricity was asked, and someone described a lightbulb, you could just as well say "...or, you could just use an oil lamp"

If Bitcoin is a ponzi scheme because of this, then literally every asset which has resale value is a ponzi scheme.

When people buy bonds, stocks, commodities, or purchase a car, a house, or even an Xbox, they are taking into account the resale value of that asset. If you supposed that when you're done with your house, it would be worth $0, you would be willing to pay a lot less for it. There's nothing fundamentally different here wrt Bitcoin.