12 ms·

Still Delphi was better. - DSL for UI (Forms) - fast native compiler that produced self sufficient binaries - great component library and many open source lib

by vrodic 5y ago

Still Delphi was better. - DSL for UI (Forms) - fast native compiler that produced self sufficient binaries - great component library and many open source libraries - Object Pascal was extended to fit perfectly the needs of UI programming

nawgz 5y ago
Building things that have no real-world constraints does often result in great beauty. Unfortunately, the web and all its ugliness became the dominant platform because it enabled no-download no-install information & application interaction
- cosmodisk 5y ago
  It was probably 20 or so years ago when I played for some time with Delphi. It was extraordinary easy to make program interfaces. Fast forward to today and we are in this clusterfuck, where everyone keeps reinventing the wheel and complexities just keep growing.
  - ohgodplsno 5y ago
    In the same way that Visual Basic offered simple, drag & drop interface builders. What happened is also changing hardware, UIs that need to adapt to changing screen sizes, different needs, theming, and many more.
    - pjc50 5y ago
      Everyone seemingly unaware that this still exists and you can still do it in Hejlsberg's C#? Drag and drop WPF components and program in code-behind? With themes and responsive design? (Big asterisk: mostly Windows-only and has recently lost product direction coherency)
      - cosmodisk 5y ago
        Windows forms are great, whilst WPF is a bit odd,to say the least.. Here's an example: https://docs.microsoft.com/en-us/visualstudio/get-started/csharp/tutorial-wpf?view=vs-2022 https://docs.microsoft.com/en-us/visualstudio/get-started/cs...
        the_only_law 5y ago
        I would almost like WOF is component styling wasn’t one of the most miserable clusterfucks of XML boilerplate I’ve used.
      - mbreese 5y ago
        My biggest problem with the drag and drop builders was how it played with version control. The last I used was nearly 20 years ago - Windows Visual Studio C++ with MFC. Even if the builder produced C++ code, it was hard to know exactly where and how the changes were made. CVS (and maybe svn?) didn’t exactly like tracking those changes. Is that any better now?
        fiddlerwoaroof 5y ago
        One thing I really liked about Delphi was its strict separation between generated and manually-written code. Delphi had a dedicated text file format that represented the form built in the GUI builder. So, VC would just pick up changes in the form file and save them like anything else.
      - ohgodplsno 5y ago
        WinForms still exists and is fine for the odd quick utility. Doing WPF without ever having to drop in the XAML is... unlikely to say the least. You're going to end up in there are one point, because styles are fucking you over or for some other reason (databinding? lol). But yes, C# is still keeping the drag & drop alive. So are plenty of tools (Lazarus, hell even Android Studio has a drag & drop designer).
      - nostrademons 5y ago
        Also Android Studio, XCode, all the React builder websites, etc. Basically every GUI platform + IDE has some form of a drag & drop interface builder. The problem is that outside of the iOS ecosystem, there are too many subtle differences in behavior to really trust the results. And because a lot of software gets worldwide distribution these days, it's economically worth it to squeeze that last bit of performance & user friendliness out of the framework. So most professional programmers learn how to do things programmatically and only use the interface builder if they're doing a quick internal tool.
    - dmitriid 5y ago
      > UIs that need to adapt to changing screen sizes, different needs, theming, and many more. People keep saying that as if that is this new thing that wasn't ever heard of before the web or smartphones. Open any desktop app and resize it. Boom, you've got "changing screen sizes". And yeah, "needs are different, and we need theming is this new thing that never existed before the iPhone ".
      - nawgz 5y ago
        I think forced aspect ratio was very common in the era of these oldschool UI toolkits. Additionally, handling multiple classes of pixel density and input (touch vs mouse) was unheard of.
    - Pxtl 5y ago
      Making resolution-agnostic applications in C# Winforms wasn't hard, it was a simple flag to tell the OS how to scale the GUI. And if you used the native widgets and set tab-indexes you'd be all set for changing sizes, blind users, OS re-theming, etc. A good UI framework should handle that stuff internally... even a bad one should do that (bad, like how winforms set the wrong default font). Imho, the real reason we don't see stuff like this for the Web is that the web isn't designed for modularity. CSS, Javascript, and HTML IDs are all global. Programming 101 lesson 1 is "don't use globals" and the Web is the perfect object-lesson in why not.
      - rhengles 5y ago
        CSS - Yes. JS - Not since 2015, I'll admit that is somewhat recent. HTML IDs - IDs are only good if they're unique. Since HTML had no notion of scope, they became global. Shadow DOM is the web platform answer for modularization, however any JS framework will allow you to slice your CSS and HTML in components.
      - nawgz 5y ago
        > if you used the native widgets and set tab-indexes you'd be all set for changing sizes, blind users, OS re-theming, etc > Imho, the real reason we don't see stuff like this for the Web Where are you looking on the web? tab-indexes and extending native web components gives you responsiveness and accessibility. The browsers provide theming capabilities for light and dark mode, and OS level color preferences (I use "red" for selected on Mac) easily show themselves on CSS `outline` etc > Globals No one uses globals on the web. This isn't 2000, or even 2013.
  - throwawayboise 5y ago
    Yeah I feel that in a way, the best time to be a developer was back in the 1980s/90s. Your tools were limited but those constraints took away a lot of the "overhead" thinking about what frameworks to use and you could just focus on functionality. You didn't have Google or StackOverflow, but had a few books on your desk that covered pretty much everything you needed to know. Or if you were working on Unix, you had man pages, K&R, and Kernigan and Pike's The UNIX Programming Environment
    - jhoechtl 5y ago
      The reason was you weren't competing with the world class. Programming was great because you could be a local hero. Now everyone strives to make as beautiful websites as <insert big blue with their genius web framework>
    - RantyDave 5y ago
      We also didn't have security issues, which helped.
  - nawgz 5y ago
    > Fast forward to today and we are in this clusterfuck, where everyone keeps reinventing the wheel and complexities just keep growing Yes, it is quite funny to see how no toolkit exists to simply produce Web UIs in a meaningful way. However, the complexity has grown largely from externalities that didn't exist during the time of effortless interface builders, which is screen sizes and aspect ratios and pixel densities of all sorts. To handle this, you need to have some lower level primitives, and of course any time you have to go to a lower level you surface more complexity. Final point - as a person who develops web UIs professionally for 7 years now, I think that the "reinventing the wheel" has been actually quite beneficial to tame this complexity. Previously, untyped JS had to be bent into surfacing type-style error messages, and good luck with boundary crossing data. Now, TypeScript lets you describe every key in your application and have incredible confidence that a fully-typed piece of UI or logic (which of course must avoid `any`) will deliver exactly what you intended. GraphQL & codegen has given us the ability to type our boundary crossing data straight from our DB or resolvers without any runtime reflection. Runtime reflection tools like io-ts also bridge that gap admirably to program defensively in the situations it's needed. It's obviously been accompanied by a lot of churn, but with strictly typed component libraries, a bit of reusable layout logic, and Hasura, I can make sexy fully-themable UIs strictly typed all the way to and from the data source without significant effort. The complexity in my new paradigm is entirely in application-level tricks like UIs visually informing users of all the async actions, animations / transitions, avoiding dynamic content causing bad layout blips, and ensuring user input is never lost. I think this kind of thing wouldn't have been easy in any oldschool toolkit because it inherently requires some wiring that isn't easy to surface
  - edgriebel 5y ago
    > where everyone keeps reinventing the wheel and complexities just keep growing Cue XKCD "Standards" comic. People look at an existing framework and declare "this is total shit, I can build a better, easier to use version!" They then start building the better-easier and realize why the old version is so hard to use--because it's a difficult fucking problem begetting awful complexity + shitty code. This repeats itself every 18-24 months, giving us the current clusterfuck of JavaScript libraries. Lather, rinse, repeat for the past 30 years (n.b. XWindows Athena -> Xt -> Motif/Lesstif -> ...<aeons pass>... -> Qt -> Electron)
