5 ms·

As a kid, I noped right out of raw Win32 API and reached for MFC instead. It made writing Windows applications so much easier.

paulryanrogers 3y ago
MFC felt pretty awkward to me, though I was introduced to it after Swing and C. I suppose it's all matter of perspectives and preferences.
user3939382 3y ago
I looked at WPF a few users ago and my impression was, I could spend 2 hours doing something I could easily do in the browser in 15 minutes. Maybe it's not that bad once you get the hang of it, but it looked so arduous I immediately decided I didn't have the will to go farther.
- eternityforest 3y ago
  As far as I'm concerned the only easy UI is a declarative reactive UI. Vue and to a degree Flutter make everything look hard
  - worthless-trash 3y ago
    What is an example of this? (non ui programmer here).
    - eternityforest 3y ago
      https://vuejs.org/guide/quick-start.html https://vuejs.org/guide/quick-start.html The "Global build" section shows off how easy it can be the best. More complicated stuff with modules might be harder especially when dealing with NPM build stuff, but it's generally pretty nice.
    - deaddodo 3y ago
      The simple distinction is this (using abstract examples): * Declarative: here is a UI that I designed ahead of time. I've set up these controls with these hooks. Your logic then plugs into my UI independent of it's design. (When myBtn is clicked, it fires MyCode::MyBtn() in your code). * Imperative: here is my main.c. In my main(), I call a function createWindow and then createButton with various parameters (size, text caption, styling, etc) that returns a handle to the widget/window. I give a callback to my widgets. When that button is clicked, the callback is fired. I can call a function called destroyWidget with that handle and erase it. Or, to simplify solely to definitions: in declarative UI, I create (or declare) the UI ahead of time and hook it into my logic. In imperative UI, the UI is rendered as requested (an imperative). The definitions are directly orthogonal to imperative vs declarative programming, in general. As to "reactive", this is an independent descriptor that simply means that the UI adjusts to it's environment. It's usually used in the context of Web or mobile devices, since an Android app that appeared the same on Phones and Tablets would offer a subpar experience for users on one or the other.
      - lelanthran 3y ago
        Which approach is "better" varies, though. Given an imperative UI and a small amount of time (depending on the surface area of the API) I can create a declarative interface to it. I cannot do the reverse given a declarative UI. My observation of declarative UIs is that, sooner or later, due to necessity, they tend towards the inclusion of imperative elements ("If we are running as Super-User, then $FOO must be a button, else it must be a link to a page requesting Super-User privileges"). At the end the "declarative" UI is declarative for only the most trivial usages. Any non-trivial usage includes hacks or workarounds to implement conditional elements, loops (for collections of elements) and subcomponent specialisation (for element reuse).
        deaddodo 3y ago
        Sure, which is why it's most popular among software with minimal UI (gamedev being a prime example).
        zogrodea 3y ago
  - fiddlerwoaroof 3y ago
    I have the opposite experience: I learned to program with Delphi, and all the React libraries feel like hard, slow ways to make stuff I'd make in five minutes in Delphi.
    - whstl 3y ago
      Were you wiring up the UI by yourself with imperative code, or were you using Delphi's form editor (or whatever it was called)? Because GP is criticizing Win32-style imperative UI code... and this is exactly what Delphi saves you from.
      - fiddlerwoaroof 3y ago
        Describing GUIs in text should have been left in the 90s but I haven’t seen a better code paradigm for GUI behavior specification than VCL-style OOP.
    - datavirtue 3y ago
      Yeah,we had this all figured out decades ago and then the web through in a monkey wrench that we never recovered from. From a webdev point of view I love Vue...but it is a slow hard way to build UIs compared to Visual Basic, Delphi, or Swing.
