5 ms·

A lot of methods of expressing software ideas are also very inefficient. The actual interesting part, the entropy, is very small. In the demo it’s literally two

by jprete 3y ago

A lot of methods of expressing software ideas are also very inefficient. The actual interesting part, the entropy, is very small. In the demo it’s literally two sliders controlling two CSS attributes which is not a lot of bits of entropy in a UI specification. With an appropriate UI specification language, that would be, what, three lines of code? Needing to manage Web UI boilerplate is where the difficulty is.

Filligree 3y ago
But if you use a specification language, then how can you build a pixel-perfect, unique set of sliders that’s subtly different from everyone else’s?
- pc86 3y ago
  IME the real "problem" (maybe just interpersonally) is when you have a product person, or a designer, who insists that something needs to be pixel-perfect and subtly different when it objectively does not. Maybe even when it is a grey area but the juice isn't worth the squeeze. Case in point I'm in the middle of, let's just call it what it is, an argument, because a new page in a new section of our app has a different design for form elements, specifically single check boxes (think TOS, affirmations, etc). Well we have shared components obviously, so we're reusing the component. No sense taking half a day or more to reskin this one checkbox on one page. The amount of grief and manhours wasted discussing this checkbox would astound you. Thousands of dollars in payroll over multiple meetings so far with no end in sight because this particular check box just has to be slightly different. The ticket which has been feature-complete for over a week has no chance of being merged in November.
  - jprete 3y ago
    The usability article [1] from yesterday suggested a similar problem - design-oriented people want to put their graphical mark on their GUIs, and it comes at a significant usability cost. GUIs are most usable when they are consistent - everyone uses exactly the same UI elements, with the same exact color schemes and shapes and sizes, to mean the same things every time. And that’s…not what people do anymore. [1] https://news.ycombinator.com/item?id=38280201 https://news.ycombinator.com/item?id=38280201
    - tsunamifury 3y ago
      Dear god another “engineers don’t get the difference between design and ux and complain that everything should just all be the same” thread.
  - fidotron 3y ago
    I swear the art form here is to provide the product people and designers with a tool/framework where they make the choices and they suffer the constraints, then they have to blame themselves when they can't do it. There is the old story about Steve Jobs and the Mac calculator app, where they made a calculator toolbox to build one in order to prevent him demanding seemingly arbitrary changes all the time. https://www.folklore.org/StoryView.py?story=Calculator_Construction_Set.txt https://www.folklore.org/StoryView.py?story=Calculator_Const...
    - lanstin 3y ago
      Exactly. Look not at the requirements but at the likely space for requirements over time and build an engine that can be tuned/tweaked/configed to meet all the likely requirements. Makes testing a little harder but makes dev and product happy.
- coldtea 3y ago
  Hook the resulting GUI code up to customizable styling?
LordShredda 3y ago
I blame Microsoft for having five different UI toolkits across three languages. Web browsers aren't that cross platform, is the GUI toolkit that is, so use that!
- creshal 3y ago
  Which of the 7251 reactive JS frameworks do you want to pair with which of the 15281 css frameworks to achieve the result?
  - zztop44 3y ago
    Does the user care?
    - isilofi 3y ago
      Yes. Almost none of those get i18n, hotkeys, shortcuts, taborder, screenreaders and other accessibility right.
      - pc86 3y ago
        Most users don't care about any of that, either. And I would argue that i18n and l10n belong outside your language's framework (and obviously outside CSS).
        projectazorian 3y ago
        Accessibility is legally mandated in many cases and if you ever want to sell your app to government or enterprise customers, it’s likely to be a requirement.
        coldtea 3y ago
        >Most users don't care about any of that, either. That's because they don't know what they are. They suffer the consequences of not having them though.
lovasoa 3y ago
I have been thinking about that a lot recently. Where I work, we spend a very small fraction of our time on building things that are unique to our business. Maybe we are doing something very wrong, but I am under the impression that most of the code that gets written anywhere is extremely low-entropy. This low-entropy, repetitive coding is not limited to the user interfaces. We do tend to describe the same structures and logic over and over again in front-ends, backends, and databases. I am currently building an open-source project that tries to make the definition of applications from database structure to business logic to user interfaces, much more declarative and compact. If you are interested, you can try it on https://sql.ophir.dev https://sql.ophir.dev
- withinboredom 3y ago
  > we spend a very small fraction of our time on building things that are unique to our business. I usually see this in places/cultures that value code-beautification projects rather than delivering value to the customer. Sometimes, they even want to do the latter, but actually do the former. If you work somewhere that focuses on delivering value, the devs constantly complain about technical debt that will never, ever get fixed. That's the only sucky part.
  - nine_k 3y ago
    "Code beautification" is not the point, but a tool. Smaller and clearer code could be faster to write, and harder to make mistakes using. This is why e.g. Rails can be so good at producing certain kinds of apps very quickly and in very few LOCs. The problem is, of course, that simplicity follows complexity, not the other way around. Because of that, it's mostly "trivial" and "repetitive" tasks that receive polished tools for easy and compact expression. Anything new and non-trivial usually grows ugly and uncouth for quite some time.
    - withinboredom 3y ago
      Code Beautification is a waste of time and ossifies a code base. It's a form of optimization that actually makes the code harder to change and the business less agile. It is pretty though.

