I must admit that even though I love Clojure and use it daily for many things, I don't like using it very much for my research (machine learning) which involves a lot of number crunching.
The main reasons being: Numerical software involves a lot of array indexing, and loops, and not much else. Clojure's functional data structures are elegant, but are not quite fast enough for heavy numerical processing so I still need to use native arrays. And if all I'm using is native arrays, the java syntax for arrays is much easier on the eyes than a bunch of nested s-exps. The other reason is that Clojure emphasizes functional programming and discourages mutation. This is fine, as I believe well-written code is usually functional anyway. The problem is that bad code is usually easier to write in an imperative way than a functional way, and the ability to write bad code is important I think. It's usually a lot quicker to whip up a mutative hack than think through the problem and factor out components and be functional about the whole thing. And usually, in the very very early stages of programming something, when you don't clearly know what it is you're programming, it's nice to be able to whip out a quick and dirty mutative hack. And then make it nice and elegant and functional later on, but Clojure makes doing that difficult for me. -Patrick On Nov 24, 3:12 pm, Mike Meyer <mwm-keyword-googlegroups. 620...@mired.org> wrote: > On Wed, 24 Nov 2010 09:20:49 -0800 (PST) > > cej38 <junkerme...@gmail.com> wrote: > > I am a physicist. I have been using Clojure full time for the last > > year and a half. The reasons that Rich (and most other Clojure > > evangelists) give for using Clojure, are all nice and good, but they > > point to what computer scientists think about. If you want scientists > > and engineers to think about switching to Clojure, you need to talk to > > the concerns that they have. Of course, there is some overlap. > > The thing is, I'm not sure it's the best choice for such people. At > least, not yet. The LISP-like syntax means you have to explain the > code if you publish it, a problem that some alternatives - which have > most of your advantages - don't have. Look at Python, a descendant of > ABC, which was designed for teaching/prototyping. It's been described > as "executable pseudo-code". > > > Here are some reasons that I would give for using clojure: > > 1. Most data analysis gets done by writing little programs that do > > certain tasks. When writing in Fortran I more or less have to write a > > new program to do each task. In clojure, I might have to write a new > > function, but I keep finding that functions that I wrote before, will > > help with these new problems. Code re-use is much higher! Less time > > coding. > > I think this says more about your coding style than Clojure. I find > that true in most of the languages I write in, but I structure > programs to make it so. > > > 2. fewer number of parameters that need to be passed into > > subroutines. When writing fortran/C programs, you not only need to > > pass in the data, but you also need to pass in parameters that > > describe the data. In clojure, you usually only pass in the data. > > The same is true of Python, and most modern languages. Clojure's data > structures - which make this possible - have been around in other > languages for quite a while now. > > > 3. (related to 2) Everything is a function, thus, as long as the > > inputs and outputs are the same, you can change the internals at > > will. This makes it super easy to try rewriting code to make it run > > faster. > > The same is true of Python. > > > 4. Using the REPL you write fewer bugs. In an imperative language you > > have to make a guess as to how a whole (possibly very long) subroutine > > should be written before writing it and then debug. Using the REPL > > you start with the most basic steps of the subroutine, make sure those > > work, and then continue to build until you have something that works. > > This is also true of Python's REPL. > > > 5. ease of changing function calls to allow for extra stuff/ > > functionality without breaking other stuff. An example would be best > > here. Suppose I had defined some function that worked for a specific > > purpose: > > (defn setzero [value] > > "If value is less than 1.0E-8 setzero returns zero.." > > (if (tolerance? value 1.0E-8) 0 value)) > > The same is true of Python: > > def setzero(value): > "If value is less than 1.0E-8 setzero returns zero" > return 0 if tolerance_p(value, 1.0E-8) else value > > > > > and later I decided that I would really like to use that same function > > again, but that 1.0E-8 won't work in this new case. I can change > > setzero so that it will work with all of my old code (without change > > to the old code) but I can make it work new code as well. > > (defn setzero > > "If value is less than parameter setzero returns zero. If no > > parameter is specified, the default value of 1.0E-8 is used." > > ([value] > > (setzero value 1.0E-8)) > > ([value parameter] > > (if (tolerance? value 1.0E-8) 0 parameter))) > > def setzero(value, parameter=1.0E-8): > """If value is less than parameter setzero returns zero > The default value of parameter is 1.0E-8""" > return 0 if tolerance_p(value, parameter) else value > > (ok, I followed the comment not the code) > > > 6. Many types of Concurrency "without all that mucking about in" MPI, > > openMP and the like (Thanks to Douglas Adams.) > > Not true in Python. Worse yet, even the most recent versions of > Python's C implementation still suffer with the GIL. This (along with > just flat liking functional programming and LISPy languages) is why > I'm looking at clojure. But as you say, these are a professional > programmers reasons for using it; I'm not sure they carry enough > weight to overcome the advantages Python (or other, similar languages) > might offer. > > > 7. Is it a scripting language or a compiled language? Yes. Depending > > on what you need it for. I often use the REPL and my code to script > > stuff. There are also times where you want to have a real program as > > a JAR file, clojure can be both. > > The same is true of Python. In fact, it's true twice: if you think > that the JVM is fast enough, you can run your code in Jython and > leverage Java tools. If that's not fast enough, you can wrap your > favorite native FORTRAN libraries (assuming it hasn't already been > done) along with a graphics library, and play with them all in the > REPL. Not merely exploratory programming, but full-blown visual > exploratory data analysis! (Yes, I know incanter does this kind of > thing, but it doesn't seem quite as mature - and I believe it runs at > JVM speeds.) > > > 8. Every problem has been solved twice in Java. Meaning it has been > > solved three times in clojure. > > Java's a relative newcomer. If it's been solved twice in Java, it's > probably been solved twice in Python, with wrapped C and C++ solutions > available as well. This is not always a good thing... > > > The underlying theme is that you can quickly write the code that you > > need to do your job, so that you can get back to doing your job. > > At this stage, I suspect that Python is still the better tool for > them. The advantages Clojure has over Python are in the "for computer > scientists" domain, whereas Python's advantages over Clojure are > things that will matter to them: access to libraries they are familiar > with, and that it's much easier to read Python code on first exposure, > means that sharing results (an important part of the process) is much > easier. > > Especially since there's a community of people willing to help them > with it athttp://www.scipy.org/. Of course, if you're trying to get > them off FORTRAN, pretty much anything would be an improvement. > > <mike > -- > Mike Meyer <m...@mired.org> http://www.mired.org/consulting.html > Independent Network/Unix/Perforce consultant, email for more information. > > O< ascii ribbon campaign - stop html mail -www.asciiribbon.org -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
