no method round(MathConst{:π},)
Try Julia
71–80 of 105 posts
Re: Try Julia
#72Julia appears to be a perfect fit for much of what I do at work. I tried it, got very excited, and then facepalmed earlier today. Let's define two functions in the REPL: function foo() return 42 end function bar() return foo() end Evaluating bar() gives 42, just as one would expect. Now let's redefine foo(): function foo() return 69 end Evaluating bar() still gives 42! Not getting something so basic correct tells me…
Not getting something so basic correct tells me to avoid the whole thing for fear of getting subtly screwed by some other oversight.
No one denies that this is a problem, and it will be fixed. But I disagree that it represents a fundamental flaw. For iterative development, it is a minor inconvenience, so other priorities have taken precedence. If you are redefining functions in this way in tested code, there may be bigger problems to worry about.
The Julia developers have paid fastidious attention to correctness (to the point of making a pilgrimage to visit Kahan early on). The type system is well thought-out and nice to use. Spurious crashes are almost nonexistent (and fixed within hours, without fail). The foundation is solid, but it's still a work in progress, and it will take some time to shake these sorts of features out.
Re: Try Julia
#73Earlier quoted context omitted.
You change a function, and that change doesn't get reflected in upstream calls—this isn't a big deal? Are you kidding me?
I think everyone involved with Julia agrees that this is something that eventually needs to work, although it is not as big of a deal if you are loading code from disk, as opposed to writing functions at the REPL. See https://github.com/JuliaLang/julia/issues/265 .
That's the issues thread that I included in my initial post. Quoting from it: "When you redefine a method, the resulting behavior is undefined."
And these people expect to be taken seriously? Sell crazy someplace else, we're all stocked up here. The honest approach would be to forbid redefining functions.
This issue was brought to my attention by pals who had investigated Julia and rejected it for this very reason. No way I'll use it for anything. And that will be my recommendation to anyone who asks me about it.
Re: Try Julia
#74Earlier quoted context omitted.
You change a function, and that change doesn't get reflected in upstream calls—this isn't a big deal? Are you kidding me?
I don't see it as a big deal. You do, so my advice is to wait for 1.0.
Except that the linked thread on Github mentions that supporting the redefinition of functions isn't a v1.0 issue.
Re: Try Julia
#75Julia appears to be a perfect fit for much of what I do at work. I tried it, got very excited, and then facepalmed earlier today. Let's define two functions in the REPL: function foo() return 42 end function bar() return foo() end Evaluating bar() gives 42, just as one would expect. Now let's redefine foo(): function foo() return 69 end Evaluating bar() still gives 42! Not getting something so basic correct tells me…
Not getting something so basic correct tells me to avoid the whole thing for fear of getting subtly screwed by some other oversight. No one denies that this is a problem, and it will be fixed. But I disagree that it represents a fundamental flaw. For iterative development, it is a minor inconvenience, so other priorities have taken precedence. If you are redefining functions in this way in tested code, there may be b…
I was cheering out loud when I first downloaded Julia and started working with it. The type system, multiple dispatch, so much win! I'm working on ionospheric ray tracing at my day job and would love to use Julia.
But when I can write a nine-line example that produces incorrect output—no thanks. Especially when one of the lead developers (see the linked thread) states that supporting function redefinition isn't needed for v1.0. Clearly these people are working under a very different set of priorities than me.
"The foundation is solid"—I do not think it means what you think it means.
Re: Try Julia
#76Fun with Julia: julia> 3 ** 60 syntax: use ^ instead of ** julia> 3 ^ 60 -3535985420588157519 julia> factorial(45) -8797348664486920192 julia> factorial(75) 0 julia> 5 * 5555555555555555555 -9115710369641325457 julia> 5 * 55555555555555555555 syntax: invalid numeric constant 55555555555555555555 This isn't C. The expectations have changed thanks to scripting languages. If I'm supposed to use this promising language t…
Yes, Julia doesn't auto-convert to BigInt, it's a trade-off between performance and easy-to-useness, but they've definitely made the right decision. You have to convert to BigInt or BigFloat like this: julia> big(3) ^ 60 42391158275216203514294433201
Why not have them as BigInt and donwconvert to machine sized ints explicitly?
In any case. If you think of it as a nicer C, it works very well. It is a slight disappointment if you think of it as a nicer Python.
Re: Try Julia
#77Fun with Julia: julia> 3 ** 60 syntax: use ^ instead of ** julia> 3 ^ 60 -3535985420588157519 julia> factorial(45) -8797348664486920192 julia> factorial(75) 0 julia> 5 * 5555555555555555555 -9115710369641325457 julia> 5 * 55555555555555555555 syntax: invalid numeric constant 55555555555555555555 This isn't C. The expectations have changed thanks to scripting languages. If I'm supposed to use this promising language t…
Julia supports arbitrary precision arithmetic just fine, but you need to explicitly use it. Overflow checks don't matter in Python or Ruby where everything is relatively slow. See also: http://www.johnmyleswhite.com/notebook/2013/01/03/computers-...
I don't think many here argue that Julia doesn't support it. In fact it would be rather disastrous if it didn't, because it wouldn't make for a very nice scientific language if the biggest int value was 2^64-1.
The question is why aren't large numbers the default, or why doesn't it do automatic up and down conversion and so on.
Re: Try Julia
#78Earlier quoted context omitted.
My point wasn't that it can't be done. My point was about usability and what programmers have come to expect from a modern language. I understand that things get trickier when trying to implement arbitrary-precision arithmetic while keeping performance high.
Do you have an example of a language with arbitrary-precision overflow by default and comparable performance?
> Do you have an example of a language with arbitrary-precision overflow by default and comparable performance?
No, but that also means Julia isn't much special then either right?
Maybe it is just me but Julia positions itself as a better Python not just a better C, in that position, can you really blame people if they misunderstand and expect same "high level" behavior from it?
Re: Try Julia
#79Am I crazy for feeling like Julia is the new HN darling like clojure, go, ruby, lisp, and scala before it? It seems like in the last week it just started popping up on HN every couple days.
It makes sense. We hear about a language, take an initially skeptical approach to it, research it, try it out, and report our findings to others we think might be interested (i.e. HN).
Re: Try Julia
#80Am I crazy for feeling like Julia is the new HN darling like clojure, go, ruby, lisp, and scala before it? It seems like in the last week it just started popping up on HN every couple days.
I don't really see the problem with this. A lot of the languages you mention have been slowly and sustainably building support, even when they aren't on the front page of HN.