Making a plea :)

[VisualLab]

So the problem will grow (regardless of the UTF-8 vs. UTF-16 vs. UTF-32 issue).

But theres a difference between maybe in the future running out of codepoints, and knowing while you write your standard that you don't have enough codepoints. When the UTF-16 spec was written they already knew that it is not sufficient, this is why unicode planes exist. Microsoft has an excuse, they started implementing before UTF-16 was finalized, and before UTF-8 was available. Embarcadero doesn't

OK. I have no choice anyway, since FPC and Lazarus use UTF-8

I mean you can use R, there are specialized languages for everything, but whenever I worked with non computer scientists, e.g. I did my masters thesis in a project chaired by electrical engineers, or worked during my masters on some medical research, they all used python. Because to non computer scientists it's easy, intuitive and provides all the tools you need.

At least in academia, yes it is. When I left academia, every engineering and medical chair has made their switch to python. No more R or Matlab. Within like 4 years all alternatives nearly completely died down and as I was working at some of these chairs, I can tell you it werent nefarious reasons, it was just that Python was the new thing that all the students wanted to work with. Python has just won.

Only that it may vary depending on the university in a given country, and even more so between countries. Just because students want something does not mean it is a good choice. Especially since students don't have much experience yet (or even none at all). The popularity of the tool on the Internet is rather at work here (because there are many ready-made ones, so you can copy them and improve them until something works for the given data). Using a hobby tool like Python is quite risky in science or medicine. Just compare it with C and the requirements that a project created in it must meet (e.g. MISRA C). C has its quirks, but is much better designed than Python (and is a few decades older, so it's been "sealed down" a bit).

And just from that I don't think that it can be a bad language, when within a few years it completely captures multiple domains (and this was all prior to the big investments of MS and co), all by itself, there must something be to the language.

Well, it's a translation like "millions of flies can't be wrong so...". Just because people have some judgment (often naive) doesn't mean they're right. After all, being right doesn't depend on the number of people, but on whether something is real or not. People once believed that lightning was thrown by the gods from the heavens. Only a few doubted it (and even fewer ridiculed it, because an angry crowd could maim or kill them). Python's popularity stems from the views spread on the Internet that Python is the best possible programming language. Since most Python users have no idea what programming is all about, they believe it. Besides: (1) its basics are indeed quite easy to learn and (2) on the Internet you can find many scripts solving typical tasks. And this is enough for most Python users. But not for everyone. And I belong to the group of those for whom Python is definitely too primitive

For example, what bothers me the most is the lack of types

Good news then for you, this was introduced just 10 years ago with PEP 484 in 2014.

This is a hint to the interpreter. There is no need to declare types (like in C++ or Object Pascal).

poor class emulation

Because it's not an OOP language, it was never intended to have classes, at least not in the OOP sense. Python is a templating language, which you can use to emulate OOP, but it's correct, if you want to do OOP, you should use an OOP language. But thats like driving your car into the lake and then complaining to the manufacturer that it's very bad at swimming.

I completely agree with you on this point. That's why I've never tried to use Python for serious programming using its "classes".

The need to configure the entire eco-system on each computer where you want to run something Python. It is too much time wasting. And no, Docker (or other such "inventions") are not a solution to this problem, they are just a clumsy and naive attempt to get around a serious problem. Problems are solved permanently and effectively, not by applying a thick layer of putty so that the cheapness does not show through.

May I remind you that for the question on how to deploy Lazarus applications on Linux on this forum the usual answer is either: Let the user install all the dependencies according to their distro
or: Use a container like docker/flatpack/snap, but there is nearly no documentation on doing that so good luck.

I can't find the last thread of such, but just a few weeks ago someone asked that question and did not get a sufficient answer. Deploying software with dependencies is hard. And tbh. it's much harder for Lazarus, where you need to install native libraries, than it is for pyhton where pip does all the work for you

