I mentioned Lazarus in other threads a few days ago (since my kids are playing around with it) and it's great to see it as a top-level post. Some random thoughts:
- It's somewhat amusing to realize that in 2017 this is pretty much the easiest way to do a desktop app (besides RealBasic/Xojo which I've yet to try - was put off by their mandatory registration)
- I wish we had RAD environments like this for more languages (Racket, Python, etc. - even JS).
- On the Mac, installation is a bit fiddly. It needs a little polish and support (a standalone, integrated bundle would be better, or at the very least a unified installer).
- We've been retrofitting web UIs to desktops to such an extent (I'm looking at you, Electron) that the tiny, supremely efficient apps Lazarus spits out put the last couple of years into stark perspective (2GB RAM used by Slack, etc.)
I love Lazarus, and hope it helps resurrect the RAD approach for other languages - if anyone knows of any similar environments (besides QtCreator, etc.), could you share the links?
I've not used Lazarus or Delphi, so I can't really compare properly. Perhaps I'm missing something. But:
> if anyone knows of any similar environments (besides QtCreator, etc.)
Why "besides QtCreator, etc"? It sounds to me almost like "do you know any X besides all of the popular X". Is there any particular reason you discount QtCreator? Does it not work for your purposes? Or is it just a case of you already know about it and want to hear about more obscure tools?
> It's somewhat amusing to realize that in 2017 this is pretty much the easiest way to do a desktop app
I've found Qt with QtCreator to be an incredibly productive way to develop desktop applications. Both old-school QWidgets-based Qt with QtDesigner (the RAD portion of QtCreator for pre-QtQuick) and QtQuick/QML with and without its RAD interface.
> I wish we had RAD environments like this for more languages (Racket, Python, etc. - even JS).
I've used the Python version of Qt with QWidgets in the past and it was a pretty nice workflow. I've never done it personally, but I know of people who use Python + QtQuick/QML and seem pretty happy with it. There's also various "app builder" tools for JS, but I don't know how good they are.
"It's somewhat amusing to realize that in 2017 this is pretty much the easiest way to do a desktop app (besides RealBasic/Xojo which I've yet to try"
If you're interested in Basic programming then Gambas might interest you. Although not a clone of VB, it can be roughly considered being to VB what Lazarus is to Delphi: a 100% Open Source implementation.
I would prefer Lazarus anyway, but it's indeed nice to see different alternatives to proprietary dev systems.
As awesome as Lazarus appears to be here, Rebol is even more amazing in my opinion. There is no designer, but the GUI DSL is mind bending. Red is a Rebol inspired language that is also tiny with a compiler as well so you can build a nice cross-platform-native GUI and distribute it as a tiny executable (~1.5 MB). You can see the GUI stuff for both Rebol and Red. There's a YouTube video by Nick Antonnacio (spelling) that shows him building something like 40 GUI apps in an hour ranging from email apps to games like tic-tac-toe and snake...it was pretty crazy to see the first time.
I recently tried out Lazarus, and besides looking a bit dated, it works REALLY well. I had no Pascal experience so it was also overwhelming for a hello world app. But after the basic Pascal "Hello World" command line app, a GUI app didn't even require a tutorial to get working. Really impressed and am considering Pascal for a project.
For me as for the guy who only look at Lazarus not as developer, but as user who just go to compile map editor of our game (developed by other very skilled developer) main frustration was multi-windows interface.
Not that I can't understand why some would prefer to work in that mode, but that alone make it feel more dated than it's actually is. It's still weird why they still ship it in multi-window mode by default, but fortunately all you need to do is install "anchor docking" and then it's become a lot more usable for guys like me.
Also ability to patch and recompile your own IDE on the fly without waiting for half of hour to it to compile is just great. Nothing like that is possible in case of 99% C++ projects.
As soon as you need 3rd-party libraries "statically compiled" is no longer the case. Or at least it's not easy, depend on platform and still bring a lot of mess.
Though in the right hands Lazarus is a great tool since relatively complex project could be completed just by one developer. E.g here is our game engine map editor:
Another thing to note is that FPC provide good performance and even used for game development and memory footprint is small. There is RTS on Steam called Cossacks 3 and it's fully in Pascal (though no idea if they using FPC outside of Linux):
I have a rather different opinion on OP that it has a needlessly verbose syntax.
Pythonic it is definitely not. Even C# (which is another creation of Anders Hejlsberg, after MS poached him from Borland) has a better, readable and concise syntax.
I used to be a Delphi evangelist in it's glory days. Now I bristle when I read Pascal source code, there's so much unnecessary visual noise. Of course if your brain is habituated enough to parse Pascal code, eventually you will tend to filter out the begin..end's.
Pascal syntax belongs to C family of language.
As regards to Python-like syntax, I think you are referring to the Nim language, whose syntax happens to be similar to that of Pascal.
I've created small projects in Lazarus and you are right in all points except in the small binary part, also I would add that it comes with db drivers for Postgrees, MySQL and Firebird SQL out of the box.
No GC is actually an advantage?
The world really changed, there are people rejoicing for procedural languages, while we have so many excellent OO and FP alternatives, and they are actually happy to shoot their own foot with manual memory management.
I'm not really sure that the change has been for the better.
I would love to switch off Delphi, but I'm heavily dependent on spring4d which is Delphi only right now. I may build some smaller programs or utilities in Lazarus.
I've made the mistake to write a complex project in Free Pascal. As far as I can tell pretty much every release of Lazarus is breaking something.
And surprisingly often those breaks are major (like e.g. broken multi-threading, broken-strings, ...).
For me the whole thing looks more like a playground for hobbyists and is not really useful for anything productive.
There's not much continuity in the language. And for the devs something like 95% compatibility seems to be good enough.
For small projects it might be ok to use, but you better keep your snapshot of the compiler locked in a safe place.
On the other hand: If you're young and want to make history as the guy who replaced all those begin/end in pascal with smileys: This project might be your chance...
I work with a multi-mloc application in fpc. We have migrated the code over many compiler versions with hardly any issues at all.
With every update they post a list of things breaks compatibility, and if you are affected, the refactoring tools are almost always enough.
We had two tries at a full recompile migrating from 2.6.something to 3.0.2, and passed all tests within 13 hours of starting the process. (some of the larger stuff were however already fixed since we keep a close eye on the development).
Your project was probably doing something wrong or weird since the Lazarus and Free Pascal developers have gone to great lengths to avoid breaking backwards compatibility - i have code from 10 years ago that compiles almost without changes. The only change that i have to do is when i abused strings as byte buffers that wouldn't work in Free Pascal 3.0. However that was something the FPC developers said for years and they made several release candidates so that people can report back issues. Even then the change was simply replacing all uses of `string` with `rawbytestring`.
The only backwards compatibility breaking they do is when they are fixing compiler bugs that shouldn't be used anyway. For example at some point it was possible to take the address of a property getter and this usually worked, but not always. They changed that to be illegal (according to the language reference it was illegal anyway) so any code that relied on that would need to change (a simple change would be to make a new property or function that gave back the address of the private reference and mark it as inline so that you wont get any performance penalty).
Personally i am very anal about backwards compatibility and i have abandoned tons of libraries (SDL, GTK, Qt, etc) because of that. In my experience Free Pascal, LCL and Lazarus are among the most stable frameworks to the point that they prefer to keep unnecessary things around for years just in case someone is still using them or introduce unnecessary options for the framework to change behavior in case someone is still relying on the old one (this is why for example you get a `RequireDerivedFormResource:=True;` line in new projects, older projects wont have this line which affects the behavior of how forms are created).
Obviously i don't know what your project was doing but you don't really provide any description (both of the issues you mentioned i haven't encountered), so i put my counter-experience here since i wouldn't like people to get the impression that Lazarus doesn't care about backwards compatibility. For me it is a prime example of a very complex project doing backwards compatibility right (hell, the Lazarus IDE itself can even be compiled with Free Pascal compilers that are years old just in case someone might for whatever reason - like the few cases mentioned above, or use FPC from some Linux distribution that only has old versions - be stuck with them). Things that break backwards compatibility are considered important bugs and are fixed - sometimes even at the cost of getting things "right".
Broken multi-threading, broken string, ...
Care to elaborate? UTF8 move perhaps? Which native compiler/RAD got UTF8 for free? Virtually every C/C++ project was "broken" in that respect at some point or even now.
I use both Lazarus & FPC from trunk (in between releases) and even then backward compatibility is of top priority to FPC devs.
I have had best success by using the (very stable) version provided in (X)ubuntu LTS, which I'm always staying with, so I'd say it is about finding a good strategy for version selection.
I like your comment. It highlights what misses from so many discussion about languages/tools down here. Being expressive, powerful, compiled, interpreted doesn't matter much if long term stability, reliability, backward compatibility are not a top goal for the devs.
Btw, OmniPascal for VSCode is also worth a mention as an alternative for quick edits, or for coding those CLI apps in pure FPC. A really nice project, which also helps showing that Pascal is Alive and Kicking :)
One of the things I'm excited about, is using FPC/Lazarus as GUI for computationally heavy Go code (Now with the recent efforts to use Go for datascience ... see http://gopherdata.io), now since Go supports shared object (.so/.dll) files.
I collected my (very early) research on it in this thread:
A bit funny seeing this on here tonight. My teenage daughter was looking to create a native desktop app and I pointed her to Lazarus just today. Then I login and check Hacker News...
While we're at it, for those times when you're hacking on console apps, FreePascal also has a very nice text-mode (TUI) IDE that is basically a Turbo/Borland Pascal 7.0 IDE clone - but cross-platform.
To do that, they had to port Turbo Vision (or rather its open source fork Free Vision). It's still a great TUI library... it's a shame it's Pascal-specific. Would be interesting to have an implementation of it for, say, Python, for system tools and the like.
I use Free Pascal at times. In case there are any FP developers here: your build arrangements hamper my use. I tried installing earlier this week from source and could not get it going.
My ideal would be a single configure/Makefile combination in the root directory. Consider if the user does not have root, how are they to set a prefix?
The idea of the 'build' download is good, but not if it needs to link to recent shared-objects. Particularly recent shared objects like libc. Maybe you could put statically-linked tools in the 'build' version.
I guess you need to contact devs to clarify.
I regularly build from sources for Linux and cross-compile for Windows both x32 and x64 using just single "make ..." command.
For the FPC/Lazarus project as a whole, it is also good news that there is some work going on to build up a foundation (it exists already), with funding and stuff, to support further development:
I'd definitely use it more if I could port over the last few Delphi apps I have in production. My Delphi 7 is getting a bit old...
Aside from single-file executables, the biggest advantage to Lazarus (and also Delphi) [to me] is that all the libraries are also built in the language. No needing to bounce down to opaque DLLs just to display some GUI element.
Lazarus is awesome because of the speed of the compiler, the fact that it has a GUI that works, and is OPEN SOURCE.
So one wonders WTH is going on with all the other compiled languages that have nothing like this? And no QT is not the answer, we need a built-in good enough GUI! =)
I see Lazarus pop up on HN occasionally. It's an IDE for FreePascal right? I guess I'll have to open the article again. How are the database drivers? I've been told they're ageing. Is there 64 bit support for Windows or only 32?
We've updated the description from “Proving That Pascal Is Alive and Kicking Ass”. Submitters: the guidelines ask that you please don't editorialize titles.
[+] [-] rcarmo|8 years ago|reply
- It's somewhat amusing to realize that in 2017 this is pretty much the easiest way to do a desktop app (besides RealBasic/Xojo which I've yet to try - was put off by their mandatory registration)
- I wish we had RAD environments like this for more languages (Racket, Python, etc. - even JS).
- On the Mac, installation is a bit fiddly. It needs a little polish and support (a standalone, integrated bundle would be better, or at the very least a unified installer).
- We've been retrofitting web UIs to desktops to such an extent (I'm looking at you, Electron) that the tiny, supremely efficient apps Lazarus spits out put the last couple of years into stark perspective (2GB RAM used by Slack, etc.)
I love Lazarus, and hope it helps resurrect the RAD approach for other languages - if anyone knows of any similar environments (besides QtCreator, etc.), could you share the links?
[+] [-] dkersten|8 years ago|reply
> if anyone knows of any similar environments (besides QtCreator, etc.)
Why "besides QtCreator, etc"? It sounds to me almost like "do you know any X besides all of the popular X". Is there any particular reason you discount QtCreator? Does it not work for your purposes? Or is it just a case of you already know about it and want to hear about more obscure tools?
> It's somewhat amusing to realize that in 2017 this is pretty much the easiest way to do a desktop app
I've found Qt with QtCreator to be an incredibly productive way to develop desktop applications. Both old-school QWidgets-based Qt with QtDesigner (the RAD portion of QtCreator for pre-QtQuick) and QtQuick/QML with and without its RAD interface.
> I wish we had RAD environments like this for more languages (Racket, Python, etc. - even JS).
I've used the Python version of Qt with QWidgets in the past and it was a pretty nice workflow. I've never done it personally, but I know of people who use Python + QtQuick/QML and seem pretty happy with it. There's also various "app builder" tools for JS, but I don't know how good they are.
[+] [-] squarefoot|8 years ago|reply
If you're interested in Basic programming then Gambas might interest you. Although not a clone of VB, it can be roughly considered being to VB what Lazarus is to Delphi: a 100% Open Source implementation. I would prefer Lazarus anyway, but it's indeed nice to see different alternatives to proprietary dev systems.
http://gambas.sourceforge.net/en/main.html
[+] [-] alex-e|8 years ago|reply
https://eul.im
It's only 4 MB and uses ~100 MB RAM.
[+] [-] throwaway7645|8 years ago|reply
I'm checking out Lazarus currently.
[+] [-] thro1237|8 years ago|reply
[+] [-] oregontechninja|8 years ago|reply
[+] [-] SXX|8 years ago|reply
Not that I can't understand why some would prefer to work in that mode, but that alone make it feel more dated than it's actually is. It's still weird why they still ship it in multi-window mode by default, but fortunately all you need to do is install "anchor docking" and then it's become a lot more usable for guys like me.
Also ability to patch and recompile your own IDE on the fly without waiting for half of hour to it to compile is just great. Nothing like that is possible in case of 99% C++ projects.
[+] [-] samuell|8 years ago|reply
[x] Statically compiled
[x] Native UI on Linux/Mac/Win
[x] Typically compiled without code changes on Linux/Mac/Win
[x] Small binaries
[x] No GC
[x] Readable, somewhat python-like syntax
[x] Still, doesn't rely on indentation for nested blocks
[ ] (Fill in)
[+] [-] SXX|8 years ago|reply
Though in the right hands Lazarus is a great tool since relatively complex project could be completed just by one developer. E.g here is our game engine map editor:
https://github.com/vcmi/vcmi_editor
Another thing to note is that FPC provide good performance and even used for game development and memory footprint is small. There is RTS on Steam called Cossacks 3 and it's fully in Pascal (though no idea if they using FPC outside of Linux):
http://store.steampowered.com/app/333420/Cossacks_3/
PS: Another example would be open source Hedgewars of course.
[+] [-] brass9|8 years ago|reply
I have a rather different opinion on OP that it has a needlessly verbose syntax.
Pythonic it is definitely not. Even C# (which is another creation of Anders Hejlsberg, after MS poached him from Borland) has a better, readable and concise syntax.
I used to be a Delphi evangelist in it's glory days. Now I bristle when I read Pascal source code, there's so much unnecessary visual noise. Of course if your brain is habituated enough to parse Pascal code, eventually you will tend to filter out the begin..end's.
Pascal syntax belongs to C family of language.
As regards to Python-like syntax, I think you are referring to the Nim language, whose syntax happens to be similar to that of Pascal.
[+] [-] geff82|8 years ago|reply
I like how you say python-like syntax... as so many borrow from Pascal
[+] [-] adrianlmm|8 years ago|reply
[+] [-] tigershark|8 years ago|reply
[+] [-] mmargerum|8 years ago|reply
[+] [-] generic_user|8 years ago|reply
[+] [-] WildParser|8 years ago|reply
For me the whole thing looks more like a playground for hobbyists and is not really useful for anything productive. There's not much continuity in the language. And for the devs something like 95% compatibility seems to be good enough.
For small projects it might be ok to use, but you better keep your snapshot of the compiler locked in a safe place.
On the other hand: If you're young and want to make history as the guy who replaced all those begin/end in pascal with smileys: This project might be your chance...
[+] [-] Johnny_Brahms|8 years ago|reply
With every update they post a list of things breaks compatibility, and if you are affected, the refactoring tools are almost always enough.
We had two tries at a full recompile migrating from 2.6.something to 3.0.2, and passed all tests within 13 hours of starting the process. (some of the larger stuff were however already fixed since we keep a close eye on the development).
[+] [-] badsectoracula|8 years ago|reply
The only backwards compatibility breaking they do is when they are fixing compiler bugs that shouldn't be used anyway. For example at some point it was possible to take the address of a property getter and this usually worked, but not always. They changed that to be illegal (according to the language reference it was illegal anyway) so any code that relied on that would need to change (a simple change would be to make a new property or function that gave back the address of the private reference and mark it as inline so that you wont get any performance penalty).
Personally i am very anal about backwards compatibility and i have abandoned tons of libraries (SDL, GTK, Qt, etc) because of that. In my experience Free Pascal, LCL and Lazarus are among the most stable frameworks to the point that they prefer to keep unnecessary things around for years just in case someone is still using them or introduce unnecessary options for the framework to change behavior in case someone is still relying on the old one (this is why for example you get a `RequireDerivedFormResource:=True;` line in new projects, older projects wont have this line which affects the behavior of how forms are created).
Obviously i don't know what your project was doing but you don't really provide any description (both of the issues you mentioned i haven't encountered), so i put my counter-experience here since i wouldn't like people to get the impression that Lazarus doesn't care about backwards compatibility. For me it is a prime example of a very complex project doing backwards compatibility right (hell, the Lazarus IDE itself can even be compiled with Free Pascal compilers that are years old just in case someone might for whatever reason - like the few cases mentioned above, or use FPC from some Linux distribution that only has old versions - be stuck with them). Things that break backwards compatibility are considered important bugs and are fixed - sometimes even at the cost of getting things "right".
[+] [-] MageSlayer|8 years ago|reply
I use both Lazarus & FPC from trunk (in between releases) and even then backward compatibility is of top priority to FPC devs.
[+] [-] samuell|8 years ago|reply
[+] [-] wiz21c|8 years ago|reply
[+] [-] samuell|8 years ago|reply
http://www.omnipascal.com
(Only issue is Linux support is not (yet) on par with Windows and Mac ... but then, it is open source, so that could change!)
[+] [-] Zablus|8 years ago|reply
What's about Linux support? It's working on all platforms, isn't it? http://blog.omnipascal.com/omnipascal-0-14-0-mac-and-linux-s...
[+] [-] samuell|8 years ago|reply
I collected my (very early) research on it in this thread:
https://forum.lazarus.freepascal.org/index.php?topic=24948.0
... where some users report they tried it already. Seems to work, if not super smooth. Hope it can be improved in the future.
[+] [-] whitea|8 years ago|reply
It has DDD, SOA, MVC, ORM (even for NoSql), REST, caching, logging and security features and works with Lazarus.
[+] [-] zoom6628|8 years ago|reply
[+] [-] bigtunacan|8 years ago|reply
[+] [-] int_19h|8 years ago|reply
To do that, they had to port Turbo Vision (or rather its open source fork Free Vision). It's still a great TUI library... it's a shame it's Pascal-specific. Would be interesting to have an implementation of it for, say, Python, for system tools and the like.
[+] [-] pjmlp|8 years ago|reply
It was later available in C++ as well, and there is a port available.
http://tvision.sourceforge.net/
[+] [-] tomc1985|8 years ago|reply
[+] [-] pjmlp|8 years ago|reply
[+] [-] pvg|8 years ago|reply
[+] [-] jenkstom|8 years ago|reply
[+] [-] cturner|8 years ago|reply
My ideal would be a single configure/Makefile combination in the root directory. Consider if the user does not have root, how are they to set a prefix?
The idea of the 'build' download is good, but not if it needs to link to recent shared-objects. Particularly recent shared objects like libc. Maybe you could put statically-linked tools in the 'build' version.
[+] [-] MageSlayer|8 years ago|reply
[+] [-] samuell|8 years ago|reply
https://foundation.freepascal.org/
Among founders being Delphi luminaire Boian Mitov (author of Visuino / OpenWire / OpenWireStudio etc).
Hoping the foundation can take off with some good funding.
[+] [-] scardine|8 years ago|reply
Shameless plug: if you think you are up to the task and is not too expensive contact paulo at xtend.com.br
[1] http://acbr.sourceforge.net/drupal/
[+] [-] Jack4E4B|8 years ago|reply
[+] [-] rgacote|8 years ago|reply
Aside from single-file executables, the biggest advantage to Lazarus (and also Delphi) [to me] is that all the libraries are also built in the language. No needing to bounce down to opaque DLLs just to display some GUI element.
[+] [-] samuell|8 years ago|reply
http://castle-engine.io/modern_pascal_introduction.html
[+] [-] fithisux|8 years ago|reply
https://sourceforge.net/projects/mseide-msegui/
It is a pitty dev pascal didn't catch up or ported to FPC.
[+] [-] dvfjsdhgfv|8 years ago|reply
[+] [-] Jack4E4B|8 years ago|reply
So one wonders WTH is going on with all the other compiled languages that have nothing like this? And no QT is not the answer, we need a built-in good enough GUI! =)
[+] [-] necessity|8 years ago|reply
[+] [-] jcelerier|8 years ago|reply
what do you call built-in ?
[+] [-] throwaway7645|8 years ago|reply
[+] [-] systems|8 years ago|reply
[+] [-] 0xbear|8 years ago|reply
[+] [-] sctb|8 years ago|reply