 |
|
|
|
|
|
|
|
|
|
The jaoo.dk conference is taking place in Århus these days and following this there was an interview with Lars Bak, one of the drivers behind the V8 Javscript engine, in a danish newsletter. Here he talks about the joys and wonders of dynamic typing over static ditto. He makes manay good points on how dynamic typing helps to increase programmer productivity. At least two of these points was something I had no thought so much about before. One was that the tools surrounding statically typed languages tends to be very phase oriented. You make a chance, compile, do a test run to see if it worked and then you get back to editing. Dynamic languages such as Lisp, Smalltalk or (I guess) Javascript allows you to work much more directly with the (running) program, interleaving thinking, editing and testing almost seemlessly. The other thought provoking point, one I also absolutely believes in, is that programmers working in dynamic languages tends to focus on the program logic whereas programmers working with static languages tends to focus on all of the much less important trimmings surrounding the logic. The bottom line,as he puts it, is that the bottleneck today is not those last 20-30 % of performance but rather programmer productivity and everything we can do to facilitate that should be pursued. And even if one does get concerned over performance, one should rather seek to solve the problems rather than giving up without trying. Lisp was not born as efficient as it is today (neither was C) but can not fix a problem if one does not try to fix it. Just a big a problem, I think, in many languages is the apperent view from the language designers that the biggest threat to the purity of the program is the programmer. This is most dominant in static languages where the type diciplines provides the language architect with a multitude of ways to fence those rascal programmers in but even in dynamic languages such as Erlang one can find traces of this. The logic seems to be that we want to prevent the programmers from making mistakes, and that logic is not as such flawed, there are mistakes you just do not make in a statically typed programming language. Unfortunately, the statement that a program is typecorrect is an incredible weak statement about its usefulness!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Leslie Polzer has posted an excellent little example on Getting started with CFFI. However, I think it deserves mentioning that playing around with FFI definitions is a grand way of getting to know a C library. Unlike C, Lisp is an interactive programming environment which means that you can slowly build up the necessary chunks of code, trying out stuff in order to properly understand what the various bits and pieces does. For this, 'getloadavg' (the example used in the aforementioned article) is actually too simple to properly relate to the power this gives you. Consider instead wanting to get to know something more involved such as OpenOBEX (for talking to your mobile phone) or SAF (for building highly available systems), then having an interactive environment is a tremendous benefit. Anybody who has tried to understand a complex C library by writing small snippets of C programs with printf's to demonstrate proper working should be able to appreciate the advantage of this. In fact, I think that the interactivity of Lisp is one of the top five secrets of why Lisp programmers are so darn productive. Rather than building up large suites of tests, we just try out constructs as we write the code and the code is correct from the outset (well, sort of) rather than having to go through a couple of iterations to weed out the silly mistakes. If I didn't have the REPL nearby, I know I would never ever use something as complicated as reduce, my head starts boiling everytime I have to construct even just a slightly complex 'reduce' expression, but being to able to iteratively build up and verify such expressions gives me the necessary confidence to stick it into my code anyway. In case you think that writing the initial boilerplate for a C library interface, you should check out something like the Verrazano/Fetter project. This is able to generate CFFI bindings by parsing C header files. The result is not necessarily perfect but certainly a good start. Verrazano is an old Google summer of Code of project and endured a slowdown but has again picked up steam and some of the problems in the initial implementation has been fixed in the curren instantiation; and I have found the developers to be very responsive on the mailing list when I reported some concerns. Highly Recommended (with a small salute to the Jerry Pournelle columns in Byte Magazine). Tags: lisp
Current Mood: Da.., this is a good red wine
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
I have pulled myself together and posted the pictures I took at the ILC07 on my web site. Some of the minatures on page 2 and 3 looks strange in my Safari but ok in Firefox. They should load ok however. In case you have been wondering about the site, whether it has become a study in how unstable a server can get, I should say that I hope it is better now. The server is set up here at home on my old Linux box running SBCL and AllegroServe. It is also using wireless LAN and it took me quite some time to realise that I am working at the very edge of the range of my el-cheapo netgear wlan router. Quote of the day: A quote from Ray Dillinger back in the spring of 2005, in relation to an announcement of the Boston Lisp Announcement Email List: Christopher C. Stacy: Weren't the bothons the fish people in Star Wars?
Ray Dillinger: You know, I've had a similar thought; except if I were to do it it would be the "Than Franthithco Lithp Utherth Thothiety."
Tags: ilc07, lisp
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
On the latest ACM TechNews newsletter, there was a reference to an InfoWorld story on the virtues of Dynamic Languages. The case is being made that the industry to a still greater extent turn to dynamic languages to tap into improved productivity. I am a great beliver in the promise of dynamic languages and I am here not just thinking of Lisp but dynamic languages in general including Ruby and Python that are among the ones mentioned in the article. In fact I am convinced that the next big thing in programming languages (whenever that will materialise itself) will be a dynamic language. Continuing through various links in the article I arrived at two other interesting sites: Tiobe which keeps score on language popularity based on web search engine statistics and the Language Shootout which maintains an impressive list of benchmarks implemented in various langauges. Obviously such things should not be overrated in importance (as the saying goes: there are lies, damn lies and benchmarks/statistics) but it is quite funny to look for Lisp there and compare to something like Erlang which seems to create quite a buzz, also i Lisp circles. Erlang actually fares a lot worse (according to the aforementioned websites) than I had imagined. In the Tiobe popularity index, the Lisp and scheme group is currently ranked 17 while Erlang is in the group of rank 51-100. Even if the entry named "CL" relates to a breakout of Common Lisp from the Lisp/Scheme grouping (which I do not think judging from the explanations), it is still at position 37 and thus before Erlang. In the all languages shootout SBCL is at ratio 1.9 compared to C where Erlangs best ratio is 4.2. Quote of the dayAmerican author Kurt Vonnegut died recently. From the danish blog (in danish) Harddisken I have scooped up the following quote: "If you really want to disappoint your parents, and don't have the nerve to be gay, go into the arts." Tags: lisp, programming
|
|
|
|
|
|
|
|
|
|
|
|
![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small}
clynbech's journal
Previous
sad