These problems with implementing applications (and therefore Lazarus) on Linux are (unfortunately) the result of design choices made by its creators (Torvalds et al.). This cannot be changed now (unless someone decides to revolutionize the Linux architecture, which I highly doubt, and there would also be a revolt by most of its users, mainly server users - and they would probably be right). In the case of Python, there are also various dependencies and versions of libraries and interpreter configurations. Besides, this Python problem is also present in Windows (but less severe).

This is caused by the simple laziness of people to learn. Nothing more. I have a very unpleasant experience with using "programs" written using HTML/CSS/JS (Electron, etc.). It's a poor emulation of real software. Moreover, it is bloated and resource-hungry in its operation. I agree that writing an "application" using Electron is incomparably easier than using, for example, Qt in C++. But if we go this way, then everything will be manufactured this way in a moment: houses, household appliances, cars, etc. From cardboard, string and plastic foil. This is technological regression, not progress.

Buuuut... it works right? Today there are more systems relying on this "bad" technology than there has been total software in circulation back in the 00s, when big heavy OOP languages where the shit. And it works really well. Yes my TV works with web technology, but it works fine and has so for the past 5 years, and I expect it to still work fine for the next 10.
Meanwhile in the 2000s all of that stuff was running Java, a language built around the software engineering best practices of the time, and tbh. only looking at the products, not considering my personal oppinion about the technology I only see improvements, not regression.

Can you really say that everything is being developed worse, when the final products are just getting better and better? To me it seems that this is perfectly well suited for the job. My TV would not be better if the apps on it were written in C++ or Java instead.

Yes. But this is an approach like: "it doesn't matter how it's done, as long as it works for now." This is accepting and even promoting trash and a bungling solution (because it is cheaper here and now). If it was solid but cheaper, it would be OK. But that's not the case. For many years (at least 10), there's been a lot of talk about ecology, recycling, reducing energy and material consumption, because the climate... etc. I agree that we shouldn't waste resources and energy. Generally, that ecology is important. In this case, script solutions are energy-hungry. There is no forward-thinking here. For now, this junk has no access to medical, aviation or military solutions. The problems will begin when some CEO decides that he can save money on expensive C++ programmers and hires cheap students, Python or other JavaScript enthusiasts.


We have different views on technological issues in IT. This is understandable and completely natural. All I can say at the end is: "I have no intention of being in a group singing the praises of Python." I evaluate technological solutions according to their features, which are useful to me or are not. Python is one of those that are not useful. If Python suits someone - OK. It doesn't suit me.

JavaScript, on the other hand, should not be used outside websites. We all know why, even though some people like it. Besides, for today's needs, it is insufficient. Something new would be useful (WebAssembly was supposed to be, but I guess Google or Mozilla are no longer interested in it).

[VisualLab]

Because it's not an OOP language, it was never intended to have classes, at least not in the OOP sense. Python is a templating language, which you can use to emulate OOP, but it's correct, if you want to do OOP, you should use an OOP language. But thats like driving your car into the lake and then complaining to the manufacturer that it's very bad at swimming.

However, I think it's fair to suggest that very often classes are overused.

But abuse depends on the programmer. With structural-procedural programming, one can also design an application (data structures, functions) "not very happily".

In fact users of languages such as C++ and Object Pascal seem to think that just because OOP was one of the guiding principles of the language it's absolutely essential to use it: even if a class is only instantiated once, and there are few abstraction/hiding advantages to be had.

