Lazarus

Miscellaneous => Other => Topic started by: stuey on April 06, 2018, 01:16:11 am

Title: Why Pascal?
Post by: stuey on April 06, 2018, 01:16:11 am
Sometimes when I talk about my interest in Pascal (and I still know next to nothing about it, having only read Tao Yue's tutorial for super-n00bs) I get some pushback about why I'm not learning a hipper language like Ruby or Python.

I don't really have a good answer to that... I think possibly the main reason I care about Pascal is because we had a TI 99/4A when I was a kid, and once you had graduated from its built-in TI BASIC and have thereafter mastered Exended BASIC (if you were lucky like I was to score EB from your parents), the next step up would have been UCSD Pascal; which, alas, I never did score.

Also about eight years ago I was trying to get into Macintosh programming for the classic OS (I had a PowerBook G3 with OS 9.2.2 and managed to install MPW; I wanted to use it for C programming (yes I know Classic Mac OS is not an ideal C-programming platform!) and something in the doco said "uses Pascal-style function calls" which left me thinking, oh, great, now I have to learn Pascal on top of it all).

Those weird little things combined with the mere fact that Pascal was a major, well-known programming language for such a long time, even though it's (reportedly) not the wave of the future, keep Pascal on my road map.

What's Pascal to you?
Title: Re: Why Pascal?
Post by: Phil on April 06, 2018, 01:29:46 am
What's Pascal to you?

For me, Pascal is a good way to create dynamic (shared) libraries for use on multiple platforms and with many other languages. There are not too many other languages that can do this. Typically dynamic libraries are written with C++ or C. You would not use Python or Lua (or C# or VB.NET or Java) to write a dynamic library. Maybe Swift would be in this elite group (Pascal, C++, C) someday, but not yet.

Where Pascal is not very useful is for creating the frontend to software on modern platforms (Web, mobile, macOS). In those cases it makes more sense to use languages that match up better with the target platform.

It doesn't sound like you're a programmer, so some of what I've said may not make much sense.

What are you looking at now? macOS? I would guess it might have been more than 8 years ago that you were looking at doing classic Mac app. OS X was released in 2001, I believe - that's 17 years ago when Classic started to be phased out.
Title: Re: Why Pascal?
Post by: ccrause on April 06, 2018, 10:22:55 am
What's Pascal to you?
In my opinion Pascal is just another programming language from a wide spectrum, with machine instructions and assembly at one extreme and Siri/Google Assistant at the other extreme.  One can construct endless arguments and comparisons between different languages to pick the "best" language.

In my case using Pascal is purely a personal preference. I learned Pascal at school (after playing with BASIC and LOGO) hence I express most of my logic straight in Pascal.  I also learned to use C when I played with Arduino & AVR controllers, but it is a constant struggle for me to translate ideas from Pascal syntax to C syntax.  In the end I can program any logic I can think of in either C or Pascal.  I am reasonably sure that if I learned C first, I would probably prefer that to Pascal.  I also did some minor work in PHP and FORTRAN, but that was because of external factors (mainly availability of specific functionality).  Note that I am not a professional programmer.

I like the Freepascal compiler because:
Title: Re: Why Pascal?
Post by: RayoGlauco on April 06, 2018, 01:11:09 pm
I liked Delphi a lot, but its price was not affordable for my pocket. Then I discovered Lazarus. I think Pascal is a good language for a clear and good programming, because it was created initially for educational purposes. When I was in college, learning computer science, I saw several "dirty C programming" contests (the goal was to make a totally unintelligible C program that could do some interesting task), but no "Dirty Pascal programming" contests.
Title: Re: Why Pascal?
Post by: Leledumbo on April 06, 2018, 01:54:47 pm
What's Pascal to you?
My weapon of choice when I'm not forced to use anything else specifically. One of a few language I can't have excuse like "it's compiling / building / packing / whatevershitthatmanymainstreamlanguageshave" because compilation is damn fast that compile-debug cycle has no need for interpreter (Hi, Haskell!) and release is practically a few seconds difference as opposed to minutes or hours (Long time no see, ReactJS! You again, Haskell!). All of those without any loss of performance or crazy memory hog, even deployment to server is a single static binary (not really, but at least the dependencies are usually against system level libraries, not application ones). No claim for single command installation (that does a bunch of downloading, installing, configuring, etc. that takes too long so we can go for a cup of coffee or tea and it's still not yet finished when we return) needed, because installation is not even required.
Title: Re: Why Pascal?
Post by: Paul_ on April 06, 2018, 02:05:54 pm
Because I'm not so smart to program in C++ :)
Title: Re: Why Pascal?
Post by: Lulu on April 06, 2018, 02:17:06 pm
Because I have learn Pascal in 1990, at school, and I love this language ! It is very clear to read by an human.
I've discover Lazarus 6/7 years ago, and I also discover the world of Class ! ( only procedural in 1990 )
Thanks for the Lazarus team !
Title: Re: Why Pascal?
Post by: benohb on April 06, 2018, 02:44:47 pm

The subject is very deep
.
Part of the language itself
Part about FPC and lazarus  team
Another part about Linux and multi - platform


By the way, this cheetah never got tired
https://www.freepascal.org/pic/logo.gif
Title: Re: Why Pascal?
Post by: Noodly on April 06, 2018, 02:51:26 pm
I've always loved Pascal and have been - many years ago - a professional developer using Turbo Pascal and then Delphi. After moving into managerial roles I used Delphi and later Lazarus to write personal utility programs or even the odd small production program when the developers were too busy.

I can't think of anything you could do in C/C++ that you couldn't do in Pascal. As has been mentioned, the UI in mobile platforms is where Lazarus is weak (kudos to LAMW for pushing the boundaries), but it was never intended to be anything more than a multi-platform Delphi alternative.

Overall it's fun to program with Lazarus and the community is very supportive.
Title: Re: Why Pascal?
Post by: lainz on April 06, 2018, 03:55:42 pm
I discovered it thanks to Inno Setup, it mentioned "Pascal Script", so then I googled it to know a bit more. Then I'm here =)
Title: Re: Why Pascal?
Post by: Bart on April 06, 2018, 07:38:07 pm
As a med student I followed an introduction course on programming in MUMPS, which was great fun.
I didn't have a PC then (hardly anyone had, they were expensive), so only later I took up programming again.
At the time I was unemployed and bored. A friend gave me a copy of Turbo Pascal 3.0 and a book on structural programming. The manual that came with TP was in Hebrew, so not helpfull at all to me.

I started to learn how to program, and I really loved the fact that Pascal in itself is a structured language (ever tried MUMPS??).
The compiler was lightning fast as well.

Later in an attempt to learn a "mature language", I tried C.
That horrified me.
I could not and still cannot get my head around it.

If you can read English, and you have some basic knowledge of logic, then you can understand a basic Pascal program, even if you never programmed in your life.
With C, I get lost after the first 2, max 3 lines of code.

So, I fell in love with Pascal long time ago, I had a fling with C and flead back.

From all this you can see I'm an amateur, and always wil be.
A pro would be able to learn C and more languages, and then choose the language that most suited the job at hand.

For what I want to do, Pascal can do what I need.
And it does that cross-platform.
To me, it's just a matter of taste.

Bart
Title: Re: Why Pascal?
Post by: Ñuño_Martínez on April 10, 2018, 12:57:38 pm
For me, the best high-level compiled language.  Period.

Because I'm not so smart to program in C++ :)
I was a C++ programmer but when I discovered Delphi I decided don't use C++ again in my life.  But I still like C though. ::)
Title: Re: Why Pascal?
Post by: mischi on April 10, 2018, 01:16:18 pm
I can easily use lazarus for a cross-platform user interface and then Pascal to call existing C or even Fortran routines. Try that with C :-). I knew Pascal at the time, when i got interested in Object Oriented Programming. In order to study this, i did not have to learn another language at the same time. Lazarus and Pascal may not be ideal, but gives me the best compromise. The best choice to understand my own code years later.

MiSchi.
Title: Re: Why Pascal?
Post by: marcov on April 11, 2018, 07:41:02 pm
What's Pascal to you?

While I favor the syntax a bit more than C syntax, the main motivation is the development experience as a whole. So language+libraries+tools. I particularly like the fact it can be used for easy to deploy basic win32/64 binaries.
Title: Re: Why Pascal?
Post by: Zvoni on April 12, 2018, 11:10:16 am
Coming from an 18-years-in-classic-visual-basic-background (no Pro though), FPC/Lazarus was the combination that appealed to me the most in terms of platform-independency/license-policy
As already mentioned: Looking at C/C++-Code i go crosseyed after 3-4 lines of code :-)

But as i stand here now, it's still a challenge to get through the differences between Freepascal and classic Visual Basic (e.g. no pointers or "real" inheritance in classic Visual Basic).

Oh, and i agree: TP3 rocked my World in 1988 when finishing High School in Germany
Title: Re: Why Pascal?
Post by: tverweij on April 12, 2018, 11:55:50 am
- structured
- strict
- readable
- case insensitive
- full pointer support
- full OOP (although multiple inheritance is missing)

Title: Re: Why Pascal?
Post by: Thaddy on April 12, 2018, 12:57:13 pm
And a very strict separation of declaration and implementation throughout the language, which makes it not only easier to read but also less prone to errors than C like languages that allow e.g. variable declarations within a code block... even on the fly.... which is silly although it "saves time"..<think!  >:D >.
A variable declaration is much more readable and strict because of that separation. It prevents errors although it may seem more verbose. Same goes for types. Same goes for clumsy enumerations in other languages. Same goes for - native - sets.

Btw: multiple inheritance is supported through interfaces...
There are more languages with these strict features. Almost all of them are Wirthian languages which includes imo also ADA. Although COBOL has many of the same features I mentioned.
Title: Re: Why Pascal?
Post by: segfault on April 15, 2018, 08:27:19 pm
Same goes for - native - sets.

I think this is a much under-utilised and under-appreciated feature of the language. Well thought out use of sets can simplify many programs enormously and also makes them easier to read. I know you can implement them using bit vectors in pretty much any language, but how often would you actually do it? Having them native is a big plus.
Title: Re: Why Pascal?
Post by: fcu on April 15, 2018, 10:18:24 pm
variable declarations within a code block... even on the fly.... which is silly although it "saves time"..<think!  >:D >.

i find it very useful , better than scrolling every time to var region !
Title: Re: Why Pascal?
Post by: metis on April 23, 2018, 04:25:48 pm
@fcu

Quote
better than scrolling every time to var region !
Relax Your Forefinger, and jump instead:
Jump to the Var with <Alt+Up>, then jump back with <Ctrl+H>.  ;)


