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

111–120 of 242 posts

Re: Giving up on Julia

#111

Post by vitaut »

kazinator wrote: post #91
kazinator wrote: post #79

Earlier quoted context omitted.

If distances used 1 based indexing: metric distance conversion chart: cm m km 1 1.00 1.00000 2 1.01 1.00001 3 1.02 1.00002 ... 101 2.00 1.00100 ... 100000 1000.99 1.99999 The ratios between the values aren't fixed now; we can't go from cm to m just by scaling by 100. We must subtract, scale then add. One based indexing falls apart if you have to index a region of storage as bits, bytes and words at the same time.

It's ironic, though, that most languages report 1-based source code line numbers in their error diagnostics, regardless of how they handle indexing. So that does say something. And their documentation has section numbers like 1.1, 1.2, ... 5.3.3.

The current Julia version is 0.4.5 =).

Re: Giving up on Julia

#112

Post by cowsandmilk »

GFK_of_xmaspast wrote: post #52
arcticfox wrote: post #43

Earlier quoted context omitted.

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?

I've gotten 400x speedups going from python to c++.

I've gotten 400(+)x speedups by going from python to python.

Original program was 50min in python, 1 min pypy

After figuring out some inefficiencies that were O(Nsquared), it was 3 seconds in python

This was timing for a case where N was much larger than my normal cases, where run time had been a couple seconds with the original version and optimization didn't really matter.

Re: Giving up on Julia

#113

Post by vitaut »

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?

> 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.

Re: Giving up on Julia

#115

Post by bdowling »

eternalban wrote: post #107
johnsea wrote: post #85

Earlier quoted context omitted.

R and Mathematica are also 1 based. And R really is popular ( http://www.tiobe.com/tiobe_index?page=index - ok, popularity is droping right now, likely b/c of Julia ;-))

So is Lua.

Lua tables are more interesting than that. You can have an table that is indexed by any supported type. That means tables indexed by positive or negative integers, floating point values, references to other objects or other tables, true, false, strings, coroutines, and external memory references can all be indexes. You can also have a single table indexed by any combination of these.

Re: Giving up on Julia

#116

Post by vitaut »

3JPLW wrote: post #37
vitaut wrote: post #31

Earlier quoted context omitted.

This is actually a good point, but what about Unicode? Will `(UTF8String, Float64)` emit another function?

It's the same on 0.4, and Strings are getting a big overhaul on 0.5. Here are the results for 0.4: $ julia -e 'f(a, b) = @sprintf("this is a %s %15.1f", a, b); code_native(f, (AbstractString, Float64))' | wc -l WARNING: Returned code may not match what actually runs. 628 $ julia -e 'f(a, b) = @sprintf("this is a %s %15.1f", a, b); code_native(f, (ASCIIString, Float64))' | wc -l 194 $ julia -e 'f(a, b) = @sprintf("thi…

Thanks, this looks better. I'll need to update the post.

Re: Giving up on Julia

#117

Post by pygy_ »

banku_brougham wrote: post #108
jandrese wrote: post #50

Earlier quoted context omitted.

No less than Dykstra has weighed in on the numbering of arrays. http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF Having worked with both, I'm inclined to prefer 0 based addressing in most cases. It's slightly less intuitive, but it generally leads to cleaner code.

no less than dykstra was convicted of grand theft auto. https://en.wikipedia.org/wiki/Lenny_Dykstra I think you mean Dijkstra, who did say that, because of an argument with mathematicians about indexing from 1.

In Dutch, ij and ÿ are interchangeable.

Re: Giving up on Julia

#118

Post by eternalban »

bdowling wrote: post #115
eternalban wrote: post #107

Earlier quoted context omitted.

So is Lua.

Lua tables are more interesting than that. You can have an table that is indexed by any supported type. That means tables indexed by positive or negative integers, floating point values, references to other objects or other tables, true, false, strings, coroutines, and external memory references can all be indexes. You can also have a single table indexed by any combination of these.

Isn't that technically a hashtable and not an array?

Re: Giving up on Julia

#119

Post by SolarNet »

KenoFischer wrote: post #110
SolarNet wrote: post #92

Earlier quoted context omitted.

> - 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 think part of this problem is the community, multiple people have reported having bad interactions with core language devs. I can only think of a couple of instance where I've heard anything like this. The first and most prominent is Dan Luu. I'm very sad about losing him from the community. I've met him a couple of times in person, I still read his blog and I very much respect him. I don't think any of us have 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 on a problematic community and we can not discuss it.

As to the code standards, my problem isn't with the CONTRIBUTING.md; that seems fine. It's how people make long term suggestions about fixing lasting problems. As an example people who suggest refactoring large sections of Julia's expansive base library (1600 symbols? a problem that causes parts of the slow startup time and memory usage) into other libraries (which would improve batteries included, etc. features) are summarily ignored / shouted down / (predicated on my previous paragraph) banned. Important improvements to the language go in circles (often on JULEP tagged issues) especially any large improvement that would require multiple people and lots of dev work and seem to gain little traction unless a core dev just takes the time to just do it; rather than a timeline to reach consensus and then design a plan for implementing it.

As smaller examples. There was a push to increase test coverage and then months later commits plummeted the code coverage numbers and no one seemed to care. Sections of important code are uncommented, undocumented, and (mostly) untested on purpose. There are modularity problems and software architecture limitations inherent in the language design that go unaddressed. Unpredictable un-typed exceptions, namespaces/modules being hard to use for non-trivial designs, "interfaces" that aren't really. And these are just the ones without serious work behind them I can remember off the top of my head (the debugger and threading I acknowledge being worked on seriously). Though things being worked on seriously suffer problems as I mentioned earlier.

Issues like these cause many of the original poster's problems. Julia is a great language, but the community seems unable to take the steps it needs to to actually make a "Tier 1" general purpose language (e.g. like python, go, clojure etc.). Setup a serious set of policies regarding language proposals; setup a transparent community policy and actually follow it; acknowledge that certain development idiosyncrasies aren't going to fly anymore; take software architecture concerns seriously; remove the toxic core language dev (that to my count has cost you at least 4 serious contributors if not more).

Julia is likely "slowing down" relative to the expected development (which many people have observed) likely (by my thinking) because it is failing to attract/retain the developers it should be as a promising language (in my opinion) because of it's poor development and community standards.

But hey, these are just my suggestions, I don't have any skin in this game. I just wish Julia was as good as it promised to be, and I'm a bit bitter it isn't for human, rather than technological or financial, reasons.

Edit: Sorry I expanded, it felt unfair to not be more complete about it.

Re: Giving up on Julia

#120

Post by nonbel »

johnsea wrote: post #85
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…

R and Mathematica are also 1 based. And R really is popular ( http://www.tiobe.com/tiobe_index?page=index - ok, popularity is droping right now, likely b/c of Julia ;-))

>"popularity is droping right now, likely b/c of Julia"

I don't see how you concluded that? http://www.tiobe.com/tiobe_index?page=R

Post reply on HN