Contemporary with what? >:-)
Contemporary with what? >:-)
Of course I can't be speak for the OP, but my impression from various forums and the Internet is there is a odd and big disconnect between Pascal, Object Pascal, and Delphi in the minds of casuals. There is also a lot of negative propaganda from C/C++/C# circles against Pascal specifically. To include referring to old papers from Brian Kernighan, which do not reflect modern dialects of Pascal/Object Pascal, but used to bash Pascal anyway. There is also no mention of Pascal/Object Pascal's various advantages over C, C++, and C#.
Many casuals would have no idea that Delphi is just a product name, and the programming language is Object Pascal. Nor would many realize that Pascal became Object Pascal. This fragmented or limited awareness, can lead many thinking that Pascal is some old dead language, whose last incarnation was Turbo Pascal, or something like that.
I'm quite shocked to see people, some self-proclaimed experienced programmers included, who act like they can't do proper Internet searches (at the very least), and don't know about the evolution of Pascal to Object Pascal and then the various IDEs and compilers out there (which there are many). A quick look at the wikipedia for Pascal (programming language) and Object Pascal should give people a clue (as the language has been evolving), but it seems a lot of people glance over that.
Oddly, YouTube (Google), appears to be doing something strange when it comes to searching for Pascal (programming language). They might be putting their foot on the scale (algorithm) for corporate reasons or something is going on that doesn't make sense and doesn't happen in searches for other programming languages. You will get a lot of these slick ignorant videos of "dying languages" or "don't learn these languages" in the results, thus giving a negative impression of Pascal. In addition, search for Pascal/Object Pascal/Delphi, and get lots of videos for C#, C++, or Java in your search or suggestions. Which is a bit disturbing, considering the list of Pascal/Object Pascal/Delphi videos are quite considerable to not do that. Also, according to the controversial TIOBE index, Object Pascal/Delphi is ranked #12 (as of April 2021). That is, Object Pascal/Delphi is ranked above Go, Kotlin, or Dart (Swift, Ruby, Julia, MATLAB, and other notables). But, if the person doesn't specifically direct their YouTube search for Object Pascal or know that Delphi's programming language is Object Pascal, then they can be confused or unaware as to what is going on with the language in modern times.
Hopefully, the list of books and links we gave, should be quite helpful and informative about where contemporary Pascal/Object Pascal is at.
Surely companies like Embarcadero with financial resources available, should dedicate a small team to shed light on these old ignorances by updating forums and old entries that are relevant to internet searches, and which so many sadly take as true.
Contrast that with C (which even today is a rather sorry programming language) and the majority of compilers available support a fairly recent standard which means, a beginner can learn GPC and "move" to MSC or Intel C will little effort. That's not the case with current flavors of Pascal.
Sad to say all that because I love Pascal but, its future is very limited and likely going to get more limited as time goes by.
It might be that the fact that Lazarus/FPC is modestly successful, i.e. indicating that there is still a measure of interest in Object Pascal wider than just Delphi, is enough to convince Embarcadero that they can't just drop Delphi since doing so would lead their shareholders to ask why they've cut off a modest revenue stream.
The bottom line is, there is no group of language experts dedicating time to improving and refining the language. What there is, is a company (a Borland descendant) which will add any quick gimmick they can think of in order to get money from their customers. That's no way of designing a programming language.
I also think that Object Pascal has a bright future.
Unfortunately, not in the commercial world it doesn't.
But OP specifically asked about Pascal, i.e the *language*... although I have obviously invited him to clarify that. And if he's asking about the language without qualifying it then from our POV he might be a rank tyro with no understanding of variables and control structures, in which case if there were an outstanding book from the UCSD or early Turbo Pascal era he would be unwise to exclude it as obsolete.
I agree with you that many of the old Pascal books have significant value for learning the basics and fundamentals. If a person is starting from say zero (don't know if that is the OP's situation), jumping straight to OOP and generics is not doable. Not to mention, part of the point of Pascal, was that it's easier to learn. It can be a much more enjoyable experience and less frustrating getting up to speed with it.
Using C/C++ in Visual Studio and then GCC, can be problematic depending on what you are doing.but that's true when the programmer chooses to use extensions that are specific to an implementation. If the programmer sticks to one of the C standards, moving from one C compiler to another is usually fairly simple. That cannot be said of Pascal because Delphi's object Pascal is not a standard and Delphi's object Pascal is riddled with contradictions and inconsistencies that would not survive in a bona fide standard.
Enough so, that jumping to or between different IDEs/compilers is doable. The flavors of the language are similar enough.Yes, it's doable but, when dealing with "real programs" it is not simple and making a single source to compile and execute successfully with the various flavors can only be done when limiting oneself to the lowest denominator. IOW, a lot of useful features in one implementation or another have to be left unused.
I also think that Object Pascal has a bright future.I really hope you're right. I'd love to see Pascal being as popular as it was in the days of Turbo Pascal 3 & 4 but, I honestly don't see that happening any time soon.
If a person knows Object Pascal, they can adjust to say PascalABC's or Oxygene's flavor of the language (or those users to Free Pascal's flavor), if there is something in particular that they want.There is no doubt that adjusting to one flavor or another is possible but, not having a capable and portable definition across platforms is a very significant problem. That's what C and C++ gives programmers and the industry and, it's quite likely that is a very significant portion of their success (same with Java.)
As we speak, TIOBE (controversy aside) has Object Pascal/Delphi ranked at #12. There are a whole lot of languages below it. Funny, don't hear people claiming all those lower ranked languages have "no commercial future".
There may still be quite a few people quietly using Pascal who are not performing internet searches with the regularity of other languages, and thus depriving the planet of those kinds of flawed metrics. :)
I believe the main problem with Pascal as a language is that there is no standard pascal. The last standard dates back to 1982 (or 1990 if you include a standard that went nowhere.)
IMHO standards are there to unify vendors that want to standardize, usually for big US government contracts in the Unix sphere(where applications are traditionally delivered in source code).But, it's not just that. When an employer is looking for a programmer, if the programmer is well-versed in the current language standard then that programmer will quickly become productive.
IMHO standards are there to unify vendors that want to standardize, usually for big US government contracts in the Unix sphere(where applications are traditionally delivered in source code). Pascal was not one of them after the eighties, and to be frank few others have been since Ada.
IMHO standards are there to unify vendors that want to standardize, usually for big US government contracts in the Unix sphere(where applications are traditionally delivered in source code).But, it's not just that. When an employer is looking for a programmer, if the programmer is well-versed in the current language standard then that programmer will quickly become productive.
With Pascal it's a different story, a programmer well versed in the last Pascal standard has a long ways to go to become proficient in FPC or Delphi. Not to mention all the cases that are "undefined territory" in the current implementations which are traps for a programmer.
A programming language needs a formal definition to make it in the industry and real interest from highly qualified language designers to improve the language over the years.
Today, the Pascal language has no direction. Whatever Embarcadero/idera/whoever dreams of, is it, whether good or bad.
IMHO standards are there to unify vendors that want to standardize, usually for big US government contracts in the Unix sphere(where applications are traditionally delivered in source code). Pascal was not one of them after the eighties, and to be frank few others have been since Ada.
Pascal might have been hurt by the assumption that it would be replaced by Modula-2, standardisation of which was marginally more successful than that of Pascal.
I believe the main problem with Pascal as a language is that there is no standard pascal. The last standard dates back to 1982 (or 1990 if you include a standard that went nowhere.)
There was an intent to update the standard in 1993, but there was a perceived lack of interest, so it never went any farther.
Some older ones, like the standards body of C and C++ have become self propelling entities, while some extremely languages like C# and Java remain one vendor only (with sometimes a few satellites), and it hasn't braked them one bit.
The bottom line is, there is no group of language experts dedicating time to improving and refining the language. What there is, is a company (a Borland descendant) which will add any quick gimmick they can think of in order to get money from their customers. That's no way of designing a programming language.
Possibly another way forward is through Free Pascal/Lazarus creating their own certification exams.
I think what is often ignored when considering pascal is, how niche this language is.
Most people using FPC and Lazarus came from Delphi, and Delphi is only relevant in the corporate world.
Also, the whole terminology is kinda weird. So the language family is Pascal, which contains multiple versions like the standardized ISO pascal or Object Pascal. Object Pascal is also not really a language but a kind of sub family, Delphi and the language the FPC uses (mode objfpc), where I don't even know the proper name for, are different dialects of ObjectPascal, which are vastly different in many regards.
Discounting BASIC (including a vast array of BASIC-like embedded scripting languages) I think the only language quite so fractured is LISP.
Odd. For my feeling Delphi is mostly one person shops or one person IT departments. Teams more often conform to IT trends (rightly so or not)
This results in a lot of people simply having never heard of pascal, while knowing about C#, Python and the other languages.
The problem therefore isn't that much of people not using pascal because they got dissuaded from using it, but rather they don't use it, because they simply do not know of it's existence.
....How should an outsider get a picture of this, if there we (the Pascal community) can't even decide on a coherent vocabulary?
Odd. For my feeling Delphi is mostly one person shops or one person IT departments. Teams more often conform to IT trends (rightly so or not)
But if that's really the case how has Borland and its successors managed to keep going after investing GOK how much to make Delphi into an enterprise-level development tool?
There appears to be a significant effort to bash Pascal in C/C++/C# circles.
And usually the real reasons are boring. Legacy, done investments, not enough business of an uniform kind to justify costly and complex migrations. (*)Legacy
And usually the real reasons are boring. Legacy, done investments, not enough business of an uniform kind to justify costly and complex migrations. (*)Legacy
The biggest reason on unsuccess of Embarcadero's Oxygen. (it's not compatible with Delphi and there's no "easy migration")
The biggest problem for C++ language. The language cannot become slim as it has to support all the old features together with new features as well.
There's no "automated" tool to port the old code into new standards.
You won't hear me arguing Pascal is the most popular language in the world, or even dispute that it is on the wane, but the view from these sad language-listings-by-google demonstrates more the fundamental problem with this way of ranking rather than prove something with the absence of Delphi or pascal.The rankings I posted searched through every public project on github, these where no surveys of developers, this does literally measure what is used by people and not what people want to talk about.
Such ranking measures what is sexy, and what people want to talk about, rather than what they use.
In the mid 2000s .NET 2 came out everybody wanted to jump ship, and I have seen the colleagues categorically entering C# in surveys and blog about it, while they were only testdriving it, while Delphi brought home the bacon. In the early 2010s, I've seen them enter LAMP as platform, but ignoring that they actually did IIS+PHP+delphi backend. They enter what they tinker with.
By that measure we should have all refused javascript because of the horrible confusion it causes with Java. Stop dragging things into the discussion by the hairs.Well, I actually remember a time where this actualy lead to a lot of confusion, this was back when JavaScript wasn't as prevalent as it is now and Java Applets where still used heaviely on the web. I was active in a general programming forum back then (2012ish) and there was at least once a week a question confusing the two
...As github is the largest open source platform by far..
Discounting BASIC (including a vast array of BASIC-like embedded scripting languages) I think the only language quite so fractured is LISP.
One dialect, one (Embarcadero) and a half(Free Pascal) vendor . I think most languages are more fragmented. :)
I remember reading an article that GitHub only is not a good judge of language popularity by itself. Much more of Pascal content is pre GitHub era, and many projects are at SourceForge or on websites. Where users of a programming language mainly get their content or solutions are relative, to include how they use it can be significantly different. Comparisons need to be more comprehensive, and include many sources.Well, sourceforge is pretty dead, it hosts around half a million open source projects, github surpassed the 100 million mark in 2018. The latest number I could find was that around 1.3% of all sourceforge projects where Pascal projects (in 2013), meaning 65 thousand projects, this would make up 0.00065% of all github projects. Haskell, which is on place 25 makes up 0.39%.
Not so long ago at my university, whenever I told someone I was programming in pascal like 70% of students simply did not know what Pascal is, and we are talking about computer science students, so the kind of people you would expect the most to know about this sort of stuff. From my own experience the only people I knew that used pascal where people who once worked with Delphi usually in a professional setting (i.e. by working in a company that used Delphi since D7 or even earlier and sticked to it), or people that used to learn programming in the 2000s or earlier (like me, I first came into contact with Delphi in like 2005ish). As I said, it's not that Pascal has a bad wrap, at least with the new generation of software developers, it is more that these people simply do not know about pascal, except maybe having heard the name once as one of these "ancient" languages (like Cobol or Algol).
There appears to be a significant effort to bash Pascal in C/C++/C# circles.
And there's an unacceptable amount of C denigration (can I use that word these days?) in the Pascal community.
"We're not having that in the compiler, it's too C-like".
There appears to be a significant effort to bash Pascal in C/C++/C# circles.
And there's an unacceptable amount of C denigration (can I use that word these days?) in the Pascal community.
"We're not having that in the compiler, it's too C-like".
And we'll say similar about features that are too Java-like or too Python-like or too Whatever-like. The point is new features need to fit nicely into the Pascal feeling (and really extend the language) and more often then not the syntaxes of other languages (especially the "curly bracket" ones) simply do not.
In looking at what is taught at schools, you have to be careful not to take the situation of one country (say the USA), and think it is the same for others. Let's remember that the USA is the birth place of Unix (in terms of being built with C), and languages like; C, C++, C#, and Java. These were pushed by huge world reach American companies like AT&T (back then), Microsoft, Sun (before Oracle), etc... So it's no surprise how strong their influence is within the USA.It's not only what is tought, many languages are well known even though they aren't tought. In my country (Germany) most universities tech Java in the general programming class, C and Assembly as part of the operating system class and Matlab in math classes. But still most students know about C++, C#, JavaScript, Python or PHP.
There may still be quite a few people quietly using Pascal who are not performing internet searches with the regularity of other languages, and thus depriving the planet of those kinds of flawed metrics. :)
IMHO Pascal is in that category of languages for which most of its users are fairly advanced and need rather less "help", or more specialized than what the general web (including stackoverflow) offers, so we are not quite as visible as others.
Think, say, of COBOL programers (which are still legion), or RPG, or even Fortran. When I was programming in COBOL, the last place I went for help was Google or SO; a couple posts in Usenet and/or specialized forums (or even a couple phone calls) found way better answers to my questions and much more quickly :)
But those, of course, are not used when indexes like TIOBE are generated.
As far as dissuading people from using Pascal, I will have to disagree. There appears to be a significant effort to bash Pascal in C/C++/C# circles. It is something embedded into their culture and has roots back into numerous Pascal VS C published papers in the early 1980s.
There appears to be a significant effort to bash Pascal in C/C++/C# circles.
And there's an unacceptable amount of C denigration (can I use that word these days?) in the Pascal community.
"We're not having that in the compiler, it's too C-like".
MarkMLl
Quite a few of the people who program in ObjectPascal here also program in C or C++. There are not opposed to C and the role it plays, but to making Lazarus/FPC look more like C, when its goal and objectives are different.
But is that really C denigration?
Quite a few of the people who program in ObjectPascal here also program in C or C++. There are not opposed to C and the role it plays, but to making Lazarus/FPC look more like C, when its goal and objectives are different.
That's not the same as constantly bashing C/C++ as a language.
Pascal does not make it in the top 50 list, and are behind languages like Puppy, Logos or Elixir, which I have never even heard of.Я даже не смотрю эти рейтинги. Они что-то поменяют для меня? Для тех кто пользуется паскалем?
As far as dissuading people from using Pascal, I will have to disagree. There appears to be a significant effort to bash Pascal in C/C++/C# circles. It is something embedded into their culture and has roots back into numerous Pascal VS C published papers in the early 1980s. Arguably, Pascal was perceived as a threat or unwanted competition, and some of those dots connect back to AT&T (to include Bell Labs), where they had specific commercial interests and agendas.Да, сейчас паскаль "затаптывают" по всем фронтам. Там даже Delphi XE - ни чего сделать не может. Происходит очень сильное давление в сетях/соцсетях и других источниках информации - указывая, что Паскаль устарел и ни где не используется.
Quite a few of the people who program in ObjectPascal here also program in C or C++. There are not opposed to C and the role it plays, but to making Lazarus/FPC look more like C, when its goal and objectives are different.И... как бы я не хотел не изучать C/C++ похоже мне тоже придётся его использовать...
That's not the same as constantly bashing C/C++ as a language.
Я даже не смотрю эти рейтинги. Они что-то поменяют для меня? Для тех кто пользуется паскалем?
google translate: I don't even look at these ratings. Will they change something for me? For those who use pascal?
...
Warfley, я думаю вам не надо всё оценивать по общим статистикам. Сообщество Паскаля развивается. Люди об этом знают, и в наших силах чтоб об этом узнало больше людей! ;)
google translate: I think you don't need to judge everything by general statistics. Pascal's community is evolving. People know about it, and it is in our power to make more people know about it! ;)
Most people using FPC and Lazarus came from Delphi, and Delphi is only relevant in the corporate world. There are some interesting projects like this (https://www.benfrederickson.com/ranking-programming-languages-by-github-users/) or this (https://githut.info/) where all public github repositories are searched through and track the popularity of languages. Pascal does not make it in the top 50 list, and are behind languages like Puppy, Logos or Elixir, which I have never even heard of.
It's weird, but if it isn't ISO 1983 or ISO 1990 Pascal, then it isn't "real Pascal" to various critics. Then when you talk about Object Pascal, it starts to get really weird.Considering Object Pascal as not being "real Pascal" is reasonable. The current incarnation(s) of Object Pascal would have never come into existence if Pascal had evolved in a rational and logical manner. The current incarnations have design blunders that make anyone with some passing familiarity in language design jaw drop.
I love pascalДавайте будем честны! Вы его не любите! Для того, кто любит - нет преград! :)
A programmer who is sufficiently into programming should be able to read someone else's code! Otherwise, why is such a programmer needed? :)The problem isn't ability. The "problem" is that a programmer is entitled to protect his mental health by not reading code that is obviously detrimental to it. The U.S Founding Fathers anticipated the appearance of lousy programs by including the 8th Amendment in the Bill of Rights: "no cruel and unusual punishment", is to be tolerated in any form (source or object.)
1) First problem is the name. Pascal, Object Pascal, Delphi, PascalABC, Oxygene, FreePascal, DWScript, Modern Pascal, etc...
]The problem isn't ability. The "problem" is that a programmer is entitled to protect his mental health by not reading code that is obviously detrimental to it. The U.S Founding Fathers anticipated the appearance of lousy programs by including the 8th Amendment in the Bill of Rights: "no cruel and unusual punishment", is to be tolerated in any form (source or object.)"Хорошие времена порождают плохих программистов"...
A programmer who is sufficiently into programming should be able to read someone else's code!
1) First problem is the name. Pascal, Object Pascal, Delphi, PascalABC, Oxygene, FreePascal, DWScript, Modern Pascal, etc...
C and C++ each has many implementations that a programmer may choose. Basic? Too many to count. Python 2 and Python 3 have been in use simultaneously for years. Not to mention Common Lisp, Scheme, Smalltalk etc. especially with the modern penchant to transpile, initially to Java, now to Javascript. Maybe only Perl 5, in between killing off Perl 4 and waiting for Perl 6, was sole king of one particular programming language ecosystem.
Name is only a problem for people who use single-implementation languages exclusively.
Lastly there is also the issue of response time. If you find a bug withing a largly popular project like the gcc or .Net and you report it, it is often fixed within days, and shipped with hotfixes immediately (if it is a severe bug that is).
So does smartlinking finally work with GCC then? FPC supported smartlinking since the last millennium, even a time with the same binutils that gcc uses.
The fpc has a small development team, which has to ration their time, and can't fix every bug.
Давайте будем объективными! Я писал - читать код! Для его поддержки надо больше чем уметь читать чужой код - его надо уметь переносить или менять язык программирования. :)A programmer who is sufficiently into programming should be able to read someone else's code!
(~R∊R∘.×R)/R←1↓ιR
Unless you are familiar not only with the language but with the idioms that experienced users of the language use to solve problems you have no chance of maintaining programs written in it.
MarkMLl
google translate: Let's be objective! I wrote - read the code! To support it, you need more than being able to read someone else's code - you need to be able to port it, or change the programming language. :)
So does smartlinking finally work with GCC then? FPC supported smartlinking since the last millennium, even a time with the same binutils that gcc uses.
I believe so, but I don't know what the granularity is.
Symbol granularity of course. I believe it can eliminate a whole .o, but that is often rare so doesn't count.
The last I heard in 2016/17 timeframe was that it was slowly getting to a decent development stage for COFF, but it wasn't really end-user stuff yet.
The point I was trying to make is that the intended granularity might be a symbol, but I don't know where they've got to in practice.
In any event, I've looked through the I/O handling on more than one C/C++ development board environment, and the bottom line is that they work so hard at being portable and general-purpose that doing something simple like changing the state of an LED takes a substantial number of uSec if done "the right way".
So this is not to blame anyone, I can completely understand this, but as a result I had to abandon whole projects and throw weeks of work away.
google translate: Let's be honest! You don't love him! For the one who loves - there are no barriers! :)I love pascal, but I am not stupid, I won't choose it blindly for everything, I will always choose the language that I consider right for the job, zealously using only your favourite language only limits your ability
If we need new libraries, we take external ones and use them at our discretion. Can't use an external library? We convert the code, fix errors - use it.Fair point, but using external libraries comes with it's own can of worms (e.g. you need to translate between high level constructs like classes or dynamic types to low level constructs for the library, which can result in more work and even more bug potential), and converting and fixing code is again running into the problem that if you don't know what you are doing (e.g. because you aren't a crypto expert), you probably shouldn't be doing it.
Want to share your code? Yes please! In any programming language! (I haven't studied C / C ++, but I do read code!) A programmer who is sufficiently into programming should be able to read someone else's code! Otherwise, why is such a programmer needed? :)
Yes, the language is supported by a small team. In one case it is good, in the other it is bad. The smaller the team, the more well-coordinated (often) they work. Everyone does their own thing. And Pascal's community helps in finding existing problems. Some of them need to be addressed immediately because they are critical enough, but many can wait.The last breaking bug I reported was over a year ago and wasn't touched since then. Just imagine this wasn't a fun project, was something a client had payed me for. Should I just tell him: "I use this very niche language, it is really great, but it might be that the program you request can be delayed by several years due to compiler bugs". What do you think will the response be? Probably something along the lines: "Then why do you use that language, and why should I pay you for it?".
I'm afraid we need to end the dialogue with you, you are not interested in Pascal, you are trying to create a split here.How dare you to tell me I am not interested in pascal? I spend a lot of my free time developing open source libraries for pascal, because I believe that Pascal is a great language and I want to do my best to extend the existing infrastructure.
All the best!
... let me tell you this, there are situations in which C++ is better suited for a program than pascal, that is, you will archive the same if not better results with less effort, but there are also situations where the roles are switched, where pascal is the better choice.
I love pascal, but I am not stupid, I won't choose it blindly for everything, I will always choose the language that I consider right for the job, zealously using only your favourite language only limits your ability
Fair point, but using external libraries comes with it's own can of worms (e.g. you need to translate between high level constructs like classes or dynamic types to low level constructs for the library, which can result in more work and even more bug potential), and converting and fixing code is again running into the problem that if you don't know what you are doing (e.g. because you aren't a crypto expert), you probably shouldn't be doing it.Если мне нужно, я использую Паскаль. Нет не решаемых проблем!
It's not about reading code, it's about other people using your code. Most programmers are fine with reading any code they like, but when it comes to extend on it or work on it, this is a completely different topic. In the worst case the thing you described earlier happens, and someone decides to use your code because they like it, but comvert it to another language. Now you have just halfed the productivity that could go into that project, and potentially just created two dead projects instead of one thats alive.По этому поводу можно спорить и спорить. Но проблема тут не в Паскале! Многие проекты рождаются "мёртворождёными": потому что они не продуманы; потому что не хватило терпения; потому что просто бросили проект; потому что не видят цели проекта... можно продолжать до бесконечности. На том же GitHub больше заброшенных проектов, которые ни кому не нужны. Из них на паскале, даже 1% не наберётся.
But as I said, languages are nothing but tools, and when I start a new project, my first and foremost goal is to archive the best result possible. This includes using the right tools for the job. You can use a hammer for putting skrews in to the wall, but I reckon that using a skrew driver will give better results. It's the same for programming languages. I have used dozens of different languages in the past, and every of them has it's advantages and disadvatages, all are designed in a way that make them more fit for some purposes and less fit for others.Я надеюсь вы понимаете, что изучал я не один язык? C/C++ я просто не стал изучать и углубляться, потому что он(они) мне просто не понравился.
You wrote that you haven't studied C/C++ (leaving the fact that C and C++ are two different languages and studying one of them is already an act in itself), well I have (at least C++, my C is really bad), and let me tell you this, there are situations in which C++ is better suited for a program than pascal, that is, you will archive the same if not better results with less effort, but there are also situations where the roles are switched, where pascal is the better choice.
As a software developer it's your due dilligence to provide the best product in the most efficient manner, what this means in detail depends on your requirements, and if you choose your tools knowing that there are other tools out there better fitted for that purpose, you are giving up on that premise.
And of course you can do what you want, but personally won't choose to create an inferior product just because I wanted to use my favorite toy.
google translate: I admit, in some ways I could be wrong! Don't get turned on by words! But everything that you write is more perceived as a dislike for Pascal!I think thats the nature of the post and the context. My posts are about popularity of pascal, which is one of it's weaknesses, so when I talk a lot about it, it of course looks like i'm only bringing up negative points, because there isn't much good things to say about a language being not popular.
google translate: If I need to, I use Pascal. There are no unsolvable problems!
Yes, I admit that this is often a costly and unrewarding "job". If urgency is needed, it is easier to do the work in another language if you have the opportunity.
[...]
My opinion: there are no "best", "worst", "suitable", "not suitable" programming languages! Everything can be solved in one - ANY programming language. You just need to know how to use it in the right path.
I think thats the nature of the post and the context. My posts are about popularity of pascal, which is one of it's weaknesses, so when I talk a lot about it, it of course looks like i'm only bringing up negative points, because there isn't much good things to say about a language being not popular.
But let me ensure you there is plenty I like about Pascal...
...You can solve any problem with any language, thats true, but it doesn't mean that they are all comparable. Some languages will make solving some problems easier than others, in some languages a given action will require a lot of boilerplate code making the code less readable, and at other times simply require more and different code (e.g. for different platforms) that mean more maintenance effort...
...So with these three projects, I could have done in each of them in each of the other languages, but the effort would have been much higher, and the quality of the product (let that be performance or code quality or features) would have suffered greatly.
The second project is an emulator for an old console. Here I chose C++, the reason being that C++ provides a lot of tools to write really optimised code in a very elegant way. For example you can write so called constexpr which are functions (or expressions) that are evaluated during compiletime. Basically it allows you to write compiletime code within the language pretty similar to runtime code.
Take the following code:This function dispatches registers to a logic that is known during compiletime. If you write "cpu.register(Register::A)" this will be simply translated to "cpu.accumulator" with not a single instruction being executed on runtime for this dispatching.
constexpr uint8_t ®ister(Register reg) { if constexpr(reg == Register::A) { return accumulator; } else if constexpr(reg == Register::F) { return *reinterpret_cast<std::uint8_t*>(&statusRegister); } else { return gpRegister[static_cast<int>(reg)]; } }
This means you can put code into functions without any runtime overhead, allowing for more readable code without any performance penalty. The example above allows for example to access every register in the same manner, using the same syntactic construct, which can massively help cleaning up the code. Pascal for example has no method to define functions that are guaranteed to be evaluated on compiletime.
On your first point about the popularity of Pascal... While its not the most popular language, it is more popular than most and has been so for 50 years. I think it's unfair to look down on Pascal for not being in the top 10 (though it's pretty close at #12), but not be disparaging about languages like Go, Julia, Rust, Kotlin, etc... That have never been in the top 10 nor are as popular as Pascal/Object Pascal.I think you are going by the tiobe numbers here, there is a lot of problems with it, which is why I absolutely do not like it. The tiobe index does not measure usage but how often people google "xxx programming". This is a really bad measure for several reasons.
Clearly you are a polyglot programmer (which is great), but it's arguably unfair to expect others to be too. Perhaps Object Pascal is their primary, preferred (most enjoyable), or only language, and they are trying to maximize its use. It might seem inefficient to a polyglot, but is very practical to such programmers. The most efficient language for a given situation, is not necessarily always the best answer. Something else to consider, having to maintain code written in several different languages can also be a cause of problems.Don't get me wrong, I said when I make a new project I evaluate the fiteness of each language according to mostly objective criterias, that doesn't mean that the decision will be objective, it is very, very subjective. For example one of the criteria is how proficient am I with the language in question, which can be measured rather objectively, but is inherently subjective.
Others may select Free Pascal/Lazarus for creating Android applications. Instead of jumping around to C++, C#, JavaScript, etc... A different programmer might want to use DWScript, Pascal Script, Pas2js, Smart Pascal, or PascalABC... Different flavors of Object Pascal/different IDEs that allow use of .NET or transpiling to JavaScript. The effort-benefit analysis that each programmer makes can be quite different.
Lastly, it does seem that sometimes people will bash Pascal for not being or having the same things as their pet languages, which is kind of nonsensical. It's like someone bashing C# for not having the "With statement". But there are ways in that language to get the same result. Upset that Pascal For-Loops don't work exactly like they do in C++, but overlook that they could get nearly the same result if they used Pascal's While-Loop. It's not always the case that another language is better to use, sometimes what is in or possible with a particular language is overlooked. Of course the choice as to how to proceed to accomplish a task/project is an individual one.
J. Gareth Moreton is playing around with concepts in the compiler to introduce such a feature to FPC as well.I know, and I am excited as a kid before christmas about this :)
I think it is more often than not not a bashing as of just finding something that one thinks pascal would benefit from. And then it is always a question of how well it would fit into pascal. For example I would love to see some features of C++ in Pascal, but I don't want to se Pascal becoming C++, because there already is C++ and I don't need another one.
There are a lot of features that I think are really great, and can be incorporated into pascal, this does not mean that I want every feature of these languages...
...Pascal is a living language that is evolving continuously. If I read something like that we don't need new concepts because they can be approximated with old concepts, this sounds to me like you are living in a kind of ivory tower. How do you think we got were we are today? Looking around other languages and trying to incorporate features into pascal is not "bashing", it is pretty much the most important part of keeping a language vital.
I'm definitely not against adding new features into Pascal. We are in agreement that Pascal should be allowed to evolve, but into what is where we should be concerned about. The point that should be emphasized is this evolution be done in a careful and thoughtful manner that fits the design and purpose of Pascal. We should honor and reflect upon what was Niklaus Wirth's original intention and design philosophy.Absolutely not, Niklaus Wirth was finished with Pascal and made two new languages, Modula and Oberon. If I wanted a language that sticked closer to Niklaus Wirths design philosophy, I would choose one of these languages, the latest version of Oberon, Oberon 07 came out just last year and was completely designed by Wirth himself. So why isn't everyone here in this forum using Oberon instead, which is arguably much closer to Wirths original intention and design philosophy of Pascal then current day Pascal is. One of the reasons for this is pretty simple, while Wirth layed a solid foundation, the derivations from his original design is what made the language flurish in the first place. One example is that Wirth believes that a high level language should not have bit operations, thats why the original pascal didn't have any and Oberon-07 from 2020 still doesn't have them. The problem is if you develop software that interfaces with real apis, does DMA with hardware or does low level network communications, you simply need them, and having a 5 line workaround for 1 bitwise or command is simply not a great choice, especially with respect to readability and maintainability.
Absolutely not...
...One example is that Wirth believes that a high level language should not have bit operations, thats why the original pascal didn't have any and Oberon-07 from 2020 still doesn't have them. The problem is if you develop software that interfaces with real apis, does DMA with hardware or does low level network communications, you simply need them, and having a 5 line workaround for 1 bitwise or command is simply not a great choice, especially with respect to readability and maintainability.
Oberon does also not support OOP, there was Oberon2 which supported limited OOP, but was ditched by Wirth in favor of working on Oberon-07. It is continued in a separate project called Component Pascal, which sees moderate success (that is in the small niche that is oberon development), but it is fair to say that OOP is also not part of Wirths design philosophy...
So long story short, a lot of the things that are highly useful and make pascal what it is, are explicitly against Wirths original intend and design philosophy...
“Procedural programming is still the most common paradigm, and it will remain so, because the semantic gap between procedural languages and computers is smaller than for any other paradigm. Instruction sequences are represented by statements, and the state space by variables.The kind of OOP he is talking about is only a fraction of the OOP paradigm as it is employed today. It is much more than "grouping related data into object and the attachment of methods to objects". Key aspects of OOP include generally, but are not limited to:
I consider object-oriented languages also as procedural. They emphasize the grouping of related data into objects, and the attachment of methods to objects. The close relationship between object-oriented and procedural views becomes apparent if we relate the respective terminologies: Basically the terms class, object, and method stand for the classical type, variable, and procedure. Instead of calling a procedure, we now send a message.” -- Wirth
I did not make any claims about what wirth personally thinks about concepts in general, but if or if not they are part of the original intend of pascal. Let's first start about bit operations, because this is simple. Bit operations where part of Algol, a language Wirth had a lot of influence on. In Pascal later, he did not include bit operations, so assuming that he not suddenly forgot that this concept exists, it is fair to assume that it is a conscious design decision to not include them, therefore they are definitely not a part of Wirths original intend for the language.
About OOP it should be noted that Wirth had a pretty narrow view on OOP...
Pascal's broken. We're stuck with it.
and that is also why he didn't introduce novel concepts like bitwise operations.Bitwise operators were not a novel concept, sets, the thing that replaced them in pascal were. Wirth orginally proposed the Set datatype in pascal to replace bit operations, an idea he originally attributes to C.A.R Hoare. Basically to use high level mathematical concepts instead of low level bits.
In the UK, .Exe in the 1990s reprinted an interview with (or paper by) Wirth in which he was scathingly dismissive of OO programming, insisting that there was nothing in it that couldn't be done using records. I'm afraid I don't have a reference or a pointer to the original paper, and don't know whether at the time of the original he was in his "Modula Phase" or had progressed to his "Oberon Phase".Вероятно я бы его поддержал в этом. Я ещё не видел ни одной программы, которая использует ООП и которую нельзя было бы перевести в процедурный вид. Но, зачастую я встречался в этом же ООП, где код был практически идентичен и ни кто даже не собирался это исправлять в ООП. В процедурном программировании я встречался с этим меньше! (вероятно из-за того, что людей программирующих процедурно сейчас на порядок меньше).
Bitwise operators were not a novel concept, sets, the thing that replaced them in pascal were. Wirth orginally proposed the Set datatype in pascal to replace bit operations, an idea he originally attributes to C.A.R Hoare. Basically to use high level mathematical concepts instead of low level bits...
It also appears that ISO 1983, might have messed up Wirth's original implementation of the set type.
Strictly speaking, bitset was just a predefined type. IIRC most compilers simply declared it packed set of 0..31 and characters set of #0..#255, just like Pascal, and manually made the difference.
Strictly speaking, bitset was just a predefined type. IIRC most compilers simply declared it packed set of 0..31 and characters set of #0..#255, just like Pascal, and manually made the difference.
I think the /explicit/ definition that it was represented by a machine word (even if that omitted the size of the word and the numeric representation of the bit ordering) was important. Before that implementations could have claimed that their sets complied with the rather loose standard even if they'd been implemented by linked lists or unpacked arrays... as would have been done by abominations like Lisp and APL which still had noticeable market share.
Yes. I think that matters too for languages that don't standardize pragma's. But the TP-FPC-Delphi block somewhat standardizes those too. (though the set packing ones are not among them, but I think some attempt at standardization would).