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 at http://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
