Skillster:
Yes, all Delphi programs use the same GUI library. The same as all other Windows applications: The Windows API.
I could never tell the difference between a Delphi application and a VC. For instance Nemu (the famous N64 emulator) is coded in Delphi, you wouldn't know that by looking on it...
Perhaps there is some common design twist among Delphi developers though. But have no doubts, I could easily make designs identical with Qhimm's programs', for instance.
Halkun: Ok, my very biased counter arguments:
Assembler: Well, try writing a large corporate application with a development time of about 2 years, then maintain that for ten years after that. Possible? I wouldn't say so...besides it's useless for me as it isn't cross-platform.
The main thing I have against it is that more advanced stuff quickly get a little unmaintainable. It's very difficult to create bloat with it! This is a good thing for small stuff, but for huge projects you sometimes need the bloat. If you program something in ASM, then you abandon it and someone else must take over...someone who have no knowledge of your program...you'd better have things documented.
Standard C: Solves all of the problems I mentioned in assembler. You can do everything with it, but programming stuff that are OO in nature (like widgets etc.) is a bit too messy for my taste. Yes, widgets can be done without OO...but what about widget libraries? Saying you've avoided OOP in a widget library would in 95% of the cases be a lie, you would have simulated the idea somehow.
Inform: Looks great! Now program me Quake IV or an Office suite using it!
Seriously, games will always have scripting languages and custom data files. The mere thought of programming the individual rooms in a programming language more advanced than the one you've shown perhaps shows your thinking on programming...the ASM way...
We come from two different lairs here. I usually generalize everything in a project, I want everything to be customizable, EVERYTHING. You make things very specific, meaning you get things done fast and slick, but there's a higher chance you'll have to start from scratch next time. There's no telling what's best. I bloat and make stuff easy to maintain, you don't bloat and get things done fast. Am I right?
There's a place and time for every language...
Wait, I'm getting too friendly here. Here you go:
Overloading is very neat. It isn't needed in a type-unsafe language though, and can be vedry dangerous if misused (all functions with the same name should do the same thing, only according to different types of parameters).
You can use globals in C++, who told you otherwise?
And about object-oriented languages: The Inform code you posted doesn't look very object-oriented to me, I think we define OOP in entirely different ways. To me (and most other OOP programmers), OOP means: Polymorphism.
Polymorphism is the use of the virtual keyword in C++. Consider this code:
class Widget
{
virtual Draw(Surface& surface) = 0;
}
class Button : public Widget
{
virtual Draw(Surface& surface);
// Any Button properties
}
class Edit : public Widget
{
virtual Draw(Surface& surface);
// Any Edit properties
}
Now, no rendering code has to care if it deals with an Edit or Button. They're both widgets. In fact, anyone else which have never seen any of my code except the Widget declaration can easily create other widgets, and they'll fit into the rendering engine without any knowledge in the rendering engine about that particular widget (in fact, the rendering engine only knows about Widget itself). This is the reason I use C++. Any other object oriented language would do, but the more perfect languages are mostly academical, while C++ has huge library support (both C++ and C libraries) and is more widely used. Besides I fail to see the flaw in C++...
