A guided intro to the Free Pascal language(getlazarus.org) |
A guided intro to the Free Pascal language(getlazarus.org) |
https://dadroit.com/ https://peazip.github.io/ https://cudatext.github.io/ https://lazpaint.github.io/
As far as I know, there is no toolkit out there that lets you make fine looking applications for multiple platforms with proper speed.
The old Pascal you may know is not the new Pascal. The development of Pascal is mostly focused on ease of development while maintaining low-level programming and backward compatibility. It looks old on its face, but it is young at heart.
I recommend starting with Lazarus, https://www.lazarus-ide.org, a much lighter IDE compared to so-called light projects like VSCode, with many more features and components to play with.
Friendly word: don't let the comments with outdated information make you miss a great and fun tool.
Don't get me wrong, though. I do think Lazarus/FreePascal are underrated, but some of these claims are exaggerated. FPC generates good code, but on par with GCC/LLVM? I'd guess it's probably sitting closer to Go in terms of performance characteristics. More than good enough, but surely a ways away from the ridiculously complicated optimization systems in LLVM and GCC which aggressively vectorize, constant-fold, DCE, inline calls, interchange loops, and so forth.
I stand by what I said about speed: I've been comparing the resulting code of GCC or Clang and FPC for years, and if you know what you're doing, the resulting speed will be almost the same. Sure, Clang does some quirky things, but at the end of the day, I've never seen a piece of code written by the same person in both languages (the result of one mind with one style of code) that resulted in a different speed. To be fair, GCC or Clang are a step ahead because they are the result of millions of dollars in corporate support, but my response was to emphasize that the speed is not what people remember from decades ago. As a sample, you can try the Dadroit tool, I linked, I am on the team, and you can compare a result of Pascal with similar tools.
And I agree with you. Don't get me wrong; despite my passionate response about Pascal, I am not saying that Pascal is a one-to-one replacement for new languages; my thesis is that you have most of the cool stuff you hear in this old language too, just without the hype, to encourage people to give it a try and not repeat the old "Pascal is old."
And they have bounds checking, which makes it almost impossible to get buffer overflows
There is an FPC-LLVM variant. Then it uses LLVM to do all the optimizations
Take that as a small (subjective) clue. Anything that is great about Rust or Nim or <..> could also have extended Pascal or M2 for the same result, and much sooner. Especially goes for M2, because the grammar was so small, thus avoiding the old PL1 traps from an overloaded parser.
FPC needs smart macros, needs to backport M2 interfaces, and the solid green thread spec* backported from M2, but it really is in the ballpark. You want gc? Well, fair enough, but you can write a pretty good mark/release* facsimile with RTTI. Or how about Eiffel simulated contracts with open arrays?
And Lazarus, good grief what a 30 year old premiere open source project. No point in even talking about how awesome it is.
Co-Pascal has been doing co-routines for 45 years.
In turbo pascal, you could create mini-heaps that could be dumped most anytime. They weren't smart, but still a cool feature.
Macros would be a horrible thing to add to Lazarus/Free Pascal, in my opinion. They would make the reader have to second guess everything they see. Also, it would likely slow down things by not allowing single pass compilation any more.
>Co-Pascal has been doing co-routines for 45 years.
I wrote a Turbo Pascal implementation of co-routines back in 1987[1], although I'm just learning of that term now. I was frankly amazed at how simple it was to get working, though I did surprise myself the first time fork returned twice, and I was confused as to why it did ;-)
[1] https://www.pcorner.com/list/PASCAL/TASKER4.ZIP/TASKER.PAS/
(Though I hear the strings, at least, know their own size!)
I didn't really have a need to work with pointers and do pointer math in Pascal, because language itself provided facilities to work with heap objects safely.
Also standard Pascal compiler added array bounds safety and many other checks, and you would easily find these errors during program execution (there wont be a silent exception).
Also because Pascal compiler is LL(1) single pass compiler, you could easily do a cycle of: edit code, compile (<1 second on 333Mhz Pentium-II), and run.
That compiler enabled developer experience of like modern Python/Javascript
Unlike C++ which spent enormous time evaluating macros, compiling, linking, etc
eg I use C a lot and find myself referencing array index [0] a lot, in pascal arrays starts at [1] if not specifically defined so I know this from experience, frustratingly I have a different problem in C which will either return random data or crash if writing.
What does this mean, exactly? Usage in the style of Go requires garbage collection and being safe like Rust (without GC) requires a borrow-checker, and as far as I know Free Pascal doesn't have either.
I am working towards this in https://github.com/planetis-m/cowstrings
In general, expect a lot more compiler magic out of Pascal, a lot of concepts were hacked into the Borland compilers over time.
I hate the insane pricing Embarcado has imposed on Delphi. They have had cross platform GUIs in Delphi for a long time. Something for some reason other tools struggle and mostly fail to do.
I have not been able to "sell" it to clients mostly due to price.
I remember that Pascal was the norm for Mac programming for a time during the late 1980s or so. You could use THINK Pascal (later Symantec) or MPW Pascal. Pretty soon everyone was programming in C and compiling their programs with Metrowerks CodeWarrior.
Nop, more like the other way around in the 80's. Before, there were two reasons: lack of a standard (Pascal was a learning language, not intended for professional use) and the VM fever: very often so-called P-Code systems were the quick and dirty way to have a programming language for a new system. The result was slow, incompatible, cumbersome access to machine resources.
C was always compiled and had a clear standard that included direct memory access. Also UNIX.
But in the 80s, TurboPascal was $50, had everything that C had + an IDE + compiled x100 faster. Later there was a nice text-mode GUI (TurboVision), then Delphi. Microsoft defused it poaching most Borland talent.
https://wiki.freepascal.org/Lazarus_on_Raspberry_Pi
https://wiki.lazarus.freepascal.org/fpcupdeluxe
A personal dream: having something like Lazarus that works with other languages too; that would likely become a game changer for desktop apps development.
Pascal also has libraries for nearly everything, check awesome pascal for a list of actively maintained third party libraries: https://github.com/Fr0sT-Brutal/awesome-pascal
I feel like pascal is a hidden gem.
Programming languages have advanced _a lot_ since Pascal was created. It's core principles remain valid (safety by default, readability, flexibility). But the feedback loop between language design and actual usage is much tighter thanks to the Internet and open source.
Some things I still miss from my Delphi days are the language-level enumsets, near-instant compilation and RAD tooling (GUI builder).
After using VCL for a year or two, I started branching to other, much more popular programming environments, and was shocked about how bad they were for GUI development. Why would anyone put themselves through the pain of writing interfaces manually using programming languages not designed for it (like C) when you could design everything in a convenient GUI builder?
It's sad they decided to focus on the "enterprise" market and buried themselves in the long term. Writing GUI stuff in Delphi was (probably is) a pleasure: they compiled quickly, looked native, and ran fast on my shitty hardware.
I understand why some programmers dislike Pascal's syntax, but C and C++ are also old and still popular (including for new projects). Syntax and semantics are closely entwined but C and C++ syntax still influence "modern" languages.
Wild. Also nice units for doing mmap and all libc stuff. I really ought to finish learning Pascal and actually write something in it. Not a bad language.
so necessary parts get linked statically to the resulting binaries, and those binaries do not require libc. most of the library goes with roots to kernel calls, bypassing libc.
once you start using threads or link to other c libraries (like gtk) then libc becomes a dependency.
Maybe when I am done with my compiler (written in D), I'll write something fun and small like that in Pascal. Who knows! But I love FPC!
Have any of you used both languages? What made you stick with Free Pascal instead?
(To be clear, I'm interested in a comparison that goes beyond the price point of the commercial compilers, which is a tired subject at this point.)
I have nothing impressive to show for my work except for a lot of retro-pride when I type in e.g. the snippet which triggers the Pascal program which tells me how old I am. With some bells and maybe a couple whistles.
I was surprised to learn that there was Pascal for the C64, which I thought was more of a "BASIC or bare metal" system.
I too was a victim of the great AP Pascal force-feed in my HS comp. sci. class...but fortunately at the same time there were demoscene programmers around the world blowing my mind with Pascal programs and it seemed like there were new projects to appreciate online (BBS) every day after school.
To whit: Someday I would like to write a Pascal raytracer that tells me how old I am, with emoji output, since my other ride is a text editor. (And if you don't like my driving, get off the sidewalk!)
https://lemonspawn.com/turbo-rascal-syntax-error-expected-bu...
If coding with C, like text adventure games, then for example:
But, I tried FP last year. I wrote a program to mimic a small tool in the company I worked for. It was fun actually. At the time, I sort of wanted a lot to write stuff in Emacs. There is an LSP server for FP but it's not really complete.
- It has the most sane strings you'll ever see, you don't have to allocate them, and they can hold gigabytes of text.
- You'll never confuse equality tests = with assignment :=
- It's case insensitive
- It doesn't do macros
- It is one of the fastest compilers available
- It is one of the best GUI builders available
Things it doesn't do right
- Begin/End seems verbose to some people
- Other "standard" pascal systems gave it a bad name
- Historically, Borland et al, priced people out of their products and killed off a loyal use base.
Pascal was awesome. So much better than the others. It really launched my interest in coding once it clicked.
I remember discovering that the early Apple game Wizardry was written in it one day when I was hacking around with it.
https://www.cs.virginia.edu/~evans/cs655/readings/bwk-on-pas...
I laugh out loud when I remember it, definitely the programming language with the most funny/catchy name ever!
Cut a long story short, Ive installed Dr Racket today and working through the tutorials.
Much later however, I started really appreciating Pascal, both as a teaching language and as a multiplatform language.
PeaZip, CudaText, Transmission Remote GUI, UltraStar Deluxe and plenty others are written in FreePascal.
At the time, I remember pascal feeling like "real programming". The programs were compiled and they operated at various levels of abstraction, from pointers up through advanced data structures and interfaces/ADTs. I didn't see Scheme as more than a toy, which was partly because the MIT Scheme implementation was just an interpreter. And I hated Basic and still do.
Pascal was great because it was pretty easy to learn and somewhat consistent. Its most annoying feature, semicolon-as-separator, was easily handled by the terrific Think pascal editor.
In its time, Pascal was a great choice. There were real-world things that you could do immediately using Think Pascal and Turbo Pascal. Making the switch to C and Unix wasn't simple but probably easier than starting with Basic. However, I was left with a bias towards wordy languages like Pascal, Ada and Modula-3 that took a while to get over :)
I could write an article about each of these features, but in summary they each are powerful and help users write more useful programming code when leveraged correctly.
Pascal is way too verbose and boilerplate-ly compared to that.
I believe the right approach to programming is graphics for kids.
My mom taught programming in the early 80s. She took a course at the nearby community college, and a year later, was teaching the course. Her background was... high school math teacher. She said: "Programming is just math, a program is like a proof." Fortunately I loved math and proofs, so that way of thinking wasn't an obstacle for me. Clearly we know differently now.
they could approach the same math from the other side, by starting to write games. and gradually come to game math. that would be more interesting, and then it would become obvious why one may need some math while programming.
I guess it depends on the school and people there to create a fun but educational culture.
I write lazarus programs, and link to my lib**.so files which are all written in C. Works very well.
this also tells us that c++ became so big and complicated that one company (embarcadero size company) is not able anymore to support own compiler, they need to maintain own patches.
This is of course far from having something like C++ Builder.
To have something like C++ Builder it'd need a lot of things to work together:
1. A C++ compiler will need to be extended so it can use Free Pascal classes (in terms of memory layout) and add any necessary language functionality for "published" sections (RTTI data that allows FPC objects to describe themselves and be streamed/serialized), metaclasses (classes in FPC are objects and can have their own virtual methods, including virtual constructors), delegates (basically "fat" pointers) as well as data types like sets, strings, etc that FPC has. LCL (Lazarus' framework) relies heavily on pretty much all of FPC features.
2. FPC will need to somehow be able to import classes defined on the C++ side too so that components written in C++ will be usable in Lazarus. Also almost goes without saying but it should be possible to statically link programs using both FPC and C++ in the same executable.
3. The C and C++ runtime libraries will need to use FPC runtime library functionality for things like memory management (FPC's memory manager is pluggable) so that "crossing" memory management will work fine - even across dynamic library boundaries (e.g. calling `malloc` on the C++ side and then "FreeMem" on the Free Pascal side, even when the latter is in a dynamic library that shares a memory manager with the host program, should Just Work).
4. Lazarus' "codetools" will need to be expanded to support parsing C++ in addition to Free Pascal so that all of the IDE's automatic code writing and refactoring functionality will work for C++ too - things as simple as double clicking on a button and having the methods be written automatically in the editor with the cursor placed in the method body rely on this working.
These are from the top of my head, there might be other issues to handle, but even from the above it should be clear that it requires not only a lot of work but also a lot of different projects to work together (unless FPC and/or Lazarus devs decide to implement their own C++ compiler and runtime).
In the short term it might be easier to use Qt Creator which has some RAD-ish features. It is certainly clunkier, the API feels to be made with a code-first (as opposed to LCL's WYSIWYG-designer-first) approach and the IDE isn't as featureful (also at least for me it never works out of the box on Linux) but it is the closest open source project you can find for C++.
Exactly.
When I hear "safety" I think of what guarantees the language is able to give me and how. As an example, if I don't import "unsafe" in Go, pure Go code is guaranteed to be "memory safe" except for concurrency hazards. In general, this means that pure, safe Go code cannot ever trigger a use-after-free, double free, out-of-bounds memory access, etc. Of course, this doesn't prevent bugs, but the guarantees provided do prevent certain classes of security issues entirely. Bugs that trigger Go panics are almost never exploitable, whereas bugs that trigger segfaults often are.
With Go, it's possible to disallow unsafe code entirely, because the safe subset of the language includes almost the whole thing. The only real escape hatch is the unsafe package.
Rust is similar, but instead of unsafe as a package, it has unsafe blocks. And instead of still allowing concurrency errors, Rust enforces memory ownership tracking via referential lifetime checking. Lifetime checking still applies even when using unsafe blocks. Lifetime checks prevent bugs like double free, use-after-free and more, but they also prevent concurrency errors by entirely disallowing multiple mutable references to exist to the same data, as well as disallowing a mutable and non-mutable reference to the same data simultaneously. The only way I'm aware of to crash safe Rust code outside of panics is by causing a stack overflow, but this condition is not exploitable. Thus Rust has one of the most impressive definitions of a "safe subset" that I'm aware of. The only way you can really do better is probably using theorem provers to prove correctness, or maybe you could make bounds checking a bit more runtime-efficient using a SAT solver to disprove possible out of bounds errors.
As far as example code goes, I think it's moot. The point is that FreePascal doesn't really have an explicitly safe subset. As you are describing, it is possible to use FreePascal safely. In fact, it's easier to do so than many other languages. I hear you. However, that having been said, technically, most languages have a "safe" subset of operations that can not have any runtime hazards. FPC's safe subset is probably bigger and more useful than C's, but it isn't explicitly defined like Go or Rust. That alone puts it in a different class. Having safe subsets be well-defined allows you to net hard guarantees by enabling one to enforce the use of only safe subsets. It allows you to turn "probably never" into "absolutely never, ever." (Until you get hit by a hardware bug like rowhammer or a faulty CPU... But, you know.)
> I stand by what I said about speed: I've been comparing the resulting code of GCC or Clang and FPC for years, and if you know what you're doing, the resulting speed will be almost the same.
I mean, if you write good Go code, it will also optimize very nicely. The FPC optimizer is no slouch: it has all of the basic optimizer passes you could hope for. It's documented as such. It's probably a good compile time trade-off. But the documentation reveals it does indeed lack certain advanced passes like auto vectorization, and I'd find it surprising if the optimization passes were as sophisticated as LLVM/GCC.
Despite that Go is similar with regards to optimizer passes, nobody would consider Go particularly slow. In fact, it is considered to be very fast.
I do understand that you are telling the truth. I have no doubt you did compare GCC and LLVM to FPC and found that it is often similar in performance. That's generally true among a lot of languages for most code. Of course, there will be code where GCC/LLVM will do inscrutable things that less complex optimizers are definitely not going to do. Does it matter? I mean, it depends. Sometimes it matters. I believe that it is most likely going to matter in particularly complex and large software like web browsers, not the type of stuff most people are doing.
Anyway, I think Lazarus is still a great sell. Delphi always had one of the better UI libraries back in the day, and today, having a decent UI library at all is honestly quite a chore. Therefore the LCL alone has become quite a selling point. It's so bad that there is in fact Go bindings to the LCL, because Go and Rust lack decent, mature GUI options.
People definitely undersell Object Pascal and FPC because Pascal is old and weird looking. I feel the plight.
Pascal also avoids buffer overrun errors on strings, because strings are dynamically resized as necessary.
You can also avoid having to free objects if you declare them as implementing a certain Interface (I forget the exact one). They will automatically be freed when the number of references drops to 0.
Similarly, C++ has memory-safe strings and arrays in the STL, with automatic memory management, allocation, etc., but it is also not "as safe as Rust." On top of that, FPC lacks any equivalent of the borrow checker. Automated reference counting is a good feature, but it won't stop you from writing race conditions. Borrow checking can, which is pretty powerful.
Using FPC with LLVM will indeed give you LLVM optimization passes, but it's got quite a lot of limitations. I'd probably opt to use the FPC native code gen.
C++ does not have bound checking on [].
And people write std::string& as return type or new/delete std::string, or use iterators, and that is all unsafe. Pascal does not have anything like that
Angle trisection tools. https://www.instructables.com/The-Tomahawk-an-Angle-Trisecti... First AA proof I learned: Cannot trisect an angle with ruler and compass.
> However it is imperfect: for it is not yet delicious.
Is this the same as how in C, as long as you follow very simple convention with malloc() and free() you won't have memory safety problems?
if you were to pass reference around, then compiler would warn about potentially dangerous Free.
I don't remember ever seeing Pascal code where you received raw pointer and then directly casted it to your object type for example. Pascal has very powerful and expressive type system
It helps avoid the classic "oh, I forgot to return it" bug. Also makes the code more succinct and saves you from having to type an extra line for explicit return.
I kind of get why you would be wary of it, as it is a special variable but compared to other messed up stuff like for example Rust treating a line without semicolon as implicit return, it is a relatively tame solution for this problem and can be easily figured out.
Did you ever had any actual bugs caused by the use of result?
In some cases an implicitly declared variable feels neat and convenient, but I'm not sure it's worth it.
The parenthetical is correct, what is outside is not; Pascal had a standard (ISO 7185:1983), but the standard lacks features needed for serious use, so Pascal implementations were either standard and hobbled or useful but not interoperable.
Doesn't "1983" tell you something?
I don't mean to snark. Maybe my comment wasn't clear enough. I've talked of two different periods: the first in the seventies, the second in the eighties and later. The starndar was late. By that time, it wasn't needed because the only Pascal that was widely used was Borland's.
That it was finalized around the same time Turbo Pascal 1.0, which only ran on DOS and CP/M, was released.
> The starndard was late. By that time, it wasn't needed because the only Pascal that was widely used was Borland's.
The ISO standard closely followed the 1974 language description, which served largely the same purpose and had generally the same shortcomings on utility, so that the “interoperable but not useful because following a very limited common description, or useful but not interoperable because of proprietary extensions on top of the common description” predates the ISO standard; the lack of a common labguage spec was never as much of a problem as the focus of the spec.
And, no, by December 1983, Turbo Pascal (released the month before) was not the only Pascal that mattered. Nor would it be later in the 1980s, as Apple's Object Pascal (which influenced later versions of Turbo Pascal) became important.