- beamatronic 5y ago
  But in today's reality, there is a lot of Javascript that is getting "downloaded and installed" into your browser's cache. It's all being managed for you and it mostly works.
  - nawgz 5y ago
    Please, you must not be pedantic in this way, it's clear that I mean there's no install wizard and OS-native interactions the user must go thru, they just provide a string URL and immediately begin application-style interactions after a brief load
    - beamatronic 5y ago
      Compare and contrast today's Javascript-in-browser dependent applications versus a pure server-side-rendering model. With the latter, there is truly no software downloaded, only static assets such as images.
    - DarylZero 5y ago
      It's not really pedantic. Since any application (not just a browser) could provide the same download-interpreted-code-then-run-it functionality. It's probably not this particular feature of the web browser matters but the fact that web browsers come preinstalled with new computers.
      - nawgz 5y ago
        > It's not really pedantic I mean, if not pedantic, then perhaps grinding an axe - he said 'there is a lot of Javascript that is getting "downloaded and installed"' as if that has anything to do with the user experience I was referring to > any application (not just a browser) could provide the same download-interpreted-code-then-run-it functionality I have never heard of such a platform besides the web. That is why the web became the dominant platform. I do not know what theoretical could've would've should've has to do with the reality of technological evolution > It's probably not this particular feature of the web browser ... yes, it's not the ease of use that makes users like web, it's that computers in 2021 come with browsers installed that makes users prefer web over bloated desktop applications without good accessibility anyways! I have no clue what your comment is meaning to get at.
