Recent

Author Topic: Contemporary Pascal Discussion  (Read 12641 times)

MarkMLl

  • Hero Member
  • *****
  • Posts: 6647
Re: Contemporary Pascal Discussion
« Reply #60 on: April 16, 2021, 09:38:52 am »
The fpc has a small development team, which has to ration their time, and can't fix every bug.

Which was in part why I suggested in the "Post-Pascal" thread that perhaps the language (not just the compiler) could be usefully refactored so that a larger proportion of bugs could be fixed without having to meddle with the core compiler and make demands of the core team's limited resources.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

Seenkao

  • Hero Member
  • *****
  • Posts: 545
    • New ZenGL.
Re: Contemporary Pascal Discussion
« Reply #61 on: April 16, 2021, 09:52:58 am »
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. :)
Rus: Стремлюсь к созданию минимальных и достаточно быстрых приложений.

Eng: I strive to create applications that are minimal and reasonably fast.
Working on ZenGL

MarkMLl

  • Hero Member
  • *****
  • Posts: 6647
Re: Contemporary Pascal Discussion
« Reply #62 on: April 16, 2021, 10:04:36 am »
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. :)

Exactly: you need to be able to understand the idioms being used by the original programmer, and if necessary to switch to idioms more appropriate for the tools you're using. APL and just about everything else use different idioms, contemporary Pascal and even a fairly closely related language like C use different idioms.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11351
  • FPC developer.
Re: Contemporary Pascal Discussion
« Reply #63 on: April 16, 2021, 10:46:46 am »
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.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6647
Re: Contemporary Pascal Discussion
« Reply #64 on: April 16, 2021, 11:27:18 am »
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". The only real fix for that is to pick and choose and build new libraries, although in principle, a good compiler should be able to inline the nested functions, recognise board-specific constants and optimise the syntax tree.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11351
  • FPC developer.
Re: Contemporary Pascal Discussion
« Reply #65 on: April 16, 2021, 11:43:23 am »
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.

To be clear: It's not so much gcc that I worry about, but binutils-on-windows, as it is a linker feature. But you don't have much choice if you want to use gcc on Windows.

Quote
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".

Well, that is ok on our C/C++ cpu. 10Mhz is easily doable, and might even go as high as 35MHz. (actually we use this to make sure we configured the chip right, as toggling frequency is instruction clock/2 for read/write/modify). But we need to use an intrinsic for that too.

In reality of course you use a hardware peripheral (OC/PWM) for toggling because that is more regular, and frees up CPU.

dseligo

  • Hero Member
  • *****
  • Posts: 1177
Re: Contemporary Pascal Discussion
« Reply #66 on: April 16, 2021, 12:20:12 pm »
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.

Can you give an example of a bug like this one you had mentioned here?

Warfley

  • Hero Member
  • *****
  • Posts: 1499
Re: Contemporary Pascal Discussion
« Reply #67 on: April 16, 2021, 03:37:18 pm »
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

Quote
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.

Quote
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? :)

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.

Quote
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?".

Quote
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.
All the best!
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.

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.

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.
« Last Edit: April 16, 2021, 03:41:46 pm by Warfley »

MarkMLl

  • Hero Member
  • *****
  • Posts: 6647
Re: Contemporary Pascal Discussion
« Reply #68 on: April 16, 2021, 04:29:34 pm »
... 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.

And anybody who tries to argue that since both are Turing Complete they are completely equivalent doesn't know what he's talking about.

I agree: there are some things for which C/C++ are better, and some for which (Object) Pascal is better. And there are many situations where a mix would be better... which was of course the (largely unfulfilled) promise of .NET.

I came across this in the Python documentation/headers:


Py_BEGIN_ALLOW_THREADS

    This macro expands to { PyThreadState *_save; _save = PyEval_SaveThread();.
Note that it contains an opening brace; it must be matched with a following
Py_END_ALLOW_THREADS macro. See above for further discussion of this macro.

Py_END_ALLOW_THREADS

    This macro expands to PyEval_RestoreThread(_save); }. Note that it contains a closing
brace; it must be matched with an earlier Py_BEGIN_ALLOW_THREADS macro. See
above for further discussion of this macro.


