- There's no underlying consciousness or conscious originator (no god, no panpsychism, no underlying conscious layer at the basis of reality, no nothing) - At some point, two or more elements (rocks, atoms, etc, that weren't conscious), aligned precisely in a given configuration and zap!, they became conscious and interactive - All consciousness then sprang from that.

So the question would be, if systems favour inertia, stasis and conservation of energy, why would there be consciousness at all and just not an endless void, or a perfectly stable (as in homeostasis) system without conscious agents, or just rocks floating in the space.

I'm not saying the idea of emergent phenomena is wrong, just that you better answer the complex questions other "supernatural" theories try to address, before declaring it some sort of obvious and correct answer.

a) A theory b) That in no way contradicts the possibility of a continuum where universes may rise, expand, contract and die, only to rinse and repeat c) If nothing can be created out of nothing, and if in the universe energy cannot be created or destroyed that doesn't seem to be correct unless the universe is an artificial system d) The only way for C) to be true is if everything is always the same thing in different forms, at which point we might as well say time is infinite

(caveat: artificial systems of course - but those still need to be initiated from somewhere else at some point down or up the chain of creation - so it should follow that something infinite must be at play)

Extraordinary claims require extraordinary evidence.

And boy, that's some investment on technology you have there going.

Sometimes you can also reformulate the problem, but yes not all problems fit.

I would add though that whenever you want to write orchestration around that parallel work it's much easier in erlang than the alternatives.

What do you mean?

> Is that bad? Not using Tailwind forces you to have a separate stylesheet that hides tag to property relationships, among other hidden abstractions. The class names barely need to be learned. With an IDE, you get class name completion, and there are only a few properties that have unexpected names.

Well, the purpose is actually to have separate stylesheets, so that you can name them in a relevant manner, I don't know, like menus.[s]css, panels.[s]css, just like so you know where things are, and so that you can use a class to define repeating elements across a codebase. There's no abstractions in CSS that aren't present or amplified in tailwind - there's pre-processing utilities that are useful in tailwind but they're present in any pre-processor without the remaining stuff. And in fact the logical way of using CSS is by defining classes and then defining modifications to those classes, when needed, when they're part of a hierarchy of classes that requires it. They're one grep away of being discovered in all css files.

> What do you mean "the point of CSS"? Read the spec. It says nothing about the number of properties a class should contain.

Uhh. Yeah, I might one day, but I don't get what you're saying.

> If you mean classnames should be higher level abstractions than CSS properties,

A classname is a selector token, that you can place in CSS hierarchies and define a set of rules, that affect the elements using that classname. It's obviously a higher abstraction than a style rule.

I wasn't talking about semantic html5, I'm talking about semantic markup for readers of the code. If I see "t-4 h-3 w-2 mongo-xyz bg-pearl-800 flex flex-col m-4" I can understand it after reading all of those properties in tailwind, perhaps and how they all interact. But I'll need to understand that it uses relative sizes (like, why...) that m-px is one 1px, m-4 is 1rem, but what I want is fixed sizes 99% of the time. That someone might have disabled some of the sizes generation. Then I don't know, if someone asks me to change the styling now I have to go through all the codebase, searching for elements that are styled like that, because I have not way of identifying it and I have to change all their classes to the new style. Obviously, it's much harder to have it placed in a single file. Inline classes are better somehow than inline styles (although you can't know exactly what it's affecting), and there's a place for inline styles, but 99% of the time it's bad.

This is of course unrelated to tailwind and the words I used there were pretty uncharitable - it's open source after all - but I have yet to see a good example of it clicking, the way I've seen it, in my assumedly small real use sample pool, doesn't seem good at all.

But... I need to know all those classes to know why the final rules are put in place, I need to know that they don't have conflicting properties, or if they have, their priorities. And when you add your own custom apply's in there, then it can also break just the same. And when you customise your tailwind classes it ends the same problem. So when you're trying to figure out why rows in a table with the same number of headers and same number of td's have different sizes because some no-breaking space class was applied, and why your a.btn isn't getting the same styling as your button.btn and etc, I always feel like I've wasted more time than I should (perhaps because I know css and used it extensively)

I might have been a bit harsh on saying "dementia" as it's disrespectful for those who've put the work in writing it and releasing. It's better than all previous frameworks - I just personally think that it's problem searching for a solution as you can't really win.

Because in the end, tailwind is better than bootstrap, but it's still the wrong way and incentivises wrong patterns.

And by making it "standard" it makes everybody new to the field start with it and use it, foregoing learning the CSS. And will be supplanted at some point, and then there'll be the dance again. And again. It's just this that I don't understand.

At the point you're customising tailwind and classes you run into the same problems as with CSS without clear guidelines/organisation. So the only way to not run into that it's to use it as inline styles but with classes...

What it does is force you, as other frameworks, to learn all its intricacies, design decisions, use an heavy and complex development environment (that besides that reads files it doesn't have anything to go about reading?) so that you don't need to learn the underlying language.

Then it nudges you to write a soup of classes (that you need to learn, and need to learn the config because it seems by default it has -400 but not -500, or whatever, and need to learn their priorities), that you need to keep changing and copying pasting (yes you can write classes that coalesce your styling... but that's kinda the point of CSS and/or any other pre-processor), and forget about semantically marking your html. (I'm not saying you have to write it badly, it's just that writing it poorly seems much easier - and is the same with CSS).

I just don't see the point - with the exception of the pre-processing part of course - CSS can use some little help in some places to generate programatically some things but I think those are better served by a pre-processor and not a framework as the framework tends to guide the overall design of the remaining things.

  Chico, this no bueno!

What is "over abstracted code"? Perhaps we agree on this point, but I don't know because when people talk about these things no one has any idea of what they mean - we use "over-testing", "under-testing", "over-engineered", "sloppy", "too much abstraction", "simplicity", "complexity", and everyone has different takes on what these words mean but everyone agrees they're bad or good. It's a bit non-sensical.

What is the problem of jumping through files? Do you feel the same about jumping through functions? Is it better to have a soup that you can only test by setting up a new solar system? Is that why testing is considered "expensive"? And what is the solution when products need to be evolved, redesigned or pivoted? Re-write? Re-hire a team? Do the same crap again but with new tools? No tests? Or you simply don't like jumping?

Is it worth it to have bad api's, bad products, that offset millions of hours in work around to all developers (and non-developers as well) who have to use them because someone couldn't be bothered? Shouldn't the premium on salaries for developers conjure some real interest in doing things right? Is it normal that governmental institutions, public companies, banks, etc have awful interfaces, buggy behaviour, etc?

Isn't it normal that if you're commanding a very comfortable salary there should be an expectation of continuous improvement, research and learning for the work you choose to do?

Perhaps I agree with what you're saying, or perhaps I completely oppose it, but I can't tell.

> The fact that a map() function tells you that you're converting elements of lists does not save you from understanding what is that conversion doing and why.

It can actually, say you have a query that comes in, this calls a function that fetches records from the database, it's not a basic query, it has joins, perhaps a subquery, etc. Then you have another function that transforms the results into whatever presentational format, decorates, wtv, those results, and it's also more than a few basic couple lines of logic.

And now you have a bug report come in, that not all expected results are being shown.

If you have

  func does_query -> loop transforms

If you have

  func does_query -> func maps_results