Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We have used too many levels of abstractions

unixsheikh.com

Post reply on HN
Print view View original

501–510 of 564 posts

Re: We have used too many levels of abstractions

#501

Post by meiraleal »

johnklos wrote: post #321
hliyan wrote: post #48

In other words, cargo cult programming. I wrote about this two years ago [1] and received only polarised responses that either agreed with the point wholeheartedly, or attacked me viciously for gatekeeping. I wish there was a better way to cure this disease without triggering the professional immune systems of engineers who are highly vested in their favourite technologies. [1] https://medium.com/the-engineering-mana…

You asked good questions in that article. It's unfortunate, and I can't help but wonder if we've lost something essential because of how uncommon it is for people to be proud of their abilities, proud of their work, proud of their accomplishments. In a nutshell, I think people who truly enjoy the satisfaction of doing a thing well are spending more time, generally, trying to truly understand things than those who jus…

> It's unfortunate, and I can't help but wonder if we've lost something essential because of how uncommon it is for people to be proud of their abilities, proud of their work, proud of their accomplishments.

Is it? this forum is full of it in the form of blog posts and replies. And it is one of the things that makes it great. By the other hand, social media is also full of people boasting about their accomplishments but more often than not is just marketing.

Re: We have used too many levels of abstractions

#502

Post by kosolam »

omneity wrote: post #34
kosolam wrote: 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 don't know how others feel, but to me docker is definitely less complex internally than a VM. For one, I'm running a single kernel/set of drivers rather than two. But operationally yeah I agree, the stricter separation could make it easier to use a VM to get stuff done.

Just to clarify a bit. A VM is already a container. When you run docker inside a VM it’s another level of abstraction. Yes, one can run docker containers on bare metal, however the isolation is poor and so is the security guarantees. In terms of excess abstraction, with VMs or bare metal you just need to learn the essentials that you need to know anyways like for example linux networking and security. With docker there is additionally container networking.

Re: We have used too many levels of abstractions

#504

Post by austin-cheney »

rewmie wrote: post #497
austin-cheney wrote: post #464

Earlier quoted context omitted.

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 desi…

At least in JavaScript land all production ready frameworks only solve two problems: architecture in a box and put text on screen. These are trivial to achieve at substantially lower effort without the frameworks, but it requires a more experienced or better trained developer.

What you describe is a training failure, but your thoughts on the matter are an economic failure. The goal of software is eventual cost reduction via automation. I say eventual because software is always a cost center and its value is not immediately realized.

What you describe is employment, which is not the same thing. The least friction path to employment to turn candidates into commodities to ease selection and risk of rejection post-selection. Once employed the candidates perceived value is often measured in things you describe, which rarely translates into any kind of value add to the business. Churn is burn, which increases employee engagement but almost always increases operational costs. The way to decrease operational costs is with automation, which includes things like CI/CD, static analysis, test automation, and so forth. These automation efforts are not measured in churn.

That contrast is why many software developers are API monkeys, because its what they are hired for and what they are rewarded for. That is why software developer return on investment is not defined by business requirements. Many employers need people to perform low effort work and do not wish to invest in formal training. This is all measurable.

Re: We have used too many levels of abstractions

#505

Post by kosolam »

meiraleal wrote: post #499
kosolam wrote: 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.

Think about this from the perspective of the post. For us since we do use React CLJS and it’s array of libs did became an excess level of abstraction. A wrapper around the JS engine and JS ecosystem - which didn’t bring enough added value for us to justify its use. Typescript didn’t attract me at first but eventually it does bring a lot of added value on top of js and it’s 90% JS anyways. We build hardcore SPAs and the amazing tooling and libs for ts pay off.

Re: We have used too many levels of abstractions

#506

Post by jongjong »

meiraleal wrote: post #489
jongjong wrote: post #185

Earlier quoted context omitted.

I plan to introduce my SDK publicly via the no-code platform I've been working on as a 'low-code' alternative for cases were additional flexibility is required. To give you a rough sense: - My SDK has some front end components and back end components connected via WebSockets using a client/server framework I wrote years ago and have been maintaining. - It's all declarative so for example, for the back end, I don't wr…