Leaving aside for the moment Pascal's lack of a decent macro preprocessor, and leaving aside the potential hazards of allowing semi-skilled users to define block-local variables (I think that one's been argued to death over the last few weeks): you quite simply /can't/ /do/ that sort of thing in Pascal without resorting to a separate TList (using the heap, hence potentially contributing to fragmentation) or whatever, and I can sympathise with users of other block-structured languages who consider themselves skilled and cautious but are aghast at such omissions.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

Seenkao

  • Hero Member
  • *****
  • Posts: 545
    • New ZenGL.
Re: Contemporary Pascal Discussion
« Reply #69 on: April 17, 2021, 12:41:21 am »
Warfley, я признаю, в чём-то я мог быть не прав! Не стоит заводится из-за слов! Но всё что вы пишите - больше воспринимается как неприязнь к Паскалю!

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 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
Quote
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.
Если мне нужно, я использую Паскаль. Нет не решаемых проблем!
Да, я признаю, что зачастую это затратная и не благодарная "работа". Если нужна срочность, то проще сделать работу на другом языке, если у вас есть возможность.

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.

Quote
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% не наберётся.

google translate: On this occasion, one can argue and argue. But Pascal is not the problem! Many projects are born "dead": because they are not thought out; because there was not enough patience; because they just abandoned the project; because they do not see the purpose of the project ... you can go on and on. On the same GitHub, there are more abandoned projects that no one needs. Of these, in Pascal, even 1% will not be typed.

Quote
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.

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.
Я надеюсь вы понимаете, что изучал я не один язык? C/C++ я просто не стал изучать и углубляться, потому что он(они) мне просто не понравился.

Моё мнение: нет ни каких "лучших", "худших", "подходящих", "не подходящих" языков программирования! Всё можно решить и на одном -ЛЮБОМ языке программирования. Надо просто знать как его использовать в нужной стезе.

В данное время я не готов тратить время на переписывание одного кода с одного языка на другой, если меня это не заинтересует! Так же я не готов впустую тратить время, на проект, который изначально будет ни кому не нужен, даже если за него заплатят миллиард и его будут пропихивать везде. Я не буду "засорять" свою совесть подобными проектами.

Если я занимаюсь делом, если оно интересно, если оно принесёт пользу людям - то я готов делать проект. Даже бесплатно! (Это не значит что надо садиться мне на шею, вы просто ни чего не получите от меня).

В первую очередь, то, чем я занимаюсь, должно быть интересно мне. Если мне это интересно - я это развиваю. Есть возможность? - Делюсь!

Пригодилось? - Хорошо!

Не пригодилось... - ну чтож... бывает... от этого ни куда не уйдёшь. Буду пользоваться только я.

google translate: I hope you understand that I studied more than one language? I just didn’t study C / C ++ and deepen it, because I simply didn’t like it (they).

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.

At this time, I'm not ready to waste time rewriting one code from one language to another, if I am not interested in it! Also, I am not ready to waste time on a project that will not be needed by anyone from the beginning, even if a billion is paid for it and it will be pushed everywhere. I will not "litter" my conscience with such projects.

