PureBasic: the Quiet Survivor

[mk-soft]

Many languages take more distance from OOP. With PB you can program rudimentary with OOP (what I have proven)

[skywalk]

OOP is not entirely green.
With generative AI, the necessity for computer language abundance drops to C/C++, ASM, VERILOG, SQL, html, JavaScript, git, shell.
Helper languages like Basic, Python, Fortran, Rust, Go, etc, are niceties that will be absorbed by cumulative AI.

[MicroStream]

What it is APL ?

Annoyingly Pretty Language

However, it is a very old language, heavily based on mathematical models, and not exactly easy to learn.
In some ways, it's a nightmare.

[threedslider]

However, it is a very old language, heavily based on mathematical models, and not exactly easy to learn.
In some ways, it's a nightmare.

It remind me as Haskell, something mathematical and syntax very weird

[MicroStream]

OOP is not entirely green.
With generative AI, the necessity for computer language abundance drops to C/C++, ASM, VERILOG, SQL, html, JavaScript, git, shell.
Helper languages like Basic, Python, Fortran, Rust, Go, etc., are necessities that will be absorbed by cumulative AI.

Here I strongly disagree! Fundamentally, the programmer should retain absolute control over the code, especially when dealing with a high-level programming language. While assembler offers ultimate control over the code, this does not spare the programmer from dealing with the necessary routines in a project. Code optimisation, whether in assembly language or a higher-level programming language, is in any case an indispensable discipline that should never be left to external automation through generic logic. Although testing the individual program sections with various benchmark tests is time-consuming, it ultimately pays off through optimal runtimes. Fortunately, some compilers are now so well designed that at least a limited form of optimised code is already done in advance.

Unfortunately, all of this is often questioned for economic reasons, since labour costs money. In the business world, speed is all too often prioritised over quality. The result is always an immature product that requires endless improvements.

[syntonica]

Since Purebasic will never be an object oriented language and because it costs money, it will never be a best option for modern projects, and even less for OpenSource projects. Also the syntax is very clunky and there could be more syntactic sugar in some areas.
But still: I like the way Purebasic is going.

For me, OOP is just another tool in the toolbox. If I need an object, I need an object. It's not a religion, as you see with many users of Java or C++ with Objects. I believe PB already is OOP. Module + AllocateStructure gives you more than you need, except the syntactic sugar of the dot. With method calls in OOP languages, the receiver is passed implicitly. Here, you have to do it explicitly. It's certainly easier than doing it in C, which lacks namespacing after how many years?

I agree the syntax is odd and quirky. I'm sure it's all historical reasons. The operators are overloaded: + can mean add, concatenate, or add and assign (+= in Clangs). But. In contrast, we get EndIf, EndProcedure, EndModule, &c. instead of just End. Shrug. I'm coming from bloaty, wordy Java and sleek, cryptic C++ to sleek, wordy PureBasic.

[mk-soft]

It's good that PureBasic can also handle OOP. Same effort as in 'C'.
Otherwise you could not realize something like Windows ActiveScript or integrate other COM objects.

[MicroStream]

I agree the syntax is odd and quirky. I'm sure it's all historical reasons. The operators are overloaded: + can mean add, concatenate, or add and assign (+= in Clangs). But in contrast, we get EndIf, EndProcedure, EndModule, &c. instead of just End. I'm coming from bloaty, wordy Java and cryptic C++ to sleek, wordy PureBasic.

I believe there are now enough programming languages ​​that support object-oriented programming alongside various other paradigms. Whether PureBasic actively supports OOP or not is currently more of a philosophical question. If it's already possible, at least to some extent, then that would certainly be another plus.

And as for C/C++, there is much more to say about its history, but I will get to that later. Its strongest feature, which is undeniably present, is its enormous functionality, but that's about it. The syntax results in widely scattered code, which impairs its readability and makes maintenance extremely difficult. In its defence, one often hears the same old arguments such as: "C/C++ is a multi-level language!" Yes, sure, but that doesn't change the fact that the language is anything but modern and, due to its weaknesses, a clear departure from it is already noticeable, especially among newer languages.

Let's look at some interesting examples, such as Erlang and its little brother Elixir, or Ruby and its little brother Crystal. This is beautiful, easily readable, and cleanly structured modern code! As you can see, the family is growing and soon there will be little sisters too.

[NicTheQuick]

For me, OOP is just another tool in the toolbox. If I need an object, I need an object. It's not a religion, as you see with many users of Java or C++ with Objects. I believe PB already is OOP. Module + AllocateStructure gives you more than you need, except the syntactic sugar of the dot. With method calls in OOP languages, the receiver is passed implicitly. Here, you have to do it explicitly.

OOP is a lot more than just that. In most of my projects, I need class inheritance, method overriding, private and protected values. These are all things that are difficult to solve with procedural programming.
With OOP, it is also impossible to apply a method to the wrong object because the appropriate methods are linked to the object class. This is a great help in avoiding errors, especially in a non-strictly typed language such as Purebasic.
With OOP, you never need to know that much about a specific object; it is usually enough to know whether it implements a certain interface. For example, a drawable object has the method draw(), and that is all you need to know. It does not matter whether what is being drawn is a circle, a square, or a polygon. You don't have to build a select-case construct that calls the correct procedure depending on the object type.
If you think procedural is all you need, you might never tried to use OOP properly.

[syntonica]

OOP is a lot more than just that. In most of my projects, I need class inheritance, method overriding, private and protected values. These are all things that are difficult to solve with procedural programming.

Oh,I agree, for the most part. I love my simple top-down inheritance, Interfaces and Mixins. I'm a lone programmer, so I don't worry much about public/private, and I think I've overridden one method in 15 years of Java. (Stupid Swing...)

I'm complainig about the zealots who write wrapper classes for wrapper classes and have 5 identical methods wrapping the same thing all the way up the inheritance chain. When I study that code, it takes an hour to find something that actually does any work. Drives me crazy when I need to see how/why something is broken.

Like I said, it's a tool, and often a very useful one that solves otherwise complex problems. But if one of these programmers ever saw one of my Utilities classes full of static, procedural methids, their heads would explode.

[threedslider]

Let's look at some interesting examples, such as Erlang and its little brother Elixir, or Ruby and its little brother Crystal. This is beautiful, easily readable, and cleanly structured modern code! As you can see, the family is growing and soon there will be little sisters too.

Those languages are nice but i didn't know for Crystal, thanks for sharing with this link

Do you have heard for ZenC : https://github.com/z-libs/Zen-C ? It is pure C but more modern and less error prone