Bost

"We don't want that s*it here" reminds of being behind the Iron Curtain for ~40 years. And than the dam broke...

Sorry but that's not true. I play with ChatGPT only for about a week or two and I have seen such a response a couple of times. However it's not easy to get such an answer. I'm not denying that.

(Unfortunately I can't provide you an example. The ChatGPT history is not available right now. Wed Mar 8 02:02:14 PM CET 2023)

Underrated! (Thank you.)

That color coding is nice. Not just as a reference to the parts of the math formula, but also within the sentence itself.

That's not an IDE agnostic approach. IIRC after modifying and reevaluating the function inside which the debugger is currently in, the debug session is terminated and the evaluation context i.e. the values of input parameters are lost. Even if the session can be restored I'm not sure if it survives a REPL restart. And even if it does I'm not sure if it survives a reboot, unlike my approach.

Moreover, this approach with defs allows you to inspect every function, even those macro generated. And if committed, such a "debug session" is persistent across every instance where the code is deployed, from any development machine, through all test and staging machines right into production. (So when combined with some remote REPL access... you see what I mean?)

Another thing is that I like when my code strongly express the notion of compositionality, i.e. when it looks something like this:

  (comp
     ...
     (partial map ...)
     foo3
     (partial reduce ...)
     (fn [p] (def s3 p) p)
     (partial map ...)
     (fn [p] (def s2 p) p)
     (partial apply ...)
     (partial map ...)
     foo2
     (fn [p] (def s1 p) p)
     foo1
     (partial apply ...)
     (partial map ...))

here I introduce and comment in/out the '(fn [p] ...)' expressions as needed. That kills two birds with one stone. 's1' captures the output of 'foo1' which is also the input of 'foo2' at the same time.

Even such a filter is too often useless. Like, 4 out of 5 times. I rely more on logging and parameter inspection. E.g.:

  (defn foo [a b]
    (def a a)
    (def b b)
    (/ a b))

If the function fails, I have captured its input parameters right before the exception occurred and now I can inspect it from the REPL if 'b' is 0. From the REPL I can change the value of 'b' with simple `(def b 42)` or change the very definition of 'foo' and re-evaluate it again on the REPL with simple `(foo a b)`.

I even made myself an elisp function for inserting the '(def a a)' into the code https://github.com/Bost/corona_cases/blob/master/.dir-locals... (enjoy).

I'm sorry but this as an argument is weak. Yes, it is true, the stacktraces are terrible, bordering on useless noise, but that doesn't mean that "exceptions & stacktraces" is the only possible approach when it comes to error handling.

FYI you're writing this post on a device which is a product of millions of ideas and inventions all of them refined, abstracted and parametrized thousands of times, if not even more.

> But nobody wants to go into COBOL for fairly obvious reasons.

On YouTube, type in "COBOL Mainframe", and you'll find out pretty quickly that there's a plenty of guys from India, including juniors who work with or on COBOL and Mainframes.

Bash as a language is a downright bad. Especially the mess around `,",'. Fish is better is in this regard, however the syntax of Fish's string-related functions is unbearable. (I have a growing suspicion, with string-related functions, syntactically valid expressions can be constructed, which don't compile!)

However, neither Bash nor Fish were created with Composability in mind, which is a show-stopper for me.

IMO don't use Bash if the script is longer than 20 lines and don't use Fish if it's longer than 50. Use Python. If you want to use a proper(!) language use any LISP-Dialect like Babashka, Guile Scheme, Racket, etc. If you need Types have a look at Haskell-Scripting.

EDIT: To clarify, use Fish for its bling-bling capabilities, don't use it for scripting and configuring your machine(s).

> "teammates" were fired for having "a second full-time job while maintaining their full-time role at EFX,"

Except that having a second FULL-TIME job does affect the first one.

That means, on modern Laptops, the firmware is "sitting inside" proprietary hardware, so that it is irrelevant if this firmware is proprietary or not.

If this is conclusion of mine is correct(?), that means: even less motivation for modern Ubuntu versions to include proprietary blobs.

Be aware that "Ubuntu" doesn't mean "Free software"!

9 years ago I bought a new Dell XPS 13 with Ubuntu. Everything has been fine until one month ago when I decided to natively install Guix OS.

The wireless card "Intel Centrino Advanced-N 6235 (2x2 b/g/+ Bluetooth Combo Card)" has non-free, proprietary firmware. So no native(!) Guix on my Dell XPS. (Only hosted)

Almost. Behind "WE/US" is the society which builds and runs sports facilities (operating quite often at loss) implements sport education programmes for children and youth etc. So, no it is us being represented by the few talented ones.

In Russia, losses up to 4% are fine.

<whatever-done-correctly> is better than <wrong>

> same user validation in 2 places, changing it in 1 place may lead to issues, which are difficult to discover.

Disagree. Quicker discovering issues difficult to discover is actually a good thing.

> Its more difficult to build context of the implementation, if one needs to jump from file to file.

Agree.

In general, I personally look at DRY as "It takes time to implement and/or understand it, but when it's done then it works and it will last." "It takes time" is something your boss won't like, but that's (mostly) not an issue if working on open source SW. No boss -> no pressure -> higher quality.

Must be written in COBOL otherwise it's not realistic :)

> Every time you reach for the mouse and move the cursor or scroll a document you stop thinking at the problem at hand because [...]

... because I have well over 200 of own keybindings in my spacemacs dotfile already and quite a few of them don't do what I need in some particular situation or some underlying package got broken or, or, or...

> you're focusing on the motion, and when you're done with the mouse you waste mental energy resuming your previous train of thought, maybe even forgetting something.

That's because it's already half past 3 p.m and except having two or three coffees, I haven't eaten anything yet.

Besides, I highly doubt if I don't get any Nobel- or Turing-Award it's because I don't keep my fingers on the home row.

It must be hard math, soft science and such. Definitely!

I think the Mars Colonists will really benefit from learning this craft. Or maybe even the ISS astronauts... you know just in case, your trip home gets postponed.

Trained people are fine, but most people are not trained and not very easy to control in unfamiliar surroundings.

And now tell me please which doctor or test IS 100% reliable?

> There's no test that can only be performed via canine.

Because we haven't developed any.

> The sheer amount of untrained dogs is just way too high to use a trained dog as an argument.

The sheer amount of stupid people is just way too high to use a smart person as an argument.

> Any weird tips for weight loss?

Get yourself a bicycle, take two weeks holiday and ride from A to B where A and B need to be >2000km apart. You can eat as much as you want and you will loose weight.

However people may change...

> you don't realize just how stressful interviews are to some people

Getting stressed too much about a job interview may be a sign of overcommitment. And I believe you're not looking for a guy ready to go over corpses.

> storage is cheap

Sometimes. Sometimes not.

The physical HW, i.e. RAM and HDD storage is cheap but price you pay for accidental complexity is high. E.g. when your non-tail-call recursive calculation eats away all available memory. And you need to persistently store the intermediary results - just a handful of long integers in a dbase. And that dbase must be set up and maintained. That means dealing with access rights, usernames, passwords, replication, backups etc. In every environment: prod, tests, on every development branch (separately!), etc.

In another dimension, read / write operations mean yet more side effects to deal with. And on top of that, dealing with intermediary results means yet more accidental complexity in the source code.

So no, the workaround for "the memory limitation problem" can be in fact the most expensive part of a project. And now imagine, the data grows day by day...

Constant probability function. (Please be precise!)