Principles are products of practice, not the reverse
alsado.caThe core thesis is "I believe principles should not stifle progress".
It turns out that people can have very different kind of principles in mind.
Some principles are primarily ethical, such as "Make our product work for people with disabilities, because it's the right thing to do".
Some principles are primarily legal, such as "Encrypt data at rest and in motion, because we don't want compliance problems".
Some principles are primarily practical, such as "Bias for action: if you're 80% sure, and you decision is easy to reverse, then proceed."
There are the deeper principles that are broadly applicable in many fields, generate new practices, and applicable in creative and versatile ways.
I interpreted this post completely differently. I think it is talking specifically about design principles for code/systems. The core thesis appears to be "principles should be based on what works in practice, not what sounds good in theory."
My ad hoc response would be that this is a question of maturity. In an unexplored area you have to experiment to find the principles that work. Once you have found them, you should use them, everyone rediscovering them on their own is probably a waste of time. On the other hand discovering something on your own can aid a deeper understanding, so maybe it is not too bad after all. And it provides an opportunity to reevaluate, maybe the environment has changed in such a way that the principles also have to change.
> On the other hand discovering something on your own can aid a deeper understanding, so maybe it is not too bad after all
That is the take we globally landed on I think.
For instance students will be asked to prove known theorems, solve classic problems, literally reinvent the wheel. And sometimes realize it's all wrong and there's better approaches or more accurate theories.
"Please derive in this 90-minute exam what took 100 years to comprehend"
I was going to write the same. Also, it implies (rightly) that changing high-impact theories should be left to experts who have fully explored the domain and the mechanisms.
There are times to disregard inconvenient aspects of theory:
Quick-and-dirty development: If you are building an passenger jet, yes stick to theory. But if you are hacking together a quick tool that won't be used past the end of the week and which will have little impact, then just get it done!
Early stage development: You're in an experimental stage anyway. Better to experiment more than to perfect the product. You can address theory later when your concept has matured.
For low-impact development, I think it's often better to encourage people to experiment, explore, and learn - to have agency - than to worry about theories. That's how people learn and engage best.
I think the author's examples/analogies are strange and don't really fit with or support the author's point:
> The Wright brothers achieved flight before fully understanding the physics behind the airfoil,
> James Dyson learned what makes a great double cyclone vacuum only after building them,
> The bicycle was invented without an understanding of the mechanisms which maintain its balance.
The principles in question are physical, immutable laws of nature, and they are in fact the cause of success, not the byproduct of success. You can be ignorant of physics, but you can't ignore it, otherwise you'll end up injured or dead.
On the other hand, the principles of HTML semantics were just an invention of Tim Berners-Lee, not God. There's nothing stopping you from ignoring those principles. This follows from the quoted tweet: "they are often disregarded by developers and tools when producing markup and styling".
Also, it's cherry-picking. They didn't know everything (the nature of cutting-edge R&D), but they knew plenty.
Well, if the phrase on the title is true for you, you are working with some really unprincipled principles.
They shouldn't. Principles are something that guides practice. Like the principles of aerodynamics guided the evolution of the airplane even if they weren't fully known at the time. (And this example on the article is just wrong.)
If you use the same word for something that is derived from practice (like best practices, on the HTML example), you will lack one for the really fundamental stuff.
I think it's more of a loop. Principles guide practice, but practice may cause you to discover that your principles were mistaken of limited. Eg, the discovery of quantum effects.
A more worked-through explanation of this can be found by reading up on "reflective equilibrium" https://en.m.wikipedia.org/wiki/Reflective_equilibrium
I'm not sure why you picked physics as an example which probably is the single field where the most principles were developed from mimicking practice and observation, aerodynamics included.
This whole post could be a distinction without a difference. Like others say, it's a loop. The same could be better expressed as do what's pragmatic. Have principles that are formed from experience and apply them judiciously. Then we don't have to argue definitions or which is more important, etc.
I started off, from Day One, heavily structuring and documenting my code.
These days, I don't even think about it, and my productivity is pretty much as good as you can get.
Plus, I am the one that usually has to go back into my code, and maintain it, so I'm glad of that habit.
"We are what we repeatedly do. Excellence, then, is not an act, but a habit."
- Mis-attributed to Aristotle.
> These days, I don't even think about it
When I read this, I assumed you meant "I don't even think about heavily structuring and documenting my code". And my intuition (after 14 yoe or so) is that this is correct. Heavy structure for a greenfield area is a premature optimization. And comments are only for expressing what can't be expressed using code or other tools. I'd say if you need _heavy_ comments you've chosen the wrong tool for the job.
Then again, maybe I'm just not smart enough to anticipate the right levels of abstraction on the first go.
He is saying he developed structuring and documenting as a habit and now it is second nature and doesn't cost extra effort. And since he is the one maintaining the code and coming back to it he is the primary beneficiary and is doing his future self a favor with the extra details.
That’s pretty much it.
Also, these days, I tend to design “iteratively,” so the structure and documentation help a lot.
That’s not something I could have done in my yute.
I talk about the way I do code documentation, here: https://littlegreenviper.com/miscellany/leaving-a-legacy/
It is a moral principle that websites should mostly use HTML. This is not because it's the easiest way to build websites and certainly not because it's the best way to make lots of money. It's because it ensures everyone can use the same web and gives the user agent as much power as possible to act on the user's behalf.
> It's because it ensures everyone can use the same web and gives the user agent as much power as possible to act on the user's behalf.
Those aren't the principles underlying HTML, and I doubt Tim Berners-Lee was thinking about that at all when he designed HTML. Instead, he was trying to design a format which could be read by both machines and humans, which is why "semantic" HTML elements were introduced. In the end, LLMs were what allowed machines to understand web pages, not semantic HTML elements.
If we do want to make this about accessibility, anyone who has worked with screen readers knows that semantic HTML has failed on that front too. Screen readers rarely understand fancy elements. Instead we often have to create obscene DOM structures to get the reader to say something reasonable, which is at complete odds with the ideals of the semantic web.
> If we do want to make this about accessibility, anyone who has worked with screen readers knows that semantic HTML has failed on that front too. Screen readers rarely understand fancy elements.
Isn't that a failure of screen readers, not of semantic HTML? That is, with semantic HTML in place, changes to screen readers themselves can fix the problem by extracting the information that is there; but, without semantic HTML in place, no effort on the part of the developers of screen readers could extract information that wasn't there. And, to put the emphasis differently, if screen readers won't change at all, then there is absolutely nothing that we can do with HTML—except, as you say, to abuse it to achieve what can at best be a fragile and unreliable effect—to fix the problem on that end.
It may, in some sense, be moot because developers of screen readers aren't interested in making those changes, but I think that placing the onus of responsibility there is a more accurate description.
"It's because it ensures everyone can use the same web"
But they cannot. A blind person just cannot make good use of a visual map feature, so there is no reason to make it in pure html for accesibility. You'll have to find other ways to serve them. (I assume mostly with text descriptions of the area)
Not according to my morals!
You gotta be careful with this one in the context that it is being applied here (HTML). This risks becoming an ableist mantra because the practice might be disregarding accessibility concerns.
The blog post would benefit greatly if it had some examples from the world of web dev. It's not very clear what kind of principles they are talking about.
The example given in the post was using <div>s rather than semantic HTML elements. The motivation for the principle of using "semantic HTML elements" comes from the lofty ideals of the Semantic Web[0]. However, these principles didn't come from best practice. Instead, someone (Tim Berners-Lee) thought that it was a cool idea and tried to convince everyone of it without demonstrating that it could actually deliver on any of the promises it made. The argument instead is that principles should be based on what is proven to work, rather than what sounds good in theory. I agree with the sentiment in the post.
Thanks, I really didn’t get what they meant with the example they were using.
Out of curiosity why is writing everything as a single element type more ergonomic? I’ve not done frontend web dev in a while and using <p> <h1> and so on seems like it would be more ergonomic to express intent.
The reason why it's so tempting to just use `<div>` everywhere is that `<div>` elements have very simple and predictable behaviour with regards to styling, composition and event handling.
Same cannot be said for a lot of other HTML elements, which often have bizarre and inconvenient rules when it comes to style-ability, or nest-ability.
It works (and should work) both ways. Main reason is that abandoning the principles doesn't automatically mean innovation. Most of the time it's just tradeoff between safety/cost and perceived convenience. And quite often the convenience is illusory because the costs are simply pushed to someone else or just delayed.
I can think of one reason for strict adherence to principles is for newbies, for new starters not familiar with the world they're dealing with, too many moving pieces can be overwhelming, so using principles to fixate a few things can be helpful.
In software engineering, “principles” constitute a delicate and evolving synthesis of theoretical constructs and empirical lessons.
They transcend the mere aftermath of triumphs, as posited by the author, to encapsulate the intricate tapestry woven by both successes and failures.
The author posits that principles are the byproduct of success, but that’s simply not the whole truth.
Principles, far from being dichotomous with experimentation, represent not only “prescriptive guidelines for successful implementation” but also incorporate the counsel of hard experiences and bitter emotional lessons distilled from the long and enormous crucible of software project failures.
In my experience managing and coding software engineering projects, this kind of fidelity to principles becomes a multidimensional pursuit, where the so-called “failure principles” bear just as much gravitas as their counterparts learned from success.
> This is also why it’s important for the makers of policies and standards to be connected with the real-time experimentation in a market, and not in silo, to constantly adapt, iterate, and refine standards and principles according to real-world outcomes.
This lesson is profoundly true, and encompassed in lean experimentation and their ilk, and while it’s important not to rely on principles to guide product as effectively it becomes tradition guiding product instead of learnings and therein lies real risk, principles and the practice of adapting, iterating and refining standards are not exclusive in any way. You can have a map and make changes as you learn things in the exploration.
That is why we have rules of thumb and principles for doing things: because it’s incredibly important to pay attention to “principles” in order to mitigate the not so insignificant risk of catastrophic failure. So saying that all principles come from success is not correct.
After all, ‘those who chase two rabbits never catch one’ isn’t the lesson of a successful hunt.
And then, there are the deeper principles, which are broadly applicable across diverse fields.
Examples:
- Permaculture design principle #1 - "Observe and Interact"
- Kanban principles, "Make work visible", "Everything in its place"
(This quote seems to no longer appear in your comment, but I started drafting my reply about five hours ago.)
> - Do not repeat yourself.
I recently ran into a case where DRY was practically a necessity, because the alternative (of simply repeating myself) would not only have been prone to copy/paste errors during authorship, but also have resulted in code with an incredibly low signal to noise ratio (which also would have made authorship quite tedious).
For a bit of backstory, I'm currently toying with writing some Luau bindings for Rust, but Luau (by default) throws C++ exceptions instead of using longjmp. These exceptions can be thrown by almost any Luau function, and I need to prevent them from unwinding across FFI boundaries to avoid triggering Undefined Behavior, because in Rust, it is UB for a "C"-ABI function to unwind into its caller.
Here are some things that can throw C++ exceptions in Luau:
- OOM when allocating new garbage-collectible objects in an existing VM. Creating the VM itself is (most traditionally) done through luaL_newstate, which returns NULL on allocation failure, but once you have a VM, attempting to instantiate a collectible object within it will throw an exception if allocation fails. This can happen indirectly through any other operation that internally creates collectible objects.
- Attempting to modify a readonly table. Luau implements a readonly bit for tables that controls a guard against modification of that table, even by native code. It does this by throwing an exception when any such modification is attempted. However, just like collectible objects, table modification is an implementation detail of all sorts of things. While I don't expect anyone to be able to readonly the Luau registry, it is still a thing that you can do to arbitrary other tables (assuming that the host side doesn't omit or remove the `table.freeze` function from the standard library). Technically, you could defensively check the readonly bit from Rust before attempting those operations, but that would cause it to be checked twice on each operation, and this workaround doesn't generalize to other sources of exceptions, nor does it work through indirections (random other functions that happen to write to tables internally).
- Arbitrary function calls, if an interrupt callback is set. Luau supports an "interrupt" callback that is periodically called by the VM at "checkpoints" such as function calls. The interrupt callback is allowed to throw an exception, as this is the officially supported method of eventually terminating functions that contain infinite loops or other code that blocks the thread for too long. AFAIK, it can also be triggered in the middle of C closures if you perform certain operations like making a Luau function call. Although Luau function calls themselves may error, the interrupt callback can cause any Luau function call to error, even if it normally should not.
Luau probably expects those kinds of operations to be performed primarily by C++ functions executing under the VM ("C closures"), where any exceptions will be automatically caught and a status code returned to whoever called the VM. Generally, it is quite a reasonable assumption to make that a library will be used from the same language that it is written in.
However, Rust can't currently express "C closures" that are capable of unwinding, because unwinding out of a "C"-ABI function is Undefined Behavior (Rust wouldn't be able to unwind into the VM), and so is a "C"-ABI function unwinding into a Rust stack frame (library functions wouldn't be able to unwind into Rust in the first place).
The "C-unwind" ABI should eventually allow Rust to express and call FFI functions that are capable of unwinding, but it hasn't quite reached stabilization yet.
If Rust had already supported "C-unwind", I could have just defined a C++ wrapper function that catches Luau exceptions and translates them into a tagged union or something representing success or failure. Unfortunately that is not yet the case.
Luckily, Luau has some internal functions that allow you to catch exceptions regardless of whether they are exceptions or longjmps, but they work by executing a callback that you pass to it, and you can only pass a single pointer value through to the callback. Therefore, my first solution was to place the arguments to be passed in a struct, as well as a slot for a return value, and then read that struct by pointer in order to call the function and write its return value into the slot.[0]
This worked, but it was a lot of manual code for each individual function that had to be protected from errors - you had to duplicate the argument list about 4 times (wrapper function signature, struct definition, struct initializer, and wrapped function invocation), which quickly got quite tedious, especially since quite a few functions are going to need this wrapping treatment.
My first DRY implementation[1] was to create a template that can produce a wrapper around any function, that calls it with any number of arguments, of any types. I still needed to manually prepare a list of functions in advance to protect, since you can't instantiate templates over FFI, but this was a lot more painless than the first try.
It's just that the templates are a bit of a mess.
[0]: https://github.com/LoganDark/luau-rs/blob/787eb0c7987c08304c...
[1]: https://github.com/LoganDark/luau-rs/blob/de5abd5420a5311c27...
I would say, and do say, that Principles are Rules of Thumb
If you've ever had to live through some shit, principles are born as a way to stay alive when shit hits the fan. They aren't simple rules of thumb for the people who live them.
I would argue that most aren't. Most principals I've heard seem to happen because they look good on paper or sound smart in a meeting.
Heh, the ones that sound good are the ones that people spent time refining and proving to themselves. For example, the one I primarily live by is “Do whatever you want as long as you are willing to pay the price and deal with the consequences.” It’s quite nuanced, in reality, because there are always unforeseen consequences in any action, and there may also be hidden costs.
This principle is a bit weird to frame some kinds of decisions around, it ignores that fact that inaction also has a cost and consequence, and ignores the fact that there are unknown unknowns.
That’s why to anyone else, it is simply a “rule of thumb” because internally, there are simply certain kinds of decisions this doesn’t make any sense for and there are two other principles that come into play.
We all eventually come up with our own “truth” and principles to live by. Eventually. I think it’s just a product of getting older and especially going through things largely outside of your control.
Good points. The reason I equated "Rule of Thu8mn" with "Principle" is that neither is always correct. They are abstractions that cannot list all possible details, therefore they apply in many or most situations but not all.
People say they "live by their principles" but I don't think that always is the case for them, in every situation anyway.
Rule-of-Thumb comes from electro-magnetism I believe and it's point is it makes something more complicated easy to remember.
https://www.electricaltechnology.org/wp-content/uploads/2020...
