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

Giving up on Julia

zverovich.net

Post reply on HN
Print view View original

141–150 of 242 posts

Re: Giving up on Julia

#141

Post by lispm »

IshKebab wrote: post #45
unlinker wrote: post #34

Earlier quoted context omitted.

Why is strong/dynamic typing considered such a big deal?

Two main reasons: 1. You can detect very common errors (e.g. typos) at compile-time instead of maybe detecting them at run-time. This makes the code much much more reliable (or equivalently you don't need to do nearly as much testing). 2. Dynamic typing prevents IDEs from doing extremely useful things like real code completion and symbol renaming. If you're thinking "but I edit Javascript with code completion" or "co…

There are ways to deal with that in dynamically typed languages.

1) Common Lisp implementation use a compiler to detect typos, etc.

    CL-USER 21 > (defun bar () (fo0))
    BAR

    CL-USER 22 > (compile *)

    The following function is undefined:
    FO0 which is referenced by BAR
2) In Common Lisp one can ask the running Lisp system for information about classes, symbols, functions, etc.

The use cases for renaming are also completely different. If you take for example a Java class and you want to rename an attribute and update the getter/setters you might want to use a 'tool'. In a dynamically typed language like Common Lisp, this is often not necessary because code generation is widely used and changes can be propagate that way.

Re: Giving up on Julia

#142

Post by ScottPJones »

KenoFischer wrote: post #133
SolarNet wrote: post #119

Earlier quoted context omitted.

I remember plenty of cases I got simply from observing the Julia repo for a few months, I could list them if you like... But I've been told by Julia contributors before that discussing this on HN is not an appropriate place. So we can discuss it, where I start linking to public examples on HN, or you can ignore my opinion on a problematic community and we can not discuss it. As to the code standards, my problem isn't…

> I remember plenty of cases I got simply from observing the Julia repo for a few months, I could list them if you like... But I've been told by Julia contributors before that discussing this on HN is not an appropriate place. So we can discuss it, where I start linking to public examples on HN, or you can ignore my opinion and we can not discuss it. I do think HN is not the right forum to link to individual comments…

I haven't disappeared (even though somebody just might have preferred that I had done so), I still love the Julia language (even though I think there are some warts, some flab that can be lost, etc.), am still programming in Julia pretty uch 24/7, have been very active in trying to help people new to Julia (on Gitter, StackOverflow, Quora, julia-users), even teaching it to my kids, promoting it on Twitter, trying to help improve the language as much as I can without being able to submit issues or PRs on GitHub, and contributing what I can of my own work under MIT license on GitHub. I'm also attending JuliaCon 2016 this summer, will just have to see what my reception there will be.

Re: Giving up on Julia

#143

Post by Avshalom »

mindcrime wrote: post #140
bluecalm wrote: post #75

Earlier quoted context omitted.

The thing about 1 based indexing is that it's a kind of in your face "this is different" decision from the point of view of a programmers of most popular languages. To be honest I wouldn't want to start investing my time into a language where people who proposed 1 based indexing are making design decisions. It's not that I think they are incompetent but it's clear they care way more about some different world than ab…

To be honest I wouldn't want to start investing my time into a language where people who proposed 1 based indexing are making design decisions. Possibly because you're used to working with languages like C, C++, Java, Pascal, Javascript, Python, etc. But in the world of languages tied closely to scientific / mathematical programming (Matlab/Octave, R, etc.) 1-based indexing is the norm. If you'd "grown up" so to spea…

Pascal (and Ada) actually expects you to specify the both the first and last index foo[1..10] or foo[0..9] are both valid arrays (though I believe 1 is the traditional first index) which is handy when you do run into situations where one or the other is a poor fit for an algorithm.

Re: Giving up on Julia

#144

Post by eggy »

bmh100 wrote: post #41
vitaut wrote: post #19

Earlier quoted context omitted.

Thanks for the detailed response. I hope that my post wasn't too harsh, the intent was mostly to attract attention to the current issues not to undermine the great work that you and others have been doing. I'm glad that many of the issues that I mentioned are being addressed. Maybe I'll give Julia another go in some time =). The question of syntax is subjective of course. From the set {C-like, Python, MATLAB} I'd def…

