Back when I was an IT leader running all our internal appdev, I had a "pet" business system that my team used exclusively to write, optimize and rewrite as a testbed and learning environment for new frameworks. It was probably not the most efficient way for me to run the org, but I honestly believe it saved lots of longer term headaches by containing a few potentially terrible decisions to the scope of a single, not-mission-critical app.
We have used too many levels of abstractions
181–190 of 564 posts
Re: We have used too many levels of abstractions
#182I 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…
This comment makes no sense to me.
How is Clojure a layer of abstraction that had to be removed and replaced with Java? What do you think that Clojure was abstracting exactly?
Same question for Typescript. In fact, Typescript is a layer on top of Javascript so I could say that you actually added one more here.
Re: We have used too many levels of abstractions
#183Earlier quoted context omitted.
I'm also self-taught. I've been doing it since (roughly) 2009, and like many others I started at the highest level of abstraction with front-end web dev. I've worked with some mid-level languages like Objective-C and Java, but like you I've never really dug deeper than that. I know this is tired and cliche at this point, but literally this week I sat down with ChatGPT and asked it to teach me how to write WAT (web as…
Very cool! Have you already taken the time to cross-examine the output to ensure it's hallucination-free?
Yeah I was running all the code to validate what it was giving me, but I also try to subtly prompt it to repeat itself so I can see if it’s being consistent.
I’m sure it’s not error-free, but the speed of learning makes up for it IMO. Like I’d been struggling for a while to learn tree-sitter, the documentation is overwhelming. I had a chat with AI and got a working solution for my problem in probably 4-6 hours, and now I can write tree sitter grammars without help. It’s really incredible.
Re: We have used too many levels of abstractions
#184One cause I've seen of this is the "college is not needed to be a coder" trend from the past few years (decade?). it is true that most of my skills were acquired after college, but there is some sort of global system understanding that you get from college (in my case computer+software+network engineering) where you can quickly narrow down potential sources of a problem, all the way down to say, the TCP/IP stack, CPU…
"College" can be extended to include any technical secondary school in societies with dual system education. (i.e. Switzerland, Austria, etc.)
Re: We have used too many levels of abstractions
#185The other thing is that we've adopted the wrong abstractions on many occasions. Today, in the software industry, we have an arrogant mono-culture which believes that we're at the end of history and have figured it all out... But in fact, I believe we've gone down the wrong path with many more recent tech. I feel like everything was moving on the right direction until around 2014... Then it's like progress started goi…
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 write much code, I just declare the models, what fields they have, what views of the data are exposed and specific access controls. The back end is mostly a large JSON object. I don't want to go into too much details but the way it's set up, it's very flexible and you can model almost any kind of data and relationships with little to no code. It guides you towards a good architecture which makes good use of database indexing (so it performs and scales well). To connect the back end models and front end, it's a twist on the old CRUD concept so that it is conflict-free. I went down a completely different path to GraphQL and I think the result is simpler, more efficient, provides better access control, simpler caching and code (or should I say markup/JSON) is much easier to read and maintain. As you build your system using it, it guides you into making optimal architectural decisions at every step, keeping complexity as low as possible (as opposed to GraphQL which, by virtue of its extreme flexibility allows complexity to grow out of control).
- The front end components provide ways to render lists and objects in complex ways (e.g. grouped, filtered based on relationships between different models; all declarative). Components are hooked into the model backend in a particular way so they update in real time by default. Real time updates are delivered to the front end efficiently. Only relevant components/views update themselves and they do so automatically. Pagination is automatic and specified declaratively as part of the HTML and in accordance to limits specified in the back end JSON. Access control is enforced automatically based on the rules specified on the back end in the JSON object.
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.
Re: We have used too many levels of abstractions
#186Earlier 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.
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 understanding the type of operators and the axioms of maths. The child was perfectly find completing maths problems without that depth.
Re: We have used too many levels of abstractions
#187I think there is one interesting angle to this problem. I am someone who grew up with the technology, as the levels of abstractions were being added. I am now benefiting from all those accumulated decades of knowledge. As the IT / development world was changing, I had enormous privilege and comfort to learn the things at the pace they were happening. Being able to assimilate changes over long decades. Be a witness to…
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…
Speaking as one of those guys, the first computer I programed on was a Timex 2068, a reality check is discussing industry events and noticing a bunch of clueless faces among junior devs.
Re: We have used too many levels of abstractions
#188Earlier quoted context omitted.
> spending a decade working with a low level programming language before you jump into high level programming language is simply not an option. Nobody said that. But spending a week is definitely an option to all programmers, and many would benefit from it.
Do you have any ressources to share ? I am a self taught developer, I do stuff at my level (typescript, lisp), also because when you work alone, such high level languages allow you to express things nicely and fast . I kinda know how a cpu works, I understand what is going on when you perform some bare metal programming, but I never barely went down the rabbit hole and performed some low level stuff. I'm in the situa…
This is a 30min talk that I keep coming back to:
Python, Linkers, and Virtual Memory by Brandon Rhodes (Python core dev)
https://www.youtube.com/watch?v=twQKAoq2OPE
(Most of the content is not actually specific to Python)
He beautifully pulls back the curtain on so many lower level concepts like virtual memory management, dynamic linking, heap/stack, fork(), copy-on-write.
The talk is broad in nature, not deep. It takes you just below the surface of many magic black boxes, and, as you put it, enhances your proximity with those topics.
For me, so many things clicked in this single talk:
- How virtual memory works (incl. paging in/out, swapping)
- Why there's those discrepancies between RSS / PSS
- What segfaults and page faults are
- What actually happens when I get errors related to dynamically linked libraries, either at build time or runtime
- Actually understanding the output of top / ps
Re: We have used too many levels of abstractions
#189I think there is one interesting angle to this problem. I am someone who grew up with the technology, as the levels of abstractions were being added. I am now benefiting from all those accumulated decades of knowledge. As the IT / development world was changing, I had enormous privilege and comfort to learn the things at the pace they were happening. Being able to assimilate changes over long decades. Be a witness to…
I am exactly the same, coming from making my own add on boards for early PCs and programming in machine codes and then following tech as it developed. Yes it is hard to find young persons with the same level of understanding but they do exists.
Re: We have used too many levels of abstractions
#190I think there is one interesting angle to this problem. I am someone who grew up with the technology, as the levels of abstractions were being added. I am now benefiting from all those accumulated decades of knowledge. As the IT / development world was changing, I had enormous privilege and comfort to learn the things at the pace they were happening. Being able to assimilate changes over long decades. Be a witness to…
Where do we draw the line though? Surely those proficient in low level programming languages don't then need to become proficient in building motherboards from scratch?