The Amateur Meathead Responds

An education in etiquette, manners and the understanding tradeoffs in software engineering

You know you are dealing with a real professional when they call you a “meathead“ and your writing for “meathead ramblings,” and accuse you of being unprofessional and clueless.

I could not help but chuckle Barry when I read your response. It is always fun to get feedback on ones writing and I do appreciate that you spent some time on writing yours. I cannot help but imagine some sort of Hollywood movie where an overweight guy in the bottom of his basement is tapping a way at his keyboard in anger about somebody on the internet who is wrong, and who must be corrected and put in his place.

I guess I have the honor of being that guy.

But hey I don’t get all that easily offended, so I will try to address the issues you raised in a mostly serious manner.

However, there’s far more to a GUI framework than its tooling. At some point, it needs to be wired to the application’s code. It is a critical part of the implementation process and you ignored it.

I am not claiming to be an expert on Godot, but I am not sure this is the big problem you believe it to be. Godot has plugin support for C++ through what they call GDNative. For the kind of complex applications I talk about which I have spent my career building, that is the language you are most likely going to be using anyway. With their GDNative C interface you can interface with anything can can produce code with a C interface. Many languages can do that e.g.:

• Swift
• Rust
• Objective-C

If you need to “show it to somebody”, it is better to send them a skeletal GUI as an executable.

You could be working on different platforms. Frequently a reality for me. And besides you may want to do quick iterations and prototyping. Setting a project that needs compilation can be unnecessary amounts of work. E.g. when working with Qt, we would often send around Qt .ui files.

I have done prototyping in all sorts of ways. I have had interactive prototypes utilizing limited interactivity in PDF files e.g. I had used paper prototypes with people. Many ways of doing this. Sometimes people want to be able to experiment and tweak your prototype to send you feedback.

If the “somebody” is a team member, shouldn’t they already have a licensed copy anyway?

I don’t know about you but in any organization of any size, there a a lot more people than developers involved in creating a product. You get feedback from people who are not necessarily developers. You don’t want to tell them to install 5 GB worth of software just to look at a prototype and give some feedback.

A professional isn’t concerned about license fees or the minor inconvenience of online registration to get a project done.

Your organization may only have licenses for the developers, and the ones you want feedback from are not necessarily developers.

I don’t know what organizations you have worked in, but I cannot say I have ever found it fun to deal with licenses, certificates etc. Often you have an outsources IT organization where any request, such as getting another license will test your patients. Any software product that lets you avoid corporate IT is a win in my book. In smaller companies it tends to be mostly okay. But the larger the organization gets the bigger the pain in my experience.

A bit of research would have revealed that Autodesk’s Fusion360, a popular 3D modeling CAD/CAM software, is built on it.

See that is the difference between you and me. You google to make an opinion about how good Qt is for making such applications. I base my opinion on actually having spent years working on applications of that complexity myself and seeing the problems with using Qt first hand.

Qt survived decades of battle testing with a staff of developers supporting it.

Funny you try to lecture me on Qt. I am not sure you where even a developer when I started using Qt the first time. I remember interacting with founders online. I live in Norway and I have been on job interviews with them and worked at companies with close relationship with them. It is a company and a product I know very well from years of experience.

The issues you had with it could’ve been better articulated than with an “I don’t know.”

You sound a bit like a fanboy. That is okay I was a Qt fanboy years ago too. But back then the alternatives tended to be horrible stuff like MFC.

The problem with Qt today is that it kind of dropped the ball on those of us who work on complex professional applications in favor of mobile UIs, car interfaces etc. We have seen basically no updates in years for Qt native widgets. I was away from Qt development for over 5 years. Came back and imagined I had to get up to speed with a lot of changes. But there as pretty much no changes. The Qt GUI designer had all the same limitations as 5 years earlier. Zero improvements.

You then go on to shred SwiftUI and Cocoa for being too complex. Yes, it’s complex because it gives you a very high degree of control and power.

I think my criticism of SwiftUI and Cocoa went right over your head. Let me clarify a bit. I love Cocoa. It has for most of my career been my favorite GUI toolkit.

Yes some people have not like Cocoa because it is pretty big on abstractions and design patterns. To effectively use Cocoa you need to understand the Model-View-Controller pattern.

I personally loved the springs and struts approach in Cocoa to build GUI applications, it was flexible while at the same time really easy to work with.

So my issue isn’t Cocoa as such but a particular Cocoa technology: Auto Layout. As I said this looked really promising at first. But my experience was that it easily got too complex to work with. It was not a great abstraction. And I highly doubt I was the only to think that.

Why else do you think SwiftUI arrived? If Auto Layout was so awesome, why did it get replaced?

On SwiftUI I am basically sitting on the fence. I said I think it looks promising, but that I currently lean towards the Godot approach because I prefer visual design tool. I articulated why.

