← Back to context

Comment by embedding-shape

10 hours ago

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

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

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

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

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

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

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

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

  • 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

      1 reply →

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.

  • 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!

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