cmuratori
Every year Microsoft makes it harder to actually ship a working executable.

- Casey

You know, the popularity of this series might get their attention. Maybe you will have some input into that at some point.

Microsoft is a large corporation with goals and deadlines and bottom lines, but it's run by human beings, and human beings aren't bad. Once they understand that you're just trying to be able to ship stuff more easily, people will start to listen. It may take a while, but people will start to listen.

naikrovek
Also, no one in this thread has mentioned the efforts internal to Microsoft (that are not secret AT ALL) to do exactly what you say Microsoft are not doing, which is to slow this crazy train down and rethink how things are designed at the macro scale.

Why would we mention those? They're literally irrelevant when Microsoft continues to ship dramatically more complex distributions every year on the platform we actually use! Sure, there's internal projects at Microsoft. When I interned there in 1993 they even had a real-time OS research project. Who cares? Over two decades later, there are still no real-time features in Windows. It literally does not matter at all what random side projects Microsoft is doing. It matters what they are actually doing every year on the platform we actually have to ship on.

Look at the TINY versions of windows that MS have made available for the Raspberry Pi or the Arduino Galileo, for example. In the case of the latter, that thing is like 150MB if I recall correctly.

Did you just call a 150MB OS _for a fixed hardware platform_, that doesn't even have DirectX support, "tiny"? Please tell me that did not just happen.

- Casey

cmuratori

naikrovek
Also, no one in this thread has mentioned the efforts internal to Microsoft (that are not secret AT ALL) to do exactly what you say Microsoft are not doing, which is to slow this crazy train down and rethink how things are designed at the macro scale.

Why would we mention those? They're literally irrelevant when Microsoft continues to ship dramatically more complex distributions every year on the platform we actually use! Sure, there's internal projects at Microsoft. When I interned there in 1993 they even had a real-time OS research project. Who cares? Over two decades later, there are still no real-time features in Windows. It literally does not matter at all what random side projects Microsoft is doing. It matters what they are actually doing every year on the platform we actually have to ship on.

Look at the TINY versions of windows that MS have made available for the Raspberry Pi or the Arduino Galileo, for example. In the case of the latter, that thing is like 150MB if I recall correctly.

Did you just call a 150MB OS _for a fixed hardware platform_, that doesn't even have DirectX support, "tiny"? Please tell me that did not just happen.

- Casey

I'm not an MS apologist. I JUST described their direction as a "crazy train."

And, yes, it's tiny given how much you can do with it, when compared to full Windows. It also includes full debug support for nearly everything, and most of the size is taken up by the remote debugging support.

I guess why I disagree with you once in a while is because I've never once written game code, and that is apparently all you do. You are aware that other software development tasks exist, and I'm sure you would agree that they have merit, but you don't care because they don't involve games?

I'm just trying to state my opinion here, and be nice about it. Feels like you hate my guts every time you reply to me, anywhere.

naikrovek
It also includes full debug support for nearly everything, and most of the size is taken up by the remote debugging support.

"Most" of the 150mb is taken up by support for remote debugging? What do you mean?

- Casey

cmuratori

naikrovek
It also includes full debug support for nearly everything, and most of the size is taken up by the remote debugging support.

"Most" of the 150mb is taken up by support for remote debugging? What do you mean?

- Casey

Well, I don't have the thing in front of me, and I haven't even turned it on in a while, but when I was looking through it, it was about 200MB on disk, installed and running, and nearly all of that was infrastructure for remote code debugging via visual studio. Maybe 10% of that was what one would consider an OS runtime, and that included everything in C:\windows\ if I am remembering correctly. Tiny, considering that whole OS includes the CRT and full remote debug support for it, meaning the debug symbols and whatever else is used when you use breakpoints and that stuff remotely from visual studio.

The Win10 Raspberry Pi stuff grew out of this, and it does have a gui (of sorts) and a complete Win32 API as well as the new, silly, universal app model API, and full remote debug support for both.

Again, I'm not apologizing for MS in any way. I just have this apparently infuriating ability to see both sides of an argument simultaneously. Or perhaps the infuriating part is that I have the temerity to post.

naikrovek
I just have this apparently infuriating ability to see both sides of an argument simultaneously.

What argument? So far there isn't an argument? There is just "Windows is now a nightmare to distribute software on", which it doesn't sound like you're arguing against, and "Microsoft has some projects where they ship smaller versions of Windows on unrelated platforms" to which I replied "who cares?" And so far nobody has argued about the "who cares", so I'm assuming we all agree that a) such projects exist, and b) they don't matter at all to the original point?

There might have been an argument about whether 200mbs for an OS was tiny, but when I questioned that you then said that you didn't actually mean that it was 200mbs, you meant something else, but we don't have numbers for that something else, so there's not going to be much of an argument there. Obviously I am not going to argue that "some unspecified percentage of 200mbs" is too large for an operating system :P

