I was tasked with building a small utility for copying out a few GB of files from a super-complicated folder structure, and convert it into a different structure, with the requirement that it should have an interactive GUI (to do various selections interactively), and run natively on Windows and Mac.
Couldn't have found an easier route than to build this in FPC with Lazarus.
Even though I had hardly coded a line in the language before, it was built from scratch to "happy end-user" in 80 hours, including learning the language.
I built it on Xubuntu, then imported it on my Windows VM and compiled, WITHOUT A SINGLE CHANGE! On Mac, I needed to add a missing import statement or so.
Simply an outstandingly productive tool for open source, cross-platform GUI development.
Btw, a shoutout to the awesome OmniPascal project, which allows you to write Delphi and FreePascal in the Visual Studio Code editor (when you are not building GUI apps, and and/or don't need a full blown visual IDE, or just for navigating around in legacy code bases): http://www.omnipascal.com
Unfortunately, code completion is so far only available on Windows [1], but will hopefully come in due time (you can vote for the issue in [1]).
It's amazing to see how fast VS: Code is picking up extensions with full autocomplete, go-to definition, and other IDE-styled features. Atom's equivalents are rarely as nice, unless you're using Nuclide because they wrote their own damned framework inside the editor to achieve those features! I think it's because VS: Code's APIs are built around exposing those sorts of features nicely and simply.
- OCaml [0]: IntelliSense, go-to-definition, interactive debugging. This plugin is so well done that I feel VS Code is the best editor for my OCaml work now!
- Nim [1]: IntelliSense, go-to-definition, linting, Nimble building integration
- Purescript [2]: IntelliSense, compilation, linting, quick fixes for common errors, and type inspection
Seriously, more and more are added every day, which is just awesome. I'm still annoyed at small UI parts of VS: Code, but honestly the functionality and speed make it second to none in my opinion.
---
(Correction: A few hundred GB of files actually ... an extraction took like 7-8 hours in total, so the progress bar was kind of crucial for the users :) )
Nice little intro, everything there would compile fine with Free Pascal on Linux, Windows or OSX
BTW Shoutout to the FreePascal/Lazarus team, the improvements over the past 12 months have been great and finally convinced me to make the move from Delphi. I even created my first Real Linux desktop program two months ago to replace an XP status display screen in a factory.. A real big step for me :-)
This is interesting - I knew work was ongoing on FPC/Lazarus - but not so much that it might draw people away from Delphi. Could you say something more about what you used to miss, that's now available - and how you use Delphi/Pascal?
The gossip now is that only 8 people are left on charge of it:
Paul said
>2016/06/24 at 21:14
>Yes and here some hot news.
>Delphi and C++Builder Team now is only 8 developers
>IDERA contract free lance developers without experience in >Delphi and pay per job
Is ironic, but in one of the oldest forums of Delphi (where I'm moderator) some of us have left the language long ago (or more exactly, use it sparly), yet still are there!
So the thing is Delphi improve a lot, yet is mismanaged, cost too much, the only way to get bugs fixed is buy next version and each few months yet another company buy it.
The thing is so crazy that some people are considering seriously do a buy from the community (ie: Pay money to buy the product)...
I use Delphi XE2 and Lazarus 1.6 daily and I now prefer Lazarus due to a variety of reasons.
The main reason is that there are no more grey areas of my code, if something doesn't work, the documentation is missing or doesn't work the way I like, then right-click find the declaration and look at it or change it. This includes the IDE. For someone used to GPL it is no big thing but as a Delphi Programmer it is close to magic.
Portability is awesome. Being able to write your program in Lazarus Windows and then open it in Lazarus in Ubuntu and it just runs is amazing the first time you see it as a Delphi programmer.
The hardest part is migrating when you have third party components. Unless you can get the source code or a free pascal version you're stuck. I have an 85K line wine management system written in Delphi but it uses a lot of third party components so it is never going to just open and re-compile, however I have gone through changing a touchscreen module and it looks and feels the same except it also works in Linux!
Lastly I tend to agree, Delphi was badly mismanaged. For example I had to re-install XE2 on my new Windows 10 PC and I had to go through the most horrible install process getting it activated as it took 3 goes and required emails to support to prove I paid for it, the Official Delphi Forums are just about dead and there is still no free version which means nobody is ever going to learn it.
Note that I have not tried the most recent Delphi versions, but Lazarus 1.6 out of the box is much more stable than Delphi XE2.
The mismanagement debate is almost a separate topic!
There was massive pressure in the 2000's to convert to .NET and C# from corporate managers, auditors and customers, I never understood how this became such a force but In 2005 it was intense to the point of paranoia and a lot of my colleagues converted (Delphi 8 sealed the deal in most cases). Needless to say most are now very happy with C#. if I had stayed an employee and not gone independent at the time it would have happened to me.
As of now I am very happy with my decision to stay with Pascal, Delphi XE2 compiles my legacy code fine even with Windows 10 and All new developments are in Lazarus giving me the ability to support Linux/BSD and ARM processors which more customers are coming to appreciate.
Wonderful! I've long been a fan of end-of-life Turbo Pascal and Object Pascal thereafter. I love the language's simplicity, type safety, and speed. To my eye, Object Pascal is the goto language for minimalist OOP. In the spirit of C, it's short, sweet, and sufficient.
I worked with different versions of Delphi for 7 years. I miss it sometimes. The language was quite good, but people would always judge it because of the IDE that made it "too easy"
I started programming "for real" with Turbo Pascal (5.5 probably) while in high school. It was easy to copy it for personal use from there. Although later I actually went and bought Borland Pascal 7.0, a big and fairly expensive box with the disks and lots of books inside. I think I wanted it to be able to create Windows applications, but ended up hating Windows, so really only utilized a little of its potential..
I saved my money and bought a copy of Turbo C. Before that, I used both Basic (first on the TI 99/4A then on QBasic) and Pascal (on computers in schools) with some Logo, Icon, and later AutoLisp (for AutoCAD).
I really liked Pascal and I always thought it was somewhat unfortunate it didn't survive outside of a small programming niche.
But why. I don't understand why you'd use Pascal today when you could use C++. I jumped over 25 years ago and never missed Pascal the language, only the Turbo Pascal development environment. Many languages later I still have never wanted to go back and write in any Pascal variant. It's a verbose, weak, and inexpressive language.
Compared to any other OOPL, C++ is simply ghastly -- a grossly overcomplex mishmash of hacks in the key of C inspired to repent for the multitude of sins that historically bedeviled C, and have since led to a never ending cascade of ill-fated hacks to shoehorn a nearly 50 year old unsafe high level assembly language into the guise of a modern type safe OOPL. History has since shown this to have been a tragically quixotic quest which inevitably and catastrophically spun wildly out of control, mutating and metastasizing into a disgusting chimeric monster that now strikes fear and loathing into the soul of even the most stouthearted digital denizen, who only when lit by the faint glow of a failing CRT, oft have been heard to admit furtively and only under duress in the faintest of whispers:
Reading through the docs, it was nice seeing that Pascal wasn't sitting still through all the these years. Generics, extension methods (class helpers) and value types - though the last features actually existed way before class, and I've extensively used it back in the day, old style objects are unsafe and were abandoned for a while without being fixed.
Too bad that memory management is still tedious and categorically unsafe with all sorts of crazy hacks like a TComponent hierarchy and reference counting that exists only for interface.
It was a reasonable trade-off for me back in the days where the best thing C++ had was auto_ptr and a bunch of incompatible vendor specific classes. Nowadays, it's a world I wouldn't want to come back to (or I would happily programming C).
A note about the second link's table: Free Pascal since version 3.0 does have native unicode support. In fact it has native support for any encoding and it does on-the-fly conversions between different encodings without the programmer having to pay any special attention (but you can use different string types, such as utf8string, if you want the in-memory data to be in a specific encoding).
C++ has also had native unicode support for a while now (made standard in C++11). The table complains that indexing is byte-based, but that's arguably better than the deceptive UTF-16 based indexing many languages have, since UTF-16 code units are not equivalent to unicode code points. Even UTF-32 code points are not equivalent to composed characters or visible gylphs, so character-based indexing makes very little sense unless you're using a Unicode-specific library.
I also wonder why C++ is claimed to have no instance function pointers even though std::bind was available since TR1 and boost::bind was available aeons ago. Did the author confuse C++ style function references with C function pointers? But this is like confusing the C++ std::string (which exist only as a library feature) with C-style char arrays.
I agree about the IDE of Turbo Pascal, but Delphi 1.0 was pretty RAD too. Only thing I don't like about Pascal of 20 years ago was the lack of proper lists and dictionaries, and the tedium of writing long keywords like begin and end all over the place.
Ah, the days when I typed "begin" and "end" at the speed of puting a curly brace.
Don't actually feeling the need to go back though. It's not about language properties anymore, but the library ecosystem. I hated when anything useful in Delphi was a C dll port. You're never a first class citizen.
Good to know that many things are native Pascal nowadays, even some great Pascal people choose to either write from scratch or native porting instead of writing wrappers. Personally I don't mind using wrappers, but having native Pascal counterpart is better in the long run since no 3rd party implementation dependency required, things can be fixed and improved right away.
If only programming had gone that way. It almost did. The original Macintosh was programmed mostly in Apple Pascal. Wirth's original Pascal had some serious limitations, which led to far too many Pascal variations. Unfortunately, none of them won out over C.
Let me give you just one example adding to the other comments. In Turbo/Borland Pascal, you could declare global variables (including arrays) allocated at a specific memory address, e.g.:
var video: array[0..4000] of byte absolute $B800:0000;
It also had a special modifier for functions, that made them work as interrupt handlers. And inline assembler with nice, readable syntax that allowed addressing variables directly.
Consequently, it was actually easier to do most low-level DOS hackery in Pascal rather than C.
So yes, I'd expect it do just fine for drivers, as well.
"Consequently, it was actually easier to do most low-level DOS hackery in Pascal rather than C."
I remember downloading source code in the mid 90s of various DOS graphics effects from the demoscene, and being surprised how much of it was in Pascal. And also frustrated, because I'd gone with Turbo C++ instead & had to try porting the code across myself.
Of course. And the "limitations" of pascal is a larger-than-life myth! Is like judge C from how it was at the first release.
By the time of TurboPascal the things was great. The peak was around Dephi 3 and it was possible to circle around C/C++ all day long, barring, obviously that the market share and ecosystem was bigger for C/C++ so that answer why you "cant'" do some stuff. Because was not implementation or library for it, NOT BECAUSE THE LANGUAGE.
Sure... somewhere I have book that covered writing a full blown multi-threading "OS" in Turbo Pascal.
In the late 80's I wrote a framework that allowed multi-user games (via dial-up) to be created. Included 256 color graphics, mouse input etc... had fun fighting IRQ conflicts etc. Good times :)
This is like a blast from the past. My first interaction with programming was with Borland Delphi 6 which had its own dialect of Object Pascal. Poor internet connection and no stackoverflow had me figuring out programming on my own, mainly by using Delphi's help books and looking at code examples. Which is probably why I eventually lost interest - I couldn't figure out complex OP concepts on my own at that age.
Fast forward to the present, I really envy the people learning programming today for the first time. The amount of possibilities and resources now is many orders of magnitude bigger, making learning so much more enjoyable.
I had a memory lane trip few months ago. Got to run turbopascal 7.0 in dosbox. It's an amazing piece of software. The included help is great. And the language was deceptively simple. I didn't understand the value of intervals, set types, even ordinals (succ and prec)... Pretty neat.
Small sidenote: even QBasic was amazing for a free code environment in these days. The language is bare, but QBasic had some form of modularization. I thought nothing of it at the time, but it feels they tried to make people think in terms of isolated "objects" not large source files full of global variables.
QBasic was what I started on. Built my original hacking tools and 4GL prototype in it. The semi-memory safety, simple syntax, and rapid compilation let me iteratw stuff out quickly.
Does anyone use Pascal for web development (cgi, dynamically generated web sites)?
I would love to use a fast, low-memory, natively-compiled, strongly typed language with a clear, readable syntax. Pascal meets all these requirements.
Golang is the other language I'm considering. It has many web-related libraries, excellent documentation and a lot of momentum. Free Pascal, unfortunately suffers from fragmented documentation (the wiki is often out-of-date and hard to navigate). Despite that, I still prefer Pascal syntax over Go (yes, really).
So, if you are using Pascal for web development, what has been your experience? Would you recommend it?
The IDE/compiler/web server used in Elevate Web Builder were written using Delphi. We've also written two small database engines, as well as two ODBC drivers and a .NET data provider, using Object Pascal and Delphi. Object Pascal is a very versatile and useful language that allows you to write applications that do just about anything from front-end UIs to back-end server code. Being able to debug server-side code in the IDE is a life-saver and allows one to get to the root of any coding issues immediately.
FreePascal is also equally nice, albeit a little rougher around the edges in certain places. But, every year it gets better and more polished and has come a very long way since its humble origins.
I'm considering building a high performance pascal wrapper around libuv, which should let me get the same pipeline performance that you can currently get out of asp.net core's "kestrel" web server. In a word, fast. Right now if people are using Indy as their HTTP component they will first of all have some strong limitations on what they can do with certificates and https, and secondly they will not have a very fast stack.
Agreed, I couldn't recommend mORMot more! Several more notes:
- The docs for mORMot is very much lengthy and is not written by a native English speaker, you might feel overwhelmed getting started by reading it, but actually it's very simple to start, with the supplied 33 samples: https://github.com/synopse/mORMot/tree/master/SQLite3/Sample...
- Check the commit logs of its github repository, see how active the development is.
- The FPC/Lazarus foundation (http://foundation.freepascal.org/) was launched several days ago, check the Projects menu - you can expect a lot of modern language features would be added.
- The newpascal.org site was launched recently to get you started easily for Linux web development with mORMot/Lazarus
I do. I don't use CGI, though. As I find the embedded web server is more reliable. However, changing between CGI, FastCGI amd embedded server is a matter of changing a single uses clause entry.
It's applicable for both the preshipped fpWeb and Brook, which is my choice of web framework due to its simpler and shorter hand coding.
The feature you really want for web-development is closures. I can't imagine writing event-handling code without them. As far as I know, Pascal does not have closures.
Unfortunately, with closures you need good memory handling. And this means either a complicated type-system such as Rust's, or a garbage collected environment. The way C++ does closures is too dangerous for event-driven code, imho.
I never need a closure. You need a shift in thinking, closures are much heavier than ordinary procedures, at least in Golang (yes, this is a real world experience).
Delphi has closures, FPC is on development, but in the end I won't use it much. I need performance and maintainability, closures are against those two.
1. You don't need closures at a language level to do event callbacks. Just the ability to refer to functions by reference and call those references. Closures certainly make it syntactically nicer, but you can work without them.
2. You don't need event callbacks in a webserver to make it performant. The memory/CPU overheads needed to make closures work are essentially identical to what's needed to make blocking threaded code work, as long as the threading is done in userspace and you have support for expanding stacks. Even if you don't have support for those niceties, modern kernels and hardware are perfectly capable of handling thousands of OS-level threads.
Manual memory management is the weak point of Pascal. It limits functions to never returning newly constructed objects, which really limits the expressiveness of APIs both in the standard library and in custom code.
The manual reference counting system in old objective-c provides a better solution which while still cumbersome, doesn't prevent good powerful APIs.
The automatic reference counting capability of Delphi interfaces always seemed like a good idea to me, but seems to be rarely used.
> It limits functions to never returning newly constructed objects, which really limits the expressiveness of APIs both in the standard library and in custom code.
How? Set the return type of the function to be the object type you want, then result := TYourObjectType.Create; and you'll return a newly constructed object.
Note that Free Pascal does have automatic reference counting for interfaces, although it is not a good idea to use it for memory management because (like with Delphi) it is very easy to pass around an instance that isn't counted and end with memory leaks.
However one of the compiler's designers has an experimental branch which allows you to mark classes as being automatically managed and any instance and use of those classes becomes reference counted. So at some point it might become part of the main compiler (although it is probably far from now since AFAIK it isn't something people really ask for from FPC and there are other things to do).
Interesting with the new FreePascal and Lazarus foundation, which was just started a week ago, to support development of it as an alternative to Delphi [1] (Source [2])
I assure you, it can. Be it through API, custom socket protocol, bindings, no problem. When one doesn't exist yet, creating yourself is not a big deal.
It's a nice thought, but Pascal's age and its verbose (but highly readable) syntax means that many programmers will never give it more than a passing glance (regardless of the modern features it has to offer).
Age and verbosity has imho no influence. I'd rather say the following points are important:
- the project is not on github, issue tracker looks like from 2 centuries ago, ditto website, several different forum (maillists) instead of e.g. one discourse instance for the 'whole pascal project'
- the granularity of the code libraries is difficult (compiler, rtl, component sets (ui and non-ui), tools, lazarus, web, ...). You cannot just clone one of these parts and work on it
- no (fully supported) Cocoa support and thus the Mac platform is a bit handicapped (32bit Carbon), too many obscure legacy platforms, too many options, too complicated
- no modern defacto standards, e.g. md/rst formatted docu, different syntaxes/dialects (fpc, delphi, mse, oxygene, smartpascal, etc...)
- iirc license situation is a bit 'chaotic' (some LGPL 2.1 (with exception), some GPL 2 (3?), some MPL 1.1/2, more?) and in comparision to newer languages, e.g. go/rust (MIT, APL) the licenses are more (copyleft) restrictive. I like that more modern environments dropped ideological for pragmatic
- afaik no big company/organization invests money into the pascal ecosystem (if this were the case, probably most of the points above would be different)
This is just to say why I think it is not more popular, I very much appreciate the project/work, it's great!
The forums (and I think wiki) etc are astonishingly up-to-date though in my experience, and I have mostly got a useful answer in the forum within an hour or so, so I would say, don't judge the book by the cover :)
Last time I've been programming on Pascal was almost 20 years ago, just before I've learned Java. The Delphi was a breakthrough in 90s, but today, when we have MLoC-size apps, this language is just too outdated, fighting the wars of the past and preserving some unnecessary legacy. Memory management? Dependency management? Reflection and generative programming support? There are some things, of course, that are still nice to have in languages like Java (I liked the class helpers), but, thinking about development productivity and code quality, I'm not sure this can be called anything else but a steampunk toy, as modern as contemporary replica of some Art Nouveau thing.
If you haven't touched Pascal in 20 years you should refrain from making comments about the language not being fit for development productivity and code quality, it simply isn't true.
Your assumption that I did not get familiar with the topic before writing my comment is wrong. I've not only read this article, but also spent some time researching what's beyond it - enough to have an opinion and express it. If all you can do is to make such advices, you could refrain from making this comment yourself. If you have something to say about the matter, I'd be happy to learn and discuss in a productive way.
Should I care about yet another "bullocks" opinion or maybe you have any sensible objections or questions? I'm ready to explain something, but not when the discussion goes this way.
The vast majority of apps today are still small, and certainly nowhere near MLoC-size.
It certainly lacks features many of us takes for granted. But people e.g. still write C, that is far more primitive, so if people want to do Object Pascal, why not.
Though it's a shame to see it effectively win over a language like Oberon (if one first is to stay in the Pascal lineage).
Thanks to lots of available 3rd party frameworks, modern web portal can be just 50-100KLoC, but add all the dependencies and you may become really close to million lines. All these dependencies have to be resolved, loaded and processed in order to compile your code, namespace and version conflicts must be avoided, test dependencies separated from production ones etc, so you cannot ignore it as some magic on the back stage. Of course, there's still some room for low-level utilities or one-time scientific calculations, for which Pascal can be used (hell, I remember that times, when we, the kids, hacked our school network to get super user access by writing keyloggers and simple viruses on TP6), but should it be a language of first choice for that today?..
I agree with your first 2 sentences, which Modern Pascal is just as capable, if not more, than Java. Lazarus is an example of such complex project, it has near 5 MLoC (without external dependencies) according to openhub and is managed just fine, thanks to the compiler's smart dependency management.
Modern Pascal is a very good language of choice when you have tight budget but still want to compete with enterprise Java systems. The low resource requirement is one prominent factor while the performance is similar if not better in real world applications. We have one of our apps (web application with embedded web server, proxified by nginx) running constant 100MB RAM only at peak, single process, while serving tens of thousands of users, backed only by a single SQLite database. Even the 100MB is mostly due to our template engine automatic caching system.
Java will win in microbenchmarks, but that's the best HotSpot JVM can do. Tight loops and complex calculations are actually seldom happened in enterprise apps, while context switching happens a lot more often as (a lot of) users move from one context to another frequently.
Thanks, that's really interesting. I'm not surprised that Pascal applications are very fast - after all, it's native. My main concern is the maturity of ecosystem - tools, libraries, frameworks, everything that defines the TCO (development + distribution + maintenance) of modern application. It's good to know that something exists in this field and there are examples of live apps and it would be interesting to compare the stacks and their capabilities.
Couldn't have found an easier route than to build this in FPC with Lazarus.
Even though I had hardly coded a line in the language before, it was built from scratch to "happy end-user" in 80 hours, including learning the language.
I built it on Xubuntu, then imported it on my Windows VM and compiled, WITHOUT A SINGLE CHANGE! On Mac, I needed to add a missing import statement or so.
Simply an outstandingly productive tool for open source, cross-platform GUI development.
(The tool: https://github.com/NBISweden/mdc-file-export )