Live data from Hacker News

Why I'm Betting On Julia

evanmiller.org

251–258 of 258 posts

Re: Why I'm Betting On Julia

#251
post #20

I'm excited by Julia, but I don't think this article makes a very good sell. It's neat that you can dump the generated assembly, but I'd rather see a demonstration of a robust profiler so that I know which functions I need to dump in the first place. I also disagree that the popularity of Node stems from "getting disparate groups of programmers to code in the same language". From what I've observed, it's not that bac…

I tend to agree with you about tools. I have yet to meet a language feature that's more important than library availability, profiling, autocompletion, documentation, debugging, etc. Then again, I don't face the script/C/CUDA choice everyday (most of his detractors on this thread don't either, I'd be willing to bet) so his circumstances are probably different enough to justify a different priority list. His argument…

FFI = Foreign Function Interface

Re: Why I'm Betting On Julia

#252
I like what I see so far at this page [1] and will watch closely to see whether Julia catches on.

One thing -- can we call agree that dictionary literals begin and end with '{}', that arrays are zero-indexed and that an index into a unicode string is properly a character and not a byte? Or are we doomed to permute endlessly on details such as these? I wish any new languages would set aside a large set of tempting innovations and just go with the flow on the smaller points.

[1] http://learnxinyminutes.com/docs/julia/

Re: Why I'm Betting On Julia

#253

I really don't like the anti-intellectual tone of the beginning. "The problem with most programming languages is they're designed by language geeks, who tend to worry about things that I don't much care for. Safety, type systems, homoiconicity, and so forth." can be rewritten as: "The problem with most software is that they are designed by computer geeks, who tend to worry about things that I don't much care for. Inf…

The problem with most cars is they're designed by professionals, who tend to worry about things some people don't much care for. Safety, security, reliability, and so forth.

That is exactly how many people will pick a car. They assume the cars already have these properties as a minimal requirement, and then proceed to pick one based on how it looks and how comfortable it is &c.

Re: Why I'm Betting On Julia

#254
post #204

