ferd (u/ferd) - Readit News

ferd commented on Ask HN: Remember Fidonet? · Posted by u/ukkare

ferd · 3 days ago

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 :-)

ferd commented on Ask HN: Hearing aid wearers, what's hot? · Posted by u/pugworthy

SkipperCat · 4 months ago

Has anyone had and experience using hearing aids to deal with tinnitus? I've got some small hearing loss in the high frequencies and I'm looking at getting fitted for hearing aids to help boost those frequencies. The hope is to train my brain to stop replacing the deficit of sound with the monotone tinnitus noise.

I've tried some OTC hearing aids (Sony & Sennheiser) but its been hit or miss. I'm going to try whatever the hearing aid tech at my ENT proscribes.

ferd · 4 months ago

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.

ferd commented on When did people favor composition over inheritance? sicpers.info/2025/11/when... · Posted by u/ingve

marcosdumay · 4 months ago

> You can reuse code without paying that price of inheritance.

The same pinball of method calls happens at almost exactly the same way with composition.

You save some idiosyncrasies around the meaning of the object pointer, and that's all.

ferd · 4 months ago

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.

ferd commented on When did people favor composition over inheritance? sicpers.info/2025/11/when... · Posted by u/ingve

OrderlyTiamat · 4 months ago

> It can easily become a pinball of calls around the hierarchy.

This is why hierarchies should have limited depth. 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 but to overwrite some logic.

But if the lineage goes too deep, it becomes hard to follow.

> 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.

I'd say this is a fact of life for all pieces of code which are reused more than once. This is another reason why low coupling high cohesion is so important: if the parent method does one thing and does it well, when it needs to be changed, it probably needs to be changed for all child classes. If not, then the question arises why they're all using that same piece of code, and if this refactor shouldn't include breaking that apart into separate methods.

This problem also becomes less pressing if the test pyramid is followed properly, because that parent method should be tested in the integration tests too.

ferd · 4 months ago

> 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.

ferd commented on When did people favor composition over inheritance? sicpers.info/2025/11/when... · Posted by u/ingve

wseqyrku · 4 months ago

> 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.

What if you are actually dealing with state and control-flow complexity. I'm curious what would be the "ideal" way to do this in your view. I am trying to implement a navigation system stripping interface design and all the application logic, even at this level it can get pretty complicated.

ferd · 4 months ago

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.

ferd commented on When did people favor composition over inheritance? sicpers.info/2025/11/when... · Posted by u/ingve

trallnag · 4 months ago

While in Python everything is overridable, does this show up in practice outside of (testing) frameworks? I feel like this is way more common in Java. My experience in Python is limited to small micro service like backends and data science apps.

ferd · 4 months ago

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

ferd commented on When did people favor composition over inheritance? sicpers.info/2025/11/when... · Posted by u/ingve

kccqzy · 4 months ago

This is only the case when the language does not distinguish between methods that can be overridden versus those that cannot. C++ gives you the keyword "virtual" to put in front of each member function that you want to opt into this behavior, and in my experience people tend to give it some thought on which should be virtual. So I rarely have this issue in C++. But in languages like Python where everything is overridable, the issue you mention is very real.

ferd · 4 months ago

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++

ferd commented on When did people favor composition over inheritance? sicpers.info/2025/11/when... · Posted by u/ingve

ferd · 4 months ago

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.

ferd commented on Getting syntax highlighting wrong tonsky.me/blog/syntax-hig... · Posted by u/robenkleene

ferd · 5 months ago

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.

ferd commented on Ask HN: What are you working on? (September 2025) · Posted by u/david927

claviska · 5 months ago

I launched Quiet UI this week:

https://quietui.org/

It prioritizes accessibility, longevity, performance, and simplicity.

With the autoloader, one script tag loads components dynamically without downloading the entire library. (npm also available.)

Theming uses color-mix() and OKLAB to create uniform color palettes from a single CSS property. Adaptive palettes are used for dark mode.

All form controls are form-associated via ElementInternals and work with native validation APIs (required, pattern, etc.).

Dialogs, popovers, tooltips, etc. use Popover API for top-layer access without having to portal or hoist.

Some of the more fun components include: Joystick, Stamp, Mesh Gradient, Flip Card, Random Content, Intersection Observer, Typewriter, Lorem Ipsum, Slide Activator

The library is free for personal, educational, non-profit use. Commercial use requires a license.

ferd · 5 months ago

Nice. Great work. Bookmarked