- fomine3 3y ago
  To be fair, making an app in 2008 (when WPF released) with JS was a completely mess. WPF was usable and they introduced data binding/MVVM. In 2018 (React/Redux), it's fair that JS seems to be advanced vs WPF. Though its productivity isn't so bad (unless you want to fully customize everything).
  - ufmace 3y ago
    Also on "to be fair", JS libs have a nasty habit of either completely redoing the API, or dropping maintenance entirely and encouraging everyone to switch to the new hotness which also has a completely different API, every 6 months or so. It's a lot easier to have a nice API if you get to rewrite it on a whim and tell anyone who doesn't like it to fork off. WPF may be weird and messy, but your app will still work unchanged even now (well I think, haven't used it in a while).
- deaddodo 3y ago
  I don't even get this arduousness argument. A barebones WinMain is extremely long-winded (what causes most people to "nope out"), certainly, but once you get passed that it's fairly consistent and the API calls reasonably formed. I don't think it's an example of a perfect API, but the concepts and functionality of it mean once you learn the basics of it (handles, resources, parentage, text encoding, type annotation, etc) they apply to any other widget you'll implement, from legacy ones all the way back in 1993 to modern ones introduced in Windows 7+.
GuB-42 3y ago
For me it was the opposite. Raw Win32 is low level: you manipulate the event loop directly, and you have to deal with the layout yourself, but otherwise rather simple. MFC had a mix of generated code and handwritten code. Writing MFC code by hand was hell, and using a graphical IDE was nowhere as convenient as Visual Basic or anything by Borland.

paulryanrogers 3y ago

MFC felt pretty awkward to me, though I was introduced to it after Swing and C. I suppose it's all matter of perspectives and preferences.

user3939382 3y ago

I looked at WPF a few users ago and my impression was, I could spend 2 hours doing something I could easily do in the browser in 15 minutes. Maybe it's not that bad once you get the hang of it, but it looked so arduous I immediately decided I didn't have the will to go farther.

eternityforest 3y ago
As far as I'm concerned the only easy UI is a declarative reactive UI. Vue and to a degree Flutter make everything look hard
- worthless-trash 3y ago
  What is an example of this? (non ui programmer here).
  - eternityforest 3y ago
    https://vuejs.org/guide/quick-start.html https://vuejs.org/guide/quick-start.html The "Global build" section shows off how easy it can be the best. More complicated stuff with modules might be harder especially when dealing with NPM build stuff, but it's generally pretty nice.
  - deaddodo 3y ago
    The simple distinction is this (using abstract examples): * Declarative: here is a UI that I designed ahead of time. I've set up these controls with these hooks. Your logic then plugs into my UI independent of it's design. (When myBtn is clicked, it fires MyCode::MyBtn() in your code). * Imperative: here is my main.c. In my main(), I call a function createWindow and then createButton with various parameters (size, text caption, styling, etc) that returns a handle to the widget/window. I give a callback to my widgets. When that button is clicked, the callback is fired. I can call a function called destroyWidget with that handle and erase it. Or, to simplify solely to definitions: in declarative UI, I create (or declare) the UI ahead of time and hook it into my logic. In imperative UI, the UI is rendered as requested (an imperative). The definitions are directly orthogonal to imperative vs declarative programming, in general. As to "reactive", this is an independent descriptor that simply means that the UI adjusts to it's environment. It's usually used in the context of Web or mobile devices, since an Android app that appeared the same on Phones and Tablets would offer a subpar experience for users on one or the other.
    - lelanthran 3y ago
      Which approach is "better" varies, though. Given an imperative UI and a small amount of time (depending on the surface area of the API) I can create a declarative interface to it. I cannot do the reverse given a declarative UI. My observation of declarative UIs is that, sooner or later, due to necessity, they tend towards the inclusion of imperative elements ("If we are running as Super-User, then $FOO must be a button, else it must be a link to a page requesting Super-User privileges"). At the end the "declarative" UI is declarative for only the most trivial usages. Any non-trivial usage includes hacks or workarounds to implement conditional elements, loops (for collections of elements) and subcomponent specialisation (for element reuse).
      - deaddodo 3y ago
        Sure, which is why it's most popular among software with minimal UI (gamedev being a prime example).
      - zogrodea 3y ago
- fiddlerwoaroof 3y ago
  I have the opposite experience: I learned to program with Delphi, and all the React libraries feel like hard, slow ways to make stuff I'd make in five minutes in Delphi.
  - whstl 3y ago
    Were you wiring up the UI by yourself with imperative code, or were you using Delphi's form editor (or whatever it was called)? Because GP is criticizing Win32-style imperative UI code... and this is exactly what Delphi saves you from.
    - fiddlerwoaroof 3y ago
      Describing GUIs in text should have been left in the 90s but I haven’t seen a better code paradigm for GUI behavior specification than VCL-style OOP.
  - datavirtue 3y ago
    Yeah,we had this all figured out decades ago and then the web through in a monkey wrench that we never recovered from. From a webdev point of view I love Vue...but it is a slow hard way to build UIs compared to Visual Basic, Delphi, or Swing.
fomine3 3y ago
To be fair, making an app in 2008 (when WPF released) with JS was a completely mess. WPF was usable and they introduced data binding/MVVM. In 2018 (React/Redux), it's fair that JS seems to be advanced vs WPF. Though its productivity isn't so bad (unless you want to fully customize everything).
- ufmace 3y ago
  Also on "to be fair", JS libs have a nasty habit of either completely redoing the API, or dropping maintenance entirely and encouraging everyone to switch to the new hotness which also has a completely different API, every 6 months or so. It's a lot easier to have a nice API if you get to rewrite it on a whim and tell anyone who doesn't like it to fork off. WPF may be weird and messy, but your app will still work unchanged even now (well I think, haven't used it in a while).
deaddodo 3y ago
I don't even get this arduousness argument. A barebones WinMain is extremely long-winded (what causes most people to "nope out"), certainly, but once you get passed that it's fairly consistent and the API calls reasonably formed. I don't think it's an example of a perfect API, but the concepts and functionality of it mean once you learn the basics of it (handles, resources, parentage, text encoding, type annotation, etc) they apply to any other widget you'll implement, from legacy ones all the way back in 1993 to modern ones introduced in Windows 7+.

GuB-42 3y ago

For me it was the opposite. Raw Win32 is low level: you manipulate the event loop directly, and you have to deal with the layout yourself, but otherwise rather simple. MFC had a mix of generated code and handwritten code. Writing MFC code by hand was hell, and using a graphical IDE was nowhere as convenient as Visual Basic or anything by Borland.