cuddlecake

Essentially, what this code does is:

  background: linear-gradient(to right, #007CF0, #00DFD8);
  -webkit-background-clip: text;
  -webkit-text-fill-color: transparent;

- the background is the linear gradient

- background-clip makes the background only appear behind text

- text-fill-color changes the text's fill color. Not sure why text-fill-color is used, `color: transparent` seems to do the same.

If you want a non-react, reusable way:

  .gt {
    background: linear-gradient(var(--gt-direction), var(--gt-start-color), var(--gt-end-color));
    -webkit-background-clip: text;
    color: transparent;
  }

Fiddle: https://jsfiddle.net/wmvhkrfe/16/

This way you can add various CSS helpers for start-color (or set them manually via JS)

If it's better than 90% of today's synth music, does that mean that 10% of today's music is better than Moroder/Jarre?

That's a lot!

Not sure if OO really rules the GUI space. Afaik, at least Swift, Dart (Flutter) and Kotlin are trying to solve the mismatch between OO and Reactive Programming (where functional approaches very helpful)

Most of GUI development is pure data handling (render state and react to interactions) where a strong functional toolset is much appreciated (lambda, pattern matching) and some parts are well done with closures (where OO comes in)

Ultimately I would love to have a GUI development language that allows me to use one set of language features and constraints when I really just want to use functions on data immutable data, strong pattern matching and ADT for modelling) and another when I need strong closures, with message based dispatches and reactivity.

Basically, whatever React does, minus the constraints of requiring JS compatibility.

> They forgot to talk to people who are actually members of the black community.

Afaik, modern slaves are mostly Asian (women).

Whatever, I prefer the name "main" over "master", and moreso I prefer "trunk". Often, branch names like "develop" are used as well.

What this change helped produce was mostly that tools do not rely on `master` being the default branch, which is very helpful in some regards.

I don't like the continuing insinuation that there's "some loud obnoxious screams from certain SJW-like people".

Usually it's just loud obnoxious screams from Anti-SJW people, and people blindly following the call to arms against what they call "SJW bullshit".

Every now and then I find a link or a mention in the comments about literature or information regarding a topic I find interesting.

Lately, I learned about CSS stack contexts because of a blog post here, and read other posts by the same author. Learned a lot about CSS that day.

Oh no, I thought I finally got rid of recommendations for content by TechLead, and now I accidentally clicked on this.

Does TechLead produce anything other than shallow content with Clickbait Titles and promotion for his Tech Interview lessons?

Except for Angular2

I personally would recommend against making a lot of custom classes via @apply, especially when pairing with a component based framework like React.

React makes it easy to avoid the need for duplicate naming such as 'btn' css class and a <Button> component.

I would also recommend twin.macro, though I'm still on the fence about using it.

At the very least, it helps with difficult things like style overwrites, ensuring utilities are spelled correctly, conditionally applying utilities and bailwind (one-off styles)

I feel like being Anti-Haskell is becoming a ridiculous meme.

The author makes a lot of statements, but no arguments, no proofs, and no explanations.

Also, the post is riddled with "The Community does X" memes, such as:

> Funnily enough everyone in the Haskell community blamed everyone else instead of [...]

> [Senior Developers tell you to just] write types and interfaces for the types and fill in the blanks

> Look, even most haskellers would agree that purescript is a better choice compared to GHCJS

> [Haskellers are] using some obscure definition from category theory to explain [Monads]

> Haskell proponents try to claim that type signatures are somehow documentation

> Every few months some newbie comes along to the Haskell reddit and asks why is Haskell documentation so confusing, and the post get destroyed by people telling them to get good or just pointing at academic papers. Really?

> suddenly their precious castle [of type declarations] is reduced to dust

and the author does not give a single link or concrete example, not a single proof or evidence of this actually being the case. In the author's defense, I would also think that the Haskell Community behaves exactly like that, if I had taken every comment on HN about Haskell as being correct and truthful.

One very absurd claim by the author that I'd like to point out is:

> programs deal with data, and data has no types

All data has a type (structure, schema, intent), otherwise it wouldn't be data. Instead, it would be electrical noise.

> Types wrap data and treat it like a black box whereas schema describes the shape and content of data.

I don't understand why the author makes a distinction between "types" and "schema". I get the feeling that the author makes the distinction only to bash on Haskell because Haskellers will talk of "data types" and not of "data schemas".

> Suddenly they are left reeling as they find out that the real world is, in fact, dynamic.

