241–250 of 257 posts
Earlier quoted context omitted.
First of all that is ridiculously slow. Secondly, unlike Matlab you don't have everything you need available after starting the REPL. For instance if you want to plot something you might run `using Gadfly`. How long does that take? 16 seconds. Sixteen seconds. For real. This is not usable.
Hold on how long is MATLAB boot ?
Earlier quoted context omitted.
If you are running a script over and over (or using small modules to do organize things) it will be very fast and easy to work with. The compilation is just for the first time a script is run, not every time. It really isn't a barrier any more than, say, waiting for `library` commands in R.
I don't think I've ever seen an R library() take more than about a second, and usually the action is complete as my finger is starting to raise from the 'return' key. When I tried "using Plots" in julia, it took several tens of seconds the first time, and several seconds in subsequent sessions. So, slower than R, but not terribly so. I suspect the real advantage of Julia is that it lets the analyst stick to a single…
1) I can contribute to widely used packages like DataFrames and HypothesisTests. I had never made a git commit before this and my only "real" programming was CS 101 in Java. The fact that I could get up and running so easily contributing is a testament to the language's ease of use
2) I think its tough to predict your computational needs at the start of a project. Sure everything can be done in `lme` in R at the outset, but if you need some new bootstrapping procedure that a reviewer wants you might be left connecting some high performance code to an existing, large, R-based codebase. That's tough. I think Julia makes that "refactoring" (if you can call it that) easy.
3) Hopefully Julia will open a lot of doors for me in the future in my research career. I will be able to write interesting simulation procedures that are otherwise too unweildy for the comparison R or Stata economist.
Earlier quoted context omitted.
If you're going to give a counterexample, please give it. I thought about my post after I read it and came to this- given Djikstra's (only system which can describe an empty interval and interval with first element without "unnaturals" ) and (?)'s argument that it creates a nice homomorphism between real-number intervals and integer slices then it's inarguable to me that 0-based is more mathematically elegant. Where…
Since @zimablue seems serious about this, and for those who care as much about the array indexing question and why Julia's "arbitrary" indexing might be useful, here are links to a couple of my previous comments [1,2] on HN: [1]: https://news.ycombinator.com/item?id=15473169 [2]: https://news.ycombinator.com/item?id=15472933 -- The idea is that the interface to the data structure should ideally closely match the sema…
It depends. In the USA, 0-indexed floor numbers are the norm. Elsewhere (eg, Australia), 1-indexed floor numbers are the norm.
The main issue I encountered as a Julia user is that multiple dispatch doesn't scale very well. When you start building out a project, it's easy to keep track and debug if multiple dispatch starts failing (i.e. type starts spreading everywhere and Julia slows to Python like speeds). In medium-to-large projects, it becomes extremely cumbersome to manage this. It's doable, but adds a layer of complexity management to p…
There's no reason Juno or any other IDE couldn't display the output of a static analyser inline, or allow you to command-click a function call to go to the site of the exact function being called, or show a list of alternatives, and so on.
Give Julia and its IDEs a few years to improve and you might find it much better suited to large projects. I wouldn't consider Java any good for large projects either, if it didn't have the excellent IDE support it now enjoys.
The main issue I encountered as a Julia user is that multiple dispatch doesn't scale very well. When you start building out a project, it's easy to keep track and debug if multiple dispatch starts failing (i.e. type starts spreading everywhere and Julia slows to Python like speeds). In medium-to-large projects, it becomes extremely cumbersome to manage this. It's doable, but adds a layer of complexity management to p…
Earlier quoted context omitted.
In python you’d normally just use module level functions for that. Using a class without having instances and all static functions doesn’t really buy you anything.
The only problem I found with this approach is to manage state and dependencies: say, if the functions need to work with database, it is not convinient to send it as a parameter. A class instance initialised with a database looks more feasible in my opinion.
Earlier quoted context omitted.
Yes, I got that. But the "good parts" according to this artcle derive from where it can work like a statically typed language.
Yeah but it's not statically typed. Let's say you have a machine learning algorithm and you'd like to change your algorithm to have a complex-valued weights instead of float valued weights. How do you do that in a statically typed language? Let's say you want to test the numerical performance of the fast Fourier transform using an alternative datatype to IEEE 754 (for example bfloat8). How do you do that? Another app…
You can do that only if the interface for both types is identical or compatible. They should offer at least a common subset of the same operations. Hence, "generics" is the answer to your question.
I understand your feeling. But my impression is that this kind of "black magic" isn't always the best. With generics and static typing, if it compiles, you'll know it will work. With "type inference" you need to test it at runtime. It may compile with near-native performance, or it may not. And maybe a small change in your source code will turn near-native performance to dismal performance.
Earlier quoted context omitted.
All fair enough but not particularly relevant here (in the context of "why Swift"). For doing numeric work in a language actually defined for that purpose, you will have proper 2D (and hopefully n-D) arrays, and hopefully slicing operations on them. So you'll never do this. In this context doing 2D indexing in 1D arrays is a code smell. It does come up in the case of writing libraries for general purpose language wit…
Well, the nice thing about doing 2d indexing in 1d arrays is the 1d array sits in one contiguous block of memory, which can be important for performance, and also makes it a lot easier to pass the array to C libraries (which I think you alluded to). Whereas in a lot of languages, int[3][3] might be stored as 3 pointers to 3 arrays. I imagine Julia optimizes this?
Earlier quoted context omitted.
Faster startup, better printing of values, integrated package manager, integrated help system, filesystem autocompletion, etc.
Swift actually has faster startup, a better package manager by far, better custom printing support. It also has playground and jupyther notebook integration. Swift is a solid piece of engineering, Julia is a hacky toy.
Earlier quoted context omitted.
And these were not published on their website: https://arxiv.org/pdf/1801.10277.pdf http://proceedings.mlr.press/v37/regier15.pdf https://arxiv.org/pdf/1803.00113.pdf I had to go so far as to read the project Github page to find them.
In all those papers, there at least one member of the team in the author list, or a member of a partner organization (Intel, Lawrence Berkeley National Laboratory, etc). I wouldn't call them fair independent reviews of the language.
Whose opinion do you want, the Pope? Would a divine sanction be enough for you?