Good for you:) I'm sure C++ programmers feel the same way of their language as well. And Cobol programmers etc...
After you've stared at it long enough, most things start to look like readable. It's just a matter of how long do you want to stare before you start understanding.
But back to the point. I find syntactic sugar like stdcall, published, the whole property MyData: Integer read GetData write SetData; thingy, {$R BUTTONS.RES} compiler commands, ANSIChar ANSIString WideChar WideString @MyRecord ^MyRecord, PChar vs String, far external etc etc... All the syntax makes it harder for me to learn and understand the language, plus it makes the syntax look too busy to my liking. Are all these different words really necessary?
Much like I feel about C++.
The fundamental flaw I think both C++ and Object Pascal have is the fact that they try to be both procedural and object oriented at once. It doesn't work. Either be procedural (C = elegant) or do OO (SmallTalk, Java = elegant). Don't do the hybrid. It doesn't work. In the end, procedural programming always breaks the OO model. If you need both ways, just use two different languages, the ones that excel in their respective fields.
unless you are one of them wussy VB programmers that regards real OO as a flaw because it's "too hard"
Ah, so quick to jump to conclusions. I've never programmed in VB. Maybe Delphi is better when compared to that (VB is the closest thing to Delphi after all, or is it the other way around).
As for OO, I'm for it all the way. It takes a serious effort to change your way of thinking from procedural to OO (I'd say easily 18 months, even if you practice OOP almost daily), but I don't think OO is particularly hard, nor do I slam Object Pascal because of that. I just think there are far more elegant languages for doing OOP than Object Pascal.
Good points on Object Pascal not including templates or multiple inheritance though. I agree on those somewhat. Although I find generic programming quite useful, just the implementation in C++ (templates) is messy. Don't know my Delphi enough to tell how generic programming is achieved using Object Pascal. If at all?
Surely that's just a J(V)M QOI issue. If the implementation you (or your customers) are using is crap, bitch to you J(V)M vendor about it (or tell your customers to) until it gets fucking fixed.
It's not only a vendor problem (unless you're using green threads).
On most systems the JVM uses native threads for performance and scalability reasons. Now let's take a look at the Java API. In java.lang.Thread there exists 10 levels of priorities for Java threads. Now let's see how this maps to a native thread system of say...oh so dear Windows NT.
On NT you don't have process priorities in the same sense that most Unixes have. Instead, what you have is thread groups (Low, Medium, High, Realtime) and each of these has 7 levels. So let's say our JVM runs on the High priority group. There's only 7 levels there, yet we have 10 in Java threads. There must be some overlapping going on here! So you cannot guarantee that your Java thread with priority of 7 is lower than your Java thread with priority of 8. Maybe they map to the same level 5 on the native threads!
Then take a look at the thread model Solaris uses... and Linux which clones light processes... it gets very messy real quick.
So its not just a vendor problems. Java leaves alot to desire when specifying threads, and mostly the reason is that abstracting all the thread models of the world is a pretty difficult thing to do.
Allen Holub has a great series of articles on Java threads. He goes into some length in explaining both the threading models of both NT and Solaris. He also nick names the NT thread system as an 'unholy mess' which is quite amusing:)
Object Pascal for the core language... an elegant programming language
I'm sorry but I can't agree on this. Object Pascal is far from being an elegant language. It suffers from a buttload of unuseful syntactic sugar, and very obviously alot of features have been put in to keep people used to C++ idioms happy. Unfortunately they also introduced the same flaws as C++ has.
Object Pascal can only be called an elegant programming language if you happen to think C++ is an elegant programming language. Which I don't. Both languages suffer from the fact that they attempt to uphold compatibility to their ancestors (C and Pascal) while at the same time serve people with OO paradigm. It all ends up being real messy, IMHO,
Not commenting on Delphi and the IDE in general, just the language underneath.
However it doesn't change the fact that this may (and indeed does) violate the principle of "platform independance": the programmers of (multi-threaded) Java applications need be aware of on which platform(s) his/her applications will be running. Or alternatively go through the troubles of writing dedicated, thread-scheduling code or other "workarounds".
This is true. If you do need a system that, for example, requires prioritizing of the Java threads, you have no choice but to write your own scheduler. It's the only way to get a guaranteed behaviour out of your application on every system.
Problematic, indeed. But then, if you compare the threading models of NT, Solaris and Linux for example, and try to figure out how to abstract the systems so that you can guarantee a similar behaviour under all those systems, my guess is you quickly find it extremely difficult to do.
Green threads are an option, but the cost is quite expensive.
IMHO, threads are such a low level feature of the OS, much like the memory allocation or pointer semantics, that either you go with the "mostly platform independent" way, or have to revert to something like green threads that don't scale.
I seem to recall that a large chunk of JBuilder (something like 80%) is already written in Java. Which would make the porting to Linux alot faster than other more Win32 specific products.
If you're interested in writing debuggers for Java then you might wanna take a look at Java Platform Debugger Architecture (JPDA). This is where JVMDI falls under as well.
JPDA provides the infrastructure needed to build end-user debugger applications. It includes Java Debug Interface (JDI) which allows you to do remote debugging, Java Debug Wire Protocol (JDWP) which defines the protocol used between the debugged process and the debugger application, and Java Virtual Machine Debugger Interface (JVMDI) which lets you hook up to the guts of JVM.
Nope. If you have trouble understanding my English, we can continue this conversation in Finnish. How's yours?
I am having a real hard time believing anyone would post such ignorant facts about Java in public as you have. Java developers do not have to pay royalties to Sun if they want to sell their applications. If you cannot grasp the license text for Sun's JDK, then the problem is yours, not mine.
Since you seem to be quite happy being an ignorant FUD spread machine, expect to get flamed. If you bother to do some real research and back your claims that I, in fact, have to pay Sun for distributing my own Java applications, please feel free to enlighten me.
You are trying to argue that if I download Sun's JDK, build a megacool Java app and compile it with Sun's compiler, and start selling it, I need to pay royalties to Sun? Is that what you are saying?
If it is, you are wrong. Any Java developer can tell you that. I mean, there are thousands of people selling their Java software, and none of them are paying Sun anything.
As for your other post, the license you're looking at is for the source for the JDK. No one is forcing you to download that. That license is there in case you want to take the source for Sun's JDK, change or otherwise use it in your software, and then sell it. In that case you pay Sun royalties for using their source for the JDK. Again, nothing there says the bytecodes generated by this JDK is under any licensing terms with Sun.
my face is a bit red here because I don't know what an invariant is
Invariant is simply a method or a function that checks the internal state of an object, ensuring that no fields have invalid values.
For example, if I want to implement an abstract data type with C++, for example a simple ring buffer, I'd most likely use two index variables, head and tail for accessing an array with the buffer data in it. Now its pretty clear to me, that if my tail or head ever gets a negative value, my code has bugs in it (since I'm only using them to point at the data in the array, range of 0..n).
So I'd define a private method boolean Invariant() that checks that both head and tail are always positive. Then in the two methods I'm implementing for my ADT class pop and push, I'll always call an assert for my invariant, making sure that if ever my indexes turn negative, I get an exception.
Then there's also stuff like IBM's remote AWT which lets you write your app initially as a fat client, and without changing your source code at all, you can also use it remotely from a server and direct the GUI to a very thin client.
That would give the end user an option of either using the fat or thin client. With no additional costs to the developer.
StarOffice, on the other hand, is already pretty solid, and Sun probably wouldn't need to remove much code before releasing the source code.
Solid or not, StarOffice is huge. It takes a considerable amount of effort to study source code of this magnitude. How many open source developers are willing to do it, before they're able to code even a tiny little feature in this suite. My guess is not many.
OTOH, StarOffice might be a model piece of software, extremely modular with clean interfaces that allow you to contribute by only studying one part of the software. But unfortunately, I doubt very much that StarOffice is such a piece of software.
Seems to me 95% of open source software developers want to get right into hacking code, and any amount of studying they'd need to do before getting to that phase, is just going to turn them off the project, be it licensed under Netscape, Sun or whatever license.
Your non-standard usage of terminology confuses the issues -- perhaps because you are confused about them?
For that I apologize. If you have pointers for standardized definitions of both object-oriented and object-based, I'd love to see them. I've yet to find one.
"Object-based" (as opposed to "Object-Oriented") is generally taken to mean "can use -- or fake using -- objects, but cannot create them"; that makes Delphi/Object Pascal OO, and VB Object-based.
Using that definition, yes it would. But what I was after here, is that I've found that Object Pascal, and C++, both break the OO model, at least at the logical level, by breaking encapsulation. Therefore I do not count Object Pascal as being a true OO language. I used OO-based instead, cause that was closest I could come up with. But Object Pascal (and C++) do have far superior object models compared to VB (which I wouldn't call Object based at all, more like structured language). *shrug* Still need to find a way to define these things so that we both know what we're talking about.
Hybrid" (as opposed to, for want of a better term, "totally OO") means the ability to do stuff the old-fashioned non-OO way *too*, in addition to OOishly.
Yes, that's the meaning I have for hybrids too.
In that sense, the only "totally OO" languages I know of are Smalltalk and apparently Eiffel. Is that what you wanted Delphi to be?
Yep, although I'm not rigid about the requirement of being totally pure OO. Just something better than C++ has. I find Java's level of OO adequate, although the primitive types do bug me from time to time.
Sorry, can't be done -- if it were, it wouldn't be Delphi any more.
Why can't it be done? Like I asked in another post, to my knowledge, Delphi is the only environment that uses Object Pascal, and Borland is the entity that defines their version of it. Maybe there are reasons coming from the need of backwards compatibility support that dictate this can't be done? Other than that, I can't think of a reason why not.
1) So what's better with Java's OO support than Delphi's? Maybe you hadn't noticed that the "Beans" component model is pretty much a copy of OP's object model -- maybe you didn't know that Sun actually *bought* it from Borland?
I'm actually very aware of this fact. So much so, than whenever someone spreads the FUD that Sun is the only one that makes decisions about Java and they never listen to anyone else's opinion, I point out that JAvaBeans mainly came from Borland, EJB from IBM, Swing and JFC from Netscape, etc.
What I was referring to was not the component models (which I again must disagree term-wise, to me component model differs from object model). The fact that Object Pascal breaks the encapsulation, being a hybrid language, turns me down. I just don't like it. In that sense, I find Java's (or Smalltalk's or Eiffel's) OO support better.
2) Hmmm... Dunno if I can help here... How's this: Think "state", not "flow"? (Yeah, that leads to modal programs -- but hey, I can't say it better!)
Simple really.. all that GUI stuff that's supposed to be there to help me, just adds alot of noise, and quite frankly, is more confusing to me. I just like to keep looking at my code in a good editor and work there. The fact that I have to look around (for the Object Inspector for instance) to find what the caption of some lable is, or if a button is disable or not, is distracting to me. Maybe not the most popular opinion, knowing how many people absolutely love these types of IDE's and wouldn't work in an environment without them, but that's how I feel. I know that Delphi does not strictly force you to use all the graphical bells and whistles (or should we call them tools?) but it very heavily encourages you to, actually even tells that its the superior way of doing it. I'd like to make that kind of decision myself. Delphi really doesn't give me that chance. Either you like their way, or you better not use it at all. Not good. And a problem with alot of IDE's.
3) Well, you shouldn't expect the IDE to give you *all* your code; write the real action in your own procedures (investigate Data Modules and Action Lists), then just call it from your event handlers.
I'm not expecting that. Actually I'd like it alot more if it'd write little less of it. And your point of ActionLists is a very good one, I've used those myself. The problem here is, my only project with Delphi has been one that was written on the course of 2 years before I got into it, and frankly, I don't like their style of building software. The code is hanging off of the GUI components like ugly warts, making it really hard to follow.
4) Try using it intelligently in stead of "fighting" it. Sorry, but it had to be said...
No problem. I do try. But sometimes the IDE just isn't build the way I find most natural for myself. Which means, like it or not, I end up fighting it.
5) Well, *learn* it in stead of just casting a quick glance.
Well, like I said, I just got into Delphi six months ago when this project was given to me. I am trying to learn it, and I by no means did not mean to give the impression that I was some kind of a Delphi expert. But, as it is, I don't like it that much that I'd choose it for the next project, if given the opportunity to pick a tool. Unless the only other alternative was VB.
I didn't mean to be to harsh on Delphi. I don't think it totally sucks. For Windows environment, if the choice is VB (and that's what Delphi gets compared to most often) it is the better solution, IMHO. I just don't agree with the view that it's perfect, flawless etc., which is the impression you very easily get when listening to Delphi advocates (the bad ones).
Slashdot Mirror
Uhh, yes you can.
Go back to class, kid.
Good for you
After you've stared at it long enough, most things start to look like readable. It's just a matter of how long do you want to stare before you start understanding.
But back to the point. I find syntactic sugar like stdcall, published, the whole property MyData: Integer read GetData write SetData; thingy, {$R BUTTONS.RES} compiler commands, ANSIChar ANSIString WideChar WideString @MyRecord ^MyRecord, PChar vs String, far external etc etc... All the syntax makes it harder for me to learn and understand the language, plus it makes the syntax look too busy to my liking. Are all these different words really necessary?
Much like I feel about C++.
The fundamental flaw I think both C++ and Object Pascal have is the fact that they try to be both procedural and object oriented at once. It doesn't work. Either be procedural (C = elegant) or do OO (SmallTalk, Java = elegant). Don't do the hybrid. It doesn't work. In the end, procedural programming always breaks the OO model. If you need both ways, just use two different languages, the ones that excel in their respective fields.
unless you are one of them wussy VB programmers that regards real OO as a flaw because it's "too hard"
Ah, so quick to jump to conclusions. I've never programmed in VB. Maybe Delphi is better when compared to that (VB is the closest thing to Delphi after all, or is it the other way around).
As for OO, I'm for it all the way. It takes a serious effort to change your way of thinking from procedural to OO (I'd say easily 18 months, even if you practice OOP almost daily), but I don't think OO is particularly hard, nor do I slam Object Pascal because of that. I just think there are far more elegant languages for doing OOP than Object Pascal.
Good points on Object Pascal not including templates or multiple inheritance though. I agree on those somewhat. Although I find generic programming quite useful, just the implementation in C++ (templates) is messy. Don't know my Delphi enough to tell how generic programming is achieved using Object Pascal. If at all?
It's not only a vendor problem (unless you're using green threads).
On most systems the JVM uses native threads for performance and scalability reasons. Now let's take a look at the Java API. In java.lang.Thread there exists 10 levels of priorities for Java threads. Now let's see how this maps to a native thread system of say...oh so dear Windows NT.
On NT you don't have process priorities in the same sense that most Unixes have. Instead, what you have is thread groups (Low, Medium, High, Realtime) and each of these has 7 levels. So let's say our JVM runs on the High priority group. There's only 7 levels there, yet we have 10 in Java threads. There must be some overlapping going on here! So you cannot guarantee that your Java thread with priority of 7 is lower than your Java thread with priority of 8. Maybe they map to the same level 5 on the native threads!
Then take a look at the thread model Solaris uses... and Linux which clones light processes... it gets very messy real quick.
So its not just a vendor problems. Java leaves alot to desire when specifying threads, and mostly the reason is that abstracting all the thread models of the world is a pretty difficult thing to do.
Allen Holub has a great series of articles on Java threads. He goes into some length in explaining both the threading models of both NT and Solaris. He also nick names the NT thread system as an 'unholy mess' which is quite amusing
I'm sorry but I can't agree on this. Object Pascal is far from being an elegant language. It suffers from a buttload of unuseful syntactic sugar, and very obviously alot of features have been put in to keep people used to C++ idioms happy. Unfortunately they also introduced the same flaws as C++ has.
Object Pascal can only be called an elegant programming language if you happen to think C++ is an elegant programming language. Which I don't. Both languages suffer from the fact that they attempt to uphold compatibility to their ancestors (C and Pascal) while at the same time serve people with OO paradigm. It all ends up being real messy, IMHO,
Not commenting on Delphi and the IDE in general, just the language underneath.
This is true. If you do need a system that, for example, requires prioritizing of the Java threads, you have no choice but to write your own scheduler. It's the only way to get a guaranteed behaviour out of your application on every system.
Problematic, indeed. But then, if you compare the threading models of NT, Solaris and Linux for example, and try to figure out how to abstract the systems so that you can guarantee a similar behaviour under all those systems, my guess is you quickly find it extremely difficult to do.
Green threads are an option, but the cost is quite expensive.
IMHO, threads are such a low level feature of the OS, much like the memory allocation or pointer semantics, that either you go with the "mostly platform independent" way, or have to revert to something like green threads that don't scale.
Maybe it's easier?
I seem to recall that a large chunk of JBuilder (something like 80%) is already written in Java. Which would make the porting to Linux alot faster than other more Win32 specific products.
Shrug.
If you're interested in writing debuggers for Java then you might wanna take a look at Java Platform Debugger Architecture (JPDA). This is where JVMDI falls under as well.
JPDA provides the infrastructure needed to build end-user debugger applications. It includes Java Debug Interface (JDI) which allows you to do remote debugging, Java Debug Wire Protocol (JDWP) which defines the protocol used between the debugged process and the debugger application, and Java Virtual Machine Debugger Interface (JVMDI) which lets you hook up to the guts of JVM.
For more info, go to the JPDA Home Page.
Been to any good English classes lately?
Nope. If you have trouble understanding my English, we can continue this conversation in Finnish. How's yours?
I am having a real hard time believing anyone would post such ignorant facts about Java in public as you have. Java developers do not have to pay royalties to Sun if they want to sell their applications. If you cannot grasp the license text for Sun's JDK, then the problem is yours, not mine.
Since you seem to be quite happy being an ignorant FUD spread machine, expect to get flamed. If you bother to do some real research and back your claims that I, in fact, have to pay Sun for distributing my own Java applications, please feel free to enlighten me.
Ok, let me get this straight.
You are trying to argue that if I download Sun's JDK, build a megacool Java app and compile it with Sun's compiler, and start selling it, I need to pay royalties to Sun? Is that what you are saying?
If it is, you are wrong. Any Java developer can tell you that. I mean, there are thousands of people selling their Java software, and none of them are paying Sun anything.
As for your other post, the license you're looking at is for the source for the JDK. No one is forcing you to download that. That license is there in case you want to take the source for Sun's JDK, change or otherwise use it in your software, and then sell it. In that case you pay Sun royalties for using their source for the JDK. Again, nothing there says the bytecodes generated by this JDK is under any licensing terms with Sun.
Find that clue yet?
I still remember the time when all the cool hacker dudes only wrote assembly cause C was just "too slow".
Kinda funny hearing the same argument about Java being given now..
Geez, you have to be really ignorant to think you need to pay to Sun for selling Java software.
If you take their source, and start selling it, THEN you need to pay them. You can build your own Java apps and do whatever you want with them.
Get a clue.
Nokia Mobile Phones
Oh. You live in Sweden then?
Care to explain me, how Sweden is less free than some other countries?
I just recently read an article of a Japanese-Russian research group that's trying to bring mammoths back to earth.
At another point he appeard to be falling asleep.
;-)
But where's the evidence of that? Other than what the news papers have reported.
Like you said yourself, reading the reports will give a skewed view
Uhmm. How come a troll post gets moderated to informative at level 4??
Nope, it's a quote.
It gave we a good chuckle in a middle of sorting out some pretty hairy code. The original author was quite frustrated with the VMS file handling.
also think ISI has an OS called Chorus, which is designed to run on parallel processors.
Do you mean ChorusOS? Sun owns it and is developing it these days.
Invariant is simply a method or a function that checks the internal state of an object, ensuring that no fields have invalid values.
For example, if I want to implement an abstract data type with C++, for example a simple ring buffer, I'd most likely use two index variables, head and tail for accessing an array with the buffer data in it. Now its pretty clear to me, that if my tail or head ever gets a negative value, my code has bugs in it (since I'm only using them to point at the data in the array, range of 0..n).
So I'd define a private method boolean Invariant() that checks that both head and tail are always positive. Then in the two methods I'm implementing for my ADT class pop and push, I'll always call an assert for my invariant, making sure that if ever my indexes turn negative, I get an exception.
boolean MyClass::Invariant() {
if (head < 0 || tail < 0) return false;
return true;
}
void MyClass::pop() {
assert(Invariant());
}
etc...
Or even if they're buttheads who don't read it, if it works like asserts. Which is cool.
Bingo.
Disclaimer: my C++ is really rusty.
That would give the end user an option of either using the fat or thin client. With no additional costs to the developer.
Has anybody ever tried it?
Solid or not, StarOffice is huge. It takes a considerable amount of effort to study source code of this magnitude. How many open source developers are willing to do it, before they're able to code even a tiny little feature in this suite. My guess is not many.
OTOH, StarOffice might be a model piece of software, extremely modular with clean interfaces that allow you to contribute by only studying one part of the software. But unfortunately, I doubt very much that StarOffice is such a piece of software.
Seems to me 95% of open source software developers want to get right into hacking code, and any amount of studying they'd need to do before getting to that phase, is just going to turn them off the project, be it licensed under Netscape, Sun or whatever license.
IMHO.
I think ONE thing will come of it -- Unisys will get even more bad PR.
But then there are those who say there is no such thing as bad publicity...
It's unaccessable several times a week from Finland after 5pm. During the day it works fine (cause people on the other side are sleepy).
Your non-standard usage of terminology confuses the issues -- perhaps because you are confused about them?
For that I apologize. If you have pointers for standardized definitions of both object-oriented and object-based, I'd love to see them. I've yet to find one.
"Object-based" (as opposed to "Object-Oriented") is generally taken to mean "can use -- or fake using -- objects, but cannot create them"; that makes Delphi/Object Pascal OO, and VB Object-based.
Using that definition, yes it would. But what I was after here, is that I've found that Object Pascal, and C++, both break the OO model, at least at the logical level, by breaking encapsulation. Therefore I do not count Object Pascal as being a true OO language. I used OO-based instead, cause that was closest I could come up with. But Object Pascal (and C++) do have far superior object models compared to VB (which I wouldn't call Object based at all, more like structured language). *shrug* Still need to find a way to define these things so that we both know what we're talking about.
Hybrid" (as opposed to, for want of a better term, "totally OO") means the ability to do stuff the old-fashioned non-OO way *too*, in addition to OOishly.
Yes, that's the meaning I have for hybrids too.
In that sense, the only "totally OO" languages I know of are Smalltalk and apparently Eiffel. Is that what you wanted Delphi to be?
Yep, although I'm not rigid about the requirement of being totally pure OO. Just something better than C++ has. I find Java's level of OO adequate, although the primitive types do bug me from time to time.
Sorry, can't be done -- if it were, it wouldn't be Delphi any more.
Why can't it be done? Like I asked in another post, to my knowledge, Delphi is the only environment that uses Object Pascal, and Borland is the entity that defines their version of it. Maybe there are reasons coming from the need of backwards compatibility support that dictate this can't be done? Other than that, I can't think of a reason why not.
1) So what's better with Java's OO support than Delphi's? Maybe you hadn't noticed that the "Beans" component model is pretty much a copy of OP's object model -- maybe you didn't know that Sun actually *bought* it from Borland?
I'm actually very aware of this fact. So much so, than whenever someone spreads the FUD that Sun is the only one that makes decisions about Java and they never listen to anyone else's opinion, I point out that JAvaBeans mainly came from Borland, EJB from IBM, Swing and JFC from Netscape, etc.
What I was referring to was not the component models (which I again must disagree term-wise, to me component model differs from object model). The fact that Object Pascal breaks the encapsulation, being a hybrid language, turns me down. I just don't like it. In that sense, I find Java's (or Smalltalk's or Eiffel's) OO support better.
2) Hmmm... Dunno if I can help here... How's this: Think "state", not "flow"? (Yeah, that leads to modal programs -- but hey, I can't say it better!)
Simple really.. all that GUI stuff that's supposed to be there to help me, just adds alot of noise, and quite frankly, is more confusing to me. I just like to keep looking at my code in a good editor and work there. The fact that I have to look around (for the Object Inspector for instance) to find what the caption of some lable is, or if a button is disable or not, is distracting to me. Maybe not the most popular opinion, knowing how many people absolutely love these types of IDE's and wouldn't work in an environment without them, but that's how I feel. I know that Delphi does not strictly force you to use all the graphical bells and whistles (or should we call them tools?) but it very heavily encourages you to, actually even tells that its the superior way of doing it. I'd like to make that kind of decision myself. Delphi really doesn't give me that chance. Either you like their way, or you better not use it at all. Not good. And a problem with alot of IDE's.
3) Well, you shouldn't expect the IDE to give you *all* your code; write the real action in your own procedures (investigate Data Modules and Action Lists), then just call it from your event handlers.
I'm not expecting that. Actually I'd like it alot more if it'd write little less of it. And your point of ActionLists is a very good one, I've used those myself. The problem here is, my only project with Delphi has been one that was written on the course of 2 years before I got into it, and frankly, I don't like their style of building software. The code is hanging off of the GUI components like ugly warts, making it really hard to follow.
4) Try using it intelligently in stead of "fighting" it. Sorry, but it had to be said...
No problem. I do try. But sometimes the IDE just isn't build the way I find most natural for myself. Which means, like it or not, I end up fighting it.
5) Well, *learn* it in stead of just casting a quick glance.
Well, like I said, I just got into Delphi six months ago when this project was given to me. I am trying to learn it, and I by no means did not mean to give the impression that I was some kind of a Delphi expert. But, as it is, I don't like it that much that I'd choose it for the next project, if given the opportunity to pick a tool. Unless the only other alternative was VB.
I didn't mean to be to harsh on Delphi. I don't think it totally sucks. For Windows environment, if the choice is VB (and that's what Delphi gets compared to most often) it is the better solution, IMHO. I just don't agree with the view that it's perfect, flawless etc., which is the impression you very easily get when listening to Delphi advocates (the bad ones).