8 ms·

> I don’t think people who make APIs really appreciate how important it is to get them right, and how much unnecessary work their mistakes can cause for hundred

• lockhouse 3y ago
  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).
    • 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.
• marmakoide 3y ago
  In the late 90's, my Dad bought Visual Studio 6 to learn C++. I knew my way around Turbo Pascal, i386 assembler and C/DJGPP on DOS, so I figured I could try to code for Windows, "I am Big Boy now". The Visual Studio 6 box had an introduction book to win32 and MFC ... Nothing made sense to me, a lot of boiler plate code was there without much explanation about why it was there. I just said "nope, life is too short to suffer this", and went back to DOS. Learned Unix system programming at the university, it felt sane and consistent. This introduction to win32 API was so traumatizing, even now, I would not touch it with a barge pole, POSIX or GTFO.
  • physicles 3y ago
    I had a similar experience. I'd been doing C++ for DOS with some x86 assembly for a couple years when I somehow got access to Visual C++ (probably version 5) with MFC. Just getting to Hello World took me a solid week. Eventually I wrapped my head around it, but moved to C#/WinForms as soon as that came out.
    • bergen 3y ago
      Boggled my mind in university that c# was so smooth to get an application running, and the same ideas could not be applied to C++, in basically the same Coding environment. Tried for 4 separate times, always threw the towel.
  • rob74 3y ago
    I tried to switch from Delphi to Visual C++ around the same time, which made me appreciate even more how easy it was to build a GUI app with Delphi as opposed to the way VC++ did it (having a barebones visual designer and other than that forcing you to use all the gnarly APIs directly), how straightforward Object Pascal was compared to C++, and how much faster the compiler was, and decided to just stick with Delphi for the time being. The later .NET IDEs improved the usability quite a bit (thanks Anders Hejlsberg!), but those were for .NET, they didn't generate native code.
    • pjmlp 3y ago
• iamwil 3y ago
  I've always wondered who were the people that were responsible for such terrible Windows APIs. They must have had an axe to grind or followed some ideology. As a kid, I wanted to make games, and just found the win32 API inscrutable. I too lost a couple years.
  • cratermoon 3y ago
    > I've always wondered who were the people that were responsible for such terrible Windows APIs. Charles Simonyi comes to mind.
    • indy 3y ago
      Truly terrible APIs never originate from one mind. Instead they're the result of a whole bureaucracy of people each of whom have to inject their own particular requirements, coding preferences and "what if in the future..." guesses.
      • cratermoon 3y ago
        I dunno. Simonyi invented what became known as Hungarian notation.
        • return_to_monke 3y ago
          A very good article on why Simonyi probably wasn't the one: https://www.joelonsoftware.com/2005/05/11/making-wrong-code-look-wrong/ https://www.joelonsoftware.com/2005/05/11/making-wrong-code-... my verdict is that Simonyi didn't communicate the idea - good otherwise - well enough
          • cratermoon 3y ago
            Oh, yes, I remember reading that while back. As Joel says, "if you write convoluted, dense academic prose nobody will understand it and your ideas will be misinterpreted", which doesn't let Simonyi off the hook completely. As for Apps Hungarian, I was just discussing this the other day on a forum devoted to John Ousterhout's A Philosophy of Software Design. In Chapter 14, "Choosing Names" Ousterhout discusses a case where a variable named 'block' was used in a place where there were both physical and logical blocks, both integer types. His suggestion, which isn't wrong, was to use different variable names for different kinds of blocks, making it possible for a programmer to tell if a logical block variable was being used in some physical block handling code. This is similar to Joel's example of using 'rw' and 'col' prefixes for variables that are both integer types. When I see a convention like this, I ask, "why can't they be different types?". In modern languages you can define new types easily, and define different interfaces or APIs to operate on the types. With 'physicalBlock' and 'logicalBlock' types, or 'row' and 'col' types, programmers can lean on the compiler or interpreter to prevent many errors. Beyond looking wrong to the programmer, the code is wrong, and won't compile or interpret correctly, provided there is a reasonable type system for the language. The obvious concern is a proliferation of types, and yes that can happen when taken to extremes. One area where Joel's example makes a very strong case for types is 'us' and 's'. Strings are handy, but also the wrong abstraction. A 'SafeString' type would very clearly communicate the abstraction at the proper level: the thing in question is not a string, it's a representation of encoded user input. An attempt to assign a SafeString to a plain old string would be an error. Passing a string to a function that declares a SafeString would be an error. There's even a name for using ints and strings when different types would be better: Primitive Obsession. A sign of this obsession would be passing around a user ID and password as strings, and a corrective would be a Credential type that encapsulates both ID and password types, and includes the necessary parsing and validation on creation. This eliminates an entire class of errors much more strongly than a convention where every string that contains a password has a 'pw' prefix, and userID strings are prefixed with 'userid' or just 'id'. Of course, if the language doesn't provide useful typing, then naming conventions are essential. In languages with good type systems, always be asking, "does the language's primitive type really represent the abstraction in use here?"
• deleted 3y ago
  [deleted]