- DarylZero 5y ago
  The user downloads a browser that downloads the site-specific javascript application.
k__ 5y ago
It was the pinnacle of an era that was gone with the rise of the Internet.
- ldng 5y ago
  That does not diminish the accomplishment in my eyes.
  - k__ 5y ago
    It doesn't, but that doesn't help us now. See Flash.

by vrodic 5y ago

nawgz 5y ago

Building things that have no real-world constraints does often result in great beauty. Unfortunately, the web and all its ugliness became the dominant platform because it enabled no-download no-install information & application interaction

cosmodisk 5y ago
It was probably 20 or so years ago when I played for some time with Delphi. It was extraordinary easy to make program interfaces. Fast forward to today and we are in this clusterfuck, where everyone keeps reinventing the wheel and complexities just keep growing.
- ohgodplsno 5y ago
  In the same way that Visual Basic offered simple, drag & drop interface builders. What happened is also changing hardware, UIs that need to adapt to changing screen sizes, different needs, theming, and many more.
  - pjc50 5y ago
    Everyone seemingly unaware that this still exists and you can still do it in Hejlsberg's C#? Drag and drop WPF components and program in code-behind? With themes and responsive design? (Big asterisk: mostly Windows-only and has recently lost product direction coherency)
    - cosmodisk 5y ago
      Windows forms are great, whilst WPF is a bit odd,to say the least.. Here's an example: https://docs.microsoft.com/en-us/visualstudio/get-started/csharp/tutorial-wpf?view=vs-2022 https://docs.microsoft.com/en-us/visualstudio/get-started/cs...
      - the_only_law 5y ago
        I would almost like WOF is component styling wasn’t one of the most miserable clusterfucks of XML boilerplate I’ve used.
    - mbreese 5y ago
      My biggest problem with the drag and drop builders was how it played with version control. The last I used was nearly 20 years ago - Windows Visual Studio C++ with MFC. Even if the builder produced C++ code, it was hard to know exactly where and how the changes were made. CVS (and maybe svn?) didn’t exactly like tracking those changes. Is that any better now?
      - fiddlerwoaroof 5y ago
        One thing I really liked about Delphi was its strict separation between generated and manually-written code. Delphi had a dedicated text file format that represented the form built in the GUI builder. So, VC would just pick up changes in the form file and save them like anything else.
    - ohgodplsno 5y ago
      WinForms still exists and is fine for the odd quick utility. Doing WPF without ever having to drop in the XAML is... unlikely to say the least. You're going to end up in there are one point, because styles are fucking you over or for some other reason (databinding? lol). But yes, C# is still keeping the drag & drop alive. So are plenty of tools (Lazarus, hell even Android Studio has a drag & drop designer).
    - nostrademons 5y ago
      Also Android Studio, XCode, all the React builder websites, etc. Basically every GUI platform + IDE has some form of a drag & drop interface builder. The problem is that outside of the iOS ecosystem, there are too many subtle differences in behavior to really trust the results. And because a lot of software gets worldwide distribution these days, it's economically worth it to squeeze that last bit of performance & user friendliness out of the framework. So most professional programmers learn how to do things programmatically and only use the interface builder if they're doing a quick internal tool.
  - dmitriid 5y ago
    > UIs that need to adapt to changing screen sizes, different needs, theming, and many more. People keep saying that as if that is this new thing that wasn't ever heard of before the web or smartphones. Open any desktop app and resize it. Boom, you've got "changing screen sizes". And yeah, "needs are different, and we need theming is this new thing that never existed before the iPhone ".
    - nawgz 5y ago
      I think forced aspect ratio was very common in the era of these oldschool UI toolkits. Additionally, handling multiple classes of pixel density and input (touch vs mouse) was unheard of.
  - Pxtl 5y ago
    Making resolution-agnostic applications in C# Winforms wasn't hard, it was a simple flag to tell the OS how to scale the GUI. And if you used the native widgets and set tab-indexes you'd be all set for changing sizes, blind users, OS re-theming, etc. A good UI framework should handle that stuff internally... even a bad one should do that (bad, like how winforms set the wrong default font). Imho, the real reason we don't see stuff like this for the Web is that the web isn't designed for modularity. CSS, Javascript, and HTML IDs are all global. Programming 101 lesson 1 is "don't use globals" and the Web is the perfect object-lesson in why not.
    - rhengles 5y ago
      CSS - Yes. JS - Not since 2015, I'll admit that is somewhat recent. HTML IDs - IDs are only good if they're unique. Since HTML had no notion of scope, they became global. Shadow DOM is the web platform answer for modularization, however any JS framework will allow you to slice your CSS and HTML in components.
    - nawgz 5y ago
      > if you used the native widgets and set tab-indexes you'd be all set for changing sizes, blind users, OS re-theming, etc > Imho, the real reason we don't see stuff like this for the Web Where are you looking on the web? tab-indexes and extending native web components gives you responsiveness and accessibility. The browsers provide theming capabilities for light and dark mode, and OS level color preferences (I use "red" for selected on Mac) easily show themselves on CSS `outline` etc > Globals No one uses globals on the web. This isn't 2000, or even 2013.