This can rather be said about programmers of strictly object-oriented languages ​​(C#, Java). If someone chooses them, they know what consequences it entails. In the case of C++ or Object Pascal, this doesn't have to be the case, because they are hybrid.

[VisualLab]

That’s really strange that the makers of Delphi would not make easy to access platforms to promote their product. How much did it cost to talk to other delphi programmers?

Borland's management (this was especially visible after the post-Inprise period) was greedy for "quick money". So they were stingy. They didn't give a damn about customers and the company's welfare. They disregarded long-term action.

In addition, Borland's management tried to implement Jack Welch-style management (buying and selling smaller companies, applications, etc.). It was obvious to most people that this would end badly (many companies did this and went bankrupt). For a while, this was possible, but only in very large corporations with specific business profiles. It was a short-term game. In the long run, it gradually caused problems in the company (but by then such a smartass was already rich and retired). This happened with banks and insurance companies. Intel is also reaping the fruits of this (or rather its employees). The smaller the company (assets) was, the shorter the period of decline lasted. That is why Borland went bankrupt quickly, and Intel is only now having problems. Microsoft has also wasted a lot of money (losses) but it has a lot of assets, so it is holding up for now (but the attitude of the people in the management board probably still hasn't changed).

[MarkMLl]

OK. I have no choice anyway, since FPC and Lazarus use UTF-8

Actually, I've been wondering over the last few days: is it possible to completely override the declaration of String, e.g.

Code: Pascal  [Select][+][-]

1. type
2.   String= MyString;
3.  

The reason I ask is that I'm considering a legacy project, and in order to make the code legible to the largest number of people would very much prefer to /not/ mess around with UTF-8's variable size codepoints. At the same time I'd like to be able to support multiple input codings, and multiple internal representations depending on whether the character set is ANSI, Unicode, or some custom antique codepage.