> I'm almost at a point where I can build entire complex apps using only HTML on the front end and JSON on the back end with essentially no code. I think you are missing the point of no-code. Your solution isn't even low-code, you just created a framework with well-thought components to start a project. If you need to integrate a third-party component that uses code, you'll need to integrate that code in your HTML/JS…

It's definitely no code. I built some dynamic pages of my service to manage data with it that are all HTML markup and JSON. I would have used it for all pages if I had created the components earlier.

HTML is markup, not code. JSON is object notation, not code. I used very little code to build my service. I think this type of highly flexible low-code is the right path to no-code.

I know from experience that people with zero tech knowledge can be taught HTML and CSS in a few weeks.

Re: We have used too many levels of abstractions

#507

Post by HumanOstrich »

jongjong wrote: post #185
tommybu wrote: post #114

Earlier quoted context omitted.

I am curious about your SDK now. Do you host it publicly? If no, could you at least explain what is the difference between your method and mainstream frameworks?

I plan to introduce my SDK publicly via the no-code platform I've been working on as a 'low-code' alternative for cases were additional flexibility is required. To give you a rough sense: - My SDK has some front end components and back end components connected via WebSockets using a client/server framework I wrote years ago and have been maintaining. - It's all declarative so for example, for the back end, I don't wr…

You might find the paper Out of the Tar Pit interesting if you haven't already read it: https://github.com/papers-we-love/papers-we-love/blob/main/d...

The ideas and approaches you talk about evoked some of the concepts from that paper for me. It talks a lot about separating accidental complexity and infrastructure so you can focus only on what is essential to define your solutions.

Re: We have used too many levels of abstractions

#508

Post by anthk »

pmlnr wrote: post #102

> So what is going to happen when the level of understanding in the tech industry reaches such a low point in which the majority of people don't even know how to fix the tools they are using? Priesthood. See: Foundation by Asimov.

AKA an Space Age retelling of the ending of the Roman Empire and the beginning of the Middle Age.

Re: We have used too many levels of abstractions

#509

Post by HumanOstrich »

bluecheese452 wrote: post #467
hliyan wrote: post #48

In other words, cargo cult programming. I wrote about this two years ago [1] and received only polarised responses that either agreed with the point wholeheartedly, or attacked me viciously for gatekeeping. I wish there was a better way to cure this disease without triggering the professional immune systems of engineers who are highly vested in their favourite technologies. [1] https://medium.com/the-engineering-mana…

I read your blog post in order to understand why you might be getting negative reactions. You are coming across off as combative and arrogant. It feels like you are quizzing people on details in order to show you know more than them.

I disagree. The questions are posed as challenges but are not charged, subjective, or overly pedantic. I also don't see where he's trying to show he knows more than they do in a self-serving way.

Some people choose to interpret any challenge as a personal attack. ¯\_(ツ)_/¯

Re: We have used too many levels of abstractions

#510

Post by syndicatedjelly »

pydry wrote: post #54
EvanAnderson wrote: post #51

Earlier quoted context omitted.

> ...ask a musician if they are really in the weeds of why the instrument is producing music (the physics behind it!). They are probably aware that it's vibrating air, but, in general, they won't know the theory behind it. A big difference is that, unlike computing, their instrument probably won't stop working because of some subtle change to physics introduced by a seemingly-unrelated change made to the universe by…

Musical instruments can and do break for unknown reasons and it's exactly as reasonable to expect musicians to crack out their machine tools to fix them as it is to expect a javascript dev to fix a kernel bug. Computers are a relatively new invention. There are still people around from the times when knowing the entire stack from top to bottom was not just valuable but necessary. They worked during periods when abstr…

To really press on the analogy some more:

- Knowing how to change strings is comparable to knowing how to use the browser console

- Knowing music theory is comparable to understanding programming language theory

- Being competent on the fretboard is comparable to being competent in one programming language. Strumming/fingerpicking could be considered another language.

---

And then for the controversial one...

- Only knowing how to use music-making software is like only knowing how to use low-code applications for development.

dodges tomatoes

Post reply on HN