Looks interesting: http://lambda-the-ultimate.org/node/4452
Any experiences, thoughts?
Julia
-
Polter
- Posts: 0
- Joined: Thu Jan 01, 2004 12:00 am
Julia
MadMax, some curiosities regarding the performance of std::accumulate are also related to it using operator+ (not operator+=) and issues with trying to optimize it with move semantics (from a compiler point of view) keeping standard-compliance; discussion here: http://gcc.gnu.org/ml/libstdc++/2011-01/msg00015.html
I solely mention those as "curiosities", since I wouldn't expect them to have an impact on "small" data structures (like a built-in double) (and the example above considers std::string), but it might still be of interest.
I solely mention those as "curiosities", since I wouldn't expect them to have an impact on "small" data structures (like a built-in double) (and the example above considers std::string), but it might still be of interest.
-
Corey
- Posts: 0
- Joined: Thu Jan 01, 2004 12:00 am
Julia
I disagree ComteZero: I think it is incredibly healthy. In my opinion, programming languages are much like spoken languages: their syntax defines their expressiveness (I am a big believer in the Sappir-Worf Hypothesis). There are certain things that are more easily captured in one language versus another. If you play with C, Ruby, Haskell, Clojure, Factor, and APL, then try to compare that with fragmentation in Unix, I believe you will see that the diversity in the former literally forces you to look at problems in a different way, whereas fragmentation in the latter does not.
I am incredibly interested in Julia, myself. I've always been a "right tool for the right job" kind of guy, and tend to hack my code together through a series of different languages (mainly Clojure, Python, and Ruby). Some are stand-alone API services, some pull data, some are purely for visualization.
While I don't find Julia's syntax to be all that exciting, its focus on numerical computation (a la Matlab) is. Even more exciting, to me, is its macro syntax (hurrah lisp!). If I can smash Clojure and Python together, I'll be happy.
However, until it gets a robust set of libraries underneath it (sockets, HTTP client, database, visualization, et cetera), it will be relegated to simple statistical analysis of static datasets -- which to me isn't all that interesting. I can already do that with Python (w/ pandas, numpy, et cetera). Unless the syntax proves to be significantly easier, I don't know why I would bother re-writing the majority of my libraries.
I am incredibly interested in Julia, myself. I've always been a "right tool for the right job" kind of guy, and tend to hack my code together through a series of different languages (mainly Clojure, Python, and Ruby). Some are stand-alone API services, some pull data, some are purely for visualization.
While I don't find Julia's syntax to be all that exciting, its focus on numerical computation (a la Matlab) is. Even more exciting, to me, is its macro syntax (hurrah lisp!). If I can smash Clojure and Python together, I'll be happy.
However, until it gets a robust set of libraries underneath it (sockets, HTTP client, database, visualization, et cetera), it will be relegated to simple statistical analysis of static datasets -- which to me isn't all that interesting. I can already do that with Python (w/ pandas, numpy, et cetera). Unless the syntax proves to be significantly easier, I don't know why I would bother re-writing the majority of my libraries.
"Then there was the man who drowned crossing a stream with an average depth of six inches." W. I. E. Gates
-
ComteZero
- Posts: 0
- Joined: Thu Jan 01, 2004 12:00 am
Julia
i see some of your points, and agree that it's good to have different languages.
but i stay on my opinion, based on (non-verified) feeling that number of different language is rising exponentially.
you see many overlaps, much energy is spent just to port libraries from one language to another, whereas this energy could be used to improve what's already existing.
also some tend to specialize to an extent where you spend more time to learn 5 languages because you have 5 different problems.
at the end your time is spent in grammar books (learning different libs) than to effectively talk.
and even if you talk, you don't write litterature !
but i stay on my opinion, based on (non-verified) feeling that number of different language is rising exponentially.
you see many overlaps, much energy is spent just to port libraries from one language to another, whereas this energy could be used to improve what's already existing.
also some tend to specialize to an extent where you spend more time to learn 5 languages because you have 5 different problems.
at the end your time is spent in grammar books (learning different libs) than to effectively talk.
and even if you talk, you don't write litterature !
/* Trust is good, no trust is better. */
-
Polter
- Posts: 0
- Joined: Thu Jan 01, 2004 12:00 am
Julia
Yeah, I think we have some distance to go until we settle at the one true language. And that's coming from a guy crazy enough to do early prototyping in C++ (no, not always, not that crazy) just to avoid too many gluing languages 
But a good point on improving on what we have, and looking at some CS research (a new language each week) I can certainly understand the view that it's going somewhat overboard. Ultimately though I think the market will sort it out, anything too niche / w/o major backers is destined for history's trash bin anyway.
I like this aspect of Julia -- Calling C and Fortran Code -- certainly looks friendlier that the mess of MATLAB/MEX (perhaps comparable to some aspects of Lua -- C function call syntax in Lua is as friendly as it gets (the same as native Lua function), OTOH data interchange involves stack manipulation on the C side if not using a wrapper). It really helps one can use types for this in Julia (and the lack of that ability in MATLAB -- in particular used as described in the "Break functions into multiple definitions" part here -- is IMHO one of its main weaknesses, next to a horrible JIT opt. level). The plans to make it even easier (http://news.ycombinator.com/item?id=3607142) seem promising.
Dynamic typing is a bit of a downside, though -- personally I would strongly prefer automatically inferred static typing. Can't really see any benefits to dynamic typing compared to that, and it does tend to result in messy code.
That being said, I have to agree libraries are a must (one of the reasons C++ fits in my case is that there's plenty, with R a strong alternative) and for that a critical mass of devs/users seems an unavoidable necessity. It's kind of a chicken and egg problem, unless the project were to get some significant commercial backing, one needs the libs for the users/devs to come, while the users/devs would like to have an existing infrastructure...
But a good point on improving on what we have, and looking at some CS research (a new language each week) I can certainly understand the view that it's going somewhat overboard. Ultimately though I think the market will sort it out, anything too niche / w/o major backers is destined for history's trash bin anyway.I like this aspect of Julia -- Calling C and Fortran Code -- certainly looks friendlier that the mess of MATLAB/MEX (perhaps comparable to some aspects of Lua -- C function call syntax in Lua is as friendly as it gets (the same as native Lua function), OTOH data interchange involves stack manipulation on the C side if not using a wrapper). It really helps one can use types for this in Julia (and the lack of that ability in MATLAB -- in particular used as described in the "Break functions into multiple definitions" part here -- is IMHO one of its main weaknesses, next to a horrible JIT opt. level). The plans to make it even easier (http://news.ycombinator.com/item?id=3607142) seem promising.
Dynamic typing is a bit of a downside, though -- personally I would strongly prefer automatically inferred static typing. Can't really see any benefits to dynamic typing compared to that, and it does tend to result in messy code.
That being said, I have to agree libraries are a must (one of the reasons C++ fits in my case is that there's plenty, with R a strong alternative) and for that a critical mass of devs/users seems an unavoidable necessity. It's kind of a chicken and egg problem, unless the project were to get some significant commercial backing, one needs the libs for the users/devs to come, while the users/devs would like to have an existing infrastructure...
MadMax, some curiosities regarding the performance of std::accumulate are also related to it using operator+ (not operator+=) and issues with trying to optimize it with move semantics (from a compiler point of view) keeping standard-compliance; discussion here: http://gcc.gnu.org/ml/libstdc++/2011-01/msg00015.html
I solely mention those as "curiosities", since I wouldn't expect them to have an impact on "small" data structures (like a built-in double) (and the example above considers std::string), but it might still be of interest.
I solely mention those as "curiosities", since I wouldn't expect them to have an impact on "small" data structures (like a built-in double) (and the example above considers std::string), but it might still be of interest.
-
Polter
- Posts: 0
- Joined: Thu Jan 01, 2004 12:00 am
Julia
http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012/Julia
MadMax, some curiosities regarding the performance of std::accumulate are also related to it using operator+ (not operator+=) and issues with trying to optimize it with move semantics (from a compiler point of view) keeping standard-compliance; discussion here: http://gcc.gnu.org/ml/libstdc++/2011-01/msg00015.html
I solely mention those as "curiosities", since I wouldn't expect them to have an impact on "small" data structures (like a built-in double) (and the example above considers std::string), but it might still be of interest.
I solely mention those as "curiosities", since I wouldn't expect them to have an impact on "small" data structures (like a built-in double) (and the example above considers std::string), but it might still be of interest.
-
quantie
- Posts: 0
- Joined: Thu Jan 01, 2004 12:00 am
Julia
I played with it very fast at certain things and LLVM helps. Problem is Rhas a ton of packages that would need to be ported over. Some of the R heavy weights seem to be tinkering worth watching.
Although I'd hope that R gets a complete rewrite at some point in the no so distant future.
Although I'd hope that R gets a complete rewrite at some point in the no so distant future.
Blistering Barnacles;Thundering Typhoons
-
Polter
- Posts: 0
- Joined: Thu Jan 01, 2004 12:00 am
Julia
The Julia Language hits a new speed milestone
MadMax, some curiosities regarding the performance of std::accumulate are also related to it using operator+ (not operator+=) and issues with trying to optimize it with move semantics (from a compiler point of view) keeping standard-compliance; discussion here: http://gcc.gnu.org/ml/libstdc++/2011-01/msg00015.html
I solely mention those as "curiosities", since I wouldn't expect them to have an impact on "small" data structures (like a built-in double) (and the example above considers std::string), but it might still be of interest.
I solely mention those as "curiosities", since I wouldn't expect them to have an impact on "small" data structures (like a built-in double) (and the example above considers std::string), but it might still be of interest.
