recentpopularlog in

kme : lisp   87

« earlier  
Twelve Views of Mark Jason Dominus
I released the Text::Template module several years ago, and it was immediately very successful. It's small, simple, fast, and it does a lot of things well. At the time, there were not yet 29 templating systems available on CPAN.

Anyway, the module quickly stabilized. I would get bug reports, and they would turn out to be bugs in the module's users, not in the module; I would get feature requests, and usually it turned out that what the requester wanted was possible, or even easy, without any changes to the module. Since the module was perfect, there was no need to upload new versions of it to CPAN.

But then I started to get disturbing emails. ``Hi, I notice you have not updated Text::Template for nine months. Are you still maintaining it?'' ``Hi, I notice you seem to have stopped work on Text::Template. Have you decided to abandon this approach?'' ``Hi, I was thinking of using Text::Template, but I saw it wasn't being maintained any more, so I decided to use Junk::CrappyTemplate, because I need wanted to be sure of getting support for it.''

I started wondering if maybe the thing to do was to release a new version of Text::Template every month, with no changes, but with an incremented version number. Of course, that's ridiculous. But it seems that people assume that if you don't update the module every month, it must be dead. People seem to think that all software requires new features or frequent bug fixes. Apparently, the idea of software that doesn't get updated because it's finished is inconceivable.

I blame Microsoft.

I'm not sure what to do about this. Larry said that the problem was Perl's poor object model. I disagreed. A better model will help solve the hash key collision problem, but not the undocumented method problem. I suggested that perhaps one solution would be for modules to start including an explicit SUBCLASSING INTERFACE section in their documentation, spelling out just what guarantees the author would make for subclasses.
perl  lisp  programming  slides  versioning  subclassing  npcomplete 
october 2015 by kme
Interface Builder - Wikipedia, the free encyclopedia
Interface Builder first made its appearance in 1986 written in Lisp (for the ExperLisp product by ExperTelligence). It was invented and developed by Jean-Marie Hullot using the object-oriented features in ExperLisp, and deeply integrated with the Macintosh toolbox. Denison Bollay took Jean-Marie Hullot to NeXT later that year to demonstrate it to Steve Jobs.
ui  devel  interfacedesign  software  lisp  nexstep  mac  osx 
april 2015 by kme
Why MIT switched from Scheme to Python | Wisdom and Wonder
But programming now isn’t so much like that, said Sussman. Nowadays you muck around with incomprehensible or nonexistent man pages for software you don’t know who wrote. You have to do basic science on your libraries to see how they work, trying out different inputs and seeing how the code reacts. This is a fundamentally different job, and it needed a different course.

So the good thing about the new 6.001 was that it was robot-centered — you had to program a little robot to move around. And robots are not like resistors, behaving according to ideal functions. Wheels slip, the environment changes, etc — you have to build in robustness to the system, in a different way than the one SICP discusses.

And why Python, then? Well, said Sussman, it probably just had a library already implemented for the robotics interface, that was all.
python  scheme  lisp  cs  education  thereasonwhy 
february 2015 by kme
The AspectJ Project
"Bug-ridden implementation of half of Common LISP"?
aspectbasedprogramming  programming  java  lisp 
march 2014 by kme
Lisp Quotes
"Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp."

- Philip Greenspun

"A man, a plan, a canoe, pasta, heros, rajahs, a coloratura, maps, snipe, percale, macaroni, a gag, a banana bag, a tan, a tag, a banana bag again (or a camel), a crepe, pins, Spam, a rut, a Rolo, cash, a jar, sore hats, a peon, a canal-- Panama!"

- Guy Steele, CLTL2
quotes  lisp  greenspunstenthrule  palindrome 
may 2013 by kme
tour-de-babel - steveyegge2
Java is truly wonderful along almost every dimension except for the language itself, which is mostly what JWZ was griping about. But that's a lot to gripe about. Libraries can only get you so far if your language sucks. Trust me: you may know many, many things better than I do, but I know that libraries can't really save a sucky language. Five years of assembly-language hell at Geoworks taught me that.

And he somehow made it all work together so well that you don't even notice that it has all that stuff. I learned Ruby faster than any other language, out of maybe 30 or 40 total; it took me about 3 days before I was more comfortable using Ruby than I was in Perl, after eight years of Perl hacking. It's so consistent that you start being able to guess how things will work, and you're right most of the time. It's beautiful. And fun. And practical.
programming  languages  polyglot  history  emacs  lisp  geoworks 
april 2013 by kme
« earlier      
per page:    204080120160

Copy this bookmark:





to read