371–380 of 407 posts
Earlier quoted context omitted.
Create react app, with all node_modules included, is well over 200MB of garbage OSS libraries. That’s insane for a hello world.
That’s like saying a pencil weighs 1000kg because the machine that makes them does.
I don't get it. I assume the author is trying to make it sound absurd that you would need all these layers of factories to build a simple spice rack and, by analogy, that frameworks are also absurd. But if you were building spice racks at scale, of course you would build them in a factory! And you'd use machinery made in other factories. And those factories would have tools and machines made in yet other factories. T…
Yea it’s nonsense. Factories are fantastic. If you want to do something as a hobby, sure don’t use the most advanced tools and do it by hand, but for everyone else especially professionals who are charging other people for their time and effort using the best possible tooling is essential. In fact, if somebody didn’t use a common library or framework and instead “rolled their own” it’s downright irresponsible, obnoxi…
Yes, the state of the industry is a hot mess, but I'm not sure this article rings true. Failing to leverage good frameworks is as big a problem as over using the bad ones. I would point to Rails as an example of an appropriate framework (and Laravel if PHP is your jam). The trouble is so many others are bad, incomplete or defunct, but I don't think the answer is the golang mantra of 'we don't need no stinking framewo…
Frameworks are bad because they don't compose. What does compose? Simple types and pure functions. If you want to create a community with high levels of code reuse, start there.
I was listening to a talk (strange loop conf, can’t search the talk itself) where the speaker claims C and languages derived from it feel clunky because they were invented, while Lisp, Haskell were discovered. The latter group is more cohesive and relies on simpler truths instead of the amalgam of idioms you can find in Java. I concur with this because programming with Clojure feels wonderful. Your code is a straight…
Earlier quoted context omitted.
And they mark up the price to $200 (that's what the device costed... a 68k in 2017...)
Iirc they had to lobby college board to change the rules to allow colored screens on exams since the black and white screen was more expensive than the colored ones since no one made the black and white ones anymore I'd be open to allowing smartphones/tablets on all tests so long as there's no internet. Note taking is more important then ever imo, and knowing how to apply things rather than doing he computational mac…
Shouldn't hike the prices on the super old TI-89 Titanium unless the screen (and the CPU, and etc.) is really that much more expensive now.
Earlier quoted context omitted.
If “hello world” is the whole requirement behind an app, and you won't develop it further, you don't heed to use react. In fact, here's your whole app: “hello, world!”. Copy it, save it in .txt file, serve in static anywhere you want.
I wish more people would actually follow this advice. When they don't need anything "reactive" they would not use React. When they don't actually need an SPA, they would not use React. When they don't actually need dynamic behavior on a website, they would not use React or JS. But unfortunately people use what they don't need all the time, rather following hype than reason.
Earlier quoted context omitted.
I wish more people would actually follow this advice. When they don't need anything "reactive" they would not use React. When they don't actually need an SPA, they would not use React. When they don't actually need dynamic behavior on a website, they would not use React or JS. But unfortunately people use what they don't need all the time, rather following hype than reason.
Or, may be, they use the tool they're familiar with, because what they need is to be productive immediately instead of wasting their time to learn different tooling. Even if this different tooling is simpler that what your already know.
Generally people use 10x on cost at every subsequent step. Andy Grove famously talked about how this made the FDIV pentium bug cost Intel untold millions instead of pennies.
He said when the mistakes and decisions seemed free early on, that's actually when they were the most expensive.
As more commitments were made towards the design, it became costlier to back out. Then they discovered it after production and shipping, and by then it became so costly and famous people still remember it 30 years later.
To be more direct, if someone doesn't know how to do it right they Shouldn't Be Doing It. If someone can't fly a plane, they shouldn't be flying planes. If someone can't operate a construction crane, they shouldn't be operating one.
Same thing here. If they're doing it wrong because that's all they know, they are unqualified. They should not be given the responsibilities.
So that method of doing what you're familiar with is the cost of incompetency. Planes and cars crash under incompetent hands and software doesn't fare much better.
Earlier quoted context omitted.
> But in the world of the factory factory factory, the apprentice carpenter (who really just wanted to drive a few nails) is now faced with trying to understand the gargantuan complexity of the factory factory factory. Sometimes I wonder if that's the point of all this complexity. (EDIT: I mean really excessive complexity as alluded to in the article with factory factory factories, or 100 microservices all in differe…
No, I choose the technology and/or fundamentals that the juniors will have to learn if they want to level up as a developer. The best way to get them to work the right way is to use a framework that incentivizes it. If doing things wrong is made harder, and doing things right is made easy, everyone wins.
I don't get it. I assume the author is trying to make it sound absurd that you would need all these layers of factories to build a simple spice rack and, by analogy, that frameworks are also absurd. But if you were building spice racks at scale, of course you would build them in a factory! And you'd use machinery made in other factories. And those factories would have tools and machines made in yet other factories. T…
Yea it’s nonsense. Factories are fantastic. If you want to do something as a hobby, sure don’t use the most advanced tools and do it by hand, but for everyone else especially professionals who are charging other people for their time and effort using the best possible tooling is essential. In fact, if somebody didn’t use a common library or framework and instead “rolled their own” it’s downright irresponsible, obnoxi…
To be fair this is from 2005 so frameworks were less composition based.
But yeah, HN has been full of noobs for a while. In both a technical and epistemological sense.
Earlier quoted context omitted.
Or, may be, they use the tool they're familiar with, because what they need is to be productive immediately instead of wasting their time to learn different tooling. Even if this different tooling is simpler that what your already know.
Right but the earlier you catch your mistake the more time you'll save in total. Generally people use 10x on cost at every subsequent step. Andy Grove famously talked about how this made the FDIV pentium bug cost Intel untold millions instead of pennies. He said when the mistakes and decisions seemed free early on, that's actually when they were the most expensive. As more commitments were made towards the design, it…
In context of a simple project: yes, React is not the best tool for the job if you look at project requirements. But also consider the fact that the bundle size and optimization might not be that important from business perspective, and project scope is very limited from time perspective. That's why using React might be the best choice: you're optimising for developer productivity on the short run.
However, the situation you are describing now is different. Not only project's business priorities are different, but also the scope is much larger. Which means that spending time on choosing tools and learning a new tool would tale a much smaller % of project's timeline, and thus it makes sense to spend a lot of time on that to potentially save a lot of time and improve other characteristics later on.
In other words, you don't do pre-production on hello world, but you do on something huge.