Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

Ivar thank you very much answering, that's the kind of insight that I was searching for ...you answered while I was still taking snapshots so sorry for the noise! :D On Thu, Jan 1, 2015 at 11:27 AM, Ismael VC wrote: > I get it now, in Julia stable releases are in a frozen branches instead of > b

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

I get it now, in Julia stable releases are in a frozen branches instead of being nodes from a stable master branch, which is what I was expecting. Instead of that master is used for developing the next release, qgit is helping me to understand Julia's work-flow: ​ Rust (like in the git book): ​

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

Yes, Git allows for many different models for development. As Julia is a pretty small project (compared to the linux kernel), we have a much simpler structure. Julia is also in a early phase so we are exploring different options, and we need a branch to distribute and try out new ideas. We also

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

Ok, so the branching models in "git book" are just examples not instructions. Thanks Sean! On Thu, Jan 1, 2015 at 9:36 AM, Sean Marshallsay wrote: > Ismael, > > I think you're over-compliacating Julia's workflow slightly, in that first > image you posted ( > http://git-scm.com/book/en/v2/Git-B

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

Ismael, I think you're over-compliacating Julia's workflow slightly, in that first image you posted ( http://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

Tobias: I don't think that Julia is more frequently broken, but Dann experienced this (his blog post started this discussion), I have also experienced it several times (but I'm an inexpert noob) and of course I'm sure other have also experienced this. I just wanted to know the advantages of Julia'

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

Hi Ismael, why do you think that master is more frequently broken in Julia than in other projects? This really does not happen often. People develop in branches and after serious review they are merged to master. This discussion further is to isolated and does not take into account that Julia

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

For us, master means the branch that people willing to test out new changes should be on, in order to provide feedback. If you don't want to do that you should use the stable branch. We try to keep master building as often as possible, and if it doesn't that should be considered a priority and addr

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

Perhaps we could add a diagram of the Julia work flow because I think we are using neither one of those models, we don't have lieutenants, nor a dictator do we? ​I'm sorry for the ugly diagram, I just want to really understand the current work flow, so correct me if I'm wrong. I don't know about

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

While the basic assert based tests are good enough for me, I do wish that the test framework could be more flexible. Some of this is historic - we started out not wanting a separate set of unit vs. comprehensive test suites. The goal with the unit tests was to have something that could be easil

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

This has actually been a particularly nasty bug, it broke many packages on 0.3.x, from Gadfly to GLM to HDF5, starting sometime in mid October. Tim had a workaround in Color.jl that solved some of the issues, but there are still reports of more failures. Thanks to Tim and Jameson for tracking

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

I haven't quite fixed it yet, although I've pushed it from the realm of a heisenbug to an issue with the return value of typeintersect for some specific inputs. I'm guessing however that this is one question where Jeff's expertise (in type system design) is rather critical, over emailing a distrib

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

Ah, that's good to know. Even better that Jameson may have fixed it! > On Dec 30, 2014, at 8:10 PM, Tim Holy wrote: > >> On Tuesday, December 30, 2014 06:40:30 PM Stefan Karpinski wrote: >> That change only exists on master, not in the 0.3.x stable releases. So it >> seems likely that you were

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

On Tuesday, December 30, 2014 06:40:30 PM Stefan Karpinski wrote: > That change only exists on master, not in the 0.3.x stable releases. So it > seems likely that you were actually using the unstable development version > of Julia when you encountered all of these problems. Otherwise you could > no

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

On Mon, Dec 29, 2014 at 3:37 PM, Dan Luu wrote: > I have a "stable" .3 build I use for all my Julia scripts and IIRC that's > where I saw the dates issue with Gadfly. I dunno, maybe I should only use > older releases? > This seems to be at odds with this claim in the blog post: When I worked ar

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

Just my two cents here Jim but I've been using v0.4 (usually updated daily) extensively since the summer and have only run into one segfault (which sat very firmly in "I'm doing something stupidly unsafe here" territory). I would argue that if you run into a segfault Julia is definitely not beh

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

> > And when I run the release-0.3 branch under valgrind (even something as >> simple as the empty script `julia -e ""`), the results can be somewhat >> scary (at least that is my interpretation). > > Valgrind tends to report false positives in language runtimes using > mark-and-sweep garbage colle

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

On Tuesday, December 30, 2014 5:02:00 PM UTC-5, Jim Garrison wrote: > > Part of the reason I was inclined to think that exceptions are unsupported > is that I often see my code segfault if I create an exception e.g. by > pressing Ctrl+C. For instance, if I open the REPL, and type > > julia>

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

On Monday, December 29, 2014 9:27:41 PM UTC-5, Stefan Karpinski wrote: > > On Mon, Dec 29, 2014 at 9:07 PM, > wrote: > >> >> I would really like if I could throw and catch an exception without >> needing to consider that my program might panic as a result of doing so. I >> just looked through th

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

+1 to everything Stefan said. Even for internals arcana, by a quick headcount there are (at very least) 10-15 people not named Jeff who have spent significant time in various parts of src/ and can point people in the right direction on questions about almost everything except (possibly) type infere

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

On Tue, Dec 30, 2014 at 12:11 AM, Dan Luu wrote: > If it helps clear the air, the specifics are that when I ask Stefan > how something works the most common response I get is that I should > ask you or the mailing list since it's your code and he doesn't really > understand it. He could probably

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

Thanks, Tim! On Mon, Dec 29, 2014 at 10:39 PM, Tim Holy wrote: > For anyone who wants to help with the test coverage issue, I just posted > some > instructions here: > https://github.com/JuliaLang/julia/issues/9493 > > --Tim > > On Monday, December 29, 2014 06:55:37 PM Ravi Mohan wrote: > > Fwiw

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

The Travis complaint is valid and really difficult. We rely on Travis pretty heavily since it's a great tool, but there's something peculiar that I don't think anyone fully understands about the Travis environment (VM config? amount of memory? dunno), Julia's runtime, or the combination of the

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

Only partly related, but one of the tings that I've found most surprising about Julia is how much of the substantive discussion and planning happens on Github vs the mailing list. Personally, I had a radically different view of the development process, etc after following the project on GitHub than

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

I have to say that Jeff and Stefan (and of course all the other from the "core" team) do an awesome job. I have been waiting myself for responses of Jeff but with a software project that big it is absolutely normal that one will not always get an immediate response to every bug report. If someo

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

> That thing about build stats? Probably grabbing the wrong numbers, which wasn't true, and could be easily spot checked by using the script pointed in my linked post. I apologize for missing that part if your post (and I added a follow up comment to the hacker news discussion once you pointed tha

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

Ok, I'm starting to see where you're coming from a bit better. As you can gather, I don't read every issue discussion (especially in packages) so I have not seen some of these things. Personally, I have always really appreciated your bug reports and fixed several myself. I hope to keep doing that.

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

Dan, thanks for the honest critique. Keno, Stephan, Jeff, thanks for the quick and specific replies. Tim, thanks for the very explicit instructions on how newbies such as myself can contribute. I also think julia-users is very welcoming, which helps me be bullish on the language. On Monday,

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

Hi Jeff, That's a lot of claims, so let me just respond to one, that my post "implies ... that we don't understand our own code". Where I've been vague and imply something it's because I don't like calling people out by name. I literally stated the opposite in my post, saying that the Julia cor

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

For anyone who wants to help with the test coverage issue, I just posted some instructions here: https://github.com/JuliaLang/julia/issues/9493 --Tim On Monday, December 29, 2014 06:55:37 PM Ravi Mohan wrote: > Fwiw the correct engineering response here seems to be to acknowledge the > subset of

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

Yeah, there's absolutely no problem with try/catch or try/finally. The only debate is about how much you should use them. HDF5 uses loads of `try/finally`s to clean up properly before throwing an error. --Tim On Monday, December 29, 2014 09:26:55 PM Stefan Karpinski wrote: > On Mon, Dec 29, 201

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

Fwiw the correct engineering response here seems to be to acknowledge the subset of Dan's criticisms that are valid/reasonable, fix those, and get back to work. Criticising Dan's motives etc isn't a productive path (imo) If there are low hanging fruit fixes on such a successful project,(the buil

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

On Mon, Dec 29, 2014 at 9:07 PM, wrote: > > I would really like if I could throw and catch an exception without > needing to consider that my program might panic as a result of doing so. I > just looked through the entire corpus of Julia code I have written so far, > and the only places I catch

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

On Monday, December 29, 2014 2:39:34 PM UTC-5, Stefan Karpinski wrote: > > Unlike Python, catching exceptions in Julia is not considered a valid way > to do control flow. Julia's philosophy here is closer to Go's than to > Python's – if an exception gets thrown it should only ever be because the

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

I feel like you are trying to convey the impression that finding bugs in julia results in insults and no help from us. That is a total mis-characterization of the project. There is also no equivalence between responses to bug reports, and responses to blog posts. As far as I know, all 9000 of our b

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

Welp, I ended up checking up on this thread again because of a conversation with Stefan, so here are some more responses. I tried https://github.com/dcjones/Gadfly.jl/issues/462 on the current release binary on julialang.org and it still fails as before, so that wasn't because I was running off of

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

On Monday, December 29, 2014 4:13:35 PM UTC-6, Jeff Bezanson wrote: > > But one > feature we could stand to add is asserting properties that must be > true for all arguments, and running through lots of combinations of > instances. > Anyone who is interested in this is welcome to use https://g

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

Reporting % success rather than demanding 100% success would seem to be a strictly weaker testing policy. Arguably, with macros you need fewer features since `@test a == b` could recognize an equality test and report what a and b were. But one feature we could stand to add is asserting properties

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

Dan, I know there are many areas where we should improve. For now I share Stefan's frustration about the mystery bugs you keep alluding to. I don't expect a full detailed report on each one, and I get that you don't want to interrupt work to file them. But we have now seen at least two blog posts a

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

I imagine there are advantages to frameworks in that you can expected failures and continue through the test suite after one fails, to give a better % success/failure metric than Julia's simplistic go/no-go approach. I used JUnit many years ago for a high school class, and found that, relative to

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

On Mon, Dec 29, 2014 at 4:58 PM, Milan Bouchet-Valat wrote: > I'd add: improve the manual to make it clear that Julia's philosophy > with regard to exceptions (easy). > > I'm only realizing today that exceptions are supposed to be raised in > Julia only when the caller is at fault. If we want pac

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

On Mon, Dec 29, 2014 at 4:45 PM, Steven G. Johnson wrote: > I'm don't understand his perspective on "modern test frameworks" in which > FactCheck is light-years better than a big file full of asserts. Maybe my > age is showing, but from my perspective FactCheck (and its Midje > antecedent) just

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

I think one important way to improve the stability of Julia is to separate Julia and its standard library (e.g. split Base into "crucial base" and stdlib). This will help making the core rock solid and will further reduce the number of binary dependencies to a minimum. It also helps to make more

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

Le lundi 29 décembre 2014 à 16:41 -0500, Stefan Karpinski a écrit : > I think the main takeaways from Dan's post are the following: > * Figure out a better way to measure coverage and work towards > 100% coverage. > * Make a thorough pass over all Base code and carefully examine

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

On Monday, December 29, 2014 4:12:36 PM UTC-5, Stefan Karpinski wrote: > I didn't read through the broken builds post in detail – thanks for the > clarification. Julia basically uses master as a branch for merging and > simmering experimental work. It seems like many (most?) projects don't do

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

I think the main takeaways from Dan's post are the following: - Figure out a better way to measure coverage and work towards 100% coverage. - Make a thorough pass over all Base code and carefully examine situations where we throw exceptions to make sure they are correct and can only

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

Stefan, ok. My advice was actually also constructive. I have tried various open source software in my life and there were several that were broken. But then I have simple not used it if I am not satisfied. I think it is clear that Julia's development model could be improved. But unless a compan

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

Let's please take Dan's comments as a constructive critique (which it is), rather than an attack. I know Dan personally and happen to know that this is where he's coming from. On Mon, Dec 29, 2014 at 3:58 PM, Tobias Knopp wrote: > So you dislike Julia and encountered several bugs. Reading your p

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

On Mon, Dec 29, 2014 at 3:37 PM, Dan Luu wrote: > Here are a few responses to the stuff in this thread, plus Keno's comment > on HN. > > The Travis stats are only for builds against master, i.e., only for > things that got merged. BTW, this is mentioned in the linked post. For > every project lis

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

On Mon, Dec 29, 2014 at 2:58 PM, Tobias Knopp wrote: > So you dislike Julia and encountered several bugs. Reading your posts is > like you want to blame someone for that. If you are not satisfied with Julia > simply do not use it. I don't really use Julia anymore! Thanks for the suggestion, thoug

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

To be fair, that's really an argument in Dan's favor, unless Dan is not a researcher, in which case you might be able to say that Julia is better for you because you're a researcher and Dan is not. But that would imply a domain mismatch. To say that one likes and understands a language, warts and

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

So you dislike Julia and encountered several bugs. Reading your posts is like you want to blame someone for that. If you are not satisfied with Julia simply do not use it. And seriously: You cannot compare Julia with a project that has Google in the background. Its clear that they have a "more

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

Here are a few responses to the stuff in this thread, plus Keno's comment on HN. The Travis stats are only for builds against master, i.e., only for things that got merged. BTW, this is mentioned in the linked post. For every project listed in http://danluu.com/broken-builds/, only the "main" bran

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

Slightly OT, but I imagine the try/catch Dan refers to is the display system. Unfortunately it is a horribly brittle way to implement that code that still now has the potential to cause bugs (due to the fact that you can't tell where in the stack the error came from). I'm prototyping something to t

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

Completely agree on the exception handling philosophy (as Stefen has put it). Not only should you not rely on exception handling to make your API reliable, for some reason encouraging exception handling has a way of making folks think very defensively: "Oh, so I should handle every possible scenari

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

There's lots of things that are very legitimate complaints in this post but also other things I find frustrating. *On-point* Testing & coverage could be much better. Some parts of Base were written a long time ago before we wrote tests for new code. Those can have a scary lack of test coverage. T

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

The post reads like a rant. As every software project out there Julia has bugs. So is it really necessary to complain about bugs of an open source project in a blog post? Am Montag, 29. Dezember 2014 18:30:26 UTC+1 schrieb Tim Holy: > > In my personal opinion, his post is a mix of on-target and

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

In my personal opinion, his post is a mix of on-target and off-target. I completely agree with the inadequacy of our testing, particularly in packages. However, it's also not entirely simple: julia is _so_ composable that it's hard to come up with tests that cover everything. Until recently we'v

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

Here is Keno's comment https://news.ycombinator.com/item?id=8810146 and the general HN discussion https://news.ycombinator.com/item?id=8809422 On Monday, 29 December 2014 17:44:35 UTC+1, Keno Fischer wrote: > > I've written up some of my thoughts on the issues raised in this article > in the hac

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

I've written up some of my thoughts on the issues raised in this article in the hacker news discussion, but to answer your question, there's still a number of big items that need to be tackled by the core team. I do think it might make some sense to have a docs/tests sprint just prior to the 0.4 re

[julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

Dan Luu has a critique of Julia up at http://danluu.com/julialang/ (reddit thread at http://bit.ly/1wwgnks) Is the language feature-complete enough that there could be an entire point release that targeted some of the less-flashy things he mentioned? I.e. commented code, better testing, error