by jprete 3y ago

Filligree 3y ago

But if you use a specification language, then how can you build a pixel-perfect, unique set of sliders that’s subtly different from everyone else’s?

pc86 3y ago
IME the real "problem" (maybe just interpersonally) is when you have a product person, or a designer, who insists that something needs to be pixel-perfect and subtly different when it objectively does not. Maybe even when it is a grey area but the juice isn't worth the squeeze. Case in point I'm in the middle of, let's just call it what it is, an argument, because a new page in a new section of our app has a different design for form elements, specifically single check boxes (think TOS, affirmations, etc). Well we have shared components obviously, so we're reusing the component. No sense taking half a day or more to reskin this one checkbox on one page. The amount of grief and manhours wasted discussing this checkbox would astound you. Thousands of dollars in payroll over multiple meetings so far with no end in sight because this particular check box just has to be slightly different. The ticket which has been feature-complete for over a week has no chance of being merged in November.
- jprete 3y ago
  The usability article [1] from yesterday suggested a similar problem - design-oriented people want to put their graphical mark on their GUIs, and it comes at a significant usability cost. GUIs are most usable when they are consistent - everyone uses exactly the same UI elements, with the same exact color schemes and shapes and sizes, to mean the same things every time. And that’s…not what people do anymore. [1] https://news.ycombinator.com/item?id=38280201 https://news.ycombinator.com/item?id=38280201
  - tsunamifury 3y ago
    Dear god another “engineers don’t get the difference between design and ux and complain that everything should just all be the same” thread.
- fidotron 3y ago
  I swear the art form here is to provide the product people and designers with a tool/framework where they make the choices and they suffer the constraints, then they have to blame themselves when they can't do it. There is the old story about Steve Jobs and the Mac calculator app, where they made a calculator toolbox to build one in order to prevent him demanding seemingly arbitrary changes all the time. https://www.folklore.org/StoryView.py?story=Calculator_Construction_Set.txt https://www.folklore.org/StoryView.py?story=Calculator_Const...
  - lanstin 3y ago
    Exactly. Look not at the requirements but at the likely space for requirements over time and build an engine that can be tuned/tweaked/configed to meet all the likely requirements. Makes testing a little harder but makes dev and product happy.
coldtea 3y ago
Hook the resulting GUI code up to customizable styling?

LordShredda 3y ago

I blame Microsoft for having five different UI toolkits across three languages. Web browsers aren't that cross platform, is the GUI toolkit that is, so use that!

creshal 3y ago
Which of the 7251 reactive JS frameworks do you want to pair with which of the 15281 css frameworks to achieve the result?
- zztop44 3y ago
  Does the user care?
  - isilofi 3y ago
    Yes. Almost none of those get i18n, hotkeys, shortcuts, taborder, screenreaders and other accessibility right.
    - pc86 3y ago
      Most users don't care about any of that, either. And I would argue that i18n and l10n belong outside your language's framework (and obviously outside CSS).
      - projectazorian 3y ago
        Accessibility is legally mandated in many cases and if you ever want to sell your app to government or enterprise customers, it’s likely to be a requirement.
      - coldtea 3y ago
        >Most users don't care about any of that, either. That's because they don't know what they are. They suffer the consequences of not having them though.

lovasoa 3y ago

I have been thinking about that a lot recently. Where I work, we spend a very small fraction of our time on building things that are unique to our business. Maybe we are doing something very wrong, but I am under the impression that most of the code that gets written anywhere is extremely low-entropy. This low-entropy, repetitive coding is not limited to the user interfaces. We do tend to describe the same structures and logic over and over again in front-ends, backends, and databases. I am currently building an open-source project that tries to make the definition of applications from database structure to business logic to user interfaces, much more declarative and compact. If you are interested, you can try it on https://sql.ophir.dev https://sql.ophir.dev

withinboredom 3y ago
> we spend a very small fraction of our time on building things that are unique to our business. I usually see this in places/cultures that value code-beautification projects rather than delivering value to the customer. Sometimes, they even want to do the latter, but actually do the former. If you work somewhere that focuses on delivering value, the devs constantly complain about technical debt that will never, ever get fixed. That's the only sucky part.
- nine_k 3y ago
  "Code beautification" is not the point, but a tool. Smaller and clearer code could be faster to write, and harder to make mistakes using. This is why e.g. Rails can be so good at producing certain kinds of apps very quickly and in very few LOCs. The problem is, of course, that simplicity follows complexity, not the other way around. Because of that, it's mostly "trivial" and "repetitive" tasks that receive polished tools for easy and compact expression. Anything new and non-trivial usually grows ugly and uncouth for quite some time.
  - withinboredom 3y ago
    Code Beautification is a waste of time and ossifies a code base. It's a form of optimization that actually makes the code harder to change and the business less agile. It is pretty though.