Memory Management et al (newbie question)

[Gravitas]

Hello to all!

I am a hobbyist (barring symbolic maths programs) in computing.

In my spare time, I am trying to learn a system's language. My criteria are:
a) fairly small language (cf. syntax)
b) simple and human readable syntax
c) compiled and non garbage collected

I ended up to choose between Nim and (Free)Pascal. So I have two questions:

1. Which is the default memory management model (mmm) in FreePascal? In some places I have read that the mmm follows the manual way, but in other places I have read that the manual way is one of the admissible ones.
Also, which is the relation between mmm and the libraries?
I am asking this question because, e.g., in Nim the default option is ARC (automatic reference counting) and there is the option of none. Yet, it seems that in that case the use of many libraries seems problematic, for they depend on GC.

2. Any thoughts on Nim vs FreePascal?

Of course, any other idea or suggestion(s) would be much appreciate.

Thank you in advance for your time.

[marcov]

Free Pascal uses a ARC for strings and dynamically sized arrays. It doesn't use it for classes/objects.

However, interfaces can be reference counted (for e.g. Windows COM), and that can be used in limited ways for some automated classes work.

I don't use NIM, so can't comment on that.


In the very distant past I did something simple with expression parsing and symbolic math, and it is still distributed as package symbolic in freepascal

[Gravitas]

Perfect!

so, it is partially manual model -if understood it correctly. Is there any way to have full manual mm without breaking libs?

Also, what if someone uses no OO features?


thank you

[marcov]

Perfect!

so, it is partially manual model -if understood it correctly. Is there any way to have full manual mm without breaking libs?

There are static arrays and strings, and you can also manually allocate memory for dynamically sized versions and access them with pointers, roughly like in C. This is also not a black/white decision, sometimes doing as much manual/static as possible is done in high performance code, and not in less speed dependent parts.

I myself work in a performance sensitive environment, and mostly us ARC arrays and strings, and don't got to static. Because they can't nest, there is no cycle breaking necessary, and so the overhead is not really a problem or unpredictable, other than the heapmanager (but that overhead exists in dynamically allocated manual management too). 

In general I learned to profile code for performance, and tackle the bottlenecks in a focussed effort, rather than relying on old dogmas.

Also, what if someone uses no OO features?

Object Pascal is a mixed paradigm language, procedural and OO, much like you can still use nearly everything from C in C++.

[Gravitas]

I see. In general, there much discussion -especially within langs like Zig Odin, Rust. In any case, I would like to have something flexible, and fairly small. Nim, e.g., is very fancy, with a lot of features. I am oriented towards Pascal -without OO- (just procedural and perhaps functional). Something like C replacement (well, modulo the functional part! :-) )...

[marcov]

Define "small". Language definition, executable size, library size, memory footprint, smallest possible system?

Moreover, it might not be language but specific development system, and how you use it. This touches dogma vs practical concerns again. "small' is typically more a dogma than a practical feature.

FPC/Lazarus is vast,  and while not extremely small, usage  with static dialect options will give fairly small standalone binaries.

[Gravitas]

Small in both syntax (as opposed to, e.g., C++) and features. Essentially, I am looking for an alternative to C.
I want, something simple, powerful.

[marcov]

Small in both syntax (as opposed to, e.g., C++) and features. Essentially, I am looking for an alternative to C.
I want, something simple, powerful.

Object Pascal is vast and more a C++ than a C.

[Gravitas]

Oh I see...

Ok, one final (double) question then...
a) is this is the case for pure (i.e., without OO) Pascal?
b) any alternative to propose (not C)?

Thanks for your time and effort!

[marcov]

Ok, one final (double) question then...
a) is this is the case for pure (i.e., without OO) Pascal?

As said that is procedural, much like C.

b) any alternative to propose (not C)?

I like Object Pascal, that's why I'm here.  And as said I'm more used to judging complete tool chains (compiler X for language y on OS z) on how useful for a narrow intended purpose it is, rather than on abstract principles like language size.

So it is hard for me to recommend something else.

[Gravitas]

No, before you said that Object Pascal is vast, like C++...and I asked whether this is true for pure Pascal (without OO) as well :-)

[MarkMLl]

Ok, one final (double) question then...
a) is this is the case for pure (i.e., without OO) Pascal?

Strings, other than shortstrings, are reference-counted. Ditto dynamic arrays plus a couple of other things.

By any stretch of the imagination, they're "pure" Pascal.

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

1. var
2.   s1: string[255]; // Not reference counted
3.   s2: string; // Reference counted.
4.   s3: ansistring; // Reference counted, not Unicode.
5.   a1: array[0..65535] of byte; // Not reference counted.
6.   a2: array of byte; // Reference counted.
7.  