While neither languages are easy to learn, millions of app developers found it easy enough.

SwiftUI and Cocoa are not actually programming languages Barry. Cocoa is a GUI toolkit and SwiftUI is simply a way of doing layout of Cocoa GUI components they are not separate technologies.

If it wasn’t clear in my original post Barry, I have actually worked on numerous iOS applications in both Swift and Objective-C. Assuming a technology is easy, because lots of people use it, is a logical fallacy. Lots of people wrote their applications in Assembly code at one point, that is hardly proof of that application development in Assembly code is easy.

Lots of people write C++ code. That does not mean C++ is a userfriendly language. User-friendliness is not measured in how many people are able to grasp a language. People where perfectly capable of writing large programs in Assembly code. It was just very slow to do. User-unfriendliness slows you down. That costs time and money. Hence it matters.

Your disdain for and difficulty with strongly typed languages expose you as an amateur.

An amateur would get all worked up about being called an amateur because they are insecure about their skill and knowledge. Instead I see this as a useful teaching moment.

It is common to for beginners in the industry to have very strong opinions about silver bullet like solutions such as, the more object-oriented the language is or the stronger typed it is the better it is.

The experience professional however understands that everything comes with tradeoffs. Too weak typing can make make important bugs hard to catch. Too strong typing on the other hand can lead to either too inflexible language or one which is too high level of complexity.

Complexity is not free. IBM did a study some time ago where they looked at productivity over time. What kind of developers produced code that had value over time. It turns out that a lot of the developers we regard as the clever ones did not have good long term productivity for an organization. They code they wrote was too complex and difficult to grasp for maintainers that it ended up not being used by other developers.

In other words you are not stronger than the weakest link. As has been attributed to Albert Einstein: “Any fool can make something simple complex, but it takes a genius to make something complex simple.”

As a software developers it is important to be able to recognize complexity, instead of being afraid somebody calls you stupid or unprofessional if you do.

I have encountered people like you all my life Barry, because I have always valued elegant design and simplicity. My first technology affection was a Commodore Amiga. A beautifully designed system. I remember complaining to a friend running DOS on PC about the complexity of usage compared to Amiga. At the time I believe we were trying to move one of the programs loaded into memory into the right 64K memory slot. We had to try to line up the programs so we would not fragment the memory too much.

This kind of manual optimization of memory allocation was of course totally unnecessary on a more modern system like the Amiga. Yet my PC friend believed the complexity of DOS was a sign of its superiority. That Amiga was just a toy because it was too easy to use. Real men used DOS and configured their autoexec.bat and config.sys file to deal with Bill Gates’ crazy 640KB memory limit.

As you Barry, my friend interpreted my complain about complexity as somehow a lack of intelligence. Never mind that he only played games on his PC, while I actually knew how to write Motorola 68000 assembly code on my Amiga to produce graphics effects. Or never mind that I later knew enough about the internals of DOS to write computer viruses which could stay resident by modifying the interrupt vector table, and dealt with programs rewriting themselves while running.

No, I was still the idiot for daring to question the sanity of the design of DOS.I remember MP3 players before the iPod. Sometimes absolutely terrible user interfaces and software synching. But you couldn’t tell the sales guy that. Remarking on software being poorly designed, just meant you where an idiot who just didn’t get it.

I have fought much of my career against this toxic attitude. I eventually became head of UX at my one of my previous companies because I was among the few who actually bothered to run proper user tests to finally convince a lot of management that our software had terrible usability. Until I did, the response I got kind of echoed yours Barry: “That our users where really smart so they didn’t need better usability.”

Usability is one of the hardest things to push at any company, because very few people dare to say anything is complex. They don’t want to singled out by some Barry telling them they are amateurs. But I don’t have such low self-esteem, that I was afraid of that.

Usability of a programming language is not all that different from usability in graphical user interface. There are many share principles and concept. Things like consistency, orthogonality, keeping a limited number of concept in your head at the same time etc.

Experienced developers understand and welcome the benefits it brings in terms of quality and reliability, especially on large projects.

Of course, you pretend as if I don’t know. I rewrote a whole commercial App to Swift and saw many advantages from going from more weakly typed Objective-C to more strongly typed Swift. I have also written my owns from scratch in Swift. I am not unfamiliar with the benefits.

The problem is you judge without really knowing anything about the specifics of my issues with Swift. When porting from Objective-C to Swift it was mostly fine because you don’t functional style code in Objective-C. The syntax is poorly suited for it. It is geared strongly towards object-oriented programming. In particular the Smalltalk inspired syntax makes that really nice.

However trouble really starts to mount as soon as you begin to try use Swift in an functional fashion. Named arguments, which is so nice for object-oriented programming becomes a real pain when going functional.