• userbinator 3y ago
  I have the exact opposite experience --- I've been programming in win32 for about as long as it existed, and did win16 before that. There's no better way to make super-efficient single-EXE applications that can run on every version of Windows since Win95 (and if you try a little harder, you can get to Win3.11 with Win32s.) Everything newer has felt far more bloated and complex. That said, some parts of Windows API are horrible; everything COM-related comes to mind.
  • pyeri 3y ago
    Instead of dabbling with the windows API directly, a better option is to use the .NET WinForms API. You can use any CIL language like C# or VB.NET. Granted that it is a framework or toolkit like many others but one of the most efficient and relatively easiest to use that I've found so far. I've tried hello worlds with many other frameworks like Java Swing/AWT/SWT, Python Tkinter/PySide, Electron.js framework, etc. and none came close to WinForms API, especially when it's powered using the super efficient Visual Studio Community Edition.
    • namdnay 3y ago
      Wasnt there an issue with your apps then needing the user to install the “.NET runtime” or something? I remember it being the main reason why people stayed on win32 for so long
      • pyeri 3y ago
        The .NET runtime usually comes pre-installed on all machines above Windows 7. It's just that if your app needs some advanced feature, you need to upgrade runtime version in those cases, this is pretty much how other runtime based systems like Java and Python also work. Most people who stayed with win32 for long were C programmers who preferred the "purist way". But those who wanted developer productivity soon switched to the frameworks of .NET, Java, Python, etc.
        • pjmlp 3y ago
• suzzer99 3y ago
  I had a similar experience with BASIC on the C64 in high school, which set me back about 10 years from becoming a programmer. But on the upside I got a lot out of my system in my 20s, and have never gotten burnt out on programming.
• nvy 3y ago
  Once, I tried to write a GUI program in pure win32, that would have a custom window shape like demoscene intros/warez cracktros. Once.
  • 3dbrows 3y ago
    I’m sure you managed to get the MIDI background music working easily though.
    • deleted 3y ago
      [deleted]
  • sph 3y ago
    Oh God you just stirred a long forgotten memory of my youth. Trying to make custom-shaped windows. I also felt it was unreasonably hard in MFC/Visual C++ to just have a button in a different colour. The RAD system was so barebones compared to what I was used to previously with Visual Basic, and the people in Delphi could make vibrant, colourful GUIs which were a pain in the butt to do in C++. I will always remember Delphi as the cool RAD system that could create beautiful GUIs but the language is a bit ass, so I never took the time to learn it. (I have never liked the feel of Pascal for some reason)
• notduncansmith 3y ago
  Maybe ironic but I wouldn’t be where I am without Windows APIs. I was 19, and I was a member of some forums where folks shared knowledge on how to (ab)use various technologies for profit; many of these technologies were Web-based. I didn’t know any Web programming, but I knew VB.NET from some community college courses (with some fundamentals from high school) and I figured out how to drive this browser and interact with pages. This allowed me to automate various Web interactions and make a few bucks writing code, which eventually led to my current career as a professional software developer. I was getting paid (not much lol) to build apps before I knew either of brands like “port” but I hope that, no matter how much money is in the table, y’all feel good about every deal! Respect
• arc-in-space 3y ago
  Same here. Trying to write something using win32 as a ~14yo made me feel like an absolute worthless idiot and I just didn't touch code for 2-3 years.
• kalleboo 3y ago
  I'm convinced that the only reason I got into programming is because my first exposure to it was via HyperCard, which is still just the most friendly and enticing introduction to programming I've even seen.
• robertlagrant 3y ago
  I remember trying some Win32 stuff in the early 2000s and being gently ribbed in a chat room for not knowing what a message pump was. At the time I was thinking I was so junior, I didn't even know what something so commonplace was. Now... not so much.
• mschaef 3y ago
  > When I was a kid I tried to build a windows app. Getting a notepad clone even kind of close was a triumph for me, I remember having similar struggles. Windows programming was a huge lift. Not only were there new API's to learn, it was really an entirely different and novel architectural style. Kerry Nietz writes about the experience of porting FoxPro from DOS to Windows... his description is apt: "Turn the program inside-out". For me, that was hard to do at a time when I was still working through how to make a normal program.
• blarg1 3y ago
  I still remember thinking how weird all the windows stuff was when I was a kid. Not just the windows api, but weird stuff like mfc.
• analog31 3y ago
  HyperCard, visual basic, and Python have saved me from ever needing to understand OS innards.
• datavirtue 3y ago
  Constantly reminded of this every time I see any Win32 API code. Horrid names kept me away from native windows development as a kid. They didn't make any sense to me, which I found very aggravating. Having 30yrs under my belt has only convinced me more of how horrible that shit is.
• phantom784 3y ago
  When teaching myself as a kid, I quickly realized that win32 was way over my head. However, web stuff seemed easy enough, so I started teaching myself web development instead. This was in the early 2000s, before everything started moving to web applications. It certainly managed to pay off! I never did learn win32...
  • cmg 3y ago
    This was also me as a kid with the Mac - we got our first home computer in 1993. Pascal? WindowPtr? Compilers? Yikes - I'm only 9 years old! I'd done some QBasic and Logo at school but couldn't wrap my head around the 'abstract' GUI stuff: If I tell the turtle to go Forward, it goes forward... Then I discovered HTML - much easier to wrap my head around at the time.