Transparent Like Frosted Glass | Hacker News Reader

Transparent Like Frosted Glass

explaining.software

40 pointstodsacerdoti25 comments

Reminds me of similar concerns around understanding our infrastructure systems and the built environment.

In the Industrial Revolution through New Deal days, innovations were coming and going, and novel and exciting for the time, but still based on simple enough principles that most people understood the basics of the emerging technologies even if they had to be reminded of the dangers. Nowadays I imagine it'd be hard for someone to give a cogent answer to the question "where does your trash go when the garbage people pick it up?"

This isn't to promote some "kids these days" narrative but rather to help us understand how layers of complexity and nuance are added on top of existing technologies relatively quickly.

Simple, effective systems are attractive because they can be comprehended. Complex, gargantuan systems are attractive because of the monumental amounts of resources they can coordinate.

Still, as then, it is today a civic duty to understand your contributions to the systems you inhabit and to act as a good faith steward for the sustainability and efficacy of those systems.

To me one of the biggest changes was LPs and then CDs to flash drives for portable data storage (now just cloud). With an LP you can actually see the grooves and how the stylus rides in it. You can hear the vibrations, if you listen closely, and imagine how the sound is recorded (even for stereo). With CDs you can still see the diffraction patterns and grooves, even if it takes a microscope to spot the little pits and the little lasers are invisible, and there was a metaphor to LPs (where for a short time there were laser stylus as well).

Now it's just black boxes. Shove it in and magic happens. You're not going to figure out a multilayer high density flash even if you have an ion beam cutter and an electron microscope. Your best bet is figuring out the electrical protocol on the USB, though with multi-level differential embedded clock 40Gb/s links that's almost hopeless. I feel a bit sad for those just learning how things work. Software is the only system "simple" enough to wrap your head around, and that has just allowed the actual implementations to be ever more complex.

But isn't most hardware today defined using "software", with desired logic coded in Verilog or VHDL and then just realized using billions of tiny transistors?

I’m a senior citizen and I couldn’t enjoy the end of LPs and cassettes fast enough. LPs scratched and skipped and wore down. Cassettes stretched and broke and wore down. I thrill to the idea that I can get a perfect rendition of the bits every time (modulo lossy compression or poor remastering).

I don't think anybody's disagreeing that you get better audio reproduction and less fragility from CDs. Just that they aren't learnable or hackable, and learners and hackers lose something (something separate, and maybe even less valuable, than audio reproduction but still something of value)

The abstraction of individual contributions is problematic when you end up with huge swathes of rent extraction justified by capitalist meritocracy. As a society, we don't need so many (any?) of our best and brightest wrangling zero-sum financial algorithms, yet that's where we are. These very clever people basking in their smug wealth whilst the poors outside actually dig up the streets to repair the water mains or produce the food they eat.

> "average application engineer"

Boy, that brings back memories. In The Days of Yore, there was an implicit caste system, where "application engineers" were considered "lesser beings."

Having done both systems engineering, and application engineering, I like application engineering, a lot more. I don't particularly care, whether or not anyone looks down their nose at me.

I always find it funny how engineers have a caste system. Systems engineers look down their noses at application engineers, everyone looks down at web developers. But it used to be that mechanical engineers looked down at electrical engineers, who looked down at all software engineers. I like to imagine a Roman engineer judging a medieval siege engineer by whether they can build an aqueduct or not, and the siege engineer judging a Victorian civil engineer by whether they know how to make a simple, run of the mill catapult.

Why are web devs at the bottom of this totem pole? It's a very multi-disciplinary job, often requiring expertise in a handful of languages, UI, design, distributed systems, etc.

Web devs, these days, are a very different animal, from the old HTML jockeys.

Most rich Web sites, nowadays, have quite a bit going on (and that is often reflected in massive page loads).

I don't think they should be, and I don't think that belief is as prevalent anymore. But when I was starting out, there was a real divide even between people who wrote server code and people who wrote front end code for the same product, let alone among programmers who worked on lower level or more abstract things. I assume because the web jobs were newer, and more people back in the 90s-00s had moved into those jobs from places other than the traditional CS or engineering professional tracks. But I always felt like web development was really, really hard to be good at.

Web dev looks sort of like graphic design without the artistry, from an outside point of view.

Depends what you’re making. And there’s a lot of non UI technical work.

When doing an EE undergrad, the ranking I saw was:

ChemE > EE > MechE > Civil.

I guess there could be a bias, maybe MechE’s would swap their spots and ours. But I don’t think it is a totally universal thing. The fact that ChemE was some impossibly difficult magical alchemy stuff that nobody outside of their program could understand was universally agreed upon though.

I mean, it’s all goofy inter-field teasing and anybody who takes it too seriously is a dummy anyway.

I would say that civil engineers probably have more on the line, than anyone else. They can kill people, and go to jail, more often, than any of the others (where doing so is more of an exception, and with civil engineers, it's the norm).

That’s probably why they don’t do anything cool. :p

Arguably that's part of why that order might be the way that it is: Civil Engineering has existed long enough to have criminal liability and defined jail terms. The others are younger (sometimes far younger) and much less experienced with things like the justice system (and the justice system less experienced with them in turn).

Current EE undergrad (one semester left) and my university doesn't have ChemE so I'm sitting comfortably at the top of the chain :^)

The article starts with Sherry Turkle, who is a genius IMHO. She discusses transparent versus opaque, in terms of computers, and is quoted in the NY Times about it.

https://www.nytimes.com/1995/12/07/books/books-of-the-times-...

Ms. Turkle adds two computers to the list of test objects: two contrasting machines, the I.B.M. PC and the Macintosh. The former, she explains, was for users who wanted to see into "'the guts' of the machine." It was transparent and invited analysis.

"In contrast the 1984 introduction of the Macintosh's iconic style presented the public with simulations (the icons of file folders, a trash can, a desktop) that did nothing to suggest how their underlying structure could be known." It was opaque, and invited a belief in what William Gibson, in his novel "Neuromancer" (1984), termed "cyberspace." ...

One therefore pays close attention when she explains how the shift to postmodernism has been reflected in a new outlook on artificial intelligence. No longer are designers striving for an overarching theory of mind. More and more they see hope in computers that can learn, or what she terms "emergent A.I.," which, as she writes about it, accords with the fragmented, "decentered" self posited by postmodernism.

(If you're curious to know more about Dr. Turkle, this TED talk is good IMHO: https://www.youtube.com/watch?v=MtLVCpZIiNs)

I cite her from time to time: taking things at "interface value..."

I’m not a fan of the way this presents interfaces. It’s quite nebulous, and despite coming close to the mark, it doesn’t appropriately distinguish between data and transport. It seems like what it’s trying to get at is that you can ignore how transport works in an exchange of data, sometimes, right up to the point where it turns into a problem.

The point is that an interface should help you to both ignore and understand the underlying implementation. I'm not sure I understand your point about data and transport, since most interfaces (e.g. names) don't touch the network. Are these just synonyms for interface and implementation?

I bring it up because the author was talking about network transparent APIs, where the developer doesn’t have to care about whether the call goes over the network. But of course this is not something you can actually afford to ignore. It’s quite a different concern from the data exchange that happens between application and API, however.

Yes, and that is used as an example for the general point: a network transparent API doesn’t help us understand the network when it inevitably fails.

I was on a project once that developed an IPC API based on remote procedure calls. The first thing they did was hide the RPCs, precisely for this reason. And the second thing they did was ditch the RPCs in favor of TCP/IP socket reads and writes, because once you hide them the RPCs don’t buy you anything but headaches. Bye bye DCE.

Reply on news.ycombinator.com