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

The Future of Programming (2013) [video]

youtube.com

Post reply on HN
Print view View original

41–50 of 105 posts

Re: The Future of Programming (2013) [video]

#41

Post by ModernMech »

jtwaleson wrote: post #33
ModernMech wrote: post #23

My unpopular opinion is if we had just done a lot of the stuff Bret has been talking about for 10 years -- investing in better developer tooling -- we could have realized productivity gains better than what AI provides without having to spin up massive data centers. Unfortunately "dev tools" don't get funding today unless they're "AI dev tools".

Agreed, but: I know a couple of players in the "Enterprise Low-Code" space, who have invested heavily in deeply integrated development environments (with a capital I) and the right abstractions. They are all struggling with AI adoption as their systems "don't speak text". LLMs are great at grokking text based programming but not much else.

To me, enterprise low code feels like the latest iteration of the impetus that birthed COBOL, the idea that we need to build tools for these business people because the high octane stuff is too confusing for them. But they are going the wrong way about it; we shouldn't kiddie proof our dev tools to make them understandable to mere mortals, but instead we should make our dev tools understandable enough so that devs don't have to be geniuses to use them. Given the right tools I've seen middle schoolers code sophisticated distributed algorithms that grad students struggle with, so I'm very skeptical that this dilemma isn't self-imposed.

The thing about LLMs being only good with text is it's a self-fulfilling prophecy. We started writing text in a buffer because it was all we could do. Then we built tools to make that easier so all the tooling was text based. Then we produced a mountain of text-based code. Then we trained the AI on the text because that's what we had enough of to make it work, so of course that's what it's good at. Generative AI also seems to be good at art, because we have enough of that lying around to train on as well.

This is a repeat of what Seymour Papert realized when computers were introduced to classrooms around the 80s: instead of using the full interactive and multimodal capabilities of computers to teach in dynamic ways, teachers were using them just as "digital chalkboards" to teach the same topics in the same ways they had before. Why? Because that's what all the lessons were optimized for, because chalkboards were the tool that was there, because a desk, a ruler, paper, and pencil were all students had. So the lessons focused around what students could express on paper and what teachers could express on a chalk board (mostly times tables and 2d geometry).

And that's what I mean by "investment", because it's going to take a lot more than a VC writing a check to explore that design space. You've really gotta uproot the entire tree and plant a new one if you want to see what would have grown if we weren't just limited to text buffers from the start. The best we can get is "enterprise low code" because every effort has to come with an expected ROI in 18 months, so the best story anyone can sell to convince people to open their wallets is "these corpos will probably buy our thing".

Re: The Future of Programming (2013) [video]

#42

Post by floppyd »

The non-linear code structure (including visually) is something I've been thinking about for a long time and arrived at very naturally. I'm the "spread all the papers on the table to take in every interaction all at once" type of person, and so often I imagined a code editor that would allow me to just "cut" a piece of code and move it to the side. Separating stuff into files is kinda this, but it's not visual and just creates a lot of mess when I try to separate out small functions that are not reusable somewhere else. I don't even need the underlying non-linearity — just let me move the papers around on my code desk!

Re: The Future of Programming (2013) [video]

#43

Post by acedTrex »

blue_pants wrote: post #32
jane2plane wrote: post #28

Earlier quoted context omitted.

A toy C kernel is also an end of semester project. What makes real kernels take man years to complete is the hardware support, the majority of Linux source code is drivers - the endless tables of hardware register definitions, opcodes and state machine handling.

But couldn't we do something about that as well? Couldn't drivers be built on some abstraction that would simplify some work? I have zero knowledge about this area though

I'm sure the hardware folks will be lining up to cooperate with the annoying software engineers giving them abstract constraints lol

Re: The Future of Programming (2013) [video]

#45

Post by Legend2440 »

cfiggers wrote: post #6
LAC-Tech wrote: post #2

