innocentoldguy

Yes. They work fine in Chrome. Mellel is the only app I can think of where they don’t work.

Vitamin D is a lifesaver for me. I'm severely deficient, and if I don't take about 10,000 IU a day, I seem to get colds every five minutes.

Yes. Basic emacs keybindings work pretty much everywhere in macOS. I have run into a couple of apps that don’t behave correctly, but 99% of the time they work.

I was going to trade in an old truck and buy my daughter a Tiguan this weekend. I guess I’ll rethink that.

Self-help non-fiction books killed themselves by focusing on entertainment, in the form of amusing anecdotes, rather than substance. Most self-help books could be reduced to a 3-by-5 card without losing any of the core information.

I use Karabiner-Elements on macOS, and finding keyd was a godsend on Linux. I cannot deal with standard keyboard mappings and the lack of hold/tap keys.

I made a modal editor, like Vim and Helix, in Rust that has some prose features I wanted, and with a keybinding system I find more logical and consistent.

I've found that if I apply for any company that uses Workday, it's an immediate rejection, so I don't bother with them anymore.

Neither do I.

LLMs seem to have an easy time with Elixir and Phoenix in my testing.

I find Elixir's memory and threading models much more compelling than Go's for web services. There are many great libraries for Elixir as well, but if you need something else, Elixir makes rolling your own libraries very easy. I'd recommend giving Elixir a try, if you haven't already.

I just found my BeOS 5 and BeProductive CDs from the late 90s. I wish I had something to run them on.

Philips is the company that came up with the term "Compact Disc" for CDs, so we can blame them for goofing up the regional spellings and making the world more confusing.

I think Alan Shugart (or at least his team at IBM) started calling portable data disks "floppy disks," and then "hard disk" emerged to differentiate rigid disks from bendy ones. Maybe we can also blame him and his team.

The important thing is that someone gets blamed. :D

I have been around for a similar amount of time. Another change I have seen over the years is the shift from programming being an exercise in creative excellence at work to being a white-collar ditch-digging job.

I'm currently using Niri+Noctalia just to try them out, but I typically use Gnome and like it quite a bit for its simple, clean interface.

I use macOS and Linux, and the way GNOME works makes switching between them easier for me than when I run KDE, for instance (I'm sure others have a different experience, and that's what is so great about Linux).

Django is perfectly capable. I'd use Phoenix for its scalability and performance, if it were me, but I've built large-scale projects in Django before, and it worked well.

I feel sorry for this woman. Meta did this to me because they're discriminatory dicks, so I know how she felt. Fortunately, I have a tremendous amount of family support.

I have the same question. I've been in the software industry since the early 90s and I've seen the "static types are the best thing since sex" fad fade in and out repeatedly during that time.

Having used plenty of strongly-typed and dynamically-typed languages, I really can't say strong typing has had any effect on me whatsoever. I honestly couldn't care less about it. I also can't remember ever having a type-related bug in my code. Perhaps I have an easier time remembering what my types are than others do. Who knows?

No worries, and I forgive you for the sardonic Japanese. I wish you the best.

Hi, ursAxZA. Yes, you're describing an "elision," which is where speakers drop or blur sounds together to make speech more fluid, like the way some people say, "Sup?" when they mean, "What's up?" or replace the T with a glottal stop in the word "mountain," as they do in Utah.

I wholeheartedly agree that it is fine to write things like "Sup?" when appropriate, such as dialogue in a novel. You see this all the time in Japanese TV, books, magazines, manga, etc. However, I disagree that elisions should dictate how we spell words in regular written communication, especially when discussing a tool meant to help non-native Japanese speakers learn the language. And as the parent poster pointed out, when singing, you would sing "se n se i" rather than "se n se e." The same is true of haiku and other instances where the morae (linguistic beats similar to syllables in English) are clearly enunciated.

As I said, sensei is technically four morae and different than "sensē," and, in my opinion, should remain that way in Romaji, it being a writing system and one method for inputting Japanese text.

Thanks for the respectful conversation. I appreciate the points you brought up.

You're welcome.

I'm sure at some point, Gleam will figure it all out.

We are talking about writing/spelling, aren't we?

Why would you want to confuse the hell out of those learning Japanese by spelling せんせい (sensei) using an E with a macron, a la "sensē," when that is not at all how you spell it or type in phonetically in an IME? Having a one-to-one romanization for each Hiragana phonetic is far more logical for learners, who are essentially the target of romanized Japanese, than creating a Hooked on Phonics version that is completely disconnected from writing reality.

I also think your comment, written in Japanese, saying, "This stupid nonsense isn't going to be of any use to anyone," is both ignorant and uncalled for.

In Japanese, an E column kana followed by I sometimes makes a long E, like in 先生 (sen + sei -> sensē).

While it is sometimes difficult to discern the combined E and I sound, especially for non-native speakers, the word 先生 (sensei) is technically pronounced "sensei" and should be spelled that way to distinguish it from words with long E sounds, such as ええ (ee) and お姉さん (oneesan). Similarly, the OU in 東京 (toukyou) and the OO in 大きな (ookina) are different and should be spelled differently. I hope this helps.

EDIT: Added a comma.

- No state machine behaviours. Gleam cannot do gen_statem.

- Limited OTP system messages. Gleam doesn't yet support all OTP system messages, so some OTP debugging messages are discarded by Gleam.

- Gleam doesn't have an equivalent of gen_event to handle event handlers.

- Gleam doesn't support DynamicSupervisor or the :simple_one_for_one for dynamically starting children at runtime.

I don’t mean to minimize the huge effort by the Gleam team; however, Elixir cannot become Gleam without breaking OTP/BEAM in the same ways Gleam does. As it stands now, Elixir is the superior language between the two, if using the full Erlang VM is your goal.

And, he delivers the line with such perfection.

I find Elixir and Erlang easier, but I'm still a neophyte with Rust, so I may feel differently in a year.

I'd love to hear more about this!

He deployed our applications using Kubernetes and refused to implement libcluster. There was something else, too, but I can't recall what it was. It was seven years ago.

Yeah, this is weird...

I kept telling this developer that you're supposed to test your private functions through your public interfaces, not expose your private functions and hope nobody uses them (which they did), but that fell on deaf ears. He was also a fan of defdeligate and used it EVERYWHERE. Working with that codebase was so annoying.

I worked for a company writing Elixir code several years ago. Prior to my arrival, the ignorant architect had deployed Elixir in a way that broke the BEAM (which he viewed as "old and deprecated"). Furthermore, one of the "staff" engineers—instead of using private functions as they're intended—created a pattern of SomePublicModule and SomePublicModule.Private, where he placed all the "private" functions in the SomePublicModule.Private module as public functions so that he could "test them."

I tried almost in vain to fix these two ridiculous decisions, but the company refused to let code fixes through the review process if they touched "well-established, stable code that has been thoroughly tested." After being there for a couple of years, the only thing I was able to fight through and fix was the BEAM issue, which ultimately cost me my job.

My point in all this is that, at least sometimes, it isn't good engineers writing silly code, but rather a combination of incompetent/ignorant engineers making stupid decisions, and company policies that prevent these terrible decisions from ever being fixed, so good engineers have no choice but to write bad code to compensate for the other bad code that was already cemented in place.

Wouldn't you just `cast` instead of `call` if you thought this was going to be an issue?