How many projects have been started for our beloved machine...

[elmer]

This is just what I've been looking for! 

I'm not sure why you'd need a tutorial? You code the compiler!

Because I've hardly found any documentation on how HuC is *supposed* to be used, and if I'm trying to make improvements, then I need to know what people think stuff is supposed to do.

There's some stuff in there that's not how I would have done it, and I need to know how to avoid breaking things.

It's pretty clear that compatibility with existing code is far more important than whatever notions I may have over what I personally feel to be the "preferred" way (there's hardly ever a hard "right" or "wrong" in this stuff).

I also want to be able to point folks to some decent documentation in the readme for Uli's HuC, and in any page of programming links that we make.

Anyway ... I'm just messing around inside someone else's code, not "coding the compiler". That's different. And remember that the core of HuC is based on Ron Cain's SmallC, which was designed to be short enough, and simple enough, to be a type-it-in-yourself magazine article, back-in-the-day.

And just because I messed-around in GCC to get the compiler outputing PC-FX code again, doesn't mean that I have any clue of the *real* complexity of the internals inside their compiler.

I disagree, I find coding skills to be mostly portable.

I've got to both agree, and disagree.

I hope that we can all agree that just because you've got a lot of experience in one area of programming, doesn't suddenly mean that you can instantly be a productive expert in a different area of programming. There is usually a *lot* of domain-specific knowledge that needs to be learned.

That *seems* to me to be the main thrust of what The Old Rover and Arkhan are saying, and I totally agree.

But I've found that a *good* programmer can usually pick up the simple stuff quickly, and transfer their problem-breakdown, and logic-organizational skills between domains and languages, pretty easily.

That *seems* to me to be what you're saying, and I agree.

But (IMHO), the really hairy areas in any domain, are going to take anyone a long while to master.

Luckily, there are very few of those (if any) on these old 4th-gen single-processor consoles.

[DarkKobold]

I also want to be able to point folks to some decent documentation in the readme for Uli's HuC, and in any page of programming links that we make.

If you didn't know about the tutorial, you might not know about this- http://archaicpixels.com/Main_Page
I apologize if you already did know. I use this as my main "WTF do I do now?"

I hope that we can all agree that just because you've got a lot of experience in one area of programming, doesn't suddenly mean that you can instantly be a productive expert in a different area of programming. There is usually a *lot* of domain-specific knowledge that needs to be learned.

That *seems* to me to be the main thrust of what The Old Rover and Arkhan are saying, and I totally agree.

But I've found that a *good* programmer can usually pick up the simple stuff quickly, and transfer their problem-breakdown, and logic-organizational skills between domains and languages, pretty easily.

That *seems* to me to be what you're saying, and I agree.

Yeah, I think that is mostly what I was getting at. In academic settings, there seems to be two (10) types of people, those that just *get* coding, and those that don't. Even if they don't have the mastery of a language, it seems much easier to switch around, because the fundamentals stay the same. Its a lot easier than learning a new spoken/written language.

[nodtveidt]

Yeah, once you understand programming in general, it's not nearly as difficult to take on another language, provided the paradigm doesn't differ too radically. For many years (nearly two decades), I mostly used BASIC and C, so trying to learn C++ was a major pain in the tail because it's a completely different paradigm. However, once I managed to wrap my head around the differences, I learned other OOP languages as well. In addition to coding HE and LDP, I'm also studying Android and Python... they are very different but understanding the basic principles of both procedural and OOP methodologies helps tremendously. Still, my eyes glass over if I look at the source code to gcc or even huc (and this is coming from someone with formal education in PLT, mind you)... but the code for Quake, for example, makes perfect sense to me.