Live data from Hacker News

Julia as a CLI Calculator

krasjet.com

51–60 of 134 posts

Re: Julia as a CLI Calculator

#51
post #5

Earlier quoted context omitted.

Simply loading the REPL takes half a second for me. I use it all the time as a simple calculator.

This is simply not true. I have a 3 year old mac, and this is doing simple arithmetic (including starting and exiting Julia). 0.14 seconds user time. $ time ~/Desktop/Julia_Releases/Julia-1.4.app/Contents/Resources/julia/bin/julia -E "1+1" 2 ~/Desktop/Julia_Releases/Julia-1.4.app/Contents/Resources/julia/bin/julia -E 0.14s user 0.08s system 65% cpu 0.342 total In about 0.5 seconds, I can actually do something non-tri…

I load a few packages in my startup. `--startup=no` makes the difference between about 0.12s and 0.5s on the 1+1 example for me.

This doesn't really bother me, but maybe I should try PackageCompiler or adding `using OhMyREPL, Revise, Cthulhu, BenchmarkTools` to a userimg.jl for when I build from source.

Re: Julia as a CLI Calculator

#52

Since this is a calculator topic, I'd like request your input on which calculators you use. I use the Emacs calculator (M-x calc) and XCalc ( http://www.tordivel.no/xcalc/ ) as I like to use RPN calculators. The Windows 10 calculator is painful and slow. XCalc has a mini mode, where it will sit as a small, single line without distracting you too much. I like that feature very much. One thing with Emacs is that I forg…

I kid you not, I use Spotlight on macOS (cmd+space) as my simple calculator if I’m outside the terminal. If I’m inside the terminal I probably have an IPython instance open. For advanced stuff I use Mathematica as mentioned here: https://news.ycombinator.com/item?id=23428991

Re: Julia as a CLI Calculator

#53
post #36

I really wish there was a language based on Swift that would include most of the nice language, REPL and library characteristics of Julia (and perhaps few from Dart). That would get really close to a "perfect language" for me. Overall I like Julia - and use it as a CLI calculator as well - but there are several things that prevent it from being a good general purpose language: - OOP support is "meh". - str.parse(Int)…

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

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

Re: Julia as a CLI Calculator

#54
post #36

Earlier quoted context omitted.

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

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

Re: Julia as a CLI Calculator

#55

Since this is a calculator topic, I'd like request your input on which calculators you use. I use the Emacs calculator (M-x calc) and XCalc ( http://www.tordivel.no/xcalc/ ) as I like to use RPN calculators. The Windows 10 calculator is painful and slow. XCalc has a mini mode, where it will sit as a small, single line without distracting you too much. I like that feature very much. One thing with Emacs is that I forg…

I use a function "ev" that wraps bc. It's crude, but handy:

    $ ev() { echo "scale=3; $*" | bc -l; }
    
    $ ev 22/7
    3.142

Re: Julia as a CLI Calculator

#56

Earlier quoted context omitted.

> str.parse(Int).abs is more readable than abs(parse(Int, str)). Oof, beauty is in the eye of the beholder. I appreciate the regularity of abs(parse(Int, str)) rather than remember what to call as a function, and what must be called as a method of some object. Of course my preference would be for a syntax that has the added benefit of getting rid of extraneous commas: (abs (parse int str)) > 1-based indexing Again, b…

> Oof, beauty is in the eye of the beholder. I guess that's true, from my experience Julia's way is simply less readable. It also make IDE autocomplete much more useful. > A lot of relevant math is 1-indexed. Initially I kind of liked it and disagreed with people who didn't. But as I used Julia over time, I regularly encountered situations in which it was really frustrating and enacted a mental tax. The opposite neve…

> But as I used Julia over time, I regularly encountered situations in which it was really frustrating and enacted a mental tax. The opposite never happens.

The opposite would be true for a large swath of people coming from scientific computing backgrounds if Julia defaulted to 0-based indexes. That said, in my experience people doing scientific computing have a poorly calibrated sense of what constitutes “hard.” I’m sure plenty of breakthroughs born of brilliant and horrifying code were created over sleepless weekends by grad students who didn’t understand that what they wanted to do was a mental tax.

I guess I don’t hear a lot of people doing scientific computing complain about indexing schemes. I prefer 1-based indexes, but 0-based indexes is a small and trivial issue in my list of grievances against, say, Python.

Re: Julia as a CLI Calculator

#57

I really wish there was a language based on Swift that would include most of the nice language, REPL and library characteristics of Julia (and perhaps few from Dart). That would get really close to a "perfect language" for me. Overall I like Julia - and use it as a CLI calculator as well - but there are several things that prevent it from being a good general purpose language: - OOP support is "meh". - str.parse(Int)…

“OOP” is an anemic special case of the multiple dispatch that Julia provides. So if you don’t know any better you can program in that style using Julia. “str.parse(Int).abs is more readable” No, but it makes sense if you also think that OOP makes sense. You can index based on anything you want.

No it's not. OOP is regularly used for new projects by experienced programmers. Julia doesn't have interfaces for example.

I know that I can set indexing to be 0-based. Not a good solution.

Re: Julia as a CLI Calculator

#58

Earlier quoted context omitted.

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

Re: Julia as a CLI Calculator

#59
post #37
post #33

Earlier quoted context omitted.

> - OOP support is "meh". And boy, am I ever glad it is.

Having built several OO codebases with 1000+ classes I really really really second this view.

OOP has become an antipattern (ok, partially kidding but...)

Re: Julia as a CLI Calculator

#60

I really wish there was a language based on Swift that would include most of the nice language, REPL and library characteristics of Julia (and perhaps few from Dart). That would get really close to a "perfect language" for me. Overall I like Julia - and use it as a CLI calculator as well - but there are several things that prevent it from being a good general purpose language: - OOP support is "meh". - str.parse(Int)…

> OOP support is "meh".

Interesting. I love Julia specifically because it doesn’t use an OOP approach. At least for the kind of work I do, I have found multiple dispatch to be far more powerful and cleaner to reason about than dispatching on the type of an implicit first argument.

Post reply on HN