As for this

Feels like you hate my guts every time you reply to me, anywhere.

Wasn't that the very first time I had ever replied to you? It was on this forum, anyways... maybe you mean somewhere else? Although I suppose you could also use the term "every time you reply to me, anywhere" to refer to this one singular time I have replied, because it would still be technically correct :)

- Casey

Twitter. You and Jonathan both muted me long ago because I had questions about your opinions. Not challenges, just questions.

You guys do not seem to be very tolerant of dissent.

naikrovek
You guys do not seem to be very tolerant of dissent.

That's just the reality of having a high volume of replies. You make a judgement call about what you look at and what you don't. My Twitter feed isn't a democratic forum, it's my personal Twitter feed. If I think someone is making good points, I'm happy to argue with them arbitrarily long. If I don't, I mute them so I can move on to interacting with other people. This is 10x true, for Jon, who has a completely unreasonable number of followers at this point :)

As you can see from this thread, I am not intolerant of dissent even when I think it's uninformed. Anyone can post anything on the forums here, and I don't delete it. But my counterposts are going to take on the tone of the dissent - if they are accusatory, then mine will be dismissive. If they are thoughtful, mine will be thoughtful.

Generally speaking, I am not a nice guy so I definitely don't go out of my way to write a very soft and gentle reply when the OP doesn't do so.

- Casey

Eh, I had a huge thing typed up here, but if I were you, I wouldn't have read it, so it's gone.

I'll say this, though, and maybe it'll resonate:

I used to KNOW FOR A FACT that game development was hard. You've shown us that it's nowhere nearly as difficult as we thought.

You KNOW FOR A FACT that the tools you use are insufficient in a lot of ways. When will you show us that writing tools that don't suck is nowhere nearly as difficult as you thought? Jon is doing it with JAI.

After Handmade Hero has finished, I will hopefully see the excessive complaint from you about dev tools cease, and I will hopefully begin to see you create some game-development specific tools that don't suck.

naikrovek
You KNOW FOR A FACT that the tools you use are insufficient in a lot of ways. When will you show us that writing tools that don't suck is nowhere nearly as difficult as you thought? Jon is doing it with JAI.

Nowhere near as difficult as I thought? I don't think writing tools is difficult! I just think people who write tools aren't good at it. I do a lot of tools programming at Molly Rocket, and it's something that I'm very serious about. But they are proprietary parts of our business at the moment, so they're not something that I stream about. One of them is our metaprogramming environment, which I've mentioned. The other ones we haven't discussed publicly. Eventually we may ship some of them externally, but we're a game developer so that's not our primary focus.

So, just to be clear, I do not "only write game code". Game code is actually a small fraction of the work that I do. I would say that it doesn't even comprise 50% of the type of code that I write, or have historically written.

- Casey

I guess I would have expected you to have improved gdb then, if it is so easy. With an open source tool like that, it seems to me that getting good functionality added to it would be easy for someone like yourself that knows what they're doing.

So is it easy to write good tooling or is it not, because gdb still sucks.

Do you understand the meaning of fanboysim?

Linux DOES have problems. The only flavor of Linux I can install on my laptop is MINT because of drivers issue. I also have to physically plug my laptop directly into a router because it needs the internet to down the drivers I need in order for it to work properly. Should people complain? YES. Should they fix it? YES. Even Jon and Casey has b*** about it on twitter. What's my point to all this? We all don't take sides on a company to the point where these flaws blinds us. Linux is created by a community of people who take their time to work on creating Linux, not by a million dollar company with thousand of dollars that can create resources to fix these bugs.My point is that it's just NOT one sided and we accept the badness by complaining about it and not cover it up because it's our most favorite company in the world.

My mission here isn't to create the perfect software. I am not perfect. My mission is to create a program that works, not just once, but all the time the same way it work a year ago and something that doesn't crash half of the time or give you an error that doesn't give you a clue whats wrong. That's good software in my opinion and it's not perfect and will crash sometimes, but it's better than the stuff you see Microsoft ship out that WE MIGHT HAVE TO BUY.

naikrovek
So is it easy to write good tooling or is it not, because gdb still sucks.

So, if you're still not sure about it, this kind of comment is why people mute you on Twitter. Being argumentative and nonsensical is kind of the magic combo for that. You just picked a random project and decided that because I never went and improved it, I must be wrong about tools programming?? Do you really believe that makes sense as something to say?

But, whatever. All of this should be pretty obvious to anyone who thinks about it for a second, but since that apparently didn't happen:

Writing tools is no different than writing games, although some of the technique choices differ. But this is rather completely true, meaning that a poorly written tool may be difficult or impossible to really improve substantially without a complete rewrite because of the infrastructure choices made, the design of the code, etc. In a lot of ways, the quality of a program often flows from the architecture, such that if a tool is shitty, it's usually not because the programmers did a great job on the bulk of it but just failed at the edges. It's usually because the architecture is very poor and it is difficult for the programmers to make the user-facing parts do what everyone can plainly see they should do.

