After typing next about 20 times without seeing anything interesting, I quit.
Try Julia
91–100 of 105 posts
Re: Try Julia
#92Earlier quoted context omitted.
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-...
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.
>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.
Scientific programmers don't expect a behavior different than Julia's from a modern language.
>I understand that things get trickier when trying to implement arbitrary-precision arithmetic while keeping performance high.
It's not merely "trickier". It's impossible to be fast enough.
Re: Try Julia
#93Earlier quoted context omitted.
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?
>No, but that also means Julia isn't much special then either right?
That's a really dumb conclusion. It's special in other things it offers (from a better Matlab like language with crazy ass speed to homoiconicy and great FFI). Who said it's only special if it fulfils some specific rainbow-unicorn pipe dream?
It also doesn't read the programmer's thought -- so not special in that regard either.
>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?
Lots of people also find Go a "better Python", and Go is like assembly compared to Julia...
Re: Try Julia
#94A lot of the comments I see about Julia (and other trendy high level languages) are of the following form: "I can do things I needed C to do before, and almost as fast" which leads me personally to ask, If you could do this in C before, and faster, then why are you switching? Most people will say "because C is bad/difficult/clumsy for doing X" which leads me to say, why are you using C to do X? I sincerely believe (a…
>which leads me to say, why are you using C to do X?
Because they know C, it's fast and it has lots of libs available. They might also dislike Java or CL.
Not every engineering decision is perfect, lots of factors play in.
>Attempts to combine the best of C (speed) with the best of scripting languages (easy to do things fast without having to pay attention to what you are doing) in my opinion end up merely joining the worst of both worlds rather than the best of both worlds.
The "pay attention" things is to needless complexity (memory management etc). They only reason we put up with those things was to get speed. If we can get adequate speed without those, nobody cares about them.
>Besides isn't programming about being specific? Do you really want to code stuff without having to worry about the details?
No, programming is about getting results. Nobody cares about the details in the level of programming language minutuae.
We care about the "effort put in" and "quality/speed of results coming out" ratio.
Re: Try Julia
#95Earlier quoted context omitted.
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 neede…
>Clearly these people are working under a very different set of priorities than me.
Yes, they are pragmatists.
Plus they know that the language is the first priority, not the REPL.
Re: Try Julia
#96Earlier quoted context omitted.
That annoys me too but it isn't a big deal, it'll probably get fixed in the future.
You change a function, and that change doesn't get reflected in upstream calls—this isn't a big deal? Are you kidding me?
That's only an issue for quick iterating tests in the REPL. The REPL is not a priority.
You're not supposed to rename functions in your code -- are you kidding me you're hang up on this?
Re: Try Julia
#97Earlier quoted context omitted.
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. N…
>This issue was brought to my attention by pals who had investigated Julia and rejected it for this very reason.
You should pick different advisors.
Re: Try Julia
#98Earlier 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?
That's only an issue for quick iterating tests in the REPL. The REPL is not a priority. You're not supposed to rename functions in your code -- are you kidding me you're hang up on this?
No kidding—this is a show-stopper for me.
I'm running Emacs with a split window for development. R runs in the bottom window, and the source file I'm editing is in the top. This lets me send code to R for evaluation and supports an incremental style of development. I'll slowly build up functions, and this sometimes requires editing functions that my current function uses. This style of development is typical for people using R, Matlab, Lisp, or any language featuring a REPL. But you can't do it in Julia.
Julia needs to support this style of development if it's to garner support from people using these languages. Full stop.
And the fact that Julia doesn't support updating functions makes me think that something is very broken down in the core of the language. The tone of the GitHub thread is: "We don't know how to fix this." Scary!
Re: Try Julia
#99Earlier quoted context omitted.
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. N…
> This issue was brought to my attention by pals who had investigated Julia and rejected it for this very reason. You should pick different advisors.
Nope, I should buy them beers since Julia is wholly unsuited for what I'm trying to do, which is interactive network performance analysis and interactive development of ionospheric ray-tracing code.
It's funny: I've forwarded this issue to several pals with experience in language & compiler design, and to a man they were dismayed that something so basic was going unfixed or was even broken in the first place.
Re: Try Julia
#100Earlier quoted context omitted.
That's only an issue for quick iterating tests in the REPL. The REPL is not a priority. You're not supposed to rename functions in your code -- are you kidding me you're hang up on this?
No kidding—this is a show-stopper for me. I'm running Emacs with a split window for development. R runs in the bottom window, and the source file I'm editing is in the top. This lets me send code to R for evaluation and supports an incremental style of development. I'll slowly build up functions, and this sometimes requires editing functions that my current function uses. This style of development is typical for peop…
Julia certainly allows you to redefine functions, it simply doesn't trigger automatic upstream recompilation.
https://gist.github.com/anonymous/8656066
> I'm running Emacs with a split window for development. R runs in the bottom window, and the source file I'm editing is in the top. This lets me send code to R for evaluation and supports an incremental style of development. I'll slowly build up functions, and this sometimes requires editing functions that my current function uses. This style of development is typical for people using R, Matlab, Lisp, or any language featuring a REPL. But you can't do it in Julia.
This is what everyone does in Julia too, with Emacs, IJulia, and others. Here is how to do it: put "module X" at the beginning of your file, and an extra "end" as the last line. Each time you send the file to Julia, the module is recompiled, and inter-dependent functions are updated to the latest version. Problem solved. This is mentioned (in a slightly different context) in the FAQ:
http://docs.julialang.org/en/release-0.2/manual/faq/#how-can...
But I admit it's not immediately obvious, and we should probably put it front-and-center somewhere.