This is one of my favourite talks ever! Glad to see it here (probably again).
Also, Erlang (non-explicitly) mentioned!
Also, I'm super glad we never got those "APIs" he was talking about. What a horrid thought.
The Future of Programming (2013) [video]
31–40 of 105 posts
Re: The Future of Programming (2013) [video]
#32Earlier quoted context omitted.
The big failure is that we stick with languages designed for computers and not people. A C (or Rust) kernel is a heroic effort that takes man-years to complete. A Lisp one is an end of semester project that everyone builds for their make belief machine (also implemented in Lisp).
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
Re: The Future of Programming (2013) [video]
#33My 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.
Re: The Future of Programming (2013) [video]
#34Earlier quoted context omitted.
>The issue doesn't seem to be performance; it seems to still come down to being too eccentric for a lot of use-cases, and difficult to many humans to grasp. Lisp is not too difficult to grasp, it's that everyone suffers from infix operator brain damage inflicted in childhood. We are in the same place Europe was in 1300. Arabic numerals are here and clearly superior. But how do we know we can trust them? After all DCC…
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.
Re: The Future of Programming (2013) [video]
#35In case, like me, you didn't know who Bret Victor is,
"...Victor worked as a human interface inventor at Apple Inc. from 2007 until 2011." [1]
Re: The Future of Programming (2013) [video]
#36I was greatly inspired by his work. After getting enough skills, I even built my own IDE with live coding and time traveling. Its practical use is questionable, and it seems like nobody is really interested in such tools. Playground: https://anykey111.github.io Images: https://github.com/anykey111/xehw
This is excellent: thank you for pursuing these wonderful ideas.
I wish to have the skills to explain my work as well as Bret Victor does. Editing, reverting, and committing parts of a running program feel alien to users.
Re: The Future of Programming (2013) [video]
#37Earlier quoted context omitted.
The big failure is that we stick with languages designed for computers and not people. A C (or Rust) kernel is a heroic effort that takes man-years to complete. A Lisp one is an end of semester project that everyone builds for their make belief machine (also implemented in Lisp).
How is Lisp performance these days? It was around in the 70’s, right? So I guess the overhead couldn’t be too bad!
Depends on the Lisp, but Clojure is in the same order of magnitude as Java for the most part, and SBCL Common Lisp is one of the fastest GC languages.
Re: The Future of Programming (2013) [video]
#38Earlier 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 could get every hardware manufacturer in the world onboard with such an interface, perhaps. But even if 90% of them were onboard there would be edge cases that people and companies would demand support for and there goes your standard.
Drivers exist to ultimately turn actual hardware circuits off and on, often for highly specialized and performance-critical applications, and are often written based on the requirements of a circuit diagram. So any unified driver platform would also involved unified hardware standards, likely to the detriment of performance in some applications, and good luck telling Electrical Engineers around the world to design circuits to a certain standard so the kernel developers can have it easier.
Re: The Future of Programming (2013) [video]
#39Look at the big brain on Bret!
Re: The Future of Programming (2013) [video]
#40Earlier 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
> Couldn't drivers be built on some abstraction that would simplify some work?
That's like asking the alchemist to publicly publish their manuscripts.
In an ideal world, yes. However, we don't live there. Until a few years ago, GPUs and other drivers were guarded more carefully than the fucking Fort Knox.
Once you publish your drivers, you reveal a part of the inner workings of your hardware, and that's a no-no for companies.
Plus, what the other commenter said - getting hardware guys to design for a common driver interface is probably not gonna get traction.