@All the others
I love Lazarus and FPC.  :-*
It installs fast and w/o Problems (at least with me: WinXP SP3).
It is so easy to use, compiles and runs fast, and is full with useful Features, ...

Question:
Afaik, the first MacOs's had been written with Pascal.
-> Does anybody know, why, and why Pascal was left ?

Title: Re: Why Pascal?
Post by: Phil on April 23, 2018, 04:30:05 pm

Afaik, the first MacOs's had been written with Pascal.
-> Does anybody know, why, and why Pascal was left ?

https://en.wikipedia.org/wiki/Object_Pascal#Early_history_at_Apple
Title: Re: Why Pascal?
Post by: RAW on April 23, 2018, 08:50:52 pm
Quote
@All the others
I love Lazarus and FPC.  :-*
It installs fast and w/o Problems (at least with me: WinXP SP3).
It is so easy to use, compiles and runs fast, and is full with useful Features, ...

YES !!!! DEFINITELY !!!!

I really like the SECONDARY INSTALLATION...  :)
Title: Re: Why Pascal?
Post by: metis on April 27, 2018, 03:08:52 pm
@Phil

Referring to that article:
"Apple dropped support for Object Pascal when they moved from Motorola 68K chips to IBM's PowerPC
 architecture in 1994. MacApp 3.0, for this platform, was re-written in C++."

