Things That Turbo Pascal Is Smaller Than (2011)
prog21.dadgum.com
prog21.dadgum.com
Viewed another way, Turbo Pascal recaptured the incredibly rapid edit/run cycle that I first experienced with a PDP-8M running BASIC. Only now, I had 64k instead of my shared of 12k shared among a maximum of four users, an IDE instead of a line editor, and a far better language.
Turbo Pascal also blew away anything else available on the PC. I had a C compiler from Microsoft that was far more expensive and far slower.
Turbo Pascal was a truly magical piece of software. I remember that I had some initial skepticism about it. As I recall, it took some liberties with the language. But once I finally used it, I was instantly converted.
IMHO, nothing has quite captured that experience of development until IntelliJ, starting with 4.x or 5.x.
There's a dedicated group of troopers who have kept the flame alive. It's cross platform. There's an Android port in progress. There's a JavaScript backend. The IDE is like all the good things about Delphi 7, none of the drawbacks.
The community is really a nice bonus, too.
I have to admit being a prick in this particular matter. Not being able to find subject when search on Google, Githab etc reveals a ton of info I think says something.
One extra thing. I do use Linux and find it very useful. Do I need to abandon it because Linus is not a shining example of polite person?
I've done some Pascal coding, and this lack of libraries or projects is for me a practical impediment. Freepascal (and Delphi) come with very complete stdlibs (if they are called that), but I'd not be satisfied with merely Python's stdlib either. On top of that, string handling is imho very uncomfortable in Pascal, feels like nothing changed much in 20 years. I found a recent Freepascal university course, but source files with 10kLoC do not make it helpful to get started.
So, while the Freepascal forums seem helpful, it's a meager resource if that's basically all the community is.
https://github.com/search?q=Rust 85,885 repository results
https://github.com/search?q=delphi 9,938
https://github.com/search?q=pascal 9,259
* Open source Delphi/Pascal are shared elsewhere?
* Delphi Programmers do not like to showcase or open-source their projects?
* Delphi/Pascal is used to create mainly proprietary software?
Either way, I think that for Free Pascal to prosper in the long term, something should change. Perhaps more open source projects published on Github/Gitlab.
You are confusing "hard to find" with "less". There is way less projects on github (the original question specifically mentioned github). However 9,000 is still a big number and one can find virtually anything needed from a practical standpoint. On top of that both delphi and lazarus come with huge system libraries.
C++ for example dwarfs delphi on github. However when I am doing C++ I am looking for very few projects in very specific areas (network, file management, db connectivity etc). Suddenly your choice becomes not that big when you separate all the noise.
Also whole bunch of delphi projects are located elsewhere due to various reasons. Hence my advice to ask Google.
Finally delphi projects tend to be rather large and high quality, check this one for example: https://github.com/BeRo1985/pasvulkan or other repos from the same guy.
https://sourceforge.net/directory/?q=rust 27 programs
https://sourceforge.net/directory/?q=pascal 2268Github has some repos but mostly dumps of old Delphi projects, not really a great resource.
Here's the wiki page on component authoring:
In general IME on Linux the best approach is to install FPC (either from repositories or, better, using the official release) and then download the Lazarus source code and compile it somewhere in your home directory with 'make bigide'. This will avoid any problems with Lazarus packaging that often tends to be broken (again, IME).
You can see the whole process in this video i took a couple of years ago:
https://www.youtube.com/watch?v=s_01Xhd2EJM
(this is making a simple puzzle game)
I'm basically doing the same procedure for many years now and i never had an issue with getting Lazarus or any of its packages to work.
Having said that, the next version of FPC will support dynamic packages. They had to change some things in how RTTI is stored, apparently, to accommodate the OS differences (this may break some programs that use the RTTI structures directly, though the fix is trivial and 99.999% of programs wont be affected - even some of my own code that does touch RTTI directly works fine in both the latest stable version and the development version).
However chances are Lazarus will still keep using the recompile approach for some time since it'll need to work with FPC 3.0.x... and also it will take some time to update all packages to work dynamically.
Anyway, what i'm trying to say, this was done due to technical issues and compiler limitations due to what FPC and Lazarus have to support and remained an issue for a long time because in practice it didn't make much of a difference. However it will soon be solved.
Delphi has for some years the possibility to work on more then just Windows, and still is a breeze, regardless if I targeting Android or Windows, to just "here is the package, put the component on palette" with just 2 clicks.
I really hope Lazarus will come home, like you say, with this, since Delphi is not targeting ARM in Linux, while Lazarus does. We'll see what future holds, as I have no problem using one or the other as long as the compiled project works on its intended target. Also regarding RPI, I can just install Android on RPI4 and Delphi will have no problem targeting that
In any case i was referring to Delphi in general from the start. Delphi had support for dynamic packages since version 1, but for decades they only supported Windows. FPC on the other hand had support for multiple OSes before even version 1.0 was released.
TBH i do not remember the exact details, but IIRC it had to do with memory management, symbol resolution and RTTI support across DLLs (e.g. being able to do something like "Foo is BarClass" in DLL A, Foo is an object instantiated in DLL B with a class that is only available on that DLL B but descends from a class defined in the main program whereas BarClass is a variable holding a virtual class defined in DLL C that also descends from the same class - essentially tying to merge in RTTIs from different AOT compiled modules where none has a complete view).
And of course the fact that it was a low priority issue since there wasn't any major practical drawback (personally the only issue i had was that i couldn't share the RTL and LCL between executables that i'd otherwise package together, meaning that the produced executables would take more disk space than necessary since each executable is having their own copy of the RTL and LCL instead of using them from a shared object/DLL).
I do have fun playing with them though, trying to learn each what quirks lurks around. I mean one example is above I said - Delphi can target ARM if it's Android, but can't target ARM if it's Debian. So I can run on RPI something Delphi cooked if I have Android there, but if I have Raspbian I can't. Same hardware, different OS, such a hard nut to crack :). While if it's Intel and you have Linux, guess what - Delphi owns it.
So for now I am switching between IDE's/Frameworks all depending on availability of technology and most importantly what client(s) want.
A few years ago I tried playing around with it on macOS, but all I remember is that I wasn't able to get things up and running because I kept encountering problems. Maybe I was doing something wrong or I didn't invest enough time in setting up and learning how to properly use the tool. I think I tried using Homebrew to install everything during my previous attempt, but since I'm not seeing any mention of this option as part of their macOS installation instructions [0] then I'm guessing that might've been the source of my problems.
Would you still recommend learning Lazarus and FreePascal in 2020?
I've mostly done web development, but I'm also interested in traditional native application development. My hypothesis is that learning to use some of these older tools or systems can teach you a lot of lessons which carry over across languages and platforms. For example: learning a bit of Qt helped me refine my internal models for various UI widgets. I want to learn to write faster and higher quality applications than our current highly-frustrating standard.
[0] https://wiki.lazarus.freepascal.org/Installing_Lazarus_on_ma...
One try to sell you something, the other had an idea for a language he started to work on over the holidays.
An interesting approach, but how practical is it for more modern languages?
GCs aren't new either - going back to John McCarthy's 1959 implementation in Lisp - which makes me think a non-optimizing AOT C# compiler and stop-the-world GC could probably be implemented with minimal memory usage (actually, isn't this how the .NET Micro Framework worked?)
Looking at my current .NET project I'm working on - the actual compilation of about ~800 C# source files to CIL takes less than a couple of seconds - the rest of the build-time is taken-up by asinine build-steps in inherited MSBuild .targets files that I don't have any control over (one step involves copying all of the source files and assets - to a separate pre-build directory twice). Methinks problems with computer efficiency exist in non-obvious places.
You probably know, but for those who don’t: Pascal requires both. It’s not as if Turbo Pascal implemented a subset of the language.
Also, multiple passes is less important nowadays. In early times, memory was so tight that each pass wrote its output to disk or tape. Early FORTRAN compilers had many. See for example the ‘sections’ in https://archive.computerhistory.org/resources/text/Fortran/1.... Depending on how you count, that’s 6 to 9 passes. (Or one. That document says “With one exception, Fortran may be considered as a one pass system. That is, it looks at the source program only once, and it makes a scan of each statement once only. From then on, references are to tables only.” I think that’s bending th truth, though)
Nowadays, intermediate results can be kept in RAM. Clang, for example, can runs tens of passes, some of them multiple times. That still slows things down, but less so.
Many years ago i wrote a Java-like scripting language (classes, GC, etc) with that approach. Funny enough, at the time it didn't occur me that i could have separate bytecode streams for methods, etc, so the VM was almost like a custom CPU (the only non-CPU-like feature was an instruction to allocate memory) and since it generated bytecode while it was parsing the source code itself (even skipped any separate tokenization, i parsed the character streams directly) while it also allowed code to be placed outside of functions or classes (it was a scripting language after all), every time a class or function was encountered in source code, it'd emit code to jump over it - so the final bytecode would start by a series of jumps over the functions and classes before arriving to the first actual instruction :-P.
Pretty sure it was the world's first IDE, not just an IDE. In a single .exe file it had a WordStar compatible text editor, compiler, linker and libraries.
That probably depends on whether you count live-coding environments like Smalltalk had as “IDEs”
Xerox PARC workstations were the first IDEs, alongside Lisp Machines from Genera and TI.
BASIC >
I have to admit that I still judge programming tools, and in fact, entire computers, against the beloved BASIC prompt. You flipped a switch, got a BEEP, and 3 seconds later, you were in heaven.
Today the closest thing for me is firing up a PC and opening a Jupyter notebook. But it's certainly not the same.
You use a program called EDLIN that writes the line numbers for you, and even renumbers your lines automatically whenever you have to insert something in the middle of your program. It's really neat!
Are you sure you didn't have 640kB?
The PC could only be expanded to 64KB on the motherboard. Anything beyond that required expansion cards, each adding at most 64KB initially (which opened the door for larger third party upgrades from AST and others). With only six slots and separate cards for the floppy disk controller, video, serial and parallel ports the largest practical configuration was initially only 192KB. Not that the software could take advantage of all that (in the case of .com stuff quickly ported from CP/M, things improved with .exe).
When most people try to remember the original IBM PC they normally think of the 1983 PC XT (IBM 5160) instead which had more slots and more memory.
Around 1989 I was asked to fix a Basic program that tested car shock absorbers. It took me less time to write a new version in Turbo Pascal than it would have taken for me to completely read the source of the original program. The IDE made a huge difference but the speed was also important since it allowed me to modify and try several times per minute.
As a kid in the 80s, one of the standout images is of my father sat - motionless, absorbed - in front of a brilliant blue CRT.
I often think back on that fondly when I see my own son puzzling at what I might be doing on VS Code.
In high school, I ended up doing telephone survey work, mostly market research. We had to fill out these terrible timesheets so that clients could be billed for each call. Poking around, I discovered that the office had a PBX [1] to run all our phone lines. It was hooked up to a PC, and in the manual I discovered it would log every digit dialed, plus other events.
I talked my bosses into letting me mess with it. And then I convinced them to pay me some outrageous sum ($500, I think) to write Turbo Pascal software that would generate an automatic report every night replacing the timesheets. Given that I was making something like $5/hr (well above the $3.35 minimum wage), it seemed like a great double victory.
https://en.wikipedia.org/wiki/Business_telephone_system#Priv...
When I started on Java, I was disappointed at the quality of IDEs so much that I resorted to coding in Notepad instead. I was so used to the seamlessness of Borland IDEs. It was only when I did a 30-day trial of IntelliJ that I started using an IDE again.
I was trying to find out when these versions were released to see if I could line it up with the projects I was working on at the time, but I can't find a list of major releases with dates.
- https://www.jetbrains.com/company/press/press-archive/pr_111... - press release for 3.0, Nov 11 2002
- https://www.jetbrains.com/company/press/press-archive/pr_021... - PR for 4.0, Feb 11, 2004
(Found via `intellij idea "3.0"` and `intellij idea "4.0"`)
- http://web.archive.org/web/20030320181401/http://www.intelli... - announcement for 2.6, Jun 3 2002
- http://web.archive.org/web/20030210115005/http://www.intelli... - APPROX - download page offering 3.0.1, archived Feb 10 2003
- http://web.archive.org/web/20010223163551/http://www.intelli... - APPROX - download page for 1.0.2 (build 339), archived Feb 23 2001
(Started poking around inside IA by following the EAP link at https://wiki.c2.com/?IntellijIdea, which is helpfully woefully out of date)
- https://confluence.jetbrains.com/display/IDEADEV/Home has info back to 9.x (expand "88 more" on the left)
- https://www.jetbrains.com/company/press/press-archive/pr_151... - irrelevant but interesting FOSS release announcement, Oct 15, 2009
If more accuracy is needed, perhaps the relevant info will only be one or intermediate pages away from the above.
The application was table driven, all important configuration items were stored in a text file as a key-value pair. It had a bar-code scanner and was tied into a cash drawer. Receipts were printed on small dot matrix printer.
It took about 4 weeks to write.
The best programming environment ever.
Or it could be handled simply by listing "The Terminator (Beta)" and "The Terminator (VHS)" as separate titles.
If the sales tax ever changed, the owner could easily make that change as well. It had a built in rewards program, specials, sales, all editable in the text file.
Once the software was delivered I never touched it again.
There was no contact in either profile, so my choice was to post as a comment, or leave you unknowingly exposed
This particular comparison is interesting when you consider that the primary author of Turbo Pascal, Anders Hejlsberg, has been at Microsoft working on C# and TypeScript for quite a while.
Using Python with its Global Interpreter Lock seems like a total antipattern when it comes to use resources wisely.
That doesn't mean that lots of programs aren't bloated by overly complicated internal designs. Sometimes this is a concession to the development team structure. Sometimes this is incompetence. It is hard for me to tell from the outside.
I find all the squiggly lines and annotations that Resharper adds to the code quite helpful. These are a kind of low key way of indicating minor issues with the code. I find that appropriate for things like coding style violations because they often aren't an immediate concern because I want to get things working first. But they are a good reminder of the open cleanup work once that is done.
Sometimes I wonder whether this is somehow related to a quest for clean/simplified (or, as some might say, dumbed down) user experiences in other situations. Also, is this in general more of a thing in America compared to the rest of the world?
Nowadays, the same "database" in Free Pascal can be achieved with a simple "array of TCustomer" type that keeps everything in memory and is loaded/written to disk with a couple of lines of code. Computers are so fast that unless you have every single citizen of a European country as a customer, you can simply perform linear searches directly in RAM without touching the disk. If anything this approach would also be much faster than if the Turbo Toolbox approach was used on a modern PC.
Of course a lot of software is very inefficient but TBH i do not ever expect this to change since people will always value features and convenience above performance - even when they do not use said features themselves.
The touch command under OS X Lion (44,016 bytes).
...and I bet that one is dynamically linked.
I believe the reason why it's so fast is because it has no optimiser, and generates code as it parses. Pascal is also one of the easier languages to compile.
It's possible that the author is thinking of pre-TP4.0 chain files (which were used to get around the 64K memory limit of .COM format before TP switched to generating EXEs.)
$ bloaty `which touch` -d segments,sections --domain=file
FILE SIZE
---------------
55.1% 19.6Ki __LINKEDIT
91.7% 18.0Ki Code Signature
2.7% 544 Symbol Table
1.9% 376 Lazy Binding Info
1.6% 328 String Table
1.2% 232 Indirect Symbol Table
0.6% 112 Binding Info
0.2% 32 Export Info
0.1% 24 Function Start Addresses
0.0% 8 Rebase Info
0.0% 8 Table of Non-instructions
0.0% 0 [__LINKEDIT]
22.2% 7.90Ki __TEXT
35.0% 2.77Ki __TEXT,__text
33.6% 2.65Ki [__TEXT]
17.2% 1.36Ki [Mach-O Headers]
4.2% 339 __TEXT,__cstring
3.4% 274 __TEXT,__const
3.3% 266 __TEXT,__stub_helper
1.9% 150 __TEXT,__stubs
1.5% 120 __TEXT,__unwind_info
11.2% 4.00Ki __DATA
94.9% 3.80Ki [__DATA]
4.9% 200 __DATA,__la_symbol_ptr
0.2% 8 __DATA,__data
11.2% 4.00Ki __DATA_CONST
98.4% 3.94Ki [__DATA_CONST]
1.6% 64 __DATA_CONST,__got
0.3% 104 [Mach-O Headers]
100.0% 35.6Ki TOTAL
Those [__TEXT], [__DATA], and [__DATA_CONST] sections are the part that is lost to padding, so 10.4Ki or so.
Disclosure: I am the author of Bloaty.
It supports 8 different flags (plus an undocumented -? flag), with support for using absolute or relative times, setting various timestamps on a file, and options for dealing with symlinks and permissions and such. More features than I'll ever need, but not outrageously so.
On Mojave, this file is only 23392 bytes, so it's no longer bigger than Turbo Pascal. Plus, automatic filesystem compression shrinks this down to only 7340 bytes on disk. Since blocks are 4096 bytes, this is actually the second-smallest (non-empty) file!
[1]: https://opensource.apple.com/source/file_cmds/file_cmds-287....
One says "1988 Pascal", the other one "2018 Kotlin". I wrote those after noticing how similar the syntax is for variable declaration and it felt like going back to my roots.
The sheer joy of knowing your IDE, the language and the target platform all in one interface reminds me a lot of the days staring at the blue screen of Borland Turbo Pascal in the early 90s. I really missed it in all those years of web development I did afterwards.
The Terak was an interesting machine:
> The Terak 8510/a of 1976 or 1977 was among the first desktop personal computers with a bitmap graphics display. It was a desktop workstation with an LSI-11 compatible processor, a graphical framebuffer, and a text mode with downloadable fonts. Despite the lack of a MMU, it was capable of running a stripped version of UNIX version 6. It was the first personal machine on which the UCSD p-System was widely used.[1] Various universities in the USA used it in the late 1970s and early 1980s to teach Pascal programming. It provided immediate graphic feedback from simple programs encouraging students to learn.[1]
Also, in those days, we were running Version 7 Unix on a PDP 11/45, which supported several concurrent users in what would now be an unimaginably tiny 256K of RAM.
I still take on jobs to do embedded programming in assembly language on PIC or similar processors and my clients are usually amazed at what can be done in tiny amounts of code.
Adjusting for inflation, NASA spent $283 billion going to the moon[0]. I can't be bothered to find a breakdown of how much of that budget could be directly tied to writing code, but I suspect that the investment was a wee bit higher than a rando frontend dev slapping together some libraries in 2020.
[0] https://www.planetary.org/get-involved/be-a-space-advocate/b...
The microprocessor wasn't radically different from the 4 bit computer that I built on breadboards for my college electronics class, and I could tell you pretty much all of the things it could do.
Then the only limitation was you and your own wits.
Today, not only is there a language to learn, but libraries, and a framework, and an architecture, and a "stack" and revision control system... you can't ever master the whole thing and it's changing faster than the baud rate of my eyeballs. It's still a boatload of fun, but a new kind of fun, and sometimes I like going back to the old kind.
Technology degrades: https://youtu.be/pW-SOdj4Kkk
Then came C++, and I wasted A LOT of time trying to wrap my head around it while creating nothing of value before giving it up entirely.
My Pascal experience also landed me my first job after university, which was to help write/maintain a system developed in Delphi.
Learned C after that, but drifted away from programming (for a decade or so) around when C++ came out. I came back around to computers when I wanted to build myself a static website - and I'm still in the wondrous rabbit hole.
These days, much of my time is spent reading and writing TypeScript. How strange after all these years, I'm again speaking a language created by Anders Hejlsberg. It's a joy to work with VS Code editor as an integrated development environment, and I fondly remember my time with Turbo Pascal.
Long story short, I ended up looking into Pascal and using that tp3 "editor" to learn a bit of Pascal, which seemed a lot more fun than COBOL.
One other thing, it was so cheap and fast that people started using it as their text editor of choice. It would be interesting to know how many copies of TP were sold that never compiled a line of code.
I keep a private github repo called NVBC (NecroVisualBasiCon) with snippets of the all the madness that was trying to trick VBA into being a useful tool. The IDE was good, but the language itself was surgically precise in delivering 83% of what one wanted for a given task.
One thing I liked about pascal but missed in every language since is the ability to have arrays start from arbitrary values. It can be fudged in C/C++ pretty easily but still, be nice to have it built into languages like java/scala/so many more.
type Day = (Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday);
Days = set of Day;
const Weekdays = [Monday..Friday];
...
if Today in Weekdays then ...
...
Here are some of my favourites:
When I got my Amiga a year later I was happy that there was a Pascal compiler, then saddened that it only had stdio sort of interface. No way to open windows and draw things or the like. Luckily I found a FORTH that not only had a 68k assembler but also all of the constants and things you needed to write graphics and the bonus of making that single executable file.
Sorta sad I never really got to use Pascal after that. By university time it was all Assembly, FORTRAN and C for the CS classes.
Ha, I learned it via TP when I was 14 in 1994! So many dumb hijinks in that class. If there was somebody you didn't like, one thing you could do was space out past the end of line 1 of the program and just write END; in the 100th column or so. That made everything else in the file just a comment. There was no word wrap, so unless they knew how to page right, there was no way they'd ever figure it out!
I also wrote a 2-player pong game, but I knew the keyboard handler could only handle 3 keys at a time, so if you wanted to temporarily disable the other player at a key moment, you could just hold down three keys and shut him out.
Ah, good times.
When I was 14 and I first got access to a PC at school, Turbo Pascal was the first proper programming language I got access to. It got a compiler, strong typing, an IDE and a help page. Help page was invaluable since we didn't have Internet access nor did I owned Pascal books.
Pascal made me think anything is possible, from games to line of business apps. It provided low level access and I toyed with rebooting the PC and entering BIOS and bypassing BIOS password by writing to some hardware register.
My journey with Pascal didn't last much, as I discovered C and C++ which seemed even more amazing and flexible.
It was directly accessible from the DOS prompt with the MODE command.
Don't remember if TP had a library function that exposed it.
Turbo Pascal 5.5 and later had all MS-DOS graphical modes.
I guess it is time to go into archaeology trip to see how is right.
I am quite aware that intellisense is a Microsoft brand, just kept the same wording as the person I was replying to.
Thanks for the correction.
- Intellisense
- project-wide refactoring
- lookup into external code (IntelliJ idea can even decompile .jars)
- multi-language projects
- debugging (including stepping into external and decompiled libs) with watch values of nearly unlimited complexity
Language:
- lambdas/anonymous functions
- type inference
- extension methods
Turbo Pascal for Windows also.
Multi-language projects was a available in the full box Borland products, as one could get Borland C++ and Turbo Pascal together.
In fact the symbiotic relationships of Java/C++ and .NET/C++ can somehow be mapped to TP/C++.
If you take a look at later versions or even early Delphi, I'd say garbage collection. Other languages from the Wirthian family had it, like Modula-2/3 or Oberon.
Lambdas/first class functions.
Unicode support.
Syntactic sugar up the wazoo.
Other than that, I think one could be very productive in a TP 5.5-ish language even today. The rest would be mostly about the infrastructure and community, like IDEs, package management and Medium posts with lots of memes.
Coupled with nested subroutines, there was already a couple of things possible.
C and its descendants was such a step backwards.
PS loved turbo pascal. Everything I know about oop I learned from the manual for tp4. First job I ever had programming required using it, but even then it was being replaced by C.
Things missing in C: Bounds checking; Non-null references; Subranges; Sets; Nested functions?
Learning C after that experience was probably similar to how Bjarne felt being forced to leave Simula for BCPL.
It ran in an amber monochrome screen.
When I got a newer, faster computer, the colors were a bit under designed, and it ran too fast. =)
Good times.