- throwawayboise 5y ago
  Yeah I feel that in a way, the best time to be a developer was back in the 1980s/90s. Your tools were limited but those constraints took away a lot of the "overhead" thinking about what frameworks to use and you could just focus on functionality. You didn't have Google or StackOverflow, but had a few books on your desk that covered pretty much everything you needed to know. Or if you were working on Unix, you had man pages, K&R, and Kernigan and Pike's The UNIX Programming Environment
  - jhoechtl 5y ago
    The reason was you weren't competing with the world class. Programming was great because you could be a local hero. Now everyone strives to make as beautiful websites as <insert big blue with their genius web framework>
  - RantyDave 5y ago
    We also didn't have security issues, which helped.
- nawgz 5y ago
  > Fast forward to today and we are in this clusterfuck, where everyone keeps reinventing the wheel and complexities just keep growing Yes, it is quite funny to see how no toolkit exists to simply produce Web UIs in a meaningful way. However, the complexity has grown largely from externalities that didn't exist during the time of effortless interface builders, which is screen sizes and aspect ratios and pixel densities of all sorts. To handle this, you need to have some lower level primitives, and of course any time you have to go to a lower level you surface more complexity. Final point - as a person who develops web UIs professionally for 7 years now, I think that the "reinventing the wheel" has been actually quite beneficial to tame this complexity. Previously, untyped JS had to be bent into surfacing type-style error messages, and good luck with boundary crossing data. Now, TypeScript lets you describe every key in your application and have incredible confidence that a fully-typed piece of UI or logic (which of course must avoid `any`) will deliver exactly what you intended. GraphQL & codegen has given us the ability to type our boundary crossing data straight from our DB or resolvers without any runtime reflection. Runtime reflection tools like io-ts also bridge that gap admirably to program defensively in the situations it's needed. It's obviously been accompanied by a lot of churn, but with strictly typed component libraries, a bit of reusable layout logic, and Hasura, I can make sexy fully-themable UIs strictly typed all the way to and from the data source without significant effort. The complexity in my new paradigm is entirely in application-level tricks like UIs visually informing users of all the async actions, animations / transitions, avoiding dynamic content causing bad layout blips, and ensuring user input is never lost. I think this kind of thing wouldn't have been easy in any oldschool toolkit because it inherently requires some wiring that isn't easy to surface
