Plugged in my USB LaserJet, and it didn't work. I tried hp-setup and localhost:631, but it kept saying nothing was detected.
After some searching, I found out this was a big problem in Ubuntu 11.10.
My solution:
1. Installed the latest available Linux kernel.
2. Added the Ubuntu Precise repo in Synaptic, reloaded the package information, and installed the latest available cups package (also libgnutls and a few other cups-related packages).
3. Disabled the Precise repo. Failure to do so would lead to many tears after I completely messed up my OS.
4. Rebooted and tried hp-setup. Still didn't detect anything.
5. Went to localhost:631 and tried to detect a new printer. Nothing. Experienced an emotion similar to frustration but when you know you are eventually going to get it to work.
6. Entered "nano /var/log/syslog" at the command line after unplugging and replugging the printer. Scrolled to the bottom of the file. It gave me the printer's URI, showed the printer's name, and said it was "re-enabled".
7. Scratched my head.
8. Went back to localhost:631, clicked the "Administration" tab, clicked the "Manage Printers" tab, saw my printer listed. Felt strange emotions, one of which was joy that I had my printer detected, another of which was confusion, as in "is this interface designed optimally?"
9. Printed a test page. It worked.
10. Wrote a blog post in case someone else encounters the same problem.
Observations, solutions to problems, and even a few rants about Linux, free software, and computing in general
Friday, November 25, 2011
Monday, November 14, 2011
Wireless on Ubuntu 11.10 and Mint 12
Ubuntu 11.10 has managed to make the wireless internet on my laptop not work. They're great at introducing bugs that never get fixed: this is the only distro with that problem, and I try a lot of distros. The bug carried through to Mint 12 RC, which is of course built on top of Ubuntu 11.10.
I had to install wicd and completely remove network-manager. If you don't remove network-manager, you will get a "Connection Failed: Bad Password" error from wicd if you're using WPA2.
I had to install wicd and completely remove network-manager. If you don't remove network-manager, you will get a "Connection Failed: Bad Password" error from wicd if you're using WPA2.
Wednesday, November 02, 2011
Chainloading GRUB 2 from GRUB
I installed PCLinuxOS on my laptop (more on that some other time - I was impressed). Among the other OSes on there is Debian Squeeze. The problem is that Debian Squeeze uses Grub 2, while PCLinuxOS uses Grub.
After some fruitless searches and guesses as to what to do (Grub knowledge doesn't help much with Grub 2) I decided to check the Arch Wiki. As usual, the answer was there. Add the following entry to /boot/grub/menu.lst in PCLinuxOS:
title Debian
root (hd0,4)
kernel /boot/grub/core.img
where root (hd0,4) tells Grub that Debian is installed on /dev/sda5.
After some fruitless searches and guesses as to what to do (Grub knowledge doesn't help much with Grub 2) I decided to check the Arch Wiki. As usual, the answer was there. Add the following entry to /boot/grub/menu.lst in PCLinuxOS:
title Debian
root (hd0,4)
kernel /boot/grub/core.img
where root (hd0,4) tells Grub that Debian is installed on /dev/sda5.
Monday, October 31, 2011
Some additional perspectives on OOP
I did some research this weekend about OOP. I more or less took it for granted that OOP is what it is and didn't think much about it until just recently. Nothing new, but some links that I found interesting. I plan to add more when (if) I find them.
Paul Graham (the world's only celebrity Lisper)
Why Arc Isn't Especially Object-Oriented
The Hundred-Year Language
Joe Armstrong (creator of Erlang)
Ralph Johnson, Joe Armstrong on the State of OOP
Why OO Sucks
Jeff Atwood
Your Code: OOP or POO?
Karsten Wagner
OOP is Dead
Alan Kay (who coined the term)
Dr. Alan Kay on the Meaning of “Object-Oriented Programming”
prototypes vs classes was: Re: Sun's HotSpot
Generic programming vs object oriented programming
Type erasure
Object Orientation is a Hoax
Richard Gabriel and Guy Steele
Objects have failed
Objects have not failed
Other
Problems With Existing Oop Evidence
OOP Criticism
SICP (the course, not the book)
OOP in Scheme
OOP vs type classes
Haskell vs OOP
A fresh look at OOP with concurrent objects
Teaching FP to Freshmen (The comments are informative, as it's clear the OOP supporters are not willing to defend Java/C++-style OOP. Yet for all practical purposes Java/C++-style OOP is OOP.)
Bjarne Stroustrup keynote at GoingNative 2012 I can't find the quote right now, but Stroustrup makes it clear that C++ is much more than an OOP language. He says something along the lines of, "inheritance can sometimes be useful".
Stop Writing Classes
HN Discussion of Stop Writing Classes
Of course, there are alternatives to what is usually called OOP. As I've learned, it's tough to even get a definition of OOP.
Rifle-Oriented Programming with Clojure
I'm not anti-OOP. I just think there are better ways to do what is done in C++ or Java.
Paul Graham (the world's only celebrity Lisper)
Why Arc Isn't Especially Object-Oriented
The Hundred-Year Language
Joe Armstrong (creator of Erlang)
Ralph Johnson, Joe Armstrong on the State of OOP
Why OO Sucks
Jeff Atwood
Your Code: OOP or POO?
Karsten Wagner
OOP is Dead
Alan Kay (who coined the term)
Dr. Alan Kay on the Meaning of “Object-Oriented Programming”
prototypes vs classes was: Re: Sun's HotSpot
Generic programming vs object oriented programming
Type erasure
Object Orientation is a Hoax
Richard Gabriel and Guy Steele
Objects have failed
Objects have not failed
Other
Problems With Existing Oop Evidence
OOP Criticism
SICP (the course, not the book)
OOP in Scheme
OOP vs type classes
Haskell vs OOP
A fresh look at OOP with concurrent objects
Teaching FP to Freshmen (The comments are informative, as it's clear the OOP supporters are not willing to defend Java/C++-style OOP. Yet for all practical purposes Java/C++-style OOP is OOP.)
Bjarne Stroustrup keynote at GoingNative 2012 I can't find the quote right now, but Stroustrup makes it clear that C++ is much more than an OOP language. He says something along the lines of, "inheritance can sometimes be useful".
Stop Writing Classes
HN Discussion of Stop Writing Classes
Of course, there are alternatives to what is usually called OOP. As I've learned, it's tough to even get a definition of OOP.
Rifle-Oriented Programming with Clojure
I'm not anti-OOP. I just think there are better ways to do what is done in C++ or Java.
Friday, October 28, 2011
Restarting sound on Debian Squeeze
Finally found something that works. Many thanks to the author of this post.
sudo /etc/init.d/alsa-utils stop
sudo alsa force-reload
sudo /etc/init.d/alsa-utils start
sudo /etc/init.d/alsa-utils stop
sudo alsa force-reload
sudo /etc/init.d/alsa-utils start
Clojure and OOP, part II
I gave some thoughts about Clojure and OOP last week. Now that I've got a little spare time, I want to finish those thoughts.
First, I want to link to this post by Stuart Halloway. It was one of the first posts I read on Clojure (and potentially the first time I had heard of Clojure). Without it I may not have even bothered with Clojure. I'm not a big fan of OOP, and don't use it that much, but I didn't think I could completely give it up.
Encapsulation
I didn't address the issue of encapsulation at all in my previous post. That's because, to me, encapsulation has never been a big issue.* In C++, you declare the inner workings of your classes to be public, private, friends and probably some others that I don't know. It's similar to running a web service. You can't open everything to anyone who wants it.
To be honest, I've never been in a situation where it would have been worth the work to set up an elaborate system in which I define who gets access to what. If there is a piece of data that should be accessible to the outside world, why can't I just use getters and setters? If there's no "get" defined, then I shouldn't be accessing the data.
Maybe to better summarize my experience, I'm not disagreeing with the concept of restricting access to data. What I don't see is how declaring public, private, friends, and whatever, and all the complexity it adds, plus all the work it creates (you have to do it for every class) is better than getter and setter functions combined with common sense and a few simple rules. The C++ approach seems no more reasonable than Haskell's purity requirement. Trying to debug a complicated OOP program is no fun. Maybe I work on smaller projects and don't have ten million lines of code and a hundred programmers of varying quality working with me, so my observations don't carry over to those situations.
For what it's worth, here is Rich Hickey's answer to an interview question by Fogus: "Following that idea—some people are surprised by the fact that Clojure does not engage in data-hiding encapsulation on its types. Why did you decide to forgo data-hiding?"
(Warning: partial quote) "...And if you have a notion of “private”, you need corresponding notions of privilege and trust. And that adds a whole ton of complexity and little value, creates rigidity in a system, and often forces things to live in places they shouldn’t.... If people don’t have the sensibilities to desire to program to abstractions and to be wary of marrying implementation details, then they are never going to be good programmers."
I see nothing controversial about that perspective.
Clojure and Learning OOP
I included the word "learning" in the title of my earlier post. I would argue that Clojure is a much easier way to learn about the underlying concepts of objects (but using maps), polymorphism, and inheritance. These are concepts that every programmer should understand and use.
I would go further, though. Even if you want to use OOP in Java or C++, you're better off to start with Clojure. The advantage of Clojure over Java/C++ is that you can learn one thing at a time. It's very easy for anyone to understand what's going on when you introduce a single concept. With Clojure, the concepts are well-motivated.
In Java or C++ you get hit with everything at one time. There's a lot of coupling. The degree of difficulty rises very quickly with lines of code when someone is trying to learn something. Introducing the grouping of related data, methods, and the system of privileges all at once is not only too difficult, there's no motivation. I've been programming for decades, and I don't see a need for C++-style encapsulation. How is a new programmer supposed to understand?
Only then do you get into polymorphism and inheritance, concepts they have a reason to learn. Give me an hour with a new programmer and I'll have him doing polymorphism and inheritance, and he'll have at least a small understanding of what they are and why he'd want to use them. Then put him in a class on Java or C++ and he'll have no problems. That's why you're better off to start with Clojure even if the goal is to train them in a more "practical" language.
Parenthesis Whining
As an aside, for those who think the use of parenthesis makes Lisp unsuitable for teaching programming, let me present you with Hello World! in Java:
In Clojure, Hello World! is
One set of parenthesis vs two in the Java program. Plus the Java version has two sets of {}, class, public, static, void, System.out, and String[]. If that doesn't make a programming newbie vomit, nothing will.
As with my other post, I'll conclude by admitting I'm not an OOP expert. I appreciate any comments you might have.
* If it were, I would have to stop programming in R, because I'm not aware that R offers real encapsulation.
First, I want to link to this post by Stuart Halloway. It was one of the first posts I read on Clojure (and potentially the first time I had heard of Clojure). Without it I may not have even bothered with Clojure. I'm not a big fan of OOP, and don't use it that much, but I didn't think I could completely give it up.
Encapsulation
I didn't address the issue of encapsulation at all in my previous post. That's because, to me, encapsulation has never been a big issue.* In C++, you declare the inner workings of your classes to be public, private, friends and probably some others that I don't know. It's similar to running a web service. You can't open everything to anyone who wants it.
To be honest, I've never been in a situation where it would have been worth the work to set up an elaborate system in which I define who gets access to what. If there is a piece of data that should be accessible to the outside world, why can't I just use getters and setters? If there's no "get" defined, then I shouldn't be accessing the data.
Maybe to better summarize my experience, I'm not disagreeing with the concept of restricting access to data. What I don't see is how declaring public, private, friends, and whatever, and all the complexity it adds, plus all the work it creates (you have to do it for every class) is better than getter and setter functions combined with common sense and a few simple rules. The C++ approach seems no more reasonable than Haskell's purity requirement. Trying to debug a complicated OOP program is no fun. Maybe I work on smaller projects and don't have ten million lines of code and a hundred programmers of varying quality working with me, so my observations don't carry over to those situations.
For what it's worth, here is Rich Hickey's answer to an interview question by Fogus: "Following that idea—some people are surprised by the fact that Clojure does not engage in data-hiding encapsulation on its types. Why did you decide to forgo data-hiding?"
(Warning: partial quote) "...And if you have a notion of “private”, you need corresponding notions of privilege and trust. And that adds a whole ton of complexity and little value, creates rigidity in a system, and often forces things to live in places they shouldn’t.... If people don’t have the sensibilities to desire to program to abstractions and to be wary of marrying implementation details, then they are never going to be good programmers."
I see nothing controversial about that perspective.
Clojure and Learning OOP
I included the word "learning" in the title of my earlier post. I would argue that Clojure is a much easier way to learn about the underlying concepts of objects (but using maps), polymorphism, and inheritance. These are concepts that every programmer should understand and use.
I would go further, though. Even if you want to use OOP in Java or C++, you're better off to start with Clojure. The advantage of Clojure over Java/C++ is that you can learn one thing at a time. It's very easy for anyone to understand what's going on when you introduce a single concept. With Clojure, the concepts are well-motivated.
In Java or C++ you get hit with everything at one time. There's a lot of coupling. The degree of difficulty rises very quickly with lines of code when someone is trying to learn something. Introducing the grouping of related data, methods, and the system of privileges all at once is not only too difficult, there's no motivation. I've been programming for decades, and I don't see a need for C++-style encapsulation. How is a new programmer supposed to understand?
Only then do you get into polymorphism and inheritance, concepts they have a reason to learn. Give me an hour with a new programmer and I'll have him doing polymorphism and inheritance, and he'll have at least a small understanding of what they are and why he'd want to use them. Then put him in a class on Java or C++ and he'll have no problems. That's why you're better off to start with Clojure even if the goal is to train them in a more "practical" language.
Parenthesis Whining
As an aside, for those who think the use of parenthesis makes Lisp unsuitable for teaching programming, let me present you with Hello World! in Java:
class HelloWorldApp {
public static void main(String[] args) {
System.out.println("Hello World!");
}
}
In Clojure, Hello World! is
(println "Hello World!")
One set of parenthesis vs two in the Java program. Plus the Java version has two sets of {}, class, public, static, void, System.out, and String[]. If that doesn't make a programming newbie vomit, nothing will.
As with my other post, I'll conclude by admitting I'm not an OOP expert. I appreciate any comments you might have.
* If it were, I would have to stop programming in R, because I'm not aware that R offers real encapsulation.
Friday, October 21, 2011
Clojure, a great way to learn OOP
Edit: There are two parts to this post. You can read the second part here.
Clojure is not sold as an OOP language, but it is a great way to learn OOP concepts. I had the (mis)fortune of learning OOP by using C++. I actually tried to learn OOP with Java and Python, but the problem was that the examples were so completely pointless that I was able to learn how to do OOP in those languages, but I never learned what OOP actually is. I had to learn that while using C++ to do things that made sense.
I will admit that I'm not a big fan of OOP. I always read that it reduces complexity, that it makes it easier to model your problem, but in most cases I didn't see that the benefits outweighed the overhead.
I've learned something while using Clojure. Nobody really cares about OOP. We care about what OOP does for us, and you can get the benefits of OOP without the BS of C++/Java-style OOP. Objects and polymorphism are convenient. Clojure has made me realize that there are alternative (and IMO far better) ways to get the benefits of OOP.
Here's a quote from Practical Clojure by Luke VanderHart and Stuart Sierra (which I highly recommend if you have no knowledge of Clojure): "The most important example is that maps can do 90 percent of what objects do in an object-oriented program. What real difference is there between named properties of an object and a key/value pair in a map? As languages like Javascript (where objects are implemented as maps) demonstrate, very little." It was nice to see in print something that I've been realizing for myself.
Maps and multimethods are not only very easy to understand, it's tough to learn them without also knowing why you'd want to use them. There's so much formal BS with C++/Java OOP that someone new to the language can't really capture everything. With Clojure you do a lot less and get the same benefits. It's also a natural part of programming in Clojure, even if your program is only 40 lines long, which means it's perfect for introductory programming classes. OOP is sold in the C++/Java world as a way to handle large-scale programs. There's no reason for that to be the case.
It seems strange to say it, but using Clojure has pushed me in the direction of OOP.
{I am not claiming to be an expert in OOP. Take my comments as coming from someone who is a little bit more than a beginner when it comes to OOP. I'd love to hear your thoughts if you disagree. I might learn something.}
Clojure is not sold as an OOP language, but it is a great way to learn OOP concepts. I had the (mis)fortune of learning OOP by using C++. I actually tried to learn OOP with Java and Python, but the problem was that the examples were so completely pointless that I was able to learn how to do OOP in those languages, but I never learned what OOP actually is. I had to learn that while using C++ to do things that made sense.
I will admit that I'm not a big fan of OOP. I always read that it reduces complexity, that it makes it easier to model your problem, but in most cases I didn't see that the benefits outweighed the overhead.
I've learned something while using Clojure. Nobody really cares about OOP. We care about what OOP does for us, and you can get the benefits of OOP without the BS of C++/Java-style OOP. Objects and polymorphism are convenient. Clojure has made me realize that there are alternative (and IMO far better) ways to get the benefits of OOP.
Here's a quote from Practical Clojure by Luke VanderHart and Stuart Sierra (which I highly recommend if you have no knowledge of Clojure): "The most important example is that maps can do 90 percent of what objects do in an object-oriented program. What real difference is there between named properties of an object and a key/value pair in a map? As languages like Javascript (where objects are implemented as maps) demonstrate, very little." It was nice to see in print something that I've been realizing for myself.
Maps and multimethods are not only very easy to understand, it's tough to learn them without also knowing why you'd want to use them. There's so much formal BS with C++/Java OOP that someone new to the language can't really capture everything. With Clojure you do a lot less and get the same benefits. It's also a natural part of programming in Clojure, even if your program is only 40 lines long, which means it's perfect for introductory programming classes. OOP is sold in the C++/Java world as a way to handle large-scale programs. There's no reason for that to be the case.
It seems strange to say it, but using Clojure has pushed me in the direction of OOP.
{I am not claiming to be an expert in OOP. Take my comments as coming from someone who is a little bit more than a beginner when it comes to OOP. I'd love to hear your thoughts if you disagree. I might learn something.}
Monday, October 17, 2011
Installing a Network Printer on Scientific Linux 6.1
Took me a while to figure this out. Can't use the http://localhost:631 configuration window. Have to go to > System > Administration > Printing. Click on New. Click on Find Network Printer. Enter the IP address in the text box next to "Host...". Click on Find. The rest should be straightforward.
I had to find the IP address by printing the network configuration page from my HP wireless printer.
I had to find the IP address by printing the network configuration page from my HP wireless printer.
Friday, October 07, 2011
Adding existing Clojure files to a project in Counterclockwise
I haven't done this in a while, and it took me a while to find out how to do it again. {Insert rant about how things get done in the Java world.}
Under the project name, right-click on "src". Click on Import.... Under "General" click on "File System". Click next.
Click on the Browse... button and select the directory (has to be different from the current project directory). Check the boxes beside the names of the files you want to add.
Not exactly the most intuitive procedure, but par for the course in the Java world.
Under the project name, right-click on "src". Click on Import.... Under "General" click on "File System". Click next.
Click on the Browse... button and select the directory (has to be different from the current project directory). Check the boxes beside the names of the files you want to add.
Not exactly the most intuitive procedure, but par for the course in the Java world.
Tuesday, September 27, 2011
Why do I still use newLISP?
One of the big* unanswered questions in the world today is why I use newLISP if I am using Clojure. I use R because that's what I've been using for years, I use Fortran because I need speed, and I use Clojure because I want Lisp. So what does newLISP bring to the table when I'm already using Clojure?
Here are a few thoughts:
1. Java is heavy. For example, I work with sockets, and Clojure/Java is overkill for that.
2. You sometimes need an understanding of the Java classpath and all that jazz, and I don't possess that understanding. I can make it work (so far) but I'm not a Java developer and it gets to be a nuisance. The Java build system is a perfectly acceptable reason to avoid Clojure altogether.
3. Another is here:
http://stackoverflow.com/questions/840190/changing-the-current-working-directory-in-java
http://stackoverflow.com/questions/3921744/how-do-i-change-directory-in-command-line-with-clojure
I'm sure you can do what you need to do in Clojure, but I don't want the headache. With newLISP, it's straightforward, and I don't have to learn a new approach for no particular reason.
4. It's easy to call C libraries from newLISP (some of the time anyway). It hasn't been a pleasant experience when I've tried to call C from Java in the past. I'm well aware of SWIG, but SWIG is hardly a fun experience, it's just less painful than the alternatives.
I could add more examples, but the reasoning would be the same. It's partially a matter of scripting language vs full-blown programming language, and partially a matter of JVM vs native platform. I'm probably not going to use newLISP for a big simulation, but there are times that it is the best choice.
I'm not claiming Clojure or any other Lisp can't do these things. Further, I could use Python, Ruby, or Perl for all of my scripting needs. I just find newLISP to be the best solution for me.
* Definitions of big may vary.
Here are a few thoughts:
1. Java is heavy. For example, I work with sockets, and Clojure/Java is overkill for that.
2. You sometimes need an understanding of the Java classpath and all that jazz, and I don't possess that understanding. I can make it work (so far) but I'm not a Java developer and it gets to be a nuisance. The Java build system is a perfectly acceptable reason to avoid Clojure altogether.
3. Another is here:
http://stackoverflow.com/questions/840190/changing-the-current-working-directory-in-java
http://stackoverflow.com/questions/3921744/how-do-i-change-directory-in-command-line-with-clojure
I'm sure you can do what you need to do in Clojure, but I don't want the headache. With newLISP, it's straightforward, and I don't have to learn a new approach for no particular reason.
4. It's easy to call C libraries from newLISP (some of the time anyway). It hasn't been a pleasant experience when I've tried to call C from Java in the past. I'm well aware of SWIG, but SWIG is hardly a fun experience, it's just less painful than the alternatives.
I could add more examples, but the reasoning would be the same. It's partially a matter of scripting language vs full-blown programming language, and partially a matter of JVM vs native platform. I'm probably not going to use newLISP for a big simulation, but there are times that it is the best choice.
I'm not claiming Clojure or any other Lisp can't do these things. Further, I could use Python, Ruby, or Perl for all of my scripting needs. I just find newLISP to be the best solution for me.
* Definitions of big may vary.
Well, that was fast...
I just compiled newLISP on a quad-core machine. It took...4 seconds!
This is a case where it's actually faster to compile than to install from a repo.
Update: Thanks to the comment below, I can do it even faster:
1. Download the newLISP source:
http://newlisp.nfshost.com/downloads/
2. Extract the archive.
3. cd into newlisp-x.x.x
4. ./configure-alt
5. make -j 4
6. (As root) make install
Steps 4-6 took about 10 seconds.
[Deleted previous, now irrelevant steps]
This is a case where it's actually faster to compile than to install from a repo.
Update: Thanks to the comment below, I can do it even faster:
1. Download the newLISP source:
http://newlisp.nfshost.com/downloads/
2. Extract the archive.
3. cd into newlisp-x.x.x
4. ./configure-alt
5. make -j 4
6. (As root) make install
Steps 4-6 took about 10 seconds.
[Deleted previous, now irrelevant steps]
Friday, September 23, 2011
I look forward to using the D programming language in the future
Unfortunately, I don't know that I'm going to spend a lot of time on it right now. In many ways it's like Racket or Scheme. It's a solid language but it's just not at a point where it's reasonable to try to use it for work.
It needs a better website and better access to the outside world, i.e., more libraries. It's "sort of" compatible with C - dealing with C header files is a lot of work. If I want to install an extension in R or Python or some other language (in R they're called packages), they're easy to find and easy to install and get working properly. That's not really the case with D. Heck, it's hard to even tell if individual projects (most of which are partially done at best) are still active.
Hopefully these things will get worked out. I doubt that they will, unless a large corporation decides it has a reason to invest in D development, but I'll give it another try in a year and see if I feel more comfortable with it.
Yes, D is a better C++, but I'm not sure I'm looking for C++. For now I'm more than happy to push forward with my combination of Clojure, R, Fortran, and newLISP. Lisp is just more compatible with my brain.
Languages to learn over the next couple of years: Scala, OCaml, and Haskell. Other possibilities: Go, Factor, Forth, Pure. Even if I don't use a language for real tasks, it's never a bad thing to pick up some new approaches to old problems.
It needs a better website and better access to the outside world, i.e., more libraries. It's "sort of" compatible with C - dealing with C header files is a lot of work. If I want to install an extension in R or Python or some other language (in R they're called packages), they're easy to find and easy to install and get working properly. That's not really the case with D. Heck, it's hard to even tell if individual projects (most of which are partially done at best) are still active.
Hopefully these things will get worked out. I doubt that they will, unless a large corporation decides it has a reason to invest in D development, but I'll give it another try in a year and see if I feel more comfortable with it.
Yes, D is a better C++, but I'm not sure I'm looking for C++. For now I'm more than happy to push forward with my combination of Clojure, R, Fortran, and newLISP. Lisp is just more compatible with my brain.
Languages to learn over the next couple of years: Scala, OCaml, and Haskell. Other possibilities: Go, Factor, Forth, Pure. Even if I don't use a language for real tasks, it's never a bad thing to pick up some new approaches to old problems.
Monday, September 19, 2011
64-bit Firefox builds for Linux
Now that I'm running 64-bit Linux, the one problem I was bumping against was getting updates for Firefox. They've got their new schedule of releasing frequently. Some distros aren't keeping up - and probably for good reason, if they care about stability.
It was easy to find the nightly builds. That's actually pretty slick, with a new update coming through each day automatically. Well, it's slick unless you use your machine for work, in which case you don't want things to break. Oh, also, many of your extensions won't work. Not really what I'm after.
For some reason, Mozilla only provides 32-bit Linux builds on their download page. It will show a 32-bit download link even if your OS is 64-bit. After much searching, I found the 64-bit downloads:
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/
{This is probably something that everyone else already knows. I didn't. This way I can find it in the future.}
It was easy to find the nightly builds. That's actually pretty slick, with a new update coming through each day automatically. Well, it's slick unless you use your machine for work, in which case you don't want things to break. Oh, also, many of your extensions won't work. Not really what I'm after.
For some reason, Mozilla only provides 32-bit Linux builds on their download page. It will show a 32-bit download link even if your OS is 64-bit. After much searching, I found the 64-bit downloads:
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/
{This is probably something that everyone else already knows. I didn't. This way I can find it in the future.}
Tuesday, September 13, 2011
CUDA 4.0 on Scientific Linux 6.1
Edit: Further experimentation has indicated that you might run into trouble if you have multiple OSes on your machine. You need to boot with "rdblacklist=nouveau" appended to the line starting "kernel". That is done automatically if SL has control over Grub. If you use another OS that controls the boot manager, you will have to figure out how to make the change. I did battle with this on a machine where Mint, using Grub 2, controls booting.
I don't know much about Grub 2, so I solved the problem by reinstalling Grub from SL. For some reason, in that case, SL assigns a timeout value of 0 seconds, then chainloads the Grub 2 boot menu. It took me a while to figure out what was going on...
-- Original post follows --
I installed the nvidia driver as described in this post:
http://scientificlinuxforum.org/index.php?showtopic=15
using the command
yum --enablerepo=elrepo install kmod-nvidia
No problems after a reboot. I then installed the CUDA toolkit and SDK as described in the documentation. I got an error saying -lcuda could not be found when building the code samples. The solution was to make a symbolic link (as root) using
ln -s /usr/lib64/nvidia/libcuda.so /usr/lib64/libcuda.so
I then did "make" to build all the samples. I ran about half a dozen of them without any problems.
I've had my share of problems setting up CUDA. I'm happy it was so easy.
I don't know much about Grub 2, so I solved the problem by reinstalling Grub from SL. For some reason, in that case, SL assigns a timeout value of 0 seconds, then chainloads the Grub 2 boot menu. It took me a while to figure out what was going on...
-- Original post follows --
I installed the nvidia driver as described in this post:
http://scientificlinuxforum.org/index.php?showtopic=15
using the command
yum --enablerepo=elrepo install kmod-nvidia
No problems after a reboot. I then installed the CUDA toolkit and SDK as described in the documentation. I got an error saying -lcuda could not be found when building the code samples. The solution was to make a symbolic link (as root) using
ln -s /usr/lib64/nvidia/libcuda.so /usr/lib64/libcuda.so
I then did "make" to build all the samples. I ran about half a dozen of them without any problems.
I've had my share of problems setting up CUDA. I'm happy it was so easy.
Saturday, September 10, 2011
Calling a C shared library from D
As I said at the end of my post on C++ vs Fortran, I think D is a better language than C++. My preferred language is Lisp (newLISP for little jobs and Clojure for the heavy stuff). The more I play with D, though, the more I like it.
As good as the language is, there are some obvious problems - the website needs to be redone by a professional web designer, and the available libraries on dsource should be better organized so it's easier to find what you're looking for, dead projects thrown out or put into their own area, and a clear separation between the D1 and D2 projects. Even better would be to give some guidelines to contributors, and suggestions as to critical projects.
Until a few days ago I had been slowly learning D by reading The D Programming Language and porting C functions to D. I then decided that D is definitely worth having in my toolbox when I want a compiled language. To be practical I need to be able to link to C shared libraries.
This is such an important thing that you'd expect there to be a clear, easy-to-follow tutorial hitting you in the face as soon as you go to the website. Not really. It's not difficult at all to do. It's just that the information is scattered all around. I don't see any way that someone who does not have C/C++ experience can figure it out. That's a shame because a very good reason to use D is that you want to use a language that provides you with more than just access to the computer's memory (unlike C) and doesn't require a decade to achieve mediocrity (unlike C++).
So here's a simple example. This site shows how to make a .so using GCC. That's sufficient for our purposes. I called my shared library libmean.so.
On the D side, here is a file (dlinktoc.d) that calls the C function "mean":
import std.stdio;
extern (C) double mean(double a, double b);
void main() {
double a = 4.7;
double b = 7.6;
auto c = mean(a,b);
writeln("The mean is: ",c);
}
This is a typical D program except that I have included the extern (C) line to tell D that mean is a C function. I saved dlinktoc.d in the same directory as I created libmean.so.
The compiling and linking is similar to what you would do with a C program:
dmd dlinktoc.d -L./libmean.so
Running:
./dlinktoc
The mean is: 6.15
As good as the language is, there are some obvious problems - the website needs to be redone by a professional web designer, and the available libraries on dsource should be better organized so it's easier to find what you're looking for, dead projects thrown out or put into their own area, and a clear separation between the D1 and D2 projects. Even better would be to give some guidelines to contributors, and suggestions as to critical projects.
Until a few days ago I had been slowly learning D by reading The D Programming Language and porting C functions to D. I then decided that D is definitely worth having in my toolbox when I want a compiled language. To be practical I need to be able to link to C shared libraries.
This is such an important thing that you'd expect there to be a clear, easy-to-follow tutorial hitting you in the face as soon as you go to the website. Not really. It's not difficult at all to do. It's just that the information is scattered all around. I don't see any way that someone who does not have C/C++ experience can figure it out. That's a shame because a very good reason to use D is that you want to use a language that provides you with more than just access to the computer's memory (unlike C) and doesn't require a decade to achieve mediocrity (unlike C++).
So here's a simple example. This site shows how to make a .so using GCC. That's sufficient for our purposes. I called my shared library libmean.so.
On the D side, here is a file (dlinktoc.d) that calls the C function "mean":
import std.stdio;
extern (C) double mean(double a, double b);
void main() {
double a = 4.7;
double b = 7.6;
auto c = mean(a,b);
writeln("The mean is: ",c);
}
This is a typical D program except that I have included the extern (C) line to tell D that mean is a C function. I saved dlinktoc.d in the same directory as I created libmean.so.
The compiling and linking is similar to what you would do with a C program:
dmd dlinktoc.d -L./libmean.so
Running:
./dlinktoc
The mean is: 6.15
Wednesday, September 07, 2011
C++ vs Fortran
I've been wanting to put together a blog post about Fortran for a while now, but it never made it to the top of my list of priorities. I'm happy to see that someone named eric_t went ahead and put together a really nice page:
https://bitbucket.org/eric_t/modern-fortran/wiki/Home
So, predictably, the C++ mob showed up with their pitchforks to argue against the use of Fortran. (Actually, a lot of them were arguing against FORTRAN, demonstrating their ignorance.)
As someone who has used both C++ and Fortran for numerical programming, it's hard for me to think of a good reason to use C++ for this stuff.
Let me start out by explaining my perspective, which is what rarely happens in programming language debates. I write numerical programs that do statistical analysis, simulations, and various types of numerical analysis. Most of my programs are less than 5000 lines.
I don't know or care about comparisons of C++ against Fortran for 50 developers working with a codebase of a million lines. I work together with only a few others. I have no interest at all in software development. I write programs as necessary to feed myself.
C++ comes with the mother of all learning curves. I'm not talking about the fact that there's no complexity too large to fit into a C++ program (the language is more than happy to accommodate any desired level of complexity). Though of course that is a problem.
I'm talking about the ability to do basic things like linear algebra or writing functions. A Matlab user can convert to Fortran in about 10 minutes. Obviously you won't know very much, but in the time it takes to get used to the idea of compiling a program and specifying types for your variables, you can define two matrices and do a matrix multiplication in Fortran. The language was written for scientific computations. You can take a look at the gfortran manual to see all the built-in goodies that come with a Fortran compiler.
The bare minimum for doing the same exercise in C++ is that you have to get your hands on a library that does what you want. So you have to know about the existence of Eigen or another libary. Then you have to figure out how to call it. Then you have to figure out how to link to an external library. And the documentation is probably not that helpful. There are friendly C++ users for sure. It's just that you won't have a clue what they're telling you to do. They'll be telling you to set up a makefile. They'll be recommending that you look at Boost and talking about how great it is and you'll be all WTF.
All this mess because you wanted to try out C++ to do a simple matrix multiplication. In Matlab it was just a few lines. In C++ it's a month-long project.
And before you use that C++ library, are you really sure you won't end up with a memory leak? Do you even know what a memory leak is? It probably won't matter for your simple matrix multiplication, but it's real comforting to know that you should worry about such things in order to write such a simple program, isn't it?
Now that the numerical version of "Hello, World!" is out of the way, you can get on to real work. You need to start with a tutorial. Not a complete introduction to the language, of course, just a tutorial that will give you a basic understanding of the language.
An excellent tutorial (that has taught me a great deal) is C++ Primer Plus. I just pulled the Fifth Edition off my shelf. It's okay to just read through Chapter 17. You don't even have to read the appendices. The first 1039 pages of the book is enough for now.
You will have worked through Chapter 4, including the section on "Pointers and the Free Store" and "Pointers, Arrays, and Pointer Arithmetic". You'll have learned about "Dereferencing Pointers". You'll get to work through well-designed syntax like (page 308)
int sum(int (*ar2)[4], int size);
or (page 309)
*(*(ar2 + r) + c)
You'll learn about "Memory Models and Namespaces" in chapter 9. The topics include material useful to newbies like "Automatic Variables and the Stack".
Further along (page 677) you'll learn about "Inheritance and Dynamic Memory Allocation".
Maybe you can just learn the language a little bit at a time. Here's the thing. You really can't. You have to know a lot to read code written by others and to use libraries written by others. Complexity is never hidden behind the scenes with C++. You have to understand memory management before you write your first line of code.
You might think you'll just call libraries so you'll be okay. That's not programming in C++, but let's pretend it is. An easy library (written in C) to call is the GSL. You want to solve a system of equations. Here's the function call:
Then when you're done with your tutorial, at a minimum, you need to learn about templates and the STL. And, although not strictly necessary, you should pick up some books by Scott Meyers so you can learn about pitfalls of the language.
If you think I'm just some idiot blogger who doesn't know anything about programming, and don't want to take my word that C++ is too complex to be a reasonable language choice, take a look at this blog post:
http://gigamonkeys.wordpress.com/2009/10/16/coders-c-plus-plus/
It was not a group of mediocre developers too lazy to learn a programming language that he interviewed. From my perspective, Ken Thompson's comment is the most relevant:
"It certainly has its good points. But by and large I think it’s a bad language. It does a lot of things half well and it’s just a garbage heap of ideas that are mutually exclusive. Everybody I know, whether it’s personal or corporate, selects a subset and these subsets are different. So it’s not a good language to transport an algorithm—to say, “I wrote it; here, take it.” It’s way too big, way too complex."
If you can program in Matlab, you can program in Fortran. The same is not true for C++. The complexity is not optional: you just can't interact with the outside world without bumping into it.
The advice to use C++ goes something like this:
1. Spend ten years learning to write C++ programs.
2. Start writing all the programs that you could have been writing ten years ago using Fortran.
I understand what these C++ developers are going through. If I invested ten years of my life learning nearly 1% of the C++ language, I would be upset to find out that those ten years were wasted. I'd be looking for some way to make it feel as though I didn't flush ten years of my working life down the toilet.
There are better choices. For many things, Fortran is an excellent choice. It even has recursive functions and lets you specify that a function is pure. It's not Lisp but that does offer a bit of comfort to someone like me.
If you like the object oriented side of things, Java has closed the speed gap a lot (not that I like Java, but being a better choice than C++ is a low standard). There's also D and Objective-C. The more I use D the more I like it. You really should have your head examined if you have the choice between D and C++ and you choose C++ because you think it's a better language. There might be a different reason to use C++ (like, you're too stubborn to admit that your favorite language sucks) but it's definitely not the case that C++ is a better language.
There are languages like Scala (I've played with it a little but not done any real work, so I can't say much about it) and Clojure that have access to the JVM. You can do the performance critical parts in Java if necessary.
LuaJIT2 is really fast, and the upcoming GSL Shell will be based on LuaJIT2 (at least that's my understanding). Even the current version of GSL Shell does well for speed. PyPy is constantly improving as well. Both are excellent, if somewhat incomplete, choices.
C++? No way. There might be a few cases in which C++ is the best choice, but given the time investment required to learn C++, that is a very small set. If you factor in the time to learn the language, write/debug your program, revisit the program later to fix bugs/add features, and then compile and run programs, even pure interpreted Ruby is likely to be a better choice.
Update: I just watched an excellent presentation by Herb Sutter:
http://channel9.msdn.com/posts/C-and-Beyond-2011-Herb-Sutter-Why-C
He definitely makes a strong case for C++. I don't disagree with much of what he said, except that I think he overstates the speed gap for many tasks between C++ and languages like Java, though for the applications he's talking about the difference still matters. Interestingly, for those applications, developer time is almost irrelevant.
He never says C++ has replaced Fortran. In fact, at the beginning of the talk, he specifies that the three languages that can deliver the needed performance are C, C++, and Fortran. Later at that same conference, they talked about D:
http://channel9.msdn.com/posts/Scott-Meyers-Andrei-Alexandrescu-and-Herb-Sutter-C-and-Beyond
https://bitbucket.org/eric_t/modern-fortran/wiki/Home
So, predictably, the C++ mob showed up with their pitchforks to argue against the use of Fortran. (Actually, a lot of them were arguing against FORTRAN, demonstrating their ignorance.)
As someone who has used both C++ and Fortran for numerical programming, it's hard for me to think of a good reason to use C++ for this stuff.
Let me start out by explaining my perspective, which is what rarely happens in programming language debates. I write numerical programs that do statistical analysis, simulations, and various types of numerical analysis. Most of my programs are less than 5000 lines.
I don't know or care about comparisons of C++ against Fortran for 50 developers working with a codebase of a million lines. I work together with only a few others. I have no interest at all in software development. I write programs as necessary to feed myself.
C++ comes with the mother of all learning curves. I'm not talking about the fact that there's no complexity too large to fit into a C++ program (the language is more than happy to accommodate any desired level of complexity). Though of course that is a problem.
I'm talking about the ability to do basic things like linear algebra or writing functions. A Matlab user can convert to Fortran in about 10 minutes. Obviously you won't know very much, but in the time it takes to get used to the idea of compiling a program and specifying types for your variables, you can define two matrices and do a matrix multiplication in Fortran. The language was written for scientific computations. You can take a look at the gfortran manual to see all the built-in goodies that come with a Fortran compiler.
The bare minimum for doing the same exercise in C++ is that you have to get your hands on a library that does what you want. So you have to know about the existence of Eigen or another libary. Then you have to figure out how to call it. Then you have to figure out how to link to an external library. And the documentation is probably not that helpful. There are friendly C++ users for sure. It's just that you won't have a clue what they're telling you to do. They'll be telling you to set up a makefile. They'll be recommending that you look at Boost and talking about how great it is and you'll be all WTF.
All this mess because you wanted to try out C++ to do a simple matrix multiplication. In Matlab it was just a few lines. In C++ it's a month-long project.
And before you use that C++ library, are you really sure you won't end up with a memory leak? Do you even know what a memory leak is? It probably won't matter for your simple matrix multiplication, but it's real comforting to know that you should worry about such things in order to write such a simple program, isn't it?
Now that the numerical version of "Hello, World!" is out of the way, you can get on to real work. You need to start with a tutorial. Not a complete introduction to the language, of course, just a tutorial that will give you a basic understanding of the language.
An excellent tutorial (that has taught me a great deal) is C++ Primer Plus. I just pulled the Fifth Edition off my shelf. It's okay to just read through Chapter 17. You don't even have to read the appendices. The first 1039 pages of the book is enough for now.
You will have worked through Chapter 4, including the section on "Pointers and the Free Store" and "Pointers, Arrays, and Pointer Arithmetic". You'll have learned about "Dereferencing Pointers". You'll get to work through well-designed syntax like (page 308)
int sum(int (*ar2)[4], int size);
or (page 309)
*(*(ar2 + r) + c)
You'll learn about "Memory Models and Namespaces" in chapter 9. The topics include material useful to newbies like "Automatic Variables and the Stack".
Further along (page 677) you'll learn about "Inheritance and Dynamic Memory Allocation".
Maybe you can just learn the language a little bit at a time. Here's the thing. You really can't. You have to know a lot to read code written by others and to use libraries written by others. Complexity is never hidden behind the scenes with C++. You have to understand memory management before you write your first line of code.
You might think you'll just call libraries so you'll be okay. That's not programming in C++, but let's pretend it is. An easy library (written in C) to call is the GSL. You want to solve a system of equations. Here's the function call:
int (* f) (const gsl_vector *x, void *params, gsl_vector *f)
Then when you're done with your tutorial, at a minimum, you need to learn about templates and the STL. And, although not strictly necessary, you should pick up some books by Scott Meyers so you can learn about pitfalls of the language.
If you think I'm just some idiot blogger who doesn't know anything about programming, and don't want to take my word that C++ is too complex to be a reasonable language choice, take a look at this blog post:
http://gigamonkeys.wordpress.com/2009/10/16/coders-c-plus-plus/
It was not a group of mediocre developers too lazy to learn a programming language that he interviewed. From my perspective, Ken Thompson's comment is the most relevant:
"It certainly has its good points. But by and large I think it’s a bad language. It does a lot of things half well and it’s just a garbage heap of ideas that are mutually exclusive. Everybody I know, whether it’s personal or corporate, selects a subset and these subsets are different. So it’s not a good language to transport an algorithm—to say, “I wrote it; here, take it.” It’s way too big, way too complex."
If you can program in Matlab, you can program in Fortran. The same is not true for C++. The complexity is not optional: you just can't interact with the outside world without bumping into it.
The advice to use C++ goes something like this:
1. Spend ten years learning to write C++ programs.
2. Start writing all the programs that you could have been writing ten years ago using Fortran.
I understand what these C++ developers are going through. If I invested ten years of my life learning nearly 1% of the C++ language, I would be upset to find out that those ten years were wasted. I'd be looking for some way to make it feel as though I didn't flush ten years of my working life down the toilet.
There are better choices. For many things, Fortran is an excellent choice. It even has recursive functions and lets you specify that a function is pure. It's not Lisp but that does offer a bit of comfort to someone like me.
If you like the object oriented side of things, Java has closed the speed gap a lot (not that I like Java, but being a better choice than C++ is a low standard). There's also D and Objective-C. The more I use D the more I like it. You really should have your head examined if you have the choice between D and C++ and you choose C++ because you think it's a better language. There might be a different reason to use C++ (like, you're too stubborn to admit that your favorite language sucks) but it's definitely not the case that C++ is a better language.
There are languages like Scala (I've played with it a little but not done any real work, so I can't say much about it) and Clojure that have access to the JVM. You can do the performance critical parts in Java if necessary.
LuaJIT2 is really fast, and the upcoming GSL Shell will be based on LuaJIT2 (at least that's my understanding). Even the current version of GSL Shell does well for speed. PyPy is constantly improving as well. Both are excellent, if somewhat incomplete, choices.
C++? No way. There might be a few cases in which C++ is the best choice, but given the time investment required to learn C++, that is a very small set. If you factor in the time to learn the language, write/debug your program, revisit the program later to fix bugs/add features, and then compile and run programs, even pure interpreted Ruby is likely to be a better choice.
Update: I just watched an excellent presentation by Herb Sutter:
http://channel9.msdn.com/posts/C-and-Beyond-2011-Herb-Sutter-Why-C
He definitely makes a strong case for C++. I don't disagree with much of what he said, except that I think he overstates the speed gap for many tasks between C++ and languages like Java, though for the applications he's talking about the difference still matters. Interestingly, for those applications, developer time is almost irrelevant.
He never says C++ has replaced Fortran. In fact, at the beginning of the talk, he specifies that the three languages that can deliver the needed performance are C, C++, and Fortran. Later at that same conference, they talked about D:
http://channel9.msdn.com/posts/Scott-Meyers-Andrei-Alexandrescu-and-Herb-Sutter-C-and-Beyond
Friday, September 02, 2011
Gretl on Scientific Linux
I don't even use Gretl, but sometimes it needs to be available to others. That's why I created Gretl SlackBuilds, and now I have tried to build it for SL.
I pulled the following required packages from the Fedora build at
http://pkgs.fedoraproject.org/gitweb/?p=gretl.git;a=blob_plain;f=gretl.spec;hb=fe69e968cb87ca23907ba147a8071420f702a960
BuildRequires: desktop-file-utils
BuildRequires: gtk2-devel
BuildRequires: glib2-devel
BuildRequires: blas-devel
BuildRequires: fftw-devel
BuildRequires: gettext
BuildRequires: libxml2-devel
BuildRequires: gtksourceview-devel
BuildRequires: libgnomeui-devel
BuildRequires: lapack-devel
BuildRequires: readline-devel
BuildRequires: ncurses-devel
BuildRequires: gmp-devel
BuildRequires: mpfr-devel
BuildRequires: gnuplot
BuildRequires: gnu-free-sans-fonts
BuildRequires: bitstream-vera-sans-mono-fonts
BuildRequires: bitstream-vera-sans-fonts
I made sure all of that stuff was installed. Then I did
./configure --with-lapack-prefix=/usr
make -j 4
make check
make install (as root)
Be sure you have everything in the list above. I thought I did, but missed libgnomeui-devel. It compiled and installed, but I ended up with only gretlcli. It won't necessarily fail if you're missing something.
There are packages available on the Gretl homepage, but not 64-bit, which is why I did the compilation. Now if only I could figure out how to get ACML to work with Gretl...
I pulled the following required packages from the Fedora build at
http://pkgs.fedoraproject.org/gitweb/?p=gretl.git;a=blob_plain;f=gretl.spec;hb=fe69e968cb87ca23907ba147a8071420f702a960
BuildRequires: desktop-file-utils
BuildRequires: gtk2-devel
BuildRequires: glib2-devel
BuildRequires: blas-devel
BuildRequires: fftw-devel
BuildRequires: gettext
BuildRequires: libxml2-devel
BuildRequires: gtksourceview-devel
BuildRequires: libgnomeui-devel
BuildRequires: lapack-devel
BuildRequires: readline-devel
BuildRequires: ncurses-devel
BuildRequires: gmp-devel
BuildRequires: mpfr-devel
BuildRequires: gnuplot
BuildRequires: gnu-free-sans-fonts
BuildRequires: bitstream-vera-sans-mono-fonts
BuildRequires: bitstream-vera-sans-fonts
I made sure all of that stuff was installed. Then I did
./configure --with-lapack-prefix=/usr
make -j 4
make check
make install (as root)
Be sure you have everything in the list above. I thought I did, but missed libgnomeui-devel. It compiled and installed, but I ended up with only gretlcli. It won't necessarily fail if you're missing something.
There are packages available on the Gretl homepage, but not 64-bit, which is why I did the compilation. Now if only I could figure out how to get ACML to work with Gretl...
Rmpi on Scientific Linux 6.1
Update: No need to read my frustrated rant. Here's what I did to get Rmpi working on Scientific Linux 6.1 64-bit. It should also work on Red Hat Enterprise Linux 6.1 64-bit and CentOS 6.1 64-bit, though I've not tried, and would appreciate feedback if it doesn't work:
1. yum install openmpi openmpi-devel
2. If you don't have a working R installation: yum install R-core R-devel
3. From within R: install.packages("Rmpi",configure.args=c("--with-Rmpi-include=/usr/include/openmpi-x86_64","--with-Rmpi-libpath=/usr/lib64/openmpi/lib/","--with-Rmpi-type=OPENMPI"))
4. As root (at the command line, not in R) open /etc/ld.so.conf, add /usr/lib64/openmpi/lib, then run ldconfig.
-- Actual post plus rant follows --
Continuing on with my Scientific Linux trial, when I've got a few minutes to spare, I tried to install Rmpi. Oy. I guess I've been spoiled by Slackware (likely the best strategy is just to stick with Slackware 13.1).
First, I installed openmpi and openmpi-devel.
Then I tried installing Rmpi but got stupid errors about mpi.h not found. Went to Google. Wasted time. Went to Google some more. Wasted some more time. Should not be this dang difficult.
Finally, based on this:
http://www.cybaea.net/Blogs/Data/R-tips-Installing-Rmpi-on-Fedora-Linux.html
I was able to construct the magic incantation:
install.packages("Rmpi",configure.args=c("--with-Rmpi-include=/usr/include/openmpi-x86_64","--with-Rmpi-libpath=/usr/lib64/openmpi/lib/","--with-Rmpi-type=OPENMPI"))
Now hopefully it works. I was going to record here all the stuff that needs to be done to get a working SL 6.1 installation that can be used on other machines. It's turning out to be more work than I anticipated. Can it really be the case that nobody uses Rmpi on RHEL-based distros? Or am I just missing the easy way to do this? I thought Rocks Cluster was based on CentOS. Given the popularity of R, somebody must have done this already.
Edit: I also had to add /usr/lib64/openmpi/lib to /etc/ld.so.conf, then run ldconfig, all as root.
1. yum install openmpi openmpi-devel
2. If you don't have a working R installation: yum install R-core R-devel
3. From within R: install.packages("Rmpi",configure.args=c("--with-Rmpi-include=/usr/include/openmpi-x86_64","--with-Rmpi-libpath=/usr/lib64/openmpi/lib/","--with-Rmpi-type=OPENMPI"))
4. As root (at the command line, not in R) open /etc/ld.so.conf, add /usr/lib64/openmpi/lib, then run ldconfig.
-- Actual post plus rant follows --
Continuing on with my Scientific Linux trial, when I've got a few minutes to spare, I tried to install Rmpi. Oy. I guess I've been spoiled by Slackware (likely the best strategy is just to stick with Slackware 13.1).
First, I installed openmpi and openmpi-devel.
Then I tried installing Rmpi but got stupid errors about mpi.h not found. Went to Google. Wasted time. Went to Google some more. Wasted some more time. Should not be this dang difficult.
Finally, based on this:
http://www.cybaea.net/Blogs/Data/R-tips-Installing-Rmpi-on-Fedora-Linux.html
I was able to construct the magic incantation:
install.packages("Rmpi",configure.args=c("--with-Rmpi-include=/usr/include/openmpi-x86_64","--with-Rmpi-libpath=/usr/lib64/openmpi/lib/","--with-Rmpi-type=OPENMPI"))
Now hopefully it works. I was going to record here all the stuff that needs to be done to get a working SL 6.1 installation that can be used on other machines. It's turning out to be more work than I anticipated. Can it really be the case that nobody uses Rmpi on RHEL-based distros? Or am I just missing the easy way to do this? I thought Rocks Cluster was based on CentOS. Given the popularity of R, somebody must have done this already.
Edit: I also had to add /usr/lib64/openmpi/lib to /etc/ld.so.conf, then run ldconfig, all as root.
Thursday, September 01, 2011
gvim on Scientific Linux
Almost got the software I need. gvim is not gvim or vim-gtk, on Scientific Linux it is given in package vim-X11.
RKWard on Scientific Linux
Update: It's probably a good idea to put the summary up front. I even confused myself when installing on another computer this weekend.
Summary:
1. Install any of the above listed build dependencies that are not on your system.
2. Download the latest rkward source.
3. Unpack the source, enter the directory.
4. mkdir build; cd build
5. cmake .. -DCMAKE_INSTALL_PREFIX=`kde4-config --prefix`
6. make -j 4 (or however many processors you've got)
7. make install (as root)
8. Start RKWard. Click on >> Settings >> Configure RKWard
9. Add /usr/share/kde4/apps/rkward/all.pluginmap under the section titled "Select .pluginmap file(s)"
{The last step may not be needed. You'll know if it is when you open RKWard.}
-- Actual post follows --
As with LyX 2.0, I'm going to have to bite the bullet and build RKWard myself. A Google search for "building rkward" leads me to koji.
The requirements are listed as (omitting rmplibs):
I'm missing giflib-devel and kdelibs-devel on my system, so I install them. I download the rkward source and unpack it.
Following the instructions on this page:
http://sourceforge.net/apps/mediawiki/rkward/index.php?title=Building_RKWard_From_Source
I do the following.
mkdir build; cd build
cmake .. {I'm not specifying any options}
make -j 4
make install
It works (there's an entry for it under "Education") but not correctly. I get a message "Plugins are needed: you may manage these through "Settings->Configure RKWard"." Unfortunately no such option exists.
I look at the documentation again. I try
cmake .. -DCMAKE_INSTALL_PREFIX=`kde4-config --prefix`
make -j 4
make install
The plugins message still comes up, but now I've got a full menu and the ability to open files. I open >> Settings >> Configure RKWard and the menu is on Plugins. I added /usr/share/kde4/apps/rkward/all.pluginmap.
Now when I open RKWard there are no more error messages and everything works properly.
Summary:
1. Install any of the above listed build dependencies that are not on your system.
2. Download the latest rkward source.
3. Unpack the source, enter the directory.
4. mkdir build; cd build
5. cmake .. -DCMAKE_INSTALL_PREFIX=`kde4-config --prefix`
6. make -j 4 (or however many processors you've got)
7. make install (as root)
8. Start RKWard. Click on >> Settings >> Configure RKWard
9. Add /usr/share/kde4/apps/rkward/all.pluginmap under the section titled "Select .pluginmap file(s)"
{The last step may not be needed. You'll know if it is when you open RKWard.}
-- Actual post follows --
As with LyX 2.0, I'm going to have to bite the bullet and build RKWard myself. A Google search for "building rkward" leads me to koji.
The requirements are listed as (omitting rmplibs):
| R-devel >= 2.13.1 |
| cmake |
| desktop-file-utils |
| gettext |
| giflib-devel |
| kdelibs-devel |
| pcre-devel |
I'm missing giflib-devel and kdelibs-devel on my system, so I install them. I download the rkward source and unpack it.
Following the instructions on this page:
http://sourceforge.net/apps/mediawiki/rkward/index.php?title=Building_RKWard_From_Source
I do the following.
mkdir build; cd build
cmake .. {I'm not specifying any options}
make -j 4
make install
It works (there's an entry for it under "Education") but not correctly. I get a message "Plugins are needed: you may manage these through "Settings->Configure RKWard"." Unfortunately no such option exists.
I look at the documentation again. I try
cmake .. -DCMAKE_INSTALL_PREFIX=`kde4-config --prefix`
make -j 4
make install
The plugins message still comes up, but now I've got a full menu and the ability to open files. I open >> Settings >> Configure RKWard and the menu is on Plugins. I added /usr/share/kde4/apps/rkward/all.pluginmap.
Now when I open RKWard there are no more error messages and everything works properly.
LyX 2.0 on Scientific Linux
I'm giving Scientific Linux a try. While it's a nice looking distro, I'm disappointed that rkward is not available at all, and LyX is still stuck in the 1.6.x series. I'm trying to build LyX 2.0. This is my experience - for my own reference, but if it helps someone else, even better. Google did not provide directions.
yum-builddep lyx doesn't work. Even though I've got the source repos enabled, and used yumdownloader to download the source rpm, I get the message
No source RPM found for lyx-1.6.10-1.el6.x86_64
It would be nice to have (useful) documentation. I am new to the RHEL-based distros so I have no idea what I'm doing.
My initial ./configure says
** moc 4 binary not found !
** uic 4 binary not found !
** qt 4 library not found !
I'm installing qt-devel. I don't see a collection for KDE or Qt development in the package manager GUI, so that's my best guess.
A search for moc turns up automoc, "Automatic moc for Qt 4". Hopefully that's it.
The top result in a search for uic - which I've never heard of before - is basket. I'm pretty sure that's not what I need. Scrolling through the entire list does not bring up anything helpful. A Google search for "lyx uic" turns up nothing helpful. "qt uic" gives background about the "User Interface Compiler" but not anything that solves my problem. "rhel uic" indicates PyQt4 might do the trick.That's what I try. Doesn't seem like the optimal choice, but if it works, I'll take it.
"Configuration of LyX was successful." Awesome!
make - completes with no errors
make install - completes with no errors
I've got a menu item for LyX. Open it up, it's 2.0, everything works.
Summary (can probably improve on the choice of build dependencies, but I have no time or interest in digging into it further - what I've got works)
1. Install qt-devel PyQt4 automoc
2. Download the latest LyX source.
3. Unpack the source and enter the new directory.
4. ./configure
5. make
6. make install (as root)
yum-builddep lyx doesn't work. Even though I've got the source repos enabled, and used yumdownloader to download the source rpm, I get the message
No source RPM found for lyx-1.6.10-1.el6.x86_64
It would be nice to have (useful) documentation. I am new to the RHEL-based distros so I have no idea what I'm doing.
My initial ./configure says
** moc 4 binary not found !
** uic 4 binary not found !
** qt 4 library not found !
I'm installing qt-devel. I don't see a collection for KDE or Qt development in the package manager GUI, so that's my best guess.
A search for moc turns up automoc, "Automatic moc for Qt 4". Hopefully that's it.
The top result in a search for uic - which I've never heard of before - is basket. I'm pretty sure that's not what I need. Scrolling through the entire list does not bring up anything helpful. A Google search for "lyx uic" turns up nothing helpful. "qt uic" gives background about the "User Interface Compiler" but not anything that solves my problem. "rhel uic" indicates PyQt4 might do the trick.That's what I try. Doesn't seem like the optimal choice, but if it works, I'll take it.
"Configuration of LyX was successful." Awesome!
make - completes with no errors
make install - completes with no errors
I've got a menu item for LyX. Open it up, it's 2.0, everything works.
Summary (can probably improve on the choice of build dependencies, but I have no time or interest in digging into it further - what I've got works)
1. Install qt-devel PyQt4 automoc
2. Download the latest LyX source.
3. Unpack the source and enter the new directory.
4. ./configure
5. make
6. make install (as root)
Friday, August 12, 2011
I am not afraid to admit that I've used Lisp for real work
[Really long post, but I don't see how to break it into smaller pieces. I wrote it a few weeks ago. I didn't want to post it at that time because I wrote some negative things about certain Lisp implementations. I took out a few of the negative comments, but most of them are still there. I stand by my opinions. You're free to have your own opinions, just like me, but I don't publish comments with swear words. I also don't publish comments that are uncivil or completely uninformative.]
As is the case with most programmers, I'd heard of Lisp, but didn't take it seriously because it was always presented as a dead language. Many of those comments came from former Lisp users. Lisp was just not up to the standards of "modern" languages, like Java, C++, Python, Ruby, (add your favorite language). Lots of nostalgia, but they'd made peace with the death of Lisp the way you make peace with the death of a pet dog when you're in middle school.
As is also the case for many programmers, I came upon the writings of Paul Graham and decided that Lisp might be worthy of further exploration. Then I read that the only app anyone admits having written in Lisp was later rewritten in Python. (That's only a slight exaggeration.)
It's hard to come upon examples of the use of Lisp the way you can find examples of Ruby, Python, or even Tcl.
Let me proudly say that I'm not afraid to write programs in Lisp. My situation is different from, say, a web developer for a Fortune 500 corporation. I do numerical programming. I get paid to do simulations, statistical analysis, and a variety of other types of numerical analysis.
I have one of the best jobs in the world. I am free to choose my programming language. It makes no difference if I'm the only programmer in the world using a particular language. Most of the programs I write are less than a few thousand lines, and most of the time, they are almost independent of all the other programs I write. In other words, what matters is that the program I write for a specific task does its job for that task and that task alone. Yep, I do scripting.
Which languages do I use? If you have read other posts on this blog (making you part of a very small group) you know R is what I use most often. Yet I love Lisp and plan to do a lot more Lisp programming going forward. I would not be surprised if five years from now Lisp was my main programming language.
Lisp is a great language and you too can trust it if you write numerical programs of 5000 lines or less. You can probably trust it for other tasks as well but I don't have such an experience with Lisp. Please tell the world that Lisp is a great language for numerical/statistical analysis. Those who dismiss it are wrong. There's absolutely no reason to not give it a trial. See what libraries are available. Look at some code written by others. It never hurts to learn another language, and if you have used only Matlab, you will learn a hell of a lot about programming even if the only thing you do is read The Scheme Programming Language without writing a single line of Lisp code. You have a lot to gain and nothing to lose. I guarantee it.*
Now that I've given a little background, I'd like to discuss the question of which Lisp to use. There are a number of alternatives in the Lisp world. The choice can be confusing to beginners, which would have included me not that long ago. I will briefly discuss four of the available options: Common Lisp, Scheme, Clojure, and newLISP.
Common Lisp: This one is often described as the "industrial strength" Lisp. In many cases, someone will just say "Lisp" when in fact they are referring to Common Lisp. My assessment of Common Lisp is that it's what you'd have if you start with Java, take out most of the good stuff, add on some Lisp features in the clumsiest possible way, and leave changes to a political process that ensures change will never happen.
Common Lisp is sort of the Oldsmobile of programming languages. It was good relative to the alternatives in the mid-80's, but then it stagnated, leading to its downfall.
There are some advantages. It's the only Lisp that's ever been popular in the enterprise. There's a lot of documentation available. There are a lot of libraries available. Some of the compilers have the potential to produce really fast code. There are, possibly surprisingly to the outsider, a lot of programmers who have used Common Lisp. That helps to the extent that you need to interact with other Lisp users, say to ask questions.
The community is a serious drawback. While most of the community is great, they haven't figured out how to control a vocal few.
My opinion: Stay away from Common Lisp as a beginner. The user community is stuck in the disco era. You can always try it later if you want. If you try only Common Lisp you will agree with those who say Lisp is not a suitable alternative to today's more popular languages. It had its chance to be popular, it failed spectacularly, and it failed spectacularly for a reason. If you have a beard and 15 years of Unix experience, you will probably feel right at home, so my advice doesn't apply to you.
Scheme: My first use of Scheme to any degree was going through SICP. Absolutely awesome experience.
I've written elsewhere about the big problem with Scheme. It's elegant, but the core language is too small to do anything useful, and the extensions are of exceptionally low quality, with some of the worst documentation of any product in the western hemisphere.
Scheme is an excellent language for teaching programming. The Scheme developers do not have an incentive to put together high-quality, properly documented language extensions. This is what you will encounter if you read the documentation on a Scheme extension:
foo [option] name code
foo transforms name into code. You can set options as desired.
Section 5 of the Scheme specification prohibits the use of informative examples when documenting functions. The 80th time I had to look at source code to figure out what an extension did was when I gave up on Scheme.
The developers of Scheme extensions are happy when they can say, "It is possible to do X" for any choice of X. To be useful, they'd need to be able to say, "It is possible to do X in a reasonable amount of time with a reasonable amount of effort." You sure as heck don't want to be relying on a piece of code and then find out that it's not doing what you thought it was, and have no idea how to fix the problem. That's when you start thinking about the reaction of your family if you get fired.
And no, Racket is not different in that regard, the extensions are a complete mess and the examples, if they exist at all, are unlikely to help much. This is not a criticism of Scheme or Racket. They are intended to be used as tools for teaching and research. I'm fine with that. There are other choices available. If you are learning Lisp do not get frustrated that Scheme/Racket can't do what you need. That does not mean Lisp is a bad choice of language.
Clojure: This is one awesome language. It's a modern Lisp. Not only is the language awesome, but the creator, Rich Hickey, has a lot of interesting things to say. You can tell that he has been in the trenches for a long time doing real programming, yet he is excited to incorporate ideas from the academic community.
Oh, Clojure also runs on the JVM, meaning you have access to everything provided by the king of enterprise programming languages. There are several good Clojure books out already, and more are on the way. There is serious upside both in terms of the language and the prospects for a career writing Lisp programs.
There are at least two downsides. The first is that using Clojure almost guarantees you will be bringing in some Java. That means many of the bad things about Java apply to Clojure as well. With time, Clojure is likely to develop its own libraries, which will minimize the Java drawbacks. The second downside is that the development tools are not mature, as you should expect with such a young language.
newLISP: Ultimately, I have come to like newLISP the best. newLISP is unmatched in the Lisp world in terms of documentation. After dealing with Common Lisp and Scheme documentation, I was shocked at the quality and quantity of examples that come with newLISP. You can learn to do everything the language does with little difficulty.
Another attractive feature of newLISP is that Common Lisp programmers criticize it for failing to meet their definition of being a "real" Lisp. That's a good sign, because Common Lisp has failed, so if you want to put together a language programmers actually want to use you better do some things differently from Common Lisp. newLISP lets you get work done quickly and correctly, and that's the only reason I've ever used a programing language.
As a scripting language, newLISP is not a competitor to either Common Lisp or Clojure. It is not a speed demon, but if you're using a scripting language, you obviously should not expect the speed of C or Java. It does quite well in terms of speed relative to other scripting languages I've used including Tcl and Python.
For most Linux distributions you will have to compile it yourself. However, that is easy (almost trivial - just follow the directions) and extremely fast (measured in seconds rather than minutes).
The bottom line: If you want to get started with Lisp for real world projects and have programming experience, install newLISP and try it out. The documentation on the website will definitely help you to get going quickly.
If you want to learn to program, install Racket, and use drracket with SICP. Any Scheme will also do.
If you want something suitable for the enterprise, get one of the Clojure books and give that a try.
Although I don't have any recommend uses for Common Lisp, there are many resources available if you want to go that route. CLISP is a good choice, but keep in mind that it does not come with a compiler. I will add that Land of Lisp is a very, very good book (and recent to boot) that will be one of the best purchases you ever make.
The decision of which Lisp is not as big as it might seem. You can carry a lot of your knowledge from one to the other. The best strategy may well be to study all of them. Whichever you choose you will be happy with your choice - even if that choice turns out to be Common Lisp.
*I'm an anonymous blogger, so don't expect my guarantee to mean much.
As is the case with most programmers, I'd heard of Lisp, but didn't take it seriously because it was always presented as a dead language. Many of those comments came from former Lisp users. Lisp was just not up to the standards of "modern" languages, like Java, C++, Python, Ruby, (add your favorite language). Lots of nostalgia, but they'd made peace with the death of Lisp the way you make peace with the death of a pet dog when you're in middle school.
As is also the case for many programmers, I came upon the writings of Paul Graham and decided that Lisp might be worthy of further exploration. Then I read that the only app anyone admits having written in Lisp was later rewritten in Python. (That's only a slight exaggeration.)
It's hard to come upon examples of the use of Lisp the way you can find examples of Ruby, Python, or even Tcl.
Let me proudly say that I'm not afraid to write programs in Lisp. My situation is different from, say, a web developer for a Fortune 500 corporation. I do numerical programming. I get paid to do simulations, statistical analysis, and a variety of other types of numerical analysis.
I have one of the best jobs in the world. I am free to choose my programming language. It makes no difference if I'm the only programmer in the world using a particular language. Most of the programs I write are less than a few thousand lines, and most of the time, they are almost independent of all the other programs I write. In other words, what matters is that the program I write for a specific task does its job for that task and that task alone. Yep, I do scripting.
Which languages do I use? If you have read other posts on this blog (making you part of a very small group) you know R is what I use most often. Yet I love Lisp and plan to do a lot more Lisp programming going forward. I would not be surprised if five years from now Lisp was my main programming language.
Lisp is a great language and you too can trust it if you write numerical programs of 5000 lines or less. You can probably trust it for other tasks as well but I don't have such an experience with Lisp. Please tell the world that Lisp is a great language for numerical/statistical analysis. Those who dismiss it are wrong. There's absolutely no reason to not give it a trial. See what libraries are available. Look at some code written by others. It never hurts to learn another language, and if you have used only Matlab, you will learn a hell of a lot about programming even if the only thing you do is read The Scheme Programming Language without writing a single line of Lisp code. You have a lot to gain and nothing to lose. I guarantee it.*
Now that I've given a little background, I'd like to discuss the question of which Lisp to use. There are a number of alternatives in the Lisp world. The choice can be confusing to beginners, which would have included me not that long ago. I will briefly discuss four of the available options: Common Lisp, Scheme, Clojure, and newLISP.
Common Lisp: This one is often described as the "industrial strength" Lisp. In many cases, someone will just say "Lisp" when in fact they are referring to Common Lisp. My assessment of Common Lisp is that it's what you'd have if you start with Java, take out most of the good stuff, add on some Lisp features in the clumsiest possible way, and leave changes to a political process that ensures change will never happen.
Common Lisp is sort of the Oldsmobile of programming languages. It was good relative to the alternatives in the mid-80's, but then it stagnated, leading to its downfall.
There are some advantages. It's the only Lisp that's ever been popular in the enterprise. There's a lot of documentation available. There are a lot of libraries available. Some of the compilers have the potential to produce really fast code. There are, possibly surprisingly to the outsider, a lot of programmers who have used Common Lisp. That helps to the extent that you need to interact with other Lisp users, say to ask questions.
The community is a serious drawback. While most of the community is great, they haven't figured out how to control a vocal few.
My opinion: Stay away from Common Lisp as a beginner. The user community is stuck in the disco era. You can always try it later if you want. If you try only Common Lisp you will agree with those who say Lisp is not a suitable alternative to today's more popular languages. It had its chance to be popular, it failed spectacularly, and it failed spectacularly for a reason. If you have a beard and 15 years of Unix experience, you will probably feel right at home, so my advice doesn't apply to you.
Scheme: My first use of Scheme to any degree was going through SICP. Absolutely awesome experience.
I've written elsewhere about the big problem with Scheme. It's elegant, but the core language is too small to do anything useful, and the extensions are of exceptionally low quality, with some of the worst documentation of any product in the western hemisphere.
Scheme is an excellent language for teaching programming. The Scheme developers do not have an incentive to put together high-quality, properly documented language extensions. This is what you will encounter if you read the documentation on a Scheme extension:
foo [option] name code
foo transforms name into code. You can set options as desired.
Section 5 of the Scheme specification prohibits the use of informative examples when documenting functions. The 80th time I had to look at source code to figure out what an extension did was when I gave up on Scheme.
The developers of Scheme extensions are happy when they can say, "It is possible to do X" for any choice of X. To be useful, they'd need to be able to say, "It is possible to do X in a reasonable amount of time with a reasonable amount of effort." You sure as heck don't want to be relying on a piece of code and then find out that it's not doing what you thought it was, and have no idea how to fix the problem. That's when you start thinking about the reaction of your family if you get fired.
And no, Racket is not different in that regard, the extensions are a complete mess and the examples, if they exist at all, are unlikely to help much. This is not a criticism of Scheme or Racket. They are intended to be used as tools for teaching and research. I'm fine with that. There are other choices available. If you are learning Lisp do not get frustrated that Scheme/Racket can't do what you need. That does not mean Lisp is a bad choice of language.
Clojure: This is one awesome language. It's a modern Lisp. Not only is the language awesome, but the creator, Rich Hickey, has a lot of interesting things to say. You can tell that he has been in the trenches for a long time doing real programming, yet he is excited to incorporate ideas from the academic community.
Oh, Clojure also runs on the JVM, meaning you have access to everything provided by the king of enterprise programming languages. There are several good Clojure books out already, and more are on the way. There is serious upside both in terms of the language and the prospects for a career writing Lisp programs.
There are at least two downsides. The first is that using Clojure almost guarantees you will be bringing in some Java. That means many of the bad things about Java apply to Clojure as well. With time, Clojure is likely to develop its own libraries, which will minimize the Java drawbacks. The second downside is that the development tools are not mature, as you should expect with such a young language.
newLISP: Ultimately, I have come to like newLISP the best. newLISP is unmatched in the Lisp world in terms of documentation. After dealing with Common Lisp and Scheme documentation, I was shocked at the quality and quantity of examples that come with newLISP. You can learn to do everything the language does with little difficulty.
Another attractive feature of newLISP is that Common Lisp programmers criticize it for failing to meet their definition of being a "real" Lisp. That's a good sign, because Common Lisp has failed, so if you want to put together a language programmers actually want to use you better do some things differently from Common Lisp. newLISP lets you get work done quickly and correctly, and that's the only reason I've ever used a programing language.
As a scripting language, newLISP is not a competitor to either Common Lisp or Clojure. It is not a speed demon, but if you're using a scripting language, you obviously should not expect the speed of C or Java. It does quite well in terms of speed relative to other scripting languages I've used including Tcl and Python.
For most Linux distributions you will have to compile it yourself. However, that is easy (almost trivial - just follow the directions) and extremely fast (measured in seconds rather than minutes).
The bottom line: If you want to get started with Lisp for real world projects and have programming experience, install newLISP and try it out. The documentation on the website will definitely help you to get going quickly.
If you want to learn to program, install Racket, and use drracket with SICP. Any Scheme will also do.
If you want something suitable for the enterprise, get one of the Clojure books and give that a try.
Although I don't have any recommend uses for Common Lisp, there are many resources available if you want to go that route. CLISP is a good choice, but keep in mind that it does not come with a compiler. I will add that Land of Lisp is a very, very good book (and recent to boot) that will be one of the best purchases you ever make.
The decision of which Lisp is not as big as it might seem. You can carry a lot of your knowledge from one to the other. The best strategy may well be to study all of them. Whichever you choose you will be happy with your choice - even if that choice turns out to be Common Lisp.
*I'm an anonymous blogger, so don't expect my guarantee to mean much.
Monday, July 11, 2011
Why not use Scheme more?
Another observation post, probably not worth your time, but I want to express my thoughts. You've been warned.
I really first started using Scheme when I went through SICP. Well, I didn't make it all the way through, but I learned a lot in any event. When you've got masters like that to show you what can be done with Scheme/Lisp you wonder why everyone isn't using it.
As you can guess, I think I know why not everyone is using it. I primarily do numerical computing, so that is the set of features I consider when evaluating a new programming language. A couple of things stand out when I think about using Scheme rather than R and Fortran.
1. There is a lack of libraries. This is well known, sometimes called "the island problem".
2. There is a lack of data structures. If I want to do matrix algebra, I want to use a language that offers a matrix class as part of the language. I want to use a language that does matrix multiplication as part of the language. There are good reasons for that: less hassle, less chance of breakage when the core of the language changes, less chance that you're relying on an extension written by one individual that will stop working when he gets bored and moves on.
Item 1 is not as true as it used to be. The major Schemes have a lot of libraries available. There are also tools for wrapping C code, so honestly, any lack of libraries more or less reflects the small user base, rather than the other way around. If there were more interest, the libraries would appear quickly. There's just no interest.
Item 2 is still a problem and likely to remain so forever. I'm just not sure that a minor inconvenience is a major hurdle to adoption. Something like a standard set of libraries being available with each implementation would be a solution.
I've reconsidered the situation since discovering Clojure, and IMO the real problem with Scheme (any of them) is the sucky documentation. It stinks. It really, really stinks. {Clarification: Upon reading the post, I was not clear that I'm talking about the developers of Scheme extensions, not the developers of the core language itself. There exists very good documentation for the core language if you're doing the usual things.}
Have the Scheme documentation writers never heard of examples?
I've never seen a community that was so collectively clueless about how to write documentation. And I'm a Slackware user. I don't think anyone has ever complained about the excessive documentation that comes with Slackware.
I might even consider writing some documentation myself, if not for the fact that I can never get anything in Scheme to work, because the documentation sucks so bad. My philosophy is to just move on if I have to work too hard to figure something out. I've come to realize that developers that don't document their work very well are usually not good developers.
Let me elaborate on that point a bit. The software might work as intended, but the underlying code is only part of the project, and by itself has no value. A good design means I don't have to think too much to use it. And when I return to the code in a year, I'll be able to easily figure out what I did and how to extend it.
If I have to work for six hours to figure out how to call a simple function, that's a sign that at some point I'm going to find that my program isn't doing what I thought it was doing. At some point I'm going to say, "WTF? Why was that matrix transposed? It makes no sense." Of course there was no way I could have known that, and there's no way I will ever understand the philosophy driving the development of the library. Then a few seconds later I'll be terrified, "Hold on, if the developer would do something like that, how can I trust the other lines of code that I've been writing for the last two weeks? There's no freaking documentation!" Then I'll move on to a real language, redo everything, and be sure to avoid the mistake of trusting Scheme in the future.
Go to one of the popular Scheme implementations. Just pick one. They're all equally useless. Pick out an extension that does something you need for numerical computing. If there's documentation at all - and there may very well not be - try to use that documentation to write a program. Use all of the important "things" that the extension does. Use those important things in different ways, like you would actually use them in an actual programming exercise where you are actually trying to feed yourself. Can you even figure out how to call all of the functions properly in less than two weeks?
Most of the documentation is just a slopped-together list of functions and a short, content-free description that might (though in most cases probably won't) be sufficient to jog the memory of the developer himself as to what the function should do. There's no chance in hell that a programmer writing a program related to his career is going to spend enough time to figure out how to use the extension. Sure, there are hobbyists who will figure it out, but I'm talking about real work in an environment where money is on the line.
I cannot treat the developers of Scheme as real developers. They're not professionals. Some are, of course, but I'm talking averages here, and the average Scheme developer is of pretty low quality relative to the average Java developer. The average Scheme developer thinks he's much better than the average Java developer because he can use recursion properly and was smart enough to recognize the brilliance of Lisp. Great, but if you measure developer quality in terms of the value of the output in a given amount of programmer time, Scheme developers probably have a negative value, because most of what they do gets in the way of developers interested in making a product that does something of value.
Do I like Java? Not a chance in hell. If I had to choose between Scheme and Java to do something with money on the line, even assuming all the same libraries are available in Scheme and Java, which would I choose? I'd take Java in a second. Scheme could learn a lot from Java about working with beginners.
It's a shame that Scheme has been plagued by crappy documentation. There's no reason that Scheme, on technical merit, cannot be Java. The difference is that Java was written for business applications, and that required documentation, and they got it. The Scheme community has decided that working with beginners is not fun and it has caused Scheme to be viewed as a goofy artifact of the past, rather than the language of the future.
I really first started using Scheme when I went through SICP. Well, I didn't make it all the way through, but I learned a lot in any event. When you've got masters like that to show you what can be done with Scheme/Lisp you wonder why everyone isn't using it.
As you can guess, I think I know why not everyone is using it. I primarily do numerical computing, so that is the set of features I consider when evaluating a new programming language. A couple of things stand out when I think about using Scheme rather than R and Fortran.
1. There is a lack of libraries. This is well known, sometimes called "the island problem".
2. There is a lack of data structures. If I want to do matrix algebra, I want to use a language that offers a matrix class as part of the language. I want to use a language that does matrix multiplication as part of the language. There are good reasons for that: less hassle, less chance of breakage when the core of the language changes, less chance that you're relying on an extension written by one individual that will stop working when he gets bored and moves on.
Item 1 is not as true as it used to be. The major Schemes have a lot of libraries available. There are also tools for wrapping C code, so honestly, any lack of libraries more or less reflects the small user base, rather than the other way around. If there were more interest, the libraries would appear quickly. There's just no interest.
Item 2 is still a problem and likely to remain so forever. I'm just not sure that a minor inconvenience is a major hurdle to adoption. Something like a standard set of libraries being available with each implementation would be a solution.
I've reconsidered the situation since discovering Clojure, and IMO the real problem with Scheme (any of them) is the sucky documentation. It stinks. It really, really stinks. {Clarification: Upon reading the post, I was not clear that I'm talking about the developers of Scheme extensions, not the developers of the core language itself. There exists very good documentation for the core language if you're doing the usual things.}
Have the Scheme documentation writers never heard of examples?
I've never seen a community that was so collectively clueless about how to write documentation. And I'm a Slackware user. I don't think anyone has ever complained about the excessive documentation that comes with Slackware.
I might even consider writing some documentation myself, if not for the fact that I can never get anything in Scheme to work, because the documentation sucks so bad. My philosophy is to just move on if I have to work too hard to figure something out. I've come to realize that developers that don't document their work very well are usually not good developers.
Let me elaborate on that point a bit. The software might work as intended, but the underlying code is only part of the project, and by itself has no value. A good design means I don't have to think too much to use it. And when I return to the code in a year, I'll be able to easily figure out what I did and how to extend it.
If I have to work for six hours to figure out how to call a simple function, that's a sign that at some point I'm going to find that my program isn't doing what I thought it was doing. At some point I'm going to say, "WTF? Why was that matrix transposed? It makes no sense." Of course there was no way I could have known that, and there's no way I will ever understand the philosophy driving the development of the library. Then a few seconds later I'll be terrified, "Hold on, if the developer would do something like that, how can I trust the other lines of code that I've been writing for the last two weeks? There's no freaking documentation!" Then I'll move on to a real language, redo everything, and be sure to avoid the mistake of trusting Scheme in the future.
Go to one of the popular Scheme implementations. Just pick one. They're all equally useless. Pick out an extension that does something you need for numerical computing. If there's documentation at all - and there may very well not be - try to use that documentation to write a program. Use all of the important "things" that the extension does. Use those important things in different ways, like you would actually use them in an actual programming exercise where you are actually trying to feed yourself. Can you even figure out how to call all of the functions properly in less than two weeks?
Most of the documentation is just a slopped-together list of functions and a short, content-free description that might (though in most cases probably won't) be sufficient to jog the memory of the developer himself as to what the function should do. There's no chance in hell that a programmer writing a program related to his career is going to spend enough time to figure out how to use the extension. Sure, there are hobbyists who will figure it out, but I'm talking about real work in an environment where money is on the line.
I cannot treat the developers of Scheme as real developers. They're not professionals. Some are, of course, but I'm talking averages here, and the average Scheme developer is of pretty low quality relative to the average Java developer. The average Scheme developer thinks he's much better than the average Java developer because he can use recursion properly and was smart enough to recognize the brilliance of Lisp. Great, but if you measure developer quality in terms of the value of the output in a given amount of programmer time, Scheme developers probably have a negative value, because most of what they do gets in the way of developers interested in making a product that does something of value.
Do I like Java? Not a chance in hell. If I had to choose between Scheme and Java to do something with money on the line, even assuming all the same libraries are available in Scheme and Java, which would I choose? I'd take Java in a second. Scheme could learn a lot from Java about working with beginners.
It's a shame that Scheme has been plagued by crappy documentation. There's no reason that Scheme, on technical merit, cannot be Java. The difference is that Java was written for business applications, and that required documentation, and they got it. The Scheme community has decided that working with beginners is not fun and it has caused Scheme to be viewed as a goofy artifact of the past, rather than the language of the future.
Saturday, July 09, 2011
What's wrong with Clojure syntax?
Short post, not a lot of value.
I keep reading things about Clojure's syntax being ugly. I don't think that's the case at all. It's extremely consistent and easy to follow. Maybe I'm just weird, but I've always preferred Tcl for short scripts because I like the syntax. Sometimes the critics of Clojure/Lisp syntax are even Java programmers!
I keep reading things about Clojure's syntax being ugly. I don't think that's the case at all. It's extremely consistent and easy to follow. Maybe I'm just weird, but I've always preferred Tcl for short scripts because I like the syntax. Sometimes the critics of Clojure/Lisp syntax are even Java programmers!
Saturday, June 18, 2011
Calling R from Clojure
From what I've read and based on the time I've played around with it, Clojure looks like a very good language. There's no reason to praise it here. Just ask Google if you want to read some praise for Clojure.
For me, it is promising because it runs on the JVM and has complete access to existing Java code. That means it's both fast and will do most of what you want to do. (Scala fits into the same category. I will be checking out Scala in the future.)
In addition, it is a dialect of Lisp, which means I'm a huge fan of the syntax as wells as the approach to problem solving. I've enjoyed using Scheme in the past, but given the lack of libraries, Scheme is not suitable for the numerical programming I do. I'm aware of projects like Chicken Scheme and Gambit-C, and I know about Swig and their foreign function interfaces and all that, but I'm too busy to do everything my employer wants me to do. There's no way I'm going to spend months of my time extending the language, usually with crappy documentation if it even exists at all.
I said above that Java will do "most" of what you want to do because one of the few limitations of Java is that it is just not complete in terms of numerics. The situation is better than it was ten years ago, but I've still not worked much with Java, simply because I know it won't do everything I need it to do. Oh, and I hate the syntax with a passion. 8000 lines of GOTO-infested FORTRAN 77 is much more pleasant to me than 200 lines of Java.
The Clojure community offers a project called incanter that provides access to many of the available Java math libraries. There's also a project called rincanter that is supposed to bring R functionality to Clojure, building on the Java Rserve client. If it worked I would be happy to use it. Unfortunately rincanter does not work right now.
An Example
It's easy enough to get it working in Clojure. Here's what I did, along with a short example code.
First, I installed Eclipse. I then installed counterclockwise (no idea why they chose that name). I went through the tutorial instructions to set up a working project. All of my previous Clojure programs were REPL, so I just went through the experience of setting up the Eclipse environment, and can happily say that it is easy to do. I then downloaded Rserve.jar and Rengine.jar from rforge.
After starting my new project, I told Eclipse about Rserve.jar and Rengine.jar by right-clicking on "Referenced Libraries" --> "Build Path" --> "Configure Build Path..." --> "Add External JARs...".
Here's a sample program to demonstrate the calling syntax. You can convert the other parts of the Rserve Java examples into Clojure using the same ideas.
(import '(org.rosuda.REngine))
(import '(org.rosuda.REngine.Rserve RConnection))
(def c (new RConnection))
(def d (. c eval "rnorm(10)"))
(def e (. d asDoubles))
(println (first e))
(println (rest e))
This was done using Clojure 1.2 and Eclipse 3.5.2 on Linux Mint 11.
For me, it is promising because it runs on the JVM and has complete access to existing Java code. That means it's both fast and will do most of what you want to do. (Scala fits into the same category. I will be checking out Scala in the future.)
In addition, it is a dialect of Lisp, which means I'm a huge fan of the syntax as wells as the approach to problem solving. I've enjoyed using Scheme in the past, but given the lack of libraries, Scheme is not suitable for the numerical programming I do. I'm aware of projects like Chicken Scheme and Gambit-C, and I know about Swig and their foreign function interfaces and all that, but I'm too busy to do everything my employer wants me to do. There's no way I'm going to spend months of my time extending the language, usually with crappy documentation if it even exists at all.
I said above that Java will do "most" of what you want to do because one of the few limitations of Java is that it is just not complete in terms of numerics. The situation is better than it was ten years ago, but I've still not worked much with Java, simply because I know it won't do everything I need it to do. Oh, and I hate the syntax with a passion. 8000 lines of GOTO-infested FORTRAN 77 is much more pleasant to me than 200 lines of Java.
The Clojure community offers a project called incanter that provides access to many of the available Java math libraries. There's also a project called rincanter that is supposed to bring R functionality to Clojure, building on the Java Rserve client. If it worked I would be happy to use it. Unfortunately rincanter does not work right now.
An Example
It's easy enough to get it working in Clojure. Here's what I did, along with a short example code.
First, I installed Eclipse. I then installed counterclockwise (no idea why they chose that name). I went through the tutorial instructions to set up a working project. All of my previous Clojure programs were REPL, so I just went through the experience of setting up the Eclipse environment, and can happily say that it is easy to do. I then downloaded Rserve.jar and Rengine.jar from rforge.
After starting my new project, I told Eclipse about Rserve.jar and Rengine.jar by right-clicking on "Referenced Libraries" --> "Build Path" --> "Configure Build Path..." --> "Add External JARs...".
Here's a sample program to demonstrate the calling syntax. You can convert the other parts of the Rserve Java examples into Clojure using the same ideas.
(import '(org.rosuda.REngine))
(import '(org.rosuda.REngine.Rserve RConnection))
(def c (new RConnection))
(def d (. c eval "rnorm(10)"))
(def e (. d asDoubles))
(println (first e))
(println (rest e))
This was done using Clojure 1.2 and Eclipse 3.5.2 on Linux Mint 11.