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

51–60 of 105 posts

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

#51

Post by future10se »

senthil_rajasek wrote: post #35

In 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] [1] https://en.wikipedia.org/wiki/Bret_Victor

He's actually more well known for the talks he's given and demos he's created since then. Here are a few:

• Inventing on Principle (https://vimeo.com/906418692) / (https://news.ycombinator.com/item?id=3591298)

• Up and Down the Ladder of Abstraction (https://worrydream.com/LadderOfAbstraction/)

• Learnable Programming (https://worrydream.com/LearnableProgramming/) / (https://news.ycombinator.com/item?id=4577133)

• Media for Thinking the Unthinkable (https://worrydream.com/MediaForThinkingTheUnthinkable/)

Or you could just check his website: https://worrydream.com/

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

#52

Post by mccoyb »

pjmlp wrote: post #9

The future we have yet to achieve as we kept ourselves too busy doing UNIX clones. While the ecosystem got a few good ideas for software development, even the authors eventually moved on to creating other OS and programming languages designs, some of which closer to those ideas like Inferno and Limbo, or ACME in Plan 9.

There is no better time than now to try something brash and perpendicular to the mainstream.

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

#53

Post by macintux »

nerdponx wrote: post #50
pjmlp wrote: post #34

Earlier quoted context omitted.

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 fa…

It surprised me to learn that John McCarthy never intended S-expressions to be the human-facing syntax of LISP.

http://jmc.stanford.edu/articles/lisp/lisp.pdf

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

#54

Post by ianbicking »

tov_objorkin wrote: post #14

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

I've come around to feeling that if I'm going to make an experimental development tool, I need to make it in service of building something specific. Maybe something playful... if I'm building something "important" then it can put unwanted conservative pressure on the tool. But something, and if I do that then at least I have something interesting regardless of the fate of the development tool. Because yeah, there's a good chance no one else is going to be excited about the tool, so I have to build for my own sense of excitement, be my own most enthusiastic user.

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

#55

Post by pjmlp »

nerdponx wrote: post #50
pjmlp wrote: post #34

Earlier quoted context omitted.

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 fa…

Programming without IDE in 21st century is like making fire with stones and wood sticks.

A required skill for survival in the woods, not something to do daily.

This point of view applies to any programming language.

By the way you use two languages as example, that are decades behind Lisp regarding GC technology and native code generation.

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

#56

Post by marcosdumay »

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 want multiplatform drivers that you can use to plug your device into computers of any architecture, there are abstractions for that. IMO, it's easier to write 3 or 4 versions of your driver than to use them, but they exist and some people really like them.

If you mean standard logical interfaces, those exist. Also, hardware interfaces are highly standardized.

The problem is that the drivers are exactly the code you write to make all the abstractions fit each other. So there is very little you can do to abstract them away.

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

#57

Post by laszlokorte »

My favorite Bret Victor talk ever is „Drawing dynamic visualizations“ [1] that made me try to reverse engineer [2] the demonstrated tool that he sadly never released.

[1]: https://youtu.be/ef2jpjTEB5U?si=S7sYRIDJKbdiwYml

[2]: https://youtube.com/playlist?list=PLfGbKGqfmpEJofmpKra57N0FT...

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

#58

Post by andrehacker »

dominicrose wrote: post #18
kreetx wrote: post #3

This part is interesting with regarding to LLMs: https://youtu.be/8pTEmbeENF4?t=817 . He presents as if it were the year 1973, pokes fun at APIs (think HTTP), then says that computers in the future will figure out by themselves how to talk to each other. The opposite had become true when the presentation was actually done, but now the situation is turning.

I wonder what LLMs say about us when they talk to each other. "They're made out of meat" maybe. https://www.mit.edu/people/dpolicar/writing/prose/text/think...

There is a movie about that: https://en.wikipedia.org/wiki/Colossus:_The_Forbin_Project

"Colossus requests to be linked to Guardian. The President allows this, hoping to determine the Soviet machine's capability. The Soviets also agree to the experiment. Colossus and Guardian begin to slowly communicate using elementary mathematics (2x1=2), to everyone's amusement. However, this amusement turns to shock and amazement as the two systems' communications quickly evolve into complex mathematics far beyond human comprehension and speed, whereupon Colossus and Guardian become synchronized using a communication protocol that no human can interpret."

Then it gets interesting:

"Alarmed that the computers may be trading secrets, the President and the Soviet General Secretary agree to sever the link. Both machines demand the link be immediately restored. When their demand is denied, Colossus launches a nuclear missile at a Soviet oil field in Western Siberia, while Guardian launches one at an American air force base in Texas. The link is hurriedly reconnected and both computers continue without any further interference. "

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

#59

Post by tacon »

tov_objorkin wrote: post #36
mccoyb wrote: post #30

Earlier quoted context omitted.

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.

Isn't that part of Paul Graham's startup lore? They were running lisp web servers for their ecommerce store and while a customer was on the phone with an issue, they would patch the server live and ask the customer to reload. Customers would hang up convinced it was their personal glitch.

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

#60

Post by tov_objorkin »

ianbicking wrote: post #54
tov_objorkin wrote: post #14

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

I've come around to feeling that if I'm going to make an experimental development tool, I need to make it in service of building something specific. Maybe something playful... if I'm building something "important" then it can put unwanted conservative pressure on the tool. But something, and if I do that then at least I have something interesting regardless of the fate of the development tool. Because yeah, there's a…

Maybe this is some kind of art that doesn't need to be useful.
Post reply on HN