Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Julia

ucidatascienceinitiative.github.io

Post reply on HN
Print view View original

131–140 of 257 posts

Re: Why Julia

#131

Post by andrewflnr »

dnautics wrote: post #101
RivieraKid wrote: post #98

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…

Erlang is arguably the most object-oriented language in common usage. Actor concurrency is closer to the original OO model than everyone else's "struct with methods". I'm more inclined to agree with you overall, but Erlang might not be your best example. :)

Edit: never mind, you're obviously aware...

Re: Why Julia

#132

Post by agumonkey »

enriquto wrote: post #127
xiphias2 wrote: post #107

Earlier quoted context omitted.

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 availabl…

> Julia is not a scripting language, it's a language for mathematical analysis. Ok, this clarifies the matter a lot. So julia is not intended to be a general-purpose programming language. Are you involved in julia development? (Besides, I strongly dislike the design tradeoff of not being a good unix citizen.)

Not Scripting != Not general purpose

Re: Why Julia

#133

Post by agumonkey »

krull10 wrote: post #108
agumonkey wrote: post #87

Earlier quoted context omitted.

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.

Preaching the convinced

Re: Why Julia

#134

Post by altairiumblue »

Cosi1125 wrote: post #90
disgruntledphd2 wrote: post #79

Earlier quoted context omitted.

Nah, it's just a re-implementation of S, which was really, really old and different from what people expect. R is wonderful (and has multiple dispatch, thank you very much), but it's definitely not as familiar to developer types as Python is. R has lots of weird quirks (a[1] vs a[[1]] vs a[1,]) and uses function based generic programming rather than object based generic programming. Because of the re-implementation o…

Wise words here. In my humble opinion, applying S's syntactic sugar on top of Scheme-forged core did more bad than good to R. Most of R's quirks stem from the authors' desire to keep it as compatible with S as possible. As for the two approaches to solving problems (TIMTOWTDI vs Python's "one true way") I think that's a matter of personal preference; I, personally, appreciate the freedom that R gives me. Also, it mig…

Your very last point should be heavily against R, not in favour. Having multiple ways to do the same thing is fine when you work by yourself, but in a large team it makes the style of the codebase vary a lot based on who wrote each block of code and makes reviewing others' code more difficult. If you want to get anything done, reading code really shouldn't be your daily challenge of how "outside the box" you can think just so you can understand what is going on.

Re: Why Julia

#135

Post by ModernMech »

alexeldeib wrote: post #75
ModernMech wrote: post #53

Earlier quoted context omitted.

This is something I don't fundamentally understand. As someone who works a lot with MATLAB I'm very used to and like 1-based indexing. But when I use C or Python, 0-based indexing is not something I complain about or hold against the language. It's just the way things are. Maybe if you don't think of it in terms of a different index basis and instead you think of it as indexing vs. offsets then it becomes easier to s…

I don't hold it against any language, but it certainly breaks with common convention. The number of simple off by one errors I had when I started writing Lua was a bit irritating.

> but it certainly breaks with common convention

That depends on which circles you run in. If you're a programmer, yeah, it breaks with common convention. If you're a scientist or engineer, not so much. When writing a programming language for scientists and engineers you have a choice: do I stick with programmers' conventions or do I stick with engineers' conventions? I've had the pleasure of teaching both MATLAB and C++ to freshmen engineers. For them, they get off-by-one errors in C++, not in MATLAB.

Re: Why Julia

#136

Post by improbable22 »

zimablue wrote: post #129
ssivark wrote: 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…

Indeed it's starting to sound rather more like a church than a bikeshed!

I am curious what people write all day for this to be such a big issue. It's not like you need to re-invent N-dimensional array indexing every morning -- we have abstractions. If translating code then it could be from either convention... or from a mathematics book. (Where you may note that mathematicians are unconvinced by the CS arguments... admittedly not a group of people known for taste in all matters, but taste in notation they have thought about quite a bit.)

Re: Why Julia

#137

Post by tnecniv »

Honestly my biggest bug with Julia was the lack of good programming environment. I detest MATLAB, but I can be very productive in that IDE. PyCharm is pretty good too when using NumPy. For Julia though, the tooling just didn't seem there yet.

Re: Why Julia

#138

Post by newen »

ddebernardy wrote: post #115
ryanmonroe wrote: post #96

Earlier quoted context omitted.

Forgive my ignorance, but are you saying you use A[(i-1)×m+j] to get the element in the i-th row and j-th column? Why not use A[i, j]?

GP wrote (emphasis mine) 'For "2D indexing" into a 1D array '. I presume it's some graphics-related optimization or some pointer arithmetics-related work, but I'd also be curious about some concrete use-cases too.

Julia n-D arrays are stored contiguously in memory. So, you can access the memory by reshaping the array into whatever dimension you want and then access it using the A[i,j,k] syntax.

Re: Why Julia

#139

Post by ModernMech »

zimablue wrote: post #129
ssivark wrote: 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…

I'm not convinced. I've written a great deal of software in C++ and MATLAB. I don't see what the big deal is either way. You say this thing has been "decided 20 years ago" (by whom?) but that's clearly not the case, as myriad languages that use 1-based indexing are in existence, continue to come into existence, and are used to great effect. You cite Djikstra's argument (well, you didn't actually cite it [1]) but his reasoning isn't exactly air tight; he appeals to subjective ideas of "ugliness" and "unnaturalness" and "preferences" and cites a single anecdote for Mesa as proof of his correctness, then dismisses FORTRAN, ALGOL, and PASCAL out of hand as a "pity". Again, I'm not convinced.

[1] https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/E...

Re: Why Julia

#140

Post by jahewson »

fanf2 wrote: post #99
sametmax wrote: post #10

Earlier quoted context omitted.

Multiple dispach and meta programming are available in python as well. Although duck typing is usually a better solution and it's not really a killer feature to data analysts anyway. Compared to python, i'd say julia has the reputation for being generally faster for things you can't use numpy with, and you can more easily scale multiple cpu or machines.

Multiple dispatch has to be coded by hand in Python, it isn’t a feature of the language.

Python 3.7 added the ability to use type annotations with the @functools.singledispatch decorator which lets you write functions in a multi-dispatch manner.
Post reply on HN