Hacker News Reader

Comment by user____name | Hacker News Reader

I feel like I'm the only person in the world who would rather write ugly win32 jank for the rest of my days than ever having to touch an "elegant" or "well structured" Cocoa codebase. In win32 if you want a button you call a function and pass a hande, in the Apple world you first subclass 7 interfaces in some unreadable Smalltalk-wannabe syntax and pray you don't need to access the documentation. And of course they constantly change things because breaking backwards compatibility is Apple's kink.

View on HN

After bouncing around GUI toolkits (from win32 to SwiftUI) and web for 30 years I have simply run out of fucks. They all suck. Each in their own unique way. Apple aren't worth singling out - they are just their own special isolated variant of it.

But, why? It's been 30 years. You'd think somebody would have figured out how to make a decent GUI toolkit or framework.

We just built layers of shit over the ones we have.

They generally get the design right after some mistakes and are stabilizing it, when the new UI designers take over and want to re-do it from scratch.

Have you tried WinForms? It isn’t the latest hotness so Microsoft has to be dragged kicking and screaming to support it in current VS, but they were forced to do so because corporate developers still have some clout.

I still think that WPF was the peak desktop UI framework. Extremely powerful with lots of small composable primitives, can easily do declarative but drop into more traditional event-driven imperative style where it makes sense.

I live in a bizarro universe where I started my career working on an expansive WPF desktop app on .NET Framework 4.0, and am still working on it now on .NET 10. From my perspective it's been WPF the entire time, and it's been pretty okay.

That's actually pretty close to my own career as well.

Similarly, I've been doing It development for pretty much the entirety of my career. When I see the struggles to make remotely useable apps in other frameworks I'm very happy I chose this path

I recall there used to be a problem if you edited a (win)form in Visual Studio on a computer that didn't have the DPI set to 100% - did they fix that?

The work around was 'simply' to switch to 100% DPI scaling before opening Visual Studio. On my macBook Pro built-in monitor, this was not cool.

AvaloniaUI + MVVM toolkit.

I have no complaints using Qt for cross-platform development, it has been paying my bills for the last 15+ years.

Tcl/Tk is pretty good in terms of rapid development. Unfortunately it has stagnated quite a lot over the years.

Gtk on the other hand is absolutely terrible and its developers don't help by completely rewriting things every few years and breaking all existing code in the process.

Tcl/Tk was also popular in certain niche products, like in RF test equipment.

It's still quite big in EDA (electronic design software).

This is patently false. To add a button to your UI, you open your window’s nib file Xcode/Interface Builder, click the plus button on the toolbar, and add a button. Then you control-drag from the button to File’s Owner and choose the method that you want to invoke when the button is clicked. Done.

And this already worked in OPENSTEP, like 30 years ago.

Programming with GUIs?

Why wouldn't you program a GUI with a GUI if one is available? Avoiding the use of WYSIWYG editors when making GUIs is like avoiding the use of musical instruments when writing songs.

Visual Studio and XCode are way, way overkill for most software and eventually constraining for bigger projects too.

I'm not saying you should never program with a GUI, but it comes at a cost of being able to read the code and tell what the result of the code will be, and all the associated benefits of version control and code reviews that you lose.

And as a side-effect of that, merge conflicts become murder when your "Fix right-hand margins" commit with a 20 line readable +/- diff instead becomes a 1000 line +/- diff.

The one time I built an iOS app using the xCode IB so that I could get up to speed more quickly, I really came to regret it several years into the project.

If this is a real issue, it seems to be an issue with the way a particular toolkit handles visual WYSIWYG editors. Lazarus serializes the object properties into a simple and readable text format that follows the class declarations themselves and you can easily diff them. E.g. here is the diff of a minor change i did (added a new button in a panel with an event handler and modified a property in an existing button):

https://i.imgur.com/aHMHqSc.png

Handling merges (and other VCS functions) is also simple since you can edit the file manually if needed.

I swear I meant to write an "often" in my previous post. But yeah, that was largely directed at the interface builder in xCode, for iOS - it gives you storyboard/xib files that are effectively-not-human-editable (and entirely non-mergeable) xml.

> Why wouldn't you program a GUI with a GUI if one is available? Avoiding the use of WYSIWYG editors when making GUIs is like avoiding the use of musical instruments when writing songs.

I've been a developer for a long time; I've built pretty large applications in all sorts of technologies and I now just prefer defining GUIs using text. Having a live GUI preview is great but actually dragging and dropping stuff is not more efficient to me.

To fit your analogy, using source code is like writing a song using musical notation. I'll write the song, then play it, and then go back to notation to fix it or expand on it.

I would say having a good hot reload system gives you the benefit of wysiwyg with more readable code

> Avoiding the use of WYSIWYG editors when making GUIs is like avoiding the use of musical instruments when writing songs.

And yet, most songwriters write the song, they don't record themselves playing notes.

I encourage you to listen to the Song Exploder podcast to learn about how songwriters write songs.

In my experience drag-and-drop GUI editors work great until you add the constraint that the window has to be resizeable. Then it becomes a mess of clicking through dialogs for every UI element to make sure the anchoring and display flow is set up correctly, and you often have to go back and redo this whenever you add a new element or change the layout of the form. I think the best GUI programming experience I've ever had is on Palm OS simply because it had the constraint that every program always displayed in fullscreen at 160x160 (pixel-doubled to 320x320 on later devices) so you never had to deal with resizeable windows.

Yes, generations of Mac and Windows programmers have used GUIs to create their GUIs. Visual Basic, MFC + App Studio, .NET + WinForms, Interface Builder…

Given that the initial comment was complaining about a status quo, citing a status quo is an odd defense.

That feels like quite the exaggeration. If all you want is a button, all you need to do is initialize an NSButton and then tweak a few properties to customize it as desired.

If you want something more custom, subclass NSControl and you’re off to the races.

And if Obj-C isn’t your cup of tea, one can use Swift instead, even in a codebase that had been only Obj-C prior.

You can now use SwiftUI, which is, as of the latest version, quite stable. They used to change things a lot between releases a few years ago, but nowadays you don't need to refactor your code every year. Only issue with it is that it's iOS first, so you may need to fallback to AppKit (Cocoa) to implement more complex elements.

> as of the latest version, quite stable

Until the next latest version?

Sorry, but this is simply just misinformation.

If you were doing "classic" Cocoa in the way it was intended, you wouldn't need to subclass anything for a simple button.

You wouldn't even need to write a single line of code, you'd just instantiate said button in Interface Builder, hook it up to a delegate (e.g. a window controller) and off you go. You can create a hello world example with a handful lines of code.

And even if you'd rather create the button programmatically, it's not much more involved.

Sure, if you're coming from Win32 and expect to program Cocoa without learning Cocoa, you're out of luck. But I guess that applies to all frameworks.

How to add a button in SwiftUI:

    Button(“Click Me”) { buttonWasClicked() }

I'm probably another, but I have never done any professional Win32 work. You know, those kind of jobs are rare now and I doubt they want anyone without experience.

What are you talking about? In Cocoa if you want a button you drag one in via Interface Builder. You don't even need to write any code. If you want it to do something, you type the name of the function it should call.

This is total misinformation.

This is such a wonderfully beneficial comment to the HN community. It should get an award.

Reply on news.ycombinator.com