Well-aged Online Information (it's not wine!) lazarus / 21-General ---------------------------------------------------------------------- Curt Carpenter · 2024-11-11 19:56 Quite a bit of the fpc/lazarus-realted documents you can encounter online are well over ten years old, and fpc/lazarus has clearly moved on in that period of time.  So a general question:  at about what age should information online be treated as probably obsolete and not worth studying?  For example, some of articles by Michael Van Canneyt here predate 2008:  https://www.freepascal.org/~michael/articles/. I know "it depends," but in general how old is too old to be worth the time investment? ---------------------------------------------------------------------- marcov · 2024-11-11 22:39 It depends :-) ---------------------------------------------------------------------- TRon · 2024-11-11 22:57 Same answer as marcov  However, even if the information is outdated it enriches my understanding of the topic. For me personally it does not really matter if the information is actually outdated, as it is more about the thought(s) behind it that counts. Even code from the 80's that do not have any meaning in this day and age is able to provide valuable insight on how to approach a certain topic. In general I find Michael's articles precise and to the point. 2 cents ---------------------------------------------------------------------- jamie · 2024-11-11 23:44 Thank you for that link, added to favorites!. ---------------------------------------------------------------------- Warfley · 2024-11-12 00:08 Well there is a lot more features in the FPC today than there was some time ago, BUT... the old way of doing things is still around and many people actually prefer it. For example, many people used Pascal 10 or 20 years ago or even longer, and if they want to get back into it, you still can program like its 1998. Simultaneously there are a lot of old Pascal codebases, written in TP or older Delphi versions, which can be ported to FPC easily. And either they have to run in old modes to be backwards compatible, so new Features are not possible, but also it is generally not a good idea to mix coding styles within a codebase. So all of that old information is often far from outdated, it still has a lot of value. That said, whats missing is some resources about new programming styles and paradigms. Generics, advanced records with operator overloading, management operators, etc. allow for a lot of very interesting stuff. I myself spend vast amounts of my free time just trial and erroring around what new things are possible by now and there are now completely new ways to write your code But I often feel like that it's hard to communicate these concepts because they are just not that well understood, because a lot of people still program, out of necessaty or habit, still like its the early 2000s and Delphi 7 just came out. But I think it's not just resources, it's also often times that the RTL, FCL and LCL are still quite tailored to the "old" style of doing things. There is some change in that, I have contributed some of the things I built over the years myself, but when you look into many of the FCL or RTL packages the function headers often say dates starting with 200X. I just looked at fpjson, because for some reason that was the first unit that came to my mind when thinking about fcl, and it was written in 2007. Sure the unit works and is certainly usable but if I'd redesign the unit with modern Pascal from the ground up, I would do a lot of things certainly different. E.g. you could use reference counted COM interfaces with operator overloading to have transparent conversion between base types and json data. Use TNullable with it's upack, getordefault and co method instead of the dozens of overloads with default and find methods, etc. Code could be as simple as: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i json := [  Pair('Key1', 'Value1'),  Pair('Key2', 3.14),  Pair('Key3', [    42,  'Hello World',    [      Pair('Subkey1', True)    ]  ])]Instead of Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i json := TJsonObject.Create;json.Add('Key1', 'Value1');json.Add('Key2', 3.14);jsonArray := TJsonArray.Create;jsonArray.Add(42);jsonArray.Add('Hello World');subObject := TJsonObject.Create;subObject.Add('Subkey1', True);jsonArray.Add(subObject);json.add('Key3', jsonArray); ---------------------------------------------------------------------- Thaddy · 2024-11-12 06:48 I am one of the dependers. Some old code, however, is not worth translating, e.g. if 16bit basm is used for sound and the likes. Unlike what @Warfley writes it is possible to a certain extend to add new features to old code using modeswitches but I usually try to remove deprecated code and replace it if I feel it is necessary or warranted to do partial rewrites. It is not recommended to mutilate a certain mode, say, TP mode, but it is actually lots of fun to write your own bastard mode by playing with modeswitches and also HAS_FEATURE_XXX Being mostly on trunk, I tend to use loads of modeswitches anyway. ---------------------------------------------------------------------- marcov · 2024-11-12 08:44 Warfley: I assume long term it will all go to system.json as that is delphi compatible ---------------------------------------------------------------------- Bogen85 · 2024-11-12 10:23 Quote from: Warfley on November 12, 2024, 01:08:36 amWell there is a lot more features in the FPC today than there was some time ago, BUT... the old way of doing things is still around and many people actually prefer it. For example, many people used Pascal 10 or 20 years ago or even longer, and if they want to get back into it, you still can program like its 1998. Simultaneously there are a lot of old Pascal codebases, written in TP or older Delphi versions, which can be ported to FPC easily. And either they have to run in old modes to be backwards compatible, so new Features are not possible, but also it is generally not a good idea to mix coding styles within a codebase. Not everyone has the luxury for the bulk of what they do computer wise of being in programming environments where being a decade or two behind is more than adequate. Yes, FPC has new features, but in most forward moving sectors in the computing industry those new features are not enough (while it is possible tooling and libraries could make up for some of that, the necessary momentum is not there) , and holding on to doing things the old way is counter productive. But I agree. If the old works for what you do, stick with it. But if you need the new, migrate to the new and focus on that, and it is best not to mix. ---------------------------------------------------------------------- Warfley · 2024-11-12 11:50 Quote from: Bogen85 on November 12, 2024, 11:23:45 amNot everyone has the luxury for the bulk of what they do computer wise of being in programming environments where being a decade or two behind is more than adequate. Yes, FPC has new features, but in most forward moving sectors in the computing industry those new features are not enough (while it is possible tooling and libraries could make up for some of that, the necessary momentum is not there) , and holding on to doing things the old way is counter productive. There is no right or wrong way to develop. No matter at what level you look, you see both conservative and modern language approaches. In the low level area both C and C++ are extremely popular, with C only getting a hand full new features every decade or so, while c++ is basically a completely new language every major revision of the standard. Also in the higher level world you have languages like java or go, which evolve extremely slowly, and you have languages like C# or Swift that adopt new features rapidly. There is no clear preferable solution. Personally I love playing with new concepts, but sometimes working in an environment where there is just one clear way to do something can be very beneficial. I often recognize myself working in C++ that I spend more time thinking about what's the most elegant way to do something, while in C I just do it the only way possible. And even though the C way is often more painful, it's somehow relieving being able to just concentrate at the problem itself and not on the language features that may facilitate the solution. And this is why C is still so popular, and C++ or rust or any other feature packed modern language will never replace it. ---------------------------------------------------------------------- wp · 2024-11-12 11:52 Quote from: Curt Carpenter on November 11, 2024, 08:56:49 pmFor example, some of articles by Michael Van Canneyt here predate 2008:  https://www.freepascal.org/~michael/articles/. I think these articles are extremely valuable. Their age is no argument that they might be out-dated. ---------------------------------------------------------------------- Thaddy · 2024-11-12 12:28 No, it is not, the articles are very good indeed and all principles hold and most if not all fpc specific code still works. (there are exceptions to some of Delphi specific code relying on libraries no longer available) ---------------------------------------------------------------------- VisualLab · 2024-11-12 16:43 Quote from: Warfley on November 12, 2024, 12:50:15 pmAnd this is why C is still so popular, and C++ or rust or any other feature packed modern language will never replace it. I disagree! The C language will be replaced, probably on February 31, 2124. A week later, Linus Torvalds' great-grandson will release the Linux kernel written in Python, and nVidia will provide the source code for its graphics card drivers for Linux, written in JavaScript. Microsoft will launch a new operating system: Doors, written in Object Pascal. This system will run on 1024-bit RISC-V processors and will primarily serve to display advertising using AI. Hardened programmers of the new trend will write in Rust, using the hundred-year-old VSCode. At that time, two new programming concepts will appear in Rust: stealing a variable and buying a variable. And the few 150-year- old C++ programmers will have a new solution for automating project building: CMakeMake++. This tool will be based on a new programming language that will use pure functions, statelessness and monads and will generate code for CMakeMake, which will in turn generate code for CMake++, which will in turn generate code for CMake, and then it will be easy, because that's how it's done today ---------------------------------------------------------------------- Curt Carpenter · 2024-11-12 17:05 Here is perhaps a better example of the "too old" material on the internet:  https://www.bastisoft.de/programmierung/pascal/pasinet.html .  In this case, the author added the helpful "caution" at the top of the page, but that's unusual,   It wasn't my intent to aim any criticism at Van Canneyt's many contributions.  (I still have my old copy of Mastering Turbo Pascal 5.5 and my TurboC Reference Guide). ---------------------------------------------------------------------- Thaddy · 2024-11-12 17:25 Well, At least C makes you THINK before you use it - otherwise it won't work at all -, but it is a horrible concept and just for productivity. Whereas Pascal is derived from thinkers, loved by thinkers, and also works for mere mortials. You can't always get what you want, although Pascal and Cobol payed my pension, not C! (well, a little, as did Java) But my pension is OK and I am enyoing it. (apart from the Dutch government changing the rules of the game mid- life and it is not 65, but 67'sh, stealing two years of income. BTW I agree with that theft!, the French could read this, with their 60 years.... silliy  ) ---------------------------------------------------------------------- VisualLab · 2024-11-12 18:43 Quote from: Thaddy on November 12, 2024, 06:25:08 pmWell, At least C makes you THINK before you use it - otherwise it won't work at all -, but it is a horrible concept and just for productivity. Whereas Pascal is derived from thinkers, loved by thinkers, and also works for mere mortials. I hope Dennis R. and his helpers burn in hell At least for the preprocessor, macros, unreadable function pointer syntax, and the build system. Quote from: Thaddy on November 12, 2024, 06:25:08 pmBut my pension is OK and I am enyoing it. (apart from the Dutch government changing the rules of the game mid- life and it is not 65, but 67'sh, stealing two years of income. BTW I agree with that theft!, the French could read this, with their 60 years.... silliy  ) In some EU countries, governments have also extended retirement times. Bismarck's pension model is inefficient in an increasingly socialist and ageing Europe. One day it will end up like Venezuela (or worse). Most politicians in EU countries are trying to mask the problem and delay the bankruptcy of state budgets (which are terribly indebted). ---------------------------------------------------------------------- Warfley · 2024-11-12 19:55 Quote from: VisualLab on November 12, 2024, 07:43:09 pmI hope Dennis R. and his helpers burn in hell At least for the preprocessor, macros, unreadable function pointer syntax, and the build system. I mean there is absolutely no excuse for the function pointer syntax, but the other two things get more hate than they deserve. The preprocessor was not a feature of C for a long time, it was originally a feature introduced by some compiler makers, specifically for pascal users xD The idea was that if you prefer wordy syntax over symbols, you can simply make a few defines, include them and are happy: Code: C  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i #define begin {#define end }#define procedure void procedure main()begin  ...endIt just has proven so incredibly useful that it became a full part of the language. Because C lacks any other kind of meta programming, the preprocessor allows to do things otherwise not possible. Like you can use the preprocessor where you would in another language like C++ use templates/generics. And the buildsystem is bad from a language perspective, but it's more than just a language, it's the Unix system ABI. The C ELF system allows any program written in any language to interface with any other program in any other language through linking of object files. So yeah if you look at C projects in isolation, sure it's bad. But without it Unix systems would basically not be possible at all, and we wouldn't have Linux, MacOS, Android, iOS, etc. Thats also the problem why the C buildsystem has never been improved in all those years, because it's not just a buildsystem, it's the ABI specification at the core of all unixoid operating systems ---------------------------------------------------------------------- silvercoder70 · 2024-11-12 22:22 it depends on the information and what you are looking for? for example, using this text as an example: https://vtda.org/books/Computing/Programming/Pascal/PascalUnderstandin gProgrammingProblemSolving_DouglasNance.pdf putting aside the appreciation of where "we" have come from, if nothing else it shows the reader about problem solving in Pascal. I'm not necessarily saying I would (re-)write an JSON parser, but from the basics it can be seen it is possible and how to do it ... read char by char -> lookup token -> put information into record? -> store in some structure (tree) but, would I use it for any GUI related... perhaps NO Tim ---------------------------------------------------------------------- Joanna · 2024-11-13 12:59 It’s not about if something is modern or not it’s the methodology of how it’s done, the algorithms. Techniques for doing things were around long before computers. I think many people have a fantasy that somehow there will be something that will do  everything for them and they will no longer need to think or put forth any effort. Modern computing is like a complicated water removal system for a house that guides all the water from the roof into a drain and disposes oF it discreetly and quietly. So much better than a bunch of noise and splashing some would say. Since the system is so modern and foolproof the vital parts such as the drain are in an out of the way spot where they can won’t get in anyone’s way.  People have great confidence in it and never think it will fail because they can’t see the inner workings of it. So the drain inevitably gets clogged and instead of making a bunch of splashing and noise outside from an overflowing clogged gutter, it instead has catastrophic failure as it guides all the water From roof into the ceiling of the house where it causes a lot of damage. Modern things often promise the world and hide all of the most important details of how things work from you. ---------------------------------------------------------------------- cdbc · 2024-11-13 13:08 Hi Weellll Joanna, you completely lost me, with that analogy... What's your context, with this thread's topic?!? Regards form a /wondering/ Benny ---------------------------------------------------------------------- Thaddy · 2024-11-13 14:58 Edsger Dijkstra allegedly - I doubt that - did not even have a computer and still was one of the most influential computer scientists.... Ada Lovelace did not have a computer Archimedes did not have one You do not need a computer to be brilliant in maths or subs. computer science. ---------------------------------------------------------------------- Warfley · 2024-11-13 20:51 Quote from: Joanna from IRC on November 13, 2024, 01:59:12 pmModern things often promise the world and hide all of the most important details of how things work from you. Yes, it's called distribution of concerns or divide and conquer. No one can know everything, which is why people specialize in certain areas and reuse the work of others. The same way I bring my car to a mechanic when it is broken, instead of trying and failing myself, I will rather use an implementation of e.g. a protocol by someone who put a lot of time and effort into reading the specifications getting to know all the edge cases and doing a lot of testing, rather than trying to do it myself. Don't get me wrong, it's great to learn things for understanding them better. But if you actually need to get something done, reinventing the wheel every time is just getting you nowhere. The best rype work is that one you don't have to do Quote from: Thaddy on November 13, 2024, 03:58:28 pmYou do not need a computer to be brilliant in maths or subs. computer science. Well computer before it became a technical thing was actually a job. There were rooms full of people and similar to a computer program, you would tell each of them to do certain things on paper and then hand the results to the next person who does different things. You started feeding the input to the first person in the room and the last person would hand out the final result. It's very curious to think about it, but this is how we did complex problem solving for hundreds of years ---------------------------------------------------------------------- Joanna · 2024-11-14 00:44 Quote Yes, it's called distribution of concerns or divide and conquer. No one can know everything, which is why people specialize in certain areas and reuse the work of others.It’s a double edged sword. I think it’s a good idea to know some things about other people’s jobs to avoid being taken advantage of. There is a pervasive attitude of only learning what is deemed necessary and leaving it to the “experts“. People are hesitant to ever question the experts even when flaws are obvious. Experts often use this to their advantage... ---------------------------------------------------------------------- Thaddy · 2024-11-14 08:41 Anyone can be an expert, since expert only represents decent effort. Experiri in Latin, where expertus is the past time, which expresses knowledge of.... And that in itself is enough to never trust an expert.... ---------------------------------------------------------------------- Warfley · 2024-11-14 11:34 Quote from: Joanna from IRC on November 14, 2024, 01:44:30 amIt’s a double edged sword. I think it’s a good idea to know some things about other people’s jobs to avoid being taken advantage of. There is a pervasive attitude of only learning what is deemed necessary and leaving it to the “experts“. People are hesitant to ever question the experts even when flaws are obvious. Experts often use this to their advantage... I mean especially in computer science, you can easily read yourself into all the topics you like. Most programming languages and libraries are open source today, so for example if you want to know how e.g. async await works in C#, you can just look it up. But the thing is rejecting convinience because you believe it forces people to think more about how things work doesn't work either. It will just end up with worse results because people who don't do these deep dives still need to get their work done and start doing things badly. I very often see that with C code, because there are a lot of things the C compiler does accept which are very very wrong, but seemingly work. And because a lot of people have the idea that whatever the compiler eats up and works in a few tests must be correct, they just do that. My favorite example for this is C vs Java. Both languages are quite similar in that they are quite conservative language designs with very few features (at least compared to their counterparts like C++ or Kotlin). But you can write good C code, but the language doesn't make it easy because it's easy to do things wrong. On the other hand, take for example Java, it's quite hard to write outright broken Java code, because the language makes it very hard to do severe mistakes. If there was a magical compiler that would read my mind and create the exact program I want without any bugs or misunderstandings, there is no need to manually program anything over using this. There is no virtue in doing something just for the sake of doing it. In the end our goal should always be to create the best solutions possible and taking the least amount of time for doing so. How we get there is of second order. ---------------------------------------------------------------------- Joanna · 2024-11-14 13:34 Sure it’s wise to start with the tried and true technology that has already been developed instead of starting from scratch. You would think that people would stick with the best possible way of doing things but they don’t because there is this thing called profit and doing things well is less profitable than pretending to do things well. This phenomenon of making shoddy things look great on the surface is by no means limited to computing.  It’s like having a pair hardly used leather Hiking boots have vital parts that literally turn to dust after a certain number of years have elapsed. What an unpleasant surprise that was. As for experts it’s good to have friends who are experts that can help you otherwise it could end up being an encounter with a technology which you don’t understand accompanied by someone who wants to sell you things you don’t need. ---------------------------------------------------------------------- Thaddy · 2024-11-14 19:13 Quote from: Joanna from IRC on November 14, 2024, 02:34:55 pm  It’s like having a pair hardly used leather Hiking boots have vital parts that literally turn to dust after a certain number of years have elapsed. What an unpleasant surprise that was. You should excercise more, Joanna. These Boots are Made for Walking, that is what they do...Otherwise they get a life on/of their own.... Suggest trampled under foot by Led Zeppelin... if you want to avoid Nancy....Brilliant bass lline, though, love to play it. ( Chuck Berghofer, The Wrecking Crew ) Me being a - alledgedly - misogynist, I know women always buy the wrong size, mother, four sisters, wife, daughters, does not matter, so don't blame that on programming! The wrong size doesn't seldom goes away over the years. Also, the boots from Nancy do not look too comfortable in the youtube clips. What is worse is that the song is about programming. Check the lyrics... ---------------------------------------------------------------------- silvercoder70 · 2024-11-14 21:57 QuoteIf there was a magical compiler that would read my mind and create the exact program I want without any bugs or misunderstandings, My compiler would report back - invalid logic used! Code would also be jumping all over the place. ---------------------------------------------------------------------- VisualLab · 2024-11-14 22:34 Quote from: Warfley on November 12, 2024, 08:55:59 pmQuote from: VisualLab on November 12, 2024, 07:43:09 pmI hope Dennis R. and his helpers burn in hell At least for the preprocessor, macros, unreadable function pointer syntax, and the build system. I mean there is absolutely no excuse for the function pointer syntax, but the other two things get more hate than they deserve. The preprocessor was not a feature of C for a long time, it was originally a feature introduced by some compiler makers, specifically for pascal users xD (...) It just has proven so incredibly useful that it became a full part of the language. Because C lacks any other kind of meta programming, the preprocessor allows to do things otherwise not possible. Like you can use the preprocessor where you would in another language like C++ use templates/generics. Yes, in the 60s and 70s of the twentieth century it might have seemed like a good idea. Or at least a temporarily acceptable workaround, a kind of makeshift solution. However, at the end of the 1990s, everyone was probably aware that it was just crap and they should stop using it and start solving the problem properly. It is similar to the situation of a man whose roof is leaking, and instead of fixing it (which may be time-consuming, expensive and exhausting), he puts a bucket or a tub under it to collect the water that pours in during the rain. And he does it only because he is lazy, has no idea how to fix it and does not want to devote his own strength to the work (for himself, by the way). Quote from: Warfley on November 12, 2024, 08:55:59 pmAnd the buildsystem is bad from a language perspective, but it's more than just a language, it's the Unix system ABI. The C ELF system allows any program written in any language to interface with any other program in any other language through linking of object files. So yeah if you look at C projects in isolation, sure it's bad. But without it Unix systems would basically not be possible at all, and we wouldn't have Linux, MacOS, Android, iOS, etc. Thats also the problem why the C buildsystem has never been improved in all those years, because it's not just a buildsystem, it's the ABI specification at the core of all unixoid operating systems As I wrote above, at the end of the 1990s everyone was aware that it was simply crap and they should stop using it and start solving this problem properly. But the sentiments for the "golden days of ..ix" won. And today we still have shitty OSes. And the fact that they are free does not improve the situation in any way. Just because certain solutions were good at one time (or seemed so at the time) doesn't mean that they should still be used. From old technologies: ladder wagons, horse-drawn carriages, wooden tubs and forest huts still work. But somehow people (apart from single freaks) are not thrilled with them and do not want to use them. They prefer newer solutions. There would be no MacOS, Linux, and iOS, but there would be something different. It's possible it would be something much better. Nature (the world) does not tolerate a vacuum. ---------------------------------------------------------------------- VisualLab · 2024-11-14 22:42 Quote from: Joanna from IRC on November 14, 2024, 02:34:55 pmSure it’s wise to start with the tried and true technology that has already been developed instead of starting from scratch. You would think that people would stick with the best possible way of doing things but they don’t because there is this thing called profit and doing things well is less profitable than pretending to do things well. Not always. Sometimes people do something because they hope to gain fame or want to prove to their surroundings that they are right, that their idea is extraordinary and necessary. And sometimes out of simple (and naive) nostalgia for the mythical "golden times" of certain archaic solutions that they may not have even experienced much in their lives (like L.T.). ---------------------------------------------------------------------- Joanna · 2024-11-14 22:52 Quote from: Thaddy on November 14, 2024, 08:13:13 pmQuote from: Joanna from IRC on November 14, 2024, 02:34:55 pm  It’s like having a pair hardly used leather Hiking boots have vital parts that literally turn to dust after a certain number of years have elapsed. What an unpleasant surprise that was. You should excercise more, Joanna. These Boots are Made for Walking, that is what they do...Otherwise they get a life on/of their own.... Suggest trampled under foot by Led Zeppelin... if you want to avoid Nancy....Brilliant bass lline, though, love to play it. ( Chuck Berghofer, The Wrecking Crew ) Me being a - alledgedly - misogynist, I know women always buy the wrong size, mother, four sisters, wife, daughters, does not matter, so don't blame that on programming! The wrong size doesn't seldom goes away over the years. Also, the boots from Nancy do not look too comfortable in the youtube clips. What is worse is that the song is about programming. Check the lyrics... I prefer sandals. Boots should not have an expiration date when the synthetic rubber/polymer connecting the sole to the boot turns to dust. This is an excellent example of why experts should never be trusted. They cut corners and make great looking products that fail catastrophically. I’m sure that the equivalent to my boots exists in the software world. ---------------------------------------------------------------------- Warfley · 2024-11-14 23:54 Quote from: VisualLab on November 14, 2024, 11:34:39 pmIt is similar to the situation of a man whose roof is leaking, and instead of fixing it (which may be time-consuming, expensive and exhausting), he puts a bucket or a tub under it to collect the water that pours in during the rain. And he does it only because he is lazy, has no idea how to fix it and does not want to devote his own strength to the work (for himself, by the way). I would use a very different analogy, because the issue with the preprocessor is that it is way to powerful (it's turing complete after all and can do string manipulation). So it's more like if you have a leaky roof but instead of fixing it, whenever it rains you shoot rockets into the sky to dispurse the clouds through the explosions Quote from: VisualLab on November 14, 2024, 11:34:39 pmAs I wrote above, at the end of the 1990s everyone was aware that it was simply crap and they should stop using it and start solving this problem properly. But the sentiments for the "golden days of ..ix" won. And today we still have shitty OSes. And the fact that they are free does not improve the situation in any way. Just because certain solutions were good at one time (or seemed so at the time) doesn't mean that they should still be used. From old technologies: ladder wagons, horse-drawn carriages, wooden tubs and forest huts still work. But somehow people (apart from single freaks) are not thrilled with them and do not want to use them. They prefer newer solutions. There would be no MacOS, Linux, and iOS, but there would be something different. It's possible it would be something much better. Nature (the world) does not tolerate a vacuum. I mean it's not like there are no alternatives. Microsoft went into the totally different direction, instead of having one unified format and buildprocess that can be used by any language, with object files that are linked together by a liker, Microsoft chose that every language should have their own buildsystem to create PE executables. And now after 30 years of NT kernel and 60 years of Unix we clearly see that *nix like systems are generally prefered for development. Sure windows has won in many other markets, but when it comes to developing applications, *nix systems are preferred. Pretty much all buildsystems today are *nix first windows second. Often relying on tools developed for *nix systems ported to windows (often through cygwin or mingw). The reason it is so good and has stood the test of time, is because it is so generic. Can you design a better system for a language? Yes definitely, most languages have a better build system. But can you design a system that is better independent of a language? That turns out to be really hard. And again, the thing that C allows is not just to build C applications, it allows you to write an application in which some parts are written in C, others in Pascal, others in Rust, etc. and they can all work together as one binary seemlesly to the end user ---------------------------------------------------------------------- domasz · 2024-11-15 21:55 Sorry but C/C++ are a joke. They aren't even standardized properly. I can compile most Turbo Pascal code under Delphi and Free Pascal because of standards. I cannot compile Visual C++ apps under Borland C++ or Borland C++ under GCC on Linux. Without complicated makefiles you can't compile anything while with delphi/tp/fpc you just click Compile and get a binary. ---------------------------------------------------------------------- Warfley · 2024-11-15 22:36 It's the exact opposite, C and C++ are standardized by the ISO, while (Object-) Pascal isn't, but due to the more or less monopoly that Borland and now embarcadero has on the language it's what is often called a quasi standard, like java. The reason you observe that behavior is exactly because of that. The C and C++ standard, because it's standardized by committee, is basically just what all members of the committee could agree to. Each Compiler vendor then adds additional features on top of that. If you actually restrict yourself to strictly following the ISO C standard, your code will run basically identical on all major compilers. If you rely on Compiler specific features, it will only work on that Compiler. In Pascal it's different, here the reason why your tp code works in tp, Delphi and FPC is simply because tp and Delphi are made by the same company, and FPC is quite strictly following compatibility. That said not all is compatible. First there are some divergence both in language (e.g. inline vars) but also in RTL. Additionally Delphi is not even the native mode to the FPC and in mode FPC or ObjFPC, the language is quite different. But in the end it's just a private decision by the FPC development team to what degree to follow Delphi compatibility and to what degree they won't. There is no standard, no standardization committee, etc. ---------------------------------------------------------------------- Curt Carpenter · 2024-11-15 23:26 To bore everyone with the "how old is too old" question again, I've spent the past few days exploring alternative ways to implement inter- process communications using sockets.  There are quite a few different ways to approach this, in the fcl, the rtl, using packages like synapse, indy, INet, SImpleIPC, using shared memory -- and others.  The range of advice one finds on the forum about which approach to use is all over the map.  X is depreciated, use Y:  Y has bugs and memory leaks, Z is good but not cross platform...  etc..  And there is not much if any documentation on any of the alternatives although there are many examples to start from (most I've tried work with limitations and reservations). Anyway -- fun to note that "fsocket" in fcl-net is dated 2003! ---------------------------------------------------------------------- Warfley · 2024-11-16 00:22 Yes FCL net is quite an interesting bit. There are a lot of things in there like netdb httpsvt, or fpsock (which I guess you meant with fsocket), etc. Which seem like there was the idea for something but never really got anywhere, while other things like ssockets or sslsockets are useful even though still lacking. But I mean such things are to expected, if you look at the contributed units on the website, you see that there are a lot of units contributed by different people over time ---------------------------------------------------------------------- Curt Carpenter · 2024-11-16 01:53 Yes,  sorry:  fsock.  And no doubt there are people out there that have mastered and are still using it. One day, somebody needs to write a history of the open source phenomenon.  It has aspects that are I suspect unique in the story of our species. ---------------------------------------------------------------------- PascalDragon · 2024-11-16 13:12 Quote from: Warfley on November 15, 2024, 12:54:41 amI mean it's not like there are no alternatives. Microsoft went into the totally different direction, instead of having one unified format and buildprocess that can be used by any language, with object files that are linked together by a liker, Microsoft chose that every language should have their own buildsystem to create PE executables. No one is stopping compiler developers to use MSVC's masm and link. In fact FPC can even use masm (though not link). Everything on Windows is PE/COFF after all. Quote from: domasz on November 15, 2024, 10:55:26 pmSorry but C/C++ are a joke. They aren't even standardized properly. I can compile most Turbo Pascal code under Delphi and Free Pascal because of standards. As Warfley already wrote: C and C++ are both standardized. The Pascal dialects understood by TP, Delphi and FPC (with the exception of FPC's support for ISO Pascal) are not standardized. Quote from: domasz on November 15, 2024, 10:55:26 pmI cannot compile Visual C++ apps under Borland C++ or Borland C++ under GCC on Linux. Without complicated makefiles you can't compile anything while with delphi/tp/fpc you just click Compile and get a binary. C and C++ are simply designed in a different way, namely that the compilation modules are independant of each other and due to the headers every source essentially contains all required information and thus it's the job of the build system (which is not part of the language specification) to get it all together. (Object) Pascal simply has a module system that is part of the language (and C++ is getting there as well with module support). ---------------------------------------------------------------------- VisualLab · 2024-11-17 00:51 Quote from: Warfley on November 15, 2024, 11:36:34 pmIt's the exact opposite, C and C++ are standardized by the ISO, while (Object-) Pascal isn't, but due to the more or less monopoly that Borland and now embarcadero has on the language it's what is often called a quasi standard, like java. The reason you observe that behavior is exactly because of that. The C and C++ standard, because it's standardized by committee, is basically just what all members of the committee could agree to. Each Compiler vendor then adds additional features on top of that. If you actually restrict yourself to strictly following the ISO C standard, your code will run basically identical on all major compilers. If you rely on Compiler specific features, it will only work on that Compiler. In Pascal it's different, here the reason why your tp code works in tp, Delphi and FPC is simply because tp and Delphi are made by the same company, and FPC is quite strictly following compatibility. That said not all is compatible. First there are some divergence both in language (e.g. inline vars) but also in RTL. Additionally Delphi is not even the native mode to the FPC and in mode FPC or ObjFPC, the language is quite different. Yes, you are right, from the point of view of formalism C and C++ are standardized. And Pascal and Object Pascal are not standardized. I.e. more specifically, there is no committee for Pascal and Object Pascal. However, practice shows something else. Apparently this standardization of C and C++ works, but there are many exceptions in the operation of these compilers. The standardization of programming languages ​​is a bit like the standardization of quality control, health and safety or information security in companies (e.g. ISO 9000, ISO 18000 or ISO 27000). In reality, however, these aforementioned "papers" are a collection of "wishful thinking", a conglomeration of generalities, high-flown phrases, smart-aleck recommendations, and various corporate gibberish. Real standards are strict. For example, those concerning industrial equipment and infrastructure (threads, pipe flanges, electrical insulation, etc.) or those concerning the performance of industrial physicochemical measurements (determining acid number, determining kinematic viscosity, etc.). Such standards have a narrowly and strictly defined subject of standardization. They describe each element in detail. Meanwhile, programming language is too broad, complex and incredibly extensive a subject. In practice, to maintain strict control over the development of the language, sometimes it works better when there is a single entity setting the rules of the game (unless it suffers from schizophrenia). These smaller entities then have no choice but to comply or disappear. But there are exceptions, e.g. C# or Swift. Although C# probably has a more stable specification than Swift. On the other hand, decision- makers at Apple have no qualms about changing the rules of the game every now and then, and in many different matters (corporate schizophrenia?). Either way, the problem, as usual, is people who don't want to cooperate with each other, but everyone wants to show how important and smart they are. But this is a non-IT topic, so I will take a break here. Quote from: Warfley on November 15, 2024, 11:36:34 pmBut in the end it's just a private decision by the FPC development team to what degree to follow Delphi compatibility and to what degree they won't. There is no standard, no standardization committee, etc. Why isn't there? The FPC programming team is a committee Does it need to have the "anointing" of corporate CEOs, like the C++ committee? Luckily for us, no ---------------------------------------------------------------------- Warfley · 2024-11-17 16:14 Quote from: VisualLab on November 17, 2024, 01:51:28 amYes, you are right, from the point of view of formalism C and C++ are standardized. And Pascal and Object Pascal are not standardized. I.e. more specifically, there is no committee for Pascal and Object Pascal. However, practice shows something else. Apparently this standardization of C and C++ works, but there are many exceptions in the operation of these compilers. I can only disagree. While I don't work with C and C++ anymore (aside from a few side projects), I used both languages very intensively for quite some time. And while it's true that some parts of the standard tend to not be adopted (C++ had multiple approaches for modules), in general if you write ISO compliant C and C++ code it works identical on all major compilers. The problem is neither the standard noch the compilers. The problem is that a lot of C and C++ developers specifically work outside the standard. For example, the C standard says that int is a signed type with at least 15 significant bits and long at least having 31 (31 significant bits in going from -2^31..2^31). In practice it's very compiler and target dependent. On many 32 bit systems and compilers both are 32 bit, but on 64 bit systems often int is 32 bit and long 64. The problem now is if you have programmers writing code assuming that int is 32 bit and long is 64 bit, then you port this to another compiler and it breaks. But thats not the fault of the compiler or standard, the standard specifies the type int32_t and so on, which guarantee to be 2nd complement with an exact bit number. So the actual problem is that many programmers rather write "int" than "int32_t" and then wonder why it breaks on porting to another system. If you are writing ISO compliant C, your code will run identical on GCC, Clang, MSVC, Intel C, Boarland C++, etc. It's just that a lot of C developers don't know the standard very well. Quote from: VisualLab on November 17, 2024, 01:51:28 amIn practice, to maintain strict control over the development of the language, sometimes it works better when there is a single entity setting the rules of the game (unless it suffers from schizophrenia). These smaller entities then have no choice but to comply or disappear. But there are exceptions, e.g. C# or Swift. Although C# probably has a more stable specification than Swift. On the other hand, decision- makers at Apple have no qualms about changing the rules of the game every now and then, and in many different matters (corporate schizophrenia?). Either way, the problem, as usual, is people who don't want to cooperate with each other, but everyone wants to show how important and smart they are. But this is a non-IT topic, so I will take a break here. I mean it generally depends. Languages like C# and Swift work well because the company that makes these decisions also takes the effort to make it attractive. Swift while being a really good language, is only really a thing because it's the native language for iOS and MacOS. Without that probably no one would use it. Similarly Microsoft put C# with .Net, ASP and also their contracts with Unity, into a very good position. If you want an example of where this didn't work well, you can look at the very same companies. Besides Swift Apple first developed Objective C, and everyone hated it. And Microsoft besides C# introduced VB.Net. Quote from: VisualLab on November 17, 2024, 01:51:28 amWhy isn't there? The FPC programming team is a committee Does it need to have the "anointing" of corporate CEOs, like the C++ committee? Luckily for us, no Well the thing about Standardization organizations is that they are open to anyone and work transparently. For example if I want to contribute to an ISO standard, joining the ISO working groups, while being annoying, is not very difficult. All you need to do is to join your national Standardization Organization, so for me here in Germany it would be the DIN, which granted is tailored towards companies and costs like a Thousand euros per year, so it's not really free, but this is literally the only payment you have to do and it's fixed. From that point onwards a lot of beurocracy has to be done, with different roles and positions. The first step is to join the national mirror working group. Basically whenever the ISO makes a new proposal, it is sent to all the UN member state standardization organizations, where the mirror working groups can then have an internal vote and this vote is then given to the ISO committee. So taking my example I would be then as a member of DIN get to vote for the opinion that DIN/Germany would hand in at the ISO. As part of this vote the member states can elect delegates which will then become members of the working group. Besides the national delegates theres also the option to get chosen as independent expert. Once you're in there you can take part in the comittee work, if you want to take the role of editor or other special roles you can apply for that in the comittee work. Lastly once the draft is finalized it will again be given to the national SDOs to get the final vote. Meaning no matter if you get delegated or anything, as long as you become a member in your national SDO you will have a vote. I myself am for my work right now in this process of getting into certain standardization working group, and while it's a beurocratic pain that takes many months, it is quite non discriminatory and does not depend on budget or something. Also important is that the SDOs have clear procedures for the working groups, where the discussions and decisions are well documented each meeting is preceded by minutes outlining the topics, decisions and reasoning, and everything will be published so that every single decision can be traced back to why it was taken, when and by whom. There are different governance models, each with their pros and cons. The three most notable are standardization through an SDO, maintainance through a Foundation and Private ownership. SDOs are the most transparent and give everyone the opportunity to contribute with equal voting power, independent of money. On the flip side they have a lot of beurocratic overhead and tend to underspecify. Foundations (like for example with Python) tend to favor the contributers who "donate"/invest the most money, here often voting power is proportional to financial contributions. And private ownership tends to have a very specific target and vision that is important for the maintainer, e.g. Swift is specifically designed for iOS development, to the degree that Swift for Linux or Windows is just an after thought. But the Maintainer has no obligations other than to themselves. For private projects (as Zig or how I would also consider the FPC to a certain degree) it's often a question of vision of the maintainers, while for companies it's usually first and foremost their personal business interests. So the reason why the FPC maintainers are not comparable to an SDO commitee is simply that  there are no rules for them. There are no general organizational rules like there are for SDOs (e.g. EU Regulation 2012/1025 for european SDOs), there are no Rules of Procedure for the working groups and official subgroups, there are no formalities, no requirements on documentation and no formal voting. You can't sue them if they don't follow procedure, and they aren't responsible to anyone but themselves. Not saying that this is necessarily a bad thing, personally I find it better than the embarcadero approach. That said, looking at extended Pascal standardized by ISO there are a lot of things in there that are very well thought out and are something that would be still beneficial today