That's why Haskell has `Maybe`, duh. I don't buy into the statement that the "real world is dynamic". It's just as slogan-y as "The Real World is Object-Oriented", because it seems to be trivially observed, BUT, programming is not the Real World. One programmer has a data type that he/she sends over the wire. It would be weird if another program didn't anticipate the data but could still handle it correctly without expecting the data to have a certain type. Programming is not dynamic, programming is guessing "what the fuck did the other programmer try to send me" and defining a type for that. This is done either implictly by just accessing the fields or explicitly by defining the type and parsing the data.

---

All in all, I feel like this post adds nothing in value, and I am very annoyed that it has been ranked #1 on HN, but this stays consistent with how I personally perceive the broader HN Community.

Sidenote: I am not a Haskell Developer.

The first paragraph is killing me. Had that exact situation in a startup I joined. It was annoying and it ruined my passion for the project, because the outcome of that "one" discussion shaped the project for two years.

Guy (formerly a friend) got hired 2 months after me, decided that the backend I'm working on had no architecture, so forced me to discuss architectures with him (he had never designed, developed or worked on web applications before) for two months, in the end filled with animosity, until we settled on an architecture he proposed (because he befriended the CEO better than I did). It frustrates me, whenever I think about how 2 years of problem solving were wasted on a futile architecture that we had to completely rewrite into something more akin to what I initially worked on.

"Made in X" has nothing to do with "nationalism". Also: "Made in US" labels are incredibly useful, with regards to data privacy.

The `blue-x00` is just the default, you can override which colors are available via the tailwind.config.js file, as detailed in the documentation:

https://tailwindcss.com/docs/customizing-colors

If it doesn't, surely, you can define what you mean by "trivial things"?

Your entire criticism boils down to "what waste of time trying to solve trivial things" without defining what you regard as trivial.

What's a good side project, if one is not really interested in the problem space of the side project?

I.e. I mostly just program for money, so how do I motivate myself to do a side project I'm not interested in, just to learn the language?

I wonder if I could ask my employer for two weeks of time to "rewrite" parts of our backend in Elixir, just so I could scratch that itch, without any of the consequences of it actually reaching production.

Like a programming language sabbatical

It's a new feature from TypeScript 4.1 (this version is yet in beta)

https://devblogs.microsoft.com/typescript/announcing-typescr...

It's two images that will both be displayed fully at around 1400px width.

Responsive design gone wrong, there

> Like a painter, you must know when to stop painting.

You presuppose that Postgres (or all software) is comparable to art, without making or explaining the comparison.

You say that "you must know when to stop painting", but what if the developers behind Postgres know when to stop, and it just isn't finished?

What makes you reason that Postgres is finished?

I must admit I am completely ignorant to how much of an issue this is in real life, but I'm also in the privileged position of having the backend code compiled and run on remote servers, rarely on my own machine. On the other hand, I'm a junior developer, so I might yet stumble on this problem's relevancy at some point.

To be fair, docker is already a pain on my machine (using Fedora 32). I gave up on using docker at some point.

Could you try to explain why you think rust is an ugly programming language?

Not sure if being "deployable" is an issue, considering docker exists. So, anything is deployable in the future by default, given a machine running the correct docker image.

Or am I misinterpreting the argument?

So you are critical of homosexual men having sex? Is that correct?

Just for dummy me, can you make a statement that is "critical of homosexuality" but not homophobic?

I don't even know how to argue on this. The average HN poster is definitely better than the average 8chan poster.

But that does not mean all HN posters are free of being hateful/discriminating against certain groups of people. Be it by accident or willfully.

Thinking that HN would be better than <insert any bad behavior here> is a bit too hopeful of an assumption. Everyone is prone to bad / ignorant behavior. HN users being no exception.

I have been coding TypeScript for the last 2 years, non-stop, which also shielded me from the surprise of the function's body getting stringified.

It's relatable. Most developers did not grow up with the knowledge of JS language's Design principles, which is not something I would criticize anyone for.

Can you name one or two of those popular frameworks?

Having state in a closure does not imply that it's OOP, so I'd really like to see those frameworks for reference.

"The performance benefits are evident" is a bit too authoritative to me. Would you mind giving a summary of the performance benefits?

You're correct, there's barely any difference, from a structural point of view.

I was mainly taking issue with the author's comparison of processes with microservices:

> You can consider each process a logical microservice

But as you said, the process trees can be considered (micro)services, but I wouldn't say that each process represents a microservice. It's just not accurate in my opinion.