Julia needs something like IPython/Jupyter but without Python.
That might be possible with nteract (Javascript, not sure if pure) and the IJulia kernel.
Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software
141–150 of 249 posts
Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software
#142what good is philosophy if you choose arrays based on 1? https://groups.google.com/forum/?hl=en#!topic/julia-dev/tNN7...
Please don't post unsubstantive flamebait to HN. We don't need yet another low-quality spat about array indexing.
Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software
#143As a current R user, and former SAS user, can someone give me an elevator pitch as to why Julia is worth my time? I use a lot of the tidyverse and some more niche epidemiology/stats packages in R, I'm also pulling in datasets on the order of 1-10 million rows from MS SQL.
One usecase: Do you want to do interesting cutting edge modeling of disease propagation dynamics or other complex systems simulation?
Then check this out: https://julialang.org/blog/2019/01/fluxdiffeq
Here's context : https://jontysinai.github.io/jekyll/update/2019/01/18/unders...
There's nothing else like it.
Also here's the julia equiv to dplyr: https://github.com/queryverse/Query.jl
Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software
#144Earlier quoted context omitted.
I think Python has a large advantage in this space since it is not as specialized. For many projects that I work on the actual core number crunching code is small (or part of a library I don't have to worry about). The rest of the code could be scraping data, or a web application. These are things that there are numerous packages available for in Python but seem to fall outside the focus of Julia.
Julia would be ideal for those task as well, but alas the libraries aren't there. Julia can easily call Python functions with PyCall, although I still wouldn't want to extensively use a complicated Python library in this way.
Seems like it would be better to call Julia from python.
Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software
#145Earlier quoted context omitted.
As a European I'm not really surprised, but it's not exactly the same thing. It's not like the ground level is considered "the 0th floor" and thus we use 0-based indexing. In most European countries the ground floor is not considered the same thing as the others. As Wikipedia puts it: "In most of Europe, the "first floor" is the first level above ground level". We consider and count as floors the "layers" above the g…
>> A multi-floor building with ground floor + 3 floors can even named "3rd-storey building" in some countries I think you just refuted your own previous assertion that 1-indexing is universal in all other aspects of life.
Not sure what you mean. There are 3 floors (as europeans define a floor, ie. anything ABOVE what americans call ground floor) and are named floor 1, floor 2 and floor 3.
So, no 0-based indexing here.
We call the house a "3-storey house" not because we zero index, but because the cardinality of it's floors (as europeans define a floor) is 3. In "3-storey building" for Europeans, 3 is the "length", not the last index.
Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software
#146Earlier quoted context omitted.
> It's the difference between numbering the contents of the list (1 indexing), and measuring the distance from the beginning of the list to the start of the item (0 indexing). The problem is that one is indeed an indexing (numbering the contents 1...X...N and asking for item X, customers[X]), whereas the other is not, but is used as an indexing (e.g. customers[5] is not getting the 5th item but the sixth).
Where does your definition of "an indexing" originate? The word "index" literally means "to point at" (hence, index/pointer finger), and in this sense, every element may indeed be indexed -- in this case, by means of a unique integer. If I had to give a name to the concept you're talking about, it would be an "ordinal index".
>If I had to give a name to the concept you're talking about, it would be an "ordinal index".
Which is both the naive understanding of a numeric index in everyday life in general, and the most common case in mathematics (and most math/scientific software).
Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software
#147what good is philosophy if you choose arrays based on 1? https://groups.google.com/forum/?hl=en#!topic/julia-dev/tNN7...
So does: APL, AWK, COBOL, Fortran, Lua, Mathematica, MATLAB, R, Smalltalk, Wolfram Because it is Mathmatics and have 1 be based on 0 makes no sense, you then have to switch between the two and it is easy to make a mistake. This is why I don't use Python and Pandas. I got burnt once and that was enough and switched to R. Sadly we are stuck with 0 based array in programming and due to a historical issue.
[deleted]
Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software
#148Earlier quoted context omitted.
Multi-methods are much more powerfull than instance methods, but yeah lets agree to disagree. :)
Sorry to continue, but could you elaborate on that? I understand both concepts, but not their relative merits...
Instance methods are bound to a specific object definition, thus they can only be applied to instances of that specific object or its descendants.
Also in static languages, the set of available instance is closed and extending it requires approaches like extension methods now available in a couple of OOP languages.
Whereas multi-methods are dynamically dispatched taking into consideration the whole set of parameters, and can be defined after the fact. Meaning that they aren't necessarily written in the same module that defines the respective data structures, which opens the door to more extensible designs.
Taking the Alan Perlis' quote "It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures." to the next level.
Because not only can you define all those functions that operate on one data structure, they actually apply to the tuple made by the dynamic type of all parameters at call site.
Naturally it also might make it harder to follow what actually happens with a given method dispatch.
This is my insight from having gone through "The Art of the Metaobject Protocol" and dabbling with multi-methods in Clojure, so I might not be 100% correct here.
Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software
#149Earlier quoted context omitted.
> as we do in all other aspects of life You mean like elevators? You may be surprised to learn that elevators in America are 1-indexed (ground floor == floor 1), but in Europe they are 0-indexed (ground floor == floor 0).
As a European I'm not really surprised, but it's not exactly the same thing. It's not like the ground level is considered "the 0th floor" and thus we use 0-based indexing. In most European countries the ground floor is not considered the same thing as the others. As Wikipedia puts it: "In most of Europe, the "first floor" is the first level above ground level". We consider and count as floors the "layers" above the g…
Ground floor, 1st floor, 2nd floor still sounds very much like 0-based indexing. Is the objection just that people don't literally say the word "zero", but instead say ground?
Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software
#150Earlier quoted context omitted.
That's a good point that it doesn't have the direct homoiconicity of Lisp, but it is not buried deep, since we have full access to the underlying AST as just an Expression type. In practice, this makes macros much less painful than in other non-lisp languages. This means that macros are used all the time, and idiomatically. The most proiminent non-lispy language with a macro system that I can think of is Scala. Macro…
I agree that macros are better than in other non-lisp languages, but I find them ugly in Julia. Maybe not painful, but they don’t integrate seamlessly into the language.
They are ugly, I agree. Personally, I prefer lisp (especially Clojure) syntax, but not many people agree with me there.