Live data from Hacker News

We have used too many levels of abstractions

unixsheikh.com

401–410 of 564 posts

Re: We have used too many levels of abstractions

#401

Earlier quoted context omitted.

I have worked with interns and young devs just out of school who are sharp as tacks. I had an intern a few years ago, the first task we paired on was to figure out why our MySql connections from Qt were misbehaving. We stepped through the application code, the Qt code, found where it was failing, and ended up backporting a Qt patch from upstream to fix it. Yes, I gave him some guidance, but once he caught on he was a…

I’ve worked with around a dozen interns/co-ops, and only 2 stood out to me. The rest often made me wonder if they could reasonably handle this kind of career. I hope they could! It’s tough if you feel a degree of responsibility for their success. Mentors are one of your greatest assets early on (and arguably later as well), and to try hard to have them succeed and thrive only to see them languish on trivial tasks is…

Maybe a difference between then and now is that "back in my day" CS still wasn't considered to be a "hot" college major. And there was believed to be more flexibility in choice of a major relative to whether you could get a decent job.

Today, there are probably a vast number of entrants who heard that CS is the ticket to a high paying job, and they are also told that an internship is a vital bullet point on their resume, if not a guarantee of a job at the internship site.

Then, as now, students studied under the constant drone of "you will never use this stuff once you finish college." They still have to decide if they're actually interested in the subject matter or not.

A good bellwether of career interest is the students in the youth symphony. They've all aced every subject in high school, plus rocket club, gentleman sports, and orchestra. The program for the end-of-season concert will have a little bio for each graduating senior, including their college interests. Half of these kids want to major in CS.

Re: We have used too many levels of abstractions

#402

At a certain point software engineering may come to resemble medicine more than mathematics, where the lower layers of operation are known to be poorly understood and innovations emerge from tinkering rather than derivations from first principle.

It seems like many important innovations we use today were derived from first principle.

Rust uses algebraic datatypes with ML-style type condtructors and Hindley-Milner type inference to achieve, for example, types like Option> or Option or Option, so that you're forced to check for the case of a null pointer (None), and if it's not in an Option, then it's guaranteed not to be null. This was originally conceived of mathematically in the 1980s and then implemented in ML.

The Hindley Milner type system was devised in 1969 from the typed lambda calculus.

Golang was influenced a lot by Communicating Sequential Processes, a formal system for describing concurrent behavior in systems, first described in 1978 by Tony Hoare.

Graph theory is a field of math that comes up a lot in computer science, in marketing, networking, compilers (register allocation and functional programming language interpretation).

The only innovation I can think of that came purely from tinkering is Rust's borrow checking system, and they're still trying to formalize that while improving it.

Derivations from first principle are always important.

Re: We have used too many levels of abstractions

#403

The future looks especially bleak because LLMs, for many who I work with, are doing with logic what Google did with memory. 'Just ask chatgpt' will be a thing ; maybe not chatgpt, probably indeed just google but with a their chatbot which can do 'logic' and abstractions built in. Google -> you don't need a longterm memory, just Google it. So with good LLMs (and the latest iteration of chatgpt is really good at a lot…

While I agree with you that programmers increasingly relying on LLMs would be (is?) a problem, there is an element of neo-Luddism to this, as was excellently framed by xkcd[1] some years ago. Could we not choose to fill all that time we used to spend writing code on testing/verification instead? Or on performance, or documentation, or security? Or, to go back to the premise of the blog, on re-educating ourselves in the tools we use every day but don't actually understand? I don't know how the industry will adapt and I won't bother making predictions, but the future doesn't necessarily involve everyone becoming mindless code monkeys.

[1]: https://xkcd.com/1227

Re: We have used too many levels of abstractions

#404
Speaking of failures traceable to levels of abstraction.

"The hacking was rather discrete and would most likely never had be discovered where it not ..." should be "The hacking was rather discreet and would most likely never been discovered were it not ...".

The abstraction at fault here? Spell checkers. It's not enough to know how to look for the squiggly red lines under words, it's necessary to know what words mean. As Jerrold H Zar put it:

    Eye halve a spelling check her,
    It came with my pea sea.
    It plane lee marks four my revue
    Miss steaks aye kin knot sea.
https://arnold.hosted.uark.edu/Other/ZarOde.pdf

Re: We have used too many levels of abstractions

#405

Earlier quoted context omitted.

When I was at Fog Creek, we still had that as an interview question (with googling allowed). It was a good judge of how most folks approached something they used but didn’t necessarily understand. If the applicant already knew how to do it, that was a different signal as well.

Think ChatGPT would be allowed nowadays? It’d be my source for something so esoteric. I haven’t bothered to learn mail protocols because any message you send will be marked as spam unless it’s from a major provider.

