discussing Clojure with non-CS types
cej38
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.
I will note that this is a quick listing of ideas to discuss. There
are surely more points to make, and better, cleaner ways of discussing
them. Also, I haven't made any effort to use well thought out English
sentences.
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.
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.
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.
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.
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))
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)))
6. Many types of Concurrency "without all that mucking about in" MPI,
openMP and the like (Thanks to Douglas Adams.)
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.
8. Every problem has been solved twice in Java. Meaning it has been
solved three times in clojure.
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.
Joop Kiefte
> 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))
>
> 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)))
You mean this I suppose:
(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 parameter) 0 value)))
cej38
On Nov 24, 12:28 pm, Joop Kiefte <iko...@gmail.com> wrote:
> 2010/11/24 cej38 <junkerme...@gmail.com>:
Eric Lavigne
> 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.
If you're comparing with Fortran, my favorite advantage is that I can
create a new array in a function, and return it from that function. In
Fortran, I would have needed to create the array in whatever code
calls that function, and pass the array in. This issue adds a lot of
overhead to any effort to reuse code. (I'm not sure if this issue was
fixed in the more recent Fortran 2003 or 2008 versions.)
I know a lot of nuclear engineers, from my previous life as a nuclear
engineering grad student, and I have been unable to convince any of
them to try languages other than Fortran. Their arguments fall into
three categories.
1) Not fast enough.
If it's even a little slower than Fortran, that's unacceptable. Even
C++ is not acceptable for this reason, and anything with garbage
collection is worthy of a raised nose.
This actually seems like a legitimate reason. I just think that faster
development time is worth giving up some execution speed, especially
if you can use the extra time to experiment with possibly faster
algorithms. Additionally, raw execution speed is one of the priorities
for the upcoming Clojure 1.3.
2) It's not Fortran, and I don't have time to learn another language.
I have work to do.
Of course, much of that work involves programming in Fortran, and
would get done so much faster in any other language.
3) It doesn't work on [big computer configured by someone else].
Of course, the computer was configured that way to support a bunch of
engineers who only program in Fortran. If this were the real problem,
the computer would be configured differently.
=================================================
I think the best thing you can do to convince your colleagues to use
Clojure, is to create open source Clojure libraries and applications
that they would find useful. Eventually they will want more than what
the applications provide out of the box. The desire to customize their
favorite tool will provide an immediate motivation to learn Clojure,
and the fact that such a great tool was created in Clojure will be
good evidence that Clojure could be useful in other projects.
Bonus points if that tool, created in Clojure, turns out to be faster
than they would have expected from a Fortran program.
cej38
colleagues, computer time is cheap, my time is not. If I can write
code that does the same thing in two languages, and the code written
in one language runs in half the time of the other, while the code in
the other language took half the time to write, which one should I
use?
cej38
9. Unit testing is much easier! The effort it takes to write unit
tests is Fortran is so high, it might as well be impossible, and thus
almost no one does it.
Mike Meyer
cej38 <junke...@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
CuppoJava
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.
Michael Gardner
> 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.
I think this is a matter of mindset. Like learning a new human language: it takes a while to begin thinking in the new language. Until then, you have to think in your native language and translate on-the-fly, which makes certain things awkward to express.
Similarly with functional programming: once you begin to "think functionally", the functional solutions are the ones that come to mind first, rather than the imperative ones.
David Nolen
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.
-Patrick
Carson
It's essentially a lisp-like way to write C, with lots of integration
with libraries to do numerical computing, machine learning, etc.
Carson