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…
The optional typing seems like the perfect solution to this... skip explicit typing for small scale projects, but make sure you add it for production...
I actually like 1-based for numerical work. A lot of great languages (Smalltalk, APL, Lua...etc) use it too. It makes sense with matrices.
APL let you choose. It was only trouble and then Iverson made J 0-based.
Yeah you can change when needed of course (forgot about that).
Iverson's J did a lot of things (chief of them was removing the awesome symbols) to make it more appealing. A lot of folks understand the cause, but also realize it takes away one of the best reasons to use APL. So moving to 0-base wasn't necessarily because he thought it was better.
I want to like Julia but after a decade of Python, every time I try it, it’s a death by a thousand cuts (and outdated Google results). I just can’t afford to have productivity drop to near zero for the learning curve plus reimplement everything. Also I ha e found multiple dispatch to be harder than regular OO methods to locate (for IDEs but grep also).
You don’t have to reimplement all your python work from the get go. You can call python from Julia.
I wish Julia would be more strict wrt type coercion of integer to float values. I've once spent a day debugging the issue caused by the following line of code, where t1, t2 are floats and v is an array: d = (t2 - t1) * length(v) It should've been LinearAlgebra.norm():Float instead of length():Int. Had julia been stricter the code would have failed to run, saving me much time.
I actually can't think of a single language that doesn't allow you to multiply an integer and a floating point value, yielding a floating point result.
> OOP tried to solve the problem of how to get tons of devs working on huge projects at the same time I am skeptical of that history. Simula and smalltalk were academic endeavors long before lots of devs were working on projects, Java became popular because it was a portable C++ which had no pointers and garbage collection.
Smalltalk was being adopted across the industry when Java came around, the big difference was that JDK was free beer and one of the big Smalltakers (IBM) rebooted their environment into Eclipse, while jumping into Java bandwagon.
That is seriously rewriting history. Smalltalk was not big in any shape or form in business in the mid '90s.
I recently began learning Julia and initially everything was amazing, except for 1 based indexing but with everything else I could overlook that. Then I attempted building something medium sized and it all fell apart. I feel like it needs some serious work on tooling, the module system, packages, etc. Has anyone built something medium-large sized in Julia? Maybe I'm missing something. When I was trying to use modules…
Agreed, that's my experience as well. Julia is amazing for scripts and smaller projects, but I wish there was something like Swift (which I'm increasingly convinced is closest to the ultimate general-purpose language) with all the nice things that Julia has. Specifically, these things make Julia less suitable for larger projects: - Lack of support for OOP. And no, purely functional programming is not the best way to…
> - You can't use a function before it's defined.
I'm not sure what you mean by this. You obviously can't call a function before it is defined, but you can use a function in another function without any problems:
julia> foo(x) = bar(x)
foo (generic function with 1 method)
julia> bar(x) = x+2
bar (generic function with 1 method)
julia> foo(3)
5
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…
THanks for a serious reply. The cached function computation argument is an interesting one, which resembles the answer by evanb here https://mathematica.stackexchange.com/questions/86189/why-do... I hadn't seen it before, basically if I understand it right treating all vectors as lisp s-exps which are themselves 0-indexed (0th element is 'list' , because you're doing a lot of symbolic manipulation. It's the best argu…
No, IIUC, my explanation is nothing like what's mentioned in that comment. I'm trying to argue that it behooves us to use indices which conveniently model the problem domain, not some holy system where the head always starts with zero. I gave several examples to the effect, where zero based, one based, or different offset indexing makes sense. If you're really curious to continue the discussion, feel free to reach out via email (refer my profile). This thread is become unwieldy.
honest question, not a serious SDE here. In what ways is julia not supportive of OOP?
It doesn't have interfaces for example. It doesn't have access modifiers. Also, not sure if this belongs to OOP but working with optionals is cumbersome.
Again sorry for being dense but:
- aren’t access modifiers the way to define scope? That is possible in julia.
- getters and setters, wouldn’t those be defined in a struct in julia?
- inheritance: pretty sure this doesn’t exist in julia.
I seriously barely understand, i’m reading from the doc here: