419 karma · joined March 4, 2013
It's a feature that was obvious back when we were all using Nokia 3310s. Connect phone and computer as one thing. Call and message from either. Heck, calling from your computer was an obvious feature-to-be back in the monochrome screen days!
It's ridiculous that a) Apple is the only company that has this right now, and b) it took them so long to get there in the first place.
What the hell is everyone doing!?
Alternatively, we've got closed systems like Slack that are slowly and pervasively getting rid of open systems like IRC.
I'm really not sure that there's an engineering time advantage in taking a reasonably solid existing piece of software and rewriting it in Electron. Is the technical debt really that large?
Really, I think the problems we have are political, and not technical. I include things like NIH syndrome in that group.
So, no, supply and demand theory kinda doesn't stack up when it comes to housing.
Foreign owners are likely to move at least a portion of this money overseas, which takes it out of the local economy, reduces the ability of residents to innovate by taking financial risks etc etc.
How dare they.
I mean, you can write a bunch of pinning tests, then try to prise out various bits and pieces, sure.
But what if all the stuff you're trying to prise out can now be accomplished with a few open source libraries that didn't exist way back, with a very simple rewrite of your business logic on the top?
That's a situation I've encountered quite a few times - a lot of legacy code that's largely boilerplate, with business logic drizzled over the lot, oozing into the little cracks.
Well done, internet intention interpreter dolessdrugs.
My personal theory is that the movement away from 'record stores' has really killed discoverability of new music and genres, and most of the new platforms just feed you more of the same music you already listen to.
It will be interesting to see what happens in the next decade, you may be absolutely right about a backlash against the ultra-commercialised nature of some of our modern toys.
Far more thrilling than having Windows 10 invade itself onto some modern soulless fucking lounge bar. I mean hardware.
Facebook is constantly trying to outgrow what it should be, and the more it does this the less nice it becomes.
Twitter I have little issue with though, amazingly.
Sports, activity interest groups fill the void a little.
But there's so little downtime as an adult these days it's a chore.
Everyone makes mistakes, and the sooner people realise that in this modern, lose your job because of a twitter post society, the better.
Sitting down after dinner and having a few deep, interesting conversations with friends and random strangers was enlightening, and so rare these days.
So at least in that regard it's arguably much worse than it was 15 years ago when many different genres were alive and well.
I would hate stores to implement half of the recommendations. Swiping my smartphone on entry?!
I'd prefer to shop at the distributor's warehouse.
That's not to say that it always happens, and certainly some less, uh, experienced developers will write terrible code. But they'll write terrible code in Haskell as well (or no working code at all, which has been my experience at least once).
I'd consider myself very comfortable with maps, folds, filters and zips. I wouldn't consider myself super fluent with their use in Haskell, which definitely contributes to my own struggles with the language.
But for something like the canonical quicksort example in Haskell, it takes me quite a while to figure out whether it's actually implementing quicksort by the book, or whether it's implementing something that sounds like quicksort but isn't. This is because I have to map the declaration to the underlying implementation when it matters. Probably more often than not it doesn't matter at all as long as the code works and isn't causing problems (which is where the functional primitives are fantastic), but I do find that digging deeper into a more complex functional algorithm can be a difficult task.
This is because you have to think about how every part might work behind the scenes. Am I doing something stupid like mapping my whole data set with a computationally intensive function? Is one of the innocent-looking predicates in my list comprehension actually some super intensive function that's had an operator overload? Am I going to be applying this predicate to the entirety of a massive list where in an imperative context I would have a really obvious switch case or set of ifs, a clear non-symbol invocation of reallyExpensiveFunction, and exited my loop early?
It's a little difficult to describe I guess, but for me reading [what I believe to be] idiomatic Haskell code at a high level is reasonably straightforward, if somewhat slow due to the compactness, but actually understanding what that code is doing can be incredibly difficult.
In some ways it's the same type of issue I have against liberal use of recursion. It might be reasonably easy to describe a recursive algorithm, but to really get in and understand it requires a much deeper understanding that's often easily more difficult than understanding its imperative cousin. There are real reasons why comp sci students struggle with it.
This is how software worked for multiple decades before subscriptions came about.
But don't forget compatibility updates. Underlying platforms change all the time, it makes sense for users to have to pay for these updates outside a certain time period.
Perfect.
... But JetBrains attempted to explain why this doesn't work with the subscription model. And failed IMO, but regardless.
It's only become a big thing after iOS and it's lack-of-a-filesystem and lack of inter-app data flows locked users out of their own devices.
Quite often I don't want many of the "new features". For me, bug fixes and security fixes are the main thing, followed by compatibility updates. I'm quite happy to pay for the latter when it was me that caused the issue by updating my OS/hardware in the first place. I'd quite like some amount of the former to be included in the original cost.