Live data from Hacker News

Why Julia

ucidatascienceinitiative.github.io

111–120 of 257 posts

Re: Why Julia

#111
post #68

Earlier quoted context omitted.

> I do not have this mindset then. I prefer tools who are mindset oblivious. They are really useful! Yet you picked a specialized tool "imagemagick" (made for working with images), and want to drive it by another specialized tool (the shell, made for file and process management). Since you want "mindset oblivious" tools why not write everything from scratch, in C?

> Since you want "mindset oblivious" tools why not write everything from scratch, in C? Because imagemagick, julia and other specialized programs already provide the advanced algorithms that I need. Unfortunately, julia is not a good team player.

The Julia tooling is not currently designed for repeatedly creating new REPL/interpreter instances to quickly solve one small problem.

What it excels at is rapidly solving the same problem many times within one REPL/interpreter (since after the first time the code will be compiled), or for longer computations where the overhead of the initial compilation does not matter.

It would be great if it could also get fast at the use case you are interested in, but this isn’t currently what it excels at.

Re: Why Julia

#112

Earlier quoted context omitted.

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.

For "2D indexing" into a 1D array it's actually a little awkward. With an n×m matrix, - zero-indexed: i×m+j - one-indexed: (i-1)×m+j OTOH one-based is slightly better for trees stored in 1D arrays: - zero-indexed: parent=(child-1)/2; children=2×parent+(1, 2). - one-indexed: parent=child/2; children=2×parent+(0, 1). My favourite fact about this stuff: in VB (or was it VBA?) when you asked for an array of size n, you a…

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 with poor support for numerics and linear algebra, but then you should be abstracting this away from your callers.

Re: Why Julia

#113

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…

> - Lack of support for OOP. And no, purely functional programming is not the best way to code all projects.

Julia doesn't rely on functional programming and there are also structs and operator overloading. What feature do you think is missing specifically?

> Dynamic typing.

Julia is not dynamically typed, though if you write a type unstable function, you will get back an Any type.

- Module system doesn't seem to be design well.

What specifically is problematic?

Re: Why Julia

#114
post #82

Earlier quoted context omitted.

I use R daily at work, and often reach for it before Python for non-statistical tasks out of comfort. But R's functions for non-statistical tasks often break the language's idioms. Those dealing with files and connections are especially ugly. I wouldn't call it insane or unreal, but it's definitely not intended for general scripting.

I don't argue that R is not insane ;-) As for (a bunch of) functions in the basic library (which, essentially, is a set of packages that you can discard or simply not use), I dare say it has little to do with the language itself. I don't like Python's regular expressions library, for example, but it's only a set of functions (or methods) that you can write on your own! The same goes for R's data-wrangling routines; t…

> there's this tidyverse, and you can write good, reliable, production-grade code without using a single function from the base library

A different take on the subject (https://r4stats.com/2017/03/23/the-tidyverse-curse/):

> On the other hand side – I have met a guy using R in production. And he told me that he needs code that stayed the same for 5+ years. That is why he does not use dplyr or any tidyverse, it is still changing too much.

Re: Why Julia

#115

Earlier quoted context omitted.

For "2D indexing" into a 1D array it's actually a little awkward. With an n×m matrix, - zero-indexed: i×m+j - one-indexed: (i-1)×m+j OTOH one-based is slightly better for trees stored in 1D arrays: - zero-indexed: parent=(child-1)/2; children=2×parent+(1, 2). - one-indexed: parent=child/2; children=2×parent+(0, 1). My favourite fact about this stuff: in VB (or was it VBA?) when you asked for an array of size n, you a…

Forgive my ignorance, but are you saying you use A[(i-1)×m+j] to get the element in the i-th row and j-th column? Why not use A[i, j]?

GP wrote (emphasis mine) 'For "2D indexing" into a 1D array'. I presume it's some graphics-related optimization or some pointer arithmetics-related work, but I'd also be curious about some concrete use-cases too.

Re: Why Julia

#116
post #99

Earlier quoted context omitted.

Multiple dispach and meta programming are available in python as well. Although duck typing is usually a better solution and it's not really a killer feature to data analysts anyway. Compared to python, i'd say julia has the reputation for being generally faster for things you can't use numpy with, and you can more easily scale multiple cpu or machines.

Multiple dispatch has to be coded by hand in Python, it isn’t a feature of the language.

Sorry you are right. We only have single dispatch built in. I never had the use case for more so I confused them.

Re: Why Julia

#117
post #63

Earlier quoted context omitted.

Multiple dispach and meta programming are available in python as well. Although duck typing is usually a better solution and it's not really a killer feature to data analysts anyway. Compared to python, i'd say julia has the reputation for being generally faster for things you can't use numpy with, and you can more easily scale multiple cpu or machines.

By metaprogramming in Python, do you mean using decorators ? If so that's a far cry from metaprogramming

Import hooks with access to the ast, full object introspection and metaclass are not too shaby.

They are not that used though, too much magic and implicit processing are not promoted in the community.

Re: Why Julia

#118
post #106

Earlier quoted context omitted.

And 80% of the internet switches (Cisco and juniper) are controlled by erlang. So? I think you're looking at this wrong. Part of the reason why so many large scale products use OO, is because they use Java, and java is awesome if you're working at such a large organization that your productivity is most easily measured by pointy haired managers who count how many LOC you've written ;) As for readability and conceptua…

I might be wrong, but my understanding is things happened backwards from that. OOP tried to solve the problem of how to get tons of devs working on huge projects at the same time; java came along to try to be an awesome OOP environment, so Java became the standard.

> 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.

Re: Why Julia

#119
post #112

Earlier quoted context omitted.

For "2D indexing" into a 1D array it's actually a little awkward. With an n×m matrix, - zero-indexed: i×m+j - one-indexed: (i-1)×m+j OTOH one-based is slightly better for trees stored in 1D arrays: - zero-indexed: parent=(child-1)/2; children=2×parent+(1, 2). - one-indexed: parent=child/2; children=2×parent+(0, 1). My favourite fact about this stuff: in VB (or was it VBA?) when you asked for an array of size n, you a…

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?

Re: Why Julia

#120

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…

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.
Post reply on HN