One-based indexing is also used in Fortran, which seems to be used in a great deal of numerical computing even today. Additionally, BLAS/LAPACK is an important linear algebra library written in Fortan. I am somewhat confused by your discussion of startup times. Since Julia is a "programming language for technical computing", what scenario are you imagining where startup times would be a significant concern?

Fortran was meant to be a high-level language at the time, so chose 1-based indexing. When C and lower-level languages came on the scene they reverted it back to zero-based, since this is more appropriate at the lower hardware level. CBLAS is zero-based.

Intel's Math Kernel Library, which is a performant math library hand-tuned for Intel processors is zero-based in MKL-CBLAS.

It all depends on what you are familiar with, and staying consistent in use. I just use zero-based indexing in J and C and my numerical low-level work.

Re: Giving up on Julia

#145

Post by chrispeel »

SolarNet wrote: post #92
KenoFischer wrote: post #9

Happy to address these points: - Startup performance/memory usage Yes, we are definitely very acutely aware of these. Julia is not currently optimized for frequently run short scripts. That's the price on pays for having to bring up the entire runtime system (initializing the compiler, RNG, external libraries etc). The good news is that there will be a solution to this soon, which is to statically compile your julia…

> - Slowing down in development I think part of this problem is the community, multiple people have reported having bad interactions with core language devs. Also the policies for inclusion of features, how to propose features, how decisions are made with respect to the code base, etc. all seem poorly documented.

I have never had a bad interaction with the core language devs. OTOH, they are passionate about the language; I've found all the core developers I've met very helpful.

Re: Giving up on Julia

#146

Post by SolarNet »

KenoFischer wrote: post #133
SolarNet wrote: post #119

Earlier quoted context omitted.

I remember plenty of cases I got simply from observing the Julia repo for a few months, I could list them if you like... But I've been told by Julia contributors before that discussing this on HN is not an appropriate place. So we can discuss it, where I start linking to public examples on HN, or you can ignore my opinion on a problematic community and we can not discuss it. As to the code standards, my problem isn't…

> I remember plenty of cases I got simply from observing the Julia repo for a few months, I could list them if you like... But I've been told by Julia contributors before that discussing this on HN is not an appropriate place. So we can discuss it, where I start linking to public examples on HN, or you can ignore my opinion and we can not discuss it. I do think HN is not the right forum to link to individual comments…

> There are several recent examples where people have suggested such things

That's great but amount to a couple of functions, the larger issues addressing more serious refactorings never get off the ground (Base contains multiple thousands of symbols (not even counting how in a multiple dispatch language one symbol can contain hundreds of definitions) common lisp, by all accounts a sprawling language with multiple dispatch, has 978).

> I don't understand what exactly the criticism is. At first I thought it was about, too much dicussion, but then it seemed to be about too little dev time, please do clarify.

Both. Neither. It's about how there is unending discussion until a core dev just does it. This is not an efficient use of anyone's time. Set the scope of an issue, discuss, decide on a course of action, layout issues. This allows a core dev to get their input in place, but then not have to actually wait for them to have the time to do the whole thing themselves.

> There's somewhat of a tooling problem here, since we can't run the coverage tests on travis, so we don't get them integrated in the GitHub UI, but people do look at them and add tests as appropriate.

The number seems to fluctuate randomly from 83% in January, to 11%, 45%, 65%, 75%, 11%, 81% now. Which is a net loss and wholly sporadic. How does anyone know what to write tests for when coverage bounces all over the place? Also what good are the tests if no one takes the time to use them anyway? You have tests but they seem pretty useless with how you are using them. I understand it's a tooling issue, but a metric isn't very good if no one is bothering to use it, why waste the time to not use it.

> but I wouldn't say that they are so on purpose

"Look at the code and you'll understand." is the jist of the documentation of a 10000+ SLOC base used at the heart of Julia. Sure I could read all that, but I'd rather have a bit of documentation. Also the tests for this amount to it's examples.

> not some sort of unwillingness to fix problems

I disagree on at least 1 of them. Typed exception handling was flat out rejected because it's too much like Java by key devs; forget the fact everyone does it anyway using reflection. Interfaces and modules don't seem to make any progress because of some people complaining about similar issues.

