More strongly, if the pattern matching of a phenomenon totally / perfectly models the phenomenon, and you end up with a perfect model of the phenomenon, that enables you do do causal prediction, how can you NOT call it understanding? What more is there?
Don't know about your landlord specifically, and I'm no landlord, but there's also a bunch of people (including homeowners) that will wait until summer starts to test and then complain about HVAC... just on peak season for HVAC maintenance, where the waiting times are long (and the price will probably be higher).
Then use them! Then those projects will cease having a single contributor or being unmaintained. This doesn't need to be a binary decision (either there is no risk or I won't use it), just choose the project / scope with knowledge that there is some risk in a small community; so internal use rather than client facing, specialized uses, etc.
not sure how using a project adds a contributor. but for the latter - I'm not sufficiently competent at Prolog and friends to meaningfully contribute. I do donate money, though, to projects I regularly use - like for example FreeTube or Linux Mint.
APL was designed to be written on a chalkboard (if I remember the story right). It is quite dense, and programs are quite small. Reading is slow and requires you to ponder about what was written. You can hold a lot of content in a small amount of 'ink'.
Now, an idea: HN is always complaining that an ipad (or any other tablet) is a consumption device, as it is not designed to be used with keyboard/mouse. Do any of you know if there is an app where you can write APL with a stylus, and has the ability to evaluate expression on the fly, similar to a repl? That would be an awesome thing to do.
J is unclear on the concept, it's a hack to port APL to ASCII. I'm typing on a ZMK keyboard now where an APL unicode layer would be trivial. There are modern APLs. One can code a iOS keyboard with AI help.
While a native APL would be nice, the cloud solution would be robust access to a professional product. Build the chain via existing tools to bridge the iPad to APL running on a desktop machine.
I looked into this recently; but I've decided on Lean 4 as the successor "best language in existence" for my needs.
Hopefully this becomes a reversal in the trend of giving less and less context to the user.
I'm not against the considerations of the article regarding the user and its state of mind, but please do add as much technical detail as possible!
Even if an error message is a cryptic error code, that's better than a "Something went wrong" message. This is not better, or even friendlier, UX. An error code can be referenced, can be searched on the internet, can be passed around on a ticket or on a call... add parameters to your error template, reference the name of the file, the item name that does not respond, the HTTP error code... just give the user some transparency, some agency. Help the client build up a mental model of the error: when / how / why might it be happening.
I'm somewhat fond of including a UUID for that reason. As long as they can copy-paste it into Google, they can get results that are precisely the errors from your application, unlike "error 55324". The same works internally: zero ambiguity which system it came from, and it's trivial to find the full history of the error (message). It's not great for verbally communicating tho.
But yes, I can get behind making things nicer to read and less technically scary, but include enough detail so that people can solve their own problems if needed. There's a decent chance that the software will outlive your desire to support it.
IBM have been doing this for centuries, each error comes with a code you can look up for more information. Although this is probably way too late, all nix/nux utilities should come with either a magic ID string you can copy into Google to find all the other people baffled by the same error message ("Quadrant change in relocatable expression", that's an actual error message), or just an option to launch a browser with said info, because the message itself ain't giving you anything to go on.
If it's something I can fix as the user, I need good clear information.
If it's not something I can fix as the user, weigh the options: do I even need to know there's an error? Can you just cache the operation and try again later? Maybe an indication that it's happening in the background?
Current favorite peeve: Uber Driver app for deliveries complains "couldn't upload the photo" of the drop off. It's because this customer lives somewhere off the signal map. I can't do anything about it until I drive a mile back in the other direction. So, instead of blocking further operation, just hold that pic until we get back to civilization, ok? I need the map to get to the next pick up or dropoff, and this nonsense is in the way.
Anything is better than "something went wrong". It is quite possibly the stupidest error message every created, we know something went wrong because whatever we tried to do errored out. The best description I've seen of it was in a book draft:
When web UI developers die they go to what appears to be waiting area before
the gates of paradise. However no matter what they do to get in, anything
they try just pops up a message saying "Something went wrong". No other
information, just "Something went wrong" over and over again. Then they
wonder why there are flames and screaming all around them...
I'd say Java, because it has a massive footprint amenable for training, and a strong type system (does not have sum types though and those are trendy).
You'd have to steer the LLM to use the style you want, and not massively overarchitect things though, but that's going to be an issue nonetheless.
> It's already demeaning to expect them to "learn an accent"
The concept of an accent is broad, but at least part of it you need to learn together with the language, as speaking a non-native language with a thick accent is partly based on the fact that you have yet to learn.
Without being exhaustive, things that might fall into the "speaks with an accent" concept in this thread:
- Prosody. Prosody can vary per region but a distinctly alien prosody to a language is a barrier for the receptor of the message, that expects a given language and a range of prosodies. E.g. as I know french quite well, hearing english with a heavy french accent makes my brain try to understand what's being said as said in french, and interferes a lot.
- Sound shifts for particular phonemes. While some of it might be local to the language in certain registers (idea --> /ide"er"/, three --> /free/), others are clearly issues in the target language pronunciation (eg. japanese people having trouble with the l phoneme, spanish people adding an /e/ sound prior to an s-mobile, or v versus b for spanish people also).
- Connected speech. Where do you end words, how do you omit sounds, etc. Also massive hindrance to understanding.
- Grammar. Alien grammar is a hindrance to communication. You need to learn that.
reply