Live data from Hacker News

Why Julia

ucidatascienceinitiative.github.io

101–110 of 257 posts

Re: Why Julia

#101

Earlier quoted context omitted.

Sorry, why do you need OOP? I haven't coded OO in about 10 years now. (Mostly Julia, elixir, and functional JavaScript). It's great. Would never go back.

Because sometimes it's better for readability and conceptual simplicity to structure the code as objects connected to each other. Most of large-scale successful projects, often written by better developers than me or you, use OOP.

And 80% of the internet switches (Cisco and juniper) are controlled by erlang. So?

I think you're looking at this wrong. Part of the reason why so many large scale products use OO, is because they use Java, and java is awesome if you're working at such a large organization that your productivity is most easily measured by pointy haired managers who count how many LOC you've written ;)

As for readability and conceptual simplicity, may I introduce you to something called the Factory pattern?

Re: Why Julia

#102

Earlier quoted context omitted.

> Lack of support for OOP. Please. No. Languages that try to do everything are crap. If you want to do something OOP, why don't you grab a language built for it?

I do. Many languages have excellent support for both OOP and FP. I think Swift is currently the best-designed general-purpose language and wish that it would improve in areas where Julia is better, e.g. standard library and available packages or REPL.

I'd much rather whave a couple of language that specialize in their own paradigm rather than a single one which tries to do everything, to be honest.

Re: Why Julia

#103

Earlier quoted context omitted.

Regardless of the answer, I have plans to learn it simply out of curiosity. I'm just not yet convinced that there are any practical benefits to using Julia over the other languages.

As you said yourself, you have no performances problem with R and Python, so I do not think you need to learn Julia. However, in fields dealing with larger datasets ( e.g. genetics, astrophysics, ...), Python and R are real bottlenecks in data processing pipelines, and are thus often replaced by programs in C/C++/Java/etc. Having a language with the expressiveness and dynamism of Julia on the one hand, and performanc…

Do they use Fortran in those fields?

Re: Why Julia

#104

Earlier quoted context omitted.

Because sometimes it's better for readability and conceptual simplicity to structure the code as objects connected to each other. Most of large-scale successful projects, often written by better developers than me or you, use OOP.

And 80% of the internet switches (Cisco and juniper) are controlled by erlang. So? I think you're looking at this wrong. Part of the reason why so many large scale products use OO, is because they use Java, and java is awesome if you're working at such a large organization that your productivity is most easily measured by pointy haired managers who count how many LOC you've written ;) As for readability and conceptua…

I don't think that's a big part of the reason to be honest. Also, modern Java has a reasonable support for FP.

I'm talking about projects like Mapbox, Blender, Firefox, Android.

Re: Why Julia

#105

As someone who has never run into performance problems with R, and also knows how to use Python - is there a good reason to learn Julia?

Last week I compared a standard regression command across several statistical programs (R, Py, Stata, Matlab, Julia, etc) on a stupidly simple 10x5 matrix, and Julia took ages to run (this is on windows). Even loading the CSV file took seconds in Julia, hundreds of times slower than all of the other packages put together. I'm not sure if they just suck at Windows, but I was extremely dissapointed... :/

The first time you run code in a REPL Julia will have to compile it. So starting a new REPL, and trying to solve a very small problem one time will currently be a terrible workflow for Julia (unless you don’t care that it may take a few seconds).

If you had run your code again within the same REPL you’d see it runs substantially faster the second time. Likewise, if you had tried to process a large enough matrix or CSV that compilation time should be a minimal subset of the total computing time, and probably not noticeable.

It isn’t a language limitation, just a tooling limitation. The startup times have been getting better as Julia develops, but there is still noticeable overhead the first time code gets run in a new REPL...

Re: Why Julia

#106

Earlier quoted context omitted.

Because sometimes it's better for readability and conceptual simplicity to structure the code as objects connected to each other. Most of large-scale successful projects, often written by better developers than me or you, use OOP.

And 80% of the internet switches (Cisco and juniper) are controlled by erlang. So? I think you're looking at this wrong. Part of the reason why so many large scale products use OO, is because they use Java, and java is awesome if you're working at such a large organization that your productivity is most easily measured by pointy haired managers who count how many LOC you've written ;) As for readability and conceptua…

I might be wrong, but my understanding is things happened backwards from that. OOP tried to solve the problem of how to get tons of devs working on huge projects at the same time; java came along to try to be an awesome OOP environment, so Java became the standard.

Re: Why Julia

#107

Earlier quoted context omitted.

I guessed that it wasn't your habits but if you step outside that box a bit you'll realize that lifting up or down things inside loops is the most natural thing to do. And for you example (which may not be your real use or workflow) you could have two loops, independent or coupled through a queue so that the julia process is only started once.

Of course! Once I realize that after a few seconds only a dozen images have been processed I cut the loop, remember that the julia repl is dog slow, and then, rewrite the task in a different way. But I would prefer not to have to do that. Moreover, for more complicated examples, there may be data dependencies that make the loop commutation non trivial. The slow startup time may be a minor inconvenience, I agree. But…

You have to use it inside a REPL, like R or Matlab. Julia using LLVM and compiling on-the-fly is not sloppy design, it's a design tradeoff (and a great one, if you really need speed).

Julia is not a scripting language, it's a language for mathematical analysis.

Also going back to your example the solution would be to use ImageMagick.jl from Julia, and extend the library (4 extra lines with ccall) if it's not available, and send a pull request to help the community.

Re: Why Julia

#108

Earlier quoted context omitted.

What were you planning to use Julia for where its init time matters?

Nothing, i'm just curious [1] about Julia. I never used it. [1]It's just because i find the science python stack a bit absurd.

Right now, using is as a “quick” command line utility for solving small problems is probably not a good Julia work flow (unless the overhead you mention doesn’t matter to your application). Where it shines is for longer-running or repeated computations where the initial compilation cost of starting a new REPL doesn’t matter.

Re: Why Julia

#109
post #106

Earlier quoted context omitted.

And 80% of the internet switches (Cisco and juniper) are controlled by erlang. So? I think you're looking at this wrong. Part of the reason why so many large scale products use OO, is because they use Java, and java is awesome if you're working at such a large organization that your productivity is most easily measured by pointy haired managers who count how many LOC you've written ;) As for readability and conceptua…

I might be wrong, but my understanding is things happened backwards from that. OOP tried to solve the problem of how to get tons of devs working on huge projects at the same time; java came along to try to be an awesome OOP environment, so Java became the standard.

What is or is not OOP is actually fuzzy. When it boils down to it erlang's actor model is basically an implementation of smalltalk objects (but don't tell joe Armstrong that). Elixir's module/struct/protocol looks awfully like OO in the post bjarne soustrop era.

Conversely, python's objects feel anti-object since you're passing self all the time (aka dot notation is a weaksauce syntactic sugar)... You could easily model this behavior if you really wanted in Julia, for example, with a custom operator (not that you should)

    function Base.^(o  fn(o, a...)
    end

Re: Why Julia

#110

I want to like Julia but after a decade of Python, every time I try it, it’s a death by a thousand cuts (and outdated Google results). I just can’t afford to have productivity drop to near zero for the learning curve plus reimplement everything. Also I ha e found multiple dispatch to be harder than regular OO methods to locate (for IDEs but grep also).

Have you tried methods(some_function) or the @which macro?
Post reply on HN