I think "Wanted" should be changed to "Imagined" to better reflect the content.
With that being said, it's a refreshing article. Most articles on Steve Jobs focus on how visionary he was, how he was predicting everything etc. This one is stating that, he was a human after all, just like us, and that the future is notoriously hard to imagine and predict. Nassim Taleb would agree :)
Yeah, I really would too. It always irks me when some highly successful businessman gives a talk about "do what you love and you will find success". As if billions of people before him that weren't particularly successful hadn't already tried that.
I wonder if it's a similar thing about the supposed benefits companies thought they were going to get about limiting the customers "right" to repair their products.
On one hand, the benefit look "obvious", yet when you take into consideration the second-hand effects (like bad publicity, people getting frustrated by the inability to repair and getting a cheaper alternative) my guess is the costs were bigger than the benefits.
I've found that equipment that comes with the intention that end users can repair tends to be more robust (if somewhat more expensive) than the inverse.
If you plan not to repair you can skimp on all sorts of things (fasteners that break when you open them, clips that snap off, you can pump glue in etc) that actually lead to complete failure.
It's annoying, it's also hard (though the internet has helped) to get spares for things I can remember my father having no issue getting spares for, cooker elements, washing machine controllers and the like - I can remember when white goods came with a manual that had part codes to order those things in the back and I'm only 38, it's almost a form of learned helplessness.
Someone who can do the work of repairing appliances can make good money doing something else. As the manufacturing cost goes down, it really does make less and less sense to support repair.
It's clearly a local optimum, ideally you'd do the engineering to make repair cheap too, but I don't see how you climb out of it.
Tax the externalities unless we can efficiently recycle everything power efficiently.
I.e. increase the cost of cheap disposable manufacturing so that making things repairable is the better economic decision (and better environmentally).
In modern, highly efficient markets, it's impossible to tell the difference between a great business decision, great luck, a terrible business decision, and terrible luck.
Right to repair is doomed if its proponents make it about the bottom line. You don't really know if this decent thing or another is going to increase or decrease revenue.
Making it about doing what's right for the consumer is great. But better to promote Right to Repair during the boom times, when everyone's making money, and say that it's good for the bottom line, even if you don't really know.
And therein lies the problem. People who are great consumer advocates are terrible liars.
Apple admitted that people changing batteries and continuing using old phones affected their profits, this companies need in a way or other to make more and more profit and this means convincing you to get a new device every year or maximum two.
Apple is telling themselves that at the same time they're saying that the prices are fine. They don't want to admit that they over-reached on the price, especially in countries like China.
That is true, but the current situation is simpler. Design for disassembly and repair is expensive, time consuming, and difficult. It is far easier to have robots slap components together. That is plenty of explanation for phones now shipping.
Is it really cheaper or is something we were told. There are repairable phones that are not more expensive because of that, if you mean we can make this phone or laptop 2$ cheaper if we use glue instead of a screws then we can agree that we want to pay 2$ more to have the ability to swap the battery or keyboard instead of replacing the entire or half of the device.
And where does it end? When the whole world is buying a new iphone every year what do they do next? Release one every month? Force disable older iphones?
What's interesting about Google is, they can have open source products that are hated a big % of devs (Angular) and something that doesn't have that problem (Tensorflow).
I wonder what's the underlying issue behind this disparity. Wonder if it the teams themselves behind those products...
PyTorch is gaining popularity but still behind Tensorflow in popularity, code, documentation and models available. The main difference is the eager execution that Tensorflow does not have until 2.0 that is out soon.
A lot responses challenging your Angular-is-hated claim, but I'd like to challenge your other one.
Tensorflow is not necessarily the most loved framework, despite it being in python, and being around for years now. This is in stark contrast to the way TF was marketed and hyped up, as the f/w that's going to take over the world of DL. That clearly didn't happen.
I think torch/pytorch is more popular (but don't quote me on that). And there are about half-a-dozen more competing with these two.
Putting two and two together, Angular and TF likely have more similarities than differences when it comes to community response.
I think there are dozens of inference frameworks. But full featured ones probably just TF / PyTorch / mxnet / Chainer that I am aware of (since caffe2 is merged into PyTorch).
I think "hated" is a too strong a word here. They're releasing software that they use themselves and I think there are hits and misses in large part based upon how closely your own processes and what you're trying to accomplish match up with what Google is trying to do.
Old opinions strongly held. I think Angular 1 left a bad taste in peoples mouths and that gets carried over in perpetuity. Take php for example, I'm sure you can find plenty of devs who haven't touched php in 10+ years but will still say they despise it.
It gets a lot of hate on HN when compared to React/Vue/etc, but I used it for years and it was a breathe of fresh air coming from raw JS. I think a lot of people on HN form opinions on software and its landscape without actually using it or interacting with its community (outside of HN).
According to on of the biggest frontend developer surveys, The State of JavaScript 2018 [1], Angular is the leading framework that people don't want to use again after having tried it.
So it's not merely HN criticism, this is a very common theme and having used all popular big name fronted frameworks myself extensively, I can also see why many people feel that way. Not gonna steer the discussion there, though, just came here to point out that it's not a niche opinion.
While this is a very personal opinion, the main problems that I have with Angular are only increased with newer versions. I used to really like Angular 1.x, from there on, the required amount of scaffolding etc has only increased.
I'm sure you can however find someone who feels just the opposite way.
All in all I don't think this affects the results too much though. For example Vue is also in one big bucket with 1.x still being a thing. Angular isn't the only one who's had a fair share of changes over time.
I see Vue as ,,Angular, the good parts.''
It's not that Angular is that bad, it's more that it was over-engineered (just like TensorFlow compared to pyTorch), but it was the best framework when it came out.
It's so weird to me that AngularJS (1.x) is a polarizing as Electron.
It has it's warts, but I still love it as it's productivity factor is off the charts. Tried getting into Vue but do not want to deal with the complexity of learning a build tool. Could not get routing to work in Vue with static files.
I think most people (including me) didn't like the 1.4 to 2.0 "transition" (e.g. not a single ounce of backward compatibility, basically Angular 1.4 was abandoned)
you might not be aware but there is a lot of unhappiness with TensorFlow in the community. For example, I hear many comments about how complex it is, how hard the basic API is to use, how many random parts it's acquired. Most of those people point at Torch, and in fact tensorflow is adopting some of Torch's approaches for this reason.
It will be interesting to see if tensorflow retains a fairly high level of popularity over time. The 1->2 transition is a big risk for them because so many people are on TF 1, there's a ton of intrusive changes.
For myself, I was surprised by how low-level Tensorflow was. I found that basic operations (things like saving and reloading a trained model) were much more difficult than in Keras, scikit-learn, or other machine learning libraries. Using Tensorflow feels sort of like computing derivatives with limits.
And the documentation and examples seem to go out of their way to avoid mentioning when you should use any given approach; instead happily inexplicably using any one of them with wild abandon.
Wow, does this mean that (in the near future) we'll be able to take that HUGE repository of WinForms apps and port them to the web? Would be exciting...
This. When evaluating someone's claims, always take into consideration their background, career to evaluate for bias. This is the reason if, for eg, Spain plays against France in soccer finals, they won't put a world-class Spanish judge, however good he/she may be.
We had to deal with this in reverse: we had a form that depending on what you fill in and the settings doesn't show some options.
The browser was submitting the form with auto-fill details that failed the validation checks for those fields. Hard to show an error message for fields the user can't see.
Yes, it is more robust to have code on the server side discard input that isn't expected rather than validate it, but it annoying extra work when those fields have no security impact.
The alternative is to tell the browser not to auto-fill those fields, but doing that feels broken too.
Just pretty difficult to ensure a field really is visible to the user, the problem is it'll always have some weaknesses and those who would abuse it will find those weaknesses
I had this issue with a developer once: We were at a hackaton, and I made a quick-and-dirty feature (we had less than 6 hours left). The other developer on our team got pissed because the code "sucked" and spend a full hour refactoring it...
While this is an extreme, I think every developer is a perfectionist in one area or another. This can be a disadvantage when you're working in highly unpredictable environments (read: business) and where a simple quick-and-dirty MVP will do the job.
So their tendency to be a perfectionist (in situations where this is NOT the optimal mindset) is my biggest struggle when working with developers.
I find that there's a good tension between the two, but that context is really important. Certainly in the hackathon situation the refactor seems like a foolish choice.
With that being said, it's a refreshing article. Most articles on Steve Jobs focus on how visionary he was, how he was predicting everything etc. This one is stating that, he was a human after all, just like us, and that the future is notoriously hard to imagine and predict. Nassim Taleb would agree :)