Live data from Hacker News

The Future of Programming (2013) [video]

youtube.com

101–105 of 105 posts

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

#101
post #74

Bret Victor speaks so idealistically it's difficult to disagree with his vision, but in reality he's a radicalized, scrappy cult leader. His ideas sound super cool but they're impractical - that's why nobody can make them work. We're delusional for worshiping him. https://christophlocher.com/notes/ethnographic-research-on-d...

I think you're 100% about this, but we have to define "impractical". If we take it to mean "the things he shows will never be how we develop software in the future" I agree, to the extent that what he shows is his vision of working, and it doesn't seem he likes to do the kind of work people get paid wages/salaries to do.

The thing though about "nobody can make them work" is that there's really not funding to do so, because corporations don't really see a payout on the other side. So is it "impractical" or just "of no interest to corporations"? Because with AI, we see what happens when corporations think there is a giant payday on the other side. Somehow "unlock our human potential through better ergonomic design of technology" doesn't open wallets but "replace your entire dev team with a robot" causes an endless tsunami of cash. One is "impractical" and the other is "our new reality". I'd say as far as feasibility goes, the former or more practical than the latter, but as far as fundability goes, the latter is more practical than the former.

If I'm going to take away anything from what Victor has said over the years, it's what the article starts off saying, that his...

  vision is rooted in the idea that the computer revolution of the ’70s and early ’80s was cut short, primarily by premature com­mer­cia­li­za­tion. While the computer as a medium was still unfolding its potential, and way before it could do so entirely, it was solidified into commercial products, thereby stifling its free growth. Once corporations had built their businesses on the ideas developed so far, they were only interested in incremental change that could easily be integrated into the products, rather than revolutionary new ideas.
I think that's 100% true by construction, and we can see that in the languages that have risen to the top, which have all been molded for use by corporations for corporate purposes. In this case "impracticable" means "not suitable for corporate use", and it's simply not true that programming languages are only practical if corporations can use them profitably, because there are so many other purposes for programming languages.

And so I think that's the reason for the culty vibes, because without htem he wouldn't be able to do what he does. If he sold it in more grounded terms -- fundamental HCI research -- he can't get funded. So he talks in terms of human revolutions and then he gets some true believers and effective altruism people to open their wallets, get some of those SV devs to spread some of their big tech money around to causes they care about, because they're the ones who have to ultimately deal with the bad programming UX we've built for ourselves.

And that's what Bret Victor is ultimately advocating: better UX for devs, mostly through observability. That's not so radical or impractical. His work has to be because otherwise he doesn't have a job... moreover, he'd have to get a job. But that doesn't mean he doesn't have a good point.

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

#102
post #20

Earlier quoted context omitted.

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

> "what LLMs say about us when they talk to each other" That's like asking what does a kaleidoscope paint on its day off.

Have we come full circle to: [...] asking if a submarine can swim? (Dijkstra)

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

#103
post #25

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

Well said. I have always struggled with the S expression syntax though I have wanted to learn Lisp for a long time.

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

#104
post #92

Earlier quoted context omitted.

Both Lisps (Common and Scheme) are garbage-collected, so they're in the 'slow as molasses' group of languages (which covers pretty much everything outside of C, C++, Rust, Fortran, Pascal, Ada, and assembly); but among the 'slow as molasses' group, Common Lisp (at least SBCL, which may be the most prolific implementation) is blazingly, scorchingly, stupendously fast. If you know how to use it it's a bat out of hell o…

In the arbitrary collection of programs in https://benchmarksgame-team.pages.debian.net/benchmarksgame/... , SBCL runs x5 slower than C, Racket x15 slower than C. Chez Scheme shoud be in between, like x10 slower than C. (Anyway, some C programs use very advanced low level tricks, so the difference with realistic programs may be slower.) It's a pity they don't rune benchmarks for Clojure, and I have no idea to make up…

> Chez Scheme shoud be in between

? The default implementation as of Racket version 8.0 uses Chez Scheme as its core compiler and runtime system.

https://docs.racket-lang.org/reference/implementations.html

> some C programs use very advanced low level tricks

* possible hand-written vector instructions or "unsafe" or naked ffi" are flagged

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

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

#105
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…

> S-expressions are indisputably harder to learn to read.

Has this been studied? This is a very strong claim to make without any references.

What if you take two groups of software developers, one which has 5-10 years of experience in a popular language of choice, let's say C, and then take a group of people who write LISP professionally (maybe clojure? Common lisp? Academics who work with scheme/racket?) and then have scientists who know how to evaluate cognitive effort measure the difference in reading difficulty.

Post reply on HN