-> So far, so good, but why did they have to change the programming language,
     only because of changing the processor. Did Pascal not support it ?
     (Sorry for these questions, but I'm only a Hobby-Programmer).
Title: Re: Why Pascal?
Post by: Zoran on April 27, 2018, 03:26:07 pm
And a very strict separation of declaration and implementation throughout the language, which makes it not only easier to read but also less prone to errors than C like languages that allow e.g. variable declarations within a code block... even on the fly....

Ah, THE one argument I strongly disagree with.

I believe that declaring variable only in the block where it belongs is what actually makes code not only less prone to errors, but also easier to read.
"Don't declare variable outside of exact block they belong to" is what I really miss in Pascal.

.... which is silly although it "saves time"..<think!  >:D >.

And it is not about saving time.
Title: Re: Why Pascal?
Post by: Phil on April 27, 2018, 03:44:05 pm
-> So far, so good, but why did they have to change the programming language,
     only because of changing the processor. Did Pascal not support it ?

I don't know, but I'm sure you can research that and find out. That was before my time as a Mac user.

Apple has switched primary language several times. When they acquired NeXT and the OS / frameworks that would eventually become OS X and the Cocoa framework, they switched to Objective C. Then about four years ago they switched to their own homegrown Swift for all the Darwin platforms (macOS, iOS, tvOS, watchOS) as well as Linux.

Now Google has forked Swift for use with TensorFlow. Pretty impressive growth for barely 4 years in.

https://www.tensorflow.org/community/swift
Title: Re: Why Pascal?
Post by: Leledumbo on April 28, 2018, 10:36:42 pm
I believe that declaring variable only in the block where it belongs is what actually makes code not only less prone to errors, but also easier to read.
"Don't declare variable outside of exact block they belong to" is what I really miss in Pascal.
Quite the contrary, my experience with block level declaration makes my code buggier than the Pascal strict single declaration style. This is mainly due to the variable shadowing where you might unintentionally shadow the outer variable having the same name and type as the inner one and accidentally misrefer, either in outer or inner block. Not that often happen, but when it does, it really sucks to debug.
Title: Re: Why Pascal?
Post by: ASerge on April 29, 2018, 10:12:14 am
I believe that declaring variable only in the block where it belongs is what actually makes code not only less prone to errors, but also easier to read.
"Don't declare variable outside of exact block they belong to" is what I really miss in Pascal.
Quite the contrary, my experience with block level declaration makes my code buggier than the Pascal strict single declaration style. This is mainly due to the variable shadowing where you might unintentionally shadow the outer variable having the same name and type as the inner one and accidentally misrefer, either in outer or inner block. Not that often happen, but when it does, it really sucks to debug.
Agreed. I prefer to do more complex logic in several blocks with nested functions. First, it is so easy in pascal. Second, a named block of code is very easy to understand and reduces the complexity of the code. And if you think about efficiency, "inline" will remove this issue.
Title: Re: Why Pascal?
Post by: Thaddy on April 29, 2018, 10:29:27 am
Indeed, but separation of even local declaration and implementation is by itself enough reason why I like Pascal over languages that allow inlined - as in within a implementation codeblock - variable declaration in code. That's a hell for debugging and also for team programming: you may have overlooked what another team member was doing. In Pascal you can examine the declaration block without having to search for any offending declaration with the implementation itself. And that is by design.  And IMO a very strong feature, since even properly written C(++) code will try to avoid that feature for the same reason.
If you run into the need for such a variable you should look at a local function or procedure to handle it while in scope and indeed compiler inlining will do a good job in most such cases.
Title: Re: Why Pascal?
Post by: Zoran on April 29, 2018, 04:47:11 pm
Okay, but to be complete I should also say that, while block scope in C++ (*) is a plus for me, lacking "routine nested in routine" Pascal feature is much bigger minus for C++. So, when comparing these two features, Pascal wins.

(*)
I prefer to write "C++" here, not "C-like languages", just because I think that among C, C++, Java, C#, C++ is the first to be compared with Object Pascal (object oriented, compiles to native code).
Title: Re: Why Pascal?
Post by: Thaddy on April 30, 2018, 09:06:44 am
It is a bit more complex than that since  Objective C is also a candidate here and - one year - older than C++. The "feature" that started this is C syntax. C++, objective C and Object Pascal can all be used in a procedural way too. They are supersets of course. To me the biggest disadvantage of C++ are its long compile times even if it leads to - not even always - very efficient code generation.
Title: Re: Why Pascal?
Post by: kupferstecher on April 30, 2018, 03:30:49 pm
"routine nested in routine" Pascal feature
I quite hate that feature. The function name gets pulled away from its code. Besides I don't see why the feature would be needed, just reduces a bit typing.
Anyways, I don't use it so in the end I'm fine with it.
Title: Re: Why Pascal?
Post by: Zoran on April 30, 2018, 06:37:29 pm
Besides I don't see why the feature would be needed, just reduces a bit typing.

Reduces typing? No. It is not that trivial (and, by the way, it does not reduce typing -- you still have to write the whole function, don't you?).

When you need some functionality inside a function, you can implement it only there, by creating nested function, whose scope is within the function it is nested in, so not polluting outer scope.

This is far from trivial, as reducing typing would be, this gives one more possibility to avoid polluting the outer level scope -- a strong contribution to cleaner code.
Title: Re: Why Pascal?
Post by: marcov on April 30, 2018, 07:24:09 pm
I quite hate that feature. The function name gets pulled away from its code. Besides I don't see why the feature would be needed, just reduces a bit typing.

Nested procedure can take parameters, so that is more than just typing.

I like them a lot. The IDE keeps the procedure signatures (multiple, if nested) in the top lines even to assist.
Title: Re: Why Pascal?
Post by: Handoko on April 30, 2018, 07:50:21 pm
When you need some functionality inside a function, you can implement it only there, by creating nested function, whose scope is within the function it is nested in, so not polluting outer scope.
+1

I rarely use nested procedure/function, but it is a feature I like very much. Using it properly it really makes the code more readable and maintainable. It's has been discussed here:
http://forum.lazarus.freepascal.org/index.php/topic,38536.msg262013.html#msg262013
Title: Re: Why Pascal?
Post by: Pascal on April 30, 2018, 08:42:57 pm
When you need some functionality inside a function, you can implement it only there, by creating nested function, whose scope is within the function it is nested in, so not polluting outer scope.
+1

It helps deduplicating code and making complex routines more readable by splitting code into meaningfull nested routines.
Title: Re: Why Pascal?
Post by: Leledumbo on May 01, 2018, 06:07:18 pm
I quite hate that feature. The function name gets pulled away from its code. Besides I don't see why the feature would be needed, just reduces a bit typing.
Anyways, I don't use it so in the end I'm fine with it.
Quite the contrary, you can name the nested subroutines very well according to their specific task inside the outer routine. And no, it doesn't reduce typing, it adds instead. But for the much more increased readibility and potentially prevent duplication, the more typing pays.

This is a rather extreme example (you don't do this often), but imagine how will this be written without the nested subroutines:
Code: Pascal  [Select][+][-]
  1. function Tokenize: TTokenList;
  2. var
  3.   StartLine,StartCol: LongWord;
  4.   Kind: TTokenKind;
  5.   Lexeme,ContextBasePath: String;
  6.   Look: Char;
  7.   TempState: TLexerState;
  8.  
  9.   procedure InitFields;
  10.   begin
  11.     StartLine := Line;
  12.     StartCol := Col;
  13.     Lexeme := EmptyStr;
  14.   end;
  15.  
  16.   procedure HandleText;
  17.   begin
  18.     case Look of
  19.       '{': begin
  20.         LexerState := lsPossiblyTagStart;
  21.       end;
  22.       else begin
  23.         Lexeme := Lexeme + Look;
  24.       end;
  25.     end;
  26.     Look := ReadChar;
  27.   end;
  28.  
  29.   procedure HandlePossiblyTagStart;
  30.   begin
  31.     case Look of
  32.       '{': begin
  33.         if Lexeme <> EmptyStr then begin
  34.           AddToken(StartLine,StartCol,Kind,Lexeme,ContextBasePath,Result);
  35.           InitFields;
  36.         end;
  37.         LexerState := lsTagStart;
  38.       end;
  39.       else begin
  40.         Lexeme := Lexeme + '{' + Look;
  41.         LexerState := lsText;
  42.       end;
  43.     end;
  44.     Look := ReadChar;
  45.   end;
  46.  
  47.   procedure HandleTagStart;
  48.   begin
  49.     case Look of
  50.       '{': begin
  51.         LexerState := lsUnescapedVariable;
  52.         Kind := tkUnescapedVariable;
  53.       end;
  54.       '&': begin
  55.         LexerState := lsUnescapedVariableAmp;
  56.         Kind := tkUnescapedVariable;
  57.       end;
  58.       '#': begin
  59.         LexerState := lsOpenSection;
  60.         Kind := tkOpenSection;
  61.       end;
  62.       '/': begin
  63.         LexerState := lsCloseSection;
  64.         Kind := tkCloseSection;
  65.       end;
  66.       'a'..'z','A'..'Z','_',' ': begin
  67.         LexerState := lsEscapedVariable;
  68.         Kind := tkEscapedVariable;
  69.         Lexeme := Look;
  70.       end;
  71.       else begin
  72.         raise ETokenize.Create('Invalid tag char: ' + Look);
  73.       end;
  74.     end;
  75.     Look := ReadChar;
  76.   end;
  77.  
  78.   procedure HandlePossiblyTagEnd;
  79.   var
  80.     p: SizeInt;
  81.   begin
  82.     case Look of
  83.       '}': begin
  84.         Lexeme := Trim(Lexeme);
  85.         case TempState of
  86.           lsOpenSection: ContextBasePath := ContextBasePath + Lexeme + '.';
  87.           lsCloseSection: begin
  88.             if ContextBasePath = EmptyStr then
  89.               raise Exception.Create('Closing unopened section: ' + Lexeme)
  90.             else begin
  91.               p := RPos('.',ContextBasePath);
  92.               Delete(ContextBasePath,p,Length(ContextBasePath) - p);
  93.             end;
  94.           end;
  95.         end;
  96.         AddToken(StartLine,StartCol,Kind,Lexeme,ContextBasePath,Result);
  97.         InitFields;
  98.         LexerState := lsTagEnd;
  99.       end;
  100.       else begin
  101.         Lexeme := Lexeme + '}' + Look;
  102.         LexerState := TempState;
  103.       end;
  104.     end;
  105.     Look := ReadChar;
  106.   end;
  107.  
  108.   procedure HandleTagEnd;
  109.   begin
  110.     LexerState := lsText;
  111.     Kind := tkText;
  112.   end;
  113.  
  114.   procedure HandleVariable;
  115.   begin
  116.     case Look of
  117.       '}': begin
  118.         TempState := LexerState;
  119.         if LexerState = lsEscapedVariable then
  120.           LexerState := lsPossiblyTagEnd
  121.         else
  122.           LexerState := lsPossiblyUnescapedVariableEnd;
  123.       end;
  124.       'a'..'z','A'..'Z','0'..'9','_',' ','.': begin
  125.         Lexeme := Lexeme + Look;
  126.       end;
  127.       else begin
  128.         raise ETokenize.Create('Invalid tag char: ' + Look);
  129.       end;
  130.     end;
  131.     Look := ReadChar;
  132.   end;
  133.  
  134.   procedure HandlePossiblyUnescapedVariableEnd;
  135.   begin
  136.     case Look of
  137.       '}': begin
  138.         LexerState := lsPossiblyTagEnd;
  139.       end;
  140.       else begin
  141.         raise ETokenize.Create('Invalid tag char: ' + Look);
  142.       end;
  143.     end;
  144.     Look := ReadChar;
  145.   end;
  146.  
  147.   procedure HandleUnescapedVariableAmp;
  148.   begin
  149.     case Look of
  150.       '}': begin
  151.         TempState := LexerState;
  152.         LexerState := lsPossiblyTagEnd;
  153.       end;
  154.       'a'..'z','A'..'Z','0'..'9','_',' ','.': begin
  155.         Lexeme := Lexeme + Look;
  156.       end;
  157.       else begin
  158.         raise ETokenize.Create('Invalid tag char: ' + Look);
  159.       end;
  160.     end;
  161.     Look := ReadChar;
  162.   end;
  163.  
  164.   procedure HandleSection;
  165.   begin
  166.     case Look of
  167.       '}': begin
  168.         TempState := LexerState;
  169.         LexerState := lsPossiblyTagEnd;
  170.       end;
  171.       'a'..'z','A'..'Z','0'..'9','_',' ','.': begin
  172.         Lexeme := Lexeme + Look;
  173.       end;
  174.       else begin
  175.         raise ETokenize.Create('Invalid tag char: ' + Look);
  176.       end;
  177.     end;
  178.     Look := ReadChar;
  179.   end;
  180.  
  181. begin
  182.   Initialize(Result);
  183.   LexerState := lsText;
  184.  
  185.   InitFields;
  186.   ContextBasePath := EmptyStr;
  187.   Look := ReadChar;
  188.   Kind := tkText;
  189.   while Look <> EOFChar do begin
  190.     case LexerState of
  191.       lsText                        : HandleText;
  192.       lsPossiblyTagStart            : HandlePossiblyTagStart;
  193.       lsTagStart                    : HandleTagStart;
  194.       lsPossiblyTagEnd              : HandlePossiblyTagEnd;
  195.       lsTagEnd                      : HandleTagEnd;
  196.       lsEscapedVariable,
  197.       lsUnescapedVariable           : HandleVariable;
  198.       lsPossiblyUnescapedVariableEnd: HandlePossiblyUnescapedVariableEnd;
  199.       lsUnescapedVariableAmp        : HandleUnescapedVariableAmp;
  200.       lsOpenSection,lsCloseSection  : HandleSection;
  201.     end;
  202.   end;
  203.   if Lexeme <> EmptyStr then begin
  204.     AddToken(StartLine,StartCol,Kind,Lexeme,ContextBasePath,Result);
  205.   end;
  206. end;
  207.  
The inner subroutines depend on local variables of the outer subroutine, so without nested subroutine feature, you will need to duplicate that for ALL of them. It's not just unnecessarily tedious, but can easily fail when you forget to mark one (or two or three or more) as var (every inner subroutine will both read and write those variables). Otherwise, you can just copy their bodies into the case statement, but... are you sure you really want to give up readability that much?
Title: Re: Why Pascal?
Post by: Thaddy on May 01, 2018, 06:29:50 pm
@leledumbo:
I agree with you but consider this:
Unindent all...... :D After all, white space is actually ignored by most languages except Python.... :(  It is up to the - not only Pascal! - programmer to respect it and make sense of it.
Code: Pascal  [Select][+][-]
  1. {$macro on} {$define labas:='hello,'}{$define pasauli:='world'}program dosomethingsilly;begin;writeln(labas, pasauli);end.
Btw: that's Lithuanian. My wife is...

Point I am trying to make that this feature relies on programmer discipline. It is not a language feature of Pascal to make things understandable. It is a language feature to make things readable (after all) O:-) Not everybody has the gift of logic. Not even programmers. :'( :o :(
Title: Re: Why Pascal?
Post by: kupferstecher on May 01, 2018, 11:02:26 pm
Nested procedure can take parameters, so that is more than just typing.
I wasn't aware of that so I didn't see the point of nested functions. Already convinced!

(From a code-readability point of view I'd prefere the nested functions to be placed below the "outer" function.)
Title: Re: Why Pascal?
Post by: HeavyUser on May 01, 2018, 11:15:21 pm
(From a code-readability point of view I'd prefere the nested functions to be placed below the "outer" function.)
that is impossible in all known languages, all procedures/functions must be declared and compiled before they are used so above is the only appropriate place.
Title: Re: Why Pascal?
Post by: Ñuño_Martínez on May 02, 2018, 01:39:30 pm
About nested procedures/functions:  C allows them.  Or they allowed in ANSI, not sure if C-99 and after allowed (I'm sure old GCC compilers do and some other don't, as Microsoft).  They work(ed) in a very similar way than Pascal ones.  I'm not sure if the actual language definitions allows them (I read somewere it is impossible to build a BNF depiction of C), and AFAIK it is not "standard".  I used them only once (in an old version of Allegro.pas, when an extra DLL was needed) and somebody asked because he can't compile it (Microsoft compiler).
Title: Re: Why Pascal?
Post by: marcov on May 02, 2018, 03:26:08 pm
Afaik originally it was a gcc extension (maybe meanwhile standarized), but is syntax only. Afaik gcc doesn't implement children touching the parent variables or parameters.

Without that, it is fairly superficial
Title: Re: Why Pascal?
Post by: Leledumbo on May 02, 2018, 04:27:51 pm
Nope, it's not (yet?) standardized in C, not in C99, not even in C11. It remains a GCC specific extension as Clang also doesn't implement it.
Title: Re: Why Pascal?
Post by: Ñuño_Martínez on May 02, 2018, 05:44:23 pm
Afaik originally it was a gcc extension (maybe meanwhile standarized), but is syntax only. Afaik gcc doesn't implement children touching the parent variables or parameters.
May be not now, but it did allow to use parent variables and parameters.  I can't find the code right now (I've found it wasn't in the old Allegro.pas code %)) but I did it and it worked.

Anyway, as you said, it isn't standard so it is not a good idea to do it.  As I've said somebody said it didn't compiled in his system.
Title: Re: Why Pascal?
Post by: metis on May 08, 2018, 12:56:23 pm
@Zoran
Quote
"Don't declare variable outside of exact block they belong to" is what I really miss in Pascal.
How would You declare global Vars then ?

@All the others
What I really miss in Pascal, is the Possibility to declare static Vars within a Routine. :(

Maybe this is a good Opportunity to turn the Discussion to...
What is missing in Pascal ?
What can not be done with Pascal without "big Detours" ?

 :)
Title: Re: Why Pascal?
Post by: Handoko on May 08, 2018, 01:01:33 pm
What I really miss in Pascal, is the Possibility to declare static Vars within a Routine. :(

Did you mean local typed constants?

It should be stressed that typed constants are automatically initialized at program start. This is also true for local typed constants and initialized variables. Local typed constants are also initialized at program start. If their value was changed during previous invocations of the function, they will retain their changed value, i.e. they are not initialized each time the function is invoked.

Source: https://freepascal.org/docs-html/ref/refse10.html
Title: Re: Why Pascal?
Post by: metis on May 08, 2018, 01:10:45 pm
@Handoko

No, I mean Vars, that are declared in a Routine and keep their Value until the next Call. 

 :)
Title: Re: Why Pascal?
Post by: Handoko on May 08, 2018, 01:16:36 pm
Have you read the link? Typed constant is not the constant that you thought.


Contrary to ordinary constants, a value can be assigned to them at run-time.

Source: https://freepascal.org/docs-html/ref/refse10.html
Title: Re: Why Pascal?
Post by: Pascal on May 08, 2018, 01:16:48 pm
@Handoko

No, I mean Vars, that are declared in a Routine and keep their Value until the next Call. 

 :)

That's what he meant! It's possible:

Code: Pascal  [Select][+][-]
  1. procedure xyz;
  2. const
  3.   lLock: boolean = False;
  4. begin
  5.   if lLock then exit;
  6.   lLock := True;
  7.   try
  8.     ...
  9.   finally
  10.     lLock := False;
  11.   end;
  12. end;
Title: Re: Why Pascal?
Post by: Thaddy on May 08, 2018, 01:45:25 pm
Indeed, the most use for a typed const is to maintain state over function calls, it behaves like a persistent (global) var, not a local var but is hidden from global access..
This is a slightly more revealing example that I have given before:
Code: Pascal  [Select][+][-]
  1. program untitled;
  2. {$ifdef fpc}{$mode delphi}{$H+}{$J+}{$endif}
  3. function MaintainStateOverCall:integer;
  4. const x:integer = 0;
  5. begin
  6.   Result := x;
  7.   inc(x);
  8. end;
  9.  
  10. var i:integer;
  11. begin
  12.   for i := 0 to 9 do
  13.    writeln(MaintainStateOverCall);
  14. end.
It is a very powerful tool once you know how to use it.
The alternative is writing a class, but this feature is much older and a precursor to Object Pascal.
Title: Re: Why Pascal?
Post by: Pascal on May 08, 2018, 01:52:00 pm
This is a slightly more revealing example

Sure!  :D
Title: Re: Why Pascal?
Post by: Thaddy on May 08, 2018, 02:03:53 pm
Sure!  :D
Note you need to have {$writeableconst on} or the equivalent {$J+} for this to work.
Title: Re: Why Pascal?
Post by: Handoko on May 08, 2018, 02:08:27 pm
It works on {$mode objfpc} too. Every times I start a new project using Lazarus, I get {$mode objfpc} and I can use typed constant without problem.
Title: Re: Why Pascal?
Post by: Kays on May 08, 2018, 02:21:08 pm
Indeed, the most use for a typed const is to maintain state over function calls, it behaves like a persistent (global) var, not a local var but is hidden from global access.. […]
The alternative is writing a class, but this feature is much older and a precursor to Object Pascal.
Or a unit where the var is allocated in the implementation section.

[…] {$writeableconst on} […]
One of the worst compiler switches, ever (besides {$COperators on}). I mean constants, hence their name are supposed to remain constant, i.e. you can't assign any value to them.
Title: Re: Why Pascal?
Post by: Thaddy on May 08, 2018, 02:21:29 pm
That would actually be a bug. Same goes for mode delphi. In delphi it should be off by default. Oh, minor issue.
Title: Re: Why Pascal?
Post by: Thaddy on May 08, 2018, 02:26:59 pm
One of the worst compiler switches, ever (besides {$COperators on}). I mean constants, hence their name are supposed to remain constant, i.e. you can't assign any value to them.
No it is not: it is a constant over calls, not a traditional constant without type (which many people will probably also do not understand: how to determine the type of a constant....).
Actually this is THE compiler feature (internally) that allowed OOP in pascal. And sometime later lead to Object Pascal and subsequently Delphi and FreePascal.
And the difference is actually quite well explained in the manuals.
Being able to hide from global scope is a feature that allows classes and objects.

That was a really silly remark, Kai. You can do much better.
Title: Re: Why Pascal?
Post by: Zoran on May 08, 2018, 03:16:50 pm
However, the syntax is quite unfortunate. I never understood why are these declared with const keyword.
Perhaps we should call these global variables with local scope (although accessible from local scope only, they are allocated in global memory region).

Of course, as we know what we are doing, there is nothing wrong with using this feature.
Title: Re: Why Pascal?
Post by: Thaddy on May 08, 2018, 03:29:52 pm
However, the syntax is quite unfortunate. I never understood why are these declared with const keyword.
Perhaps we should call these global variables with local scope (although accessible from local scope only, they are allocated in global memory region).

Of course, as we know what we are doing, there is nothing wrong with using this feature.
I somewhat agree with you, but note typed consts are typed. So although const necessarily  has a different meaning it is quite natural.
I would worry more about open array parameters vs dynamic array parameters. Now that's a clash that is hard to understand for most.
Title: Re: Why Pascal?
Post by: Zoran on May 08, 2018, 04:43:01 pm
but note typed consts are typed. So although const necessarily  has a different meaning it is quite natural.

Typed? Natural? What makes it typed?
Seriously, why do we call these typed?
A true const also have its type. Only you don't always have to type its type. :D
Is that what makes it not typed?

Not to mention that you can declare true constant's type explicitly, as well:
Code: Pascal  [Select][+][-]
  1. const
  2.   N = Int64(123); // a true const
  3.  

Title: Re: Why Pascal?
Post by: Zoran on May 08, 2018, 04:46:24 pm
@Zoran
Quote
"Don't declare variable outside of exact block they belong to" is what I really miss in Pascal.
How would You declare global Vars then ?


Are you serious?

I'd do it this way:
Code: Pascal  [Select][+][-]
  1. var
  2.   N: Integer;
  3.  
Title: Re: Why Pascal?
Post by: lainz on May 08, 2018, 06:54:13 pm
@Zoran
Quote
"Don't declare variable outside of exact block they belong to" is what I really miss in Pascal.
How would You declare global Vars then ?


Are you serious?

I'd do it this way:
Code: Pascal  [Select][+][-]
  1. var
  2.   N: Integer;
  3.  

He means in each scope. With your code you are creating a variable for all function scope, that doesn't means is the local scope, for example a 'for scope' or an 'if scope', in other languages variables are local to the if or local to the for.

Code: Pascal  [Select][+][-]
  1. function
  2. begin // function scope
  3.  
  4. for ... do
  5. begin // for scope
  6.  
  7. if ... then
  8. begin // if scope
  9.  
  10. end // if scope
  11.  
  12. end // for scope
  13.  
  14. end // function scope
Title: Re: Why Pascal?
Post by: Thaddy on May 08, 2018, 09:37:05 pm
but note typed consts are typed. So although const necessarily  has a different meaning it is quite natural.
Typed? Natural? What makes it typed?
Not to mention that you can declare true constant's type explicitly, as well:
Code: Pascal  [Select][+][-]
  1. const
  2.   N = Int64(123); // a true const
  3.  
That is a constraint, not a type. A const is typeless, usually platform dependent as well. Only its value is guaranteed.
A const is evaluated by the compiler and can be substituted by a fixed value without storage. A typed const has an actual storage allocation.
Basics.... >:( >:( <means beyond grumpy! :'(>
Title: Re: Why Pascal?
Post by: ASBzone on May 09, 2018, 03:55:58 am
Way back when, I wanted to be a programmer...

I learned BASIC on a TRS-80, then on other home computers from TANDY, then on the C-64.
I also learned Assembler on the C-64.

In 1986, I ran into Pascal on a DEC PDP-11/44 at college -- it was awesome.
I started looking for Pascal everywhere.

Back on the PC, I got into BASIC again, and into dabbled briefly in Assembler again.  I did QuickBasic and AmigaBASIC (my favorite BASIC interpreter).
I dabbled in VisualBasic, but was not too impressed.

I started working as a hardware guy, not a software guy, and my career took off.    I still programmed, sporadically, as a hobby...   I loved TurboPascal.

Delphi came out, and I was in awe.  Loved it, loved it, loved it.

I also started learning C and C++.  Meh.   Nice languages, but nothing like Pascal for me (totally subjective sentiment).

Back in 2011, I found the need to write some utilities for systems management purposes, and after playing around with Visual C++, I came across FPC and Lazarus, and felt right at home.

It works for me.

If I had never run into Pascal, I would probably have gone on to master C++ and later C#, since I spend most of my time on Windows systems these days.

For me, Pascal just happened to suit my personality, and has been quite capable of doing all that I have needed.  (These days, I am mostly writing console utilities, but I have some additional software plans ahead.
Title: Re: Why Pascal?
Post by: ASBzone on May 09, 2018, 03:58:32 am
And a very strict separation of declaration and implementation throughout the language, which makes it not only easier to read but also less prone to errors than C like languages that allow e.g. variable declarations within a code block... even on the fly.... which is silly although it "saves time"..<think!  >:D >.

I was *just* having that discussion with my teenage son yesterday, as he was lamenting the structure of Pascal, in favor of the *flexibility* of Python.
Title: Re: Why Pascal?
Post by: engkin on May 09, 2018, 04:49:27 am
Since this thread is in a forum for "Pascal" it will be more like glorifying Pascal as a programming language.

I also started learning C and C++.  Meh.   Nice languages, but nothing like Pascal for me (totally subjective sentiment).
Thank you for being objective here.

I would like to remind Pascal lovers of the following cryptic list of local and global compiler directives:
Code: Pascal  [Select][+][-]
  1. {$A}
  2. {$B}
  3. {$C}
  4. {$D}
  5. {$E}
  6. {$F}
  7. {$G}
  8. {$H}
  9. {$I}
  10. {$J}
  11. {$L}
  12. {$M}
  13. {$N}
  14. {$O}
  15. {$Q}
  16. {$R}
  17. {$S}
  18. {$T}
  19. {$V}
  20. {$W}
  21. {$X}
  22. {$Y}
  23. {$Z}
  24.  

You should not use any of them, if you really care about your code being easy to read, you know. If you see a member using {$H+} in their code and claims Pascal is easy to read, ask them to use {$LONGSTRINGS ON} instead, just to be consistent. You can't hate count++ and use {$H+}.

{$WRITEABLECONST} is just another funny Pascal readability issue. I don't know what it does to prevent errors/mistakes, but it almost proves that this is a missing part in the language itself, replaced with an abuse of a compiler directive.

Code: Pascal  [Select][+][-]
  1. {$push}{$J+}
  2. ...
  3. {$pop}
Title: Re: Why Pascal?
Post by: Thaddy on May 09, 2018, 05:48:12 am
Compiler directives are not necessarily part of the Pascal language. Strictly speaking they aren't.
But cryptic syntax is always possible:
Code: Pascal  [Select][+][-]
  1. begin write(^M^J^G);end.
Now, how many of you remember what that does.?
Title: Re: Why Pascal?
Post by: engkin on May 09, 2018, 06:35:10 am
Compiler directives are not necessarily part of the Pascal language. Strictly speaking they aren't.
Yes, sure. They are not part of the language. Still practically the language can not be used without them.  :(

But cryptic syntax is always possible:
Code: Pascal  [Select][+][-]
  1. begin write(^M^J^G);end.
Now, how many of you remember what that does.?
Equivalent to #13#10#7.

Quote
the caret character (^) can be used in combination with a letter to specify a character with ASCII value less than 27. Thus ^G equals #7 - G is the seventh letter in the alphabet. The compiler is rather sloppy about the characters it allows after the caret, but in general one should assume only letters.
Title: Re: Why Pascal?
Post by: Thaddy on May 09, 2018, 06:48:42 am
Equivalent to #13#10#7.
Equivalent to mechanical typewriter (return + bell).
There's a difference, though. Technically the ^M syntax is - the only - true Pascal escape syntax whereas #13 syntax is simply byte representation of a char misused for escaping. (yes, I know, it has the same result but semantically that is the case  :D)
Title: Re: Why Pascal?
Post by: metis on May 11, 2018, 12:05:44 pm
@Handoko
Quote
Have you read the link? Typed constant is not the constant that you thought.
Yes, it is (sorry).
I only have Internet-Access at my work place, where I cannot read all Posts, that came in the Meantime and then answer accordingly.
So, I simply didn't see the Citation written in green and the Link below.

@Handoko + Pascal + Thaddy
Though I use typed Contants quite often, I never did within Routines.
From now on, I will - Thanks for Your Hints.


@Zoran
Quote
However, the syntax is quite unfortunate.
In my Opinion, as well, it's quite misleading to name something a "Constant", that is variable,
even if it can be seen as "constant over calls" as Thaddy mentioned. (I also fell into that "Trap".) %)
Quote
Perhaps we should call these global variables with local scope
Or simply "static variables".
Quote
I'd do it this way:
It depends on how You define an "exact block" - I wouldn't call a Unit or the Program itself an "exact block".

@lainz
Quote
He means in each scope. With your code you are creating a variable for all function scope, ...
I actually meant in each scope in the Sense of being available anytime and anywhere in the Program.
You pointed out another Issue.

 :)
Title: Re: Why Pascal?
Post by: howardpc on May 11, 2018, 01:20:41 pm
@Zoran
Quote
However, the syntax is quite unfortunate.
In my Opinion, as well, it's quite misleading to name something a "Constant", that is variable,
even if it can be seen as "constant over calls" as Thaddy mentioned. (I also fell into that "Trap".) %)
Quote
Perhaps we should call these global variables with local scope
Or simply "static variables".

AFAIK the "typed constant" description is nomenclature inherited from TP / early-Delphi times, we can't blame the FPC developers for that.
Personally I prefer to call them "initialised variables". It is one of many areas where a multiplicity of overlapping terms is not particularly helpful, and probably confusing to newcomers. However, we cannot undo our history, or insist that others use some preferred or standard name.
They used to be stored always in the data segment, not as part of the heap. Where does the compiler keep them these days?
Title: Re: Why Pascal?
Post by: Zoran on May 11, 2018, 01:32:02 pm
AFAIK the "typed constant" description is nomenclature inherited from TP / early-Delphi times, we can't blame the FPC developers for that.

Yes, the unfortunate naming is Borland's fault.

Personally I prefer to call them "initialised variables".

But now whe have initialized variables which behave differently from typed consts, see: https://www.freepascal.org/docs-html/current/ref/refse24.html (https://www.freepascal.org/docs-html/current/ref/refse24.html)

Unlike typed constants, local initialized varibles are initialized on each routine call (so, I guess they are on the stack, and typed constants are in global memory area).
So, I wouldn't call typed constants "initialized variables", as "initialized variables" are something else.

By the way, we can also notice that global initialized variables and global typed constants (with {$J+}) actually do behave quite same, they are probably implemented same in compiler.
Title: Re: Why Pascal?
Post by: metis on May 11, 2018, 02:29:01 pm
@howardpc
Quote
we can't blame the FPC developers for that.
I didn't want to blame the FPC-Developers, but everything can be improved.
 :)
Title: Re: Why Pascal?
Post by: Thaddy on May 11, 2018, 04:41:00 pm
AFAIK the "typed constant" description is nomenclature inherited from TP / early-Delphi times, we can't blame the FPC developers for that.

Yes, the unfortunate naming is Borland's fault.
No it is is not. Typed constants are not even unique to Pascal.
To mention a few: several COBOL dialects, ADA and C++.
For somebody that actually read the theory it is perfectly valid and logical naming. Typed vs Literal should be enough to understand it..
https://en.wikipedia.org/wiki/Constant_(computer_programming)
Title: Re: Why Pascal?
Post by: marcov on May 11, 2018, 04:44:40 pm
Having true structured consts is important in embedded applications where it is backed by flash or placed in a non writable code segment rather than data.
Title: Re: Why Pascal?
Post by: Zoran on May 11, 2018, 05:04:14 pm
AFAIK the "typed constant" description is nomenclature inherited from TP / early-Delphi times, we can't blame the FPC developers for that.

Yes, the unfortunate naming is Borland's fault.
No it is is not. Typed constants are not even unique to Pascal.
To mention a few: several COBOL dialects, ADA and C++.
For somebody that actually read the theory it is perfectly valid and logical naming. Typed vs Literal should be enough to understand it..
https://en.wikipedia.org/wiki/Constant_(computer_programming)

No. I have no idea about ADA and COBOL, but the constants in C++ are constant, being typed is completely irrelevant, when declared as const, once initialized, they are not writeable.
Title: Re: Why Pascal?
Post by: Thaddy on May 11, 2018, 05:24:07 pm
In C++ - depending on compiler settings - it is possible to change the value of a named constant within its scope. That is basically the same as Pascal.
The big difference between const and named/typed const is memory allocation. Named consts and typed consts have an address....
Title: Re: Why Pascal?
Post by: snorkel on May 11, 2018, 05:53:17 pm
This is going to make me look super old, but I learned pascal back in college circa 1992, the University I went to had the core programming courses in pascal and then you took electives for other languages like C++
I used VB for awhile and it sucked and then Delphi came on the scene around 1995 and I immediately dropped VB like it was molten lava hahah.
The best part is on windows you can still to this day make single file exes that just work, no stupid java or .net runtimes etc needed.

I then dabbled with Lazarus and when it hit 1.0 in 2012 I ported everything I had to Lazarus and FPC and have not used Delphi since.

The big corporations are consumed with web development even though it is the most insecure way to develop, I hate web development as it can be hacked in a heartbeat even if your careful and implement a CRSF token system etc.
Title: Re: Why Pascal?
Post by: Zoran on May 11, 2018, 06:06:26 pm
In C++ - depending on compiler settings - it is possible to change the value of a named constant within its scope. That is basically the same as Pascal.
The big difference between const and named/typed const is memory allocation. Named consts and typed consts have an address....

You keep stressing the implementation detail (where and how these are stored internally), which is rarely important to the programmer.

Yes, it is nice to know, but much more important for the programmer is to keep distinction between what can vary (a variable) and what is constant throughout its life within its scope (a constant).
The much cleaner syntax would be to use the keyword var for what can vary, and reserve the const keyword for what cannot. This is a high level language after all.
Title: Re: Why Pascal?
Post by: Thaddy on May 11, 2018, 08:55:00 pm
Zoran you miss the point for typed consts. It is actually a low-level construct that pre-dates Object Pascal and makes maintaining state - like fields of a class - between function.procedure calls possible.
It is NOT a var!
Code: Pascal  [Select][+][-]
  1. {{$WRITEABLECONST ON}
  2. function countme:integer;
  3. const i:integer = 0;
  4. begin;
  5.   inc(i);
  6.   Result := i;
  7. end;
  8. var k:integer;
  9. begin
  10.   for k:= 0 to 9 do
  11.     writeln(countme);
  12. end.
It is const in the sense that it is const, not writable, outside of the scope where it is declared. A var is reset every call.
Nothing new, nothing to do with Pascal as such. It is quite a common concept in computer science, not only compiler design, but e.g. also functional design.
There is already sufficient difference between a typed const and an untyped - really an inferred const which size is usually determined based on the CPU register size! - const. And even if writableconst is selected, it still is a memory location and NOT free for the compiler to substitute with a immediate constant value. Although optimization may choose otherwise when appropiate.. The latter is real implementation detail....
Title: Re: Why Pascal?
Post by: Zoran on May 11, 2018, 10:29:08 pm
Zoran you miss the point for typed consts. It is actually a low-level construct that pre-dates Object Pascal and makes maintaining state - like fields of a class - between function.procedure calls possible.
It is NOT a var!
Code: Pascal  [Select][+][-]
  1. {{$WRITEABLECONST ON}
  2. function countme:integer;
  3. const i:integer = 0;
  4. begin;
  5.   inc(i);
  6.   Result := i;
  7. end;
  8. var k:integer;
  9. begin
  10.   for k:= 0 to 9 do
  11.     writeln(countme);
  12. end.
It is const in the sense that it is const, not writable, outside of the scope where it is declared. A var is reset every call.
Nothing new, nothing to do with Pascal as such. It is quite a common concept in computer science, not only compiler design, but e.g. also functional design.
There is already sufficient difference between a typed const and an untyped - really an inferred const which size is usually determined based on the CPU register size! - const. And even if writableconst is selected, it still is a memory location and NOT free for the compiler to substitute with a immediate constant value. Although optimization may choose otherwise when appropiate.. The latter is real implementation detail....

Okay... but still, other languages do treat it as a kind of a var, not const, don't they. At least C/C++ -- static variables, declared as other variables, without const, just static keyword).

Nevertheless, I'll try to accept this explanation you gave. After all, that is the way it has been in Pascal syntax for decades, so I accepted it long time ago, and there is not much point in going on opposing you further (which always presents a risk with a grumpy old man who has too many times proven himself superior to the plebs of this forum ;) ).
Title: Re: Why Pascal?
Post by: metis on May 14, 2018, 12:37:22 pm
@ASBzone
Quote
I also started learning C and C++...Nice languages, but nothing like Pascal for me...
+ For me, Pascal just happened to suit my personality, and has been quite capable of doing all that I have needed.
Though I did not try out or even learn so many ProgrammingLanguages as You did
(I'm a pure HobbyProgrammer - My Education and Profession has nothing to do with Programming, at all),
I agree with You a 100%.

I can read C/C++ w/o Problems, but I never felt any Stimulus to write a Programm with them.
For me C/C++ is like "interesting, but strange", while Pascal is like being at Home.
(really totally subjective Sentiment)


@engkin
Quote
it will be more like glorifying Pascal
Not necessarily, see here http://forum.lazarus-ide.org/index.php/topic,40803.msg285336.html#msg285336 (http://forum.lazarus-ide.org/index.php/topic,40803.msg285336.html#msg285336)
-> What is missing in Pascal ?
-> What can not be done with Pascal without "big Detours" ?
(even if this Thread's Title is "Why Pascal?".)


@snorkel
Quote
I used VB for awhile and it sucked and then Delphi came...and I immediately dropped VB
+ I ported everything I had to Lazarus and FPC and have not used Delphi since.
Same with me.


@Zoran
Quote
but much more important for the programmer is to keep distinction between what can vary...and what is constant
Yes. :)

In General, so not only referring to ProgrammingIssues:
Of course, the Theory is important, but the Practice should be kept user-friendly, otherwise
People only get lost in Details, that are not important for every Day's Work, or more "programming-spoken":
A Front-End should be comprehensive and easy to use, even if the User doesn't know every Detail of the Back-End.
If somebody is interested in getting deeper into the Theorie behind, he may do so, but it should not be obligatory.
-> Stil for me naming something (in the Front-End) a "Constant", that is actually variable, is misleading.

Just imagine, what would happen, if every Lazarus- or Pascal-User should learn Assembler first. %)
I suppose, even this Forum would be quite empty.
Title: Re: Why Pascal?
Post by: Thaddy on May 14, 2018, 03:38:09 pm
No it would not be empty at all:
Well there's a skew towards 45+ in age distribution, so yes, probably a majority has assembler knowledge. And indeed very few started with assembler but these old men switched soon to assembler to get around limitations and make the most of the hardware that was current for their personal use. Like Atari's, C64, BBC Micro, ZX80/81/spectrum and the likes. Just like these guys are all running at least one Raspberry Pi.... :-[ :o O:-) (Hardly using assembler for the ARM). I was quite happy to type in 7 pages of densely printed hexadecimals from a magazine to have my dose of gaming.... :D That's in theory, these 7 pages: I have not built in error correcting code like crc32....You'll learn it the hard way...
Title: Re: Why Pascal?
Post by: metis on May 14, 2018, 05:46:37 pm
Once upon a Time, the biggest Problem in big Towns was the Pollution
caused by the Quantity of Coaches drawn by Horses.
Nowadays, big Towns still have the same Problems, but not because of Horses.
 ;)
Title: Re: Why Pascal?
Post by: Thaddy on May 14, 2018, 06:24:56 pm
Actually, nowadays horses are welcome in city centers because -while they pollute in a more visible way - their environmental footprint is less than a truck with a Diesel engine.
Unless it is a German horse. In that case it needs re-testing.....
Title: Re: Why Pascal?
Post by: metis on May 14, 2018, 07:06:05 pm
1. One Truck is equal to about 300-500 Horses.
2. I still prefer a fast, cosy car to a Horse.
3. I never liked Diesel.
4. Other Manufacturer like from Japan or Italy got the same Problem.
(Have to leave my work place, sorry)  :)
Title: Re: Why Pascal?
Post by: marcov on May 14, 2018, 08:29:30 pm
-> What is missing in Pascal ?

Not much. I think the language suffers more from new extensions (whose applications are successively more rare, and orthogonality suffers).

Moreover, new features are already introduced while the older never are really finished, and then I mean mainly the library part.

Quote
-> What can not be done with Pascal without "big Detours" ?
(even if this Thread's Title is "Why Pascal?".)

Barring things that Pascal is not a scripting language: not much. Of course "big" is subjective.

But IMHO the problems, but also the reasons for me to use FPC/Lazarus are not in language. Once the language is sufficiently evolved enough, the attractions and problems are outside the language.

One can navel gaze at infinitum on language features, but that doesn't solve anything.
Title: Re: Why Pascal?
Post by: dbannon on May 15, 2018, 02:19:52 am
For me C/C++ is like "interesting, but strange", while Pascal is like being at Home.
(really totally subjective Sentiment)

I once heard the transition from C to C++ as being like nailing extra legs onto a dog and calling it an octopus.

And I agree, I once called myself a C programmer (yeah, in your dreams Davo) but could never handle the transition to C++, its object model just had too many things going on and you could never be sure you were seeing the big picture.

On the other hand, the Pascal object model seems initially simple and manageable but still has a rich environment beyond that initial learning curve. And it suits (eg) LCL beautifully.

Davo
Title: Re: Why Pascal?
Post by: Thaddy on May 15, 2018, 12:26:29 pm
I found an actual picture of how C++ looks like:
Title: Re: Why Pascal?
Post by: garlar27 on May 19, 2018, 01:04:53 am
I found an actual picture of how C++ looks like:

+1
Title: Re: Why Pascal?
Post by: Guser979 on August 29, 2021, 08:06:23 pm
Because if I'm not a programmer and I can produce tools that really help in my daily activities (and that's what interests me) using graphics, databases, communication, mobile-desktop integration and all that in an absurdly short time.... God. .. I wonder what a programmer can do.
TinyPortal © 2005-2018