had the privilege to be there in person. was magical live
I envy you sooo muuchh
The Future of Programming (2013) [video]
91–100 of 105 posts
Re: The Future of Programming (2013) [video]
#92Earlier 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!
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 outrunning greased lightning.
On the Scheme side of things Chez is pretty fast. It's not 'I've gained a whole new level of respect for the people who engineered my CPU' levels fast, but it's still pretty decent.
Re: The Future of Programming (2013) [video]
#93Earlier 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
FWIW android has HAL which is just this.
Re: The Future of Programming (2013) [video]
#94Earlier 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.
I see you are debating lisps ergonomics, but that doesn't dismiss the paradigm. Erlang Haskell and Prolog has far better syntax readability, so I don't see this as really relevant in discussing the alternative to Von Neuman. There are other ergonomics issues beyond syntax that pose issues to adoption (Haskell in production has become something of a running gag). Moving the paradigm into a mixed language alongside pro…
I am responding to the assertion that the reason we don't all use Lisp is because we all have brain damage. My claim is that there are broader ergonomic issues with the language family. You could argue that maybe the system architecture and execution model of the Lisp machines should be debated separately from its syntax, but I am responding to an argument about its syntax.
Re: The Future of Programming (2013) [video]
#95Earlier 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.
I see you are debating lisps ergonomics, but that doesn't dismiss the paradigm. Erlang Haskell and Prolog has far better syntax readability, so I don't see this as really relevant in discussing the alternative to Von Neuman. There are other ergonomics issues beyond syntax that pose issues to adoption (Haskell in production has become something of a running gag). Moving the paradigm into a mixed language alongside pro…
[deleted]
Re: The Future of Programming (2013) [video]
#96Earlier quoted context omitted.
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.
I view code in many contexts though - diffs in emails, code snippets on web pages, in github's web UI, there are countless ways in which I need to read a piece of code outside of my preferred editor. And it is nicer, in my opinion, to read languages that have visually distinct parts to them. I'm sure it is because I'm used to it, but it really makes it hard to switch to a language that looks so uniform and requires a…
[deleted]
Re: The Future of Programming (2013) [video]
#97The 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…
Emacs has first party support for these approach. Buffers are separate from the windows (aka panes) where they are displayed. And the latter are arranged in a tiling manner in frames (aka windows). The buffer themselves doesn't need to be tied to a file and you can use concept like narrowing to restrict the viewable part. In elisp, you will fine often the form feed ascii code (^L) which allows to define sections which can be restricted with the `narrow-to-page` command.
On my work laptop I usually have many emacs frames. One displaying a `term-mode` (terminal) buffer, another usually displaying some `compilation-mode` buffer (tests, lint) or `grep` results, two as active workspaces as I'm often dealing with different modules (one maybe the api and the other a UI component). I create other frames as I need them (like exploring another project or doing some git-fu with magit).
Re: The Future of Programming (2013) [video]
#98Earlier 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!
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 a number.
Re: The Future of Programming (2013) [video]
#99Earlier quoted context omitted.
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.
You are free to criticize or look down on the way other people work. That doesn't change the silliness of the assertion that infix operator brain damage is the reason we aren't all using Lisp right now. It's totally valid to argue that we are all missing out on the benefits of superpowered interpreter-compilers like SBCL and Chez. But prefix math operators are only a small part of the reason why.
Re: The Future of Programming (2013) [video]
#100Call me grumpy and sleep deprived, but every year I look at this talk again, and every year I wonder... "now, what" ? What am I supposed to do, as a programmer, to change this sad state of things ? Start the n-th "visual" or "image based" programming language (hoping to at least, make _different_ mistakes than the ones that doomed smalltalk and all other 'assemble boxes to make a program' things ?) Start an OS, hopin…
> Start the n-th "visual" or "image based" programming language (hoping to at least, make _different_ mistakes than the ones that doomed smalltalk and all other 'assemble boxes to make a program' things ?)
Unironically yes, this. Progress happens in this field one dead language at a time; people try a thing and make mistakes continually, so that other people can try again and make other different mistakes. Eventually, something good is found and they integrate it into C++.
But no one is going to find these ideas unless people keep trying and failing. This is a community effort, you can only do your part. And like the rest of us you will likely fail and never be thanked for your efforts -- except by the next poor sap who takes up the good fight, sees your failures, and deftly avoids all your mistakes. But the plus side is if you succeed... you also won't be thanked or rewarded so scratch all that you probably shouldn't bother if you respect yourself.