Who knows, maybe Rust and something like Ada++ http://www.adapplang.com/ will be able to dethrone C++, or Java some day.
Who knows, maybe Rust and something like Ada++ http://www.adapplang.com/ will be able to dethrone C++, or Java some day.
There is a hierarchical namespace based on units, and also there is lexical scope.
I love Lazarus, and Delphi before it, and Pascal before that ... but I gotta say, the language, readable though it is, is a pain in the rear to write.
An instance of a class is not the same thing as an object.
By default, the file open/read/write/close routines don't return error values so the caller has to do extra work to check statuses after each use of these functions (IIRC, those error codes from Assign(), Reset(), etc weren't thread-safe either!)
Some conditional expressions cannot have parenthesis (compilation error) while other conditional expressions must have parenthesis (also a compilation error).
Some builtin functions can't be easily 'wrapped' because while the function may take variadic arguments, the language doesn't allow the programmer to write variadic argument functions.
It's death by a thousand cuts; each little problem, surmountable on its own, adds to the overall friction when developing.
What I really like in Pascal:
1. Programmer-defined range types: enums are not a replacement for those. 2. Bounds checking on arrays; I'd rather crash with an exception than silently overrun the array. 3. Nested functions (although, now with almost all languages supporting anonymous functions nested functions probably aren't really needed).
I have no idea what you mean here, sorry.
> By default, the file open/read/write/close routines don't return error values
Those file IO methods are for backwards compatibility with Turbo Pascal. They haven't changed semantics since DOS. They don't support Unicode. They are heavily deprecated. Today, try using TFileStream.
> while the function may take variadic arguments, the language doesn't allow the programmer to write variadic argument functions
Pascal isn't C. You can consume variadic methods written in a C library, but the Delphi way to write the same thing is an 'array of const'. Here's the Format method, for example: http://docwiki.embarcadero.com/Libraries/Sydney/en/System.Sy...
> each little problem, surmountable on its own, adds to the overall friction when developing.
You may have better luck not thinking of it from a C background but as similar to, say, Python: some things are different.
>> An instance of a class is not the same thing as an object.
> I have no idea what you mean here, sorry.
This explains the issue quite well: https://forum.lazarus.freepascal.org/index.php/topic,43622.m...
> Today, try using TFileStream.
I have used it and was not as unhappy with it as I was with the Standard Pascal file IO functions. I was never able to figure out from the exception why a TFileStream method failed. The most you could infer was that an error occurred, but not what error.
This makes for a very poor interface to the user in the resulting application, as they have no idea what to do to fix the error before retrying. In most other languages (that Delphi and Lazarus compete with) you can let the user know what they should do to fix the error before retrying.
> You can consume variadic methods written in a C library,
That doesn't apply to what I was saying. I meant that a programmer could not write a Pascal procedure that wrapped a variadic-args Pascal procedure. C has nothing to do with this.
This is occasionally useful (say, for logging), and its ommission is one of those tiny things that add friction.
With all that being said, I still prefer doing native GUI apps in Lazarus to almost everything else out there. It's insanely readable even after a prolonged period.
> I have no idea what you mean here, sorry.
This explains the issue quite well: https://forum.lazarus.freepascal.org/index.php/topic,43622.m..."
I am not sure how Lazarus implements stuff behind the scene but I can tell you 100% for sure that in Delphi every declared class has TObject as ancestor class, so when you instantiate a class in Delphi, you are creating an object.
Like I said, my experience is quite old (circa 2004 with Delphi), but last I used Delphi, it functioned identically to the way that link for Lazarus said it did.
You could create your own class, then instantiate it, and what you got was different from creating an instance of an object.
Delphi was not a failure by _any_ stretch of imagination. In terms of RAD, it was only second to VB.
Also keep in mind that a lot of people at the time knew Pascal, in that regard Delphi was completely esthetically pleasant.
Think of Qt, WinUI, CUDA, Unreal, Visual Studio debugger, C++ Builder kind of tooling.
func Foo (X : C.int) return C.bool with Import, External_Name => "Foo";
I suppose though that you are right. A majority of modern programmers probably view sophisticated tools and pre-built packages (a la NPM) as necessities and hardly care about performance or code quality.
case Variable:
when 0 => Put_Line ("Zero");
when 1 .. 9 => Put_Line ("Positive Digit");
when 10 | 12 | 14 | 16 | 18 =>
Put_Line ("Even Number between 10 and 18");
when others => Put_Line ("Something else");
}
Where's the { to go with that }? Oh, that's right, the : is replacing is: case Variable is -- was : above
..
end case; -- replaced by } above
and there is no {. It may have made more sense to go Python-style and use significant whitespace.And regarding package management, Alire does exist and is starting to become interesting for Ada users. The list of crates is still small, but it's functional and (somewhat) easier than managing it manually.
EDIT: Fixed some things like "it's" to "its" and "process" to "procedure". It's Saturday morning and my coffee was still brewing.
Possibly part of the reason. Pascal has a very readable syntax, but for some (most?) programmers it is too "verbose" and that is enough for them to never consider it. This is probably true of any language labelled "verbose".
Python and Ruby advocates probably feel these languages have found the right level of conciseness and readability. But everyone has a different opinion. Of new languages, Nim and Julia seem aiming for the same balance: not too terse, but still easy to read. Have they succeeded?
I find it fascinating that C's influence on language syntax continues today with new languages (e.g. Rust, Zig) in a way that Pascal does not.