If I am engaged in a business, if it is interesting, if it will benefit people, then I am ready to do a project. Even free! (This does not mean that you have to sit on my neck, you just won't get anything from me).

First of all, what I do should be interesting to me. If it's interesting to me, I develop it. I have an opportunity? - I share!

Was it useful? - Okay!

It didn't come in handy ... - well, well ... it happens ... you can't get away from this. I will only use it.
Rus: Стремлюсь к созданию минимальных и достаточно быстрых приложений.

Eng: I strive to create applications that are minimal and reasonably fast.
Working on ZenGL

Warfley

  • Hero Member
  • *****
  • Posts: 1499
Re: Contemporary Pascal Discussion
« Reply #70 on: April 17, 2021, 03:50:07 am »
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.

But let me ensure you there is plenty I like about Pascal, to name some of my favorite things, nested functions are pretty much one of the best tools I've seen in a language to organise code. I really like the structure of pascal in general, and that there are no scoped variables (I think that an opt-in scoping mechanism like pythons with statement could be neat, but thats another topic). The unit structure is absolutely great, making using the FPC very comfortable for any scope of project, you don't need to make overcomplicated buildsystems like you have to for C and C++, and you are not forced in a rigid package structure like Java or C#. You can start of with a small project and let it naturally grow, without having a heavy structuring effort thats either frontloaded or backloaded being a huge timesink. It has a great mix of high and low level features, which allows you to simultaniously have a very abstract/model based code utilizing the whole aspects of OOP, while in other parts going down bare metal, without either feeling cumbersome. And not to mention that I have yet to find another solution for GUI development across all classic desktop systems thats as easy to use as Lazarus with the LCL, from a simple 1 file calculator to my big 10 kloc IDE I've wrote a few years back Lazarus just makes it really easy.

I could go on

Quote
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.

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 maintainance effort.

The simpelest example I can give you is this, I've created the program gdiff, which simply shows me the diff of a single commit in git. I chose to use bash script for it, the script is:
Code: Bash  [Select][+][-]
  1. #!/bin/bash
  2. COMMIT=${1-HEAD}
  3. git diff $COMMIT~1 $COMMIT
I could have written it in Pascal:
Code: Pascal  [Select][+][-]
  1. program gdiff;
  2. {$Mode ObjFPC}{$H+}
  3.  
  4. uses SysUtils;
  5.  
  6. var
  7.   commit: String;
  8. begin
  9.   if ParamCount < 1 then
  10.     commit := 'HEAD'
  11.   else
  12.     commit := ParamStr(1);
  13.   ExitCode := ExecuteProcess('git', [commit+'~1', commit]);
  14. end;

The bash solution is defenetly the better one here. It was much less effort to create, is concise but still conveys all the information you need with a single glance, and can be directly incorporated into the git ecosystem (which already requires a bash to be present), without the need to be compiled.

Now this is of course the most obvious example, it compares a script language that is made just to call other programs with a general purpose language. So me give you three projects, real, rather big programs I have worked on in the past and explain what languages I used and why I chose them over other, similar languages.
First one is a data visualization software. So I had a software that produced gigabytes of raw outputs in different formats, a lot of statistics and some text information as well as meta information about the run. The goal was to visualize multiple aspects of the data, compare to different runs of the same program, etc. It started out really small, I've started with a simple table program that would load the data into a table and make it searchable and so on. I wrote this in Lazarus because you can basically start lazarus and start creating a simple GUI and the very simple logic. When I was done I thought about another feature, a plotting program, that would take the data and plot it in multiple different ways. Again I decided to use Lazarus, create a new project, copy some of the code from the original and was done really quickly.
I then got a few other ideas for new features, also the table view and plot should be linked together, so I just took these seperate projects, made the forms to frames, put the common code into a seperate datastructure and created an overarching program that simply loaded these frames as "tools" into different parent objects. So I could easiely develop each tool individually, even in it's own project, as the frames where shared between projects and simply use the large program in the end to combine all the features.

Here Lazarus was by far the best solution I could have picked. It started out really small as just a small idea, but has evolved into one of the biggest projects I had worked on at the time. Because of the huge amount of data, performance was a key issue, which is not a problem with ObjectPascal and the FPC, also reading binary data is really easy using TStreams and Records. I could also reuse components I have written for previous programs (especially the plotting frame was custom created by me and the codebase is something I am using now for more then a decade).
I could have had the performance and ease of reading binary data with for example C++, but there creating the GUI and the overall project structure would have meant like tenfold the effort it did for pascal. I could have used Javascript and make it a webapp, which allows for similar ease of managing different views and creating complex GUIs, but working on binary data in javascript is a real pain in the neck and the performance of JS in the computationally expensive algorithms for preparing the data might have resulted in massive loading times (It already was like 30seconds per imported project with heaviely optimized native code). An other alternative might have been C#, but this would have bound me to windows and Linux support was key, and I don't even know if .Net would have been fast enough (if the GC starts during a computationally heavy algorithm, it can slow it down massively)
Any other solution I can think of would have meant more work for probably a worse result.


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:
Code: C  [Select][+][-]
  1.   constexpr uint8_t &register(Register reg) {
  2.     if constexpr(reg == Register::A) {
  3.       return accumulator;
  4.     } else if constexpr(reg == Register::F) {
  5.         return *reinterpret_cast<std::uint8_t*>(&statusRegister);
  6.     } else {
  7.       return gpRegister[static_cast<int>(reg)];
  8.     }
  9.   }
  10.  
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.
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.
Another thing is the power of templates in C++, they are like generics, just more powerful (turing complete infact). You can for exmple use them to implement a shallow form of inheritance using the CRTP pattern, allowing to have most features of inheritance but also restricting the virtual depth (i.e. the length of virtual function call chains) to 1. Basically you get many of the advantages of inheritance, without the runtime penalty of inheritance.
Long story short, C++ allows for some very interesting ways to write high performance code with high level concepts that usually, in languages like Pascal, are only reserved to runtime functionality and has therefore a runtime penalty to it.
So to get back to my project, as the nature of an emulator, especially one that should function well platforms with low computational power, performance is a key issue, unlike the first example, not only for key algorithms, but across the whole code base. So while in the example above I could use Pascal for both,  as it is usally very clean when writing high level code, and the low level code was only a few algorithms, where "I could get my hands dirty", in this project I needed to archive peak performance in every aspect,  and here C++ simply makes it much easier because it applys high level concepts at a compile time level, something pascal simply can not provide.


The last project is a chat, which uses encryption. I chose javascript (well technically typescript but I consider them both to be the same). One key was the requirement for a crypto library that is up to date and well tested. I already talked about the issues with crypto libraries earlier, so I won't rehash it here. Javascript has access to the browser crypto functionality, meaning the cryptolibrary is Firefox or Chromium itself, some of the arguably most well tested pieces of software available, and always providing state of the art security, you probably can't get better then this. Next is that this chat must run on mobile, I wouldn't care if it won't run on Desktop, but mobile is a must have. I am not going to pay for any of the cross platform solutions (like Xamarin or Firemonkey) so if I don't want to create two seperate apps (one for android and one for iOS), there is pretty much not an alternative. Even native development is much more tedious for android then web technology, so even disregarding cross compatibility, I would probably have chosen javascript over like Java.
I could have chosen Pascal with Lazarus here, there is the ability to write native android and iOS apps, but these apps need to be developed seperately (where as one webapp can target both platforms with the same code) while also being much more effort to implement. I could have used Lazarus with Pas2JS to generate the Javascript code, or C++ with emscripten, but this results often in even more effort, not only setting up the toolchains, but also using non web languages in the web environment, which has it's own structures and paradigms, feels very forced and often requires a lot of boilerplate code. Javascript is basically nothing but Dicts, Arrays and atomic datatypes, with everything being dynamic, which makes using it with a static language like Pascal or C++ feel very out of place.


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.
« Last Edit: April 17, 2021, 03:53:05 am by Warfley »

Blade

  • Full Member
  • ***
  • Posts: 177
Re: Contemporary Pascal Discussion
« Reply #71 on: April 17, 2021, 06:20:55 am »
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.

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.

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.

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.

PascalDragon

  • Hero Member
  • *****
  • Posts: 5444
  • Compiler Developer
Re: Contemporary Pascal Discussion
« Reply #72 on: April 17, 2021, 11:14:54 am »
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:
Code: C  [Select][+][-]
  1.   constexpr uint8_t &register(Register reg) {
  2.     if constexpr(reg == Register::A) {
  3.       return accumulator;
  4.     } else if constexpr(reg == Register::F) {
  5.         return *reinterpret_cast<std::uint8_t*>(&statusRegister);
  6.     } else {
  7.       return gpRegister[static_cast<int>(reg)];
  8.     }
  9.   }
  10.  
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.
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.

J. Gareth Moreton is playing around with concepts in the compiler to introduce such a feature to FPC as well.

Warfley

  • Hero Member
  • *****
  • Posts: 1499
Re: Contemporary Pascal Discussion
« Reply #73 on: April 17, 2021, 05:46:16 pm »
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.
First, I think that the volume of google searches for a particular language is highly correlated with the usage of that language, but the syntax is way to restricted by tiobe. When programming I regularly look things up, in most languages about similarly much, but I don't google things like "C++ programming std::set" or "ObjectPascal programming TProcess" I would simply google "c++ std::set" or "lazarus TProcess", both of which will not be counted by tiobe. You usually only google "xxx programming" when you don't know anything and are just seeking out the most basic description (like wikipedia). It can even be argued that it favors less popular and/or more forgettable languages, as people that already know about a language will not google for such superficial information.
Personally I can even attest to this, I have used quite a lot of Javascript in the past, but over the past 5 years I never googled "javascript programming", but you know what I have googled? "Modula programming language", "Algol programming language", "Fortran programming language" and many other languages, I was curious about due to their historic influences, but never wrote a single line of code with them. So according to the tiobe index, I am a Modula, Algol and Fortran programmer, but not a JavaScript programmer. Seems odd, doesn't it?

Then there is the problem with aliases, to which this community is no stranger, how often do people say stuff like "lazarus programming" instead of "ObjectPascal programming. So while not being well suited for measuring popularity in general, it even has a lot more issues with ObjectPascal specifically.

Overall I must say that the tiobe index is just unfit to judge a languages popularity, which is why I usually look at actual usage statistics. One example for this is what I have mentioned earlier in this thread is the Github user statistics. When looking at all of the over 100 million github open source repositories, pascal does not make it into the top 50. Go is on place 9, Rust and Kotlin make it to 14 and 15 and Julia on place 35, as of the first quater of 2021. Of course this is biased to open source projects.
There are also a lot of online surveys out there, made using popular survey providers, one of which for example was posted on statista: Link where Pascal also didn't make it into the top 25. And of course such online surveys have a lot of porblems, you have a selection bias, as a lot of people (like me) do not enter such surveys, people can answer multiple times if they please, also more generally, people are not always truthful and so on.

But besides each of these methods having their fair share of issues, they at least attempt to measure the usage of languages directly, while the tiobe index doesn't. The tiobe index uses a proxy in the form of very specific search queries that is arguably not a well suited measure of popularity, at most it is a measure of how many people seek superficial information of a language.

As I said, I like pascal, but it is most certainly not popular. And I think thats a shame, I think it should be in the top 50 of github, it should be at least in the top 25 on such online surveys. Sure it does not need to be spot number 1, but if the place 12 as of the tiobe index would at least be close in any of the other metrices, I think this whole thread wouldn't exist.

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.

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.
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.
For example I know that go is really great for concurrent processes, e.g. server development. But I don't know anything about Go, so if the choice would be between Pascal and Go I would most certainly not choose Go. Also recently I made a project together with a friend who is real beginner in programming and started with javascript. The project in question would be much better suited with pascal in my oppinion, but he is simply not at a level of programming knowledge to transfer his javascript knowledge to another new language, which is why I chose javascript.

What is right for you is always a very important factor. So when I say I chose the language that I recon is best suited for the project, this does not mean simply technical, but also incorporate my personal preferences, knowledge level, etc. Also not to forget simply old code, I am programming in ObjectPascal now since I was 12ish, I have a lot of old pascal code laying around, which I often find other usages for. This is one of the great features of Lazarus (which we inherited from Delphi), that the language is so stable that a custom Listbox component with additional graphics and more features I developed like 10 years ago still works like a charm in modern applications. So all these factors are of course relevant for the choosing of a language, even though they are very subjective to me personally.

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.

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. For example I really like the concept of explicetly nullable pointer as you have in TypeScript or kotlin, that does not mean that I want to have a fully dynamic type system like typescript, so while I think it would be a great addition to pascal, it would need to be implemented in a pascallian way.

But this is one thing I like so much about programming languages (well also spoken languages, but I don't want to nerd about linguistics here) that features that have proven well in other languages can get assimilated in your own language thereby having the language continuously evolve. In regards to pascal, there are a lot of things that were incorporated that made the language better. OOP, Bit operations, Operator overloading, generics, enumerators, advanced records, etc. are all features that were incorporated into pascal from different languages. Every single one of these features could have been approximated using native pascal features, but they were incorporated anyway, because they are great additions. The "for ... in ... do" loop was not native to pascal, but I wouldn't want to miss it. Same for OOP, sure you can use common prefix records with pointer to do the same, but OOP makes it much easier (I actually rebuild inheritance for records completely using generics and pointers for advanced records, and let me tell you, this is something you don't want to do).

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.

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 :)
« Last Edit: April 18, 2021, 01:57:32 am by Warfley »

Blade

  • Full Member
  • ***
  • Posts: 177
Re: Contemporary Pascal Discussion
« Reply #74 on: April 19, 2021, 10:25:51 am »
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.

Arguably, a disaster/monster has been created, when the language is no longer well-structured, begins losing readability and maintainability, and/or poorly thought out concepts are forced which are difficult for users to grasp and use.  There is a danger in pushing the creation of overly convoluted and complex code that is part of a fad, quick buck, or an unnecessary attempt to impress others or stroke one's ego.  There is nothing wrong with simplicity, which has its own kind of beauty and sustainability.

"Genius is making complex ideas simple, not making simple ideas complex" -- Einstein
« Last Edit: April 19, 2021, 10:27:35 am by Blade »

 

TinyPortal © 2005-2018