Frankenstein Pascal lazarus / 64-FPC development ---------------------------------------------------------------------- yodabitiota · 2021-03-15 22:29 First post here, so short introduction. Happy FPC&Lazarus user both hobby as professional. Not sure where to put such question as this, figured might as well drop it here. Thing that's on my mind for ages is a 'frankenstein' pascal. You know, fancy c operators like ++, replace begin and end block by curlies, and replace the curlies with hashes. But apart those cosmetic tweaks, mostly to increase cross-language readability, very little else. Well, maybe as wish to use 'var' ad-hoc (which has been discussed). It'd just make pascal more similar to 80% of the languages out there. Which i don't really use but i'm lazy. So, my first approach was to see what macro's and operators could do. That's very limited when it comes to reserved words, or writing an operator or macro for '++' seems not possible at the moment. So, a wild idea would be to start modifying FP compiler itself. Which is a rabbit hole i'm not sure willing to dive into or have time resources for, though something had to be the occasion one day, but even if so would be sane to check if such endeavor is actually possible; making a mode switch {$FRANKENSTEIN ON} and applying some tweaks to the parser. Slightly more lazy approach would be to start by dropping it as feature request, somewhere people know about the internals may know, and maybe asking some feedback. It's likely i'm not the first with such suggestion so maybe there's some existing discussion or efforts about such feature that google not easily answered. Any pointers welcome. ---------------------------------------------------------------------- AlexTP · 2021-03-15 22:40 It is some far-left extremism, that curly brackets for begin-end. And it's not needed, Pascal has it's own syntax which is OK. ---------------------------------------------------------------------- yodabitiota · 2021-03-15 22:49 Quote from: Alextp on March 15, 2021, 11:40:59 pmIt is some far-left extremism, that curly brackets for begin-end. And it's not needed, Pascal has it's own syntax which is OK. Ok, instead of Frankestein you want to call it Vegan Pascal? Sure. Syntax is ok, readability suffers. There's a reason python only uses whitespace for block markings. And var declarations out of block are only slightly less bad than global variables at occasion. I really wish some of those were a feature. ---------------------------------------------------------------------- winni · 2021-03-15 22:51 Quote from: Alextp on March 15, 2021, 11:40:59 pmIt is some far-left extremism, that curly brackets for begin-end. And it's not needed, Pascal has it's own syntax which is OK. Can you please explain the connection between far-left extremism and curly brackets. I'm curious. Winni ---------------------------------------------------------------------- trev · 2021-03-15 23:28 Quote from: winni on March 15, 2021, 11:51:06 pmCan you please explain the connection between far-left extremism and curly brackets. I imagine that it is the opposite of the connection between far-right extremism and square brackets. ---------------------------------------------------------------------- trev · 2021-03-15 23:34 Related: https://forum.lazarus.freepascal.org/index.php/topic,53139.0.html ---------------------------------------------------------------------- 440bx · 2021-03-16 00:40 Quote from: yodabitiota on March 15, 2021, 11:29:23 pmBut apart those cosmetic tweaks, mostly to increase cross-language readability, Readability ??... sounds a lot more like it would greatly increase _unreadability_.  At least in my mind, it is dubious that the "languages" that use "++" and curly braces are actually programming languages.  When I see that code, it makes me feel like a veterinarian looking at an epileptic chicken's EKG.  It's painful to look at the poor thing's misery. Quote from: yodabitiota on March 15, 2021, 11:29:23 pm It'd just make pascal more similar to 80% of the languages out there. I don't think it is practical nor desirable to make Michelle Pfeiffer look like Roseanne Barr with a beard and curly braces tattooed on her forehead.  Quote from: yodabitiota on March 15, 2021, 11:29:23 pmSo, a wild idea would be to start modifying FP compiler itself. It does sound like a wild idea particularly considering that there are, unfortunately, plenty of languages out there that poke the programmer's eyes with curly braces, ampersands and more punctuation characters than Timothy O'Leary ever saw even in his wildest trips. Quote from: yodabitiota on March 15, 2021, 11:29:23 pmmaking a mode switch {$FRANKENSTEIN ON} and applying some tweaks to the parser. That's how the C language was designed.  40 years later and the scars are still showing. Quote from: yodabitiota on March 15, 2021, 11:29:23 pmstart by dropping it as feature request, You might have a future in politics.  Next time there is a big earthquake, you can claim it's a "feature" designed to shake things up. Quote from: yodabitiota on March 15, 2021, 11:29:23 pmAny pointers welcome. here is one http://www.iso-9899.info/wiki/The_Standard ---------------------------------------------------------------------- engkin · 2021-03-16 01:28 Quote from: yodabitiota on March 15, 2021, 11:29:23 pmFirst post here, so short introduction. Happy FPC&Lazarus user both hobby as professional. Not sure where to put such question as this, figured might as well drop it here. Thing that's on my mind for ages is a 'frankenstein' pascal. You know, fancy c operators like ++, replace begin and end block by curlies, and replace the curlies with hashes. But apart those cosmetic tweaks, mostly to increase cross-language readability, very little else. Well, maybe as wish to use 'var' ad-hoc (which has been discussed). It'd just make pascal more similar to 80% of the languages out there. Which i don't really use but i'm lazy. So, my first approach was to see what macro's and operators could do. That's very limited when it comes to reserved words, or writing an operator or macro for '++' seems not possible at the moment. So, a wild idea would be to start modifying FP compiler itself. Which is a rabbit hole i'm not sure willing to dive into or have time resources for, though something had to be the occasion one day, but even if so would be sane to check if such endeavor is actually possible; making a mode switch {$FRANKENSTEIN ON} and applying some tweaks to the parser. Slightly more lazy approach would be to start by dropping it as feature request, somewhere people know about the internals may know, and maybe asking some feedback. It's likely i'm not the first with such suggestion so maybe there's some existing discussion or efforts about such feature that google not easily answered. Any pointers welcome. Hi there, and thank you for this post. I did laugh after reading the title AND the first five six replies (thank you, 440bx). As you have seen, you will not be allowed to touch the compiler. But don't get discouraged, it's easier and more logical to work on a transpiler: from Frankenstein Pascal to ObjFPC Pascal. Beside the changes you want to include, you need to translate locations between Frankenstein Pascal source code and its counterpart ObjFpc Pascal. Line numbers will probably stay the same, it is the location in each line that will change. This will allow finding the location of, say, errors reported by the compiler in the correct location on your side. If you do come up with a functional transpiler, ideas that are rejected by core developers could be added to yours. Also, new ideas could be tested on your side first before introducing them to FPC. Edit: Just to let you know what you are about to face, read this whole thread and it does not finish there, read the replies in the bug report mentioned in the first post. There is also a mailing list thread about it, I don't have the link, where the whole thing started. I don't blame people resisting new ideas, good or bad, but that should not prevent you from giving your idea a try. ---------------------------------------------------------------------- Martin_fr · 2021-03-16 02:11 Quote from: yodabitiota on March 15, 2021, 11:29:23 pmsimilar to 80% of the languages out there https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(syn tax)#Blocks Gives about 20 {} examples. And almost twice as many other examples. Ok, https://en.wikipedia.org/wiki/List_of_programming_languages_by_typ e#Curly-bracket_languages gives approx 60 {} examples, but then there are unlisted none {} languages too. Not sure, how the 80% got computed. Probably computed using curly brackets ---------------------------------------------------------------------- engkin · 2021-03-16 02:35 Quote from: Martin_fr on March 16, 2021, 03:11:55 amNot sure, how the 80% got computed. Probably computed using curly brackets I don't think so, that would make it cryptic and unreadable. ---------------------------------------------------------------------- Handoko · 2021-03-16 03:34 If you like orange, then buy some oranges. Yes, you can ask scientists to genetically modify apple to taste like orange. That might work. But why spending time, money and effort for doing it when there are plenty of varieties of orange you can choose from. ---------------------------------------------------------------------- engkin · 2021-03-16 04:32 Quote from: Handoko on March 16, 2021, 04:34:50 amIf you like orange, then buy some oranges. Or plant some oranges. Quote from: Handoko on March 16, 2021, 04:34:50 amBut why spending time, money and effort for doing it when there are plenty of varieties of orange you can choose from. Because it is possible. Because there is nothing wrong in customizing the language you like the way you wish. Because you enjoy doing what you want to do, not what others want you to do. I am not sure that you are really looking for an answer because, for one, the question itself implies that there is no space for any improvement, and the available oranges should be more than enough! IMHO, that is not the case. I am sure you agree with me, because IIRC, you plan on making your own game, despite of all the available strawberries. ---------------------------------------------------------------------- Handoko · 2021-03-16 07:43 I am writing my own game engine because I found none of the available is close to what I want. I really installed and tried them. I didn't fully read the OP's post. But s/he mentioned feature request, which I believe that means asking other to do it. In my case, I never ask other to write the game engine for me. Changing a language syntax is like changing the flavor of a fruit. To me, it is not very useful. But I would say yes to genetically modify apple to make it high content of Vit C like orange. ---------------------------------------------------------------------- avk · 2021-03-16 07:53 Quote from: 440bx on March 16, 2021, 01:40:20 amAt least in my mind, it is dubious that the "languages" that use "++" and curly braces are actually programming languages.  I've heard there is also a perception that classic C is just a computer virus disguised as a programming language. And C++ is C after a complete takeover of the attacked system. And C# is a caught and disarmed C in prison. In turn, Java harmoniously combines the beauty of C++ syntax with the performance of Python. ---------------------------------------------------------------------- MarkMLl · 2021-03-16 08:05 Quote from: engkin on March 16, 2021, 02:28:20 amBut don't get discouraged, it's easier and more logical to work on a transpiler: from Frankenstein Pascal to ObjFPC Pascal. I agree, and was about to make a similar suggestion. That would be instructional (a) because it would be useful practical experience of how tricky it can be to write a compiler and (b) because it would (if accompanied with proper test cases) indicate where there were flaws in the proposed language definition. As specific examples, since the 1970s it has been generally accepted that whitespace (including line ends) should be ignored while source is being lexed/parsed, with very few exceptions (literal strings not extending over multiple lines unless there is an escape mechanism, the remainder of the line after an  end  in ALGOL being ignored and so on). Languages such as Python which discard ; as a statement separator or terminator fly in the face of that convention: is this really a good thing? And then it turns out that C-like languages can get very nasty if you don't assume whitespace around some of the prefix/suffix operators... and that is an error of language design, not of compiler implementation. Now when I posted my "Modest Proposal" https://forum.lazarus.freepascal.org/index.php/topic,53139.0.html a few weeks ago (thanks for handling the xref, @Trev) I at least did so with the benefit of substantial experience in multiple language paradigms, and I did my best to do it in a way that respected tradition and wouldn't break stuff. And I still didn't expect people to like it, hence the title :-) While I am critical of the way that Wirth appeared to rush Pascal out with the specific intention of being similar to ALGOL but not quite compatible, the underlying concepts have been proven to be robust. Tacking extra bits onto Pascal to make it more "C-like" is about as useful as tacking extra bits onto C to make it more "Pascal like"... while both languages can benefit to some extent the result is invariably less elegant than a fresh properly-designed language. MarkMLl ---------------------------------------------------------------------- MarkMLl · 2021-03-16 08:18 Quote from: avk on March 16, 2021, 08:53:29 amI've heard there is also a perception that classic C is just a computer virus disguised as a programming language. And C++ is C after a complete takeover of the attacked system. And C# is a caught and disarmed C in prison. In turn, Java harmoniously combines the beauty of C++ syntax with the performance of Python. To his credit, Stroustrup has been rather more critical of C++ than most other language designers when discussing their life's work. "Within C++, there is a much smaller and cleaner language struggling to get out." Which if nothing else illustrates the difficulty of enhancing an existing language with novel concepts. MarkMLl ---------------------------------------------------------------------- sstvmaster · 2021-03-16 08:33 DON'T FEED THE TROLL! ---------------------------------------------------------------------- 440bx · 2021-03-16 09:00 Quote from: MarkMLl on March 16, 2021, 09:05:26 am the result is invariably less elegant than a fresh properly-designed language. I think designing a _good_ computer language might very well be the greatest challenge a programmer can face. There are countless books about algorithms to scan, parse, generate code and massage data structures used in compiler writing as well as extensive theory on grammars but, I am yet to see a book that is an in-depth scientific/mathematical study of the effects of the grammar on the expressive power of the language and its ability to minimize/eliminate terse and error prone grammatical construct (e.g, =/==, |/||, parser -> code generator organisation. I've had things working in the past which went some way towards that, e.g. pragmata to control the form of numbers and strings which affected all stages of the compiler. Apropos C... I agree that it would have been niche. I've had people explain to me that the only way that you could program a UNIX computer was by using C and I've had people explain to me that the only way you could program an IBM mainframe was by using assembler... both arguments were of course fallacious but the fact that they were voiced at all indicates just how insular the communities could be. MarkMLl ---------------------------------------------------------------------- MarkMLl · 2021-03-16 10:40 Quote from: 440bx on March 16, 2021, 11:30:37 amQuote from: yodabitiota on March 16, 2021, 10:42:04 am And there is a reason why 'newer' languages (Java, PHP, C#, *) mostly seem to mimic C-style and that reason is readability. No, the reason is definitely not readability.  The reason is the widespread acceptance of a repugnantly bad design that has very unfortunately become what a very significant percentage of programmers have gotten used to.  What's incredibly unfortunate is that the majority of programmers who have gotten infected by it are now unable to even tell the design is pure garbage.   It's a bit like heroin, very addictive but, definitely not good for the "consumer", particularly when that harmful stuff is dispensed in shiny "new packages" to make it look attractive (heroin++, D-eroin, etc) I've remarked before that it's regrettable that there are so many people- often educated and experienced people- who think that the sole criterion is "curly-bracket languages vs begin-end languages". It's not. K&R perpetrated some remarkably bad design choices which could have been avoided by familiarity with "the art". In the interest of being even-handed, I can't help but observe that Wirth perpetrated some remarkably bad design choices /despite/ being familiar with the art. MarkMLl ---------------------------------------------------------------------- yodabitiota · 2021-03-16 10:49 Quote from: ojz0r on March 16, 2021, 11:16:29 amI belive that is more connected to familiarity rather than readability per se. Well, to be fair, readability of Pascal is just fine, great even. I've no issues with that and with Pascal being my language of choice for 3 decades, it shouldn't be. But i do find myself sometimes frowning a bit, seeing alternatives. Having said that, curlies are not even on top my wish list for changes. Such wish list includes things like real boolean instead of bitwise boolean operators, implicit casting integer types to boolean, variable scope limited to block, and a few more. Dinmil linked to the v-language which indeed looks neat and clean, but ofc FPC has a feature set and a tonload of libraries, and i'm familiar with the language. Also, i'm the first to admit that dealing without those features is a real minor issue. So personally i prefer using a stable language that i know in and out and know what to expect from, than jumping on the next hyped train like Go or Rust which i consider too experimental for long-term projects. But i do observe FPC going trough great lengths to maintain Delphi compatibility, while personally i don't care at all for such. I consider FPC way superior to Delphi so why even bother. And yes, Delphi improved too over the years, and of course copy good ideas, no shame in that. Meanwhile changes that are desirable by some get plain ridiculed - someone called me a Troll for that in this thread already, making me wonder how open discussions about language features are. I totally understand 'weird' features not going mainstream, but if every month someone suggest the same thing then apparently there are thousands thinking like me, just never stirring it up. ---------------------------------------------------------------------- MarkMLl · 2021-03-16 11:09 Quote from: yodabitiota on March 16, 2021, 11:49:57 amSuch wish list includes things like real boolean instead of bitwise boolean operators, Please explain what you mean here. Quoteimplicit casting integer types to boolean, Not going to happen and AIUI C++ frowns upon that. /However/, if there were a single-character boolean inversion- let's say ! for this- I'd suggest that it would be feasible to recognise !! for boolean normalisation taking an integer type as its parameter. Please take that into account when considering the exercise I set earlier :-) Quotevariable scope limited to block, and a few more. Presumably you mean "block" as in "the single statement processed by a  for  statement. Ditto possibly a  with  statement as an explicit indication of the referent. TBH I agree with you, but "the Lieutenant wouldn't like it" :-) MarkMLl ---------------------------------------------------------------------- 440bx · 2021-03-16 11:16 Quote from: MarkMLl on March 16, 2021, 11:40:21 amIn the interest of being even-handed, I can't help but observe that Wirth perpetrated some remarkably bad design choices /despite/ being familiar with the art. Wirth did make some "poor" choices here and there but, he deserves credit for realizing them and correcting them.  Great minds correct their mistakes, mediocre ones perpetuate them. Quote from: yodabitiota on March 16, 2021, 11:49:57 am Meanwhile changes that are desirable by some get plain ridiculed - someone called me a Troll for that in this thread already, making me wonder how open discussions about language features are. It's probably fair to say they are not very open. Quote from: yodabitiota on March 16, 2021, 11:49:57 am I totally understand 'weird' features not going mainstream, but if every month someone suggest the same thing then apparently there are thousands thinking like me, just never stirring it up. Features or syntax additions/modifications should fit nicely into the spirit of the language, that's important.  Things like "++" create all kinds of problems, particularly if they are allowed to precede or follow an identifier (as done in C/C++.)  It really does not fit well into the language, that is also true of the curly braces, they are already used to delimit comments.  FPC allows the use of "<<" and that is a quite a source of headaches. Here is a feature I suggested https://forum.lazarus.freepascal.org/index.php/topic,49505.0.html that is a nice fit in the language, it's a rather simple one (at least it should be simple) but, it got shot down.  Features that don't fit the language are very unlikely to be adopted (with exceptions such as the previously mentioned "<<".) ---------------------------------------------------------------------- yodabitiota · 2021-03-16 11:51 Quote from: MarkMLl on March 16, 2021, 12:09:36 pmPlease explain what you mean here. Ok, boolean logic is always considered bitwise in Pascal. In C, we can distinguish what we want be & vs &&, | vs || and ! vs ~. In pascal, have to jump little hoops like '(A<>B) and (B<>0)', or alternatively typecasting 'boolean(A) and boolean(B)',  if A and B are integer types, which they happen to do, a lot. It's not 'cleaner code'. 440bx suggest to use '!!' which might be an alternative albeit a bit clumsy. Then, for incrementing (and decrementing) we're forced to use a pseudo function like 'inc', or a construct like 'x+=1'. Whereas in assembler this is one instruction. It doesn't have to be '++' btw, but 'inc' being a pseudofunction feels a bit, odd. And it's also one of them things happening a lot in code. So, in general boolean logic is not really elegant in Pascal. I know C sometimes looks like black magic, but it (boolean logic) is the thing we have to do as programmers, and the same line in Pascal may end up 3 times as long as in C. Allowing bools for multiplication and other math functions (implicit casting of bool to integer) would be very nice to have too. Loops are another small pain point, and there's already various discussions on that. Including the proposal to at least have a 'step'. Or to be allowed to modify the iterator. Fancier c-style would be do have multiple conditions. But this all is easily dodged with a simple while instruction so low priority in my opinion. But C's 'for' construction does have some elegance and flexibility. Luckily we have for-in loops nowadays ,if you're willing to write operators, which unfortunately don't exist for a lot of standard types and classes yet, but surely a nice feature. Now, by no means i wish to break compatibility and with those glasses on i understand the conservatism. But as programmer, looking for an elegant language and elegant code, there's a wish list aye. ---------------------------------------------------------------------- bytebites · 2021-03-16 11:55 C-language and elegance is something that does not match. ---------------------------------------------------------------------- MarkMLl · 2021-03-16 11:59 Quote from: 440bx on March 16, 2021, 10:00:50 amThere are countless books about algorithms to scan, parse, generate code and massage data structures used in compiler writing as well as extensive theory on grammars but, I am yet to see a book that is an in-depth scientific/mathematical study of the effects of the grammar on the expressive power of the language and its ability to minimize/eliminate terse and error prone grammatical construct (e.g, =/==, |/||, B) and (B<>0)', or alternatively typecasting 'boolean(A) and boolean(B)',  if A and B are integer types, which they happen to do, a lot. It's not 'cleaner code'. 440bx suggest to use '!!' which might be an alternative albeit a bit clumsy. No it's not, it's determined by the type of the operands. That's a major distinguishing feature between 1970s Pascal and 1970s C, and one that 50 years on C++ is still trying to incorporate (if it fails, it's because of the expectation of its users and their legacy code). MarkMLl ---------------------------------------------------------------------- PascalDragon · 2021-03-16 12:45 Quote from: yodabitiota on March 15, 2021, 11:29:23 pmt's likely i'm not the first with such suggestion so maybe there's some existing discussion or efforts about such feature that google not easily answered. Any pointers welcome. You are not the first with such suggestions and you're also not the first we're shooting down, because there simply will not be any modifications added to the compiler that changes syntax/language fundamentals. And this has not only to with us compiler developers preferring the Pascal language as it is, but also with maintainability. Every addition to the compiler, every new feature needs to be maintained. Now essentially completely reworking the language even if it would be behind a modeswitch is a big chunk of code that would need to be maintained. So no, I'm not even remotely sympathetic to these "suggestions". That said, what you do in the compiler's source yourself is merely up to you, it's open source after all. But don't expect your changes to appear in upstream. Quote from: 440bx on March 16, 2021, 12:16:53 pmQuote from: yodabitiota on March 16, 2021, 11:49:57 am I totally understand 'weird' features not going mainstream, but if every month someone suggest the same thing then apparently there are thousands thinking like me, just never stirring it up. Features or syntax additions/modifications should fit nicely into the spirit of the language, that's important.  Things like "++" create all kinds of problems, particularly if they are allowed to precede or follow an identifier (as done in C/C++.)  It really does not fit well into the language, that is also true of the curly braces, they are already used to delimit comments.  FPC allows the use of "<<" and that is a quite a source of headaches. Here is a feature I suggested https://forum.lazarus.freepascal.org/index.php/topic,49505.0.html that is a nice fit in the language, it's a rather simple one (at least it should be simple) but, it got shot down.  Features that don't fit the language are very unlikely to be adopted (with exceptions such as the previously mentioned "<<".) The support for the C-style shift operators had been added long before we'd become more self-conscious regarding language design and what it means to work with a language. Nowadays they wouldn't be added anymore (and especially not with the stated reason that it simplifies porting of C code  ) and I'm really considering at least coupling them to the COperators directive... ---------------------------------------------------------------------- dseligo · 2021-03-16 14:44 Quote from: yodabitiota on March 16, 2021, 12:51:02 pmBut C's 'for' construction does have some elegance and flexibility.I always hated 'for' in C, and I still do. Those round brackets and I always have to think if I set condition correctly. As for curly brackets: on my keyboard I have to use AltGr+B and AltGr+N to get them and it's kind of clumsy to do. For me it's easier to write 'begin'/'end'. ---------------------------------------------------------------------- dseligo · 2021-03-16 14:52 Quote from: yodabitiota on March 16, 2021, 11:49:57 amBut i do observe FPC going trough great lengths to maintain Delphi compatibility, while personally i don't care at all for such.I agree with that. In my opinion it would be better that delphi conversion tool "translate" Delphi code to Lazarus. I know that units then wouldn't be compatible with Delphi anymore, but it would be easier to maintain FPC/LCL without Delphi mode. I don't know if that's possible. ---------------------------------------------------------------------- avra · 2021-03-16 14:54 Quote from: yodabitiota on March 16, 2021, 12:51:02 pmSo, in general boolean logic is not really elegant in Pascal. I know C sometimes looks like black magic, but it (boolean logic) is the thing we have to do as programmers, and the same line in Pascal may end up 3 times as long as in C. Allowing bools for multiplication and other math functions (implicit casting of bool to integer) would be very nice to have too.I have an idea. Why don't you go the other way around? Go to GCC developers and suggest them to bring more of Pascal into C? Just tell me where so I can follow the discussion... ---------------------------------------------------------------------- marcov · 2021-03-16 15:19 Quote from: dseligo on March 16, 2021, 03:52:27 pmQuote from: yodabitiota on March 16, 2021, 11:49:57 amBut i do observe FPC going trough great lengths to maintain Delphi compatibility, while personally i don't care at all for such.I agree with that. In my opinion it would be better that delphi conversion tool "translate" Delphi code to Lazarus. I know that units then wouldn't be compatible with Delphi anymore, but it would be easier to maintain FPC/LCL without Delphi mode. I don't know if that's possible. Delphi compatibility is much easier than having to get 100 different opinions about what else to converge on. Further I of course agree with PascalDragon. Too much work, and we are not even searching for language syntax alternatives. There are threads enough about this on the forum (also on C readability and quicker typing, modula2 blockstructure etc). Just search them. Maybe try to convince GCC to a more pascal mode. ---------------------------------------------------------------------- dseligo · 2021-03-16 16:54 Quote from: marcov on March 16, 2021, 04:19:17 pmQuote from: dseligo on March 16, 2021, 03:52:27 pmQuote from: yodabitiota on March 16, 2021, 11:49:57 amBut i do observe FPC going trough great lengths to maintain Delphi compatibility, while personally i don't care at all for such.I agree with that. In my opinion it would be better that delphi conversion tool "translate" Delphi code to Lazarus. I know that units then wouldn't be compatible with Delphi anymore, but it would be easier to maintain FPC/LCL without Delphi mode. I don't know if that's possible. Delphi compatibility is much easier than having to get 100 different opinions about what else to converge. Further I of course agree with PascalDragon. Too much work, and we are not even searching for language syntax alternatives. There are threads enough about this on the forum (also on C readability and quicker typing, modula2 blockstructure etc). Just search them. Maybe try to convince GCC to a more pascal mode. What has GCC to do with what I wrote? ---------------------------------------------------------------------- cdbc · 2021-03-16 17:41 Hi I'm with Pascaldragon & Marcov on this one... Why add elements with a ton of work, when they're overworked anyway! I'm happy with FPC & Lazarus as they are! Regards Benny ---------------------------------------------------------------------- marcov · 2021-03-16 17:48 Quote from: dseligo on March 16, 2021, 05:54:50 pmWhat has GCC to do with what I wrote? Well, you can approach it from two directions,  Cify Pascal or Pascalize C :-) ---------------------------------------------------------------------- dseligo · 2021-03-16 18:48 Quote from: marcov on March 16, 2021, 06:48:32 pmQuote from: dseligo on March 16, 2021, 05:54:50 pmWhat has GCC to do with what I wrote? Well, you can approach it from two directions,  Cify Pascal or Pascalize C :-) Did you mix me with OP who wants curly brackets in Pascal? ---------------------------------------------------------------------- 440bx · 2021-03-16 20:08 Quote from: MarkMLl on March 16, 2021, 12:59:55 pmSo, let's keep our base languages simple. Let's identify what /has/ to be in the language, and then find an extension mechanism for the extra features... I definitely agree with that.  As I'm sure you know, the problem is, it is easy to state the goal. Its correct/robust/solid implementation is a different story.  That's why I believe committees to oversee language design are a good thing.  It's just too easy to believe something is a good idea at the time yet ends up being a really bad one, in one way or another, in the long run.  Writing code is comparatively easy, designing is hard. Quote from: PascalDragon on March 16, 2021, 01:45:17 pmI'm really considering at least coupling them to the COperators directive... At least at first blush, it makes a lot of sense to couple "<<" with the COperators directive.  It probably should have been from the beginning. ---------------------------------------------------------------------- RAW · 2021-03-16 21:01 QuoteC-language and elegance is something that does not match. QuoteHi I'm with Pascaldragon & Marcov on this one... Why add elements with a ton of work, when they're overworked anyway! I'm happy with FPC & Lazarus as they are! Regards Benny ME TOO !!!! ---------------------------------------------------------------------- marcov · 2021-03-16 21:21 Quote from: dseligo on March 16, 2021, 07:48:56 pmDid you mix me with OP who wants curly brackets in Pascal? Shouldn't I? :-) ---------------------------------------------------------------------- winni · 2021-03-16 21:40 Quote from: avra on March 16, 2021, 03:54:28 pm I have an idea. Why don't you go the other way around? Go to GCC developers and suggest them to bring more of Pascal into C? Just tell me where so I can follow the discussion...      Hi! Great idea! And until this idea succeeds we should assume that everything in curly brackets is a comment. In Pascal and in C. Winni ---------------------------------------------------------------------- MarkMLl · 2021-03-16 21:47 Quote from: winni on March 16, 2021, 10:40:32 pmAnd until this idea succeeds we should assume that everything in curly brackets is a comment. In Pascal and in C. :-) MarkMLl ---------------------------------------------------------------------- dseligo · 2021-03-16 22:41 Quote from: marcov on March 16, 2021, 10:21:30 pmQuote from: dseligo on March 16, 2021, 07:48:56 pmDid you mix me with OP who wants curly brackets in Pascal? Shouldn't I? :-) You shouldn't. I hate curly brackets for blocks and C 'for' loop. ---------------------------------------------------------------------- Gustavo 'Gus' Carreno · 2021-03-17 01:00 Hi dseligo, Quote from: dseligo on March 16, 2021, 11:41:00 pmYou shouldn't. I hate curly brackets for blocks and C 'for' loop.  No wonder you hate C for loop, it has all that openness on the right. You'll need more of an O shape, right? That makes a better loop, non?! Cheers, Gus ---------------------------------------------------------------------- engkin · 2021-03-17 05:04 Someone should consider creating a font to replace the glyphs for { and } with BEGIN and END. That alone will make the argument about "curly barckets" irrelevant. Edit: Similar solution could be used for people complained about using backticks `````` ---------------------------------------------------------------------- PascalDragon · 2021-03-17 08:33 Quote from: 440bx on March 16, 2021, 09:08:33 pmQuote from: PascalDragon on March 16, 2021, 01:45:17 pmI'm really considering at least coupling them to the COperators directive... At least at first blush, it makes a lot of sense to couple "<<" with the COperators directive.  It probably should have been from the beginning. I have not checked, but it could be that the addition of the C-style shift operators predates the addition of the other C-operators... ---------------------------------------------------------------------- 440bx · 2021-03-17 08:51 Quote from: PascalDragon on March 17, 2021, 09:33:36 amI have not checked, but it could be that the addition of the C-style shift operators predates the addition of the other C-operators... Now that you mention it, that's probably the reason. ---------------------------------------------------------------------- marcov · 2021-03-17 09:31 Quote from: dseligo on March 16, 2021, 11:41:00 pmYou shouldn't. I hate curly brackets for blocks and C 'for' loop.  Do you get the other point I made? That Delphi compatibility keeps the noses in the same direction? Sometimes I think that sharing source with Delphi is one of the lesser benefits of Delphi compatibility ---------------------------------------------------------------------- VTwin · 2021-03-17 14:51 Using "Code Templates" I type "b" to get a begin...end block with the cursor properly indented. Easier than a curly brace... ---------------------------------------------------------------------- MarkMLl · 2021-03-27 13:13 Quote from: Martin_fr on March 16, 2021, 03:11:55 amhttps://en.wikiped ia.org/wiki/Comparison_of_programming_languages_(syntax)#Blocks Gives about 20 {} examples. And almost twice as many other examples. Ok, https://en.wikipedia.org/wiki/List_of_programming_languages_by_typ e#Curly-bracket_languages gives approx 60 {} examples, but then there are unlisted none {} languages too. There's obviously a lot of people who crop up in this community with complaints about Pascal and implausible suggestions for its enhancement. There's a much larger number of people globally who have tried to implement a better language, leading to Dart, Go, Kotlin, Perl6, Python3, Swift and the rest not to mention a vast number of minor projects on Github and Sourceforge. It's pretty obvious that part of the popularity of alternative language implementation is due to the increased availability of computers, the increased number of practitioners, and the increase in the number and quality of language implementation tools. But I can't but help feel that there's still proportionately more "better C than C" projects than there were "better FORTRAN than FORTRAN" and "better ALGOL than ALGOL" projects, and that that increase is an indication of the profound dissatisfaction that the industry has with existing languages. MarkMLl ---------------------------------------------------------------------- winni · 2021-03-27 16:47 Hi! A list of languages which use BEGIN and END Far from being complete. Code: Text  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i     Algol60    Simula    Erre (C64)    UCSD Pascal    Turbo Pascal    Free Pascal    Object Pascal    Component Pascal    Virtual Pascal    Concurrent Pascal    PocketStudio    Kyan Pascal    Super Pascal 128  StatPascal    Pascal-XSC    Pascal ISO-AFNOR    SVS Pascal    ST PascalPlus (CCD)    gnu Pascal    Delphi    Kylix    Lazarus    Modula     Oberon    POW!    Oxygene    Seed7    VHDL    Verilog    ADA    PL/SQL (Oracle)    C/AL (Navision)    HLA (High Level Assembly)    Isabelle    HP PPL  Winni ---------------------------------------------------------------------- ojz0r · 2021-03-27 17:17 #define begin { #define end } dinner is served ---------------------------------------------------------------------- lucamar · 2021-03-27 17:31 Quote from: winni on March 27, 2021, 05:47:59 pmA list of languages which use BEGIN and END [snip] You're aware, of course, that about two thirds (rather three fourths) of your list can be reduced to "Pascal", aren't you? ---------------------------------------------------------------------- engkin · 2021-03-27 17:38 Quote from: lucamar on March 27, 2021, 06:31:00 pmQuote from: winni on March 27, 2021, 05:47:59 pmA list of languages which use BEGIN and END [snip] You're aware, of course, that about two thirds (rather three fourths) of your list can be reduced to "Pascal", aren't you? Give him a break, he made his point with a wrong proof. I would like to add: he is probably unbiased, as he came to this conclusion using a scientific research, his list is most likely comprehensive. I still think the "dialect" of the source code should be customizable, but not part of the compiler. ---------------------------------------------------------------------- winni · 2021-03-27 17:43 Quote from: lucamar on March 27, 2021, 06:31:00 pmQuote from: winni on March 27, 2021, 05:47:59 pmA list of languages which use BEGIN and END [snip] You're aware, of course, that about two thirds (rather three fourths) of your list can be reduced to "Pascal", aren't you? Hi 18 out of 35 are Pascal = 51% Winni ---------------------------------------------------------------------- engkin · 2021-03-27 17:51 AFAIK, Lazarus, for instance, is not a language, yet. ---------------------------------------------------------------------- MarkMLl · 2021-03-27 17:56 Quote from: winni on March 27, 2021, 05:47:59 pmA list of languages which use BEGIN and END Far from being complete. Yes, but in the broader scheme of things people aren't complaining about Pascal... they haven't heard of Pascal and the majority of working programmers weren't even born when Codegear started hiking the price of Delphi thus killing their golden goose. The point I was trying to make is that people are complaining about C/C++, and they aren't complaining about it because of some trivial syntactic detail like the tokens used to delimit a block. They're complaining- as far as I can tell- about the type handling, the lack (until comparatively recently) of native string handling, the slowness of the compilers... hence the plethora or proposed alternatives which as far as I can tell all try to address the same shortcomings but all try to do so in slightly different ways. As @ojz0r points out, even if the underlying language used begin/end it would be simple enough to use macros to tolerate { } in sourcecode. There are /far/ more things than that to worry about, many of which are subtle details of semantics. MarkMLl ---------------------------------------------------------------------- pathfinder · 2021-03-27 21:13 Shriram Krishnamurthi is one of the authors of "How to Design Programs" based on the Racket https://www.racket-lang.org/ programming language that grew out of PLT Scheme.  He is behind the development of Pyret https://www.pyret.org/, which has a Python derived syntax. Krishnamurthi has stated his reason for creating Pyret was because some people have an adverse reaction to so many parentheses and will never consider the Racket language because of them. Likewise, one of the core Racket developers, Matthew Flatt, is looking at Racket 2 (code name of Rhombus), which would look at changing the syntax of using S-expressions and infix notation to make it more mainstream and grow the user base. NetRexx, developed by Mike Cowlishaw at IBM, was the first language to run on the JVM, and it has a new release which provides complete compatability with the Java Platform Module System, which is the base for all future JVM releases.  Without evolving NetRexx it would no longer run on current and future Java releases. There is nothing wrong with evolving a language. ---------------------------------------------------------------------- MarkMLl · 2021-03-27 22:28 Quote from: pathfinder on March 27, 2021, 10:13:30 pmThere is nothing wrong with evolving a language. I agree that there is nothing wrong with evolution, and almost every language has trumpeted its superiority as soon as it has assimilated features like object-oriented programming. However the point I am trying to make is that there are a lot of people in the industry- perhaps the majority of people in the industry- who look at the dominant C/C++ based development environments and conclude that the underlying language is defective... then go on to attempt to design a better replacement which ends up being incompatible with everybody else's attempts to do the same. Obligatory XKCD: https://xkcd.com/927/ Back in the late 50s people found that they had no universal well- conceived language and cooperatively designed ALGOL, which was famously described as "not only an improvement on its predecessors but also on nearly all its successors.". Today, there are too many people working either in isolation or in the context of a single company (Google, Apple et al.)... Hell, things are so disorganised that sometimes a corporate backs two incompatible languages (I'm thinking Google with Go and Kotlin). MarkMLl ---------------------------------------------------------------------- AlanTheBeast · 2021-03-28 21:38 The language is designed for readability.  Curly braces in C is a disaster. My Superhero proposal (a few years ago) was to adopt the Ada style simple index variables not needing to be declared.  Its scope would last for the statement and block in which it appears thence to not exist out of the statement block.  Thus: 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        //. i not in existence       for i := 1 to 7 do         // i exists - probably only in a register.            begin                   // no { here  :D                somestuff;                 aproc(arr[i]);               x := y * acoolfunction(i);                writeln (i:4, x:12:3)            end;       //.   i not in existence   This was met with varying degrees of resistance, hostility and derision, alas. ---------------------------------------------------------------------- ASBzone · 2021-03-29 04:00 Quote from: pathfinder on March 27, 2021, 10:13:30 pmThere is nothing wrong with evolving a language. Yet, not every change is an evolution.  Some changes might be undesirable because they are revolutions.  Or because they are undesirable mutations (like cancer). And then there is ongoing support.  That evolution needs to be maintained, or it is counterproductive. The implication that a complaint about any specific change indicates an unwillingness to make any change at all, is incorrect. Each language has, or should have, a guiding philosophy, and that is why many of its adherents have been attracted to it.   Any changes must help to advance that goal, without undermining the experience for those who will maintain the language (or tools), or those who won't need the features proposed. These considerations should not be overlooked, especially when many who propose the changes, won't likely be the ones supporting those changes, or sticking around to enhance the userbase (which is almost always cited as one good reason to make various changes). Quote from: pathfinder on March 27, 2021, 10:13:30 pmLikewise, one of the core Racket developers, Matthew Flatt, is looking at Racket 2 (code name of Rhombus), which would look at changing the syntax of using S-expressions and infix notation to make it more mainstream and grow the user base. That's a choice that they get to make.  Hopefully, it materializes as they imagine that it will (increased user base). ---------------------------------------------------------------------- MarkMLl · 2021-03-29 08:46 Quote from: ASBzone on March 29, 2021, 06:00:55 amThe implication that a complaint about any specific change indicates an unwillingness to make any change at all, is incorrect. Reply #33 in this thread would appear to contradict that statement. My own position is that I agree that a locally-defined label for  for  loops would be useful (and, FWIW, in the spirit of ALGOL whence we all came), and also something equivalent for  with  blocks. However there is a problem here which is that because in Pascal control structures do not have an explicit  end  token, the scope of the local variable wouldn't be cleanly defined by the language's syntactic structure. Far be it from me to criticise the attitude of the core developers, but I would suggest that wholesale introduction of type helpers (hence allowing .Length etc) flies in the face of "we aren't going to change the language". While allowing mere mortals to extend types in this way (rather than having handling built into the compiler) is to be applauded, I'm not convinced that facilities of this type can be justified by "it can make Pascal look like XXXX" particularly when in practice XXXX is a pathologically ill-conceived language such as JavaScript. MarkMLl ---------------------------------------------------------------------- PascalDragon · 2021-03-29 10:57 Quote from: MarkMLl on March 29, 2021, 10:46:24 amQuote from: ASBzone on March 29, 2021, 06:00:55 amThe implication that a complaint about any specific change indicates an unwillingness to make any change at all, is incorrect. Reply #33 in this thread would appear to contradict that statement. Next time, please either link the message or quote it. So for the sake of completeness: Quote from: PascalDragon on March 16, 2021, 01:45:17 pmQuote from: yodabitiota on March 15, 2021, 11:29:23 pmt's likely i'm not the first with such suggestion so maybe there's some existing discussion or efforts about such feature that google not easily answered. Any pointers welcome. You are not the first with such suggestions and you're also not the first we're shooting down, because there simply will not be any modifications added to the compiler that changes syntax/language fundamentals. And this has not only to with us compiler developers preferring the Pascal language as it is, but also with maintainability. Every addition to the compiler, every new feature needs to be maintained. Now essentially completely reworking the language even if it would be behind a modeswitch is a big chunk of code that would need to be maintained. So no, I'm not even remotely sympathetic to these "suggestions". And now, where does my statement contradict the one by ASBzone? Please note that my statement explicitly targeted drastic changes like curved brackets instead of begin … end for blocks. Only because we reject such requests for changes does not mean that we'll reject all changes. It definitely depends on what the topic is. Quote from: MarkMLl on March 29, 2021, 10:46:24 amMy own position is that I agree that a locally-defined label for  for  loops would be useful (and, FWIW, in the spirit of ALGOL whence we all came), and also something equivalent for  with  blocks. However there is a problem here which is that because in Pascal control structures do not have an explicit  end  token, the scope of the local variable wouldn't be cleanly defined by the language's syntactic structure. While I don't support the idea of locally scoped variables for e.g. for the scope of the variable would not be a problem, because a for- statement is followed always by a single statement (which again can be a block), thus the scope of the variable would be well defined. Same for the with-statement which is followed by a single statement. Quote from: MarkMLl on March 29, 2021, 10:46:24 amFar be it from me to criticise the attitude of the core developers, but I would suggest that wholesale introduction of type helpers (hence allowing .Length etc) flies in the face of "we aren't going to change the language". While allowing mere mortals to extend types in this way (rather than having handling built into the compiler) is to be applauded, I'm not convinced that facilities of this type can be justified by "it can make Pascal look like XXXX" particularly when in practice XXXX is a pathologically ill-conceived language such as JavaScript. First of the introduction of helper types was due to Delphi. Second this doesn't change the language, it extends it. A change is something that leads to existing code no longer compiling or working while an extension (ideally) does not affect existing code. ---------------------------------------------------------------------- MarkMLl · 2021-03-29 12:47 Quote from: PascalDragon on March 29, 2021, 12:57:48 pmNext time, please either link the message or quote it. So for the sake of completeness: And now, where does my statement contradict the one by ASBzone? Please note that my statement explicitly targeted drastic changes like curved brackets instead of begin … end for blocks. Only because we reject such requests for changes does not mean that we'll reject all changes. It definitely depends on what the topic is. My apologies for not quoting. OK, I note what you're saying about changes which break backwards compatibility such as the use of braces and that you're /potentially/ open to things that don't. But I'd suggest that that's a clarification of what you said earlier, your unqualified "changes" would normally also be read to include non- breaking additions (more C-type operators etc.). And as far as breaking changes go the cavalier way that the developers broke FileExists() in 3.2.0 severely dented my confidence. If there were a better hole I'd go to it. Now my "modest proposal" posting https://forum.lazarus.freepascal.org/ index.php/topic,53139.msg392670.html was obviously made at least partly in jest- which is why I thought it appropriate to appropriate Swift's title. But I would point out that in that I specifically argued against replacing  begin end  with  { }  (braces), and argued that it would be more appropriate to use  [ ]  (brackets). I didn't expect anybody- either from the Pascal or the C/C++ camps- to like that, but I've yet to see anybody demonstrate that it is incompatible with current pascal usage... the bottom line is that I tried to make some arguments in its favour rather more robust than the "let's replace  begin end  crowd" normally manage to make it easier to deal with them QuoteWhile I don't support the idea of locally scoped variables for e.g. for the scope of the variable would not be a problem, because a for-statement is followed always by a single statement (which again can be a block), thus the scope of the variable would be well defined. Same for the with-statement which is followed by a single statement. I specifically said that it wasn't neatly delimited by the syntax, everybody knows how the semantics work out. In C/C++ you can do 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 {  int i = 0;...}  and it's obvious what the scope is, in Pascal you obviously have to do 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 var i: integer;begin...end  Now once you start thinking about a locally-scoped variable you've got 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 for...var i: integer...begin...end  or its equivalent in C/C++. But what is the end of the scope... OK, we all know it applies to a single statement but why then do we need a  begin end  pair even in a one-line function/procedure/program? :-) QuoteFirst of the introduction of helper types was due to Delphi. Second this doesn't change the language, it extends it. A change is something that leads to existing code no longer compiling or working while an extension (ideally) does not affect existing code. OK, so it's Delphi that's courting popular favour by pretending that it's JavaScript :-) But is it really still sufficiently influential that it's worth emulating? In any event, I applaud having the flexibility in the language that things like that /can/ be defined, rather than having to be hardwired (like the field widths in Write()). Quick question if I may at this point: either you or another of the core developers described class helpers as being a nasty hack that they wished would go away. While I agree that they're nasty from the POV of object accessibility etc. they're undeniably useful: does the core team similarly feel that type helpers are hackish? MarkMLl ---------------------------------------------------------------------- 440bx · 2021-03-29 13:09 Quote from: PascalDragon on March 29, 2021, 12:57:48 pmOnly because we reject such requests for changes does not mean that we'll reject all changes. That may be true but, so far, the impression is that any user suggestion will be rejected as a matter of course.  As I type this, I'm thinking about the language extension that would allow it to initialize a variable group instead of restricting initialization to a single variable.   Really simple extension too (except if the original compiler code was ill-conceived leading its implementation to be complicated/hard.) ---------------------------------------------------------------------- MarkMLl · 2021-03-29 13:27 Quote from: 440bx on March 29, 2021, 03:09:01 pmAs I type this, I'm thinking about the language extension that would allow it to initialize a variable group instead of restricting initialization to a single variable.   Really simple extension too (except if the original compiler code was ill-conceived leading its implementation to be complicated/hard.) Although in fairness that gets hairy if the assignands aren't all of identical type. MarkMLl ---------------------------------------------------------------------- ASBzone · 2021-03-29 13:42 Quote from: MarkMLl on March 29, 2021, 10:46:24 amQuote from: ASBzone on March 29, 2021, 06:00:55 amThe implication that a complaint about any specific change indicates an unwillingness to make any change at all, is incorrect. Reply #33 in this thread would appear to contradict that statement. MarkMLl I won't belabor my response too much, because PascalDragon has already dealt with it at length, but I've seen his response (and that of others) often enough in these types of posts to understand the context of any opposition.  And that is why I also attempted to be clear that every request for change does not necessarily represent the evolution of a language.  It can be something else entirely, and need not be automatically be embraced. Thus, my statement needs to be considered with all the context that it came with, as do the statements of PascalDragon and others. ---------------------------------------------------------------------- Zvoni · 2021-03-29 13:45 Quote from: MarkMLl on March 27, 2021, 11:28:48 pm*snipp* However the point I am trying to make is that there are a lot of people in the industry- perhaps the majority of people in the industry- who look at the dominant C/C++ based development environments and conclude that the underlying language is defective... then go on to attempt to design a better replacement which ends up being incompatible with everybody else's attempts to do the same. *snipp* Point in case: The desaster Microsoft created with the transition from vb6 to VB.Net (Yes, nothing to do with C/C++ as mentioned in the quote, but the principle applies) Bottom line: Microsoft managed to put off people using Basic as a developement language. In the german language there is a Proverb for something like that: "Verschlimmbessern" (I have no idea how to translate that into english ---------------------------------------------------------------------- ASBzone · 2021-03-29 13:47 Quote from: MarkMLl on March 29, 2021, 03:27:49 pmQuote from: 440bx on March 29, 2021, 03:09:01 pmAs I type this, I'm thinking about the language extension that would allow it to initialize a variable group instead of restricting initialization to a single variable.   Really simple extension too (except if the original compiler code was ill- conceived leading its implementation to be complicated/hard.) Although in fairness that gets hairy if the assignands aren't all of identical type. MarkMLl If I recall, the situation under consideration was of the following variety: 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 var  Variable1, Variable2, Variable3: integer = 0;  and/or 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 begin  ...  Variable1, Variable2, Variable3 := 10;   // All identical types  ...end; ---------------------------------------------------------------------- ASBzone · 2021-03-29 13:49 Quote from: Zvoni on March 29, 2021, 03:45:37 pmIn the german language there is a Proverb for something like that: "Verschlimmbessern" (I have no idea how to translate that into english LOL Here's what I found:  "This word literally equates to making something worse during the act of trying to improve it." ---------------------------------------------------------------------- PierceNg · 2021-03-29 13:53 Quote from: Zvoni on March 29, 2021, 03:45:37 pmIn the german language there is a Proverb for something like that: "Verschlimmbessern" (I have no idea how to translate that into english The Internet English translation of that word is "improveworsement". ---------------------------------------------------------------------- 440bx · 2021-03-29 13:54 Quote from: ASBzone on March 29, 2021, 03:47:01 pmIf I recall, the situation under consideration was of the following variety: 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 var  Variable1, Variable2, Variable3: integer = 0;  and/or 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 begin  ...  Variable1, Variable2, Variable3 := 10;   // All identical types  ...end; Yes, I would like to see the FIRST one implemented.  I don't care for the second one because, in that case, MarkMLI's point that they must all be of the same type, which is not guaranteed in the code part, comes into play (in addition to that, I don't recall needing something like that much.) ---------------------------------------------------------------------- ASBzone · 2021-03-29 14:12 Quote from: 440bx on March 29, 2021, 03:54:02 pmYes, I would like to see the FIRST one implemented. Likewise. ---------------------------------------------------------------------- AlanTheBeast · 2021-03-29 20:18 Quote from: ASBzone on March 29, 2021, 04:12:10 pmLikewise. Likewise^2 I'd even go as far as a "clearlocal" pragma that gens the code to clear all local vars to 0, or an instruction ClearLocalVars; 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 Procedure HappyPlace; var      x, y: real;      i, j: word;{$CLEARLOCAL}begin  or 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 Procedure HappyPlace;var      x, y: real;      i, j: word;begin       ClearLocalVars; ---------------------------------------------------------------------- Fred vS · 2021-03-29 20:58 Quote from: ASBzone on March 29, 2021, 03:47:01 pmQuote from: MarkMLl on March 29, 2021, 03:27:49 pmQuote from: 440bx on March 29, 2021, 03:09:01 pmAs I type this, I'm thinking about the language extension that would allow it to initialize a variable group instead of restricting initialization to a single variable.   Really simple extension too (except if the original compiler code was ill-conceived leading its implementation to be complicated/hard.) Although in fairness that gets hairy if the assignands aren't all of identical type. MarkMLl If I recall, the situation under consideration was of the following variety: 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 var  Variable1, Variable2, Variable3: integer = 0;  and/or 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 begin  ...  Variable1, Variable2, Variable3 := 10;   // All identical types  ...end;  Something like this ? Fre;D ---------------------------------------------------------------------- 440bx · 2021-03-29 21:33 Quote from: Fred vS on March 29, 2021, 10:58:22 pmSomething like this ? Fre;D That's it.  I didn't know you had already suggested that improvement to the language. 7 years ago, the suggestion had strong opposition. When I made it, it only received some mild opposition.  At this rate, there is hope, maybe in another 7 or 14 years it might make it into FPC.   If anyone needed a reason to live long and prosper, there is one now!. ---------------------------------------------------------------------- Fred vS · 2021-03-29 21:49 Quote from: 440bx on March 29, 2021, 11:33:55 pmQuote from: Fred vS on March 29, 2021, 10:58:22 pmSomething like this ? Fre;D That's it.  I didn't know you had already suggested that improvement to the language. 7 years ago, the suggestion had strong opposition. When I made it, it only received some mild opposition.  At this rate, there is hope, maybe in another 7 or 14 years it might make it into FPC.   If anyone needed a reason to live long and prosper, there is one now!.  Yes, maybe teenage suggestions are too young. Fre;D ---------------------------------------------------------------------- Seenkao · 2021-03-29 23:27 Quote from: PierceNg on March 29, 2021, 03:53:14 pmQuote from: Zvoni on March 29, 2021, 03:45:37 pmIn the german language there is a Proverb for something like that: "Verschlimmbessern" (I have no idea how to translate that into english The Internet English translation of that word is "improveworsement".  Это означает ухудшить. Eng: It means to worsen. ---------------------------------------------------------------------- ----- Извиняюсь, изначально не читал с чего всё началось. Не стоит многое изменять во FreePascal. Первоначальная причина: это язык достаточно прост для изучения и позволяет не наделать ошибок новичкам. Вторая причина: далеко не все "улучшения" - это улучшение!!! Каждый раз, когда что-то хотят внести новое - надо десять раз подумать и решать ("семь раз отмерь, один раз отрежь"). Не стоит ровняться на другие ЯП! От слова "совсем"! Не всё, что есть в других языках - хорошо! Язык паскаль, достаточно хорошо читается начинающим программировать, а впоследствии, уже становится не так важно, как это выглядит. Скобки это или begin/end. Да, в некоторых случаях очень удобно одновременно объявить переменные и задать им данные. Удобно взять и "множеству" переменных присвоить одно значение. Но! Давайте посмотрим на это со стороны программирования! Каждый, кто так будет делать, со временем не будет понимать, что происходит в программе. Будет забывать как это должно происходить в коде и будет пользоваться "тем, что легче". Как итог, как программист такой человек будет деградировать. А код, создаваемый такими людьми, будет расти. Я ориентируюсь на основную массу людей, что сейчас идут в программисты. Лично я считаю, что большую часть надо сразу отсеивать и отправлять пользоваться конструкторами. И когда человек уже сам захочет углубиться в программирование, то "милости просим". google translate: I apologize, initially I did not read how it all started. Don't change a lot in FreePascal. The original reason: This language is easy enough to learn and avoids making mistakes for beginners. The second reason: not all "improvements" are improvements !!! Every time they want to introduce something new - you have to think and decide ten times ("measure seven times, cut once"). Do not be equal to other programming languages! From the word "absolutely"! Not everything in other languages ​​is good! The Pascal language is readable enough for beginners to program, and later, it becomes not so important as it looks. The parentheses are either begin/end. Yes, in some cases it is very convenient to simultaneously declare variables and set data to them. It is convenient to take and assign one value to a "set" of variables. But! Let's look at this from the programming side! Anyone who does this will eventually not understand what is happening in the program. He will forget how it should be done in the code and will use "what is easier". As a result, as a programmer such a person will degrade. And the code these people write will grow. I am guided by the bulk of people who are now going to be programmers. Personally, I think that most of it should be immediately sifted out and sent to use the constructors. And when a person himself wants to delve into programming, then "you are welcome." ---------------------------------------------------------------------- MarkMLl · 2021-03-30 06:30 Quote from: Seenkao on March 30, 2021, 01:27:02 amDon't change a lot in FreePascal. The original reason: This language is easy enough to learn and avoids making mistakes for beginners. The second reason: not all "improvements" are improvements !!! Every time they want to introduce something new - you have to think and decide ten times ("measure seven times, cut once"). Broadly agreed. In particular don't relax type automatic conversion any further: if anything tighten it. MarkMLl ---------------------------------------------------------------------- PascalDragon · 2021-03-30 07:19 Quote from: MarkMLl on March 29, 2021, 02:47:23 pmQuote from: PascalDragon on March 29, 2021, 12:57:48 pmNext time, please either link the message or quote it. So for the sake of completeness: And now, where does my statement contradict the one by ASBzone? Please note that my statement explicitly targeted drastic changes like curved brackets instead of begin … end for blocks. Only because we reject such requests for changes does not mean that we'll reject all changes. It definitely depends on what the topic is. My apologies for not quoting. OK, I note what you're saying about changes which break backwards compatibility such as the use of braces and that you're /potentially/ open to things that don't. But I'd suggest that that's a clarification of what you said earlier, your unqualified "changes" would normally also be read to include non- breaking additions (more C-type operators etc.). C-operators are a bad example, cause essentially all core devs consider them a bad idea nowadays. Quote from: MarkMLl on March 29, 2021, 02:47:23 pmAnd as far as breaking changes go the cavalier way that the developers broke FileExists() in 3.2.0 severely dented my confidence. If there were a better hole I'd go to it. With the extension for the support to follow symbolic links or not (which was due to Delphi compatibility) it was decided to make the behaviour consistent across platforms. Quote from: MarkMLl on March 29, 2021, 02:47:23 pmQuoteWhile I don't support the idea of locally scoped variables for e.g. for the scope of the variable would not be a problem, because a for-statement is followed always by a single statement (which again can be a block), thus the scope of the variable would be well defined. Same for the with-statement which is followed by a single statement. I specifically said that it wasn't neatly delimited by the syntax, everybody knows how the semantics work out. In C/C++ you can do Now you're mixing things. From my perspective you were talking about things like the index variable of the for-loop or the captured expression of the with-statement. These have well defined scopes. For "ordinary" inline variables I agree however that the scoping rules of Pascal are not well defined for that (I wonder how Delphi handles them...). But we have a moratorium on the topic of inline variables anyway... Quote from: MarkMLl on March 29, 2021, 02:47:23 pmQuoteFirst of the introduction of helper types was due to Delphi. Second this doesn't change the language, it extends it. A change is something that leads to existing code no longer compiling or working while an extension (ideally) does not affect existing code. OK, so it's Delphi that's courting popular favour by pretending that it's JavaScript :-) But is it really still sufficiently influential that it's worth emulating? It's not JavaScript. Delphi introduced that syntax with Delphi.NET as the Delphi equivalent of extension methods which are in my opinion much less well declared than Delphi's helper types are (taken from here): 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 public static class MyExtensions{    public static int WordCount(this String str)    {        return str.Split(new char[] { ' ', '.', '?' },                       StringSplitOptions.RemoveEmptyEntries).Length;    }} This will allow code like this: 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 string s = "Hello Extension Methods";int i = s.WordCount(); While the usage is the same in Delphi/FPC the declaration is in my opinion much better: 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 type  TMyExtensions = type helper for String  private    function GetWordCount: SizeInt;  public    property WordCount: SizeInt read GetWordCount;  end; Class and record helpers were originally implemented by me (one of my first contributions to the compiler) and they were explicitly added due to Delphi compatibility. Since then however we have embraced them more by introducing the explicit type helper that can be used for classes, records, primitive types and nowadays even interfaces (what Delphi does not support) and I still plan to extend (pun intended) them to essentially all types. And there's also the MultiHelpers modeswitch that got introduced around two years ago that allows multiple helpers for the same type to be in scope without having them inherit from each other (which was by the way a language extension by a third party developer!). Quote from: MarkMLl on March 29, 2021, 02:47:23 pmQuick question if I may at this point: either you or another of the core developers described class helpers as being a nasty hack that they wished would go away. While I agree that they're nasty from the POV of object accessibility etc. they're undeniably useful: does the core team similarly feel that type helpers are hackish? I don't know who said that. As I said however we have embraced them now with default helpers being available in the SysUtils unit and extensions like MultiHelpers. Quote from: 440bx on March 29, 2021, 03:09:01 pmQuote from: PascalDragon on March 29, 2021, 12:57:48 pmOnly because we reject such requests for changes does not mean that we'll reject all changes. That may be true but, so far, the impression is that any user suggestion will be rejected as a matter of course.  As I type this, I'm thinking about the language extension that would allow it to initialize a variable group instead of restricting initialization to a single variable.   Really simple extension too (except if the original compiler code was ill-conceived leading its implementation to be complicated/hard.) See above example: the support for multiple helpers was done by a third party developer and they are currently also working on implicit specialization of generic routines (mainly bottlenecked by me reviewing it, though to be fair, that's also for Delphi compatibility) and they also kicked off a very interesting discussion about a trait- like extension on fpc-pascal. So saying that we're not allowing any extensions in is wrong. Quote from: Seenkao on March 30, 2021, 01:27:02 amDon't change a lot in FreePascal. The original reason: This language is easy enough to learn and avoids making mistakes for beginners. The second reason: not all "improvements" are improvements !!! Every time they want to introduce something new - you have to think and decide ten times ("measure seven times, cut once"). And this second reason is exactly why we're relatively strict with language extensions. We don't add everything and the kitchen sink just because someone says "it's good" even if it just a minuscle thing like 440bx's suggestion of multiple initializations (though I really should reread that thread...). ---------------------------------------------------------------------- ASBzone · 2021-03-31 18:45 Quote from: PascalDragon on March 30, 2021, 09:19:16 amQuote from: Seenkao on March 30, 2021, 01:27:02 amDon't change a lot in FreePascal. The original reason: This language is easy enough to learn and avoids making mistakes for beginners. The second reason: not all "improvements" are improvements !!! Every time they want to introduce something new - you have to think and decide ten times ("measure seven times, cut once"). And this second reason is exactly why we're relatively strict with language extensions. We don't add everything and the kitchen sink just because someone says "it's good" even if it just a minuscle thing like 440bx's suggestion of multiple initializations (though I really should reread that thread...). That is my general stance as well.   But, I also happen to like the multi-initialization suggestion, so I would be encouraged if you would, in fact, find an opportunity to re-read that thread.    I'm also quite aware that I don't have the time or necessarily the capabilities to make those changes myself, or I would make a patch myself and offer it to review/acceptance. ---------------------------------------------------------------------- MarkMLl · 2021-04-08 19:49 Quote from: AlanTheBeast on March 28, 2021, 11:38:28 pmThe language is designed for readability.  Curly braces in C is a disaster. My Superhero proposal (a few years ago) was to adopt the Ada style simple index variables not needing to be declared.  Its scope would last for the statement and block in which it appears thence to not exist out of the statement block.  Thus: 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        //. i not in existence       for i := 1 to 7 do         // i exists - probably only in a register.            begin                   // no { here  :D                somestuff;                 aproc(arr[i]);               x := y * acoolfunction(i);                writeln (i:4, x:12:3)            end;       //.   i not in existence   This was met with varying degrees of resistance, hostility and derision, alas. That proposal is all very well if the limits are- as in your example- literal constants. It's much less attractive if they're computed. I've never tried it, but I suspect that you could in principle write complex programs where every  for  clause and every array declaration operated on an explicit subrange type. Now in that case you could obviously write something like for i in TSomething do without an explicit declaration while still retaining range checking. MarkMLl ---------------------------------------------------------------------- AlanTheBeast · 2021-04-08 20:30 Quote from: MarkMLl on April 08, 2021, 09:49:52 pm That proposal is all very well if the limits are- as in your example- literal constants. It's much less attractive if they're computed. I've never tried it, but I suspect that you could in principle write complex programs where every  for  clause and every array declaration operated on an explicit subrange type. Now in that case you could obviously write something like for i in TSomething do without an explicit declaration while still retaining range checking. At the time I might not have presented it clearly enough.  When asked if it should allow enumerated types, I replied "why not?" and things devolved quickly.  (Never mind general snarkiness).  I just reviewed the enumerated type declaration and see that one can have the ord value of the first member initialized to an arbitrary value (and the rest follow of course...).  Was that in original Pascal?  I don't recall it being so.. But in the end, yes, I believe if such were to be adapted it should be for that dirt simple case of needing a simple index variable and only for such.  That preserves readability and interpretation and isn't a huge stretch on compiler design (IMO).   Not sure if I would go to enumerated types / subranges of same; as the absence of the declaration (near the action - in the proc/func) for the reader would be confusing or at least frustrating. But as I presented it recently it seems to be clear enough for all. ---------------------------------------------------------------------- MarkMLl · 2021-04-08 20:40 Quote from: AlanTheBeast on April 08, 2021, 10:30:30 pmI just reviewed the enumerated type declaration and see that one can have the ord value of the first member initialized to an arbitrary value (and the rest follow of course...).  Was that in original Pascal?  I don't recall it being so.. Don't believe so, but there's potential pain in the area: there's no real mechanism for extending an enumeration if- as an example- it represents additional operations or statuses in a subclass. Note that I'm not necessarily saying there ought to be, I'm just "tellin' it as it is". MarkMLl ---------------------------------------------------------------------- trev · 2021-04-08 23:26 Quote from: PascalDragon on March 30, 2021, 09:19:16 amQuote from: MarkMLl on March 29, 2021, 02:47:23 pmAnd as far as breaking changes go the cavalier way that the developers broke FileExists() in 3.2.0 severely dented my confidence. If there were a better hole I'd go to it. With the extension for the support to follow symbolic links or not (which was due to Delphi compatibility) it was decided to make the behaviour consistent across platforms. Unfortunately the end result is that it broke a lot of code (including in Lazarus). And as for consistency, how do you rename a directory? Of course, you use renameFile() ! How's that for consistency? Especially when the justification provided was: QuoteFileExists on Unix-based systems Reason for change: Directories are not files, thus it was illogical for FileExists to return True for existing directories. Also this brings it in line with Windows and Delphi. Directories are not files on UNIX /UNIX-like systems? Really? But they are when they need renaming? Talk about consistency. ---------------------------------------------------------------------- MarkMLl · 2021-04-09 07:13 Quote from: trev on April 09, 2021, 01:26:46 amUnfortunately the end result is that it broke a lot of code (including in Lazarus). And the developers dropped it on everybody with no use of the "experimental" etc. procedure attributes which would at least have resulted in a compilation warning. It was amateur in the extreme, and seriously dented my confidence in both the language and developers. MarkMLl ---------------------------------------------------------------------- marcov · 2021-04-09 09:22 Quote from: MarkMLl on April 09, 2021, 09:13:50 amQuote from: trev on April 09, 2021, 01:26:46 amUnfortunately the end result is that it broke a lot of code (including in Lazarus). And the developers dropped it on everybody with no use of the "experimental" etc. procedure attributes which would at least have resulted in a compilation warning. That's what user changes release manifests are for. If you only read one FPC documentation page every five years, read the user changes for major compiler versions. QuoteIt was amateur in the extreme, and seriously dented my confidence in both the language and developers. It was an undocumented side effect. Note that the argument against the side effect was exactly the mirror of what is posted in this thread. Now it is fixated and documented. EOD ---------------------------------------------------------------------- devEric69 · 2021-04-09 10:46 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 var  iVariable1, iVariable2, iVariable3: integer = 0;  Hello with my 2 cents: I would like too, to see this implemented. This would allow us to compete with VB3..VB6 :O) . It could be useful for a "in mass" and quick initialisation of variables, with only one line, in an RTTI way. ---------------------------------------------------------------------- Thaddy · 2021-04-09 12:02 Well, put those vars in a record and call default() on it. Problem solved... ---------------------------------------------------------------------- AlanTheBeast · 2021-04-09 12:12 Quote from: Thaddy on April 09, 2021, 02:02:15 pmWell, put those vars in a record and call default() on it. Problem solved... That's a problem created.  The proposed change is a natural IMO. Once upon a time Pascal did not have initialization of a variable in the declaration.  Now it does. That that doesn't clear or initialize an array is incomplete. ---------------------------------------------------------------------- devEric69 · 2021-04-09 12:21 I think like @AlanTheBeast (normal, as he's the best). I know the default statement: but, it's less "natural" and practical, than a direct assignment with a real value (0, or 55, or nil for a pointer) at the moment of declaration. And such a solution would less pollute the visual of the debugger on such traced variables. It could also be useful in order to distinguish a locally initialized variable (what I call a "local static" variable, i.e. reified from call to call of a same routine), to quickly distinguish its original assignment value from another assignment further down in the same event (e.g. eliminating the problem of reentrance in the same event due to the side effects of the same said event). ---------------------------------------------------------------------- devEric69 · 2021-04-09 13:11 Well, after re-reading of myself, the problem seems to be solved with the const keyword (nevertheless, it's strange; I would have done that in vars). Isn't it? ---------------------------------------------------------------------- PascalDragon · 2021-04-09 13:23 Quote from: trev on April 09, 2021, 01:26:46 amQuote from: PascalDragon on March 30, 2021, 09:19:16 amQuote from: MarkMLl on March 29, 2021, 02:47:23 pmAnd as far as breaking changes go the cavalier way that the developers broke FileExists() in 3.2.0 severely dented my confidence. If there were a better hole I'd go to it. With the extension for the support to follow symbolic links or not (which was due to Delphi compatibility) it was decided to make the behaviour consistent across platforms. Unfortunately the end result is that it broke a lot of code (including in Lazarus). And as for consistency, how do you rename a directory? Of course, you use renameFile() ! How's that for consistency? Especially when the justification provided was: QuoteFileExists on Unix-based systems Reason for change: Directories are not files, thus it was illogical for FileExists to return True for existing directories. Also this brings it in line with Windows and Delphi. Directories are not files on UNIX /UNIX-like systems? Really? But they are when they need renaming? Talk about consistency. Complain to Borland about this "inconsistency". Or heck, even Microsoft, cause that's what the Delphi API in this case is based on as they have MoveFile to rename both directories and files. And it simply was a bad idea back then to have that difference in FileExists and to have it documented. ---------------------------------------------------------------------- devEric69 · 2021-04-09 13:33 Quote from: devEric69 on April 09, 2021, 03:11:57 pmWell, after re- reading of myself, the problem seems to be solved with the const keyword (nevertheless, it's strange; I would have done that in vars). Isn't it? Hello @all, I wanted to add, that old VB knew how to do that, in the vars. I'm sure of that. And AFAIK, a constant is indeed a constant. ---------------------------------------------------------------------- AlanTheBeast · 2021-04-09 15:50 Quote from: devEric69 on April 09, 2021, 02:21:48 pmI think like @AlanTheBeast (normal, as he's the best). 3rd or 4th, but I am the humblest. Quote from: devEric69 on April 09, 2021, 02:21:48 pmto quickly distinguish its original assignment value from another assignment further down in the same event (e.g. eliminating the problem of reentrance in the same event due to the side effects of the same said event). In a procedure or function, each instance would have its own stack vars therefore its own 'clean' start ... earlier instances would retain what they have. ---------------------------------------------------------------------- Fred vS · 2021-04-09 16:00 Quote from: devEric69 on April 09, 2021, 03:33:00 pmQuote from: devEric69 on April 09, 2021, 03:11:57 pmWell, after re-reading of myself, the problem seems to be solved with the const keyword (nevertheless, it's strange; I would have done that in vars). Isn't it? Hello @all, I wanted to add, that old VB knew how to do that, in the vars. I'm sure of that. Hum, if Delphi does not do it, better forget it. Or maybe wait until the proposal reaches adulthood (the suggestion is very young, it is only 7 years old). ---------------------------------------------------------------------- devEric69 · 2021-04-09 16:32 Quote from: AlanTheBeast on April 09, 2021, 05:50:01 pmQuote from: devEric69 on April 09, 2021, 02:21:48 pmI think like @AlanTheBeast (normal, as he's the best). 3rd or 4th, but I am the humblest. Oh! I understand @AlanTheBeast. I hope you're not being too hard with yourself. Quote from: Fred vS on April 09, 2021, 06:00:19 pmHum, if Delphi does not do it, better forget it. Delphi, I don't believe (or I've never noticed it). But at least for old VB5, it's sure from memory (1997), even if it's off-topic with fcp. ---------------------------------------------------------------------- dtoffe · 2021-04-10 12:16 Quote from: PierceNg on March 29, 2021, 03:53:14 pmQuote from: Zvoni on March 29, 2021, 03:45:37 pmIn the german language there is a Proverb for something like that: "Verschlimmbessern" (I have no idea how to translate that into english The Internet English translation of that word is "improveworsement".  I got "disimprovement" or "disimprove", funny... ---------------------------------------------------------------------- trev · 2021-04-12 05:53 Feature bloat: Psychology boffins find people tend to add elements to solve a problem rather than take things away ---------------------------------------------------------------------- MarkMLl · 2021-04-12 07:52 Quote from: trev on April 12, 2021, 07:53:23 amFeature bloat: Psychology boffins find people tend to add elements to solve a problem rather than take things away Agreed. But this is related to toughening up the underlying language, and over the years the increase in program size and the increased number of ways that a program can be exposed to malefactors means that anything that increases the likelihood that variables be properly initialised and tightens up scoping rules confers a reliability advantage. The alternative to ensuring that programmers correctly initialise variables and understand their scope is to limit the size of their programs, and to ban public systems (web servers etc.). MarkMLl