.. as much as I enjoy coding in Object Pascal, it DOES have a variety of annoying limitations that simply aren't present in other languages.) What does all this mean? In my opinion, it means FPC and Lazarus have far more "on their plate" that most people think: without them, Object Pascal would almost certainly drift completely into the "legacy" category.
But I am curious - what are those annoying limitations?
Then there are other aspects, like quality of debugging (weak compared to commercial offering), no cheap shared hosting for webapps (like PHP or to some degree asp.net).
More interesting is to consider that that desktop apps are Delphi/Lazarus home turf. If you want to find defects you will have to go out of that comfortable bubble, to webapps, service apps etc. Yes they are possible, and there are some frameworks, but none as complete and dominant as LCL is for desktop apps.Yes, indeed.
Right, it's not the language per se that has kept Pascal out of Web apps, or mobile development, or even whole areas of programming. Case in point: GIS. Join the "community of one" and do GIS with Pascal (https://macpgmr.github.io/MacXPlatform/PascalDynLibs_3.html) or join the thousands of Python developers who have been doing GIS for years (http://plugins.qgis.org/plugins)?
Pascal itself is quite adaptable. For example, it even fits into the world of Xcode and Objective C pretty well (https://macpgmr.github.io/MacXPlatform/WebAppOverview_3.html#EmbeddedBrowser). It's just that nobody embraces it in these new areas.
.. as much as I enjoy coding in Object Pascal, it DOES have a variety of annoying limitations that simply aren't present in other languages.) What does all this mean? In my opinion, it means FPC and Lazarus have far more "on their plate" than most people think: without them, Object Pascal would almost certainly drift completely into the "legacy" category.
I have enough experience with programming languages to know that nothing is perfect.
But I am curious - what are those annoying limitations?
I am aware that desktop applications is not exactly 'what everyone is doing' these days.
However, if you want to do that, what options are there?
And who has the funds to cover licenses, subscription fees, whatever.
Windows is not free. Visual Studio is not free if you want to create apps for Windows Phone.
I know next to nothing about Apple, but don't you need to be in their developer program?
It's not about an issue but about a kind of desire...FPC supports static arrays when the size is known at compile time, and dynamic arrays when the dimension is determined at run time.
Algol 60 doesn't support locally allocated dynamic arrays...This is not correct. I do not know if there still exists a machine capable of running a true ALGOL60 compiler of old times. I replace "does" with "did" therefore. One of the two computers I actually used with ALGOL60 was the PERM, operative since 1956 (yet without an ALGOL compiler first) and moved to the Deutsches Museum, München, in 1974. The other one was by ICT (later ICL) from the UK, put into operation in 1967 for a German scientific institution, the Gesellschaft für Strahlenforschung, Neuherberg, where I did some programming and consulting and lectured on ALGOL60 in 1968.
This is not correct...You are right. From this (http://www.softwarepreservation.org/projects/ALGOL/book/Randell_ALGOL_60_Implementation_1964.pdf) on 2.2.1.1 (p. 78) "Dynamic array are also implemented using the stack". Is it important where the data is allocated for an array? FPC have SetLength(A, n). Moreover, n can be calculated in the same block, reassign and use with new value for new array allocation. This is not true for Algol.
Where should the else belong to?
if x then
if y then
c:=1
d:=1;
else (* y *)
c:=2;
d:=3;
end; (* y *)
else (* x *)
e:=4;
d:=4;
end; (* x *)
procedure xx;
begin
if then
x:=1;
else
y:=1;
end;
end proc;
Concerning the syntax (and semantics) of alternatives, whether complete: if ... then ... else or incomplete: if ... thenAt least
I prefer to understand begin end as a pair of parentheses for the purpose of making one item out of many like ( ) [ ] do in different contexts. C, C++ actually use the curly brackets for the case of statements where Pascal uses reserved words for better distinctness (and out of old tradition) .
Unpaired parentheses are a plague!
If there will be changes in this field one day I would prefer to abandon these wry pairs: record end and case end.
Are there more?
- to get a satisfying surrogate for array[1..m, 1..n] of DoubleThis?
= to write a procedure for, say, the multiplication of two arrays callable like MatMult(Left, Right, RowsLeft, CommonSize, ColsRight, Result)
= (Editing) ...or, even much better, without the three sizing parameters.
The only annoying thing for me is that something like this is not yet possible:Not very useful. Often used option
The only annoying thing for me is that something like this is not yet possible:Not very useful. Often used option
Ideologically different design. Try finally to conserve resources, but try except for error handling.
The only annoying thing for me is that something like this is not yet possible:Not very useful.
Years ago I read the source of VCL and as long as I remember they almost always had try...except inside try...finally. This is the most often usage. Not the opposite.I quickly try this code:
try...except...finally...end would be very useful and used often.
Line 4, line 9 and may be line 11 it's not used often. In most cases, they are used separatelyHm. then they should be used more often, because the finally protects also resources from within an exception block.
Line 4, line 9 and may be line 11 it's not used often. In most cases, they are used separatelyHm. then they should be used more often, because the finally protects also resources from within an exception block.
I use it all the time. I thought most real programmers would ..
Because you can really recover from the exception gracefully and without memory leaks.
It's even best practice.
because the finally protects also resources from within an exception block.
3. Incompatible type for similar data type, such as:
Not very useful. Often used optionnot covered by this pattern.
Ideologically different design. Try finally to conserve resources, but try except for error handling.