Hacker News Reader

Comment by embedding-shape | Hacker News Reader

> every declarative language becomes a programming language.

Overly pessimistic, lots of non-programming languages remain non-programming languages. Just because one of the most widely used declarative languages start adding conditionals doesn't mean the whole world is turning upside down...

> The distinction between code, config and data is being erased.

As as lisp programmer, I love it. Get rid of treating things differently, make everything the same and make everything work with everything, code should just be data.

View on HN

> Get rid of treating things differently, make everything the same and make everything work with everything, code should just be data.

"Code should just be data" doesn't imply the converse, though; there's arguably utility in having data that isn't code, even with the premise that code should be data.

Regardless of should's or should not's, data is always code.

> Just because one of the most widely used declarative languages start adding conditionals doesn't mean the whole world is turning upside down.

The question still is: why is CSS becoming a programming language? And who decides on this, anyway?

Because modern UI toolkits like Flutter proved that UI should just be code, not separated into three different languages. In this case, adding conditionals can remove the need for js in some cases, which is good.

Considering how this is seems to be designed... I don't think that's the reason?

I mean looking at the mdn docs it's just a replacement for regular other syntax https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/V...

So instead of having a css for x which defines e.g. dark mode and light mode separately, you can now define it via a single css rule.

Where previously the "tree" forked at the beginning and attributes were set multiple times, depending on various criteria - now you set it once, and evaluate it's value depending on criteria

    div {
      background-image: if(
        style(--scheme: ice): linear-gradient(#caf0f8, white, #caf0f8);
        style(--scheme: fire): linear-gradient(#ffc971, white, #ffc971);
        else: none;
      );
    }

It looks like simple syntactic sugar to me

I should have read the docs for it then. Thanks.

Please provide evidence for that proof.

The web should always have been a programming language, with all the usual constructs available in both the display and markup layers.

But instead of a single unified standard library for the industry we got a sprawling, ludicrous mess of multiple poorly thought-out semi-compatible technologies, with an associated sub-industry of half-baked fixes and add-ons.

> with all the usual constructs available in both the display and markup layers.

I'm glad the transition to mobile web accelerated on more battery efficient GPUs was possible due to the model instead of Alan Kay's idea that websites should render themselves, where each website would have needed to be upgraded for GPU support for compositing.

As always, hindsight is 20/20, but when you're living it, the half-baked decisions and add-ons are a product of you figuring it out on the fly. You don't have the knowledge of which proposal will solidify into an industry standard, and you don't know which vestigial implementations will be a nightmare for backwards compatibility down the line.

The context is also lost. Javascript was famously coded in a day or whatever and called 'javascript' not ecmascript as marketing to compete with Java. Besides that well known case there's presumably thousands of esoteric business decisions made back then which shaped the "sprawling, ludicrous" landscape, and which are now lost to time.

Yes, the web should have always been a programming language. And the flying cars of 23xx should have never used a z-debuffer doodad.

Becoming? CSS is already Turing-complete (https://stackoverflow.com/a/5239256), even without if() function.

Why? Because of enormous JS bloat. Pure CSS solutions are more performant and backwards-compatible (don't raise exceptions which abort the code).

Who decides? CSS Working Group.

Or they are performant now. But once people start writing CSS code the same way the write JS code, they stop to be. You can still write super-tight code in ASM (or eve C) and it will be blazing fast. Almost nobody does it, because it's too hard. Once people start writing CSS the same way, it'll become slow and bloated too.

The big performance sink in CSS is rule matching, or layout if you consider that to be part of CSS.

Efficient evaluation of expressions is a solved problem.

Having conditionals would actually improve performance because you can use fewer rules.

I am not a CS expert, but this does not look like a full implementation of rule 110, nor is it even pure CSS (there is HTML involved).

What I see in the SO answer is an interface for Rule 110 with an additional set of instruction (written in a natural language) for the user to execute manually. So you can use CSS + HTML to create an interface for a Rule 110, which is then written in a natural language around that interface. The answer even states that (very relevant) caveat.

> [...] so long as you consider an appropriate accompanying HTML file and user interactions to be part of the “execution” of CSS.

SO comment:

> The formal definition (simplest) of Turing Machine is simply a tuple of states set, symbol set, initial state, accepting states set and a transition function. There is no crank in it. By computation we mean somebody needs to apply the transition function faithfully on the tape which is exactly like the clicking in this case. More formally, a model of computation can be viewed as a set of rules somebody needs to follow to do the computation. In that sense, I think CSS is Turing-Complete.

There is even a "CPU emulation" in pure CSS: https://dev.to/janeori/expert-css-the-cpu-hack-4ddj and pure CSS fetch: https://dev.to/janeori/100-css-fetch-and-exfiltrate-512-bits...

A gentle reminder: conditionals aren't new to CSS; @supports and @media are conditionals; so are style queries.

if() just codifies behaviors and hacks [1] developers were already doing.

[1]: https://lea.verou.me/blog/2020/10/the-var-space-hack-to-togg...

If only Lisp had better presense in modern code editors. Emacs is not enough, especially on Windows where it is super slow. I think this is what actually stops newcomers to start with Lisp and not Python

> I think this is what actually stops newcomers to start with Lisp and not Python

What stops newcomers is knee-jerk reactions about the (lack of) syntax, it's scary to see something that doesn't look like Algol, because everyone who does mainstream programming uses Algol-like languages.

Introduce lisp to anyone who knows programming since earlier, and 99% of them will have a adverse reaction to s-expressions, before they understand what's going on. Once they understand, it makes a lot of sense obviously, but not everyone even has that kind of open mindset where they could understand if they wanted to.

Symbolic expression is one thing, I would personally find it rather cool to have more first class expression as building block everywhere. However I'm not found of using explicit parentheses all around. Even mandatory curly/square brackets are superfluous with a properly defined syntax ruleset.

I find lisp to be a very non ergonomic language and am happy that python is the default.

Can you quantify that?

Let's just say that the weights of opening and closing parentheses do not cancel out.

I've had way more issues with proper indentation in Python and YAML than I have with parenthesis in lisp. Meaningful whitespace is about the worst idea I've seen in a programming language.

You would need to show that, including the parens, the average Lisp program requires more tokens than Python.

I'm not sure that's true. Because Lisp has a lot of facilities for writing more concise code that are difficult to achieve without the parens.

My crackpot theory is that what stops newcomers is how unergonomic "(" and ")" are to type on typical keyboards. If mainstream lisp dialects used square brackets instead, we'd all be programming in it!

> If mainstream lisp dialects used square brackets instead, we'd all be programming in it!

You've almost convinced/nerd-sniped me to write a(nother) new lisp where we'll be using brackets for forms and lists and no parenthesis in sight. It's a wild theory.

It's just a reader macro, parse out quotes, other reader macros, then replace [ -> (, ] -> ) in the rest and throw into (read).

Yeah, code is data, data is code. Every Lisp programmer knows that.

>> Just because one of the most widely used declarative languages start adding conditionals doesn't mean the whole world is turning upside down.

You need to look at a large terraform project.

I spent more time than I'm willing to on large Terraform projects. How exactly is this relevant to declarative vs imperative or even my comment at all? I don't see what the "gotcha" is supposed to be here.

> > The distinction between code, config and data is being erased.

> As as lisp programmer, I love it.

You make bad engineering decisions because you consider the advantages, but not the disadvantages. <https://news.ycombinator.com/item?id=29231493>

You make bad comments because I can't understand the point you're trying to make. I'm am engineer, I make choices based on informed tradeoffs, anything else would be sub-standard. Not sure why you think I only consider advantages, but I'm afraid asking you for clarification will just lead to more ramblings.

The disadvantages are in the post I linked to.

Alright, I guess I'll reply to that with another comment you can go and read then: https://news.ycombinator.com/item?id=38373081

Fun way of having a conversation.

Reply on news.ycombinator.com