Re: [fpc-devel] what fpc is good for?
Bisma Jayadi schrieb: http://z505.com/cgi-bin/qkcont/qkcont.cgi?p=Might%20As%20Well%20Use%20Dot%20Net%20In%20Place%20of%20FPC So a 3 MB lcl/lazarus application is bigger than a .Net framework? I know a lot of computers neither having 1.1, 2.0 or 3.x installed including mine. BTW: Why unstripped? Does he always deliever his applications with debug info included? Then he continues about server applications like cgi. What the hell has an lcl appliction to do with server applications? A command line hello world is 27k on win32. FPC programs consume less than programs written in any other language: http://shootout.alioth.debian.org/gp4/benchmark.php?test=alllang=allcalc=Calculatexfullcpu=0xmem=1 FPC applications start faster than anything else http://shootout.alioth.debian.org/gp4/benchmark.php?test=hellolang=all So what is his point about server applications? Then I stopped reading because the logic is below anything I've seen before. Nicely put. ;) I've found it has good points on some arguments. It's good to be considered. :) So you found anything usefull in it? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] what fpc is good for?
No, it is not good to be considered. He complains we don't care about speed or size. I have to correct him: We care, if we can optimize something we will. As a proof FPC 2.2 will both generate faster code and generate smaller exes. I believe FPC people do really care about speed and size since FPC is a compiler. I think the article isn't merely for FPC, but for Lazarus as well. If you don't consider FPC usefull for GUI programming, apparently he does't, the LCL disappears, and the problem disappears. No way you manage to generate 3MB exes without LCL. Agree. The size problem mostly come from LCL framework. I do understand the problem, but somehow other people are being scared by that. Somehow they forgot that .Net or Java framework requires lot bigger than LCL does. Meanwhile, we are near the top for speed, and at the top for memory usage: http://shootout.alioth.debian.org/gp4/benchmark.php?test=alllang=all I've been a while no longer visiting the shootout. But.. whoo that is indeed VERY IMPRESSIVE! Watch what happens with those numbers when 2.2 is out. You guys have done a great job! Thank you and congratulations! :) There is nothing in this article we can consider, for starters because it does not contain any proposals. As I said, maybe the article is more suitable for Lazarus people. ;) -Bee- has Bee.ography at: http://beeography.wordpress.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] what fpc is good for?
Op Sat, 12 May 2007, schreef Bisma Jayadi: There is nothing in this article we can consider, for starters because it does not contain any proposals. Moreover it lacks a sense for magnitude. What can be saved in the sysutils that is so dreaded by him is 40-80kb. (and then I really remove it. If you use parts it is less) Most of this are simple text msgs btw. The size behaviour of the VCL is also a known factor, and the LCL is about the same, with a small extra factor because it is portable and multi widget set. Non trivial Delphi GUI apps also quickly rise to 1.5MB, and nearly any other non-handcoded commercial GUI framework does (even though sometimes hidden in external libraries) However the biggest hint that it is all a bit exaggerated, straight from the size matters faq btw, is the fact that there hardly any cut down RTLs. If it is all that bad, surely sb would have stepped up. I think the big mistake comes in the third paragraph. FPC HAS been set up mainly as an application compiler. From the start, because TP and Delphi are. However this focus is relatively mild. (as demonstrated by spinning off Lazarus in a separate project). The author also seems to have a grudge about binary sizes, but fails to explain what exactly his problem is with binary sizes in the context he would like FPC to go. P.s. I also don't get the 64-bit gaming speed remark. What does a game do with 64-bit? Load 4 GB of textures on startup? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] what fpc is good for?
Op Sat, 12 May 2007, schreef Marco van de Voort: Op Sat, 12 May 2007, schreef Bisma Jayadi: There is nothing in this article we can consider, for starters because it does not contain any proposals. P.s. I also don't get the 64-bit gaming speed remark. What does a game do with 64-bit? Load 4 GB of textures on startup? Games will be among the first end user applications that really need 4GB. Commercial games currently released sometimes need 2 GB, it is a matter of time until it increases beyond 3GB, which is the limit for 32-bit systems. However, here the point is more moot than anywhere else, who cares about a few mb of exe for a game that requires gigabytes of memory and is often shipped on a 9GB dvd?! :) And needless, to say, FPC is very well prepared for 64-bit. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] what fpc is good for?
Op Sat, 12 May 2007, schreef Marco van de Voort: P.s. I also don't get the 64-bit gaming speed remark. What does a game do with 64-bit? Load 4 GB of textures on startup? Games will be among the first end user applications that really need 4GB. Commercial games currently released sometimes need 2 GB, it is a matter of time until it increases beyond 3GB, which is the limit for 32-bit systems. However, here the point is more moot than anywhere else, who cares about a few mb of exe for a game that requires gigabytes of memory and is often shipped on a 9GB dvd?! :) And needless, to say, FPC is very well prepared for 64-bit. One of the things I sometimes wonder about too is how far optimizations are, most notably on non-x86 (and that includes _64). Maybe make a wiki page out of it (implemented and to-implement?) Also instruction scheduling remains important, because in this weeks (german) C'T I saw Intel is also preparing embedded in-order x86 CPU's. (and at work I use C7's). ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] what fpc is good for?
Marco van de Voort schrieb: Op Sat, 12 May 2007, schreef Marco van de Voort: P.s. I also don't get the 64-bit gaming speed remark. What does a game do with 64-bit? Load 4 GB of textures on startup? Games will be among the first end user applications that really need 4GB. Commercial games currently released sometimes need 2 GB, it is a matter of time until it increases beyond 3GB, which is the limit for 32-bit systems. However, here the point is more moot than anywhere else, who cares about a few mb of exe for a game that requires gigabytes of memory and is often shipped on a 9GB dvd?! :) And needless, to say, FPC is very well prepared for 64-bit. One of the things I sometimes wonder about too is how far optimizations are, most notably on non-x86 (and that includes _64). Maybe make a wiki page out of it (implemented and to-implement?) FPC as well as gcc are worse on non x86 architectures, however, fpc performs usually better in relation. Also instruction scheduling remains important, because in this weeks (german) C'T I saw Intel is also preparing embedded in-order x86 CPU's. (and at work I use C7's). The problem of instruction scheduling is that it is really CPU specific. That's one of the reasons why the P4 lost performance wise: Athlon and Core/Pentium M perform well with blended code, P4 didn't. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] what fpc is good for?
On Sat, 12 May 2007, Bisma Jayadi wrote: http://z505.com/cgi-bin/qkcont/qkcont.cgi?p=Might%20As%20Well%20Use%20Dot%20Net%20In%20Place%20of%20FPC Nicely put. ;) I've found it has good points on some arguments. It's good to be considered. :) Yes, but the language used puts off some people. As far as I know, Lars is a FPC fan, and he merely wishes to express concern about some of the issues he has with FPC (I'll leave the matter of whether his concerns are justified up to others to comment on). This is OK, but flame wars have been started on less strongly formulated opinions. Even when it is expressly stated that the opinions are put in an exaggerated form, as he did at the end of the page. If you start with an exaggerated opionion, you can expect exaggerated reactions. It only goes to demonstrate that to be truly critical and constructive at the same time is by no means an easy exercise. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] what fpc is good for?
There is nothing in this article we can consider, for starters because it does not contain any proposals. It even tries to give directions on how to and how to not use a tool. Normally a tool proves itself usefull by being usefull in some way for someone. Now we got a ultraflexible, even changeable and adoptable tool. So why do we sit down and cry about the tool and give directions what to do with it and what not. Is it too expensive ? Can't we change it and make everything better what we want ? Or do we want that the tool magically adopt to our wishes without further work, even if that is not that what the tool constructors intended ? Everyone is able or limited to see only what he can imagine. So - What is FPC good for? After reading that i just have to state my opinion too by providing a so called success story. I program since i am 10 Years old - now i am 33 - so i have seen and tried many different things. I hacked firmware in assembler for microcontrollers - = 2 Weeks for 1000 Lines of Code tested, understood and working. I programmed firmware in C for microcontrolers used on hundreds of Devices. = 1 Week for 1000 Lines of Code tested, understood and working. But for my hobbies i always programmed in Pascal. And on an good day i program 1000 Lines of code understood, tested and working in just 1 Day. So after studying informatics me and a colleague made the hobby a profession. We develop programs, projects and solutions WE consider attractive using delphi and freepascal. Where the amount of freepascal solutions is 50% and rising. So what do we do with it? = Everything that is imaginable. Server applications on Linux using NPTL and servicing 1000 Clients simultanousely. Embedded solutions, databaseapplications and GUI Applications, Middleware. (We run a carrier grade Billing Solution for a Cable Net VOIP/SIP Provider here in Austria, using Freepascal, ZEOS, and PostgreSQL) So what is FPC good for ? - Maybe to make a big bunch of money using it. (we do) - Learn programming - look as deep into the sources as you like, even the compiler. - Program a Scene Demo in OpenGL, make a Game, or write a Delphi Killer like Lazarus. - Waste your time with Web Applications ... :-) (just to make some emotions too) - It enables that our firm with 4-5 Programmers sucessfully competes with firms employed 10-20 programmers. *) Object Pascal is a great Language allowing to make readable, understandable, small, fast and efficient code, if you provide the skills to use it. *) Freepascal is (IMHO) after the GNU C++ environment the most flexible free compiler providing a useful and professional framework, for a variety of architectures. Don't ever press FPC or Lazarus in a scheme, as it clearly depends on your skills, what you make out of it. It is even suitable to make an OS. I am humble, and gratefull that FPC is here allowing me to make my hobby my profession, to earn money and to spend more time with my family - and that there is a community which answer questions and helps on problems - as no one is able to do eveything alone. That is what is FPC good for ! helmut ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] what fpc is good for?
On 5/12/07, Bisma Jayadi [EMAIL PROTECTED] wrote: Nicely put. ;) I've found it has good points on some arguments. It's good to be considered. :) Everybody is entitled to their opinion. I am allowed mine and totally disagree with his statement about GUI's not being used on any other platform than Windows. And that FPC and Lazarus cannot be used for decent GUI applications. Our development team at Master Maths are busy rewritting our 3rd major version of our flagship product using FPC and Lazarus. Been working on it for over 1.5 years now and it isn't a small 'toy' project! Also it has to be cross platform (Linux and Windows) so Delphi could not be used!Our product consists of 4 applications all GUI based, talking to a backend Firebird RDMS. The product is a CBT system with Centre Admin side and Accounting module and the content it displays to learners are being designed using Adobe (Macromedia) Flash and has a size of around 7+Gig covering school grades from 1 though 12. We also have authors busy with the Science modules now. Our product is being used by 200+ franchisees and a few schools. Our current v2 system can only run on Windows and considering that every centre has 25+ computers, that's a lot of Micro$oft tax that they have to pay. Also they need a MS server license which adds a lot more to the cost. We are in the process of switching all those 200+ centres to Linux which will give them a significant money saving. No more costs for server software, licensing, upgrades, etc... All this made possible by using FPC and Lazarus - and all GUI based applications. Our product can also be used as a 'distance learning' product, where students can purchase a Maths Grade CD/DVD licensed for 1 year. They can then use that CD at home, be it on a Windows or Linux PC. Again a GUI only product. Mouse clicks are easier that command line interfaces! We are just one such South African company - there are many more. South African is a big sponsor of Open Source software and the Linux platform. Just my 2c worth... Regards, - Graeme - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] what fpc is good for?
I agree with Graeme. There are professional developers out here who want a decent cross platform product and who don't like the C/++/#/Java/.net/etcetcetc because of various reasons. My own reasons are that I find C(like) languages to be semantically weak and encouraging of bad programmer behaviour. I don't have time for dealing with that sort of inefficiency, so I need a more professional option in a language. Pascal(etc) provides that, and since Delphi isn't really broadly multiplatform (even though it is a terrific piece of work in it's own right), I am left in a pickle... or at least, I would be, except that FPC has provided the solution. So all these folks can have their scathing opinions of it. Indeed, this list, and all Pascal lists seem to be a place where people like to rock up an try to justify their own attractions to C(like) languages. I often wonder whom they are trying to convince, since the folks on a list like this one have probably already asked themselves those questions and moved on in favour of Pascal(like) languages. Conversely, you don't often see Pascal people baiting list members on C language lists (not that I subscribe to too many of those - although I am familiar with C(et al) and do it use from time to time (horses for courses). Anyway. I would like to say the all supporters of the FPC community - good stuff! Thank you thank you thank you. I have endless time and respect for you all. Keep it up! I don't have time for arguing the toss over C(like) languages and the claims of C-like superiority. I just need to get the job done and I know the right platform for it. Simple really. Industrial requirements require an industrial solution, and that's where we arrive at Pascal. Thanks again to you all for a great project! Cheers, Mark. Graeme Geldenhuys wrote: On 5/12/07, Bisma Jayadi [EMAIL PROTECTED] wrote: Nicely put. ;) I've found it has good points on some arguments. It's good to be considered. :) Everybody is entitled to their opinion. I am allowed mine and totally disagree with his statement about GUI's not being used on any other platform than Windows. And that FPC and Lazarus cannot be used for decent GUI applications. Our development team at Master Maths are busy rewritting our 3rd major version of our flagship product using FPC and Lazarus. Been working on it for over 1.5 years now and it isn't a small 'toy' project! Also it has to be cross platform (Linux and Windows) so Delphi could not be used!Our product consists of 4 applications all GUI based, talking to a backend Firebird RDMS. The product is a CBT system with Centre Admin side and Accounting module and the content it displays to learners are being designed using Adobe (Macromedia) Flash and has a size of around 7+Gig covering school grades from 1 though 12. We also have authors busy with the Science modules now. Our product is being used by 200+ franchisees and a few schools. Our current v2 system can only run on Windows and considering that every centre has 25+ computers, that's a lot of Micro$oft tax that they have to pay. Also they need a MS server license which adds a lot more to the cost. We are in the process of switching all those 200+ centres to Linux which will give them a significant money saving. No more costs for server software, licensing, upgrades, etc... All this made possible by using FPC and Lazarus - and all GUI based applications. Our product can also be used as a 'distance learning' product, where students can purchase a Maths Grade CD/DVD licensed for 1 year. They can then use that CD at home, be it on a Windows or Linux PC. Again a GUI only product. Mouse clicks are easier that command line interfaces! We are just one such South African company - there are many more. South African is a big sponsor of Open Source software and the Linux platform. Just my 2c worth... Regards, - Graeme - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] what fpc is good for?
Non trivial Delphi GUI apps also quickly rise to 1.5MB lazarus may produce apps that are size comparable with those from the recent versions of delphi but those are also megabloat compared to those produced by the older versions of delphi. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] what fpc is good for?
Nicely put. ;) I've found it has good points on some arguments. It's good to be considered. :) Yes, but the language used puts off some people. Yup. Sometimes Lars sounds to aggresive. :-D As far as I know, Lars is a FPC fan, and he merely wishes to express concern about some of the issues he has with FPC (I'll leave the matter of whether his concerns are justified up to others to comment on). Yes, like the rest of us here, he's also a big fan of FPC. He even using FPC and PWU professionally, he makes his living over FPC. So, he's not the enemy! He knows all the best of FPC and Lazarus because he uses them on daily basis. PWU is one of his contribution back to the FPC community. If you start with an exaggerated opionion, you can expect exaggerated reactions. Yes. Maybe it's my fault if everybody then looks at him in a negative way because of his own article. But, he published that article in his public paswiki, somebody else will find it anyway, sooner or later. It only goes to demonstrate that to be truly critical and constructive at the same time is by no means an easy exercise. Anyway, it did happened to me as well long time ago. ;) Programming language community is indeed a very sensitive community, we must write in a very polite manner if we want to criticize anything about the language. :) -Bee- has Bee.ography at: http://beeography.wordpress.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] what fpc is good for?
it does not contain any proposals. Everyone is able or limited to see only what he can imagine. Helmut, till now, in this discussion I like your answer the best. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] what fpc is good for?
Non trivial Delphi GUI apps also quickly rise to 1.5MB lazarus may produce apps that are size comparable with those from the recent versions of delphi but those are also megabloat compared to those produced by the older versions of delphi. megabloat? A million times larger? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] what fpc is good for?
I agree with Graeme. There are professional developers out here who want a decent cross platform product and who don't like the C/++/#/Java/.net/etcetcetc because of various reasons. My own reasons are that I find C(like) languages to be semantically weak and encouraging of bad programmer behaviour. I don't have time for dealing with that sort of inefficiency, so I need a more professional option in a language. Pascal(etc) provides that, and since Delphi isn't really broadly multiplatform (even though it is a terrific piece of work in it's own right), Small addition: For me a strong reason for both FPC and Delphi compared to the others is that single exe deployment is still so doable. For a lot of small stuff that I only deliver once, I don't want to set up a complicated deployment system, or argue with external IT departments about the addition of runtime libraries. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] what fpc is good for?
On Sat, 12 May 2007 05:04:33 -0500, Michael Van Canneyt [EMAIL PROTECTED] wrote: As far as I know, Lars is a FPC fan, and he merely wishes to express concern about some of the issues he has with FPC (I'll leave the matter of whether his concerns are justified up to others to comment on). It is always useful to listen to others, regardless of the language used. The man has some valid points. It only goes to demonstrate that to be truly critical and constructive at the same time is by no means an easy exercise. Completely true. Since this article seems to have stirred some debate I will take the libery to comment some aspects of it as well as express some of my personal opinions. Now, before anyone reads further, I want to state two things: One, I have deep admiration for the FPC developpers who have created a fine compiler from scratch. Two, the next few paragraphs are written from the view point of a long-time delphi/win32 developper, so don't take them personally. Some comments about the article: 1. Linux is indeed used mostly for server apps. This is a fact. One can speculate until kingdom come why this is the case. My personal opinion is that Linux is simply a shitty desktop platform: i. There is lack of a standard graphical api (or toolkit). For example, the idiots from throlltech constantly change the entire framework. (Qt2 is different form Qt3, which is different from Qt4. They are not semantically compatible. Attempts to run binary Qt2 libraries on newer distributions cause bizarre problems such as memory clashed with libstdc++, for example). Regardless of the toolkit, one cannot expect simple things, such as an X toolwindow hint to produce consistent results. No matter what, a win32 program that ran on 95 and 3.51 will still look OK today. ii. Linux prevents people from distributing binary applications: The gcc /kernel people constantly change things. So, one cannot develop and forget. You are either forced to release the source code so that the app you are developping can be recompiled after the newest kernal/libc/++ change. The alternative is to constantly mainatin a once developped program and provide ten thousand binary variants for ten thousand distributions. And update the binary of your app every month. The later option is generally available only to large commercial organizations. Again, a win32 program that ran on 95 and 3.51 will still run and look OK today. 2. With respect to graphical applications, the man completely wrong by stating that: FPC is a C++/C/D killer. Not a Delphi killer or a Visual Basic killer. It is plain clear that neither FPC will, nor Kylix did convert a s single, mildcore vi/gc fan to object pascal. There is absolutely no conceivable way this will happen. Those who use vi and fpc, please raise your hands :-) This is actually the main reason Kylix failed: they targeted linux gui developpers. I encourage everyone to read this enlightning analysis: http://delphiroadmap.untergrund.net/A_cross-platform_vision_for_Delphi/index.html 3. As a delphi developper I have the following issues when considering FPC (I hope the following is not taken badly, I am just stating facts, as I see them): i. Too many bugs in any official release. This is unavoidable, considering the many platforms and targets supported. But it is a fact. ii. In any stable release, there are always some incompatibilities with Delphi. Which means that Delphi developpers will have to put an extra effort (in the form of $IFDEFs) to make their code compatible. In that respect the lack of an Object Pascal standard in the form of some ISO specifications is partially to blame. Given the fact that Linux IS NOT a Desktop platform, this simply means that object pascal people will keep on developping for Delphi/win32. It is a catch 22: Until borland delivers a quality multiplatform tool, no delphi developpers will do linux (exceptions do not change the rule). And until there is no serious demand for linux GUI apps there will be no motivation for borland to develop a stable, reliable, bugfree, multiplatform compiler+VCL. When I say demand for GUIs, I mean a secretary wishing to play her favourite solitaire game (one of the many hundreds of office style games, which were released for win95 and whose developpers are certainly doing something else today), or a college student using his/her favourite graphical plotter app for win32, or a more traditional type, who prefers ICQ2003b istead of the newer versions, etc. For example, my favourite browser is Opera. On win32 it looks and runs fine. On slackware 10.1 it looks and runs fine. On debian it hardly runs and looks like a crossover between a frog and a polar bear. My office computer runs debian and I am not the admin, so I cannot do anything. To summarize, if there is any chance for a large number of developpers
Re: [fpc-devel] what fpc is good for?
Hi, Ok, you dragged me into responding this subject as well :) While it might sound as such, this is not Windows vs Linux fight, only a point of view for an ex Delphi developer, and a 5 years of Linux users (as only OS). On 5/12/07, Peter Popov [EMAIL PROTECTED] wrote: On Sat, 12 May 2007 05:04:33 -0500, Michael Van Canneyt [EMAIL PROTECTED] wrote: As far as I know, Lars is a FPC fan, and he merely wishes to express concern about some of the issues he has with FPC (I'll leave the matter of whether his concerns are justified up to others to comment on). It is always useful to listen to others, regardless of the language used. The man has some valid points. It only goes to demonstrate that to be truly critical and constructive at the same time is by no means an easy exercise. Completely true. Since this article seems to have stirred some debate I will take the libery to comment some aspects of it as well as express some of my personal opinions. Now, before anyone reads further, I want to state two things: One, I have deep admiration for the FPC developpers who have created a fine compiler from scratch. Two, the next few paragraphs are written from the view point of a long-time delphi/win32 developper, so don't take them personally. Some comments about the article: 1. Linux is indeed used mostly for server apps. This is a fact. One can speculate until kingdom come why this is the case. My personal opinion is that Linux is simply a shitty desktop platform: i. There is lack of a standard graphical api (or toolkit). For example, the idiots from throlltech constantly change the entire framework. (Qt2 is different form Qt3, which is different from Qt4. They are not semantically compatible. Attempts to run binary Qt2 libraries on newer distributions cause bizarre problems such as memory clashed with libstdc++, for example). Regardless of the toolkit, one cannot expect simple things, such as an X toolwindow hint to produce consistent results. No matter what, a win32 program that ran on 95 and 3.51 will still look OK today. Ammm.. I'm a Linux user, so let me give you my point of view: Microsoft on any given new version of Windows *changes* API, changes libraries and technology, making even newer (the previous version was the first to have it) technology obsolete on a new version of an OS or a program. As example take a look at GDI+ (if I remember the name correctly). I do not know many people that changes their kernel and libc once every new version. In fact while Windows release time is one in 5 years, on the Linux world it is every 6 months ! So as long as you keep yourself with what arrives with specific distribution, you will end up having problems, but note, that there are development versions of Windows, that companies can change the OS as well, so you will also require to change your tools for every such version, and also for every new version of Windows (because the kernel is changes ...). If you are looking for a standard way of creating GUI apps with something that never changes, try to use xlib and xtoolkit. As long as the X11 protocol is in use, they never changes :) But as you can see, you are loosing a lot of features that might be added that way. For the QT from Trolltech, while I do have some issues with them, they do try and make support also for the GTK library in the area of styling. How many programs under Windows do you know that the GUI was designed regardless of the GUI toolkit that comes with Windows ? Even Microsoft does this with their Office suites... Every version of the Office suite, gives you a different look and feel. Take a look at Microsoft Office 2007, it's so different then anything else that most people just don't understand how to use it. Or you can take the IE7 vs IE65432 ... ii. Linux prevents people from distributing binary applications: The gcc /kernel people constantly change things. So, one cannot develop and forget. You are either forced to release the source code so that the app you are developping can be recompiled after the newest kernal/libc/++ change. The alternative is to constantly mainatin a once developped program and provide ten thousand binary variants for ten thousand distributions. And update the binary of your app every month. The later option is generally available only to large commercial organizations. Again, a win32 program that ran on 95 and 3.51 will still run and look OK today. As I said above, the ABI changes from version to version on ANY OS even Windows... But While Windows create new version every 5 years, Linux releases more often, but most distributions releases new version every 6 months ... There is a quotation that say the price of freedom is endless violence. There are two point of view for things. Windows have both ways (SP can change the ABI/API as well, as SP2 made for Windows XP). And on Linux, you can have them both, but the easier way is just to deploy the code for every version, or to point things
Re: [fpc-devel] what fpc is good for?
A.s. I already deleted it, but quite some older apps break on Vista now. Including e.g. Delphi 7. MS is also deviating from the compat path. Unfortunately. i. Too many bugs in any official release. This is unavoidable, considering the many platforms and targets supported. But it is a fact. This is a bit vague. I assume you mean bugs of the blocking kind. Do you have examples? ii. In any stable release, there are always some incompatibilities with Delphi. Which means that Delphi developpers will have to put an extra effort (in the form of $IFDEFs) to make their code compatible. In that respect the lack of an Object Pascal standard in the form of some ISO specifications is partially to blame. Yes. Failure of Delphi users to have any consensus about what is compiler behaviour, and what is language behaviour. Every bit of behaviour that Delphi exposes is considered gospel. To summarize, if there is any chance for a large number of developpers adopting FPC, they will have to come from the delphi crowd in the form of people willing to do a little extra work of compiling their existing code with FPC. This is the essence of Simon Kissel's proposal to Borland for cross-kylix compiler. I sincerely hope that one day this will become a reality with FPC. I've some doubts about that. One possibly end up in the same catch-22 we somewhat have been in TP/BP times. In the Turbo Pascal NG, there was sb declaring for about a decade that FPC was close, but not there yet, because it could not compile his TP code full of dosisms and 16-bit asm. IMHO this is also why Kylix failed. It was geared too much to float on a Linux-on-desktop hype, hoping to force a lot of Delphi apps to be recompiled on Linux because it-is-so-easy. It failed. Borland management probably assumed that the recompilation market was larger than the invest in new linux products markets. However the recompilation market fell victim to its own assumptions because it had to deliver a way smoother transition, which failed in a still to volatile delphi world. Compability is good, but should be a enabling factor to do stuff with FPC/Lazarus, not the end target for blind recompilation itself. Because then it will be just-not-good-enough forever. One can also see this currently with FPC. Major Delphi component builders start using FPC/Lazarus. They want to do things, and their customers are doing things, while FPC/Lazarus is not really registering en masse on A final remark: the vast majority of pascal users use Delphi. So if fpc is to attract a lot of them, compatibility with delphi must be 100%. These kinds of claims always promise heaps of users, but there are several problems with it: - Only a fraction of users will defect to run a clone. Most will either move on to the next big thing (Java/.NET) that has a lot of publicity, or stay as long as possible with Delphi. This also because they will never leave Delphi in the first place till it is really dying (because of its OS, or the toolchain competition) - The compability is never enough. Compromises (e.g. for portability) are not accepted, because their goal is only to get the code running, regardless of its quality or portability aspects. The big break is always another year away, when the compability is another magnitude bigger. - At some point the amount of compability you can add without effectively emulation e.g. winapi stops. We are building a compiler, not Wine. - At the same time you are alienating and neglecting your real users that do stuff with FPC. - At some points the heaps of commercial components are the real limitation, not the compiler. Porting is hard due to practical concerns relating to their closed source nature. Also there is another big danger: Even if bunches of users would convert to recompile their old Delphi stuff with FPC to give it another few years, what does it yield for FPC? These are all people planning to abandon the platform. Do you think they are going to invest majorly? f there is only one incompatibility with a known workaround, a delphi developpers will live with it. If there is a single major thing, one can try to fix it himself. But if there are 10 or 20 small things then most delphi users will give up supporting multplaform/fpc targets. How much will they add to FPC/Lazarus if they are not willing to invest that? Of course it is not black and white, but sb must report and fix those 10 or 20 things, (and those are not necessarily the same people). Somebody working on a project that invests real time in a FPC solution are way more likely to play a part in that, than people looking for a quick recompilation fix. Unless your boss pays you to port delphi apps to FPC. Now, I can understand that the FPC team has put a lot of effort in making a compiler from scratch and it is natutal to do things differently. But it will be a big boost for FPC if delphi compatibility stops being
Re: [fpc-devel] what fpc is good for?
On Sat, 12 May 2007 15:40:49 -0500, ik [EMAIL PROTECTED] wrote: Hi, Ok, you dragged me into responding this subject as well :) While it might sound as such, this is not Windows vs Linux fight, only a point of view for an ex Delphi developer, and a 5 years of Linux users (as only OS). Correct. Well, it certainly sounds like, but it is not. I did not make a single statement regarding which one is better. My claim is that they are different - one is more popular, and I stress popular, for desktop applications, the other for server ones. Ammm.. I'm a Linux user, so let me give you my point of view: Microsoft on any given new version of Windows *changes* API, changes libraries and technology, making even newer (the previous version was the first to have it) technology obsolete on a new version of an OS or a program. As example take a look at GDI+ (if I remember the name correctly). Of course it changes. But the majority of gui applications are compatible with newer versions of windows (up to vista), all the way from 3.51. And the compatibility comes at no cost (in terms of time) to the sysadmin. There are exceptions, mostly confined to system level applications, such as firewalls. This however is natural and cannot be helped on any OS. My only point is: this feature of windows makes it really easy to develop and forget. I am not claiming one is better, the other is not. I do not know many people that changes their kernel and libc once every new version. My sysadmin recently changed to 2.6.?? which broke the kylix debugger (2002). As a comparison, bcc 5.0 (1996) runs perfectly fine on xp. ... are you willing to help the team and add features that are missing in your opinion ? Yes. In particulr, I would like to do something about this item: http://www.freepascal.org/mantis/view.php?id=8783 On Sat, 12 May 2007 16:42:43 -0500, Marco van de Voort [EMAIL PROTECTED] wrote: A.s. I already deleted it, but quite some older apps break on Vista now. Including e.g. Delphi 7. MS is also deviating from the compat path. Unfortunately. Unfortunately, indeed. i. Too many bugs in any official release. This is unavoidable, considering the many platforms and targets supported. But it is a fact. This is a bit vague. I assume you mean bugs of the blocking kind. Do you have examples? Well, I did not want to put any specific examples which would necessarily be personal and would shift the focus of the discussion. I've mentioned a few later on... ii. In any stable release, there are always some incompatibilities with Delphi. Which means that Delphi developpers will have to put an extra effort (in the form of $IFDEFs) to make their code compatible. In that respect the lack of an Object Pascal standard in the form of some ISO specifications is partially to blame. Yes. Failure of Delphi users to have any consensus about what is compiler behaviour, and what is language behaviour. Every bit of behaviour that Delphi exposes is considered gospel. That is true and is compounded by the fact that there is no ISO standard. Furhtermore, delphi users cannot insist that an independent compiler group should do something their way. IMHO this is also why Kylix failed. It was geared too much to float on a Linux-on-desktop hype, hoping to force a lot of Delphi apps to be recompiled on Linux because it-is-so-easy. It failed.Borland management probably assumed that the recompilation market was larger than the invest in new linux products markets. However the recompilation market fell victim to its own assumptions because it had to deliver a way smoother transition, which failed in a still to volatile delphi world. I don't know if borland targeted the recompilation market or new linux developpers. If they wanted the recompilation market they should have single sourced the VCL. They should have released a reasonably bug-free multiplatform VCL. They should have priced it much cheaper and integrated the compiler into the win32 ide for cross-compiling and so on. It is actually useful to study why they failed. Kylix is certainly dead, but finding out why will help others... Some interesting views can be found here: http://delphiroadmap.untergrund.net/A_cross-platform_vision_for_Delphi/index.html Compability is good, but should be a enabling factor to do stuff with FPC/Lazarus, not the end target for blind recompilation itself. Because then it will be just-not-good-enough forever. One can also see this currently with FPC. Major Delphi component builders start using FPC/Lazarus. They want to do things, and their customers are doing things, while FPC/Lazarus is not really registering en masse on I agree. Actually, both are important and there should be a reasonable balance. FPC is targeting several different cpu architectures on many different os platforms. This alone is attractive to server side developpers. On the other hand, say any
Re: [fpc-devel] what fpc is good for?
Peter Popov wrote: Yes. Failure of Delphi users to have any consensus about what is compiler behaviour, and what is language behaviour. Every bit of behaviour that Delphi exposes is considered gospel. That is true and is compounded by the fact that there is no ISO standard. It's significance must not be overrated. See the relative incompat of older MSVC++ compilers. victim to its own assumptions because it had to deliver a way smoother transition, which failed in a still to volatile delphi world. I don't know if borland targeted the recompilation market or new linux developpers. I think so. If they wanted the recompilation market they should have single sourced the VCL. I guess that was not possible without compromising their main moneymaker. They should have released a reasonably bug-free multiplatform VCL. They should have priced it much cheaper and integrated the compiler into the win32 ide for cross-compiling and so on. It is actually useful to study why they failed. I think that is revisionism ( also a problem in Simon's article). At that time the Linux hype was at its peak, and navigating the dangers of being stoned to death by the Linux opinion makers was a top priority. ALSO crosscompilation maybe. But only crosscompilation was marketing wise not doable I think. Kylix is certainly dead, but finding out why will help others... Some interesting views can be found here: http://delphiroadmap.untergrund.net/A_cross-platform_vision_for_Delphi/index.html I know the article. I've commented extensively on it when it came out in the relevant Borland groups. developpers. On the other hand, say any stable fpc release should be able to compile (on win32), without trouble the entire VCL of say, delphi 2-5. I don't see why that is a focus point. It's a nice testsuite, but until it is free, there is no real benefit in it. Specially since the VCL-RTL separation is not complete, and neither is the compiler - RTL separation. - I've had recurring problems with open arrays on various final releases. Some issues were fixed by the developpers, for other there was no agreement what the language standard should be so I had to make workarounds Yes. I assume that was the cdecl one? Since nearly any standard doesn't cover much details about external linking, and general link and calling conventions issues, I doubt a language standard would make this go away. THe other one was fixed. Also, it is not clear if functions with open arrays can be exported/imported safely in dlls, as I don't know what is the internal representation of an open array in FPC. I'd guess it is safe for fully static types, and not safe for types allocating memory. So ansistrings and dynarrays, no. - Static linking requires some minor code modifications in comparison to kylix (they had their internal linker, so things can't be the same) (some were fixed for CrossFPC) - Minor issues in the FPC RTL force various workarounds. E.g. http://www.freepascal.org/mantis/view.php?id=8578 This is unavoidable, without freezing the scope of the project to produce a minimal clone. I do a lot of porting (Jcl, Indy, ICS, Decal among others), and while such issues are constantly discovered and fixed, the ones that stay like this are extremely rare. - Various features that use the internal RTTI of delphi. For example delphi 2 generates useful RTTI for automated methods, Delphi 6 for published method (in conjunction with a weird compiler directive). Clearly this is not a language feature, so one cannot insist the FPC should do things the same way. Unfortunately, currently this is a blocking issue for me. Yes. The problem in this case is clear. Automated is deprecated and rarely used functionality. (like e.g. dynamic methods). A final remark: the vast majority of pascal users use Delphi. So if fpc is to attract a lot of them, compatibility with delphi must be 100%. These kinds of claims always promise heaps of users, but there are several problems with it: - Only a fraction of users will defect to run a clone. True, but the delphi crowd is (well, still is) large. So a small fraction is not bad at all. Keep in mind that the actual project success is not measured in numbers. We don't get anything per download, we are paid in project activity and bugreports and patches. A higher focus on compability would hurt badly in other area's that do deliver pay. And since the bulk of the users you pull in with such an extreme (and costly) focus on compat is of the low pay kind.. Besides it is not only about defecting. What if FPC is available as cross-compiler inegrated in Borland's windows IDE? Do you ever see that happen in a scale that matters? Personally I can see FPC server applications running on a bizarre patform and a client side compiled with delphi. Oh, sure. But I don't think that that will shift the balance in any way. - The
Re: [fpc-devel] what fpc is good for?
As far as I know, Lars is a FPC fan, and he merely wishes to express concern about some of the issues he has with FPC Yes I'm a fan. It's not just the issues that I alone have with FPC since I'm not even an embedded programmer myself. I'm putting myself in their shoes. It isn't just me who is saying lazarus is on the edge of becoming the next OpenOffice sized bloatware. It is a lot of the folks on pascal game devel board too who are saying the same thing. Now to address the other people's emails.. Regarding my comments about D/C++ killer.. You guys are nitpicking me. Regarding the idea that I don't propose any solutions to the problem. Come on now, I've written capstring and compactsysutils and many other units to solve many of my problems that I complain about. The point of the articles are always to point out that FPC isn't this *perfect* fanboy thing - instead of being a *fanboy* I find myself more productive jumping into a criticboy's shoes, while contributing code at the same time. Criticism and complaints are just like bug reports. Without these reports, we all just sit behind our PC's thinking that there is no room for improvement because FPC is already so good. I think some of you should look at this URL below too, with regards to Java history and why Pascal had a big influence on Java: http://z505.com/cgi-bin/qkcont/qkcont.cgi?p=Pascal%20is%20An%20Unrecognized%20Underdog Above is one of my optimistic articles and doesn't contain too much pessimism. Just because you have seen not too many C programmers float over from C and join the Pascal community, does not mean that D programmers and C++ programmers and Java folks won't join ship. In fact, over at PasForum there is a PHP/C programmer who is considering using the powerful web utilities. Looking over my web statistics, I have found quite a few people looking for D language information, and they bookmark my site since they accidentally stumble upon some of my pages which mention D language. They realize that pascal seems interesting and more mature than D, and that is a big advantage. D is new. Pascal is mature. Whenever Linus Torvalds takes cheapshots on the Pascal language, I sometimes respond to the articles and I get some reasonable C programmers coming in to my site, and they see that current pascal isn't just a dead end.. and some of them jump ship and test out FPC. Maybe not millions, but one or two can even make a difference to spread the word. In fact some of us Pascal programmers are so humble and so positive, and so anti-critical, that we misinterpret Linus' flames on pascal as compliments to pascal. He said something once that was so rude to Pascal, and everyone thought he was complimenting pascal. Funny. (Bee, this was the structured vs unstructured article on kernaltrap, I think) Anyway, as we discussed on IRC one time, the real problem with Sysutils is that it needs to be split up into smaller units but we would break Delphi compatibility. The problem with LCL is that a lot of initialization stuff may need to be moved out. I may not have a PERFECT proposal for that myself.. figuring out what we are going to do about that, so I complain and write an article and maybe other folk will come up with brilliant ideas. Do you see why it is important to write thoughts down, including both negative and positive ones? Even if I have tried to solve some of the problem by offering code such as capstring and compactsysutils, it still helps for me to get the thoughts down on paper and have hundreds of other developers think up solutions based on my comments - even if exaggerated. I'm not just complaining about sysutils and LCL being bloatware regarding exe size, I'm looking at a bigger picture here - it is bloatware as a piece of source code to maintain, too, you know. It is hard to maintain the sysutils unit with all the include files and millions of functions and classes in it. The LCL - well I am not an expert there and I hoped someone else would find a way to make it less monolithic. Sorry for complaining and not offering any LCL code. Putting a complaint out there in the air is like putting a bug report out there - I may not have a solution to the bug but at least I reported a possible issue. I also complained and complained about websnap and asp and php, and of course I also wrote some code that solved my problem there which is all FPC based, the poor old wiki, forum, and other utilities on my site that need updating. Others choose the easy solution and use ASP and PHP.. boring. I complained about FPDOC and wrote some extensions for my own lufdoc, and I complained about numerous other things and went ahead and wrote code. I will offer you folks some system.pp units that I'm sure will help the embedded programmers too. I also complained about a web based FPC compiler being a silly idea, since people could just download the compiler.. how hard is that.. but then I went on and wrote
