Hi, On Wed, Feb 19, 2014 at 2:13 PM, bp2012 <[email protected]> wrote: > I'm not a scientific programmer. In fact, I haven't been a professionally > paid developer/dev mgmt for 8 years. However, being able to quickly code up > a solution to a problem, to perform my own research on our data, and > generate my own reports has proven to be highly valuable to my career on the > business side. > > With that said, I have been on the hunt for a language that is easy to use, > allows me to concisely expresse what I'm looking to accomplish, and have > reasonable performance. I've used verbose languages like java and c#, > scripting languages like perl and python, next generation clr based > languages like Nemerle and Cobra, functional languages like Lisp and > Clojure, and even self contained environments like Pharo smalltalk. There > are great features in those languages, but there was always something that > after a couple projects that jumped out as a big turn off or an obstacle > that couldn't reasonably be overcome. In each case, I jumped ship and moved > on to find the next promising candidate. > > I've been using julia for a number of months and have written several > projects. I haven't found a single obstacle that couldn't be overcome. With > ccall and pycall I can access a ton of libraries and the overall julia > syntax is so concise and expressive that writing software is enjoyable. > > I'm convinced that julia has a huge future in non-technical / general > purpose software development. But since not a lot of effort is expended > (yet) on publicizing to the masses, only the people actively searching for > an alternative will find it in the short term. > > To be honest I think that is a good thing. From my perspective, the > development efforts are rightly focused on the important things. For the > language to appeal to the masses, the installation process and environment > configuration would need to be idiot proof and a ton of introductory > documentation is needed. Currently, if you run into a problem you might have > to actually research it yourself. You will have to read source code that > you didn't write and maybe even have to make your own temporary fix. This is > a non-issue for motivated, bright technical people. However based on my > experience, it's a non-starter for an average business applications > developer.
+1 to everything you wrote above. I'm a scientific programmer who has been using Python thusfar, and although Python has many mature libraries (and some newer ones), I find myself using Julia for experimental projects. While its interesting to poke around the source code and have moments of epiphany, I grok this may not be suitable for teams that want production grade code (now). The only installation problem I had was hardware (laptop heated to 98 deg Cel. and shutdown) issues with BLAS compilations on an older laptop, so after that single compilation, I stick to @staticfloat's nightly builds for Ubuntu. That said, despite the compilation issues, I still prefer "git" over packaged versions - you will know what I mean if you've ever struggled with installing python scientific packages inside a virtualenv. That was many moons ago but the dependency hell was truly hellish. > As the environment and packages mature, these issues will go away and over > the next couple years, my prediction is that julia will seen a massive > increase in adoption outside of the technical computing world. > > I want to do my part and blog about the general capabilities of julia and > some of the excellent packages such as DataFrames, ODBC/SQLite, Match, and > PyCall, that make developing quick and painless. It's just a matter of > finding the time ;) I try to collect interesting cookbooks here: https://github.com/svaksha/julya/blob/master/Cookbook.md#blogs When you find the time to blog, feel free to submit a link (as a PR) or file a bug and I'll add it. - svaksha
