7 ms·

Such recent demos show both how impressively ML/AI has advanced recently, and how unimpressively repetitive and unoriginal tasks keep being reimplemented by mil

Such recent demos show both how impressively ML/AI has advanced recently, and how unimpressively repetitive and unoriginal tasks keep being reimplemented by millions of developers worldwide. Since most UI screens can be accurately described in one or two paragraphs, it's no wonder they can be represented in much detail in a relatively small embedding vector.

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.
api 3y ago
People used to write assembly language manually too, writing the most simple control structures over and over hand crafted for each case. This is even more automation of drudgery and easy repetitive work.
- gtirloni 3y ago
  I welcome these tools but when you need to be completely accurate with something, you have to drop the nice graphical tool and actually edit code.. and then it's a mess. Either the code is super complex to humans or going back to graphical mode breaks everything.
  - skor 3y ago
    that sounds quite like dreamweaver
spyder 3y ago
Huh? UIs should be repetitive not impressive or original, so users don't have to learn different new interface for every app.
- another-dave 3y ago
  I think the parent's comment isn't saying that UI should be wildly different from each other but moreso highlighting that this is a prime usecase for an easy abstraction over the top.
- creshal 3y ago
  UIs should be repetitive, but we keep reinventing them anyway to satisfy the vanity of product owners/designers/managers/clients/... and built entire industries around making slightly the UIs slightly more differently than the last time.
  - gtirloni 3y ago
    Usually things naturally get mature and stop changing so much (e.g. some software reaches such maturity level that it starts offering LTS releases). This doesn't seem to be the case with UI toolkits. Is that because we still don't understand things well enough to design a decent foundation?
    - creshal 3y ago
      I suspect a large part is that the visual nature of the topic simply lends itself to endless bike shedding and fashion cycles; maturity and stability are going to be anathemata in these contexts. But it also doesn't help that input/output formfactors keep changing. We just about understood what did and didn't work with terminals when desktop GUIs sprung up, by the time those started maturing, we had to figure out how to adapt to PDAs and pen inputs, then came smartphones and tablets, then 3D for a while, then VR, and in parallel to that increasingly exotic "classic" form factors like folding devices with fluid screen sizes, ...
    - pc86 3y ago
      In my experience it's because every time you give a page or product spec to a designer they give you something slightly different based on however they happen to be feeling that day. Combine that with whatever product people do, and you get basically random UIs for each task.
rchaud 3y ago
You've put into words what has bothered me about the relentless boosterism of B2C AI solutions on the backs of hundreds of these "Hello World" type demos. "OMG, programming is dead!" The strange thing is that on HN, the limits of these approaches re: extensibility and maintenance are easily recognized when talking about traditional no-code platforms. But somehow with AI, these problems are now fixed, and we wont have to worry about unspooling spaghetti spat out from a black box.
- dartos 3y ago
  Well yeah, you just put the spaghetti into another black box and have that deal with it
- dclowd9901 3y ago
  Do you really care about extensibility and maintenance when you could just generate an entirely new component when you want more features or need to upgrade the library?
  - rchaud 3y ago
    If the team that came up with the prototype assumes that responsibility, then no, I don't. I'm sure an AI will understand how to refactor the codebase on an adhoc basis without creating any problems down the line.
    - CamperBob2 3y ago
      Not a matter of refactoring. AI should ideally regenerate the code from the spec each time the requirements change. "Programming" won't go away, but it will refer to working with specification languages, not implementation languages. In the best of all possible worlds, you'd have to deal with the C++ or JavaScript code about as often you have to dig into the x86 or ARM assembly code now.
      - lobsterthief 3y ago
        The second you need to do something the AI can’t do, you’ll be trudging through garbage and breaking tons of things in regression (causing either errors or visual bugs). In your scenario, AI will likely produce code that _it_ determines to be maintainable, or if it’s rebuilt each time as you suggest, then it doesn’t need to be maintainable or readable at all. Good code is written for teams, not individuals. It’s written for future you and future people who you will never meet.
geodel 3y ago
Well billions of human beings are living remarkably repetitive and unoriginal life. Doing few categories of work, living in few categories of home, and eating few varieties of food. Same for entertainment, transport and so on. Most people are just running in rather tight loops. Perhaps to start with, one way to have vastly more creativity/diversity of things people do is to have vastly fewer humans on earth.
- creeptofashbash 3y ago
  [flagged]
seydor 3y ago
Html supports a lot of UI widgets now but everybody keeps reimplementing their own. And because nobody is using them they arent improving so nobody is using them so they arent improving.
- lobsterthief 3y ago
  It’s because they display—and behave—wildly differently in different browsers. This has been the story of tons of HTML5 “widgets”. I know this isn’t quite a widget, but when something as simple as input type=“number” was introduced, I was excited because it could be used to call up the mobile keyboard for numeric input. (Say for a zip code, which is a common use case). But unfortunately, it can also be changed via your mouse’s scroll wheel, accidentally, so I’m stuck using input type=“tel” for everything. (Do you want to scroll to your zip code?) The problem with these things is you can’t just push out improvements and fixes. Everything has to be backwards-compatible and I feel like they’re never nearly good enough at the beginning.
