Almost any language can read like english if done cleverly.
The key point here is "if done cleverly." I always strive to make my C++ as readable as possible. I agree that the average and novice programmer will be in good shape if they can code C++ cleverly. But that is the definition of novice, that you don't know any better until someone shows you or you figure it out with experience. If these people were able to do things cleverly in C++ then they would not be averages in the first place. They would be master level, which we are saying they are not.
I may not have written the sentence you quoted correctly. What I was trying to say is that there are programming languages that are designed such that you can't really write complex lines of code. That doesn't matter for the clever people but it sure matters a lot for novice developers. These languages tend to be wordy. They tend to need more statements of code to accomplish a task. Then there are languages that are designed such that you can write some code that did things you did not realize was going to happen. These languages tend to be terse. They tend to jam pack many operations in one high level statement. This is where people get in trouble with C++. The classic text book example is being given a line of code and asked how many temporaries will be involved and the lifetimes they have. Most people can't do it. Hell, I can't do it all the time. That's the complexity. Operator overloading is a notorious source of these hidden actions. The statement "a = b + c;" seems so innocent. Then, at runtime, the performance comes to a halt. What happened? What is truly going on in that statement? Then on some other project the statement "a = b + c;" seems to produce garbage values for a, if an exception hasn't been thrown already. Upon debugging we find that b and c are being added just fine. OK, what is going on with the return value? What is the return value? Is it by value, a reference, or a pointer to something? What is being referenced here? Are there treacherous temporaries afoot?
Now think of the kinds of statements that even the gurus trip over on! In a language like Object Pascal some of these issues are almost non-existent. That's always a plus, for the novice, the average, and even the gurus.
Here here! In the realm of native application development I have programmed in C++, Delphi, and Eiffel. Each language has its pros and cons. C++ is no doubt the most popular and most successful of the three. However, I have been most productive and had the most fun with Eiffel and Delphi. Some might be quick to say I am not experienced enough with C++ or that I haven't learned the idioms. I have programmed in C++ for many years. I have read all the books written by Stroustrup, Scott Myers, Herb Sutter, Andrei Alexandrescu, etc. I regularly read the newsgroups and paid attention to Sutter's Guru of the Week articles. With all that under my belt I still make mistakes. Why? In Eiffel and Delphi a statement of code can do one or two things. In C++ a statement of code can do several things, some of which incur side effects of their own. If you don't understand these behaviors then you write buggy code. Or, in other words, C++ is complex.
The hardcore crowd will tell you that ultimately you are better off going with C++ because of speed and power (implying that every other is a step above Visual BASIC). NONSENSE! Delphi is on par with C++. In certain situations C++ is more efficient than Delphi. In other situations Delphi is more efficient than C++. In the long run they are both the same. The only thing Delphi can't do is metaprogamming. Big deal. I can write my number crunching algorithm in C++ templates and wrap it in a library that Dephi can call. Problem solved. You know what C++ can't do elegantly? GUI development. It's tortuous. C++ Builder doesn't count because the language is modified and is not ANSI C++, which should really tell you that there is truth in the statement that C++ lacks some features. Qt has always been my favorite ANSI compliant GUI library. However, even Qt is a testament to the needed addition to C++. The meta-object compiler?? As if my compile times weren't long enough?
I have debated on the C++ newsgroups about accepting Borland's C++ extensions to the language, namely properties, closures, and reflection (advanced RTTI). I admit that boost does have a way to implement closures as template classes. They work and are efficient. My only dislike is that the syntax is too cumbersome. But I'll let that go. However, it has been argued and proven that properties CAN NOT be implemented as a class library without overhead. They simply must be a feature of the language. Combine that with better RTTI support (reflection capabilities) and you will have some powerful new tools to make elegant designs. And no, I am not advocating using RTTI for general development. Obviously if you have to test your base class pointer to discover the actual child type then your design is flawed. But that does not mean RTTI is as evil as goto statements. Properties and reflection is superior in the domain of GUI frameworks. GTK++, MFC, Qt, etc., should be proof enough that GUI libraries are too cumbersome without properties and reflection.
A lot of people ask for C++ to have some kind of GUI library but I do agree with Stroustrup's rationale for why that is not possible. There is no common denominator of design that would make sense for every platform and would appease everyone (whom has their own opinions on the design of a GUI framework, which are radically different). It is better for C++ to rely on third party libraries that deal with GUI development. That is fine for me. What I ask for is that we improve the language to allow better development for these third party GUI libraries.
Outside of GUI development, properties can be useful. The hardcore group, however, always argues against syntactic sugar because it is somehow pointless. This may be true for computer scientists. It is not true for software engineers. I always welcome any kind of help in reducing bugs. Syntactic sugar can actually help. To say it briefly, Delphi and Eiffel read like English. C++ reads like machine language. Guess which group of developers is going to have a higher defect rate?
I see the Matrix icon for this article but I can't help but think that the whole name has more Rush references than Matrix references. All these words come from various songs.
Correct me if I am wrong but since the WTL is written primarily in C++ templates then Microsoft had no choice in making in open or closed source. WTL is a collection of header files. You can't make a binary library with that alone.
Those plates also benefit people as well. As for technology, I work on license plate recognition software and I can tell you that the DMV and the state goverment (U.S.) is my enemy when they allow wacky graphical plate designs. Reflective plates are not going to help that situation.
With the current state of license plate recognition technology I say relax. There is no big brother system keeping track of where you drive by having cameras everywhere reading your plate and linking it to your identity.
Note though: LPR systems are typically used for traffic pattern analysis and toll enforcement, so drop the conspiracy theories.
So your new Dell PC running Windows XP doesn't come with a programming language. Buy one.
I have one question, does sporting equipment come standard with purchased homes? Computers are no different from any other hobby and/or career path. If you want to help invest in your kid's programming skills then buy your kid a programming language. It's no different from buying your kid sports equipment, or buying musical instruments, or paying for lessons, etc. Investing in your kid's development costs.
Actually, Hegel originally wrote that line. However, society seems to attribute this to Nietzsche because he followed up on the idea and proclaimed it louder than any of the other atheist philosophers.
"...wouldn't you want to use M$'s programming tools and techonologies which will most likey integrate better and will probably be more productive than non-M$ products?"
Not true. As an example, one would logically think that because Microsoft develops MS Windows then Microsoft's Visual Studio is the best tool for making GUI apps, COM objects, ActiveX, NT services, etc... Heh, not so. Well, ok, Visual Basic is pretty slick with COM/ActiveX, but it's crap for anything else. Likewise, Visual C++ just plain sucks (and I will spare the WHOLE story why I think it sucks). Surpisingly, Delphi makes writing GUI apps, COM/ActiveX, NT services, etc., very easy. But wait! Borland doesn't develop MS Windows, how could this be so?
Still don't believe. Try this out. COM development in Visual C++ wasn't pretty, in fact you had to know two languages: C/C++ and IDL (which is not the case with Delphi, no IDL programming required). Then Microsoft came out with COM+, which was COM with some niceties for development, like automatic reference counting for example. Now did Borland update Delphi to support COM+. Guess what? They didn't really need to. They already had it before COM+ was invented! What? That doesn't make sense. Well check this out. When Borland made support for COM, their IUnknown interface, and sub-interfaces, were designed with some of COM+'s features in mind, for example the reference counting. So while Visual C++ programmers were having fun with COM in the sadistic sense, COM+ finally came out and the Delphi developers said "heh, we already were doing that, COM+ doesn't really apply to us".
So much for the MS tools must integrate with MS technologies better than anyone else. As for.NET you have to keep in mind that part of what makes up.NET are the standard protocols. Speak those protocols and you are in the game (especially with repsect to web service development). Now it may be nice to also have the ability to use.NET classes (the assemblies), but it is not a requirement. Either way, Borland has yet another chance to show that they can make very quality.NET compatible development tools while not being Microsoft, despite Microsoft developing.NET.
As a side note, Microsoft hired some of Borland's top talent away from them. Some of them help develop.NET. The core architect of the original Delphi, Anders Hejlsberg, co-authored the C# language!! So in a way you can say that Microsoft developed.NET but Borland indirectly developed.NET. As a final note, Borland sued Microsoft for such low-ball tactics. So much for fair competition.
No need to go in reverse. In NYC, looking forward, subways usually travel on the right side, similiar to a car driving on the right side of the road. However, usually due to maitenence reasons, a subway train will temporarily switch sides and travel on the left side to bypass the working crew. At these times you will pass the ads such that it should play in reverse.
Since this topic is about Delphi 7, why don't you give Delphi a try. It has strong type checking. It is not huge and complex like C++. Because of the relative simplicity of the language it compiles extremely fast. As for garbage collection (GC), Delphi does not have GC. However, Delphi interfaces are automatically reference counted. If you stick to a pure interface model when programming you pretty much get GC behavior (although personally I don't do that and stick to explicit object creation and destruction).
What's wrong with C# that you can't touch on principle? Because it is Microsoft? Do you know who are the top designers of.NET and C#? Some of them are former Borland employees, most importantly Anders Hejlsberg. Do you know what that means? It means Microsoft may actually get something right for the first time!! (As opposed to Visual C++ and the MFC library, which they got wrong everytime).
If you don't like Microsoft then fine, but, give GNOME/Mono's version of C# a chance at least. If you program as a hobby then I guess it doesn't matter. But if you program as a profession then I would not just brush off a language backed by a company that has the power and resources to make the language here to stay. You can never be too sure that you won't come across a project that works with C#.
You got to be kidding me. I would never write code like that. This kind of programming is what makes MFC a bad library. Your C/C++ macro preprocessor is a tool, not a language. Don't use it like a language. Here is a short list why:
Can't trace preprocessor code during debugging.
Can't inspect the value of a #define during debugging. I prefer const variables.
You undermine the code completion because it doesn't know about the existence of the property. When you press '.' or '->' you will not see your property in the popup window.
Can very easily introduce obscure bugs that can be hard to find.
Take a look at MFC message maps to understand why using the preprocessor as a language is a mistake. I'm sorry but I disagree with you. Altering the language can be a good thing. Adding a new feature is not the only criterion for altering the language. If the alteration helps productivity then I am for the alteration being done. C++, especially, could really use it.
"now if they where useing STANDARD CPP why should using GCC be impossible (I suspect they have a few broken things in terms of standard support just like gcc has a few broken things)"
There is a reason why Borland doesn't use standard C++ with C++ Builder (both Win32 and Linux). Take a look at the fundamental design philosophies of the VCL/CLX. It is very component oriented. You cannot do that with standard C++ (or you can but in a really ugly non-elegant way). This is because of how Delphi worked. Two important things:
Properties. A much simpler form of accessors and mutators (via GetX/SetX).
Published section. You know private, protected, and public? Well here is published. Anything under published is public with RTTI information automatically generated. A property under a published section will be visible to the Object Inspector (or any piece of code that queries the object's RTTI).
Under Delphi these two things made for very powerful and easy programming. How do you do that in standard C++ in a simliar and easy way? I think Qt tackled that problem the best. However, Microsoft (via MFC) did the worst job. MFC is proof that C++ needs better, or updated, language facilities. Qt is also proof in a way. I like the signal/slot mechanism, but when you have to have a seperate meta-object compilation phase then that raises some kind of warning flag. I don't blame Borland for just adding their own extensions to their version of C++. IMHO they have made C++ a much better language.
On a side note, in terms of pure C++, I like Qt. It is better than most other libraries I have used. However, I prefer Borland C++ Builder over Qt.
I have job experience using MFC. I will not describe it in detail. I will just sum it up and say that it is truly the most un-productive horrid framework I have ever used. Also, Microsoft's new WTL is no better. In short, the class wizard helps you half the time (if it aint broke when you modify some code) and the message maps are a nightmare. This automatic code generation you speak of is not all that glamorous. All that code generation gives you is a cryptic program that comiles to be Notepad. You're on your own after that. The Document/View architecuture is bad and seems to be a perversion of the Model/View/Controller architecture. Doc/View can be good for small scale, but will break down and give you nightmares on large scale projects.
I started using two pieces of technology, Delphi and Qt, and I have never looked back. At work I use Visual C++ to program DLL's (using STL and no MFC classes at all) and I use Delphi to front end, as well as write the back end stuff too! If I had my choice I would ditch Visual C++ altogether, I think it gives C++ a bad name. I wish most companies would not buy Microsoft Visual C++.
I have never used wxWindows, but I can assume that it is better than MFC. As for cross platform needs MFC still is the worst choice. At one of my previous jobs they had a person that programmed a project for both Windows and Mac OS. There is MFC for the Mac platform. However, this programmer was frustrated by the details because what worked on MFC for Windows worked differently (or not at all) for MFC on Mac OS.
For cross platform I would say check out Qt and check out Delphi / C++ Builder. Qt was one of the best C++ libraries I have ever used and I wish I could use it on Windows at work. Delphi kicks ass in all aspects. IMHO Delphi is the only technology I know that can truly claim the title of being a RAD tool. Kylix is Delphi for Linux. C++ Builder should be ported to Linux by Borland soon enough.
Compilation times. Delphi has everyone beat. Delphi, according to Borland themselves, compiles 4 million lines of code per minute!!!! But don't take my word for it, try it your self. I have seen a half-a-million LOC project compile, on a GHz Pentium, in about 30 seconds!! C++ will never, ever, come anywhere close to that and it is all because Object Pascal syntax is relatively simple. Look at C++'s syntax and sematics. It's complexity limits how fast you can parse the code. Delphi by default doesn't show compiler statistics because for the average program you are working on as soon as you click the compile button the compilation is already done!!
Because of blazing fast compilation times one will definitly get in the spirit of using the debugger. First, you will get used to doing full recompiles once after you implement one method. Then you will get use to using breakpoints and watches to find bugs. I love using breakpoints, watches, evaluations, etc. It is the way to go. However, Visual C++ fosters bad debuging habits in the form of that stupid TRACE macro, or the Win32 API call OutputDebugString. It is like using printf to figure out the state of your program to try to figure out the bug.
I apologize for mentioning Visual C++ so much. I would love to use GNU C but professionaly speaking the only jobs I work on insist on using Visual C++, a brand name standard. Besides, most of the Linux people I knew prefered vi or emacs, hardly an IDE to the likes of Visual Studio and Delphi. Yeah, I know there is KDevelop and such others, but they are not as nice (and I was nausiated by the fact that KDevelop is literally a Visual Studio clone right down to also providing a Doc/View architecture, which is a bad architecture). On a side note though, I did try the Vi OLE control for Visual Studio because I do love vi alot;-)
There is no Debug mode vs. Release mode in Delphi. Not that it was a bad idea but MS dropped the ball on it and Visual C++ has made Debug/Release mode style development a pain in the ass! Delphi doesn't put debug symbols inside your executable. Instead it keeps everything inside extermal files (.dcu files). When you are finished debugging you just had your executable off as is. Actually, there is a sort-of release build in the form of "turn of assertions", but this is not the same as Visual C++ release mode where the project settings are very different from Debug mode.
Last but not least, Borland is a company who, like Apple, is sticking around for quite a long time. People think they are going out of business, but they are not. So company support is there (managers like to hear that). Also, just like there is a Linux community, there is a Delphi community, full of resources, reusable code/components, and friendly developers who are willing to help you out.
On the negative side, if you are going to do some internet development then Delphi may not be for you. I have not used Midas or VisiBroker that much and I do not know how they truly fare against Java and.NET. In these cases I know Java is much better at server side internet development, its Servlet technology and wealth of APIs kick ass. I am guessing that.NET will be very good. Guess what?.NET, and C#, was co-designed and implemented by Anders Heiljsberg, who is the father of Delphi (and was hired away by MS in the 90's to work in R&D, Borland sued MS over this). Did anyone read the C# specs? People call it Java, but do you really wanna know where the idea of properties came from?;-)
Damn! This sucks that there are so many comments already, this probably won't be read. Anyways.
I am sadened by the fact that nobody cares about Delphi, and that the only comments that mention Delphi aren't moderated up. I have used many languages (and I was impressed to see that this person mentioned looking at Eiffel, a nice language).
First off I have to say this, even at the risk of being flamed and called a troll. Either the geek culture is just ignorant, scared, or both. Stop feeling so insecure to the point where you have to use a difficult language to boost your ego. What I mean is try using a language that actually makes your life easier. I am so annoyed by these people who suggest C++. I have many years exprerience in C++ and let me tell you that it is not exactly your best friend on large projects, especially with coworkers who do not know the pitfalls of C++ programming.
Also, all you people suggesting ruby, or other new and/or obscure scripting languages, please give me a break. I like cool languages like Lisp and Snobol as much as the next, but I must admit to the reality that no real business and business project is going to go with these languages as the main development tool. There are some business that use Lisp and Smalltalk, which is cool. However, the reality is that the dominant language is C++, Java, VB, and maybe even C#. Stop suggesting languages that no clueless boss is ever going to approve of (cluesless bosses only know to use C++/Java, the buzzword language).
Now on to Delphi. Delphi is what you are looking for. First off, your requirements list is too unrealistic. You are going to to have to make some trade offs.
Delphi doesn't have operator overloading. Guess what? That is not critical. What's the difference between a + b and a.Add(b)? None.
Delphi doesn't do multiple inheritence. Guess what? If you are a good enough OO designer, you won't need it. Delphi supports single inheritence, multiple interface implementation style, just like Java and Smalltalk. So don't give that shit that multiple inheritence is needed, it is not.
Here is a quick OO design tip. I have noticed that C++ programmers like the multiple inheritence because they can have a class inherit from one class to gain capability, and then have it inherite from another class to establish communication (usually through an abstract interface). THIS IS A MISTAKE!! Golden rule of thumb, favor aggregation over inheritence. I am not going to exlpain myself on this (it would make this post too long). Take it from me, I have seen this in real projects, don't use inheritence to establish communication between objects. Use inherietence to vary state/behavior of a particular entity. Net result, designs such as these do not require multiple inheritence and are far more flexible and reusable.
Delphi is natively compiled, not like that p-code shit VB does. Delphi is made by Borland, which employs some of the brightest compiler designers around. Delphi is far more efficient than C++.
I have used C++ most of my career and I am still learning Delphi. I was skeptical of Delphi at first. But I gave it a try and did performance tests. For example, Delphi's for loops kick the shit out of C++ for loops. Another examle, Delphi's TList kicks the shit out of the STL vector and list containers. Don't be so ignorant, give it a try. I DARE YOU ALL YOU TROLL GEEK C++ PROGRAMMERS WHO FIND IT EASIER TO SAY DELPHI SUCKS RATHER THAN TRY IT!!
As for GUI, no contest! No contest!. You know easy VB is with GUI development, Delphi is even better (with more components by default than VB). People have mentioned Qt. I like Qt. It is orders of magnitude better than MFC (which is the WORST LIBRARY IN THE WORLD!!). But Delhpi's VCL is better than Qt.
Delphi does not have garbage collection. That is ok, its interfaces are automatically reference counted;-) By the way, Delphi's interfaces were modeled after MS COM, and as a result COM programming is a HELL of a lot easier in Delphi than in Visual C++, including MS's stupid ATL crap.
I thought that Delphi would not be portable, but it turns out that Borland implemented something to simulate a lot of the Windows stuff under Kylix. As a result, porting should not be hard. I will not say that porting is a snap. I would be lying. However, porting should not be that bad, but YMMV.
End result, I used to love C++. But after using many other languages I started to despise C++. Delphi was the language that made me loathe C++. I do respect Troll Tech for making an excellent product. Qt is very impressive, but MS's MFC library is the cold reality that C++ is very deadly in the wrong hands. Visual C++ with MFC has to have caused more project slippage/failure than any other language in the history of programming (well, that is my opinion). I dare anyone to check out Borland's case studies of Delphi. Check out Deja news list of compilers, where the programmers got to vote. Delphi, despite probably the least used langugae, was voted number 1, followed by Borland's C++ Bulder. Visuall C++ and VB were at the bottom of the list with negative comments too!
May not be the best form of documentation, but the source code to X, window managers, and KDE/GNOME will have the answers. Got to imagine all these projects have had many different ideas implemented in each one.
Slashdot Mirror
Almost any language can read like english if done cleverly.
The key point here is "if done cleverly." I always strive to make my C++ as readable as possible. I agree that the average and novice programmer will be in good shape if they can code C++ cleverly. But that is the definition of novice, that you don't know any better until someone shows you or you figure it out with experience. If these people were able to do things cleverly in C++ then they would not be averages in the first place. They would be master level, which we are saying they are not.
I may not have written the sentence you quoted correctly. What I was trying to say is that there are programming languages that are designed such that you can't really write complex lines of code. That doesn't matter for the clever people but it sure matters a lot for novice developers. These languages tend to be wordy. They tend to need more statements of code to accomplish a task. Then there are languages that are designed such that you can write some code that did things you did not realize was going to happen. These languages tend to be terse. They tend to jam pack many operations in one high level statement. This is where people get in trouble with C++. The classic text book example is being given a line of code and asked how many temporaries will be involved and the lifetimes they have. Most people can't do it. Hell, I can't do it all the time. That's the complexity. Operator overloading is a notorious source of these hidden actions. The statement "a = b + c;" seems so innocent. Then, at runtime, the performance comes to a halt. What happened? What is truly going on in that statement? Then on some other project the statement "a = b + c;" seems to produce garbage values for a, if an exception hasn't been thrown already. Upon debugging we find that b and c are being added just fine. OK, what is going on with the return value? What is the return value? Is it by value, a reference, or a pointer to something? What is being referenced here? Are there treacherous temporaries afoot?
Now think of the kinds of statements that even the gurus trip over on! In a language like Object Pascal some of these issues are almost non-existent. That's always a plus, for the novice, the average, and even the gurus.
Nicholas
Here here! In the realm of native application development I have programmed in C++, Delphi, and Eiffel. Each language has its pros and cons. C++ is no doubt the most popular and most successful of the three. However, I have been most productive and had the most fun with Eiffel and Delphi. Some might be quick to say I am not experienced enough with C++ or that I haven't learned the idioms. I have programmed in C++ for many years. I have read all the books written by Stroustrup, Scott Myers, Herb Sutter, Andrei Alexandrescu, etc. I regularly read the newsgroups and paid attention to Sutter's Guru of the Week articles. With all that under my belt I still make mistakes. Why? In Eiffel and Delphi a statement of code can do one or two things. In C++ a statement of code can do several things, some of which incur side effects of their own. If you don't understand these behaviors then you write buggy code. Or, in other words, C++ is complex.
The hardcore crowd will tell you that ultimately you are better off going with C++ because of speed and power (implying that every other is a step above Visual BASIC). NONSENSE! Delphi is on par with C++. In certain situations C++ is more efficient than Delphi. In other situations Delphi is more efficient than C++. In the long run they are both the same. The only thing Delphi can't do is metaprogamming. Big deal. I can write my number crunching algorithm in C++ templates and wrap it in a library that Dephi can call. Problem solved. You know what C++ can't do elegantly? GUI development. It's tortuous. C++ Builder doesn't count because the language is modified and is not ANSI C++, which should really tell you that there is truth in the statement that C++ lacks some features. Qt has always been my favorite ANSI compliant GUI library. However, even Qt is a testament to the needed addition to C++. The meta-object compiler?? As if my compile times weren't long enough?
I have debated on the C++ newsgroups about accepting Borland's C++ extensions to the language, namely properties, closures, and reflection (advanced RTTI). I admit that boost does have a way to implement closures as template classes. They work and are efficient. My only dislike is that the syntax is too cumbersome. But I'll let that go. However, it has been argued and proven that properties CAN NOT be implemented as a class library without overhead. They simply must be a feature of the language. Combine that with better RTTI support (reflection capabilities) and you will have some powerful new tools to make elegant designs. And no, I am not advocating using RTTI for general development. Obviously if you have to test your base class pointer to discover the actual child type then your design is flawed. But that does not mean RTTI is as evil as goto statements. Properties and reflection is superior in the domain of GUI frameworks. GTK++, MFC, Qt, etc., should be proof enough that GUI libraries are too cumbersome without properties and reflection.
A lot of people ask for C++ to have some kind of GUI library but I do agree with Stroustrup's rationale for why that is not possible. There is no common denominator of design that would make sense for every platform and would appease everyone (whom has their own opinions on the design of a GUI framework, which are radically different). It is better for C++ to rely on third party libraries that deal with GUI development. That is fine for me. What I ask for is that we improve the language to allow better development for these third party GUI libraries.
Outside of GUI development, properties can be useful. The hardcore group, however, always argues against syntactic sugar because it is somehow pointless. This may be true for computer scientists. It is not true for software engineers. I always welcome any kind of help in reducing bugs. Syntactic sugar can actually help. To say it briefly, Delphi and Eiffel read like English. C++ reads like machine language. Guess which group of developers is going to have a higher defect rate?
Nicholas
- Zion - Digital Man, from Signals
- Radio - Spirit of Radio, from Permanent Waves
- Free - Free Will, from Permanent Waves
- Sundog - Chain Lightning, from Presto
Nicholas...responsible for open-sourcing WiX and WTL
Correct me if I am wrong but since the WTL is written primarily in C++ templates then Microsoft had no choice in making in open or closed source. WTL is a collection of header files. You can't make a binary library with that alone.
Not your friend's professor but 'The Professor' himself, Neil Peart.
Those plates also benefit people as well. As for technology, I work on license plate recognition software and I can tell you that the DMV and the state goverment (U.S.) is my enemy when they allow wacky graphical plate designs. Reflective plates are not going to help that situation.
With the current state of license plate recognition technology I say relax. There is no big brother system keeping track of where you drive by having cameras everywhere reading your plate and linking it to your identity.
Note though: LPR systems are typically used for traffic pattern analysis and toll enforcement, so drop the conspiracy theories.
Nicholas
So your new Dell PC running Windows XP doesn't come with a programming language. Buy one.
I have one question, does sporting equipment come standard with purchased homes? Computers are no different from any other hobby and/or career path. If you want to help invest in your kid's programming skills then buy your kid a programming language. It's no different from buying your kid sports equipment, or buying musical instruments, or paying for lessons, etc. Investing in your kid's development costs.
God is dead. (Neitzche)
Actually, Hegel originally wrote that line. However, society seems to attribute this to Nietzsche because he followed up on the idea and proclaimed it louder than any of the other atheist philosophers.
"...wouldn't you want to use M$'s programming tools and techonologies which will most likey integrate better and will probably be more productive than non-M$ products?"
.NET you have to keep in mind that part of what makes up .NET are the standard protocols. Speak those protocols and you are in the game (especially with repsect to web service development). Now it may be nice to also have the ability to use .NET classes (the assemblies), but it is not a requirement. Either way, Borland has yet another chance to show that they can make very quality .NET compatible development tools while not being Microsoft, despite Microsoft developing .NET.
.NET. The core architect of the original Delphi, Anders Hejlsberg, co-authored the C# language!! So in a way you can say that Microsoft developed .NET but Borland indirectly developed .NET. As a final note, Borland sued Microsoft for such low-ball tactics. So much for fair competition.
Not true. As an example, one would logically think that because Microsoft develops MS Windows then Microsoft's Visual Studio is the best tool for making GUI apps, COM objects, ActiveX, NT services, etc... Heh, not so. Well, ok, Visual Basic is pretty slick with COM/ActiveX, but it's crap for anything else. Likewise, Visual C++ just plain sucks (and I will spare the WHOLE story why I think it sucks). Surpisingly, Delphi makes writing GUI apps, COM/ActiveX, NT services, etc., very easy. But wait! Borland doesn't develop MS Windows, how could this be so?
Still don't believe. Try this out. COM development in Visual C++ wasn't pretty, in fact you had to know two languages: C/C++ and IDL (which is not the case with Delphi, no IDL programming required). Then Microsoft came out with COM+, which was COM with some niceties for development, like automatic reference counting for example. Now did Borland update Delphi to support COM+. Guess what? They didn't really need to. They already had it before COM+ was invented! What? That doesn't make sense. Well check this out. When Borland made support for COM, their IUnknown interface, and sub-interfaces, were designed with some of COM+'s features in mind, for example the reference counting. So while Visual C++ programmers were having fun with COM in the sadistic sense, COM+ finally came out and the Delphi developers said "heh, we already were doing that, COM+ doesn't really apply to us".
So much for the MS tools must integrate with MS technologies better than anyone else. As for
As a side note, Microsoft hired some of Borland's top talent away from them. Some of them help develop
No need to go in reverse. In NYC, looking forward, subways usually travel on the right side, similiar to a car driving on the right side of the road. However, usually due to maitenence reasons, a subway train will temporarily switch sides and travel on the left side to bypass the working crew. At these times you will pass the ads such that it should play in reverse.
Since this topic is about Delphi 7, why don't you give Delphi a try. It has strong type checking. It is not huge and complex like C++. Because of the relative simplicity of the language it compiles extremely fast. As for garbage collection (GC), Delphi does not have GC. However, Delphi interfaces are automatically reference counted. If you stick to a pure interface model when programming you pretty much get GC behavior (although personally I don't do that and stick to explicit object creation and destruction).
.NET and C#? Some of them are former Borland employees, most importantly Anders Hejlsberg. Do you know what that means? It means Microsoft may actually get something right for the first time!! (As opposed to Visual C++ and the MFC library, which they got wrong everytime).
What's wrong with C# that you can't touch on principle? Because it is Microsoft? Do you know who are the top designers of
If you don't like Microsoft then fine, but, give GNOME/Mono's version of C# a chance at least. If you program as a hobby then I guess it doesn't matter. But if you program as a profession then I would not just brush off a language backed by a company that has the power and resources to make the language here to stay. You can never be too sure that you won't come across a project that works with C#.
- Can't trace preprocessor code during debugging.
- Can't inspect the value of a #define during debugging. I prefer const variables.
- You undermine the code completion because it doesn't know about the existence of the property. When you press '.' or '->' you will not see your property in the popup window.
- Can very easily introduce obscure bugs that can be hard to find.
Take a look at MFC message maps to understand why using the preprocessor as a language is a mistake. I'm sorry but I disagree with you. Altering the language can be a good thing. Adding a new feature is not the only criterion for altering the language. If the alteration helps productivity then I am for the alteration being done. C++, especially, could really use it.There is a reason why Borland doesn't use standard C++ with C++ Builder (both Win32 and Linux). Take a look at the fundamental design philosophies of the VCL/CLX. It is very component oriented. You cannot do that with standard C++ (or you can but in a really ugly non-elegant way). This is because of how Delphi worked. Two important things:
- Properties. A much simpler form of accessors and mutators (via GetX/SetX).
- Published section. You know private, protected, and public? Well here is published. Anything under published is public with RTTI information automatically generated. A property under a published section will be visible to the Object Inspector (or any piece of code that queries the object's RTTI).
Under Delphi these two things made for very powerful and easy programming. How do you do that in standard C++ in a simliar and easy way? I think Qt tackled that problem the best. However, Microsoft (via MFC) did the worst job. MFC is proof that C++ needs better, or updated, language facilities. Qt is also proof in a way. I like the signal/slot mechanism, but when you have to have a seperate meta-object compilation phase then that raises some kind of warning flag. I don't blame Borland for just adding their own extensions to their version of C++. IMHO they have made C++ a much better language.On a side note, in terms of pure C++, I like Qt. It is better than most other libraries I have used. However, I prefer Borland C++ Builder over Qt.
I have job experience using MFC. I will not describe it in detail. I will just sum it up and say that it is truly the most un-productive horrid framework I have ever used. Also, Microsoft's new WTL is no better. In short, the class wizard helps you half the time (if it aint broke when you modify some code) and the message maps are a nightmare. This automatic code generation you speak of is not all that glamorous. All that code generation gives you is a cryptic program that comiles to be Notepad. You're on your own after that. The Document/View architecuture is bad and seems to be a perversion of the Model/View/Controller architecture. Doc/View can be good for small scale, but will break down and give you nightmares on large scale projects.
I started using two pieces of technology, Delphi and Qt, and I have never looked back. At work I use Visual C++ to program DLL's (using STL and no MFC classes at all) and I use Delphi to front end, as well as write the back end stuff too! If I had my choice I would ditch Visual C++ altogether, I think it gives C++ a bad name. I wish most companies would not buy Microsoft Visual C++.
I have never used wxWindows, but I can assume that it is better than MFC. As for cross platform needs MFC still is the worst choice. At one of my previous jobs they had a person that programmed a project for both Windows and Mac OS. There is MFC for the Mac platform. However, this programmer was frustrated by the details because what worked on MFC for Windows worked differently (or not at all) for MFC on Mac OS.
For cross platform I would say check out Qt and check out Delphi / C++ Builder. Qt was one of the best C++ libraries I have ever used and I wish I could use it on Windows at work. Delphi kicks ass in all aspects. IMHO Delphi is the only technology I know that can truly claim the title of being a RAD tool. Kylix is Delphi for Linux. C++ Builder should be ported to Linux by Borland soon enough.
One downside of the C++ STL is that it is not Delphi's VCL.
Here is some more info on Delphi.
;-)
.NET. In these cases I know Java is much better at server side internet development, its Servlet technology and wealth of APIs kick ass. I am guessing that .NET will be very good. Guess what? .NET, and C#, was co-designed and implemented by Anders Heiljsberg, who is the father of Delphi (and was hired away by MS in the 90's to work in R&D, Borland sued MS over this). Did anyone read the C# specs? People call it Java, but do you really wanna know where the idea of properties came from? ;-)
Compilation times. Delphi has everyone beat. Delphi, according to Borland themselves, compiles 4 million lines of code per minute!!!! But don't take my word for it, try it your self. I have seen a half-a-million LOC project compile, on a GHz Pentium, in about 30 seconds!! C++ will never, ever, come anywhere close to that and it is all because Object Pascal syntax is relatively simple. Look at C++'s syntax and sematics. It's complexity limits how fast you can parse the code. Delphi by default doesn't show compiler statistics because for the average program you are working on as soon as you click the compile button the compilation is already done!!
Because of blazing fast compilation times one will definitly get in the spirit of using the debugger. First, you will get used to doing full recompiles once after you implement one method. Then you will get use to using breakpoints and watches to find bugs. I love using breakpoints, watches, evaluations, etc. It is the way to go. However, Visual C++ fosters bad debuging habits in the form of that stupid TRACE macro, or the Win32 API call OutputDebugString. It is like using printf to figure out the state of your program to try to figure out the bug.
I apologize for mentioning Visual C++ so much. I would love to use GNU C but professionaly speaking the only jobs I work on insist on using Visual C++, a brand name standard. Besides, most of the Linux people I knew prefered vi or emacs, hardly an IDE to the likes of Visual Studio and Delphi. Yeah, I know there is KDevelop and such others, but they are not as nice (and I was nausiated by the fact that KDevelop is literally a Visual Studio clone right down to also providing a Doc/View architecture, which is a bad architecture). On a side note though, I did try the Vi OLE control for Visual Studio because I do love vi alot
There is no Debug mode vs. Release mode in Delphi. Not that it was a bad idea but MS dropped the ball on it and Visual C++ has made Debug/Release mode style development a pain in the ass! Delphi doesn't put debug symbols inside your executable. Instead it keeps everything inside extermal files (.dcu files). When you are finished debugging you just had your executable off as is. Actually, there is a sort-of release build in the form of "turn of assertions", but this is not the same as Visual C++ release mode where the project settings are very different from Debug mode.
Last but not least, Borland is a company who, like Apple, is sticking around for quite a long time. People think they are going out of business, but they are not. So company support is there (managers like to hear that). Also, just like there is a Linux community, there is a Delphi community, full of resources, reusable code/components, and friendly developers who are willing to help you out.
On the negative side, if you are going to do some internet development then Delphi may not be for you. I have not used Midas or VisiBroker that much and I do not know how they truly fare against Java and
Nicholas
Damn! This sucks that there are so many comments already, this probably won't be read. Anyways.
;-) By the way, Delphi's interfaces were modeled after MS COM, and as a result COM programming is a HELL of a lot easier in Delphi than in Visual C++, including MS's stupid ATL crap.
I am sadened by the fact that nobody cares about Delphi, and that the only comments that mention Delphi aren't moderated up. I have used many languages (and I was impressed to see that this person mentioned looking at Eiffel, a nice language).
First off I have to say this, even at the risk of being flamed and called a troll. Either the geek culture is just ignorant, scared, or both. Stop feeling so insecure to the point where you have to use a difficult language to boost your ego. What I mean is try using a language that actually makes your life easier. I am so annoyed by these people who suggest C++. I have many years exprerience in C++ and let me tell you that it is not exactly your best friend on large projects, especially with coworkers who do not know the pitfalls of C++ programming.
Also, all you people suggesting ruby, or other new and/or obscure scripting languages, please give me a break. I like cool languages like Lisp and Snobol as much as the next, but I must admit to the reality that no real business and business project is going to go with these languages as the main development tool. There are some business that use Lisp and Smalltalk, which is cool. However, the reality is that the dominant language is C++, Java, VB, and maybe even C#. Stop suggesting languages that no clueless boss is ever going to approve of (cluesless bosses only know to use C++/Java, the buzzword language).
Now on to Delphi. Delphi is what you are looking for. First off, your requirements list is too unrealistic. You are going to to have to make some trade offs.
Delphi doesn't have operator overloading. Guess what? That is not critical. What's the difference between a + b and a.Add(b)? None.
Delphi doesn't do multiple inheritence. Guess what? If you are a good enough OO designer, you won't need it. Delphi supports single inheritence, multiple interface implementation style, just like Java and Smalltalk. So don't give that shit that multiple inheritence is needed, it is not.
Here is a quick OO design tip. I have noticed that C++ programmers like the multiple inheritence because they can have a class inherit from one class to gain capability, and then have it inherite from another class to establish communication (usually through an abstract interface). THIS IS A MISTAKE!! Golden rule of thumb, favor aggregation over inheritence. I am not going to exlpain myself on this (it would make this post too long). Take it from me, I have seen this in real projects, don't use inheritence to establish communication between objects. Use inherietence to vary state/behavior of a particular entity. Net result, designs such as these do not require multiple inheritence and are far more flexible and reusable.
Delphi is natively compiled, not like that p-code shit VB does. Delphi is made by Borland, which employs some of the brightest compiler designers around. Delphi is far more efficient than C++.
I have used C++ most of my career and I am still learning Delphi. I was skeptical of Delphi at first. But I gave it a try and did performance tests. For example, Delphi's for loops kick the shit out of C++ for loops. Another examle, Delphi's TList kicks the shit out of the STL vector and list containers. Don't be so ignorant, give it a try. I DARE YOU ALL YOU TROLL GEEK C++ PROGRAMMERS WHO FIND IT EASIER TO SAY DELPHI SUCKS RATHER THAN TRY IT!!
As for GUI, no contest! No contest!. You know easy VB is with GUI development, Delphi is even better (with more components by default than VB). People have mentioned Qt. I like Qt. It is orders of magnitude better than MFC (which is the WORST LIBRARY IN THE WORLD!!). But Delhpi's VCL is better than Qt.
Delphi does not have garbage collection. That is ok, its interfaces are automatically reference counted
I thought that Delphi would not be portable, but it turns out that Borland implemented something to simulate a lot of the Windows stuff under Kylix. As a result, porting should not be hard. I will not say that porting is a snap. I would be lying. However, porting should not be that bad, but YMMV.
End result, I used to love C++. But after using many other languages I started to despise C++. Delphi was the language that made me loathe C++. I do respect Troll Tech for making an excellent product. Qt is very impressive, but MS's MFC library is the cold reality that C++ is very deadly in the wrong hands. Visual C++ with MFC has to have caused more project slippage/failure than any other language in the history of programming (well, that is my opinion). I dare anyone to check out Borland's case studies of Delphi. Check out Deja news list of compilers, where the programmers got to vote. Delphi, despite probably the least used langugae, was voted number 1, followed by Borland's C++ Bulder. Visuall C++ and VB were at the bottom of the list with negative comments too!
May not be the best form of documentation, but the source code to X, window managers, and KDE/GNOME will have the answers. Got to imagine all these projects have had many different ideas implemented in each one.