ferd

M PLUS Code https://mplusfonts.github.io/

The most underrated font ever.

here... sysop of Sudaka's BBS :-)

Is inner-ear cell regeneration included in #06?

Shameless plug: a code walkthru modeling the rules of chess, ment as an exercise/teaching functional programming (in Clojure):

https://neuroning.com/boardgames-exercise/notebooks/walkthro...

The implementation makes it really easy to add new piece types or rules. For example, here's the full logic for rooks (sans castling):

  (defn expand-pmove-for-rook [pmove]
    (->> pmove
      (expand-pmove-dirs [↑ ↓ ← →])
      (pmoves-discard #(or (pmove-on-same-player-piece? %)
                           (pmove-changed-direction? %)))
      (map pmoves-finish-capturing-opponent-piece)
      (pmoves-finish-and-continue))))

Thanks. Tried, but doesn't look good :-(

I really like Monaspace Argon, but even the narrower option looks too wide on my terminal (kitty on macos)

yes! don't remember my number, Zone 4 for sure (Argentina).

Exchanging messages with people on the other side of the world felt like magic at the time (even though it took many hours/days for a msg to round-trip)

I also run "Sudaka's BBS" based on Maximus/2, with many interactive "apps" I'd developed using Maximus' proprietary C-like language. Great high-school times.

I can still hear my parents complaining about my monopolizing the phone line every night :-)

I've had tinnitus for about 12 years now. High-freqquencies hearing loss. I've been using hearing aids for about 4 years... They DO help me with both hearing (of course) and tinnitus.

For example, driving a car without the aids makes my tinnitus really bad (due to the background noise of the car/engine/wind/road). With aids it's a lot less of a problem.

One fear I have is if hearing aids cause even more hearing damage (after all, what they do it inject amplified sound into you ear... the exact same thing that most doctors tell you NOT to do to avoid hearing damage)... Experts tell me they don't, but without any reasonable explanation.

How so? Not sure what you mean.

If object A calls a method of object B (composition), then B cannot call back on B, and neither A nor B can override any behavior of the other (And this is the original core tenet of OO: being all about "message-passing").

Of course they can accept and pass other objects/functions are arguments, but that would be explicit and specific, without having to expose the whole state/impl to each other.

> I'd argue some amount of "co-recursion" is to be expected: after all the point of the child class is to reuse logic of the parent

That's the point: You can reuse code without paying that price of inheritance. You DON'T have to expect co-recursion or shared state just for "code-reuse".

And, I think, is the key point: Behavior inheritance is NOT a good technique for code-reuse... Type-inheritance, however, IS good for abstraction, for defining boundaries, to enable polymorphism.

> I'd say this is a fact of life for all pieces of code which are reused more than once

But you want to minimize that complexity. If you call a pure function, you know it only depends on its arguments... done. If you can a method on a mutable object, you have to read its implementation line-by-line, you have to navigate a web of possibly polymorphic calls which may even modify shared state.

> This is another reason why low coupling high cohesion is so important

exactly. Now, I would phrase it the other way around though: "... low coupling high cohesion is so important..." that's the reason why using inheritance of implementation for code-reuse is often a bad idea.

You are always dealing with state and control-flow in software design. The challenge is to minimize state at much as possible, make it immutable as much as possible and simplify you control-flow as much as possible. OO-style inheritance of implementation (with mutable state dispersed all over the place and pinball-style control-flow) goes against those goals.

Closer to the "ideal": declarative approaches, pure functions, data-oriented pipelines, logic programming.

I've seen it a lot on Django projects. Maybe I was just unlucky on the Python projects I've joined.

Good point. In Java and many other languages you can opt out instead... which might make a big difference. Is it more of a "cultural" thing?... again, many frameworks encourage it by design, and so do many courses/tutorials... so those devs would be happy to put "virtual" everywhere in C++

An important point not mentioned by the article is that of "co-recursion" with inheritance (of implementation).

That is: an instance of a subclass calls a method defined on a parent class, which in turn may call a method that's been overridden by the subclass (or even another sub-subclass in the hierarchy) and that one in turn may call another parent method, and so on. It can easily become a pinball of calls around the hierarchy.

Add to that the fact that "objects" have state, and each class in the hierarchy may add more state, and modify state declared on parents. Perfect combinatory explosion of state and control-flow complexity.

I've seen this scenario way too many times in projects, and worse thing is: many developers think it's fine... and are even proud of navigating such a mess. Heck, many popular "frameworks" encourage this.

Basically: every time you modify a class, you must review the inner implementation of all other classes in the hierarchy, and call paths to ensure your change is safe. That's a horrendous way to write software, against the most basic principles of modularity and low coupling.

No... the best way is to use the same color for all occurrences of the same identifier. So, on the last example, all instances of say "audio" should be of the same color, and those of "filename" of another color.

Original idea from here: https://medium.com/@evnbr/coding-in-color-3a6db2743a1e

One impl for Emacs: https://github.com/ankurdave/color-identifiers-mode

I still admire you Niki.

Nice. Great work. Bookmarked

Obsetico App (named after a friends' comment that "it's great for Obsessed people like my wife"

A mobile app to track tasks, events and any info about anything you care about: your car, home, tools, workshop, appliances, pets, lab equipment... anything really.

Lets you organize "resources" in a hierarchy (like "folders"). You can then define tasks, add pictures, geolocation, contacts, notes, events, etc to them. Recently added the feature to "share" resources with others.

Google Play: https://play.google.com/store/apps/details?id=com.code54.qui... App Store: https://apps.apple.com/us/app/obsetico/id6749025870

It's so generic that it's hard to describe :-) I need a better elevator pitch.

similar to https://eca.dev/ ?

Any hope to treat tinnitus? :-\

search for XPDL and BPMN

Looks very interesting.

Somewhat related: I've recently wrote a code-walkthrough (in Clojure) of modeling chess-like games.

https://neuroning.com/boardgames-exercise/

It's very basic and intended for teaching/learning functional programming, not a real library or engine like the OP.

Similar experience here... python/typescript during the day, Clojure at night ;-)

Shameless plug: just yesterday I published a step-by-step code walkthrough hoping to convey my "Clojure way" of modeling:

https://neuroning.com/boardgames-exercise/

I'd need to really learn Haskell to make sense of it all. Might be a good excuse :-)

cool, thanks!

In the age of AI, I went old-school inspired by Hanson & Sussman's book "Software Design for Flexibility")

Meant for beginners. I'd appreciate all feedback!

...package managers to (un)install software. RedHat Linux had RPM since 1998 at least

CVS certainly sucked by today's standards, and SVN was indeed a big improvement, and Git much more so.

All I wanted to stress is that the "lock-before-you-can-touch" approach was the norm in the enterprise world at the time. IMHO, this fact alone made SVN (even CVS) better than all the commercial products which I used at the time.

When some of the "enterprise" world started adopting SVN and commercial products started relaxing the locking mandate, the open-source world was already embarked on the decentralized model (git, darcs, arch, mercurial, etc).

Young devs won't believe it, but until the early 2000s, most companies used source control systems that forced you to LOCK any file on a centralized repo before you were allowed to modify it (MS's SourceSafe, ClearCase, Perforce)... This was often the case even if you just wanted to touch a file locally for some experimentation... insane.

So, at a customer site (while I was doing consulting for them), I couldn't stand it anymore (I had been using CVS myself since 1997). So I installed SVN to work on their project and showed it to the team. I was called an "irresponsible engineer"... "Modifying files without locking is a crazy! You don't do that on real engineering teams!"

The open-source world was at least 10 years ahead.