danenania 3y ago
While I agree at a high level, it's also important to understand that most of these demos are being carefully cherry-picked. If you are just seeing the viral demos on social media, you're going to think AI is further along than it actually is for more complex tasks. People who are non-technical and not using AI in anger to get real work done are going to be the most susceptible to this. Those in the weeds are generally going to have a more nuanced view of the benefits and challenges--i.e. that it's incredibly useful but also very fallible and requires careful hand-holding to get production-ready results. I say all that as an AI optimist. The value is real and the most impressive demos are glimpses of where we're heading. But it's going to take some time before the median result catches up to the hype.
- benatkin 3y ago
  I think the examples by naysayers of what AI can’t do are often cherry-picked. The way has been shown with the web. Now many people who would have been paying a designer are using things similar to Wix. A lot of people don’t need top of the line custom work, and most custom work isn’t top of the line. I’ve seen AI frequently, but a bit unpredictably, hit the high notes. https://www.joelonsoftware.com/2005/07/25/hitting-the-high-notes/ https://www.joelonsoftware.com/2005/07/25/hitting-the-high-n...
  - danenania 3y ago
    You know, that’s a great point! Both the negative and positive outliers can be cherry-picked to misrepresent what working with AI is really like in practice. Some want to pretend it’s much further along than it actually is, while some want to pretend it’s all just a flash-in-the-pan. The truth lies, predictably, in between: it’s useful and it’s real, but it’s not consistent or reliable… yet.
    - KerrAvon 3y ago
      is it a great point? the failure cases will recede as people figure out what to do with it, but right now the failures are extremely numerous.
themagician 3y ago
> how unimpressively repetitive and unoriginal tasks keep being reimplemented by millions of developers worldwide This extends far beyond just developers. This is a majority of all office work, from data entry to accounting to creative work. Most office work is just doing the same thing over and over again, often times with different people repeating what are essentially the same tasks, just at different companies.
- deleted 3y ago
  [deleted]
titzer 3y ago
It just exposes how stupid our software stacks are. Everything is driven by "well, maybe they'd want to customize this and that and that and three hundred irrelevant details". When in reality all we ever wanted was to separate the functionality from its presentation. Which, incidentally, was exactly the Web we had in 1996 with just bare HTML. Things have gone horribly, horribly wrong in such a mind-bogglingly stupid way and nobody is better for it. Oh but those dropshadows and inner flexboxes or something.
CobrastanJorji 3y ago
In that vein, I wonder if you use these embeddings and compression to work out a new sort of programming language which could extremely concisely represent these concepts. Probably the actual result would be so complex as to be worthless, like code golf languages but worse, but maybe it could help us come up with an interesting new programming language paradigm.
deleted 3y ago
[deleted]

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.

api 3y ago

People used to write assembly language manually too, writing the most simple control structures over and over hand crafted for each case. This is even more automation of drudgery and easy repetitive work.

gtirloni 3y ago
I welcome these tools but when you need to be completely accurate with something, you have to drop the nice graphical tool and actually edit code.. and then it's a mess. Either the code is super complex to humans or going back to graphical mode breaks everything.
- skor 3y ago
  that sounds quite like dreamweaver

spyder 3y ago

Huh? UIs should be repetitive not impressive or original, so users don't have to learn different new interface for every app.

another-dave 3y ago
I think the parent's comment isn't saying that UI should be wildly different from each other but moreso highlighting that this is a prime usecase for an easy abstraction over the top.
creshal 3y ago
UIs should be repetitive, but we keep reinventing them anyway to satisfy the vanity of product owners/designers/managers/clients/... and built entire industries around making slightly the UIs slightly more differently than the last time.
- gtirloni 3y ago
  Usually things naturally get mature and stop changing so much (e.g. some software reaches such maturity level that it starts offering LTS releases). This doesn't seem to be the case with UI toolkits. Is that because we still don't understand things well enough to design a decent foundation?
  - creshal 3y ago
    I suspect a large part is that the visual nature of the topic simply lends itself to endless bike shedding and fashion cycles; maturity and stability are going to be anathemata in these contexts. But it also doesn't help that input/output formfactors keep changing. We just about understood what did and didn't work with terminals when desktop GUIs sprung up, by the time those started maturing, we had to figure out how to adapt to PDAs and pen inputs, then came smartphones and tablets, then 3D for a while, then VR, and in parallel to that increasingly exotic "classic" form factors like folding devices with fluid screen sizes, ...
  - pc86 3y ago
    In my experience it's because every time you give a page or product spec to a designer they give you something slightly different based on however they happen to be feeling that day. Combine that with whatever product people do, and you get basically random UIs for each task.

rchaud 3y ago

You've put into words what has bothered me about the relentless boosterism of B2C AI solutions on the backs of hundreds of these "Hello World" type demos. "OMG, programming is dead!" The strange thing is that on HN, the limits of these approaches re: extensibility and maintenance are easily recognized when talking about traditional no-code platforms. But somehow with AI, these problems are now fixed, and we wont have to worry about unspooling spaghetti spat out from a black box.

