Re: discussing Clojure with non-CS types

2010-11-25 Thread Carson
Curious if anyone has given Lush a try here? http://lush.sourceforge.net/ It's essentially a lisp-like way to write C, with lots of integration with libraries to do numerical computing, machine learning, etc. Carson On Nov 24, 5:47 pm, CuppoJava wrote: > I must admit that even though I love Clo

Re: discussing Clojure with non-CS types

2010-11-25 Thread David Nolen
On Wed, Nov 24, 2010 at 8:47 PM, CuppoJava wrote: > > 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

Re: discussing Clojure with non-CS types

2010-11-25 Thread Michael Gardner
On Nov 24, 2010, at 7:47 PM, CuppoJava wrote: > 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

Re: discussing Clojure with non-CS types

2010-11-24 Thread CuppoJava
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. Cl

Re: discussing Clojure with non-CS types

2010-11-24 Thread Mike Meyer
On Wed, 24 Nov 2010 09:20:49 -0800 (PST) cej38 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

Re: discussing Clojure with non-CS types

2010-11-24 Thread cej38
Another thought: 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. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, se

Re: discussing Clojure with non-CS types

2010-11-24 Thread cej38
Having a fast code is important, but as I have often said to 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 th

Re: discussing Clojure with non-CS types

2010-11-24 Thread Eric Lavigne
> 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

Re: discussing Clojure with non-CS types

2010-11-24 Thread cej38
yes On Nov 24, 12:28 pm, Joop Kiefte wrote: > 2010/11/24 cej38 : > > > > > > > 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 > > purpo

Re: discussing Clojure with non-CS types

2010-11-24 Thread Joop Kiefte
2010/11/24 cej38 : > 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 set

discussing Clojure with non-CS types

2010-11-24 Thread cej38
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 abou