> Putting together the road map of what goes into each release and prioritizing are very hard, because there's just so much that could be worked on.

Then stop wasting dev time and work on the community policies that make it easier to retain devs.

Re: Giving up on Julia

#147

Post by zintinio5 »

arcticfox wrote: post #43
zintinio5 wrote: post #30

For many users of Julia, long-running performance matters more than microbenchmarks. Having converted a naively written Python program to Julia (there was a huge amount of computation being done over a large search space), I experienced a massive speedup even against PyPy. My Python scripts ran for about 10 hours before I called it quits (.6% of the work had been completed). Converting to Julia allowed me to finish w…

Just how naively was the Python written? ~1600 hours vs. 4 hours of execution time sounds like some extremely naive starting code. Is it fair to even compare them?

The Julia version was a literal translation of the Python version, the only difference being that I changed the entry point in the Julia version to allow restarting searches in different ranges. That made parallelization very easy, which is where I got most of time saved. I distributed the work across 3 machines. However, even without parallelization, the Julia version progressed much further than either CPython or PyPy. I also attempted a C version before Julia, but I ran into some issues, which Julia handled without me having to write extra code (int128 support out of the box, and various functions for prime numbers). The int128 support was the main reason I didn't write it in C, as I came across a lot of contradictory information online for __int128 in Clang or GCC.

Re: Giving up on Julia

#148

Post by bluecalm »

dnautics wrote: post #95
bluecalm wrote: post #75

Earlier quoted context omitted.

The thing about 1 based indexing is that it's a kind of in your face "this is different" decision from the point of view of a programmers of most popular languages. To be honest I wouldn't want to start investing my time into a language where people who proposed 1 based indexing are making design decisions. It's not that I think they are incompetent but it's clear they care way more about some different world than ab…

You shouldn't be so biased. Having one based indexing makes translating numerical recipes from pure math textbooks (where vectors and matrices are generally one-based) simpler and less error prone. I say this as someone who chafes at Julia's one based indexing as a matter of professional practice.

It's very error prone if you implemented algorithms using 0 based indexing your whole programming life. You are just bound to make mistakes if suddenly it's 1 based indexing.

I am not saying 0 based indexing is technically superior (I really have no opinion on that). I could compare it to switching positions of brake and accelerator in a car - you can talk about brake on the right design being superior all you want but the fatal crashes will happen if you implement it.

Re: Giving up on Julia

#149

Post by zintinio5 »

xyience wrote: post #51
zintinio5 wrote: post #30

For many users of Julia, long-running performance matters more than microbenchmarks. Having converted a naively written Python program to Julia (there was a huge amount of computation being done over a large search space), I experienced a massive speedup even against PyPy. My Python scripts ran for about 10 hours before I called it quits (.6% of the work had been completed). Converting to Julia allowed me to finish w…

PyPy doesn't get you that much -- were you not using Numpy to begin with, and if not, why not?

Correct, I was not using Numpy. I did not think of a good way to fit my program into a Numpy shaped solution. The main point is that I didn't NEED to try, as an almost literal translation to Julia worked much better. I also did not try using Numba, which I suspect would have given me similar results to Julia. I am a fan of Python overall, but sometimes you just need to choose a tool that gets the job done with the least mental effort expended on the tool. This was a one-time script that needed to be written, no maintenance was needed: I just needed an answer, and within a certain amount of time.

Re: Giving up on Julia

#150

Post by rrock »

bmh100 wrote: post #127
vitaut wrote: post #113

Earlier quoted context omitted.

> what scenario are you imagining where startup times would be a significant concern? Starting a REPL or running a computation that doesn't take long time, adjusting parameters, re-running. Startup time may not be too big in absolute numbers but it's noticeable and adds up quickly especially if you start using more packages rather than toy programs that I used as an example.

Sorry if I was being vague, but what situation would you re-run a short computation by executing the whole program again instead of using subroutines? Are we talking about a data scientist performing initial, exploratory analysis on a very small subset of data?

I agree. I'd estimate I restart the REPL about three or four times a day while developing. My analysis runs are minutes or longer, so a few seconds spinning up Julia+packages just doesn't ammount to much.
Post reply on HN