Classes are instantiated onto the heap, and you have to do a manual .Create() and .Free.

Records etc. are generally on the stack, and are subject to the normal rules of scope and visibility.

Records etc. may also be allocated from the heap (1970s-style Pascal programming), whereupon they need to be freed manually.

b) any alternative to propose (not C)?

By and large, Pascal (without overuse of OO) is... pretty good. There's some things I'm unhappy about: overuse of OO when a record or something global would do, sloppy type casting, forced use of the newly-introduced generics facility (which generally only shows up when you get into deep debugging) and so on.

I'm watching Rust with interest, but I'm unhappy about the way in which it moves away from the ALGOL programming model where visibility was determined by scope; a lot of what it's doing was tackled successfully by Pascal/Modula-2/Ada years ago particularly when one looks at Pascal's "var", "const" and "out" parameter qualifiers.

So, I think it's fair to say that if I did "know a better 'ole" I'd go to it.

MarkMLl

[cdbc]

Hi
I had to look up 'Nim'...
If this is the contender, I'd choose FPC (Free Pascal) any day of the week.
So far as I can read, Nim is a 'Hodge Podge' of all the /cool-sounding/ features from ~ 10 completely different languages, just stirred together ...and it compiles to C  - - - No thank you, sir.
Here's a quote from a reviewer, I came across when googling:

- What is bad about Nim?
"Lack of a decent IDE. There are posts on the Nim forum around what people use to develop in Nim but it really is a hodge-podge of solutions. There is no definitive IDE which works seamlessly with Nim and, for a development team to take on Nim, I think there needs to be. Lack of a step-through debugger."

Just my "Nickel's Worth"
Regards Benny

[Gravitas]

Ok, one final (double) question then...
a) is this is the case for pure (i.e., without OO) Pascal?

Strings, other than shortstrings, are reference-counted. Ditto dynamic arrays plus a couple of other things.

By any stretch of the imagination, they're "pure" Pascal.

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

1. var
2.   s1: string[255]; // Not reference counted
3.   s2: string; // Reference counted.
4.   s3: ansistring; // Reference counted, not Unicode.
5.   a1: array[0..65535] of byte; // Not reference counted.
6.   a2: array of byte; // Reference counted.
7.  

Classes are instantiated onto the heap, and you have to do a manual .Create() and .Free.

Records etc. are generally on the stack, and are subject to the normal rules of scope and visibility.

Records etc. may also be allocated from the heap (1970s-style Pascal programming), whereupon they need to be freed manually.

b) any alternative to propose (not C)?

By and large, Pascal (without overuse of OO) is... pretty good. There's some things I'm unhappy about: overuse of OO when a record or something global would do, sloppy type casting, forced use of the newly-introduced generics facility (which generally only shows up when you get into deep debugging) and so on.

I'm watching Rust with interest, but I'm unhappy about the way in which it moves away from the ALGOL programming model where visibility was determined by scope; a lot of what it's doing was tackled successfully by Pascal/Modula-2/Ada years ago particularly when one looks at Pascal's "var", "const" and "out" parameter qualifiers.

So, I think it's fair to say that if I did "know a better 'ole" I'd go to it.

MarkMLl

I see. Well,
1. I put the constraint of memory management for a variety of reasons.
2. I have very very intense dyslexia (and other related stuff). That been said, my first attempt with C, was a complete disaster... Something more readable (thus less trivial error prone) was FreePascal and Nim (that's why I chose them).
But Nim didn't fit the bill (memory management model, and you get overwhelmed by the fetaures -I want the simplicity of C).

But what marcov wrote... change a bit the picture. Another option could be Modula-2 (I think no GC whatsoever). But I was not able to have a separate gnu gcc to work in my distro (which does not pack gm-2).

As a hobbyist I just want simple things in me spare time. In the long run, some simulations with visual stuff in real time (hence, amongst other reasons the MMM).

Thank you.

[MarkMLl]

But what marcov wrote... change a bit the picture. Another option could be Modula-2 (I think no GC whatsoever). But I was not able to have a separate gnu gcc to work in my distro (which does not pack gm-2).

There was a subthread two or three weeks ago related to compiling gm2. Broadly speaking, I think that all of us with experience in the area would agree that while M2 is a better language (no dangling else, tightened up type rules) the fact that it's been barely touched over the last 25 years acts to its disadvantage.

And because it lacks some of the fundamental OO conveniences that one can use without compromising ones principles (in particular stringlists) you *WILL* find that you have to use "classical" heap-based programming (i.e. trees, linked lists and so on) heavily, and that the surviving lore will assume that you are prepared to do so.

MarkMLl