The things we do in Handmade Hero that take only a few hours, like asset streaming, might be almost impossible to do in a codebase that were architected differently without touching literally all the code and debugging the resulting problem for days. I complain about Photoshop constantly, for example, but if you gave me the source code, it wouldn't help me at all. The problems with it are fundamental and it would be much faster for me to rewrite the parts that I need than it would be to start from their codebase - I can tell you that even without looking at it, just by the behavior of the program :)

So, much like you can't just take someone's game engine and magically add streaming to it if they made a ton of bad architecture decisions up to that point, you can't just parachute into GDB, spend a day, and suddenly it's awesome. And this is even more true for programmers like me, who are architecture guys, because we get 90% of our speed from the fact that we're smart about high-level design. There are programmers that I've known who have skills more adapted to the parachute-in, change, get out style, but I'm not one of them :) A classic example of this is Michael Sartain (also a RAD guy), who consistently surprises me by the way he's able to just jump into some nightmare open source project and go improve something. Of course, even he has never be able to make a dent in GDB or LLDB to the best of my knowledge (and he did try quite a bit with LLDB, but I believe he found trying to work with the maintainers to be prohibitive, another classic problem with trying to improve open source software).

And finally, writing tools is no different than writing games in the fullest sense of that statement. Sure, it's easy to do a good job on a game engine if you're smart about it, like I'm trying to show in Handmade Hero. But it still takes a substantial time investment. It wasn't like I started showing how to program the Handmade Hero engine and then five hours later I was done. We'll be about 200 hours of programming in before the engine is in shape, and then we've still got what I estimate to be about 400 hours of programming before we have a nice game. That's 17 weeks of full-time programming! Where do you think I'm going to pluck 17 weeks of full-time programming from my schedule in order to go rewrite GDB? It's simply not feasible if you have other things that you've prioritized higher.

Someday it will probably get to the point where Visual Studio is as bad as Linux debuggers, and then I'll have to change those priorities. It's certainly going that direction. But until then, there is always some program higher on the priority list than rewriting a debugger.

- Casey

PS. As a coda, I'd like to point out that I don't actually have a problem with GDB. It's often my go-to debugger on Linux when I just need to see where something crashed or whatnot. It's problem is just that it's command-line-centrism makes it very difficult to use as a "code investigator", which is something I often use a debugger for. I like to have watches, call stacks, source views, etc. that update in an easy-to-view fashion as I step through code, and GDB sucks at that. For some reason, all the things people build on top of GDB never seem to be able to actually retain the "able to get data properly" part of GDB :( So in theory, some GDB front end would actually be fine for debugging on Linux, but even though I've tried dozens of them, I still haven't found one that actually properly implements all of GDBs inspection features while providing a usable interface.

I know why I'm muted. Thank you. My mother openly hated me when I was a child (truth) and now I am openly antagonistic toward everyone. I have cigarette burns all over me that she gave me as a child as punishment. Because I am literally not good enough for my own mother, I find it very difficult to truly care if I am disliked by anyone else, most of the time.

So, yeah, I'm an ass. I know it. Most of the time I don't care. I know why I'm muted.

Back to topic:
If gdb isn't a good example, pick another. All day long I hear people complain about X, and then never take any steps to improve X in any way, or even look for an alternative to X. They just want to complain.

I see that in you sometimes, and it frustrates me because I know you can effect change with this kind of thing. You complain about Microsoft Whatever, but if you spoke to them you would be able to express your concerns with them. Maybe you have done this, but I've never heard you say so. I've heard you complain a lot.

naikrovec, I wrote in another thread that to archive change, you have to start changing things. As from just complaining rarely anything ever gets changes. So I agree with you on the topic there.

Of course there is always that factor of time. I see it in myself, sometimes people annoy me, but I simply lack the time to change the tools for the better (I use Opensouce tools at home).

To the topic of tools, there is also the thing of perception. To stay with GDB I'd suspect the maintainers and hardcore user are perfectly fine with it. It works the way they want it, the way they like it and would never think of it doing what it does in other ways.
I admit I sometimes like the dismissive tone about those tools "sucking", one mans worst tools might be another mans golden screwdriver. This extends to more than tools, but also API, OS etc. "Bad" is very often a thing of perspective and how you use something.

I give another slightly related example: At work I have to use Visual Studio 2015. Whether or not it is good is not the topic, but that for the person next he told me it crashes sometimes about 10 times a day. I start it Monday, then it runs until Friday evening when I power the PC down.
He has an awful experience regarding stability and crashes. Until he told me, I would have said "Visual Studio never crashes".