dartos 3y ago
Well yeah, you just put the spaghetti into another black box and have that deal with it
dclowd9901 3y ago
Do you really care about extensibility and maintenance when you could just generate an entirely new component when you want more features or need to upgrade the library?
- rchaud 3y ago
  If the team that came up with the prototype assumes that responsibility, then no, I don't. I'm sure an AI will understand how to refactor the codebase on an adhoc basis without creating any problems down the line.
  - CamperBob2 3y ago
    Not a matter of refactoring. AI should ideally regenerate the code from the spec each time the requirements change. "Programming" won't go away, but it will refer to working with specification languages, not implementation languages. In the best of all possible worlds, you'd have to deal with the C++ or JavaScript code about as often you have to dig into the x86 or ARM assembly code now.
    - lobsterthief 3y ago
      The second you need to do something the AI can’t do, you’ll be trudging through garbage and breaking tons of things in regression (causing either errors or visual bugs). In your scenario, AI will likely produce code that _it_ determines to be maintainable, or if it’s rebuilt each time as you suggest, then it doesn’t need to be maintainable or readable at all. Good code is written for teams, not individuals. It’s written for future you and future people who you will never meet.

geodel 3y ago

Well billions of human beings are living remarkably repetitive and unoriginal life. Doing few categories of work, living in few categories of home, and eating few varieties of food. Same for entertainment, transport and so on. Most people are just running in rather tight loops. Perhaps to start with, one way to have vastly more creativity/diversity of things people do is to have vastly fewer humans on earth.

creeptofashbash 3y ago
[flagged]

seydor 3y ago

Html supports a lot of UI widgets now but everybody keeps reimplementing their own. And because nobody is using them they arent improving so nobody is using them so they arent improving.

lobsterthief 3y ago
It’s because they display—and behave—wildly differently in different browsers. This has been the story of tons of HTML5 “widgets”. I know this isn’t quite a widget, but when something as simple as input type=“number” was introduced, I was excited because it could be used to call up the mobile keyboard for numeric input. (Say for a zip code, which is a common use case). But unfortunately, it can also be changed via your mouse’s scroll wheel, accidentally, so I’m stuck using input type=“tel” for everything. (Do you want to scroll to your zip code?) The problem with these things is you can’t just push out improvements and fixes. Everything has to be backwards-compatible and I feel like they’re never nearly good enough at the beginning.

danenania 3y ago

While I agree at a high level, it's also important to understand that most of these demos are being carefully cherry-picked. If you are just seeing the viral demos on social media, you're going to think AI is further along than it actually is for more complex tasks. People who are non-technical and not using AI in anger to get real work done are going to be the most susceptible to this. Those in the weeds are generally going to have a more nuanced view of the benefits and challenges--i.e. that it's incredibly useful but also very fallible and requires careful hand-holding to get production-ready results. I say all that as an AI optimist. The value is real and the most impressive demos are glimpses of where we're heading. But it's going to take some time before the median result catches up to the hype.

benatkin 3y ago
I think the examples by naysayers of what AI can’t do are often cherry-picked. The way has been shown with the web. Now many people who would have been paying a designer are using things similar to Wix. A lot of people don’t need top of the line custom work, and most custom work isn’t top of the line. I’ve seen AI frequently, but a bit unpredictably, hit the high notes. https://www.joelonsoftware.com/2005/07/25/hitting-the-high-notes/ https://www.joelonsoftware.com/2005/07/25/hitting-the-high-n...
- danenania 3y ago
  You know, that’s a great point! Both the negative and positive outliers can be cherry-picked to misrepresent what working with AI is really like in practice. Some want to pretend it’s much further along than it actually is, while some want to pretend it’s all just a flash-in-the-pan. The truth lies, predictably, in between: it’s useful and it’s real, but it’s not consistent or reliable… yet.
  - KerrAvon 3y ago
    is it a great point? the failure cases will recede as people figure out what to do with it, but right now the failures are extremely numerous.

themagician 3y ago

> how unimpressively repetitive and unoriginal tasks keep being reimplemented by millions of developers worldwide This extends far beyond just developers. This is a majority of all office work, from data entry to accounting to creative work. Most office work is just doing the same thing over and over again, often times with different people repeating what are essentially the same tasks, just at different companies.

deleted 3y ago
[deleted]

titzer 3y ago

It just exposes how stupid our software stacks are. Everything is driven by "well, maybe they'd want to customize this and that and that and three hundred irrelevant details". When in reality all we ever wanted was to separate the functionality from its presentation. Which, incidentally, was exactly the Web we had in 1996 with just bare HTML. Things have gone horribly, horribly wrong in such a mind-bogglingly stupid way and nobody is better for it. Oh but those dropshadows and inner flexboxes or something.

CobrastanJorji 3y ago

In that vein, I wonder if you use these embeddings and compression to work out a new sort of programming language which could extremely concisely represent these concepts. Probably the actual result would be so complex as to be worthless, like code golf languages but worse, but maybe it could help us come up with an interesting new programming language paradigm.

deleted 3y ago

[deleted]