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

161–170 of 249 posts

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

#161

Post by hpcjoe »

you_owe_me wrote: post #58
lenticular wrote: post #46

Earlier quoted context omitted.

It's extremely expressive. Notably, Julia is homoiconic, with full lisp-style macros. It also has multiple dispatch, which is a far more general technique that OO single-dispatch. This makes it very easy to define modular interfaces that work much like statically-typed type classes in Haskell. This allows you, for example, to define a custom matrix type for your bespoke sparse matrix layout and have it work seamlessl…

Please don't vilify Python or R thinking that will help with Julia's adoption or popularity. If Julia is as awesome as its evangelists say, it will gracefully displace its competitors without the need of a smear campaign

Hmm ... I remember when Perl was king and Python was the shiny new thing. I watched Python supporters belittle Perl as "line noise" and other quite silly descriptions. They were all proud of "there is only one way do to it" versus the linguistic Perl way of "there is more than one way to do it."

I am experiencing something of a sense of schadenfreude over defense of Python against a newcomer. 20 years on, Perl is still in widespread use, still unbeatable for its growing use cases. I don't wish to speculate where Python will be 20 years from now. I do know that Fortran will still be around. That's about the only sure thing.

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

#162

Post by e12e »

Twisol wrote: post #97
coldtea wrote: post #65

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

Index finger, or first finger, right next to the zeroeth finger, the thumb... ;)

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

#163

Post by 3JPLW »

xiphias2 wrote: post #96
vanderZwan wrote: post #47

Earlier quoted context omitted.

I thought Tim Holy's Trait Tick was considered the de facto way to use traits in Julia? https://github.com/mauro3/SimpleTraits.jl

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")

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

#164

Post by yellowapple »

xvilka wrote: post #83
SiempreViernes wrote: post #26

Earlier quoted context omitted.

the "Ju" in Jupyter is for julia, do you mean you want Jupyter without the python support?

Yes, this is why I said "without Python".

Wouldn't it be easier to just use Jupyter and not use the Python-supporting stuff?

Just because Visual Studio supports Visual Basic doesn't mean I can't use it when I'm only interested in writing things in C#.

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

#165

Post by coldtea »

threatofrain wrote: post #157
dragonwriter wrote: post #151

Earlier quoted context omitted.

“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…

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 called "first" (e.g. primo in italian).

So, the thing one must understand before they say "same difference", is the other cultural difference: that most European countries don't consider the ground level "floor" to be a floor/story.

I.e, we don't consider the upper floors and the "ground floor" to be in the same set. Which is also why we don't count them when we say a "2 story house" (and we mean a house with 3 such layers, ground story + 2 stories).

Is there a zero-based indexing of the whole "heterogenous" set of ground level + floors?

Well, it's common to have the ground level designated with G or national specific names: BG, BV, E, IS, PB, PT, RC, S, P, PK, etc.

It's just that in some elevators 0 is a substitute for this -- which is probably due to the few common brands and parts being international and nobody bothering to change them (e.g. Otis). That's more a red herring than how Europeans think about floors or index them.

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

#166

Post by antpls »

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.

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

#167

Post by 3JPLW »

Iwan-Zotow wrote: post #71

Problem with Julia is not (only) 1-based array indexing, but their uses of ranges. Closed ranges are not composable. For Python-style ranges for a lot of operations (mean, sum, ...) I could define monoid, provide composition rules and be done with it. WTF I supposed to do with Julia ranges?!

Use them like the first-class vectors they are. You can use _any_ array manipulation on ranges.

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

#168

Post by dragonwriter »

antpls wrote: post #166

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.

> Naming a PL "Julia" is sexist and creepy

How? (I kind of assume that a big reason computer scientists would pull out that name without a specific referent in mind is the influence of the Julia set, named for Gaston Julia.)

> The language doesn't add any substantial value to PL theory or programming methodology compared to say, Python

Maybe; not all practical benefits in programming come from advances in methodology or PL theory.

> The future of computer-human interaction is not in programming.

I've been hearing that since the early 80s. When someone makes that future reality, we can discuss what it requires, until then programming is what we have and I'm glad it wasn't neglected for the last four decades, and I hope it won't be for the next however many it takes, either.

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

#169

Post by mattkrause »

antpls wrote: post #166

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.

Out of curiosity, what's wrong with the name? Using a human name doesn't seem much stranger than using the name of (say) a comedy troupe or fungus.

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

#170

Post by Iwan-Zotow »

3JPLW wrote: post #167
Iwan-Zotow wrote: post #71

Problem with Julia is not (only) 1-based array indexing, but their uses of ranges. Closed ranges are not composable. For Python-style ranges for a lot of operations (mean, sum, ...) I could define monoid, provide composition rules and be done with it. WTF I supposed to do with Julia ranges?!

Use them like the first-class vectors they are. You can use _any_ array manipulation on ranges.

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