Live data from Hacker News

We have used too many levels of abstractions

unixsheikh.com

491–500 of 564 posts

Re: We have used too many levels of abstractions

#491
post #186

Earlier quoted context omitted.

See, that’s the kind of social pressure I was talking about.

And that's probably healthy for society to have a check. If the questions about the sky keep the questioner in bed they might not do the things they need to ensure their continued existence. In one respect that might be food but in a business that would be delivering change or supporting the business. Another example: as a child you understand what + means and take it for granted. As part of Maths undegrad you start…

Ah you went there eh. Yeah an alternative form on my reply would have been to point out that kids are the ones who question everything. Adults learn to identify the questions which will expand knowledge, and ask those.

Re: We have used too many levels of abstractions

#492

Earlier quoted context omitted.

The problem is that it takes a really long time until technology is so good and so reliable that you really don't need to understand it to be able to operate it. Take, for instance, the "Yes, let's all go back to coding in assembly!" line -- The thing is: For a really really long time after high-level languages had become mainstream, you really did still have to know assembly to be a programmer, even if you did most…

Pilots must still understand how planes work. That’s called aviation. Most software devs have absolutely no idea how their software platform works. Most are overpaid API monkeys.

API monkeys, not by choice.

Software devs have zero control over the tooling, languages, networking and hardware.

It looks like they have a choice because the map of available options constantly shifts... but they're metaphysically locked to near-identical options in the universe of potential ways.

As long as computing is largely US based, it will always be this way. It's treason to go off-piste, in a large way.

Re: We have used too many levels of abstractions

#493
post #165
post #39

Earlier quoted context omitted.

Questioning everything also gets you stuck in bed asking why the sky is a different shade of blue. Others might have accepted the unknown and ate breakfast.

asking why the sky is blue when you don’t know is perfectly fine and even admirable when everyone else seems to know and you don’t. i would expect such a person to at least try some research first and then share what they learned and what questions they still have, but if someone is asking earnestly and i have time, then why shouldn’t i help? i don’t thjnk the logical extreme you position here is correct; if it’s an…

The question was not "why is the sky blue", but "why is the sky a different shade of blue".

Every day the sky will be slightly different. There exists a reason why, and given effort you could identify the differences and relations.

Or you could go to work.

> It's a pattern I see a lot. On the flipside, when clients have devs who mostly grok the entirety of their system, then we can focus on the questions that really matter: purpose, market fit, empirical evidence from users, _etc._

So... stopping. Not questioning everything eh.

Re: We have used too many levels of abstractions

#494
post #240
post #39

Earlier quoted context omitted.

Questioning everything also gets you stuck in bed asking why the sky is a different shade of blue. Others might have accepted the unknown and ate breakfast.

This is exactly the kind of "Sarcastic comment by arrogant developer" that the article mocks.

Not a drop of sarcasm. Perhaps you should question why you mistook wisdom for comedy?

Re: We have used too many levels of abstractions

#495

Earlier quoted context omitted.

Pilots must still understand how planes work. That’s called aviation. Most software devs have absolutely no idea how their software platform works. Most are overpaid API monkeys.

And cab drivers must still understand automobile manufacturing?

Developers for which the above argument is clever and persuasive are essentially equating themselves as the equivalent of cab drivers. Their libraries, frameworks, and hardware are black boxes to them that they manipulate in pre-prescribed ways (and sometimes just plain cargo-culting) to achieve a desired result. When their abstractions break down, they have to call in specialists to diagnose and repair them. Of course, they get very agitated and defensive when people point this out and, very much unlike what a hacker would do, try to diminish the value of expertise and skill and call it unnecessary. And, okay, for them, it is.

Yes, a cab driver does not need to understand automotive engineering because a cab driver is, in the non-pejorative, technical sense of the word, unskilled labor. Is that really the analogy you want to make though?

Re: We have used too many levels of abstractions

#496
I would love there to be a hands-on "History of Computing" class that runs through the history of computing (maybe starting in the 1970s?) through hands-on activities (through emulators probably) to give some perspective about how awesomely fast and powerful computers have become. This could also serve to expose where things have regressed (e.g. text editor and other UI responsiveness, complexity of the web stack). A version of this lesson could also be taught with video games to show though older games were visually simple, and just a tiny fraction of the file size, they were frequently just as fun.

Semi-related: I'd love to see a single video game that modernized the game experience as you played: Text mode only -> text mode + static VGA graphics -> 2D sidescroller -> Wolfenstein-quality -> DOOM-quality -> Quake-quality -> Half Life 2 quality -> modern-AAA.

Re: We have used too many levels of abstractions

#497
post #452

Earlier quoted context omitted.

> Most are overpaid API monkeys. I think that's a highly dismissive and ignorant view of what software development, as a value-creation endeavor, actually is. The responsibility of a software engineer is not mapping high-level constructs to low-level details. The responsibility of a software development engineer is to implement systems that meets the business requirements, and operate on those systems at the abstract…

The only one purpose of software is: automation . The degree to which a software developer strives towards that one purpose determines their employer’s return on investment completely irrespective of the business requirements. Unnecessary abstractions exist not to simplify any return on investment but to ease candidate selection from amongst a pool of otherwise unqualified or incapable candidates.

> Unnecessary abstractions exist not to simplify any return on investment but to ease candidate selection from amongst a pool of otherwise unqualified or incapable candidates.

This take is outright wrong. One of the most basic business requirements is turnaround time for features, bugfixes, and overall maintenance, which ultimately means minimize operational costs.

All production-ready application frameworks are designed to provide standardized application structures out-of-the-box that hide the implementation details that don't change and make it trivial to customize the parts that change more often. Backend frameworks are designed around allowing developers to implement request handlers, and front-end frameworks are designed around allowing developers to build custom UI elements from primitive components, provide views to present data, and fill in handlers to respond to user interactions. Developers adopt these frameworks because they don't have to waste time reinventing the wheel poorly and instead can focus on the parts of the project that add value.

Re: We have used too many levels of abstractions

#498
We're in the tail end of a Cambrian explosion of new languages and frameworks. That explosion is understandable giving the huge shifts from mainframes to desktops to web/mobile/cloud. The TIOBE Programming Community index shows today's programming language use much less concentrated than it was 20 years ago. I expect a few dominant languages to re-emerge as the overall computing landscape stabilizes and LLMs make it low effort to translate entire systems between languages.

Re: We have used too many levels of abstractions

#499
post #8

I support the notion of this post. In the last 6 years I’ve mostly been busy removing layers of abstraction in order to uncover the set of tools which is a good balance for me. In example, replaced clojurescript with Javascript and then eventually Typescript. Replaced Clojure with Java. Replaced docker with VMs. Avoided ansible in favor of simple bash scripts. Avoid all kinds of firewalls in favor of understanding an…

I stopped using clojurescript in favor of pure JS (without react) but if I was going to use typescript I would pretty much continue using CLJS.

Re: We have used too many levels of abstractions

#500
post #314

Earlier quoted context omitted.

What are you using server side? I've been looking outside the JS world for an alternative for doing full stack dev and Laravel Livewire seems like an amazing alternative for like 80-90% of use cases. Something like Alpine, vanilla, or even Lit for the more sophisticated interactions.

I’ve been super impressed with Livewire on several small projects. I’ve been sold these same sorts of promises before (yeah you write backend code and we put some glue in and then everything works like it’s running in browser) and usually it’s a case of a very narrow happy path and indescribable horror once you’ve fallen off and have to wade through or work around the “magic”. I did not go into Livewire with high hop…

Thanks for confirming my suspicions :)
Post reply on HN