Probably my favourite tech talk of all time. I did at least read the actor model paper! (though the 1973 one doesn't say much, you want the one with Baker, "Laws for Communicating Sequential Processes". I still don't know what he means about not liking APIs though. "Communicating with Aliens", what insight am I missing?

When two humans want to talk but don't speak a shared language, if they spend enough time together, they will figure out how to communicate eventually. But when two computers want to talk to each other and don't speak a "shared language" (aka, the client specifically must conform to the server's "language"—it's very one-sided in that sense) then no amount of time will allow them to learn one another's rules or settle…

There are ML architectures that can do that. The two halves of an autoencoder learn a “shared language” that allows them to communicate through a bottleneck.

Re: The Future of Programming (2013) [video]

#46

Post by pjmlp »

jtwaleson wrote: post #33
ModernMech wrote: post #23

My unpopular opinion is if we had just done a lot of the stuff Bret has been talking about for 10 years -- investing in better developer tooling -- we could have realized productivity gains better than what AI provides without having to spin up massive data centers. Unfortunately "dev tools" don't get funding today unless they're "AI dev tools".

Agreed, but: I know a couple of players in the "Enterprise Low-Code" space, who have invested heavily in deeply integrated development environments (with a capital I) and the right abstractions. They are all struggling with AI adoption as their systems "don't speak text". LLMs are great at grokking text based programming but not much else.

As someone that recently started to look into that space, that problem seems to be being tackled via agents and MCP tooling, meaning Fusion, Workato, Boomi, and similar.

Re: The Future of Programming (2013) [video]

#47

Post by ModernMech »

blue_pants wrote: post #32
jane2plane wrote: post #28

Earlier quoted context omitted.

A toy C kernel is also an end of semester project. What makes real kernels take man years to complete is the hardware support, the majority of Linux source code is drivers - the endless tables of hardware register definitions, opcodes and state machine handling.

But couldn't we do something about that as well? Couldn't drivers be built on some abstraction that would simplify some work? I have zero knowledge about this area though

Somebody somewhere has to do the work of making sure everything works together. Right now that's the OS. You're proposing moving that work to a standards committee. Either way, the problem persists. You either do that or go the Apple way which is to vertically integrate the wholes stack from hardware to software, but then you have Apple's problem, which was lower hardware compatibility.

Re: The Future of Programming (2013) [video]

#48

Post by zwp »

floppyd wrote: post #42

The non-linear code structure (including visually) is something I've been thinking about for a long time and arrived at very naturally. I'm the "spread all the papers on the table to take in every interaction all at once" type of person, and so often I imagined a code editor that would allow me to just "cut" a piece of code and move it to the side. Separating stuff into files is kinda this, but it's not visual and ju…

You might like https://cs.brown.edu/~spr/codebubbles/

Re: The Future of Programming (2013) [video]

#49

Post by ssrc »

blue_pants wrote: post #32
jane2plane wrote: post #28

Earlier quoted context omitted.

A toy C kernel is also an end of semester project. What makes real kernels take man years to complete is the hardware support, the majority of Linux source code is drivers - the endless tables of hardware register definitions, opcodes and state machine handling.

But couldn't we do something about that as well? Couldn't drivers be built on some abstraction that would simplify some work? I have zero knowledge about this area though

If you are ok with the performance you can obtain from an FPGA, you could do it now. Look at FPGA hardware-software co-design and related stuff.

If you mean, in general, for the hardware that already exists, that's what the HAL (Hardware Abstraction Layer) of the operating system tries to do.

Re: The Future of Programming (2013) [video]

#50

Post by nerdponx »

pjmlp wrote: post #34
nerdponx wrote: post #27

Earlier quoted context omitted.

It's not about prefix notation, it's that the fully uniform syntax has legitimate ergonomic problems for editing, human reading, and static analysis. Sexprs are better for computers than for humans in a lot of ways.

Only when not using one of the many Lisp editors that exist since Lisp Machines (Symbolics, TI), Interlisp-D (Xerox), that survive in Emacs SLIME, Cursive, LispWorks, Allegro Common Lisp, Raket, VSCode Calva.

Not true at all IMO. Reading code is reading code regardless of whether you have a fancy IDE or not.

S-expressions are indisputably harder to learn to read. Most languages have some flexibility in how you can format your code before it becomes unreadable or confusing. C has some, Lua has some, Ruby has some, and Python has maybe fewer but only because you're more tightly constrained by the whitespace syntax. Sexpr family languages meanwhile rely heavily on very very specific indentation structure to just make the code intelligible, let alone actually readable. It's not uncommon to see things like ))))))))) at the end of a paragraph of code. Yes, you can learn to see past it, but it's there and it's an acquired skill that simply isn't necessary for other syntax styles.

And moreover, the attitude in the Lisp community that you need an IDE kind of illustrates my point.

To write a Python script you can pop open literally any text editor and have a decent time just banging out your code. This can scale up to 100s or even 1000s of LoC.

You can do that with Lisp or Scheme too, but it's harder, and the stacks of parentheses can get painful even if you know what you're doing, at which point you really start to benefit from a paren matcher or something more powerful like Paredit.

You don't really need the full powered IDE for Lisp any more than you need it for Python. In terms of runtime-based code analysis Python or Ruby are about on par with Lisp, especially if you use a commercial IDE like Jetbrains. IDEs can and do keep a running copy of any of those interpreters in memory and dynamically pull up docstrings, look for call sites, rename methods, run a REPL, etc. Hot-reloading is almost as sketchy in Lisp as it is in Python, it's just more culturally acceptable to do it in Lisp.

The difference is that Python and Ruby syntax is not uniform and therefore is much easier to work with using static analysis tools. There's a middle ground between "dumb code editor" and "full-power IDE" where Python and Ruby can exist in an editor like Neovim and a user can be surprisingly productive without any intelligent completion, or using some clunky open-source LSP integration developed by some 22 year old in his spare time. With Lisp you don't have as much middle ground of tooling, precisely because it's harder to write useful tooling for it without a running image. And this is even more painful with Scheme than with Lisp because Scheme dialects are often not equipped to do anything like that.

All that is to say: s-exprs are hard to deal with for humans. They aren't for humans to read and write code. They never were. And that's OK! I love Lisp and Scheme (especially Gauche). It's just wrong to assert that everyone is brain damaged and that's why they don't use Lisp.

Post reply on HN