Functions such as map and filter work best when they don’t have to assume the arguments have particular names. They also expect function and not methods. Hence you end up with a predicament. Almost all functionality typically created in Swift will be using methods with named arguments. But these functions cannot readily be passed to functions such as map and filter. Instead they must be wrapped every time.

In a language better designed for functional programming such as LISP, Julia or Haskell you don’t run into this kind of problem.

Swift force you to deal with two four types of different functions essentially:

• Free functions without named arguments. The typical function in most languages.
• Free functions with named arguments. Unique to Swift, not use anywhere else.
• Methods with named arguments. Kind of like Smalltalk.
• Methods without named arguments. Like C#, Java, Python etc.

That breaks an important principle in usability which is about orthogonal features. You should try to avoid features with a lot of overlap in functionality.

They bypass the native GUI to render their components consistently across platforms. Unfortunately, users demand their apps to look and feel like a native one.

I am certainly one of those, but no a lot of user surprisingly don’t care all that much about this and lots of successful applications don’t have a native look and feel. Look at editors such as VSCode, Atom or Brackets which don’t have a native look yet are among the most popular editors for developers out there.

One of the most popular browser in use, Chrome doesn’t really behave like a native application. Almost everything in it is a web interface. Firefox used their own widgets for a while.

And Qt by the way doesn’t really give a native look. It just tries to approximate it, but especially on the Mac, it is usually all to evident that it is not a native application. I actually prefer the look of things like VSCode over a lot of the Qt applications which almost look like a macOS app, but is wrong enough areas to become annoying.

More important, pretty much none of the complex GUI applications in highly technical fields really look native. Especially if they are multi-platform.

Flutter is similar to Godot in this regard but at least renders it to appear native.

Which as I said I frankly find more annoying than beneficial most of the time. It is like in Qt, where a widget is drawn to look like a Mac widget but then the spacing and alignment is like on Windows making the whole thing look ugly. You end up looking like these fugly Linux themes that try to emulate a Mac look. It never works.

Ironically, you criticize Flutter for being geared towards designer types and hipsters, but you’re not a professional engineer either.

I cannot be a professional because I think Flutter looks like something for hipsters? Mind you I didn’t say it was. I said, that was my impression from the time I have spent with it. I am not claiming to be all knowing on this topic.

How can you nonchalantly brush off localization and accessibility as not important?

I did not say it was not important in general. I said it is my experience that it is not important in the field I have worked in. Big difference.

A localizable application can broaden its market reach.

Really? You have no clue what the complex technical applications for professionals are like then. If you don’t grasp English, then you also have no business doing highly complex scientific or engineering work.

Your requirement is as dumb as insisting that computer languages must be localized. I know very well how that worked, as I have had the “pleasure” early in my career trying to merge code written in English Visual Basic with Norwegian Visual Basic. I can only suspect a guy like Barry was in charge of the Visual Basic for Applications division at Microsoft at the time, thinking that if they localized the programming language they would get broader market share.

Also, governing bodies often impose accessibility requirements with noncompliance leading to litigation.

Sure, when you deal with crucial functionality all citizens must be able to access such as a bank, tickets for an airline etc. But a government isn’t going to give a shit that a tool costing 100 000 dollars to do stochastic 3D modeling of the subsurface used by about 120 highly trained specialists in the country isn’t usable for blind people.

Such nonsense just shows you have no clue about what I am talking about. Yet you apparently feel entitled to have very strong opinion on it.

Finally, you admit that you’re a Godot beginner and don’t have a full overview.

I seriously wonder what side of the bed you got up at the day, which made you so worked up about me writing about Godot. Take a deep breath, and read the first lines in my story. What does those line say? What does that hint at?

Let me quote those lines, so you don’t have to lookup the article again:

I have been trying out the Godot Game Engine lately, and I have been mightily impressed with what I see.

Emphasis is mine. What does tell you Barry? This is how the whole story begins. Does it suggest that now you will become privy to deep advice from a great sage, who have studied Godot in its every facet and detail for the last millennium? Or does it suggest that it is written by someone who “just lately tried out Godot?”

…to prepare your victims for your meathead ramblings.

It was an opinion piece Barry. Chill, just chill. Yes I know it can be hard on the blood pressure when somebody is “wrong” on the internet. Especially if they have a different technological preference than you. This is one of those moments when you are an Emacs fan and somebody dares to say they think Vim is better. How dare they?

I know there are a lot of Barry’s out there. Here is a free tip to all of you: If you disagree with somebody’s technological preferences. Then just write why you think they are wrong. Don’t make it personal. It just makes you look like a bitter little person.

And if you are really professional, don’t do like me. Don’t respond to Barry people. Just ignore them. Unfortunately I am a bit immature and cannot help myself getting engaged in a good flamefest.