Live data from Hacker News

The Future of Programming (2013) [video]

youtube.com

21–30 of 105 posts

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

#21
post #17

Earlier 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!

Considering how much of modern software is written in JavaScript and python, I have a hard time seeing how lisp overhead would pose much of a problem. Erlang is good enough for telecom equipment for 30 years ago, so that also gives us a data point.

If entertain the idea that the Von Neuman architecture may be a local maxima, then we can do even better; lisp machines had specialized instructions for lisp which allowed it to run at competitive performance to a normal programming language.

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.

- https://en.wikipedia.org/wiki/Erlang_(programming_language)

- https://en.wikipedia.org/wiki/Lisp_machine

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

#22
post #11

I love Bret Victor and believe he has some very important things to say about design (UI design, language design and general design) but a lot of his concepts don't scale or abstract as well as he seems to be implying (ironic because he has a full essay on "The Ladder of Abstraction" [0]). He makes some keen observations about how tooling in certain areas (especially front end design) is geared towards programmers ra…

The solution to seeing more Bret Victor-ish tooling is for people to rediscover how to build the kind of apps that were commonplace on the desktop but which have become a very rare art in the cloud era.

Direct manipulation of objects in a shared workspace, instant undo/redo, trivial batch editing, easy duplication and backup, ... all things you can't do with your average SaaS and which most developers would revolt for if they'd had to do their own work without them.

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

#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".

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

#24
post #17

Earlier quoted context omitted.

Seems to me the big failure was sticking with the Von Neuman architecture. Perhaps that was a forcing function towards where we’ve ended up.

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).

It is unfortunate that this field underestimates the importance of the "people" part in favor of the "computer" part. There's definitely a balance to be stricken. I do believe that languages that are designed for computers have done a pretty decent job at adapting features that are geared more towards the "people" part of the equation. Unfortunately, programmers are very tribal and are very eager to toss the wine out with the cork when it comes to ideas that may help but they've misapplied.

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

#25

Earlier quoted context omitted.

How is Lisp performance these days? It was around in the 70’s, right? So I guess the overhead couldn’t be too bad!

Considering how much of modern software is written in JavaScript and python, I have a hard time seeing how lisp overhead would pose much of a problem. Erlang is good enough for telecom equipment for 30 years ago, so that also gives us a data point. If entertain the idea that the Von Neuman architecture may be a local maxima, then we can do even better; lisp machines had specialized instructions for lisp which allowed…

>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 DCCCLXXIX is so much clearer than 879 [0].

Once everyone who is wedded to infix notation is dead our great grand children will wonder what made so many people wase so much time implementing towers of abstraction to accept and render a notation that only made sense for quill and parchment.

[0] https://lispcookbook.github.io/cl-cookbook/numbers.html#work...

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

#27
post #25

Earlier quoted context omitted.

Considering how much of modern software is written in JavaScript and python, I have a hard time seeing how lisp overhead would pose much of a problem. Erlang is good enough for telecom equipment for 30 years ago, so that also gives us a data point. If entertain the idea that the Von Neuman architecture may be a local maxima, then we can do even better; lisp machines had specialized instructions for lisp which allowed…

>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.

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

#28
post #17

Earlier quoted context omitted.

Seems to me the big failure was sticking with the Von Neuman architecture. Perhaps that was a forcing function towards where we’ve ended up.

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.

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

#30

I 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.
Post reply on HN