171–180 of 249 posts
As 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.
Earlier quoted context omitted.
> But why should you have to care, why not just sum(range)? Sure, if you have single infinitely fast CPU. In real life, we have to decompose problem, run it in parallel and compose it back. > Or @threads for i in eachindex(object) & let the details about how many cores be written once, correctly, elsewhere? Here I'm explicitly talking about details, how it should be done, importance of composition, monoids etc. I und…
1-indexed ranges can still be composable if we define them as open on the right at N+1 (which is how I imagine one would want to define things in their implementation). [1...N] = [1...N+1) = [1...K+1) + [K+1..N+1) So the real loss is your point (2) - which, I agree, makes the implementation much less elegant and simple.
you could make them work, but improper abstraction leaks out in so many fugly ways. F.e. in Python you could compose functions, not only ranges. What do you pass in? Simple, [0, len(a)). What you get out? Simple, len(a). So you could operate on ranges composing function calls like in FP. Even works for unknown beforehand sequences/streams, just count along the sequence how many events you processed, and return it as length, and it could go into composition function. With Julia you have to think what is passed and what is returned. Shall I always return len(a)? Or maybe len(a)+1? What to return in case of streaming events? Sometimes len(a) and sometimes len(a)+1 with tons of comments and warnings? It is not a good way to deal with all that and not a good way to build API. Could be done and probably was already done, sure. BUt simplicity, elegance and composability is missing in the base design.
I'm ready to burn a part of my karma to say the following : - Naming a PL "Julia" is sexist and creepy - The language doesn't add any substantial value to PL theory or programming methodology compared to say, Python - The future of computer-human interaction is not in programming. Python will be good enough until we reach that point where we can use neural networks/AI to do most of the business tasks.
- I don't think Python added anything to PL theory or methodology either. At least Julia introduced multiple dispatch to a new audience.
- How is the name sexist or creepy?
Earlier quoted context omitted.
This is why the language creators usually avoid using the word 'homoiconic' because every time one uses that word there's a finite probability of being bogged down in an incredibly uninteresting semantic argument. Instead, people prefer to say that julia code is just another (tree-like) data-structure in the language and it can be manipulated at runtime with functions or compile time with macros or at parse time with…
Then why not just say 'Julia has macros'? Lightly perusing the description of Julia's features, that seems like a clear way of expressing what it is. (I also vaguely recall Julia describing its type system as "dependent" in way that goes against convention. Maybe they just liked controversy in the early days!)
Earlier quoted context omitted.
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?
“Ground floor” is not the European name; the names are things like “Ground of the roadway” (literal word-by-word translation of the French name), “first floor”, “second floor”, etc. It's no more zero-based indexing than naming relations as “sibling”,“first cousin”,“second cousin” is, just because some hypothetical culture that also uses 1-based indexing but counts siblings as first cousins might rationalize our syste…
Earlier quoted context omitted.
Maybe it works great, but the syntax doesn't feel native to me, and I don't see it used in the standard library, which means that it's not embraced by the language developers.
Not many folks use the macros that those macro-trait packages define, but the technique itself is in widespread use throughout the core language and standard library. That's where it was first posited and implemented, in fact: https://github.com/JuliaLang/julia/pull/8432 (and see the link to the "trait trick")
Earlier quoted context omitted.
If I heard that in other countries their use of 1st floor was 1 off from me, and they had a name for whatever was before 1, then what they have is like a zero, especially if some elevators use the literal 0 to mean the ground floor.
> and they had a name for whatever was before 1 What they have merely names what Americans name as zero. But it's not a stand-in for zero, for us, it's a different entity (a different thing). A floor (etage, piano, orofos, etc) is a "layer of building where people live above the ground level layer". So there's no zero-based indexing of floors, because the first item in the set of what are considered as floors is call…
So the floors are numbered according to their distance above the ground level (whatever that's called). This matches my suggestion of treating zero-based indexing as a distance from the first element.
>> Is there a zero-based indexing of the whole "heterogenous" set of ground level + floors?
Yes there is! It's how the elevator buttons are labeled with the possible variation of using a label instead of "0".
The European elevator numbering scheme according to your own comments matches more closely with a zero-based indexing scheme than a 1-based. Or more precisely it matches my proposal to consider the numbers used to reference array elements as distances rather than indexes.
I personally don't like the fact that you have structs but no classes and no instance methods, but I know this is personal and don't want to start a religious war this morning
Multi-methods are much more powerfull than instance methods, but yeah lets agree to disagree. :)
From the interview with the award recipients: “A programming language cannot be derived from first principles alone. Language design is applied psychology—the computer program is the ultimate human-computer interface. Sometimes you have to try a design out and see how people interact with it and iterate based on that real-world feedback.” I wish more people viewed PL like this.
For example, when I explained signed and unsigned to him, since we already covered the concepts of groups of bits having 2^n possible values, he quickly understood that signed has just as many values as unsigned, but the upper half just become negative inverse of the lower half.
C evolved from actual needs, and the fact that it's still widely used today shows how incredibly well designed it was for practical but relatively general problem solving. The C committee's job is mostly just a matter of saying "no" to every new feature request, because C has proven to be versatile enough to work in an extremely diverse array of situations.
We've been using Lua's C API and the Win32 API[1] to make cool things, such as a primitive Love2d clone, and just last night he said "Wait, you're telling me this is the old way of programming Windows? It just makes so much sense and seems so well designed!" C isn't perfect, but if you start from where C started, and trace it until now, you'll learn all the reasons behind its decisions, and they make sense in practical situations.
Kind of like the difference between metric and imperial measurement systems. Metric makes sense in an isolated mathematical world (i.e. science), bu imperial units make sense when you're working with real physical objects (e.g. construction).
Are there any other resources like this to learn fundamentals of Math with Julia? ([Linear] Algebra, Calculus, Geometry, Basic Physics, Discrete Math).