Hacker News new | ask | show | jobs
by LAC-Tech 952 days ago
I maybe could have done a better job of what so captivated me watching the 'The Computer Programme' and why that feeling's so different today. The idea of ordinary people buying a computer and programming it to do useful things was one. Personal address books was covered in an episode - that's gone. There was the implicit assumption that your machine and your data was your own.

As for specific technologies, here's my rough list of what we're either starting to forget, had to re-remember recently, or have completely forgotten:

- low latency, simple, native UIs that don't require a designer

- operating on data locally first, and not over a network

- information highway instead of doom-scrolling

- message passing (constantly re-discovered, and then forgotten because people complain it's not RPC)

- relational and logic programming - I firmly believe this will come back one day, but it will be called something else and look new.

- static memory allocation. turns out it's still incredibly fast to do this.

- software design

7 comments

> low latency, simple, native UIs that don’t require a designer

This is very much alive for internal tools, but the importance of design from a product perspective has proven important, which is why you don’t see much in products anymore.

> information Highway instead of doom-scrolling

Those are just buzzwords, what exactly do you mean by this?

> relational and logic programming

SQL is alive and well, granted newer programmers don’t learn it as early as they should

> static memory allocation

I’d like to hear more of your thoughts on this as well. We’ve found that this kind of memory allocation is error prone especially in multithreaded workloads, which is why it’s not as popular

> software design

Another buzz term. Software is constantly designed and the design of software is constantly discussed. What exactly do you mean by this? Who forgot what?

This is very much alive for internal tools, but the importance of design from a product perspective has proven important, which is why you don’t see much in products anymore.

This is revisionist history. Desktop environments had become so complex and fragmented that just writing HTML & CSS seemed incredibly appealing. "the importance of design from a product perspective has proven important" is unsubstantiated, and is justification after the fact.

Those are just buzzwords, what exactly do you mean by this?

A focus on information vs a focus on 'engagement'. Knowledge vs addiction. Feeling better after using a computer as opposed to feeling worse.

SQL is alive and well, granted newer programmers don’t learn it as early as they should

Unfortunate use of words on my behalf, see: https://news.ycombinator.com/item?id=38243753

static memory allocation

The tigerbeetle database is all statically allocated and (as I understand) makes no memory allocations as a response to use requests. They seem to be having great success with this approach.

https://tigerbeetle.com/blog/a-database-without-dynamic-memo...

Another buzz term. Software is constantly designed and the design of software is constantly discussed. What exactly do you mean by this? Who forgot what?

I don't feel like this is a buzz term. Agile or whatever one wants to call sprint based work flows means no serious design gets up front anymore, and so we constantly try and code our way out of anemic or non-existent designs.

1. There’s nothing revisionist. Game developers constantly make small internal tools using native UI toolkits. I don’t understand how you could think good design being good for a product is unsubstantiated. You’re arguing in bad faith there. Apple’s entire business model is selling their product design over capability. It’s obviously important.

2. That’s fair.

3. This looks interesting, but also very academic. Did that pattern ever see wide production usage?

4. A single project both doesn’t refute my point and refutes yours.

5. That just isn’t true. There’s room for good design. We do technical specs where I work along with some agile methodology. We just recognize that time spent hammering designs up front rarely produces better or more maintainable results in the same amount of time. Though I suspect this is very domain dependent.

>- information highway instead of doom-scrolling

It's really interesting to read about the vision that drove Douglas Englebart (inventor of the computer mouse, did the "Mother of All Demos" where he introduced a bunch of modern computing tech for the first time). Englebart was a hippie who envisioned a future where researchers used the tools he was creating to collaborate remotely and work to solve complex problems. His tagline was "Boosting Our Collective IQ"

Well that is one of uses of the modern internet. Just a very small one..
> I firmly believe this will come back one day, but it will be called something else and look new.

It's called SQL, and it's pretty big and you can get paid a lot for being good at it.

I meant relational programming in the sense that William E. Byrd uses it, as something like a close cousin or a different way of looking at logical programming

miniKanren is being used for research in "relational" programming. That is, in writing programs that behave as mathematical relations rather than mathematical functions. For example, in Scheme the append function can append two lists, returning a new list: the function call (append '(a b c) '(d e)) returns the list (a b c d e). We can, however, also treat append as a three-place relation rather than as a two-argument function. The call (appendo '(a b c) '(d e) Z) would then associate the logic variable Z with the list (a b c d e). Of course things get more interesting when we place logic variables in other positions. The call (appendo X '(d e) '(a b c d e)) associates X with (a b c), while the call (appendo X Y '(a b c d e)) associates X and Y with pairs of lists that, when appended, are equal to (a b c d e). For example X = (a b) and Y = (c d e) are one such pair of values. We can also write (appendo X Y Z), which will produce infinitely many triples of lists X, Y, and Z such that appending X to Y produces Z.

https://stackoverflow.com/a/28556223

Thanks for the reply! I hope it didn't sound like I was insinuating that you did a bad job, I was just curious what concepts others would bring up in a discussion about your article's thesis. It was a good read! I look forward to more.
I think the big issue is that the stuff that already exists has so many features and so many ecosystem integrations, nobody wants to use anything simple enough to DIY.

It would be easier then ever to make a simple address book, but it wouldn't do everything Google does.

The other issue is that we never really got a proper upgrade from spreadsheets. I think you could do a VB-like studio that let average people make modern apps that they'd actually want to use, if it was free, as easy as a spreadsheet, and a cross platform local app, not something self hosted, and had a ton of random features that would interest users.

As a minor point I'd say a UI always needs good design, even more so the more minimal it is. UX matters and I'm disappointed how many developers treat it as just "making things pretty."
Yes perhaps I should choose my words more carefully.

What I was more getting at is the lost idea of a 'set piece' UI we can use to quickly make things that look nice - rather than re-inventing the wheel with styling.

Like imagine if the default browser styling was good enough, and only people with particular artistic flair needed to bother with CSS or component libraries or what have you.

This is absolutely true. Said another way industry is nearly exclusively focused on designing the visual - to the detriment of everything else.

Design goes far beyond the visual.

> The idea of ordinary people buying a computer and programming it to do useful things was one.

First program I ever wrote (I was a kid) was a program to help my mum manage the household accounts, it even loaded and saved data to a cassette.

Bless her she used it - it had to be multiple times slower than just doing it in her notebook (paper not computer, this was the 80's).

Even then a couple of things became obvious, I was gonna be a programmer and I was more inclined to solving practical problems than games.