Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Lisper's first impression of Julia

p-cos.blogspot.com

Post reply on HN
Print view View original

31–40 of 41 posts

Re: A Lisper's first impression of Julia

#31

Post by klibertp »

LeonidasXIV wrote: post #9
wirrbel wrote: post #7

I would very much like to read a comparison of CL and Clojure from the author at some point. As it seems he is offering a fair comparison.

> I would very much like to read a comparison of CL and Clojure from the author at some point. As it seems he is offering a fair comparison. I suspect the authors main problem with Clojure is, that it is a mostly functional language which heavily emphasizes doing things in the functional way and discouraging imperative programming whereas CL is more like a true multiparadigm language. I used to think that multiparadi…

> I suspect the authors main problem with Clojure

That's not a very nice thing to do, suspecting people without any kind of evidence. Not to mention the fact that there is a `set!` form in Clojure, which makes it entirely possible to write very imperative code (and thread-local semantics don't matter in single-threaded programs).

Anyway, "problems with Clojure" can be very different for different people. I like Clojure design as a language - even its interop with OO host features are very neat - but then when I want to hack some simple script in a REPL I not only need to write this:

    $ rlwrap java -cp "clojure-1.5.1.jar" clojure.main
but then I need to wait for freaking 6 seconds for the prompt to appear. 6 seconds. I don't know what more I could write here, so I'll just paste this (Chicken Scheme):

    $ time csi -e '(exit)'
    csi -e '(exit)'  0,01s user 0,00s system 81% cpu 0,007 total
So that's my problem with Clojure, nothing to do with "functional way", right?

Re: A Lisper's first impression of Julia

#32

Post by craigching »

eoi wrote: post #11
andrewflnr wrote: post #8

It seems weird to try to characterize Julia in terms of object-oriented programming. Is that just me? Julia's approach to subtyping and multiple dispatch is sufficiently different from the C++ and Python approaches to OOP that I don't even put them in the same bucket, and it seems about as far away from CL's objects as well. Julia doesn't really advertise itself as OO; you can't even find the word "object" on the fro…

I'm not familiar with Julia, but from a Common Lisp perspective it is very natural to closely link OO and function dispatch. Generic functions were added to lisp as part of its object system and make up a large part of it.

Indeed! My first OO course at the University of Minnesota (1992 or so) was object-oriented programming using Scheme (using SICP). I was more of a C++ programmer at the time and the different perspective was eye opening for me!

Re: A Lisper's first impression of Julia

#33

Post by zachbeane »

wirrbel wrote: post #7

I would very much like to read a comparison of CL and Clojure from the author at some point. As it seems he is offering a fair comparison.

https://groups.google.com/forum/#!topic/comp.lang.lisp/HQFMh... has some discussion between the author and others from 2009 regarding Clojure and Common Lisp.

Re: A Lisper's first impression of Julia

#34

Post by phkahler »

StefanKarpinski wrote: post #5
idunning wrote: post #3

Comprehensive! Covers the Lisp-y influences of Julia in great depth. My perspective on Julia is that it has 3 ingredients: 1. A principled design that derives from the experiences of past programming language and particularly the creator's experiences with Lisps. This is where a lot of the "magic" comes from: multiple dispatch, the type system, metaprogramming, etc. The article covers this aspect. 2. A need to be acc…

Regarding the Int / BigInt distinction, other issues besides performance, which haven't historically been prominent considerations in new language designs, are interoperability and transparency. In the current design, a Vector{Int} always has the same in-memory representation as it would in C or Fortran – you can take a pointer to the first array element and pass it to a library function using the C ABI and it will j…

IMHO it is total fail to have int be dependent on the machine architecture. C99 fixed this behavior with types for specific sizes so people could finally write portable code. Julia should adopt 64bit integers by default given its intended audience and the reality that even some phones have 64bit processors. int64_t works on 32bit processors too, but with a performance penalty. Having the range of a variable depend on the machine architecture really went out of style a long time ago.

Re: A Lisper's first impression of Julia

#35

Post by phkahler »

pjmlp wrote: post #27
rayiner wrote: post #19

Earlier quoted context omitted.

Aside from Apple having abandoned the language, the basic issue is that Dylan projects were very ambitiois. Dylan was aimed at C++, so Harlequin and CMU spent a huge amount of time developing sophisticated native code compilers, thread-safe GC, compilation to native executables, etc. Harlequin also did a whole IDE, with GUI toolkit and Emacs-like editor, all written in Dylan and self-hosted. Ruby, Python, etc, showed…

