Live data from Hacker News

Julia as a CLI Calculator

krasjet.com

61–70 of 134 posts

Re: Julia as a CLI Calculator

#61

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

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

Re: Julia as a CLI Calculator

#62
post #29

Earlier quoted context omitted.

By half a second I obviously didn't mean 0.5 seconds but rather a very short duration that I didn't bother to measure. Edit: Now I bothered to measure. You were saying? ~ time julia -E "1+1" 2 julia -E "1+1" 0,59s user 0,14s system 153% cpu 0,476 total ~ time julia -E "sum(sin.(rand(1000000)))" 459807.21199623536 julia -E "sum(sin.(rand(1000000)))" 1,01s user 0,17s system 125% cpu 0,948 total

Which version of Julia are you using? My main point was that while half a second (~0.5s) is perceptible startup time, ~0.1s is not. Is it a much older system than mine? I have a 2.3GHz Core i5 from about 2017.

I'm using 1.4 on an Intel i5 4460, so about 3 years older but not a laptop cpu.

I don't even think 0.5 seconds are that noticeable...

Re: Julia as a CLI Calculator

#63
post #51

Earlier quoted context omitted.

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.

The only think I'm loading at startup is OhMyREPL.

Re: Julia as a CLI Calculator

#64

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…

One good thing about the Emacs calculator is the sheer number of features available. I don't use many, but occasionally use the financial functions, and they are really great. Any suggestions on programs out there with financial functions?

See Andrew Hyatt's Emacs calculator for Financial calculation tutorial: http://web.archive.org/web/20171218022230/https://plus.googl...

(Link rot, Google Plus, web.archive.org!)

Re: Julia as a CLI Calculator

#65
post #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

Not to mention, Spotlight does a /bunch/ of unit conversions. You can even type things like `1km/h to kt` for example. There's quite a few units defined already that I'm usually pleasantly surprised. This also works on iOS.

The one downside is you can't do unit conversions of a mathematical expression, just of a number. (i.e., 2^2 m/s does not work but 4 m/s does).

Whenever I have to do something more complicated I usually use M-x calc or maxima with ezunits.

Re: Julia as a CLI Calculator

#66
post #25
post #11

Earlier quoted context omitted.

I remember years ago when caching was about to be integrated in the next version and be here in a few weeks. Now it has been half a decade of people complaining about how slow it is for his to keep recompiling the same thing over and over.

I've been using julia for about three years now and from my interactions with devs and the issues on github, caching more code has only been considered in the past year because before then, the priorities were in getting the language stable, to 1.0, and on other lower-hanging performance fruit. "Just cache more" turns out to be a harder problem than it seems at first sight, if by the very nature of the language loadi…

Yeah, Julia has had some form of precompilation/caching for ages now, but sorting out all invalidations appears to be highly nontrivial [1] and devs have had more fundamental priorities pre-1.0. There have been some substantial improvements to latency in the meanwhile nonetheless, and PackageCompiler.jl is a viable option as well.

[1] https://github.com/JuliaLang/www.julialang.org/pull/794

Re: Julia as a CLI Calculator

#67

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…

As someone coming from a physical science rather than CS background, I routinely find 0-based indexing to be "frustrating and a mental tax" compared to 1-based

Re: Julia as a CLI Calculator

#68
The typography in this post is beautiful (as well as the content), anybody know where this comes from? Did the author do it by hand or is it something off the shelf?

Asking for a friend...

Re: Julia as a CLI Calculator

#69

Earlier quoted context omitted.

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

Regardless of what is a subset of what, I certainly agree with the OP that OOP feels "anemic" in comparison to the dispatch-based paradigm of Julia.

I can't tell you how many times I've seen disparate packages written by different authors with no explicit effort towards interoperability "just work" together in Julia (e.g., [1]), something I have never seen to a comparable degree in any other language.

[1] https://www.youtube.com/watch?v=kc9HwsxE1OY

Post reply on HN