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.
Github has some repos but mostly dumps of old Delphi projects, not really a great resource.
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 2268I 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.
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.
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.
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...
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...
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.
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.
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.
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!
One try to sell you something, the other had an idea for a language he started to work on over the holidays.
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.
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.
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.
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.
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.