Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software

sinews.siam.org

Post reply on HN
Print view View original

221–230 of 249 posts

Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software

#221

Post by dagw »

dagw wrote: post #216
wycy wrote: post #84

Earlier quoted context omitted.

Interesting. Doesn't this solve the problem then for people who can't get into 1-indexed arrays?

I suppose it kind of does for your own code, but you have to explicitly 'cast' all your arrays to 0-index arrays and it might break anything that assumes it's dealing with a normal 1-index array.

And realistically in many cases you won't even notice the indexing as you'll either be iterating over the array or using an array operator rather than accessing elements via an index. And in the remaining cases, much of the time whether the index is 0-based or 1-based won't affect the way the final code looks. Still, it's nice to have the option to 0-index in the few cases where it does make your code cleaner.

Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software

#222

Post by dagw »

mbauman wrote: post #191
Iwan-Zotow wrote: post #170

Earlier quoted context omitted.

please take a look at my rant below, do not want to write it twice

Your rant comes down to a distaste of +1s in certain situations. My point is that Julia's emphasis on arrays allows you to compose ranges with mathy operations in very powerful ways. You're concerned about composing APIs that take endpoints as arguments — I say you should just accept a range in the first place! Say I have an index `idx` into a very large array and I want to select a symmetric window of `N` indices be…

Python cannot even index lists by ranges (or other lists)

True for python lists, but not true for numpy arrays.

Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software

#223

Post by IA21 »

azhenley wrote: post #4

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.

> I wish more people viewed PL like this.

I wish less people abbreviated "programming language" to PL.

Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software

#224

Post by Sean1708 »

peteradio wrote: post #144
lenticular wrote: post #49

Earlier quoted context omitted.

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.

They're way ahead of you: https://github.com/JuliaPy/pyjulia

Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software

#225

Post by mbauman »

dagw wrote: post #222
mbauman wrote: post #191

Earlier quoted context omitted.

Your rant comes down to a distaste of +1s in certain situations. My point is that Julia's emphasis on arrays allows you to compose ranges with mathy operations in very powerful ways. You're concerned about composing APIs that take endpoints as arguments — I say you should just accept a range in the first place! Say I have an index `idx` into a very large array and I want to select a symmetric window of `N` indices be…

Python cannot even index lists by ranges (or other lists) True for python lists, but not true for numpy arrays.

Oh, I'm well aware. That gets at my point, though: Julia's ranges are _just_ arrays, and behave like all other arrays in the language.

Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software

#226

Post by goto11 »

phkahler wrote: post #177
coldtea wrote: post #165

Earlier quoted context omitted.

> 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 there's no zero-based indexing of floors, because the first item in the set of what are considered as floors is called "first" (e.g. primo in italian). 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"…

I think you misunderstand how the European numbering works. Think of it like Europeans count the separations between levels. There is no 0th separation, the first separation is the ceiling above the ground level. Saying that the ground level is the "first element" is begging the question - this is just not what Europeans count. (Well some do, but then they count similar to Americans, there is still no 0th floor ether way).

It is true that some elevators label the ground level 0, but this is usually when there are also negative levels (cellars).

Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software

#227

Post by lenticular »

xiaodai wrote: post #198
lenticular wrote: post #122

Earlier quoted context omitted.

I wasn't being disrespectful of Python. We are allowed to criticize languages. The fact is, by any reasonable measure, Julia is more expressive than Python, which was all I stated. This is an advantage of Julia. Both languages have advantages and disadvantages, and comparing them honestly is necessary for people to make a good choice when selecting a language for a project. C is less expressive than Python or Julia,…

Can you give concrete examples of where Julia is more expressive than Python? I can think of defining custom units https://medium.com/@Jernfrost/defining-custom-units-in-julia...

I give examples of expressivity in my comment above. The multiple dispatch is completely ubiquitous in Julia, being the default. This allows for the definition of flexible and extensible interfaces similar to Haskell's typeclasses. Macros are used to make things like PyCall or generate fast and flexible CUDA code.

This is not easily possible in Python, especially not with high performance.

Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software

#228

Post by byt143 »

emmanueloga_ wrote: post #180

I'm always looking for good computer tools to assist with learning Math with computers. I found this: [1]. Are there any other resources like this to learn fundamentals of Math with Julia? ([Linear] Algebra, Calculus, Geometry, Basic Physics, Discrete Math). 1: https://calculuswithjulia.github.io/

https://discourse.julialang.org/t/new-linear-algebra-textboo...

Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software

#229

Post by yellowapple »

pjmlp wrote: post #215
yellowapple wrote: post #178

Earlier quoted context omitted.

I feel like they're a significant departure from the OO concept of sending a message to an object (for example, "Foo ! bar()" in Erlang or "Foo.bar()" in a more typical OO language would be interpreted as "send message bar() to object/actor/whatever Foo"). Julia's approach is more "call this function on this object", which is indeed perfectly useful, but is semantically different.

That OO concept is pretty much Simula specific, Lisp languages got influenced by the work done in LOOP and Flavours which lead to the design of CLOS, the origin of multi-methods idea. Building on top of your remark, Julia's approach is more "call the visible implementation of this function that better matches the types of all given parameters". And these are only two possible ways of doing OOP, there are a few other…

That OO concept is also what Alan Kay et. al. were envisioning when they coined the term "object-oriented". It's all about message passing between blackboxed instances with isolated/private states. Multi-methods and such are cool and useful, but they're kinda secondary to that core concept (which Julia doesn't really have, to my knowledge at least).

In other words: object orientation != strong typing (even if they do tend to go hand-in-hand).

Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software

#230

Post by yellowapple »

mruts wrote: post #200
yellowapple wrote: post #152

Earlier quoted context omitted.

Ruby and Elixir both made the same decision, and I don't feel like it's had an actual negative impact, for me at least; I've found both languages to be delightfully readable. I haven't dabbled very much in Julia since the pre-1.0 days, but I don't recall it being any more or less jarring. I suppose it could indeed be jarring if you're not already used to languages which use 'end' to terminate blocks, but after awhile…

I mean, maybe it's not a big deal. But what value does it add? What if we had a 50 character string of random digits be the terminating identifier for a block? What about 100 characters? What about 200? Syntax shouldn't create visual noise, it should be as lightweight as possible. Maybe someone can justify why a 3 character word (end) doesn't really matter. But can someone give an argument on how it adds value versus…

Because 'end' has a specific meaning in English, and that meaning translates well to ending a block. If you decide you want a programming language geared toward Spanish speakers, 'end' would indeed be gibberish (unless they also speak English), but 'fin' would not be.

You can certainly argue that '}' is language-agnostic and therefore a better choice, and I wouldn't disagree with you. But 'end' is by no means an arbitrary choice for a character sequence that ends a block.

Post reply on HN