Hacker News Reader

Comment by sgt101 | Hacker News Reader

>OOP support is "meh".

it's not an OO language. It's got a fantastically rich and powerful type system, but the true beauty of it is the way that it allows you to compose functionality. This is having a staggering impact on the evolution of the ecosystem and the progress that Julia libraries are making in creating functionality that now rivals code bases that have been in dev for 10+ years in the Python landscape.

>- str.parse(Int).abs is more readable than abs(parse(Int, str))

I respect your opinion, but mine is different. Perhaps other people find it easier to read asb(parse(Int,str)) as I do?

>- 1-based indexing.

You can change it and choose.

>- Lack of good support for nullability, think of "if let", "guard let", "??", "object?.property".

I don't know anything about this one! Fascinating!

View on HN

> You can change it and choose.

I know, not sure if it this would make things better or worse overall.

> I respect your opinion, but mine is different. Perhaps other people find it easier to read asb(parse(Int,str)) as I do?

I like when the code reads like a sentece, it's just less mental overhead.

Maybe you'd like str |> x->parse(Int,x) |> abs ?

>I like when the code reads like a sentece, it's just less mental overhead.

But the OOP version is further from a real sentence here. You're taking the absolute value of the string parsed as an integer, not "for the string grabbing the parser to apply the change to an integer to take the absolute value".

I think they're both equally correct, though the UFCS/pipe syntax is mentally easier to follow.

Let's say someone told you (making up random stuff):

"The absolute value of the sum of the mean of the square of two vectors mapped over the product of X and Y."

Try to think about that in your head. By the time you've reached the end of the sentence, there have been so many steps and no context values that you can't even follow.

If you take the opposite though:

"Take the product of X and Y, map them over two vectors, square it, sum that, and then return the absolute value."

(Again, can't guarantee these are semantically equal to each other, but you get the idea)

Then you know "Okay, starting from these things, first I do this, then I do this.." whereas the opposite way, you're given a ton of directions with zero context, and then have to try to apply them all in reverse once you're finally given the starting value.

You don't give directions to someone starting from the destination and working backwards.

>"The absolute value of the sum of the mean of the square of two vectors mapped over the product of X and Y."

abs(sum(mean(abs2,x .* y)))?

(Using a different account because I got a "you're posting too fast" error.)

It's probably even less readable to be honest. And it would mean there are now 2 ways of doing something which makes the language irregular (unless everyone switches to this syntax).

I would just read it as: "Take str, convert it to an int and take the absolute value." It also corresponds to the order of steps as it actually happens.

Another example where the readability difference is clearer:

`images.first.resize(100, 100).crop(25, 25, 75, 75)`

versus

`crop(resize(first(images), 100, 100), 25, 25, 75, 75)`

The former one isn't just more readable, it's also easier to write.

Reply on news.ycombinator.com