Live data from Hacker News

PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

dev-discuss.pytorch.org

161–170 of 291 posts

Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

#161
post #160

Earlier quoted context omitted.

And there's 1 guy he knows that's a 10x developer and always willing to take one for the team. I'll leave it to HN to figure out what that means :P

Call native libraries?

Write a metric shit ton of unmaintainable, underperforming pandas code and call it an effective solution

Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

#162
post #15

> Julia says: > A language must compile to efficient code, and we will add restrictions to the language (type stability) to make sure this is possible. > A language must allow post facto extensibility (multiple dispatch), and we will organize the ecosystem around JIT compilation to make this possible. > The combination of these two features gives you a system that has dynamic language level flexibility (because you h…

no data types, no operator overloading, no extendability of new functions to existing objects, no C/Fortran interop, mediocre performance. Need I go on?

Mediocre performance compared to what?

Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

#163
post #36

Earlier quoted context omitted.

Also no (official) REPL.

The Julia crowd really need to hang less value on the REPL - people writing serious production code don't use one, and scientists using Python have moved on to notebooks. At this point, having Julia be so focused on the REPL is a weird affectation.

I used notebooks when I did my PhD using Python, but have moved to the REPL using Julia on my PostDoc. The Julia REPL experience is so much nicer than Python's, it removes the need for notebooks completely for me.

Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

#164
post #16

Earlier quoted context omitted.

This is one of the nicer aspects of Julia. It starts out being a great language to work in. Its easy to implement algorithms that are generally difficult in other languages. Its important to remember that most of the python ecosystem, isn't written in python. The functions are often thin wrappers/objects around the real computation, which is often written in a faster language, C/C++/Fortran. Julia excels in composabi…

Let’s not ignore the giant elephant in the room: 1-based indexing. I don’t particularly care since I use R and Python but Java, C, C/C++, C# all used 0-based indexing. It’s truly a bizarre choice Julia made there.

It really is a rather small elephant. It can be jarring at first (unless you think of R, MatLab and Bash), but then you just stop thinking about it because it legit doesn't matter.

People should stop wasting time bikeshedding this insignificant detail, but for some reason it is to programmers like a red rag to a bull.

Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

#165
post #155
post #130

Earlier quoted context omitted.

I actually consider that a negative. Mathematical notation is fine when you're dealing with limited space on a blackboard, but if you're programming please name your name variables and take the time to model your domain explicitly.

I don't understand - what is wrong with condensing the python representation `sum_of_lambda_for_each_psi` to `Σλ∀φ`? It seems that 4 symbols is much quicker and easier to read than a slew of snake case stuff.

For each phi?

Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

#166
post #16

Earlier quoted context omitted.

This is one of the nicer aspects of Julia. It starts out being a great language to work in. Its easy to implement algorithms that are generally difficult in other languages. Its important to remember that most of the python ecosystem, isn't written in python. The functions are often thin wrappers/objects around the real computation, which is often written in a faster language, C/C++/Fortran. Julia excels in composabi…

Let’s not ignore the giant elephant in the room: 1-based indexing. I don’t particularly care since I use R and Python but Java, C, C/C++, C# all used 0-based indexing. It’s truly a bizarre choice Julia made there.

You mean, the little ant on the floor?

I barfed at 1-based indexing for about a week, but now it is as natural as anything.

I would compare 0-based and 1-based indexing with whether you put semicolons at the end of each line or not. Either way doesn't really change the feel (semantics) of the language.

Also, fortan is 1-based, iirc, and a lot of numerical code is in fortan.

Oh, and many many beginning programmers and scientists have a hard time with 0-based indexing. Not sure why, but such you hear, so the choice is really not that odd.

Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

#167
post #126

Earlier quoted context omitted.

For numeric code, comparing to pure python makes no sense, since people use numpy+numba to do that. Is julia much much faster than numba? I don't think so :)

Probably not faster in an absolute sense but things like loops in Julia can be properly optimized and will sometimes be more readable than structuring your program entirely around NumPy constructs.

For numpy, it's correct. But numba can optimize the loop. So optimized and readable loop is not an advantage of julia compare to numba.

Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

#168
post #25

Earlier quoted context omitted.

Because people in that game value simplicity of use over anything else (performance, safety, maintenance) and Python is a top performer in that KPI while Java is not very good at this (though it is getting better but still)

This is a big part of it. People who are scientists write code that we would think is disgusting and don’t care that much about abstraction outside of mathematical functions. There’s a lot to learn with Java. I helped classmates in my intro to programming class when I went to college, because I already knew how to code, and I have no idea why they picked that language as an introduction language. After weeks people w…

> Python was written with people like scientists in mind.

Having just taught a bunch of scientists Python, I'm skeptical of this.

Stuff that is obvious to me, but really hard to explain to coding beginners:

* why `len(list)` but `str.join(...)`? I.e. why are there two ways to call functions?

* why does `[]` do so many different things? List comprehensions, list construction, subsetting, sometimes it secretly calls a method....

* why in the name of god is the first row called 0?

* and then why does [0:3] mean rows 1, 2 and 3, not rows 0, 1, 2, 3 or 1, 2, 3, 4?

* ... except in pandas where sometimes [foo:bar] includes bar...

* in general, why is pandas so damn complex?

I thought it'd be easier to teach than R, but I'm not quite so certain now.

Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

#169
post #36

Earlier quoted context omitted.

Also no (official) REPL.

The Julia crowd really need to hang less value on the REPL - people writing serious production code don't use one, and scientists using Python have moved on to notebooks. At this point, having Julia be so focused on the REPL is a weird affectation.

I'm a scientist, I use REPL a ton. Notebooks are fine too, but there's a thing called exploration and nothing beats REPL speed for that.

In future it would be great to mashup something like repl.it with Jupyter notebooks, maybe with Medium-style wysiwyg. That might really win.

Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

#170

Earlier quoted context omitted.

Let’s not ignore the giant elephant in the room: 1-based indexing. I don’t particularly care since I use R and Python but Java, C, C/C++, C# all used 0-based indexing. It’s truly a bizarre choice Julia made there.

You mean, the little ant on the floor? I barfed at 1-based indexing for about a week, but now it is as natural as anything. I would compare 0-based and 1-based indexing with whether you put semicolons at the end of each line or not. Either way doesn't really change the feel (semantics) of the language. Also, fortan is 1-based, iirc, and a lot of numerical code is in fortan. Oh, and many many beginning programmers and…

The reason beginners have a hard time with 0 based indexing is that humans count from 1. Seriously, I've spent weeks trying to tell people "yeah, we want rows 4 and 5, so that's, uh, rows 3 and 4..." and they think it's nuts, and I now think they're right.
Post reply on HN