> There's a renaissance in native-compiled languages now, mainly thanks to LLVM and the JVM No, technology just goes in circles. Like 30 years ago when people started to realize P-Code and other VM approaches were too slow and resource hungry to be useful targeting minicomputers. Now mobiles and high electricity costs are making developers reach the same conclusions again.

> Now mobiles and high electricity costs are making developers reach the same conclusions again.

But rather than fall back on existing compiled languages, they are now trying to build something that has it all.

Re: A Lisper's first impression of Julia

#37

Post by pjmlp »

phkahler wrote: post #35
pjmlp wrote: post #27

Earlier quoted context omitted.

> There's a renaissance in native-compiled languages now, mainly thanks to LLVM and the JVM No, technology just goes in circles. Like 30 years ago when people started to realize P-Code and other VM approaches were too slow and resource hungry to be useful targeting minicomputers. Now mobiles and high electricity costs are making developers reach the same conclusions again.

> Now mobiles and high electricity costs are making developers reach the same conclusions again. But rather than fall back on existing compiled languages, they are now trying to build something that has it all.

That is also not new. While the minicomputers struggled with VMs and got back to AOT compilation, research labs workstations already had mixed mode.

The first JIT were targeted at Lisp and Smalltalk environments, and commercial Lisps always had JIT + AOT compilation support.

As for going for something new, it is hard to bring people back to technologies that are no longer mainstream, without adding something new to it.

Re: A Lisper's first impression of Julia

#38

Post by StefanKarpinski »

phkahler wrote: post #34
StefanKarpinski wrote: post #5

Earlier quoted context omitted.

Regarding the Int / BigInt distinction, other issues besides performance, which haven't historically been prominent considerations in new language designs, are interoperability and transparency. In the current design, a Vector{Int} always has the same in-memory representation as it would in C or Fortran – you can take a pointer to the first array element and pass it to a library function using the C ABI and it will j…

IMHO it is total fail to have int be dependent on the machine architecture. C99 fixed this behavior with types for specific sizes so people could finally write portable code. Julia should adopt 64bit integers by default given its intended audience and the reality that even some phones have 64bit processors. int64_t works on 32bit processors too, but with a performance penalty. Having the range of a variable depend on…

We considered that, but even though 64-bit ints work on 32-bit machines, they are dog slow. Insisting that integers are 64-bit everywhere is basically saying that you want slow for loops, slow array indexing – slow everything – on 32-bit systems. Clearly that's unacceptable in a language that is meant to be fast. So Julia has Int32 and Int64 when you want a specific bit size and Int is always the same size as your pointers. This arrangement is considerably simpler to deal with than C's "integers are whatever size I want them to be! [evil cackle]" approach. In particular, default integers and pointers are always the same size – which is not always the case in C (I'm looking at you, Win64) – so there's only one system-dependent size to worry about.

Re: A Lisper's first impression of Julia

#39

Post by peterashford »

LeonidasXIV wrote: post #28
ics wrote: post #24

Earlier quoted context omitted.

There are times when having an English word for "no, well– yes, but I don't know why you'd want to" would be very useful. It'd have to be pretty short to save breath every time a computer scientist must answer the question, "But is it a systems programming language?"

Maybe 無 (mu) [0], which is something philosophically in between yes and no. [0]: https://en.wikipedia.org/wiki/Mu_(negative)#.22Unasking.22_t...

mu is more like "you've made a category error" or "the question makes no sense" rather than "technically yes, but you wouldn't want to" - which is what the post you were responding to seemed to be aiming for

Re: A Lisper's first impression of Julia

#40

Post by LeonidasXIV »

PuercoPop wrote: post #29
LeonidasXIV wrote: post #9

Earlier quoted context omitted.

> I would very much like to read a comparison of CL and Clojure from the author at some point. As it seems he is offering a fair comparison. I suspect the authors main problem with Clojure is, that it is a mostly functional language which heavily emphasizes doing things in the functional way and discouraging imperative programming whereas CL is more like a true multiparadigm language. I used to think that multiparadi…

It is in poor taste to put words in someone's mouth and proceed to 'debunk' said words.

I seem to remember his comments on some Lisp list on usenet or something, but I might be wrong, in which case I'm sorry and didn't mean to discredit the article's author in any way (I think that Pascal Costanza is a nice and smart fellow, and always had a positive impression of his posts, and Lisp communities used to be terrible places).
Post reply on HN