These problems with implementing applications (and therefore Lazarus) on Linux are (unfortunately) the result of design choices made by its creators (Torvalds et al.). This cannot be changed now (unless someone decides to revolutionize the Linux architecture,

In the early days what we now colloquially refer to as Linux was often called GLX, indicating the importance of the contributions from GNU (Stallman et al.), Linux (Torvalds) and X11 (MIT). However none of these mandate a particular package management style etc., which is firmly in the hands of the various distreax teams: Red Hat, Debian (and its derivatives) and so on.

So a radically different distribution and installation architecture would be no big deal... but it would be difficult to attract users and even more difficult to attract project collaborators.

MarkMLl

[VisualLab]

Embarcadero isn't anything like the old Borland was.

True. There have been problems with their WWW services more than once. They do not learn from the mistakes of their predecessors. To earn a lot, you first have to invest a lot. Furthermore, it continues over time. Trying to get "quick money" usually ends badly.

[VisualLab]

These problems with implementing applications (and therefore Lazarus) on Linux are (unfortunately) the result of design choices made by its creators (Torvalds et al.). This cannot be changed now (unless someone decides to revolutionize the Linux architecture,

In the early days what we now colloquially refer to as Linux was often called GLX, indicating the importance of the contributions from GNU (Stallman et al.), Linux (Torvalds) and X11 (MIT). However none of these mandate a particular package management style etc., which is firmly in the hands of the various distreax teams: Red Hat, Debian (and its derivatives) and so on.

So a radically different distribution and installation architecture would be no big deal... but it would be difficult to attract users and even more difficult to attract project collaborators.

This is the result of clinging to the "Unix philosophy." He contributed to Linux replacing Unix with great success. And at the same time it contributed to the total defeat of Linux on the desktop. Even fragmentation "worked out" for the creators of Linux incomparably better than for the Unix suppliers

Unfortunately, two completely contradictory goals cannot be achieved. It was known that: "the stool on which Unix sat" was not a desktop (only mainframe computers that were replaced by servers). Plus the terrible fragmentation of Linux.

Although I have often wondered: "Would Torvalds be able to force unification on the desktop?" Unnecessary fragmentation would disappear. Desktop developers would benefit from full unification of the OS. Users, most likely, would benefit too. There would be more, easier-to-use applications. But that won't happen now.

[Warfley]

Well, it's a translation like "millions of flies can't be wrong so...". Just because people have some judgment (often naive) doesn't mean they're right.

In matters of taste, sure they are. In the end it's mostly that, a question of taste. Sure we could talk about that development in some languages is more productive or less error prone than in others. I'm well aware that weakly typed languages generally have a higher error ratio than strongly typed languages. But nobody decides to use a language because of that, otherwise we would all be using functional languages, as they have generally been shown to increse development time and decrease number of bugs, but we don't.
We chose languages with what we are most comfortable with, because even the best language doesn't help if the developer hates working with it.

I would argue that if there is such a thing as the perfect language, it's probably LISP, after all it's one of the first programming languages ever created, still in use today with many diehard fans, and has never gone through any major revision of it's core principles. A language thats so good from the very beginning that it never needed to change is pretty much the perfect language.
Yet you will never see me program in LISP because I really hate working with that language. It's perfect, but also terrible.

So yeah in the end with programming languages the most important thing is, how much programmers like it, and people really like python.

This is a hint to the interpreter. There is no need to declare types (like in C++ or Object Pascal).

It's not even that, the default interpreter simply ignores typehints. It's for additional tooling and compilers to perform the checking. Also you can add runtime checks for them. The language provides the tools through PEP 484, but to utilize it you need to add additional tooling.

But thats kinda normal that you need additional tooling, your FPC will also not work (at least on unix) if you don't have a linker installed.

These problems with implementing applications (and therefore Lazarus) on Linux are (unfortunately) the result of design choices made by its creators (Torvalds et al.). This cannot be changed now (unless someone decides to revolutionize the Linux architecture, which I highly doubt, and there would also be a revolt by most of its users, mainly server users - and they would probably be right). In the case of Python, there are also various dependencies and versions of libraries and interpreter configurations. Besides, this Python problem is also present in Windows (but less severe).

I mean thats always the problem with dependencies. Either you centralize like Linux does, which means you must trust the user to be able to figure out how to install dependencies, or you decentralize like Windows or MacOS does and you ship the same dependencies with each application.
Both has advatages and drawbacks. But python allows both. You can either require the user to install dependencies globally (e.g. using pip globally or the system package manager) or to install them locally (using a vritualenv).

I find python actually refreshingly easy, you clone a python repo and all you need to do is:

Code: Bash  [Select][+][-]

1. $> virtualenv .venv
2. $> source .venv/bin/activate
3. $> pip install -r requirements.txt

and you are done.

Sure I will have multiple instances of numpy on my machine because every project installs it seperately, but thats pretty much the same as the DLL hell on Windows

Generally, that ecology is important. In this case, script solutions are energy-hungry. There is no forward-thinking here. For now, this junk has no access to medical, aviation or military solutions. The problems will begin when some CEO decides that he can save money on expensive C++ programmers and hires cheap students, Python or other JavaScript enthusiasts.

It's always a question of scale. In a TV the thing that consumes all the energy is not the CPU running inefficient scripts. It's the big screen producing light and requiring cooling.
Even if you would write completely optimized handcrafted assembly code for the TV software, you will probably not even shave a single digit percent of the energy consumption. I would even reckon that the energy produced due to the additional development effort will be more than the total savings.
And the thing with medical or aviation stuff, I don't know what you are on about. Thats just throwing ideas around, point me to a real problem. Because I have seen software used for aviation control, and there they use very different mechanisms. Namely they very heavily go the route of formal verification. So it doesn't matter if it's python code or anything else (infact they usually use their own visual and domain specific programming languages as they are mostly engineers), because provably correct code is correct code.

JavaScript, on the other hand, should not be used outside websites. We all know why, even though some people like it. Besides, for today's needs, it is insufficient. Something new would be useful (WebAssembly was supposed to be, but I guess Google or Mozilla are no longer interested in it).

There is a good reason why web technologies are used on many things that are not websites, it's cross compatibility. You only need to port a browser and everything works exactly the same. Thats why it's used where Java was used previously. Radios, TVs, Fridges, Phones, etc.
I mean we probably all have written GUI applications with Lazarus, and I can't count how often I ran into bugs because QT has different behavior to GTK or to Windows Forms and don't get me started on cocoa.
Building something that needs to run on dozens of different small OSes is very hard. And emulated languages like Web technology completely circumvent that problem. Build your app in JavaScript and it will run on any device the same. Build it in Lazarus and your development time scales lineraly with each platform added

[VisualLab]

Sure we could talk about that development in some languages is more productive or less error prone than in others. I'm well aware that weakly typed languages generally have a higher error ratio than strongly typed languages. But nobody decides to use a language because of that, otherwise we would all be using functional languages, as they have generally been shown to increse development time and decrease number of bugs, but we don't.

Long development time seems to be not the only disadvantage of functional languages. In any case, if someone prefers to use such a language, that's their business. The only thing that can be irritating is the intrusive evangelization of those lovers of this language who consider it an ideal.

We chose languages with what we are most comfortable with, because even the best language doesn't help if the developer hates working with it.

I completely agree with the statement about working in the language in which we feel most comfortable.

I would argue that if there is such a thing as the perfect language, it's probably LISP, after all it's one of the first programming languages ever created, still in use today with many diehard fans, and has never gone through any major revision of it's core principles. A language thats so good from the very beginning that it never needed to change is pretty much the perfect language.
Yet you will never see me program in LISP because I really hate working with that language. It's perfect, but also terrible.

I'm afraid there is no such language. For example, I really like Object Pascal, but I'm not blind to its shortcomings and deficiencies. And I can appreciate the advantages of other languages. Of course, these must be advantages that are important to me (if I would use it). As for LISP, I once tried (out of curiosity) to familiarize myself with it. Unfortunately, the attempt ended in failure (I don't think LISP is perfect either). I would rather say what you said - that it's a terrible language. But if it suits someone, then OK.

So yeah in the end with programming languages the most important thing is, how much programmers like it, and people really like python.

Maybe I won't mention it again. I've expressed my opinion on Python several times in different posts. For me, it has too many flaws and very few advantages (easy to learn is definitely not enough).

This is a hint to the interpreter. There is no need to declare types (like in C++ or Object Pascal).

It's not even that, the default interpreter simply ignores typehints. It's for additional tooling and compilers to perform the checking. Also you can add runtime checks for them. The language provides the tools through PEP 484, but to utilize it you need to add additional tooling.

Yes. And this poverty of Python annoys me a lot. It has no features that are important to me.

These problems with implementing applications (and therefore Lazarus) on Linux are (unfortunately) the result of design choices made by its creators (Torvalds et al.). This cannot be changed now (unless someone decides to revolutionize the Linux architecture, which I highly doubt, and there would also be a revolt by most of its users, mainly server users - and they would probably be right). In the case of Python, there are also various dependencies and versions of libraries and interpreter configurations. Besides, this Python problem is also present in Windows (but less severe).

I mean thats always the problem with dependencies. Either you centralize like Linux does, which means you must trust the user to be able to figure out how to install dependencies, or you decentralize like Windows or MacOS does and you ship the same dependencies with each application.
Both has advatages and drawbacks. But python allows both. You can either require the user to install dependencies globally (e.g. using pip globally or the system package manager) or to install them locally (using a vritualenv).

If I use a Python "application" on my computer, then ultimately there is no problem. But if I create a program that is installed on users' computers (especially in some enterprise, e.g. in a quality control lab), and they have difficulties installing or running it (e.g. incompatibility of library versions, etc.), then I would have a serious problem. Why would I make life difficult for users and myself? That is why I prefer to program in languages ​​whose source code is compiled to machine code. Other than that, I don't work in artificial intelligence and have never been interested in that branch of computer science.

I find python actually refreshingly easy, you clone a python repo and all you need to do is:

Code: Bash  [Select][+][-]

1. $> virtualenv .venv
2. $> source .venv/bin/activate
3. $> pip install -r requirements.txt

and you are done.

Unfortunately, installing the Python interpreter and libraries is not always easy and painless. This is evidenced by posts on Python user forums asking about resolving various collisions in versions of different libraries. So, sometimes it's easy and refreshing and sometimes people grind their teeth

Generally, that ecology is important. In this case, script solutions are energy-hungry. There is no forward-thinking here. For now, this junk has no access to medical, aviation or military solutions. The problems will begin when some CEO decides that he can save money on expensive C++ programmers and hires cheap students, Python or other JavaScript enthusiasts.

And the thing with medical or aviation stuff, I don't know what you are on about. Thats just throwing ideas around, point me to a real problem. Because I have seen software used for aviation control, and there they use very different mechanisms. Namely they very heavily go the route of formal verification. So it doesn't matter if it's python code or anything else (infact they usually use their own visual and domain specific programming languages as they are mostly engineers), because provably correct code is correct code.

No, that was a pessimistic prediction on my part Let's hope it won't happen in the future.

JavaScript, on the other hand, should not be used outside websites. We all know why, even though some people like it. Besides, for today's needs, it is insufficient. Something new would be useful (WebAssembly was supposed to be, but I guess Google or Mozilla are no longer interested in it).

There is a good reason why web technologies are used on many things that are not websites, it's cross compatibility. You only need to port a browser and everything works exactly the same. Thats why it's used where Java was used previously. Radios, TVs, Fridges, Phones, etc.
I mean we probably all have written GUI applications with Lazarus, and I can't count how often I ran into bugs because QT has different behavior to GTK or to Windows Forms and don't get me started on cocoa.
Building something that needs to run on dozens of different small OSes is very hard. And emulated languages like Web technology completely circumvent that problem. Build your app in JavaScript and it will run on any device the same. Build it in Lazarus and your development time scales lineraly with each platform added

I completely agree that solutions based on a WWW browser are portable. I don't question it at all. I question the quality of their workmanship, the quality of the technology used to create them and their energy consumption (and I do not mean TV). I also agree that building solid products is time-consuming and expensive. This applies to many industrial products. After all, there is a greater chance that an oak table made by a professional carpenter will live longer than a very cheap Ikea table made of MDF boards and cardboard. Complex "applications" run in a web browser are inferior in quality and functionality to desktop applications using a typical GUI. For example, a comparison of classic Excel (or Libre Office Calc) and "Excel" running in a web browser. The web browser is suitable for performing operations on a bank account or dealing with various matters in the e-Office.

[BildatBoffin]

A little comeback to the initial topic. Inline variables.

I think they are great, useful. I've implemented them in styx and use them whenever possible in the compiler source code. From this experience i'd like to share a few things

First, as people has noticed, inline variables create a problem of scope. This is very important in the context of FreePascal because of managed types. Passed the scope your local inline variables are declared in, they have to be destroyed. This cause problems because for now the notion of "local sub-scope" does not exist, so people will start experiencing very surpring behaviors. These problems currently dont exist because of the clear style that is "locals exist from entry point to the exit point".

Secondly, inline variables are very useful for a style of programing that does not match to the FreePascal style. The initial discussion was focused on the "for" loops. Actually inline variables become beautiful in other contexts. Such as tuples, conditions (which also implies to have implicit boolean evaluation of expressions), by-reference arguments.

So finally I'd say I'm not pro-inline variables for FPC if it's just about "for-loops".

(As reference on how they are usefull here is a list of all usages in styx : https://gitlab.com/styx-lang/styx/-/snippets/3755596, using the GNU-style compiler messages...)

[PascalDragon]

Everyone will decide for themselves whether to use or not to use.

This is an inaccurate statement. Cause as soon as you work with third party code you need to be able to understand it and work with it. And if said third party code uses e.g. inline variables then you need to work with them.

Especially, as I said previously already, type inference in FPC can give a real headache (as it always assumes smaller int types, but for some reason always the largest float type)

For integer types the compiler prefers the smallest possible type, because it's always a safe choice. For floating point values it prefers the largest available type due to precision.

There seems to be an idea here that Wirth figured out everything there is to know about programming in 1980 and everything has been downhill since. This is surprising because the primary driver of new features in FPC seems to be copying Delphi. I can understand why you'd want to preserve the legacy of something historical but FPC is already way off the deep end with OOP, interfaces, generics, nested functions, dynamic arrays and everything else that was added (most for Delphi compatibility as the primary driver it appears to me).

Not necessarily, there was a time when new features were added much faster into FPC than into delphi. Generics, Operator Overloading, advanced records, etc. where all in FPC before Delphi and are still more powerful in FPC than in Delphi (delphi does not support generic functions, operators only as class operators, etc.)

Advanced records were not added to FPC before Delphi. We only added them years later, because they became more or less a necessity due to generics.

Personally, I can live happily without so-called inline variables, but I realize that younger programmers, who have had training in other languages, may want this feature. That said, if Delphi compatibility is still considered important, could we consider providing this feature only for Delphi mode and not allowing it in ObjFpc mode?

As said above: if one works with third party code then one needs to be able to work with them. Also they still need to be maintained inside the compiler independant of the mode.

It's relatively recent that the FPC team became more conservative, probably because of the growing code base of the compiler and the need for maintainance with the small team.

But the 3.3.1 (trunk?) version is just here, with large improvements in anonymous, generics, RTTI, and other. What is the reason it isn't released? Maybe because developers want to deeply test on the large different platforms where FPC is avalaible? Or what else?

We have certain desires for quality regarding releases which main currently does not fullfill.

It's relatively recent that the FPC team became more conservative, probably because of the growing code base of the compiler and the need for maintainance with the small team.

But the 3.3.1 (trunk?) version is just here, with large improvements in anonymous, generics, RTTI, and other. What is the reason it isn't released? Maybe because developers want to deeply test on the large different platforms where FPC is avalaible? Or what else?

Features not finished/debugged and target support.  Also major versions often have internal changes that might not be so visible, but also need to be tested/mature.

Like the reworked unit loading code...

It's not just universities... it would also help if businesses that develop/produce devices also provide apis in pascal. Not to say there are none, but the only one that I remember working with was Synway. In the telephony space, everything else was C/C++ based.

Many years ago (now) I wrote a TSP in Delphi (because that is what I had to use) ... I recall only finding one example which was too old. (There were enough code incomplete examples in C.) I was working with TSP versions 2.1 and 3. I'd be downvoted on Stack Exchange when asking a question, and otherwise stuck to working it out myself. Not looking for sympathy, this is just how it was about 10/15 years ago.

How come there were no forums for delphi like this forum to get help in or s delphi irc channel back then?

You mean like this? Or the German variant here.

Even QT used utf16 at some point iirc .

Qt still uses UTF-16.

So the problem will grow (regardless of the UTF-8 vs. UTF-16 vs. UTF-32 issue).

But theres a difference between maybe in the future running out of codepoints, and knowing while you write your standard that you don't have enough codepoints. When the UTF-16 spec was written they already knew that it is not sufficient, this is why unicode planes exist. Microsoft has an excuse, they started implementing before UTF-16 was finalized, and before UTF-8 was available. Embarcadero doesn't

OK. I have no choice anyway, since FPC and Lazarus use UTF-8

The next major version (3.4.0 or 4.0.0) will come in UTF-8 and UTF-16 flavours. main can after all already be compiled with String = UnicodeString.

OK. I have no choice anyway, since FPC and Lazarus use UTF-8

Actually, I've been wondering over the last few days: is it possible to completely override the declaration of String, e.g.

Code: Pascal  [Select][+][-]

1. type
2.   String= MyString;
3.  

No, there is not as String is determined through the $H switch and thus is more or less declared per unit.

The reason I ask is that I'm considering a legacy project, and in order to make the code legible to the largest number of people would very much prefer to /not/ mess around with UTF-8's variable size codepoints. At the same time I'd like to be able to support multiple input codings, and multiple internal representations depending on whether the character set is ANSI, Unicode, or some custom antique codepage.

Please note that AnsiString covers essentially all those points except UTF-16, because despite its name it's a code page aware string type with support for conversion between these code pages (including UTF-8). And for Unicode you can simply assign to UnicodeString and be done.

[ArtLogi]

e.g. in the Linux kernel devs are required to do declaration first despite GCC allowing differently, because it improves maintainence. They'd definitely benefit from a "feature" that enforces declaration first.

First, I am definitely _not_ in favor of inline variables but, there is at least one case in which they enable a programmer to write cleaner and simpler code and that is when using an "on the fly"/temporary variable makes it possible to break a complex expression into 2 or more simple ones whose results exist only until the value of the complex expression is determined.

Anonymous functions/procedure come somewhat close to providing such a facility but, they have a number of undesirable downsides that could easily be eliminated.

Take a look how Siemens TIA portals SCL (pascal/Ada derivative/look a like from 80s for PLCs) coding view is done, this "temp var" could be done in seconds if there would be managed tree view style dropdown area (split screen) on IDE (eg. Lazarus) to show and quick access to var section. Also nothing prevents to implement better "goto definition" and "cross reference" features for the variables (or views).

[440bx]

Take a look how Siemens TIA portals SCL (pascal/Ada derivative/look a like from 80s for PLCs) coding view is done, ...

I just had a truly very quick look.  I like the concept of "regions", I think that is missing in Pascal (and most currently popular procedural languages.) 

Basically, what I'd like to see in Pascal is "regions" where local types, constants and variables can be defined that exist only in the region they are defined.  Very similar to an inline/anonymous function/procedure but a "region" should _never_ require a separate stack frame as inline/anonymous functions/procedure do, plus they should never be callable.  They are just a scoping and grouping mechanism.  It's amazing how much cleaner and easier to understand code gets when a facility like that is available.

[MarkMLl]

I just had a truly very quick look.  I like the concept of "regions", I think that is missing in Pascal (and most currently popular procedural languages.) 

Basically, what I'd like to see in Pascal is "regions" where local types, constants and variables can be defined that exist only in the region they are defined.  Very similar to an inline/anonymous function/procedure but a "region" should _never_ require a separate stack frame as inline/anonymous functions/procedure do, plus they should never be callable.  They are just a scoping and grouping mechanism.  It's amazing how much cleaner and easier to understand code gets when a facility like that is available.

Which is why I've previously pointed out that local variables could be handled by relatively minor extensions to for-do and with-do. However I'd definitely /not/ make any pronouncement relating to that heralding a separate stack frame etc.: getting the semantics right might mandate changes to the syntax of e.g. the exit statement, and in that case stack handling is very much an implementation choice.

MarkMLl

[marcov]

Basically, what I'd like to see in Pascal is "regions" where local types, constants and variables can be defined that exist only in the region they are defined.

Micromanaging that is mostly old technology from before heavily optimising compilers, use a (nested) procedure and set it to inline. The time can be better spent on backend work that helps a variety of cases, rather that facilitating a crutch for manual workarounds.

[440bx]

Micromanaging that is mostly old technology from before heavily optimising compilers, use a (nested) procedure and set it to inline.

That's a very deficient solution for two (2) reasons:  1. it requires the programmer's attention to go where the function/procedure is defined to see what it does, basically, that's the very essence of spaghetti code, having one's attention diverted away from the mainline.  2. it's inefficient, "inline" doesn't always inline, it may, it may not, that's is already bad because it cannot be depended upon in all cases and, as a result, not only there will be an unnecessary stack frame, there will also be an additional pointer on the stack to point to the parent's stack frame.

The absence of a grouping construct in Pascal (and most other procedural language) is a major deficiency.