hnedeotes

does that really help? I have had llms fumble pretty simple stuff in html/css and probably that's what there's more information on the internet, while with simple packages/languages with clear cut semantics it seems to be much better, even if off some samples pasted into context.

[edit] the case was simply, write me an html landing page, with a navbar, a content area and a footer, make sure the content on each area doesn't extend beyond 1200px wide , make each container centered (paraphrasing)

I would be really excited to see this moving forward - saying as someone who uses Phoenix regularly (and likes it for the most part) and has used react, vuejs, and so on - even at the stage it's at is already a very promising DX with what looks like a very reasonable roadmap and clear intent.

Having elixir apps that can work seamlessly local-first would be amazing and take care of one of the only areas where phoenix can't completely cover out of the box, making things that today take a lot of glue code, and error prone, a matter of a few declarations.

wait a minute... OMG https://www.haskell.org/cabal/

It's more hand-wavy than it's admitted. When you think about it, the idea of emergent phenomena amounts to:

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

I don't understand completely why you're being downvoted. I'm european, in favour of GDPR, and I think this is a valid way of doing it. These reactions confuse me the same as using incognito or adblockers to pass paywalls and such - if that's their business model and their choice, I'm going to say no, and won't even be interested.

That's:

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)

Unbound technological surveillance in the hands of a few, and police state on the basis of false flags are the stepping stones to RealFreedom™

If time is infinite, it means that everything *must* already have happened *or* can be assumed to have happened, including game over and game restart.

no house/bike/computer will ever be better ever in the history of the universe.

Extraordinary claims require extraordinary evidence.

Yeah, just look at the amazing tech and tools. The fragmentation is by design and doesn't come through languages.

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

That's actually much a feature. Many problems can still be done quite efficiently, for instance stream parsing a file you can have each N newlines being sent to different processes, and the same with many other problems that can be sliced, traversing nested collections, fetching batches of records from stores, etc.

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.

Erlang has a simple memory model that cannot do joint parallel tasks.

What do you mean?

Webpack is also a single file.

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.

Thank you, I can be wrong obviously, but your argument in light of our current times would actually indicate that a lot of smart informed people are more tending to idiotic brainless emanations than anything else.

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.

Yeah, I don't feel the same pains though.

So yeah, I agree with pre-processing utilities - but this is just the same problem as with CSS and I think the apply idea is actually pretty neat...

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.

But honest question, wouldn't those years of wrestling with the right UI framework be better spent learning the underlying CSS rules and adopting a simple pre-processor that gives you programmatic generation for repetitive bits?

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

Yes I did, that's why I'm of that opinion.

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.

Sincerely I don't understand what's the appeal of tailwind. It's just one more sign of dementia to add to the landscape.

When the CEO asks what you think about it, just go

  Chico, this no bueno!

The problem with what you're saying is that it's meaningless without concrete examples?

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.

I agree with the no silver bullet thing - and written on another reply I don't even know if I agree with the example in the article.

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

That is true (less so in FP languages though), but the for loop doesn't either - indeed I do prefer it most of the times, I think its a reasonable expectation to provide the most intention revealing constructs when possible, it's also easier to spot "code smells" when using those. The exceptions I make is when there's significant speed concerns/gains, when what you're doing is an actual loop, when the readability by using a loop is improved.

(and I haven't read the article so not even sure I agree with the example there, this was more in general terms)

It can definitively happen, but I think more times than not the others are more readable.

To be honest this seems to be a familiarity thing > but with reduce you need to know what arguments in a callback mean

If I didn't know for it would be mind boggling what those 3 things, separated by semicolons, are doing It doesn't look like anything in the usual language(s) they're implemented. It's the same with switch.

The only thing both of them have, for and switch, and helps, is that languages that offer it and aren't FP usually use the same *C* form across all, whereas reduce's args and the callback args vary a bit more between languages, and specially between mutable and immutable langs.

I still prefer most of the time the functional specific counterparts.

I'm not against using for loops when what you need is an actual loop. The thing is most of the times, previously, for loops where actually doing something for which there are concepts that express exactly what was being done - though not in all languages.

For instance, map - I know that it will return a new collection of exactly the same number of items the iterable being iterated has. When used correctly it shouldn't produce any side-effects outside the mapping of each element.

In some languages now you have for x in y which in my opinion is quite ok as well, but still to change the collection it has to mutate it, and it's not immediate what it will do.

If I see a reduce I know it will iterate again a definite number of times, and that it will return something else than the original iterable (usually), reducing a given collection into something else.

On the other hand forEach should tell me that we're only interested in side-effects.

When these things are used with their semantic context in mind, it becomes slightly easier to grasp immediately what is the scope of what they're doing.

On the other hand, with a for (especially the common, old school one) loop you really never know.

I also don't understand what is complex about the functional counterparts - for (initialise_var, condition, post/pre action) can only be simpler in my mind due to familiarity as it can have a lot of small nuances that impact how the iteration goes - although to be honest, most of the times it isn't complex either - but does seem slightly more complex and with less contextual information about the intent behind the code.

This seems to not have any resemblance to the historical decline of the "Vedic Culture" way before any "colonising" by the "west".

If the guys writing the history didn't mess it up, wasn't buddha himself against the caste system? That seems way before there was even a Church in the West to begin with.

This was not to say that those things were left unattended or no effort has been made, it was in the context of the parent comment - dharmic definitions, and ideas, are fallible as everything else and can be corrupted and lead to the same or worse outcomes and they can mingle good ideas (Vegetarianism) with bad ideas (Casts).

Yeah, western countries are known for having about 50% of their population relegated to an untouchable status without any chance of social mobility or partaking in the benefits and rituals of the other 50% - and not only in this life, it's for eternity.

We'll leave that as an exercise for the reader

Yeah, I mean, why would you want concurrency primitives when you can spawn a thread, or do mutexes, or do locks at the db level, or use redis as an actor, for when, for instance, you want to allow users to upload N simultaneous files, but have a limit by user plan to 5 maximum uploaded files, or process N CSVs or excel files in parallel and broadcast the changes to all admin accounts, or not allow multiple simultaneous edits to a resource. It's just more sane to rely on 3 or 4 moving pieces outside of your environment to achieve it.

In fact, I think you should go pitch this idea to all OSes developers, nobody is doing more than one thing at any given point in time, so clearly multitasking is unnecessary cruft, pthreads, selects, etc just cater to insecure devs that want to feel cooler and pretend they're not in the stone age of computing anymore.