The reason to bet on Julia is disassembling a function? This is a standard feature in Common Lisp (ANSI standardized in 1994) CL-USER> (defun f(x) (* x x)) F CL-USER> (disassemble 'f) L0 (leaq (@ (:^ L0) (% rip)) (% fn)) ; [0] (cmpl ($ 8) (% nargs)) ; [7] (jne L33) ; [10] (pushq (% rbp)) ; [12] (movq (% rsp) (% rbp)) ; [13] (pushq (% arg_z)) ; [16] (movq (% arg_z) (% arg_y)) ; [17] (leaveq) ; [20] (jmpq (@ .SPBUILTIN…

(jmpq (@ .SPBUILTIN-TIMES)) So, this is going to be really slow inside a loop. Would the compiler be able to optimize it into a single multiply instruction if it could prove that the input had to contain integers?

  CL-USER> (defun f (x)
             (declare (fixnum x)
                      (optimize speed (safety 0) (debug 0)))
               (the fixnum (* x x)))

  CL-USER> (disassemble #'f)
  ; disassembly for F
  ; Size: 19 bytes
  ; 0337CE2F:       488BCA           MOV RCX, RDX               ; no-arg-parsing entry point
  ;       32:       48D1F9           SAR RCX, 1
  ;       35:       480FAFCA         IMUL RCX, RDX
  ;       39:       488BD1           MOV RDX, RCX
  ;       3C:       488BE5           MOV RSP, RBP
  ;       3F:       F8               CLC
  ;       40:       5D               POP RBP
  ;       41:       C3               RET
  NIL

Re: Why I'm Betting On Julia

#255

I like what I see so far at this page [1] and will watch closely to see whether Julia catches on. One thing -- can we call agree that dictionary literals begin and end with '{}', that arrays are zero-indexed and that an index into a unicode string is properly a character and not a byte? Or are we doomed to permute endlessly on details such as these? I wish any new languages would set aside a large set of tempting inn…

Well, in many ways, they are going with the flow. They're targeting mathematicians, and R/Matlab users… all of whom use 1-indexed arrays. And, really, the kinds of dictionaries you're used to are constructed with {} braces. The square braces hold more specifically-typed keys and objects. It's a very clever analogy to their typed/untyped arrays. And wonderful for performance.

    ["one"=> 1, "two"=> 2, "three"=> 3] # -> Dict{ASCIIString,Int64}
    {"one"=> 1, "two"=> 2, "three"=> 3} # -> Dict{Any,Any}

Re: Why I'm Betting On Julia

#256
post #58

Just yesterday I decided to start seriously developing in Julia. High-level languages are a bottleneck for computational biology. We need to be able to write things fast, and have them run fast. So far no language really does this. But Julia looks like the one. I'm going to put together a BioJulia team is anyone is interested in playing.

I am starting a Ph.D in evolutionary biology in May. Julia looks like a pragmatic solution to a lot of the voes in computation these days. If you require folks to do things, I would be happy to assist. I have extensive experience in C and python. I hack in 20 other languages too, but have not yet completed any serious projects in julia.

Re: Why I'm Betting On Julia

#257
post #58

Just yesterday I decided to start seriously developing in Julia. High-level languages are a bottleneck for computational biology. We need to be able to write things fast, and have them run fast. So far no language really does this. But Julia looks like the one. I'm going to put together a BioJulia team is anyone is interested in playing.

I suppose I need to explain my position on the involvement of Julia in bioinformatics a little bit more than just a short "I want to play" statement. What follows is a bit of a rant that attempts to explain why things are bad and that we need to work to make them better.

I have been in the field of computational biology for (practically) 3 years. In this time, I have seen my fair share of bad tools and silly approaches to very basic problems. A lot of the computer science folks may not realize it, but there is a lot of trouble of basic software engineering sort in computational biology. There is a lot of old, unmaintaned code, messy projects implemented in multiple languages, and (of course) bugs. It does not appear that anybody checks or maintains their code after publication - the projects often die after they appear in a journal once.

There is a number of reasons that the situation is the way it is. One of the sadly obvious ones is that the academics do not have the time or desire to maintain their code. Some of the project would require full-time coders to be maintained - and that is indeed the case for some of the bigger and more popular tools. This results in the fact that some projects never take off or live up to their potential - for the simple lack of time. The wasted effort means that a lot of work is being re-done and science in general stagnates because of that. There is no easy solution to this problem (other than centralizing the efforts somehow - but that is the question of community, not tools).

The issues that can be made better are the following (and I will start with the most obvious ones first):

1) We need a language that is both easy to write in and is fast enough for production. Too many times there exist projects that are written in multiple languages. I have myself partaken in a few of those. The high level code is usually written in python or perl (I shiver of the thought), while the heavier numerical things are done in C or C++. This creates a rather large divide in terms of who does what - quite often folks only know a single high level language - so the numerical implementation stays opaque with only a single person knowing how it works. This means that projects of that sort quickly become unmaintainable. There is also a lot of glue code written - and God help you if you need to understand how perl-guts work. If there was a single sane implementation for both high level and numerical stuff, it will solve a lot of those problems.

2) We need a fast language. Building on the previous argument - the reason for splitting is quite often performance. This means that we use a single language for both layers - and we get the "Node.js" effect (I'm not sure who to reference this phrase to) - both front- and back-end stuff comes together. This also means that you are not penalized for using complicated data structures in your numeric code - so one level of separation falls away automatically.

3) We need a language with a large number of capabilities. Julia community is aiming to replicate a lot of the functionality of R. That means that it is already possible to use Julia for, say, an undergraduate statistics course. There is absolutely no reason (other than the historical, of course) why R is used by the statisticians. It was written by statisticians for statisticians - and has a lot of nice features. However, that means that a lot of the efficiency considerations have been missed. R does a whole lot of data copying - which is ridiculous for large data sets. For the growing crop of statisticians it will barely make a difference which language is used - I would go as far as to say that a lot of undergrads will not even notice the difference, but those who will, will thank us later.

4) We need a functional language. Much rather, we need a multi-paradigm language that has a strong functional basis. The advantages of the functional approach are too many to name here - and I am afraid this is already becoming incomrehensive. A lot of formal math and stats is really easily translatable into functional mindset - and that is a great boon if you are trying to implement an algorithm out of a math paper. Also, Julia does not restrict you to think in a particular way - it is very adatable to your thinking patterns.

These are just a few reasons that I would try give to support a case for a new language in the scientific community.

Re: Why I'm Betting On Julia

#258
post #58

Just yesterday I decided to start seriously developing in Julia. High-level languages are a bottleneck for computational biology. We need to be able to write things fast, and have them run fast. So far no language really does this. But Julia looks like the one. I'm going to put together a BioJulia team is anyone is interested in playing.

I suppose I need to explain my position on the involvement of Julia in bioinformatics a little bit more than just a short "I want to play" statement. What follows is a bit of a rant that attempts to explain why things are bad and that we need to work to make them better. I have been in the field of computational biology for (practically) 3 years. In this time, I have seen my fair share of bad tools and silly approach…

Just as a conclusion, I would like to point those interested to the current available library implementations of the bio- related stuff (i might be missing other stuff out there): 1) BIO-seq: https://github.com/diegozea/BioSeq.jl 2) Fasta-IO: https://github.com/carlobaldassi/FastaIO.jl 3) Phylogenetics: https://github.com/Ward9250/Phylogenetics.jl
Post reply on HN