tag:blogger.com,1999:blog-67391542010-05-11T05:23:03.476-07:00Finding LispSlowly but surely, the programming world is finding Lisp...<br>
A blog by Dave Roberts (dave-at-findinglisp-dot-com)Dave Robertsnoreply@blogger.comBlogger184125tag:blogger.com,1999:blog-6739154.post-45786156314241237002009-10-17T00:29:00.000-07:002009-10-17T09:19:31.851-07:00LispForum membership is over 700<p>Wow. I have been swamped with other things lately and didn't notice that <a href="http://www.lispforum.com/">LispForum</a> membership has grown to over 700 people. That's very cool. We also passed one year of life back in June 2009. Ah, well, I sometimes forget my wedding anniversary, too. Unfortunately, my wife doesn't hack Lisp or she probably would have reminded me.</p><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/6739154-4578615631424123700?l=www.findinglisp.com%2Fblog%2Findex.html' alt='' /></div>Dave Robertsnoreply@blogger.com0tag:blogger.com,1999:blog-6739154.post-14531102021643208652009-10-17T00:02:00.000-07:002009-10-17T00:27:07.769-07:00Holy needless asdf-install, Batman!<p>Okay, so I decided to do a bit of hacking tonight that involved installing cffi. Before I started, for the first time in a long time, I actually upgraded SBCL and blew away my <code>~/.sbcl</code> directory. Then I typed it:</p>
<pre>
(require 'asdf-install)
(asdf-install:install 'cffi)
</pre>
<p>Those commands managed to pull down 21 different packages! In itself, that might be the right thing to do for something that has a lot of dependencies, but after looking in <code>~/.sbcl/systems</code> I found that I had:</p>
<pre>
alexandria.asd
babel.asd
babel-streams.asd
babel-tests.asd
cffi.asd
cffi-examples.asd
cffi-grovel.asd
cffi-tests.asd
cffi-uffi-compat.asd
iterate.asd
lift.asd
lift-documentation.asd
lift-test.asd
metabang-bind.asd
metabang-bind-test.asd
rt.asd
stefil.asd
swank.asd
trivial-features.asd
trivial-features-tests.asd
trivial-gray-streams.asd
</pre>
<p>So, that included five different unit test packages, plus the three different unit test frameworks (Lift, RT, and Stefil) dedicated to running them. I also got Swank thrown in. Honestly, I was waiting for the free set of Ginsu knives. ("But wait, there's more...!")</p>
<p>Here's the thing, people. When I install a package, I don't want your unit tests. Or the unit test framework necessary to run them. That's all just cruft that takes time, space, energy, etc. I mean, I'm glad that people are using unit tests and all, but as a user of your package, I shouldn't have to care about unit tests. Presumably, when developing/releasing your package, you ran your tests. That's all good. But if they passed for you, they'll also pass for me. Unless I'm going to start hacking your package, they're just a nuisance for me. If I am going to start hacking your package, I'm probably going to pull the source directly from git or darcs or CVS or Subversion, not asdf-install. At a minimum, can we all agree to remove dependencies on Lift, RT, and Stefil.</p>
<p>If I really want to run your tests, and I have installed them using asdf-install, I'm perfectly willing to install those other packages using a separate asdf-install command.</p>
<p>As for Swank, while I love it, again, if I want it in my environment, I'll install it separately, thank you very much.</p>
<p>Summary: Please keep your package dependencies to a minimum. If you really need to have a package that pulls in a huge set of dependencies to create a full environment (e.g. Swank and such), please separate your core library functionality from the top-level environment package and allow those of us with minimal tastes to simply install your core library functionality by itself.</p><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/6739154-1453110202164320865?l=www.findinglisp.com%2Fblog%2Findex.html' alt='' /></div>Dave Robertsnoreply@blogger.com13tag:blogger.com,1999:blog-6739154.post-7272164186665177252008-12-12T09:44:00.001-08:002008-12-12T09:46:39.641-08:00LispForum members tops 450<p>Nice! I went away on a business trip the early part of this week and came back to find that we're over 450 members on <a href="http://www.lispforum.com/">LispForum</a>. 451 to be exact. I have been really happy with the discussions happening there. Lots of good info being exchanged and none of the attitude of comp.lang.lisp.</p><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/6739154-727216418666517725?l=www.findinglisp.com%2Fblog%2Findex.html' alt='' /></div>Dave Robertsnoreply@blogger.com1tag:blogger.com,1999:blog-6739154.post-24888459894709617172008-10-09T09:25:00.000-07:002008-10-09T09:42:13.524-07:00SBCL dominates usage at LispForum<p>We have been running a <a href="http://www.lispforum.com/viewtopic.php?f=2&t=140">poll</a> for the past couple of weeks over at LispForum asking people to tell us which Common Lisp implementations they use most. I don't think it would surprise anybody that SBCL is leading the poll, but it might surprise people as to the magnitude. Currently, with something like 97 votes in, SBCL has 53% of the votes. The next most popular implementation is CLISP with about 18%. This is followed by a tie between ClozureCL (OpenMCL) and Lispworks.</p>
<p>My takeaways here are the following:</p>
<ol>
<li>First, this poll has limited sample size. 97 respondents, all of whom are LispForum participants isn't necessarily representative of anything. LispForum has a lot of newbies (and indeed was created to help foster that), so it could be that all the old, crufty smug Lisp weenies hanging out on comp.lang.lisp have a completely different usage profile. Still, it's more data than I have seen anywhere else. Perhaps some of those c.l.lisp residents will register on LispForum and vote.</li>
<li>My biggest takeaway is that SBCL has really moved beyond CMUCL. My hunch is that having a system that is relatively easy to build and is released on a regular monthly tempo is simply a superior value proposition. William Newman nailed it when he forked SBCL from CMUCL and created a healthy, vibrant community around it. I don't dare say that CMUCL is "dead," but clearly SBCL has taken that ball and run with it. CMUCL has only 1% usage in the poll.</li>
<li>CLISP seems to be a common "backup implementation" for environments where SBCL doesn't run well. For instance, my own personal preference is SBCL on Linux and CLISP on Windows, at least for the time being. I'm also using ECL for a project I'm working on right now, primarily because it has a small memory footprint and low performance requirements.</li>
<li>Lispworks is certainly leading the commercial implementations. The low price for a high-quality implementation is probably the big draw there. IMO, if I wasn't using any open source version of CL, I'd probably be using Lispworks.</li>
</ol><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/6739154-2488845989470961717?l=www.findinglisp.com%2Fblog%2Findex.html' alt='' /></div>Dave Robertsnoreply@blogger.com4tag:blogger.com,1999:blog-6739154.post-72166958273985241322008-10-09T09:23:00.000-07:002008-10-09T09:24:55.188-07:00LispForum hits 350<p>Well, we hit over 350 registered users on <a href="http://www.lispforum.com/">LispForum</a> just the other day. Thanks to everybody for their interest and participation. Lots of good topics being discussed.</p><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/6739154-7216695827398524132?l=www.findinglisp.com%2Fblog%2Findex.html' alt='' /></div>Dave Robertsnoreply@blogger.com0tag:blogger.com,1999:blog-6739154.post-88638780303991153272008-09-22T09:54:00.000-07:002008-09-22T10:27:49.620-07:00PHP vs. Lisp: Unfortunately, it's true...<p>I just found this today while browsing Reddit:
<a href="http://briancarper.net/2008/09/22/practicality-php-vs-lisp/">Practicality: PHP vs. Lisp?</a></p>
<p>This is exactly the psychology that goes through the head of everybody who hears about Lisp and decides to check it out. Summary: Lisp is awesome, except for the multitude of trivially annoying things that make it much less so, to the point that everybody just throws in the towel and uses PHP or Ruby or whatever.</p>
<p>I hate reading articles like this because I know that it's basically all <strong>true</strong>. I also know that within 24 hours, the comments section of that blog post will be filled by Lisp apologists who keep suggesting workarounds and fixes. These are the same people who <a href="http://www.findinglisp.com/blog/2005/12/reddit-and-lisp-psychosis.html">went nuclear</a> a couple of years ago when Reddit got rewritten in Python, and it's all the same old arguments.</p>
<p>If Brian Carper's blog post annoys you, stop apologizing and start innovating. Languages exist in a market place and right now Lisp marketing itself quite poorly. Yes, I know that "marketing" is rejected by techie types who think that it should never matter, but as a marketing guy who markets <strong>to</strong> techies, I'll tell you that it absolutely does. And those who reject marketing will flat-out lose to those who understand it.</p>
<p>As a "customer" of a particular language, nobody wants to hear how their particular issue is unimportant in the grand scheme of things. Nobody wants to hear that such and such a problem was "solved" 20 years ago with this particular hack or workaround that only Lisp gurus know about. Nobody wants to hear that it's a simple job to port that particular library over to that particular implementation. People have a ton of free language options these days, and if Lisp isn't going to compete in terms of ease of use and productivity, then people will choose languages that will.</p>
<p>Note that <i>theoretical</i> ease-of-use doesn't count. Everybody will probably admit that Lisp macros are all-that-and-a-bag-of-chips, and building DSLs is way more productive than writing boilerplate code, and nevermind CLOS and closures, etc. Those are <strong>GREAT</strong> things that Lisp brings to the party, but they are completely useless if a newbie can't crank out a web page in 30 minutes like he can with PHP.</p>
<p>If you step back for a second and really try to listen to the arguments against Lisp, you'll find that there are two classes of gripes: fundamental dislikes and competitive disadvantage. Things like griping about the parenthesis are a fundamental dislike. Some people don't like parenthesis. Fine. Lisp is not for you. Parenthesis and sexprs are pretty fundamental to Lisp. They're part of its DNA. If you don't like them, then you don't like Lisp itself. There's no issue with that. Just use something like Java. Most Lisp programmers hate Java syntax, too. If you're really enlightened, take a look at Dylan. In short, as a guy who likes Lisp, I'll defend Lisp's parenthesis until I die.</p>
<p>The other type of gripes are about competitive disadvantage. These are issues that are not fundamental to the language itself, it's just that the Lisp community hasn't done much to solve them. Things such as having a reasonable set of standard libraries to do programming in today's Internet-connected world have nothing to do with the fundamentals of Lisp. Library documentation and tutorials would help. Having a decent system for the installation of libraries that doesn't depend on little-known and sometimes unmaintained web servers would also help. Everything in this category is hard to defend, and Lispers should universally be ashamed of it. Imagine saying to a "customer" something like, "Yes, I know that everything is undocumented and the installation infrastructure is unreliable, but you know, that's a <strong>feature</strong>." Rubbish!</p>
<p>In short, while somebody, somewhere, will always be griping about Lisp, the Lisp community, all of us, could go a long way toward making all those gripes fall into the "I hate parenthesis" category rather than the "There aren't any libraries and what libraries do exist don't have any documentation." There is a lot of work to do. Let's get coding...</p><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/6739154-8863878030399115327?l=www.findinglisp.com%2Fblog%2Findex.html' alt='' /></div>Dave Robertsnoreply@blogger.com31tag:blogger.com,1999:blog-6739154.post-51905569093349329612008-08-16T12:26:00.000-07:002008-08-16T18:12:23.105-07:00Lisp Quiz #1: Minesweeper<p>A couple of folks were <a href="http://www.lispforum.com/viewtopic.php?f=20&t=23">discussing</a> the need for a Lisp equivalent to Ruby's <a href="http://www.rubyquiz.com/">Ruby Quiz</a> the other day on <a href="http://www.lispforum.com/">LispForum</a>. Ruby Quiz was a great way to learn Ruby. It presented a series of programming tasks that were somewhere between a simple exercise at the back of a textbook and a full ICFP Programming Contest challenge. The goal was to give budding Rubyists a meaty problem on which to test their skills, while not serving up something so difficult that it would take weeks to accomplish.</p>
<p>Well, I'm pleased to say that yesterday we took the plunge with the <a href="http://www.lispforum.com/viewtopic.php?f=2&t=108">first quiz</a>. The challenge is to write a simple algorithm (AI?) for <span style="font-weight:bold;">playing</span> Minesweeper. The game engine is delivered as part of the challenge, so there is no need to actually worry about the mechanics of Minesweeper. Just focus on creating an algorithm that will work its way through the minefield without choosing a mine.</p>
<p>The 48-hour No-Spoiler Period expires at ~5:00 PM PDT tomorrow. Check out <a href="http://www.lispforum.com/">LispForum</a> to post your solution or discuss others.</p><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/6739154-5190556909334932961?l=www.findinglisp.com%2Fblog%2Findex.html' alt='' /></div>Dave Robertsnoreply@blogger.com2tag:blogger.com,1999:blog-6739154.post-19492622495617769382008-07-14T08:33:00.000-07:002008-07-14T08:37:31.630-07:00Two weeks of LispForum<p>Well, it has been just a bit over 2 weeks since <a href="http://www.lispforum.com/">LispForum</a> went live. We've had over 160 people register and some good discussions break out on everything from Lisp web programming to GUI toolkits for Lisp to what everybody is working on that involves Lisp.</p>
<p>If you haven't checked out <a href="http://www.lispforum.com/">LispForum</a> yet, drop in and see us. You'll find a small but growing community of Lispers sharing ideas and having fun.</p><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/6739154-1949262249561776938?l=www.findinglisp.com%2Fblog%2Findex.html' alt='' /></div>Dave Robertsnoreply@blogger.com1tag:blogger.com,1999:blog-6739154.post-31383991293861828622008-06-27T23:35:00.001-07:002008-06-27T23:43:47.244-07:00LispForum, open for business<p>The other day, I realized that there wasn't a great place to discuss Lisp that was using a post-Y2K sort of interface. Sure, comp.lang.lisp has been around forever, and through Google Groups it has an HTTP interface, but when you post to Usenet you become an instant spam magnet. And new users think an all text-mode interface with no markup is just so 1985. And yes, there's always #lisp on Freenode.net IRC, which is great for realtime, but bad for searching for coherent answers.</p>
<p>So, I created Lisp Forum: <a href="http://www.lispforum.com/">www.lispforum.com</a></p>
<p>The content is a bit sparse right now. That's where you come in. Please register, hang out, and participate. My goal is to make this a friendly place with a bit less Smug Lisp Weenie-ness than comp.lang.lisp, suitable for both newcomers and old pros.</p><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/6739154-3138399129386182862?l=www.findinglisp.com%2Fblog%2Findex.html' alt='' /></div>Dave Robertsnoreply@blogger.com11tag:blogger.com,1999:blog-6739154.post-74559312497433404382008-06-27T09:27:00.000-07:002008-06-27T14:02:22.493-07:00Forth Timelessness, a Redux<p>The other day, I discussed languages which I thought were <a href="http://www.findinglisp.com/blog/2008/06/timeless-desert-island-language.html">timeless</a>. Among them, I listed Lisp, C, and Forth. After writing that posting, I spent some time playing with Forth again. Today, while browsing Reddit, I stumbled on <a href="http://www.computerworld.com.au/index.php/id;766897508;fp;16;fpid;1">this interview</a> with Charles Moore, the creator of Forth.</p>
<p>Forth is one of those languages, like Lisp, that I'd recommend that everybody study at least for a time. Even if you don't walk away believing it's the <i>Language to End All Languages</i>, you'll be better off for the experience. In fact, Forth shares a lot of fundamental attributes with Lisp while at the same time appearing almost completely different to a programmer writing code.</p>
<p>Some of the shared attributes include:</p>
<ol>
<li>Forth and Lisp both erupt from a very small nucleus of fundamental constructs. As Alan Kay has described Lisp as being "<a href="http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=273&page=4">Maxwell's equations of sofware</a>," similar statements would also apply to Forth. Both Forth and Lisp are fundamentally simple as a result. Sure, the libraries could be huge, but learning the actual language itself, the core rules, requires no more than a few minutes for each language. With both languages, there is a set of advanced rules (things like macros for Lisp or compiling words for Forth), but the basics are trivial.</li>
<li>Forth and Lisp are duals of each other when it comes to their syntax. In both cases, the programmer is essentially handing the system a direct representation of the parse tree. The parsers for each language are trivial. Lisp uses prefix notation, whereas Forth uses postfix: "(+ 1 2)" vs. "1 2 +" for example. The use of prefix notation semi-requires delimiters to be inserted, giving us Lisp's beloved/hated parenthesis. With Forth, all computation revolves around the stack. Because the operation always occurs after the parameters are pushed, you don't need the delimiters. Words simply consume whatever parameters from the stack that they want to. One implication of this, however, is that you can do things like "(+ 1 2 3 4)" in Lisp. In Forth, this ends up being either "1 2 + 3 + 4 +" or "4 3 1 2 + + +".</li>
<li>Forth and Lisp are both extensible. When you create a new function or macro in Lisp, you're extending the language itself. Your new function or macro is a peer with everything else in the language, not a red-headed stepchild. Similarly, with Forth, a word is a word is a word. You can create Forth words that interact with the compiler and do all sorts of crazy stuff. Most Forth systems also include an assembler so you can create high-performance, primitive Forth words as well.</li>
<li>Forth and Lisp are both interactive. They both use a REPL. Forth doesn't call it that, but that's what it is. The benefits of this are similar in both. You tend to code a little, then test a little, then code a little, then test a little. In the interview with Moore linked above, you can see where he talks about the speed at which things got developed as a result of the interactivity of his Forth system.</li>
<li>Forth and Lisp both include a compiler. I guess this really isn't a fundamental attribute of Lisp itself (you could be fully interpreted), but most Lisp systems do have a compiler. In some cases, that compiler can be pretty simple and primitive. In other cases, it could be very sophisticated (CMUCL/SBCL). With Forth, the compiler for threaded code is both fundamental and at the same time trivial. More sophisticated Forth systems can create more complex compilers (subroutine threading, superoperations, etc.), but those are not required.</li>
</ol>
<p>All that said, Forth and Lisp are also very different:</p>
<ol>
<li>Typically, Forth operates at the machine level, with very direct exposed representations for objects. Forth programmers think in terms of machine words, bits and bytes. In some parts of a given program, a given bit pattern will represent a character or pointer or whatever, but from Forth's point of view they're all just bit patterns in a machine word. In contrast, Lisp programmers operate a higher levels of representation with first-class status for things like symbols, numbers, characters, etc.</li>
<li>As a result of this "level difference," Forth programs are more memory efficient than Lisp programs, but they're also more dependent on the underlying machine fundamentals. For instance, if you changed the word size of the machine, a Lisp programmer probably wouldn't be aware of it. A Forth programmer might have to scramble to rewrite a good portion of the code. But very useful Forth programs are measured in KB of size, not MB.</li>
<li>A big difference that typifies the issue of operating at the machine level vs. higher levels of abstraction is that Forth doesn't include any GC capabilities. All memory management must be done manually by the programmer.</li>
<li>Forth isn't very tolerant of program bugs. Because you're operating at the machine level, when things go wrong, you might end up with a crashed machine. The Forth response to that is to just push the reset button and reload the system. Because the compiler is so fast, you'll be back to where you were before the crash in no-time. In contrast, Lisp makes a lot of effort to land the programmer in an interactive debugging shell when it detects an error condition.</li>
</ol>
<p>Note that people have proposed systems which bridge between the two worlds. <a href="http://www.factorcode.org/">Factor</a> is basically a Forth stack machine and syntax, augmented with high-level, Lisp-like data types and a GC. The result is a system which delivers Forth-like syntax with a Lisp-like debugging and development environment. Depending on your point of view, you'll either think this is the best of both worlds or the worst.</p>
<p>For me personally, I like both Forth and Lisp, but I'd use them in completely separate domains. If I was working on a deeply embedded project, where I'd want to be close to the machine architecture and where I had only a few KB into which to implement the program, I'd choose Forth. If I was writing a large application that would be running on a server with GBs of memory, I'd choose Lisp. Each works well within its target domain and the advantages of each are nearly the same: a small, extensible language with an iterative, interactive development environment.</p>
<p>As for systems like Factor, for <b>me</b> it's a "tweener" that doesn't fit my needs. By getting away from the machine details, adding high-level data types, GC, etc., Factor necessarily pushes itself out of the embedded world. You simply won't have microcontrollers running Factor. And if I'm going to be running on a system with an underlying operating system, a large graphical display, and GB of memory, I'd rather do my development in Lisp. While I like Forth, I find that Lisp's sexpr notation more closely matches my thinking model. With Forth's implicit stack, I have to be thinking all the time about what data values are at what positions on the stack. I'd choose to deal with that for an embedded design to get all the other attributes of Forth <i>in that environment</i>, but with fewer constraints, I'd choose Lisp over a "Forth with high-level data types and GC" like Factor.</p>
<p>Now, that's just me. For you, Factor may be the ticket. Slava Pestov is not an idiot (and you can quote me on that, Slava). As Factor's creator, he has obviously built a system that works well for him. Other people who seem to have far better programming skills than I do are working with Factor, too. The development environment they have put together seems to have borrowed a lot of ideas from Lisp machines, and I could see the Factor environment being really productive.</p>
<p>Whatever you choose, realize that all of these languages have some things they share. And fundamentally, both Lisp and Forth are timeless.</p><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/6739154-7455931249743340438?l=www.findinglisp.com%2Fblog%2Findex.html' alt='' /></div>Dave Robertsnoreply@blogger.com18tag:blogger.com,1999:blog-6739154.post-91841965104797402832008-06-04T17:57:00.000-07:002008-06-04T18:41:01.978-07:00A Timeless, Desert Island Language<p>I started thinking about it today. What if I was stuck on the proverbial desert island? What programming language would I want to have to hammer out that critical calculation that would somehow return me back to civilization?</p>
<p>I know this is heresy, but I think I'd choose C.</p>
<p><b>"WTF!?!?!"</b> I hear you cry. "This is a Lisp blog, dammit. You can't choose C." Well, you're right. But let me ramble for a second.</p>
<p>In my thinking this afternoon, I started to consider which programming languages are really <i>timeless</i>? Not just <i>popular</i>, mind you, but <i>timeless</i>. There aren't that many. COBOL was popular once. It wasn't timeless. PERL is certainly popular, but given the changes happening in PERL 6, it's not timeless either. Python? A very fun language, but not timeless. Ruby? Very hip and cool, but not timeless. How about Java? I once read something from the <a href="http://www.longnow.org/">Long Now</a> folks saying that they would be using Java for any programming because it was a language that could stand the test of time because of WORA. (If somebody can point me to a reference for this, please do. I was Googling madly for it this afternoon, but I can't seem to find it. I believe it was something Bill Joy wrote.) I didn't believe it then, and I certainly don't believe it now.</p>
<p>Nope, there is a huge difference between popularity and timelessness. I think C <strong>is</strong> timeless. C has been called "high level assembler." There are few other languages that do such a great job of raising you <i>just slightly</i> out of the world of bits, bytes, and machine registers, just enough to give you high level conditionals and loops, but not far enough that you can't get back to machine words.</p>
<p>Lisp is also timeless. Alan Kay has said that Lisp is "<a href="http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=273&page=4">Maxwell's Equations of software</a>." He's right. There is something that is so fundamental about Lisp that it simply cannot go away. It's far more than the parenthesis or the lists or the macros or any of that stuff that Lispers love. It's more than Common Lisp or Scheme or MacLisp or Emacs Lisp. It's all that stuff and more. At its core, Lisp is so compact and powerful as to be timeless. From <a href="http://www.findinglisp.com/blog/2004/10/principia-lispia.html">McCarthy's original paper</a> springs forth the whole world of every program that can be written.</p>
<p>In fairness to Kay, Smalltalk is pretty close to being timeless, too. In a certain sense, Smalltalk lives on in Ruby, but it's really the idea of message passing rather than Smalltalk specifically. Insofar as Smalltalk is synonymous with message passing (which it really isn't), it's timeless.</p>
<p>FORTH is timeless. The basics of a stack machine are pretty fundamental. The various FORTH words and implementation techniques may change (c.f. <a href="http://factorcode.org/">Factor</a>), but the fundamentals are still recognizable as FORTH.</p>
<p>And that's why I'd choose C as my desert island language. Because in less than 10 pages of C, I can bootstrap a basic Lisp interpreter (or FORTH interpreter, for that matter). And with Lisp, I can write everything else. When PERL and Python are as dated as COBOL and Pascal, we'll still have Lisp. And it'll still be very recognizable as Lisp.</p><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/6739154-9184196510479740283?l=www.findinglisp.com%2Fblog%2Findex.html' alt='' /></div>Dave Robertsnoreply@blogger.com22tag:blogger.com,1999:blog-6739154.post-53070016836856312742007-11-14T09:02:00.000-08:002007-11-14T09:29:46.518-08:00Dan Weinreb's Weblog<p>A couple years ago, I exchanged email with <a href="http://dlweinreb.wordpress.com/">Dan Weinreb</a> about Lisp machines. Dan was one of the founders of Symbolics and wrote the Emacs variant on the Symbolics machines. During our email exchange, I asked Dan about some of the statements and writings of Richard Stallman with respect to Symbolics and Richard's characterization of Symbolics as one of the bad guys in the Lisp machine competition with LMI. This was interesting to me because the Symbolics vs. LMI competition figures prominently in RMS's reasoning to create GNU and the whole concept of Free Software.</p>
<p>Of course, there is always another side to the story, and Dan definitely disagreed with Richard's characterization of the situation. Having interacted with both Dan and <a href="http://www.findinglisp.com/blog/2007/01/meeting-richard-stallman.html">Richard</a>, I tend to believe Dan's version more than Richard's. But that's just my opinion. I told Dan that I thought he should document his version of events because the only side of the tale that was being told up until that point was Richard's, and without any evidence to the contrary, his side was being accepted as gospel.</p>
<p>At the time, Dan basically said that he just didn't feel like it. He was tired of the whole thing and just wanted to let Symbolics rest in peace. Having founded an unsuccessful startup myself, I know exactly where he is coming from. The last thing you want to do is relive things by going through the act of documenting history. Dan told me that he would probably document things at some point, but not at that moment.</p>
<p>Well, I'm pleased to report that Dan has started a new blog and one of his first postings was his version of the Symbolics vs. LMI competition. It directly refutes some of RMS's assertions and provides a good counterbalance to this controversy. I'm glad that Dan published his side of the story. Who you believe, well that's up to you. If you're an RMS fanboy, Dan's account of things is unlikely to change your mind. But at least history will record that there were two sides to the story.</p>
<p>As an aside, I'm glad Dan has started blogging in general. He struck me as a very smart cookie and I'll definitely be adding his <a href="http://dlweinreb.wordpress.com/feed/">RSS feed</a> to my list. Whether he blogs often or not, I'm sure I'll be the better for reading his words.</p>
<p>Hat tip to <a href="http://xach.livejournal.com/144300.html">Xach</a> for noticing Dan's blog.</p><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/6739154-5307001683685631274?l=www.findinglisp.com%2Fblog%2Findex.html' alt='' /></div>Dave Robertsnoreply@blogger.com0tag:blogger.com,1999:blog-6739154.post-14206828100891449772007-11-05T18:01:00.000-08:002007-11-05T18:11:04.036-08:00Missing Bignums<p>There was a day when I didn't know what a bignum was or why I would possibly want one. I was fat, dumb, and happy with basic fixed-precision integers in C and Java land. When I first started playing with Common Lisp, I thought, "Wow, that's a neat trick that I can actually evaluate <code>(factorial 100)</code> and it works correctly, but how often am I going to be doing that??"</p>
<p>Boy, was I wrong. I'm working on a project in Emacs Lisp in my spare time and I suddenly have a need to deal with integers that are greater than the anemic 29-bit fixnums that Emacs Lisp supports. While 29 bits might be okay for working with character positions in a buffer, it falls flat on its face whenever you want to manipulate anything from the outside world. In this case, 29 bits is too small to handle any 32-bit quantity, let alone some of the 64-bit stuff I want to deal with. I'm kind of amazed that RMS didn't just implement 32-bit boxed integers if he wasn't going to do full bignums.</p>
<p>I found that <a href="http://www.emacswiki.org/cgi-bin/emacs-en/AdvancedDeskCalculator">calc.el</a> includes support for its own version of bignums and I might be forced to use those. Painful, though. I guess the old saying is true--you don't miss something until it's gone.</p>
<p>Does any Emacs guru know if bignums are being considered as a standard Emacs Lisp datatype for a future Emacs version? I'm currently working in Emacs 22.1 (Fedora 7). Given the release schedule of Emacs versions, any future support won't help me, but it would at least be comforting to know that other people see the same need.</p><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/6739154-1420682810089144977?l=www.findinglisp.com%2Fblog%2Findex.html' alt='' /></div>Dave Robertsnoreply@blogger.com4tag:blogger.com,1999:blog-6739154.post-65224373176725380392007-10-08T13:56:00.000-07:002007-10-08T16:05:30.474-07:00Stupid Programming Language Tricks<p>I spent a while last night reading about Tim Bray's adventures with Erlang. Tim started investigating Erlang as a part of his "<a href="http://www.tbray.org/ongoing/When/200x/2007/09/20/Wide-Finder">Wide Finder Project</a>" in which he's looking for programming languages that will help accelerate common tasks on the soon-to-be-very-popular CPUs with many cores but slower clock rates.</p>
<p>Tim works at Sun, and so this question and project makes perfect sense in light of Sun's Niagra and <a href="http://www.sun.com/processors/UltraSPARC-T2/">T2</a> processors with many cores and CMT. It also makes perfect sense in light of Intel's <a href="http://techresearch.intel.com/articles/Tera-Scale/1421.htm">Tera-scale computing initiative</a> where they have demonstrated chips with 80 cores. In short, the future is going to be very, very parallel, and we had better come to terms with that.</p>
<p>Unfortunately, the modern multi-threaded programming paradigms are ill-equipped to take advantage of these modern processors. Most popular programming languages have the same simple threads+locks paradigm that was popularized with pthreads and Java. While this works, it doesn't work well. As with so many things in programming, the threads+locks paradigm forces programmers to remember a whole lot of crufty details, otherwise they will produce code with very subtle bugs that is very, very difficult to debug. Put another way, threads+locks is the parallel programming equivalent of manual memory management. In the same way that GC manages memory in many modern programming languages, we need an equivalent to help programmers manage parallel programming.</p>
<p><a href="http://www.erlang.org/">Erlang</a> has many features that help it work well on multi-core systems. The language is inherently multi-threaded and concurrent and relies on threading almost down to the core (you <b>can</b> write non-threaded Erlang programs, but the language makes it so easy to use threading that you'd hardly want to). I have talked about Erlang before a few months ago (<a href="http://www.findinglisp.com/blog/2007/03/language-binge.html">her</a>e and <a href="http://www.findinglisp.com/blog/2007/03/erlang-and-termite.html">here</a>).</p>
<p>So, here we have Tim Bray asking a perfectly sensible question, "What programming language is going to help us programmers exploit the soon-to-be-commonplace multi-core CPU?" Erlang is certainly a potential answer to that problem. Unfortunately, Bray decided to pick a problem for which Erlang is particularly unsuited and then compares Erlang to another programming language that optimized for the problem, albeit without any parallel programming support--Bray picked a simple web log analysis problem.</p>
<p>The web log analysis problem is one that is well suited to Perl, Python, or Ruby. One might even say that these languages were virtually created to solve problems in this exact domain. If Perl does anything really well, it processes text with regular expressions. Python is a bit more clunky than Perl or Ruby in terms of regex syntax, but still does quite well. Ruby was created to solve many of the same problems as Perl, but with a better object model and saner syntax (IHMO).</p>
<p>Erlang, on the other hand, was created to develop 24x7x365, long-running telecom software. This is stuff that aims to have downtimes measured in a handful of minutes per year and that must be able to be upgraded on the fly and recover from any faults or failures. In short, Erlang aims to help programmers write code that can take a bullet to the head, recover, and keep on doing its thing, later allowing the programmer to find the fault, fix it, and upgrade the system, all while staying up and doing its thing. This is a <b>hugely</b> complex task, I can assure you. And Erlang conquers it in fairly good fashion.</p>
<p>So, when Bray decides to try Erlang on this problem, he naturally finds that it blows chunks. <a href="http://www.tbray.org/ongoing/When/200x/2007/09/21/Erlang">His first attempt</a> doesn't even attempt to use any Erlang threading features, which of course defeats the whole reason for the investigation in the first place. Knowing enough about Erlang to be dangerous, I found myself saying, "Well, duh! Why did you expect that to get great performance?"</p>
<p>Overall, I'm getting pretty tired about these simplistic comparisons that people do between programming languages. It always feels like they're an elaborate sort of "gotcha." Step 1, pick a task that runs particularly well on the evaluator's most familiar language (Bray picks web log analysis, which runs quite well in Ruby, his choice language). Step 2, pick a victim language. When the victim language doesn't measure up, yell "WTF?!?! [insert language] sucks." Now, in truth, Bray didn't do that last part, but you have seen the pattern other times, I'm sure (witness the number of people that list the <a href="http://shootout.alioth.debian.org/">Computer Language Shootout</a> as justification for almost anything).</p>
<p>What would have made a better comparison is writing a multi-threaded web server in both Erlang and Ruby and see which server is able to deliver the best performance to 10,000 active clients with widely varying download speeds. I'd be willing to bet that Erlang does a better job. No, I wouldn't even suggest writing a 24x7x365 telecom switch in Ruby; as fine as Ruby is, Erlang would win that hands down.</p>
<p>So, rather than making languages do stupid tricks as the basis of comparison, let's acknowledge that there is something that we can learn from just about every language. The fact is, <b>all</b> languages optimize for particular problem domains and I don't think that a universal programming language exists that would perform well on all tasks. Bray rapidly found out that Erlang isn't optimized for doing line-oriented I/O and it's regex library sucks. So what? While those problems could be eliminated from Erlang, the fact that Ericsson has deployed large telecom gear without having to fix those issues means that Erlang is ideally suited to its original programming domain.</p><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/6739154-6522437317672538039?l=www.findinglisp.com%2Fblog%2Findex.html' alt='' /></div>Dave Robertsnoreply@blogger.com20tag:blogger.com,1999:blog-6739154.post-51498099978902314112007-04-04T20:43:00.000-07:002007-04-04T21:36:38.937-07:00Brad Delp died last month<p>Brad Delp of <a href="http://www.bandboston.com/">Boston</a>, one of the all-time greatest singers in rock-and-roll took his own life on March 9, 2007. He was iconic. His falsetto was incredible. The debut <a href="http://www.amazon.com/exec/obidos/ASIN/B000002572/findinglisp-20">Boston album</a> was the first record I ever bought with my own money as a kid and remains my all-time favorite. I'm glad I actually got to see him <a href="http://www.findinglisp.com/blog/2004/08/listen-to-record.html">perform</a> live.</p>
<p>It's hard to imagine taking your own life but rock stars seem to do it far too often.</p><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/6739154-5149809997890231411?l=www.findinglisp.com%2Fblog%2Findex.html' alt='' /></div>Dave Robertsnoreply@blogger.com4tag:blogger.com,1999:blog-6739154.post-88410912853465305182007-04-04T20:40:00.000-07:002007-04-04T20:39:43.603-07:00Erlang and Termite<p>At the end of my previous discussion of my recent <a href="http://www.findinglisp.com/blog/2007/03/language-binge.html">language binge</a>, looking at Factor and Erlang, I mentioned that a perfect language would use Lisp as a base and then add some interesting features from Erlang. I mentioned Erlisp as being one step towards something like that but noted some of the limitations of Erlisp because it builds on top of Common Lisp. I noted that a ground-up rethink and true fusion would be more interesting in trying to solve the fundamental problem that Erlang is trying to solve (non-stop operation for years) but gaining some of the advantages of Lisp. I also mentioned that there was a Scheme-based experiment like Erlisp but I couldn't remember the name. Several commenters reminded me that it's called <a href="http://toute.ca/">Termite</a>.</p>
<p>So, I went back and read the paper about Termite again. I had done so a while ago but had only really retained the fact that a "Scheme-based Erlang" existed. I had forgotten its name and everything about its implementation.</p>
<p>The fact is, Termite is very close to what I would be looking for. I think it may do a better job than Erlisp because the Gambit Scheme implementation on which it is based has some nice thread capabilities (the ability to create "millions of threads on ordinary hardware"). Still, from some comments made at the end of the paper, it's clear that even the implementors think there are some limitations in Termite driven by the fact that it's implemented on top of Gambit rather than from the ground up. I don't know enough yet to understand where the limitations might be, and the authors only hint at them, never stating them outright.</p>
<p>Still, I think Termite is close.</p><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/6739154-8841091285346530518?l=www.findinglisp.com%2Fblog%2Findex.html' alt='' /></div>Dave Robertsnoreply@blogger.com0tag:blogger.com,1999:blog-6739154.post-59179171179122113412007-03-16T15:09:00.000-07:002007-03-17T19:12:33.817-07:00Language binge<p>I have been on a bit of a language binge lately. I have been playing around both with <a href="http://www.factorcode.org/">Factor</a> and <a href="http://www.erlang.org/">Erlang</a>. I'm greatly impressed with both languages, though for completely different reasons.</p>
<p>If you haven't spent any time with Factor, the best way to describe it is "high-level <a href="http://en.wikipedia.org/wiki/Forth_(programming_language)">Forth</a>." Forth is a stack-based language that is great for embedded work because you can do a whole lot in a very small footprint. Forth, like Lisp, is interactive. Unfortunately (or perhaps fortunately, if you're a big Forth fan), Forth is fairly low-level in terms of its operation. Forth likes to think in terms of machine words. A lot of things like string handling are done with pointers. When data is stored on the stack, it's untyped and if you put parameters in the wrong order, it's easy to blow things up. In general, if you're an embedded programmer, Forth rocks. If you're an application programmer, I think Forth is the wrong tool. (Please, Forth people, don't write to me and tell me that Charles Moore, the creator of forth wrote his own CAD system all in Forth to design Forth machine chips. I know all that. Moore is a genius and there are few people in the world that could do what he has done.)</p>
<p>But what would happen if you took some of the ideas that Forth has: interactivity, high-level compiler that travels with the application, implicit stack-oriented parameters in function calls, and married that with some high level data types? What if those high-level data types had embedded typing, like Lisp, and so the system could determine when you're trying to add a number and a string or other type errors? Well, you'd end up with Factor.</p>
<p>Factor is the creation of Slava Pestov, another genius. Factor runs on just about any OS that runs on x86 and on several different processors under Linux. Factor has a <b>great</b> GUI development environment that takes some cues from Lisp Machines and CLIM (think lots of hyper-linked documentation and help, along with presentations). Factor has lots of example code, including such things as a web server on which the Factor web site runs. Check out the <a href="http://www.factorcode.org/">Factor web site</a> for more info. There is a lot of goodness here.</p>
<p>As good as Factor is, however, I'm not sure it's my cup of tea for general application programming. I generally like <a href="http://en.wikipedia.org/wiki/Reverse_Polish_notation">Reverse Polish Notation</a> (RPN) and have always used HP calculators all my life. That said, I just find it difficult to keep track of stack parameters through a long set of Forth or Factor function calls. It isn't that working this way is wrong in any sense of the word, but I find that I prefer named parameters where I can attach a description to a value, as in something like Lisp.</p>
<p>So, I decided to look at Erlang. Erlang was developed by Joe Armstrong at Ericsson to address problems in the telecom field. Luke Gorrie (another programming genius) has been telling me that I should get some Erlang experience for years now. Luke and I both work in the telecom/datacom field. Luke was at Bluetail with some of the key Erlang folks and later wound up at Nortel through a series of acquisitions. I had just left Nortel a while earlier.</p>
<p>Erlang's big claim to fame is concurrency. An Erlang program is composed of multiple "processes," similar in function to OS-level processes, but running in one or more virtual machines. Processes communicate by message passing. When the processes are all located in the same VM, this happens very quickly, but the nice thing is that the communication semantics are identical if the processes are running on multiple VMs, possibly on multiple computers. This makes it very easy to write Erlang programs that run in a distributed fashion.</p>
<p>Erlang is functional and keeps the memory of each process completely separate from the others ("shared nothing"). This improves the reliability of programs for several reasons. First, you don't have to worry about mutable data structures messing you up, violating an assumption without you knowing about it. Second, processes can't interact with each other except through message passing. If a process crashes for whatever reason, the other processes around it can generally continue to function until the crashed process is restarted.</p>
<p>And Erlang processes can crash a lot. This isn't because the programs are necessarily buggy, though that's one reason, but rather because Erlang actually encourages you to program only for the common case and to crash the moment your program detects any violation of its assumptions. The theory here is that rather than trying to continue a failed computation, it's often better for the overall system reliability for a process to give up and let other processes outside the failed process clean up the resulting mess. This is an interesting philosophy but it has a lot of merit.</p>
<p>Think about your typical PC. If you're a Linux user and you encounter a buggy program, how many of you will restart it in order to try to clean up the mess? If you have a buggy Windows system, how many of you reboot it? And generally, this works. Erlang simply takes the same idea and applies what we all know intuitively to be true , rebooting often fixes problems, to processes within a larger program.</p>
<p>Now, one of the neat things about Erlang crashes is that they produce a stack trace, much like you'd have in a Lisp system, such that a programmer isn't left with no data, scratching his head, wondering why the process crashed. You at least have some data to go on when you start debugging. Erlang aims to have systems that operate non-stop for <b>years</b>. To support this, Erlang supports hot code replacement.</p>
<p>So imagine you have the scenario where a customer reports a bug. Your support person asks the customer to send the log file, in which is the stack trace. A programmer examines the data and determines a fix. You recompile the program and send the customer the new version. The customer loads the new version <i>while the old one is still running</i> and the new version takes over seamlessly, with no downtime. Yes, Lisp has had many of these same ideas, and Erlang incorporates them.</p>
<p>Erlang is not all a bed of roses. I don't like the syntax. It's scary to say this, but I really do like and appreciate Lisp sexprs. Erlang has primitive macros, ala C, but nothing approaching the power of Lisp.</p>
<p><b>Pet peeve:</b> Modern software reliability is horrible. I think Erlang at least gets its philosophy right. It's built to make highly reliable systems and it has the features to support that goal. From the get-go, it says, "Okay, we're going to be building systems that will operate non-stop for years. Of course we'll find bugs, but we need ways to be able to debug the system and then introduce changes to it without taking the system down. Further, bugs should only result in partial failures if at all possible. Where there are other tasks in the system unaffected by the bugs, they should remain available through the whole problem period." There are very few languages that could rise to that challenge. Lisp and Smalltalk come the closest, I think, but even with those there are issues of corrupted data structures hanging around and causing problems.</p>
<p>I know it's all in fashion right now, but I'm starting to contemplate my dream language. It looks a lot like CL or Scheme, but with some rather nice ideas borrowed from Erlang (and possibly Smalltalk and maybe even Ruby). In particular, the ability to have <b>large</b> numbers of concurrent processes, with message passing semantics. Keep the same sexpr syntax as Lisp and leave in all the introspection and meta-programming facilities. While there have been attempts to merge Erlang and Lisp concepts before, notably with <a href="http://www.dirkgerrits.com/programming/erlisp/">Erlisp</a> (and another one on the Scheme side whose name escapes me right now), I think what's needed is a ground-up rethink. Erlisp attempts to capture some of Erlang's process and message passing ideas in standard Common Lisp. Unfortunately, most Common Lisps don't have great multiprocessing capabilities, and none have thought through the "shared none" semantics that Erlang uses to increase reliability of the overall system. Semantically, in an Erlang system, sending a message to another process <b>always</b> creates a copy (of course, the copy may be optimized away by the compiler if the semantics are preserved). SETF has all sorts of abilities to trip you up in standard Common Lisp if you aren't careful.</p>
<p>Maybe to spare myself the embarrassment of trying to implement this (I'm not a Slava Pestov, a Charles Moore, or a Luke Gorrie), I'll base it on <a href="http://www.paulgraham.com/arc.html">Arc</a>. As soon as Paul is done, I'll get cracking on this new thing...</p>
<p>(Oh, and I'm not a Paul Graham either.)</p><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/6739154-5917917117912211341?l=www.findinglisp.com%2Fblog%2Findex.html' alt='' /></div>Dave Robertsnoreply@blogger.com10tag:blogger.com,1999:blog-6739154.post-79708982457791579882007-02-21T18:41:00.000-08:002007-02-21T18:50:45.148-08:00Olin Shivers cracks me up<p>Ever since I read the <a href="http://www.scsh.net/docu/html/man.html">Acknowledgments section</a> of the scsh manual, I have gotten a chuckle out of Olin Shivers. I particularly liked the 9mm Sig-Sauer comment. That started a phase where I read through just about everything I could find written by Olin. His Scheme-related complier articles are definitely interesting reading.</p>
<p>After seeing Olin <a href="http://video.google.com/videoplay?docid=-3704713569771882785&hl=en">present</a> at <a href="http://www.cs.indiana.edu/dfried_celebration.html">Daniel P. Friedman's 60th birthday celebration</a>, I gained a new respect for the man. Simply, Olin is smart, funny, and very articulate. I'll think of him the next time I'm out shooting my 9mm Sig-Sauer.</p><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/6739154-7970898245779157988?l=www.findinglisp.com%2Fblog%2Findex.html' alt='' /></div>Dave Robertsnoreply@blogger.com3tag:blogger.com,1999:blog-6739154.post-68767012391043891872007-01-26T15:02:00.000-08:002007-01-28T16:21:37.937-08:00Meeting Richard Stallman<p>I had the nice opportunity to speak at the Pacific Free and Open Source Software Convention (<a href="http://www.pfosscon.org/2007/">PFOSSCON 2007</a>) in Honolulu, Hawai'i, last weekend. This was done as part of my job at <a href="http://www.vyatta.com/">Vyatta</a>. While I managed to acquire a cold after coming home, earlier this week, the conference was great. Kudos to Scott Belford, Jim Thompson, and Julian Yap for putting everything together.</p>
<p>Along with me speaking, the infamous Richard Stallman, Free Software Foundation, and Barton George, Sun Microsystems, spoke as well.</p>
<p>The summary is that after meeting Stallman, I wasn't very impressed. I have been reading his writings, such as the GNU Manifesto, since the mid-1980s. I'm not sure what I was expecting, but I didn't get it. My reaction to both the man and the message fall into a few broad categories. I think I'll blog in more detail about these things in the future sometime, but here are the broad reactions:</p>
<ul>
<li>Richard is not the best spokesman for the FSF. Sure, he founded the organization. And I wasn't expecting him to wear a shirt and tie. But to be honest, he's just a shabby guy. If you ever wonder why generally Free Software went nowhere inside corporate circles until Linux came along, this is one reason. Just at a personal level, Linus is a better spokes-model than Richard. He's just as geeky, without looking shabby.</li>
<li>I react very negatively to Richard's use of "GNU/Linux" versus "Linux." Richard's contention is that all the userland for Linux came from GNU and thus Linux is really just the kernel while the whole OS should be called "GNU/Linux." Whether that is true or not, the fact is, Linus built his own operating system and he should have the right to name it. If Free Software is truly as Free as Richard wants to claim it is, naming should be one of the things where the Freedom shows. Put another way, I have no issue if the FSF and GNU want to put out their own Linux distribution and name it "GNU/Linux," or even just "The GNU System," that's fine. I have big problems with Richard trying to convince me that I should tack "GNU" onto the <b>front</b> of "Linux" for some reason. I would worry that at any time Richard might claim that the use of GPL code might warrant changing the name of your application to "GNU/Foo." This is all the more annoying because Hurd <b><i>still</i></b> sucks and without Linux the overall goals of the original GNU project would still be unmet. Simply, this whole naming thing is a big case of sour grapes that Linux has been successful and has eclipsed GNU in terms of relevancy.</li>
<li>My other big takeaway from the conference is that I don't agree with Richard on the fundamental philosophy of free software. There, I said it. <b><i>HORRORS!</i></b>. And here I am at an open source company. Sorry, while I like open source and believe there are certain advantages to it, I specifically reject Richard's <b>moral</b> basis for Free Software. Richard tries to portray access to source code and redistribution for no charge as abstract moral rights that every person should have, something akin to "<a href="http://en.wikipedia.org/wiki/Life,_liberty_and_the_pursuit_of_happiness">life, liberty, and the pursuit of happiness</a>." Using proprietary software, Richard says, is to make an immoral choice. I don't buy it. I like using Linux better than Windows for a variety of reasons, but I don't believe the people at Microsoft are immoral because they choose to keep their source code to themselves (I do think some of Microsoft's monopoly business practices are immoral, but those are another matter). In my opinion, this is why the FSF has been largely ineffectual in getting people to think about "Free Software" as opposed to "Open Source" (a term which Richard rejects as missing the point). Simply, I don't think most of the developers or users of software see a philosophical, moral argument to made with respect to closed software. Again, I think Linus here wins hands-down as the leader of a large software movement because he focuses on the real issue: the open-source development model allows users to have more control and harnesses the innovation of a larger number of creative developers.</li>
</ul>
<p>Well, that's all for now. In spite of my disagreement with Richard, I bought a copy of <i><a href="http://www.amazon.com/gp/redirect.html?ie=UTF8&location=http%3A%2F%2Fwww.amazon.com%2FFree-Software-Society-Selected-Stallman%2Fdp%2F1882114981%2Fsr%3D8-1%2Fqid%3D1169855024%3Fie%3DUTF8%26s%3Dbooks&tag=findinglisp-20&linkCode=ur2&camp=1789&creative=9325">Free Software, Free Society</a><img src="http://www.assoc-amazon.com/e/ir?t=findinglisp-20&l=ur2&o=1" width="1" height="1" border="0" alt="" style="border:none !important; margin:0px !important;" /></i> from him and had him autograph it.</p><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/6739154-6876701239104389187?l=www.findinglisp.com%2Fblog%2Findex.html' alt='' /></div>Dave Robertsnoreply@blogger.com22tag:blogger.com,1999:blog-6739154.post-1167875542176931352007-01-03T17:02:00.000-08:002007-01-03T17:52:22.196-08:00D: By Jove, they almost have it!<p>When I first saw C++ back in the mid-1980s, it looked pretty interesting. Then it started to grow into a horrible monster. I was just reading about the <a href="http://www.digitalmars.com/d/">D programming language</a> today. All I can say is, "Wow!" I wish they had this way back when. This would seem to correct most of what I find distasteful about C, C++, and Java, while keeping most of the things I like--to the point where I would actually consider using it for certain projects.</p>
<p>The things I hate most about those programming languages are:</p>
<p><b>C</b></p>
<ul>
<li>No objects</li>
<li>Manual memory management only</li>
<li>Lame macros</li>
<li>Having to define header files</li>
</ul>
<p><b>C++</b></p>
<ul>
<li>Complex, obscure syntax that I can't ever remember completely without a copy of <em>The C++ Programming Language</em> sitting next to me</li>
<li>Complex resource management schemes to avoid leading memory/etc. in the presence of exceptions</li>
<li>Did I mention that I hate the complex syntax?</li>
</ul>
<p><b>Java</b></p>
<ul>
<li>(Almost) Everything is an object (but not quite)</li>
<li>Having to run in a VM with bytecodes even when you're writing something for a single platform and don't need or want to</li>
<li>No ability for structures to overlay memory for efficient access to C and network data wire protocol data structures, forcing the programmer to do bit-twiddling with ByteArray and shifts and masks</li>
</ul>
<p>In short, D looks interesting. Is it Lisp and would I go back to using D as my main programming language? No. It still doesn't have macros the way Lisp does and it doesn't have sexprs (yes, I really do like the parenthesis), but it is a better follow-on to C than C++ and still hits the system-programming domain that Java missed so bady. It seems like something to keep in one's hip pocket.</p><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/6739154-116787554217693135?l=www.findinglisp.com%2Fblog%2Findex.html' alt='' /></div>Dave Robertsnoreply@blogger.com2tag:blogger.com,1999:blog-6739154.post-1167872562707178912007-01-03T16:57:00.000-08:002007-01-03T17:02:42.733-08:00Hello 2007<p>Welcome to a new year. I have been swamped the past six months with <a href="http://www.vyatta.com/">work</a> and <a href="http://www.findinglisp.com/blog/2006/09/new-life.html">family</a>. I'm still getting a bit of time to work on Lisp-related stuff, but not nearly as much as I'd like.</p>
<p>The biggest casualty has been blogging. I just haven't had much time to sit down and compose something cogent. Back in October, Xach added the <a href="http://xach.livejournal.com/87767.html">sparklines</a> display to <a href="http://planet.lisp.org/">Planet Lisp</a>. My first thought regarding my own sparkline was "Yikes! I've seen people at the morgue with better EEGs than that!" Hopefully, Xach won't de-list me.</p>
<p>So, to kick off a new year, here's a post to make my sparkline wiggle a bit.</p><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/6739154-116787256270717891?l=www.findinglisp.com%2Fblog%2Findex.html' alt='' /></div>Dave Robertsnoreply@blogger.com0tag:blogger.com,1999:blog-6739154.post-1165375449632938012006-12-05T19:18:00.000-08:002006-12-05T19:24:09.656-08:00SBCL 0.9.18 and 1.0 RPMs available<p>Okay, so I was asleep at the switch. Way too much going on in my life right now. I got behind on SBCL RPMs for both <a href="http://www.fedoralisp.org/">FedoraLisp</a> and <a href="http://sourceforge.net/projects/sbcl/">SourceForge</a>. I have now built the 1.0 RPMs and uploaded them to both FedoraLisp and SourceForge. I also added a FC6 repo on FedoraLisp. Apologies for causing people trouble with that, too. For completeness, I also build an SBCL 0.9.18 RPM and uploaded it. If you find any bugs in 1.0, you can back off to 0.9.18 and see if the same problems exist there. Finally, there is a recent SLIME CVS RPM to go along with the 1.0 SBCL.</p>
<p>As always, enjoy! Feel free to send me feedback. At least the good news about people telling me that FC6 wasn't working and pestering me to get SBCL 1.0 built is I know people actually are using the repo. ;-)</p>
<p>As an aside, congrats to the SBCL team. You guys rock!</p><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/6739154-116537544963293801?l=www.findinglisp.com%2Fblog%2Findex.html' alt='' /></div>Dave Robertsnoreply@blogger.com2tag:blogger.com,1999:blog-6739154.post-1159659176268927112006-09-30T16:24:00.000-07:002006-09-30T16:32:56.293-07:00SBCL 0.9.17 RPM available<p>The latest SBCL 0.9.17 RPM is available at <a href="http://www.fedoralisp.org/">FedoraLisp</a>. There is also a recent SLIME CVS snapshot.</p><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/6739154-115965917626892711?l=www.findinglisp.com%2Fblog%2Findex.html' alt='' /></div>Dave Robertsnoreply@blogger.com2tag:blogger.com,1999:blog-6739154.post-1158900111966715962006-09-21T21:27:00.000-07:002006-09-21T21:41:51.993-07:00New life<p>Well, it happened again. Another addition to the family. For those keeping a count, this is number four. Hope Ruth Roberts was born on Monday, September 18. Mom and baby are home for the hospital and doing well. So much for writing code for the next couple of months. It's so hard to hold algorithms and data structures in your head with a baby crying in the background. She's so cute, I don't think I'll care. Another girl to wrap me around her finger.</p><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/6739154-115890011196671596?l=www.findinglisp.com%2Fblog%2Findex.html' alt='' /></div>Dave Robertsnoreply@blogger.com7tag:blogger.com,1999:blog-6739154.post-1156690791244696352006-08-27T07:58:00.000-07:002006-09-03T08:21:16.866-07:00SBCL 0.9.16 RPMs released<p>SBCL 0.9.16 and a recent SLIME CVS snapshot are up at <a href="http://www.fedoralisp.org/">FedoraLisp</a>. Enjoy!</p><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/6739154-115669079124469635?l=www.findinglisp.com%2Fblog%2Findex.html' alt='' /></div>Dave Robertsnoreply@blogger.com2