Live data from Hacker News

Why Julia

ucidatascienceinitiative.github.io

161–170 of 257 posts

Re: Why Julia

#161

Earlier quoted context omitted.

It doesn't have interfaces for example. It doesn't have access modifiers. Also, not sure if this belongs to OOP but working with optionals is cumbersome.

Python also doesn’t have interfaces or access modifiers. Would you consider Python to have bad support for OOP by those criteria?

Yes, Python definitely has bad support for OOP.

Re: Why Julia

#162

Earlier quoted context omitted.

Why? You've already come to the conclusion that anybody that disagrees with you is an idiot, and you think your argument is fully reasoned and covers all bases. Why should I believe that you would change your mind given new information?

I guess, because often you're not arguing in order to convince your opponent, you're arguing to sway the crowd (and sometimes, decide yourself). And I don't think they're idiots, I just think that they're wrong. Not many people have read Djikstra and (?) and have deep faith in mathematical beauty, or have even thought about this much, doesn't make them idiots.

The most prominent programming languages designed specifically for mathematical purposes (Mathematica, MatLab, Julia, R, Fortran), all have 1-based indexing. That should be a sign to you that 1-based indexing has a legitimate mathematical rationale. Djikstra wasn't speaking on behalf of the mathematics community. The idea that if you have deep faith in mathematical beauty that you'll come to the same conclusion is absurd.

Re: Why Julia

#163

I didn't know about the Unicode tab completion. I gave it a whirl on the cli and loved it. Then I tried it out in julia-mode in Emacs, and it works there too! What other editors support this?

Certainly Atom (and Juno), Sublime Text, and Jupyter notebooks.

Re: Why Julia

#164
post #70

Earlier quoted context omitted.

If that's someone's biggest complaint against the language, then I'd say the language must be pretty awesome ;-) It's basically bikeshedding. "But I look at the shed all day..." "But I'm used to looking at reddish colors..." "Red is more correct than green because ..." Let's all move on to more important things :-)

It's not bikeshedding because: 1) it is pervasive and fairly importsnt 2) it's kind of a deep indication that something is amiss. It's like a language written in 2019 that has default dynamic not lexical binding, not in terms of importance but in terms of it's an argument that was had and decided 20 years ago. If this is wrong then you can probably assume that lots of other things which are important, decisions which…

You’re repeating yourself without defending your point. Beating us over the head with how obvious something is to you doesn’t make your argument any more compelling.

> it is pervasive and fairly important

Why?

> it's kind of a deep indication that something is amiss.

Why?

> it's an argument that was had and decided 20 years ago.

Evidently not, if we’re having this debate.

> If this is wrong then you can probably assume that lots of other things which are important...are wrong

Why?

> google why 0-based makes sense by Djikstra

Is Djiktra’s opinion so infallible it supercedes the design choices of several successful languages?

Re: Why Julia

#165
Whenever I see people claiming that Julia is fast, I feel like they are cheating.

It is only fast if you don't count the "compilation" times.

For example, every time you are trying to plot something ```using Plots```, it will take over 40 seconds to compile the Plots package.

Then, you have the large memory usage. In my experience, plotting in Julia requires approximately 14x more RAM than in python or Matlab.

Julia has an awful experience, really.

Re: Why Julia

#166
post #63

Earlier quoted context omitted.

By metaprogramming in Python, do you mean using decorators ? If so that's a far cry from metaprogramming

Import hooks with access to the ast, full object introspection and metaclass are not too shaby. They are not that used though, too much magic and implicit processing are not promoted in the community.

Not to shabby indeed ! Now have to check whats up with Hy.

Re: Why Julia

#167
post #148
post #144

Earlier quoted context omitted.

Was it Visual Age for SmallTalk which became Visual Age for Java which later became Eclipse? Vaguely remember reading something like that earlier.

Yes. With Gamma, one of the pattern book authors, as architect on Eclipse team.

Interesting, thanks.

Re: Why Julia

#168

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.

Swift does have a REPL.

Re: Why Julia

#169

Earlier quoted context omitted.

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.

What's convenient about Swift as a language which "tries to do everything" is that you can mix and match. Sometimes it's convenient to use different programming paradigms for different components.

Re: Why Julia

#170

Whenever I see people claiming that Julia is fast, I feel like they are cheating. It is only fast if you don't count the "compilation" times. For example, every time you are trying to plot something ```using Plots```, it will take over 40 seconds to compile the Plots package. Then, you have the large memory usage. In my experience, plotting in Julia requires approximately 14x more RAM than in python or Matlab. Julia…

That's the trade off I guess, because of the JIT you have a slow initialization followed by very fast code.

That's not really good for a lot of workflows though (if you're running a smallish script over and over for example).

Post reply on HN