No idea, but if it was available back then, we’d have been looking for whether you are critical about what it tells you and how you verified it was correct. That was a main idea behind the interview.

Re: We have used too many levels of abstractions

#406

We’re going to be so fucked when the people who develop things like the linux kernel die. There are no upcoming people with that level of knowledge.

this kind of alarmism is ridiculous. the new layers of abstraction have not made programmers dumber, they have added more programmers to the stack. we still have and will have people designing kernels and CPUs for fun.

Do we? It seems like there are some people developing Unix clones for fun, and building their own RISC-V or 6502 CPUs. We don't have much innovation in OSes from amateurs, though. At least there's sel4, which is formally proven to follow a certain spec that makes some security guarantees.

Re: We have used too many levels of abstractions

#407

Earlier quoted context omitted.

You can actually see this with new frontend devs. They know only full SPA frameworks, they have never seen a dump of an HTTP message, headers and verbs are abstract things to them. Hell, many of them don't know you can have fully functional websites with zero JS, including payment, video, login, etc. I started to write an HTMX tutorial ( https://www.bitecode.dev/p/a-little-taste-of-htmx-part-1 ) because I noticed a l…

> they have never seen a dump of an HTTP message, headers and verbs are abstract things to them. When I was teaching programming, I had a fun party trick whenever we got to HTTP. I'd fire up netcat (in listen mode), then connect from a web browser and "serve" a website by hand. I'd show the students the HTTP request that came in, and just manually type out a simple HTTP response and they'd see it appear live in the b…

Yeah I used to occasionally debug and test some things by writing manual HTTP requests over telnet, and it is something I’ve noticed new devs often just don’t get how approachable HTTP/1.1 is. Even if they have worked with headers and methods, there still seems to be a lot of magic happening in their minds.

Unfortunately chrome has stopped showing cookie headers in the network tab. You have to look somewhere else for those, and I think at that point you’re just seeing the current cookies, not the raw headers. Maybe there’s a security reason for that, but it is a further abstraction layer of “we’ll present the information a certain way” rather than “we’ll just show you all the information that the server sent back” that I expect will grow into other headers (maybe already has) and further remove us from seeing the raw details and having a clear understanding of what’s happening under the hood.

(You know it’s possible HTTP/3 cookies are even passed in a different way under the hood from other response headers, and that could be part of why they’ve separated them out. I hadn’t considered that possibility.)

Re: We have used too many levels of abstractions

#408

Earlier quoted context omitted.

>as a result, we've had unbelievable amounts of "wheel reinvention". During the crypto boom I distinctly remember hearing someone say something about creating a decentralized Discord. I was like... that's IRC.

I guess, if you also remove almost all of the features of discord.

Now I wonder if you ever used IRC or if you have a vastly different use of Discord than me.

Re: We have used too many levels of abstractions

#409

Earlier quoted context omitted.

"Who cares? " You are proving my point. You should care.

Why? I’d rather care about ML. My point is that your question is some esoteric gotcha party question that may as well be out of Trivial Pursuit. But you’re treating it like anyone who doesn’t care is just being a bad engineer. There are countless ways engineers spend their time, and choosing what to work on is the most important choice of their careers. It’s on you to justify the claim that knowing the difference bet…

The issue isn’t that every single person in the IT field needs to know HTTP in detail. The issue is that people who have invested in training for a role and are applying for a role do not understand fundamental technologies that are essential to that role.

For you that would be trying to work in ML not understanding any of the theory or how it works, but having used OpenCV with some premade models a few times.

For a frontend web developer who, as a large part of their role, will need to communicate with backend systems… that’s not understanding how their FE web application actually communicates with BE systems.

And from experience… yes, this is very common. And it has a noticeable impact on their effectiveness. Trying to debug why some interaction between your application and the BE application isn’t working while thinking the dev tools network inspector is just black magic and nonsense makes your job substantially more difficult.

This does make these people bad engineers. They are not able to understand and solve a huge class of the problems that they face day-to-day and instead (in my experience) often fall back on “just try a bunch of different things until something works for reasons I don’t understand” which is a poor way to approach work and leads to overly complex, buggy, brittle systems.

Re: We have used too many levels of abstractions

#410

“Everything in the tech industry is driven with a very hardcore eye for profit and very little interest in anything else” What is up with the discourse lately - of course it’s all about the profits - we’re talking about companies right not non-profits? How else are they going to pay you? The whole “expecting companies to care about so many things” apart from profit seeking mindset is just bizarre to me

Not all profit is created equal. Sometimes in order to chase greater short-term rewards, you sacrifice your access to long-term rewards. Pushing your dev team into unsustainable practices may increase next quarter's profits, but might also mean that your company is bankrupt 2 years from now.

I would amend what the author wrote to say that a lot of stuff is being driven with an eye for short-term profit, at the expense of long-term value.

Post reply on HN