I've been using it for years and was surprised to see a new version after a dacade.
After installing it, I was surprised to see that the immediate changes most noticeable to me were that the input box was unnecessarily doubled in size, enclosed in an unnecessary border, and surrounded by unnecessary dead space; and that there's now marked input lag that never existed in the original version.
I never had a single problem with 0.12 over the past ten years, and use it nearly every day -- no bugs, no missing features.
I appreciate the desire to improve and innovate, but you know, sometimes, software really is finished.
That's never the case for any consumer app, the potential for improvement in UI is practically infinite. But also, just use the old version if it's finished, you don't need to upgrade?
(this app has plenty of bugs / missing issues just like everything else, for example, blurry text on some platforms)
> That's never the case for any consumer app, the potential for improvement in UI is practically infinite.
If that's true, how do you explain the observable pattern of many consumer applications degrading in UI functionality and coherence after a certain point?
> But also, just use the old version if it's finished, you don't need to upgrade?
> If that's true, how do you explain the observable pattern of many consumer applications degrading in UI functionality and coherence after a certain point?
Most consumer software in developed under the assumption that features only have a cost when being built. Their maintenance cost, and the combinatorial complexity each new feature adds, is barely considered. As a result, software teams add complexity at a speed that exceeds the rate at which the team's size, and the volume of work it can handle, grows. Eventually this reaches a critical threshold and the quality of the software starts to decline. But this doesn't mean the software couldn't still be improved, just that there isn't the resource available to do so.
> Most consumer software in developed under the assumption that features only have a cost when being built. Their maintenance cost, and the combinatorial complexity each new feature adds, is barely considered.
I suppose that's true, but I don't see what it has to do with UI design from a usability standpoint.
> But this doesn't mean the software couldn't still be improved, just that there isn't the resource available to do so.
It's a push and pull from both sides, isn't it? The accretion of process complexity among the developers may increase over time, but so too does the completion of core features and solution of all of the low-hanging-fruit development tasks.
Pretty much every GUI application I've ever used seems to hit a point where the original purpose for which the software was devised is satisfied for essentially all common use cases, but the incentives of the dev team are to keep going, so they move more and more toward gimmicky features, unnecessary bells and whistles, visual changes to the UI, etc. because any real functional improvement is a big investment, but they still need to justify a new release.
UI churn is one of the most common failure modalities here: when you've already picked all of the low hanging fruit in functionality and performance, major UI changes can create the appearance of improvement and innovation without actually having to do any of the hard work to achieve real improvement.
So when I see unnecessary UI changes to an application that still basically does the same things in the same way, at this point I'm conditioned to assume that that application has hit the point of diminishing returns for actual functionality, and the development incentives are now going to be driving more and more churn. And that's when I consider the software "finished".
> If that's true, how do you explain the observable pattern of many consumer applications degrading in UI functionality and coherence after a certain point?
Well, that's easy: Bad choices. The better something is, the easier it is to change it in a way, that makes it worse.
I agree with GP, everything can be improved, but that doesn't mean that you will succeed, or that you should try, for various, separate reasons.
The point at which new changes are more likely to degrade an application that's already excellent for its established use cases than they are to improve it further is the point at which we should consider the software "finished".
There may be lots of theoretically plausible improvements that could be made, but if the constraints of actual practice make pursuing those ideas a net detriment, that's probably a good place to stop.
I think AI may actually make this simultaneously better and worse: it will eventually be really easy to hit all of the functional and performance targets early on, so "finished" software will at some point be much better and closer to true completion, but the mentality that drives people to keep fiddling with it instead of moving on to a new project will be just as prevalent, and the post-"finished" releases will likely be even worse.
I use qalculate too, although it's plotting UI/UX leave a lot to be desired, because as far as I understand it, it calls gnuplot, which opens a new window each time. UI is nice when using breeze on plasma, but it has a crude look on darwin
The greatest qalculate feature is it's integration with krunner on kde, which gives you access to a very powerful calculator / unit¤cy converter with Alt+Space (by default), but it often doesn't trigger when you want to convert e.g. currency, so you need to force it by adding a prefix = to a query, like
speedcrunch is wonderful but I had this pet peeve with it where it had a hardcoded limit of 5 digits before it drops to scientific notation. Not very useful for shell scripts and programming.
I opened an issue while it was on bitbucket, but the response was something "yeah, that's intentional".
This is nice to see, and it looks like this release (and maybe some earlier ones?) includes a small order of operations bug fix that hadn't been released for a long time. 1/2(-9.8) now equals -4.9 rather than -0.05102040816326530612. I like how the expression also renders with a multiplication symbol to clarify: 1 / 2 × (−9.8)
Especially for a deterministic tool like this. Do what I say, not what I mean. I want no helpful cleverness that resulted in this bug in the first place.
I used to be a speedcrunch user and it was my introduction to "good calculator apps"
However after surveying the options a while back I switched to numbat.
The main advantage is that it's easy to define your own units on the fly.
A huge amount of simple calculation errors can be avoided by just using units.
Legit answer, to be sure! But if already on macOS, how does it compare? “Better and cross platform!” is the best possibility. “Nearly as good, but free!” is also solid. “Eh, it’s fine if you don’t have access to Soulver”, wouldn’t be a ringing endorsement.
Huge fan of SpeedCrunch!! Was sad to see the formula was somewhat recently disabled on brew: https://formulae.brew.sh/cask/speedcrunch ... anyone know if this means it could be re-enabled?
I recently opened a github issue about the system UI looking dark. I got a response an hour later which appears to be AI written, I responded to it and it looks like my request has been accepted.
I absolutely do not mind it being AI driven. I have not seen this before in this. The response was not slop, just very formal and verbose.
I use speed crunch almost every day mostly to see bits and bit shift operations visually. It's just strange to see requesting feature, getting an automated further inquiry, and then a response that yeah that sounds good to do.
I also recently made a fairly complete scientific calculator. I first asked Claude what functions it would put in it, then I made some modifications (added complex numbers), and told it to write the calculator. It looked perfect in one shot. This is really how simple this kind of thing has become.
Scientific calculators are surprisingly hard to get right. SpeedCrunch itself just fixed some calculation errors (usually its order of operations based, but not always). I’d be interested to see how accurate yours is, though I also wonder if there are lower level libraries to leverage to make it a moot point
After installing it, I was surprised to see that the immediate changes most noticeable to me were that the input box was unnecessarily doubled in size, enclosed in an unnecessary border, and surrounded by unnecessary dead space; and that there's now marked input lag that never existed in the original version.
I never had a single problem with 0.12 over the past ten years, and use it nearly every day -- no bugs, no missing features.
I appreciate the desire to improve and innovate, but you know, sometimes, software really is finished.
That's never the case for any consumer app, the potential for improvement in UI is practically infinite. But also, just use the old version if it's finished, you don't need to upgrade?
(this app has plenty of bugs / missing issues just like everything else, for example, blurry text on some platforms)
If that's true, how do you explain the observable pattern of many consumer applications degrading in UI functionality and coherence after a certain point?
> But also, just use the old version if it's finished, you don't need to upgrade?
Exactly. I reverted to 0.12.
Most consumer software in developed under the assumption that features only have a cost when being built. Their maintenance cost, and the combinatorial complexity each new feature adds, is barely considered. As a result, software teams add complexity at a speed that exceeds the rate at which the team's size, and the volume of work it can handle, grows. Eventually this reaches a critical threshold and the quality of the software starts to decline. But this doesn't mean the software couldn't still be improved, just that there isn't the resource available to do so.
I suppose that's true, but I don't see what it has to do with UI design from a usability standpoint.
> But this doesn't mean the software couldn't still be improved, just that there isn't the resource available to do so.
It's a push and pull from both sides, isn't it? The accretion of process complexity among the developers may increase over time, but so too does the completion of core features and solution of all of the low-hanging-fruit development tasks.
Pretty much every GUI application I've ever used seems to hit a point where the original purpose for which the software was devised is satisfied for essentially all common use cases, but the incentives of the dev team are to keep going, so they move more and more toward gimmicky features, unnecessary bells and whistles, visual changes to the UI, etc. because any real functional improvement is a big investment, but they still need to justify a new release.
UI churn is one of the most common failure modalities here: when you've already picked all of the low hanging fruit in functionality and performance, major UI changes can create the appearance of improvement and innovation without actually having to do any of the hard work to achieve real improvement.
So when I see unnecessary UI changes to an application that still basically does the same things in the same way, at this point I'm conditioned to assume that that application has hit the point of diminishing returns for actual functionality, and the development incentives are now going to be driving more and more churn. And that's when I consider the software "finished".
Well, that's easy: Bad choices. The better something is, the easier it is to change it in a way, that makes it worse.
I agree with GP, everything can be improved, but that doesn't mean that you will succeed, or that you should try, for various, separate reasons.
The point at which new changes are more likely to degrade an application that's already excellent for its established use cases than they are to improve it further is the point at which we should consider the software "finished".
There may be lots of theoretically plausible improvements that could be made, but if the constraints of actual practice make pursuing those ideas a net detriment, that's probably a good place to stop.
I think AI may actually make this simultaneously better and worse: it will eventually be really easy to hit all of the functional and performance targets early on, so "finished" software will at some point be much better and closer to true completion, but the mentality that drives people to keep fiddling with it instead of moving on to a new project will be just as prevalent, and the post-"finished" releases will likely be even worse.
Sadly they think they are making it better. Most of the time chasing fads.
Sometimes introducing dark patterns, for reasons.
I mean, Apple (and MS) had been dumbing down their OS in the name of usability and security for a while now.
The greatest qalculate feature is it's integration with krunner on kde, which gives you access to a very powerful calculator / unit¤cy converter with Alt+Space (by default), but it often doesn't trigger when you want to convert e.g. currency, so you need to force it by adding a prefix = to a query, like
Never used speedcrunch thoughI used to use it quite a bit, but I now gravitate towards numbat instead [1].
[0]: https://www.speedcrunch.org/download.html
[1]: https://github.com/sharkdp/numbat
I opened an issue while it was on bitbucket, but the response was something "yeah, that's intentional".
I see they bumped it to 14 digits now.
for years I've had a custom build of it with
src/math/hmath.cpp:
- if (expd > 5) + if (expd > 25)
blessed be the open source!
That should really be an error.
-4.9 is unequivocally correct.
A huge amount of simple calculation errors can be avoided by just using units.
SpeedCrunch - https://news.ycombinator.com/item?id=29661485 - Dec 2021 (131 comments)
Speedcrunch (calculator) - https://news.ycombinator.com/item?id=460520 - Feb 2009 (2 comments)
https://antovsky.itch.io/naut
A calculator without source available? In this day and age?? Did I miss something? I searched, but no sign of a repo.
Looked cool, but not that cool.
I've been using it for years after struggling missing the windows 2000 calculator.
I absolutely do not mind it being AI driven. I have not seen this before in this. The response was not slop, just very formal and verbose.
I use speed crunch almost every day mostly to see bits and bit shift operations visually. It's just strange to see requesting feature, getting an automated further inquiry, and then a response that yeah that sounds good to do.
Why do you think it was AI driven? It was more than likely human driven, but largely written by an AI to save time.