Live data from Hacker News

Why I'm Betting On Julia

evanmiller.org

241–250 of 258 posts

Re: Why I'm Betting On Julia

#241

Is there a Julia forum anywhere. Like with a hierarchy of topics and subtopics and with hierarchical threads at the bottom level like HN? Optimally something that remembers what you've read.

Not a forum exactly, but julia-users and julia-dev are hosted on Google Groups which does threading and remembers what you've read. See the homepage for signup (julialang.org)

Thanks. A good variety of things there but I'm hoping someone puts together a phpBB (or similar) site such as Oculus Rift uses here: http://oculusrift.com/

Such an organized site where you could drill down to topics of interest through broader categories would really be helpful. It would be best, of course, if it was set up and accessed through julialang.org as something official.

I don't know how to do that or I would. It isn't reputed to be very difficult to set up a phpBB site and I'm sorta hoping some enthusiast who does know how picks up on it.

Re: Why I'm Betting On Julia

#242
post #202

We have a Julia and iJulia app on https://koding.com . It's going to be used by Harvard & MIT students soon. It's public and everyone can try it by simple login to Koding. The best part is you can easily try it online, without installing anything. Here is an screenshot of how it's look like (iJulia and Julia inside Terminal): http://d.pr/i/MsZt The source of this app can be found here: https://github.com/gokmen/julia…

I find the fact that I can't even find out what koding.com is when using IE 9 pretty obnoxious. Love it or not, many people are forced to use older browsers. Sending them to https://koding.com/unsupported.html without any explanation at all a great way to make people not want to bother finding out what you're offering.

But you do know and understand why they're not interested in supporting IE, right? And you'd feel the same way in their shoes, yes?

Re: Why I'm Betting On Julia

#243

Earlier quoted context omitted.

> I've never met a FFI I didn't come to loathe I've felt that pain. With so many new programming languages popping up, I've been wondering if the next killer programming improvement isn't strictly a programming language at all, but rather something that rethinks the linker, manages execution, and facilitates interfaces between larger blocks of code (maybe in multiple languages).

I've heard many very smart people (professors, leaders of large HPC efforts, "language geeks") express the same sentiment over the years. Unfortunately, it's a btch of a problem, as attested to by the veritable graveyard of half-baked solutions out there. Apple's "Bridge Support" is the closest thing I've seen to success (haven't worked with MS's CIL) and it leaves much to be desired. I'm not sure there is any way ar…

I keep hoping that some accessibility upgrade comes to the linker akin to how LLVM made compiler infrastructure more accessible, might make FFI bridging more automated. For example, if GDB can access and take apart C structs an automated way, why is FFI coding always seem to have programmers do a lot of mechanical interfacing work.

Not that all the other JVM, CIL, etc aren't approaches that yield some improvements, but something that upgrades capability or accessibility at the level of the ABI linkage level is going to be a wider impact.

Re: Why I'm Betting On Julia

#244
post #160

Earlier quoted context omitted.

Yeah, networkx is pretty good -- I actually meant that network analysis and text processing are the two areas where I'd be quite comfortable recommending Python over Matlab. For time series data, I'd personally pick R though, or perhaps SAS if it's large enough -- at least if any statistical analysis is involved... I need to check out Spyder.

R is a software that I still need to check out. I think enthought offers commercial tooling and support and also a IDE platform with tools for data story telling etc.. I usually use vim.

R design is somewhat like perl in the sense that usually there are a lot of ways of doing anything. This includes time series of course. That being said, last time I did time series, I've used xts and was quite happy with it.

Re: Why I'm Betting On Julia

#245

There's a lot to love in Julia, but my biggest nitpick is the 1-based array index. I can see where it comes from, but it's not something I can praise. I use R on a daily basis, where the aim is mostly interactive analysis, and still I cannot see any reason to use 1-based indexes. For a language that is instead mostly oriented to programming, I would have not went for the "familiarity" argument.