- edgriebel 5y ago
  > where everyone keeps reinventing the wheel and complexities just keep growing Cue XKCD "Standards" comic. People look at an existing framework and declare "this is total shit, I can build a better, easier to use version!" They then start building the better-easier and realize why the old version is so hard to use--because it's a difficult fucking problem begetting awful complexity + shitty code. This repeats itself every 18-24 months, giving us the current clusterfuck of JavaScript libraries. Lather, rinse, repeat for the past 30 years (n.b. XWindows Athena -> Xt -> Motif/Lesstif -> ...<aeons pass>... -> Qt -> Electron)
beamatronic 5y ago
But in today's reality, there is a lot of Javascript that is getting "downloaded and installed" into your browser's cache. It's all being managed for you and it mostly works.
- nawgz 5y ago
  Please, you must not be pedantic in this way, it's clear that I mean there's no install wizard and OS-native interactions the user must go thru, they just provide a string URL and immediately begin application-style interactions after a brief load
  - beamatronic 5y ago
    Compare and contrast today's Javascript-in-browser dependent applications versus a pure server-side-rendering model. With the latter, there is truly no software downloaded, only static assets such as images.
  - DarylZero 5y ago
    It's not really pedantic. Since any application (not just a browser) could provide the same download-interpreted-code-then-run-it functionality. It's probably not this particular feature of the web browser matters but the fact that web browsers come preinstalled with new computers.
    - nawgz 5y ago
      > It's not really pedantic I mean, if not pedantic, then perhaps grinding an axe - he said 'there is a lot of Javascript that is getting "downloaded and installed"' as if that has anything to do with the user experience I was referring to > any application (not just a browser) could provide the same download-interpreted-code-then-run-it functionality I have never heard of such a platform besides the web. That is why the web became the dominant platform. I do not know what theoretical could've would've should've has to do with the reality of technological evolution > It's probably not this particular feature of the web browser ... yes, it's not the ease of use that makes users like web, it's that computers in 2021 come with browsers installed that makes users prefer web over bloated desktop applications without good accessibility anyways! I have no clue what your comment is meaning to get at.
DarylZero 5y ago
The user downloads a browser that downloads the site-specific javascript application.

k__ 5y ago

It was the pinnacle of an era that was gone with the rise of the Internet.

ldng 5y ago
That does not diminish the accomplishment in my eyes.
- k__ 5y ago
  It doesn't, but that doesn't help us now. See Flash.