I'm guessing whoever was responsible for that decision was either a hardcore FORTRAN or MATLAB user, since both of those have 1-based indices. Or by a similar token, they could have chosen that because they expect that many of their users might be coming from either of those languages. I guess you'd get used to it, but I agree it's a big drawback.

Re: Why I'm Betting On Julia

#246
post #228

Can Julia be a competitor to R? I love R in concept (interactive environment for statistical analysis) but the language just drives me crazy in its multitude of types and the loosey-goosey ways it converts between them. A friend of mine is really proficient with R; when I walked him through some of the R patterns that are very confusing/irregular to me, he sort of laughed: he could see what I was saying but he said "…

Already in 2008 one of the R creators, Ross Ikaha, talked about how R is fundamentally slow and has inefficient memory use. And that a "next gen R" would be needed, and he was considering Common Lisp for the underlying language on compiler. See the "Back to the Future: Lisp as a Base for a Statistical Computing System". https://www.stat.auckland.ac.nz/~ihaka/?Papers_and_Talks But now apparently Julia also fulfills Ih…

https://github.com/blindglobe/common-lisp-stat

Re: Why I'm Betting On Julia

#248

Is there reason to believe Julia is actually fast outside of microbenchmarks? Their strategy of aggressive specialization will always look good in microbenchmarks, where there's only one code path, but could blow up in a large codebase where you actually have to dispatch across multiple options. I've never seen a Julia benchmark on a big piece of code.

I've had some problems with Julia performance for a finite element method implementation (https://github.com/scharris/WGFEA), mostly I believe because of (1) garbage generated in loops causing big slowdowns and (2) slow calls of function closures. Functions defined at the top-level which don't close over environment values are fast, closures however are quite slow, which is really painful for situations where closures are so useful, e.g. to pass as integrands to integration functions.

There is an github-issue about the closure slowdown, but I don't have it handy. Both can be worked around, by writing in a lower level style, e.g. by using explicit loops acting on pre-allocated buffers, avoiding higher-order functions, etc. The pre-allocated buffers can be a lurking hazard though (Rust avoids the danger in the same strategy with its safe immutable "borrow" idea). I felt like these workarounds were giving up too much of the advantages of a high level approach for my own tastes.

I have converted to Rust to avoid the garbage collection for sure, and I'm extremely pleased with the performance. It would be nice having a REPL though, I do miss that. And I do intend to stay involved with Julia. I'm sure the situation will improve.

Good high performance garbage collectors aren't easy (and they are easy to take for granted after being on the JVM for a while) - that's probably the biggest challenge for Julia as a high performance language, IMO.

Re: Why I'm Betting On Julia

#249

I really don't like the anti-intellectual tone of the beginning. "The problem with most programming languages is they're designed by language geeks, who tend to worry about things that I don't much care for. Safety, type systems, homoiconicity, and so forth." can be rewritten as: "The problem with most software is that they are designed by computer geeks, who tend to worry about things that I don't much care for. Inf…

And he misunderstands the "cowboy" reference in "cowboy programmers." The reference I believe is to lone operator who views himself as having superior skills and so does not integrate with the group, follow the coding rules and procedures, and generally makes work for others colleagues, often while ignoring their communications or responding to them with condescension.

Re: Why I'm Betting On Julia

#250
post #115

I really don't like the anti-intellectual tone of the beginning. "The problem with most programming languages is they're designed by language geeks, who tend to worry about things that I don't much care for. Safety, type systems, homoiconicity, and so forth." can be rewritten as: "The problem with most software is that they are designed by computer geeks, who tend to worry about things that I don't much care for. Inf…

I didn't pick up an anti-intellectual tone. His point is the same way I feel: stuff like type systems and homoiconicity (I don't even know what that means) don't interest me. I'd rather think about the work that I'm doing. Also, these things are a step or two above my level of understanding (but probably not the op's). I do care about security, thread safety, modularity, etc... but I can't really contribute to the de…

I personally care deeply about strong static typing as well as the work that I'm doing.
Post reply on HN