- It's nowhere near new and trendy enough to have a bandwagon (e.g. Node, Go, Rust)
- It's not obscure enough to have a retro-cool following (e.g. Tcl, Forth)
- It doesn't blaze any theoretical trails in computer science today (e.g. Haskell)
- It's not associated with any evil corporate entity, allowing you to praise it "ironically" (e.g. C#)
However, I find it to be a really pleasant language to work with, at least for side projects and the occasional cross-platform GUI app. It's a clean, easy-to-learn imperative style throwback... with respectable support for object-orientation (NOTE: Everything in this comment is directed toward Free Pascal's support for Delphi-compatible Object Pascal. I haven't written old school non-OO Pascal since the 1980's).
In a nutshell... the language syntax feels like Golang dropped its curly braces, and finally added generics!
I believe that the Lazarus IDE and GUI libary for Free Pascal (http://www.lazarus-ide.org) is by far the most compelling option out there for this common use case:
- You want to write a desktop GUI application, supporting OSX, Windows, and Linux from the same codebase.
- You strongly prefer static-typed languages. You don't want to cobble together a GTK app with Python or Ruby, and you REALLY don't want to embed three-quarters of Chrome and have to write your app in HTML and JavaScript.
- You want AOT compilation down to a standalone executable. You don't want to depend on the target machines having a Java VM or Mono installed. You don't want to wait another several years for Java AOT or .NET Native to become serious reality, and you don't want to deal with the flakiness of Mono's "mkbundle" tool.
- Life's too short to install a couple gigabytes worth of Qt, or try to make wxWidgets build properly on a Windows machine, and become proficient with C++.
If at least a few of the bullet-points above apply to you, then Free Pascal and Lazarus are definitely worth a look!
I recommended it to companies as a future-proof language back in the day because of how easy it was to understand and the better safety than C. I told them that would pay off in maintenance mode plus a compiler or whatever would be easy to write if its support dwindled. Wirth's stuff is just inherently so simple.
Most went with C or C++. I hear the codebases are a b to work with. ;)
>> - It doesn't blaze any theoretical trails in computer science today (e.g. Haskell)
Which is probably a good thing.
As much I'm fascinating by functional programming (type system, lambda calculus, etc etc), I find it kinda difficult to program on :p
You get to know another paradigm which is very important. Object orientation already evolved into an ideology. So it's very good to get to know something so totally different.
In China, Pascal is a very popular language for high school beginners of Olympiad in Informatics (see http://www.ioinformatics.org/ for the international competition). And it's probably the most used language in the provincial level competition, National Olympiad in Informatics in Province. Yet those who reach the national level will likely switch to C++ for many reasons (STL, performance, etc.).
I myself started programming in this way. And even now I'm glad that Pascal was my first language. It's an excellent educational language, which was its original purpose. It doesn't have "absurd" syntax; keywords are long but straightforward; and its type system is static and strong, which I believe is something that a serious programmer has to master.
By the way, although probably not as powerful as Delphi (especially in terms of widgets), Lazarus will give you a taste of the Rapid Application Development, which Delphi was famous for.
Everyone who intends to do a degree in computer science is taught Pascal, olympiads are in Pascal/C++.
Whether it's a good language to teach highschoolers (students in general, not preparing for olympiads) or not, I am not so sure. On one hand, yeah, it's pretty simple.
On other hand, I'd lean towards Python simply because it's more widespread in industry, as a result you have tons of well documented libraries for pretty much everything a highschooler will care about. Therefore, making it much easier to develop something useful, which results in higher motivation. And REPL, ipython notebooks are really neat for learning.
But that's the theory. In real life, you have loads of teachers who know only the very basics of Pascal and teaching them a new language might be... challenging (I've witnessed enough teachers struggling with basics of Pascal).
So all in all, it seems like Pascal is a reasonable option.
I think Python is a good language, but not for learning.
Everything that relates to theory (scoping, object system, typing) is poorly specified and has loads of special cases that can only be understood by using the language a lot.
My largest concern about using Python as the first teaching language for serious programmers (or you can say those who intend to pursue a CS degree) is that it's too "magical". The dynamic type system, the flexible Pythonic tricks, "hidden" (at least not explicit and obvious) details about the memory model, etc.
As a programmer, I like many of these characteristics. However, when I was helping the lower-year students with programming, I found many starting with Python faced tremendous difficulties in understanding pointers, references, and types later on. Some of them even resisted learning these concepts and further resisted using C/C++/Java, claiming that it's world of Node.js/Python/Ruby.
I'm not sure if it's just that I'm getting old (not really...).
To be honest they should teach JavaScript instead of Python in highschools. Websites ('web apps'..) are a big deal in, atleast, teenager's life, so they could atleast install Tampermonkey plugin and script some functionality for their favorite websites.
Meanwhile after learning python if you won't work in IT is useless. Plus requirement to install Python, include python in PATH and use CMD to launch .py scripts is a detterant, while with Javascript you just press F12 in browser and bam - development environment ready and lets you to manipulate open web page, which is also more exciting than console applications.
"I heard of Python; I was thinking of learning that or JavaScript..."
No. I'm from the future. You should start with Python.
The only problem I have with Python is its weird scoping rules and the fact that it's dynamically typed. But it's overall LESS weird than JavaScript. Beginning programmers need a clean, minimally weird language, ideally with a REPL, in which to grasp the basics: namely that computers follow composable sequences of instructions and these instructions need to be written in an unambiguous way. In the 80s we used cut-down BASIC dialects for this; today, Python is as close to optimal a choice as we can get.
Starting people with JavaScript and Web pages to make programming "more relevant to today's users" is like giving Hamlet a backwards ball cap, skateboard, and sunglasses to make him "more relevant to today's teens".
That's a very Windows-centric view of the world. Macs are increasing popular in education and come with Python pre-installed. Linux comes with Python pre-installed. iOS / Android require installing an app to do local programming either way, and I'd argue the Python writing apps are better than their javascript writing apps.
Microsoft should fix the "bug" that its operating system is missing interpreters for Perl, Python, etc... (Oddly enough, this list also includes javascript!)
Windows actually has a Javascript (well, the JScript dialect of ECMAScript) interpreter out of the box in the form of Windows Script Host. It also supports VBScript. You can play with it on the command line using the cscript command.
The most interesting part is that you can script applications with it. I recall writing a script that played Google's running game during the Olympics a while back when I was learning to program.
>To be honest they should teach JavaScript instead of Python in highschools. Websites ('web apps'..) are a big deal in, atleast, teenager's life, so they could atleast install Tampermonkey plugin and script some functionality for their favorite websites.
I've never ...monkeypatched websites, and I've been a professional web programmer for 17 years. Now, I could very well be an outlier, but I don't recall any of tens of tech colleagues or friends in over 4 countries really going into that.
I don't think that's a valid use case for teenagers to learn JS for. There many other reasons of course -- but monkey-patching "their favorite websites" would be very low in that list.
Good point. A few weeks ago I made a similar point here on HN, that web dev is good for starting.
Given more thoughts, I am fairly conflicted/confused about web apps vs Python :)
Web apps, as you've said, are pretty straightforward, minimal setup, extremely easy to relate to. I guess many folks who aren't familiar with coding have an idea for web site or two. That makes it a great motivator, no doubt. If a friend asked where to start, I'd probably point to this direction. HTML5 games is a pretty good choice too, and Phaser is a neat framework to start with.
However, there are a few problems with this approach.
First, most of the development/studying would be more about the details of browsers/jQuery/javascript itself. How to get the content of this input, how to attach this event, etc. The problem is that it doesn't do much to teach the mindset of programming. You know, when to apply for loop, when while loop, etc.
The other problem is that web dev is moving much much faster than most of the education systems in the world. In 2010, you probably would have taught about jQuery. In 2015, you probably would use vanilla JS as it's good enough, modern browsers are following the standards well enough. And then you have all the html5 elements (video, etc), css3 properties which are fairly important nowadays but didn't exist 5 years ago (or the browser support was poor).
So, web dev might work quite well for motivated individuals and equally motivated teachers but probably less so for mainstream education (i.e. highschools).
Python has it's place. When teaching kids, I guess it comes down to two things - are you targeting the lowest barrier to entry to make something whiz-bang to appeal to the largest common denominator of "I use Facebook so I'd like to make 'computer things'", in which case, alright they can install Tampermonkey and mess with a really inconsistent language like Ecmascript5[1] then spend a lot of time explaining things like the DOM and how to traverse it, then the issue of how to manipulate certain things (what do if getElementByName isn't working because someone decided to not properly tag things?), followed by now we have to teach them CSS so they actually can alter the aesthetics or worse, teach them JS so can actually add functionality (which involves all of the ES5 shims and a huge confusing ecosystem that even people in the industry like us have to spend tons of time working on).
On the other hand Python can be installed with one binary on Macs, Windows, and Linux with 300 packages and an IDE[1] and they'll be able to use it with the Excel spreadsheets down the road which they'll inevitably have to deal with if they're the average white-collar office worker. (See: http://xlwings.org/ and say goodbye to VBA). The large majority of people will actually use Excel on a regular basis and if their job involves reconciling a lot of semi-structured data, as it frequently occurs with my friends in the social sciences or other non-CS fields, they'll largely benefit from Python.
Not only that but after having a core Python knowledge, with the same Anaconda package, you'll be able to make your own QT-native crossplatform full GUI binaries with an 'import PySide' or write your own 'web apps' with equal ease.
If your goal is to maximize the performance of your students in international competitive programming competitions, then you should be teaching them out of Competitive Programming and Steve Skeina's book so they recognize what category the problem falls into (it's usually one of 5 or 6), along with C++ plus the standard C++ libraries that everyone uses that loads in GMP, makes matrix manipulation easy, etc.
If your goal is to cater to the guys to teach fundamentals to those who are going to matriculate into the CS uni path, then both are wrong and you should be teaching out of something like the SICP from the 'top down' and something like ML from the 'bottom up'.
[1] https://www.continuum.io/downloads if you don't like Anaconda, there are a boatload of competitors like https://python-xy.github.io/ that come with Spyder, which I think we both will agree offers a better development experience than Tampermonkey.
What was actually annotated as [1] in the end-notes should have been annotated as [2] with the proper link. The "IDE[1]" annotation should be altered to "IDE[2]".
Pascal was the teaching language of choice in the US for a very long time. My high school AP (advanced classes that provided college credit) programming classes were taught with Pascal, after the introductory class using BASIC. But, I was in high school a long time ago, and programming was taught on Apple II computers (there were some IIe computers in the lab, as well). I don't think there's widespread Pascal usage for teaching in the US today, and I don't think I would campaign for bringing it back.
I'm not sure what took its place in high schools, now that I think of it, as I'm so far removed from it.
Pascal was on the way out when I was in HS (I'm 32) but it was still kicking in the form of Delphi during the VB wars (then VB4). I have fond memories of it.
I guess if kids learn Java, and still love programming after that, they've got what it takes to be programmers in the real world.
But, I don't think I'd set out to punish kids for wanting to learn programming by making them use something that has so much tedious boilerplate and verbosity. Then again, you can actually make real things with Java; everything from games (Minecraft) to the web (sort of) to apps (most Android apps) to OS programming (Android, itself) is reasonably do-able. So, the empowerment level is high. It just seems like something more immediate would be preferable, at least for the first class (to parallel the use of BASIC in my day; maybe Python would be a good choice, since it can be used for real projects, too).
I'm not from the US, but in my high school Pascal was taught up until a few years ago when they switched to Python.
Other schools here usually teach C.
For people who are going to ask "Do people still use pascal?", long story short-> yes they do, and Free Pascal Compiler is not only the traditional Pascal that we used to lean in school, it's also an Object Pascal compiler, and has many many libraries for modern programming :))
I started learning programming with Pascal when I was a child, it helped me to understand many things, lately I had a look at Python, which I love it a lot, but when I took a look back at Pascal (Object Pascal this time) I understood that everyone should start programming with Object Pascal and learn about the basics (then use what ever you want, .NET, Java, C++, Ada, etc).
BUT I found out about this amazing language Oberon-2, and I should say that in schools we should move not to Python/Java, but to Oberon-2 (it's again a Wirthian language). Sorry for my bad English, just wanted to share my view, and I'd like also to say that (IMHO) making GUI programs using Lazarus is much easier than, well, anything else :))
We already had it quite good on the PC with Turbo Pascal and later Delphi, which is why I find a bit sad that it took us almost 20 years to get .NET Native, instead of it being the default toolchain from day one.
To be fair, most of the benchmarks I've seen from end-users don't have .NET Native outperforming the CLR except in huge number crunching situations[1,2]. As one would imagine in those scenarios using your standard stack of C++ with the GNU GSL[3] (which includes your BLAS, GMP, PDE, and standard lin. alg. stuff) is still pretty much king with MPL (based on MPI) with some (often modest, sometimes incredible OpenCL gains). In numerical methods, Fortran w/ a modern Intel MKL and MPI still reign for SIMD. I guess what I'm saying is, for your day to day Rapid App Dev (which Borland Delphi + the VCL was absolutely king at up until MS put out Lightswitch) you weren't really crunching away. Likewise, especially with modern JIT'ing if you _do_ crunch with a language that hit's the CLR hard, you still get performance similar to .NET Native (contrary to MS claims of "performance similar to C++). I've been a MS advocate for ages and admire what they've been doing since ~2005 at MSR all the way to the production cash cows[MS SQL Standard gives you a ~LOT~ of bang for your buck with SSDT/SSAS/SSRS] (check my 8 year post history - when everyone was rails rails! iOS! MBP!! I was silently C#3'ing along); I say all this as a long preface to pose this question - what exactly did .NET Native bring that presumably made it catch up to TP/Delphi?
30 years ago I was discussing these arguments between those
using Assembly and those that dared to use C, Pascal, Basic and Modula-2 in home computers.
20 years ago I was discussing these arguments between those using C, Turbo Pascal and those that dared to use C++, Object Pascal features in Turbo Pascal/Delphi.
So I still envision the day managed languages get to the next discussion cycle.
> what exactly did .NET Native bring that presumably made it catch up to TP/Delphi?
Static binaries, integration with the Visual C++ backed (it is not used in JIT/RyuJIT/NGEN).
Pushing C# for more use cases where they still make use of C++. If you look at the C# 7 roadmap there are still more features coming into that direction.
One of the reasons they made .NET Native, which came from Singularity actually, was that the C++/CX uptake is not take big. Most developers only reach out to C++/CX instead of C#/VB.NET for the APIs not exposed to .NET, like DirectX.
I was a big fan of TP and eventually made the jump to C++, which is also very dear to my heart.
But I would rather have a full stack language that offers me the safety of Algol languages, without C underpinnings.
With .NET Native and the integration of System C# features into .NET, it is becoming quite appealing.
I apologize if I came off snarky; my intention wasn't to be argumentative. All of my questions were posed with genuine curiosity rather than with the passive-aggressive tone I may have unintentionally conveyed. I certainly am not in that group of language warriors. I don't have any allegiances to languages, platforms, styles of languages, or even architectures (I'll use a Harvard based over von Neumann if it gets the job done better).
Most of the people I know choosing C++ over C# are using it for the ability to get soft-real-time guarantees w/r/t performance. E.g. the gaming development guys have a "this next framebuffer ~must~ be done within 16.6 or 33.3 ms" or "I need a deterministic 'buy/sell/hold/not-enough-information-to-say-with-a-high-confidence-factor, defer-to-safety-net-policy'". At CppCon '15 most of the people I spoke to fell into a similar camp. I don't think I even spoke with one engineer who's day job involved using C++ because <insert CLR language here> failed to have interop capabilities w/ DX or what not. Of course, those who attend conferences will bias in a certain way so I'm not making an appeal to that demographic as in any way representative of the C++ user-body.
My assertion was simply : those who are using C++ are using it out of the benefits of predictable behavior. They can't afford that situaiton of: your GC won't decide this is the appropriate time to move all those marked as Gen0->1 over and oh by the way they're all a few bits big and fragmented so no pre-fetching help for you. What makes those guys different from the guys who were ASM guys who refused to use C back in the day is that the compiler eventually outperformed the hand-rolled stuff - but even then the ASM guys were steadfast. You make some real interesting points though and you're right - I haven't looked at the C#7 roadmap. Hell, to be honest I haven't even written enough code to take advantage of Roslyn's introspective capabilities. Thanks though, insightful comment as always. (Please keep on posting and don't disappear like the good posters of yesteryear (edw519, grellas, etc)).
"30 years ago I was discussing these arguments between those using Assembly and those that dared to use C, Pascal, Basic and Modula-2 in home computers.
20 years ago I was discussing these arguments between those using C, Turbo Pascal and those that dared to use C++, Object Pascal features in Turbo Pascal/Delphi."
Nice take on it. :)
"But I would rather have a full stack language that offers me the safety of Algol languages, without C underpinnings."
Exactly. That's always a Pascal advantage. You can be clear on exactly what it does and it's probably safe by default.
Oberon was actually used in a couple of German universities, not just because of the language, but because of the whole environment (which feels a bit like SmallTalk for bit-twiddlers and -shavers).
Having said that, Oberon is a pretty strict and bare language compared to others, e.g. in its current standard, the old structured programming rule of one return statement per function is strictly enforced. Whether that's an advantage for teaching or not, I can't really say.
Sometimes I think strict and bare is better, especially for learning. One of the reasons I like C so much is that it makes doing complicated things really hard, so you end up solving problems in simple ways instead. Bare languages really force you to understand and think through your problem.
For a big, modern, highly successful product written in Pascal (Delphi), see FL Studio. A high performance entry-level DAW, complete with a fully scalable vector based UI.
They even started porting in to OS X, which was problematic before as they had to wait for Pascal on OS X to get up to par -- it's now in beta stage (available for end-user testing), and should be released sometime around late next year.
(The in-development OS X version is with fully NATIVE Pascal code, NOT to be confused with their earlier attempt to ship the PC version + WINE libraries).
Before C caught on fully in the mid-80s, for lots of commercial "powerful" apps, Pascal was a common choice. And in a lesser degree it continued to be, with Delphi et al, until late nineties, although loosing ground fast.
It's as low level as C/C++, can inline assembly easily, and offers the same, or even more, functionality out of the box. And back in the day it had excellent compilers too.
Actually, in the eighties, Mac OS used to be written in Pascal. And TeX was written in Pascal too, by Knuth. A more modern example of an app would be Skype (Delphi Pascal).
Pascal always takes me down memory lane...to the very young me, family just got the first PC. I wrote the first "programs" in good old QBasic but that couldn't create executable files so I bought a random book on Pascal (yellow book, something with 7.0?) I saw in a store which came with a floppy that had a compiler (and thus allowed me to create the magical .exe files). Thinking about this makes me smile for multiple reasons (one of which is that back then for me computers were exclusively Microsoft OS based).
The program that I wanted to write? A password protection for the new PC (loaded from autoexec). Highly insecure by design but I was pretty happy to get it working :P
The other genius idea from that era was randomly outputting sound (length, frequency etc.). My young self figured that I only had to let the program run for a while until some cool sound effects would be found...well the result was rather unpleasant :D
One of the more enlightening moments of my early development as a programmer was looking at assembler output for Pascal vs. C. It never occurred to me before that C-style is just one way of doing it and I had assumed that parameters are always right to left because "that's how it is" :)
[must have been around the time when the Phrack with "Smashing the Stack for Fun and Profit" was released as that was when I got interested in assembly]
I have almost exactly the same memories of Pascal. Being a kid tinkering with QBasic (and later QuickBasic that also created the mystical executables).
It was when I started tinkering with computer graphics I realized that QBasic was not that performant and stumbled upon Pascal. It was in Borland Pascal I first learned about pointers, vectors, memory management etc.
Funny, that's exactly how I moved from Basic to Pascal... And eventually to C since I realized that my awful self-implemented 2d graphics library would never have the performance nor the set of features of for example the Allegro game programming library.
I also tinkered a lot in Delphi after that and I'd really like to give Lazarus a try now that I'm an adult who actually knows how to program.
I've been using Lazarus 2.6 for a free time project since August as I've used Delphi 1.0 in the early nineties and I wanted to see if this was any good.
I've been blow away with it, it's Delphi brought from the dead :)
It has been a real pleasure to use and I've come to appreciate the productivity that it brings, as this open source IDE is on par with what I remembered from early Delphi versions and, amazingly, I feel this is the cleanest way to target mac and linux GUI apps today (YMMV).
It's a shame that there is no support on SWIG for freepascal but it will get there eventually.
So, kudos to the freepascal and lazarus teams and thank you very, very much!
...Delphi's not dead - see http://www.embarcadero.com/products/delphi, now it's cross platform, modern language features - generics, lambdas etc etc. Writing a Mac app in it right now :-)
"cross platform" to whatever they feel like. I remember in college my teacher bought the new version for that. Turned out "Native Android support" was phonegap which isn't native.
It's actually native now, albeit kind of a mess (or at least the C++ version is; I haven't used Delphi). For example, Windows/x86, Windows/x64, and ARM are all different compilers (OS X and ARM are both clang; x64 is an older clang, x86 is totally different) that support different features and have subtly different behavior sometimes. Then there are differences between VCL and Firemonkey, so don't even try porting an existing Win32 app.
For us who use stuff on a regular basis the changes seem small but peu a peu these add up.
Once an electrician still developing in spare time who know Turbo Pascal 5 from school while servicing the air conditioner saw me programming. When he heard that I would use Pascal he looked at my screen jumped from the ladder and left the office together with me after midnight.
Freepascal is indeed a very solid approach I use on Linux especially. Works great on Windows too.
The Lazarus IDE and GUI component library is simply fantastic, and the most productive native cross-platform GUI toolkit for the big three desktop OSes (OS X/Windows/Linux) that you'll probably find.
We needed small helper tool developed as a cross platform desktop app at the university recently, and had an extremely rewarding experience developing it in Lazarus/FPC:
After building the app on Ubuntu, I opened my Windows virtual machine, imported the project, and pressed "Run", and I had a working native windows application, without a single change! (Only on OS/X, there were some missing import of cthreads or something, that needed to be added, amounting to 1LOC).
Based on this, today, to anyone developing native cross-platform desktop apps, my number 1 recommendation is Lazarus.
Btw, I find the new JVM and Dalvik [1] and Android [2] targets very very interesting!
It's strange, the more new languages I learn, and the more complexity things like C++ acquire, the more I'm starting to feel like we lost something with simple straightforward languages like pascal and even C
I'm with you on this - its why I consider that Lua is the language to learn right now. It provides all the powers of the other languages, and all the performance/advantages of C ..
Go looks pretty simple. I just picked up Kernighan's new book; he says radical simplicity was their main goal, and lists Pascal/Oberon in their influences.
Borland's Delphi (now Embarcadaro) was a platform that made apps faster than C/C++, easier to read, less crashes, less undefined behavior, easy to extend, and so on. The properties of Pascal made it the closest thing to an ideal language for future-proof apps back then. I predicted that, if Borland failed, it would be straight-forward enough to create a replacement stack due to Pascal's focus on simplicity. It was good to see each iteration of Free Pascal do exactly that.
Not sure if I'd recommend Pascal today given whats available. It's still one of easiest to pick up and should be effectively future-proof. Way better than ending up with COBOL, C, etc codebases. Maybe those will be its legacy. Another part is Pascal/P showing how to do portability "like a boss." :)
Free Pascal in my limited experience has been ironically better than the commercial Delphi.
FPC has the ability to read arrow keys from a CLI, Delphi required some awful lump of Win32 code. Oh and FPC actually generated numbers random enough to make a simple game of Tic Tac To work :')
(Delphi did not, making the game unplayable without adding my own version of a random number generator)
I used it a few months ago to develop some HPC code for analyzing the timelines of a cosmological instrument (ESA Planck/LFI), and I was quite happy with the result. I even wrote a blog post about my experience (http://ziotom78.blogspot.fr/2015/01/lfi-data-analysis-with-f...).
Great blog post. One point, though: the reason that you got a segfault with your FillChar on the array isn't because you used a dynamic array instead of static array. Dynamic arrays are just like pointers in terms of how the compiler handles them (the element count is a negative offset from the actual start of the elements, and there are other things like reference counts there also). The reason you got the segfault is because FillChar operates directly on the passed variable. In other words, your FillChar zeroed out the first 4 bytes of the pointer (not good) and then kept right on zeroing out memory that didn't belong to it (definitely not good). The reason the:
array[0]
notation worked is because subscript references are equivalent to referencing the first element in the array like a variable. Therefore the FillChar started from there and properly filled the rest of the array.
In the rare occasions where I still have to do something for Windows, I'm still using my old and trusty version of Delphi 2010.
If I had to say anything about Pascal, I would say that it's very readable. Even with multi-years gaps between me having to work on this, it's very easy to re-familiarise myself with the code and it's very easy to understand what it's doing.
This might be related to style and, as Delphi was my first real language I've learned waybackwhen in the mid-90ies, yes, I have made a mess with my Pascal too, but it feels like it's much harder to produce a mess than it is in any other language I've worked with so far.
Of course this is all just a matter of taste - just giving my 5 cents.
In South Africa, Pascal and Delphi are still taught in schools... In fact, the University of South Africa actually has about 2 Delphi semester modules also, along with C++.
Some schools have switched over to Java, and most other universities have jumped onto the Java/.NET bandwagon.
So in a nutshell, I think it's still pretty prevalent in 3rd world countries. It's not a bad starting language to introduce students to programming concepts, although I would prefer Python for a first language.
I agree. When learning to program, one should first learn the mental activity oc solving problems with code. Then maybe learn all the boilerplate and BS associated with a language like Java. Pascal is simple enough that students can learn fundamentals first. Same with industrial BASIC. Both are like pseudocode.
Many people are turned off to programming encountering Java, C++, etc because they think programming is inherently that difficult.
I remember there used to exist a South African magazine about game development in Turbo/Free Pascal and Delphi.
It is quite nice that those universities still teach it, as that way at least those students will learn that C and C++ aren't the only way of doing systems programming.
The firm where I currently work has a rather huge Delphi legacy software. You'd be surprised how much is still being "extracted" out of if. The more modern (and better built, but I'm biased, as I'm part of the team developing it) web app, which is meant to replace the Delphi one, has not had the same success. It's picking up momentum though...
If it's better built then why hasn't had the same success? What are your metrics for "better"?
What does "more modern" mean exactly? I don't see that there's much value in pursuing design or implementation purity if the software isn't getting the same end user take-up.
The Delphi app has been continuously "enriched" with features and special cases, based on direct feature requests for each client that requested one. This has lead to the case where there are several thousands switches which need to work together, in every combination possible. They don't always work, by the way. The new app has selected the more relevant use cases and could be better structured and implemented. Modern means primarily a cleaned up UI, but also the dynamic way of customizing the GUI (defined per JSON and capable of on the fly changes for individual users or groups of users, instead of hard-code and compiled or yet another flag stored in the DB).
The clients are usually pleased with the web app but the project managers are a bit hesitant, due to the different installation process. The Delphi app has been sold/installed for well over 10-15 years and people are used to copying .exe files on a server. Copying files and .dll-s and tinkering with IIS seams to be less appealing...
The need to go "online" has been the driving factor for the web app.
It smells like the web app still has that new car smell. I'd guess that the web app will go through the same process of enrichment. The web app will get the special cases and direct feature requests and will eventually arrive at a similar state as the old application for similar reasons, just in a different implementation.
Spot on! This is not really something that the (our) developers can control. We're already seeing this. My point was that we could use the information gathered from the prior implementation and take better can and design the new app with a higher degree of flexibility, so that, when those special cases occur, we could, for example, change a configuration file, instead of the actual code.
My guess.. we're talking years of investment in a (presumably monolithic) "huge" Delphi system.
Either spend even more years adding the needed features while fighting the upscale hill.. (especially when introducing bigdata)
..or develop an alternative made out of simpler beasts: clean separation to avoid hydra scenario's. It takes time to beat that, but i see reasons to go away from a huge monolithic beast.
I don't remember hearing that the behemoth will be extended with large(-ish) new modules. It will receive several features though. The truth is that they can't just throw it out the window, especially with global scale clients still using it.
We've been in the Delphi/FP/Lazarus 3rd party tools market for 17 years, and are still going strong. Yes, it's become less-used over the years, but it doesn't have anything to do with the language not being up-to-date. It more has been due to issues with Delphi's parent company and pricing.
We wrote 2 database engines and a web development IDE using Delphi (compiles Object Pascal to JS). You can use it for just about anything: low-level, high-level, servers, games, LOB applications, mobile, and you can't beat it for code structure. It's highly readable and maintainable, and the compilers/libraries/runtimes are very backwards-compatible, so you can be assured that your coding investment will continue to produce returns for many years. You'd be surprised how many LOB applications are out there that are written in Object Pascal.
Sure, there are not much new development, but there is still a lot of people working in it every day. I am one of those people, maintaining and developing big business system.
You can find Pascal/Delphi projects everywhere: a lot of scientific instrumentation software has GUI written in Delphi, there are tons of business software, even big amount of machines has UI for their front panels written in this language.
I think Delphi/Lazarus is still best software for writing small to medium sized desktop apps available.
In the end there are 3 tribes. freepascal, Delphi and the Elements Compiler (C#, Swift, Oxygene Language is Pascal).
There are many more traditional Pascal environments too. Smartmobile (HTML 5 apps), XEROCODER (based on FPC) for Grid developments and an integration into Visual Studio Code ...
FPC Version 3 is a huge step and a great one. While I personally admire all of the people's work I must confess the evolution of freepascal as well as the Lazarus IDE is exceptional.
If only they would embrace modern code managing methods, e.g. Github to make contributing easier. And, maybe, divide the 'pascal universe' in easier digesteable parts: compiler, non-visual core code, core ui components, additional code, Ide. Try to unify documentation, language style etc. Use Markdown (or reStructuredText) with Github documentation projects. Now everything looks so dated. - But I don't complain, great that people still work on Pascal, since decades, and if it works for them, fine. - Anyway, congratulations and thanks :-)
> Powerful user friendly Wordstar compatible multi file editor
Plus OS/2 Warp and DOS compatibility.
I was a huge fan of Turbo Pascal back in the day. Before that it was BASICA and I spent days tracking down bugs by spreading printouts on the floor and tracing my GOTOs. Then Dad brought home Turbo, I tried it out by writing Conway's Life, and it ran without bugs on the first successful compile. Never looked back.
Based on some of the other comments here, it might be worth trying out again!
In Brazil, one of the big universities at the south of the country teaches Pascal as the first language in the Computer Science course. And we use the compiler Free Pascal there. The language is very didactic and still good to beginners. The fact that Pascal isn't widely used is counted as a bonus, because this will force you to learn another language as soon as you get approved in the subject that teaches programming and basic algorithms.
My first foray into "real" PC programming was done in via Kahn/Borland's fairly awesome Turbo Pascal compiler back in the the early 80's for IBM's DOS OS.
Pascal introduced me to pointers, free-form editing (I came from interpreted BASIC where line numbers and such forced format) and good CS techniques. I built a true circular linked-list as one of my first projects.
I can remember at the time being awed at how fast the compiled executables ran on the PC, and quickly started writing Blackjack and Poker simulations using the language.
It's good to see efforts in releasing this...Pascal has been of course outshined by Python, Go etc etc but it's always fun to trip down memory lane.
BTW, AFAIK Wirth's work is not limited to Pascal (there are Oberon and Modula, for example). Wonder why those languages don't gain as much exposure as Pascal does?
It's not like Pascal has an insane amount of exposure, I fail to remember any news here that wasn't about a new FPC/Lazarus release. Whereas the Oberon/Modula compiler space seems pretty defunct. And sadly, the same is true for Modula-3, the language that could've been a better Java/C#...
The only other language from the family that one reads about here (very) occasionally is Ada.
Unless one counts Go as some kind of Algol68-Ratfor.
The crt and graph libraries in Pascal are awesome and I guess the Turbo Pascal compiler as well. In the span of two weeks I went from non even being aware of the concept of "programming" to writing a platformer with only basic understanding of loops, if/switch conditions and procedures. I don't think it gets easier than that as far as imperative programming goes. It's kind of like the scheme of imperative languages.
I've never used FPC, but my interactions with/what I've heard from a couple of its devs about their engineering decisions consistently leads me to think that they have high standards, so I have a lot of respect for the project!
Best news I heard for a long time. 3.0 is almost groundbreaking especially for those designing distributed but lightweight architectures just to mention one advantage among many you get.
I am currently working on a project that I will be using at home between my laptop and (not so powerful) Raspberry PI. I am well versed in C and this project is written in it, with very minimal dependencies (currently talloc, libbsd and makeheaders). I am trying to keep resource usage at a bare minimum on the server side (Raspberry PI) for obvious reasons.
I've never worked with Pascal, and I've been looking for an alternative to C that solves some of the issues I'm having without sacrificing too many of its advantages. Since fpc is available for armv6, I am wondering if someone could give me advice on whether moving this project to Pascal would be beneficial, especially compared to the following points:
- A proper module system, without having to keep .h and .c files in sync when the interfaces aren't stable yet. I am currently using makeheaders to make things less annoying for me.
- Compiler warnings, cppcheck and scan-build offer me great feedback. Emacs integration of these tools is priceless.
- The ability to do things like recv() into the middle of a buffer. That is just too efficient to let go of. I think this is something many people overlook when comparing C to other programming languages, many times you can turn O(2n) into O(n) by taking advantage of this. Not theoretically different, but in practice it can pay off.
- Emacs integration and support. Nice to have would be support for auto-completion, static analysis, etc...
- Documentation. Man 2, 3 and 3p are priceless. Emacs man integration is great.
- Number types that are exactly the same across architectures. eg, I've had issues because off_t was ulong on one machine and ulonglong on the other.
- Memory management, error handling and everything you need to do that has nothing to do with the task at hand. It gets old quickly.
- Optionally high-level, I am comfortable working with pointers and addressing memory directly, but sometimes I look for elegance where I know performance is not going to be affected too much (ie, the trade-off is acceptable). This also means that when I'm working with higher-level constructs, I'd like to have easy access to the inner workings so that I can make such a judgement myself (either through documentation or other means).
- I don't care too much about compilation speed.
- Easy semantics and simplicity of things. I really don't think I can put that into words, it's better understood through experience. But this is one of the biggest reasons I stick with C rather than C++ or Rust.
- The availability of a widely approved guide that doesn't go into the very basics of programming to explain the language (maybe some sort of Pascal for C people kind of thing).
- There are probably a few more points I could talk about but can't think of right now. I could write them down some time later if anyone is interested.
Thank you in advance, I would really appreciate if anybody can help me with these points, I'm looking for new adventures :)
Pascal will cover a few of your points and move you sideways on others. For example you do have a required forward declaration but it's all in a single module file. FPC is a good compiler and should cover most concerns around tooling. And it's all been documented in depth at some point, although you might be studying from pretty old sources.
But because it remains a pretty simple language, it's not going to have so many nifty time saver features. If you're going for that you might be better served with a "new and hyped" language like D or Nim - those languages aren't as convoluted as C++ but they are still complex.
You can pop into the IDE and start coding/compiling/running things right away.
I haven't seen the FP/Lazarus docs lately, so I can't comment on their quality, but this is a good resource for getting up to speed with Delphi, and a lot of it is exactly the same in FP/Lazarus:
- It's nowhere near new and trendy enough to have a bandwagon (e.g. Node, Go, Rust)
- It's not obscure enough to have a retro-cool following (e.g. Tcl, Forth)
- It doesn't blaze any theoretical trails in computer science today (e.g. Haskell)
- It's not associated with any evil corporate entity, allowing you to praise it "ironically" (e.g. C#)
However, I find it to be a really pleasant language to work with, at least for side projects and the occasional cross-platform GUI app. It's a clean, easy-to-learn imperative style throwback... with respectable support for object-orientation (NOTE: Everything in this comment is directed toward Free Pascal's support for Delphi-compatible Object Pascal. I haven't written old school non-OO Pascal since the 1980's).
In a nutshell... the language syntax feels like Golang dropped its curly braces, and finally added generics!
I believe that the Lazarus IDE and GUI libary for Free Pascal (http://www.lazarus-ide.org) is by far the most compelling option out there for this common use case:
- You want to write a desktop GUI application, supporting OSX, Windows, and Linux from the same codebase.
- You strongly prefer static-typed languages. You don't want to cobble together a GTK app with Python or Ruby, and you REALLY don't want to embed three-quarters of Chrome and have to write your app in HTML and JavaScript.
- You want AOT compilation down to a standalone executable. You don't want to depend on the target machines having a Java VM or Mono installed. You don't want to wait another several years for Java AOT or .NET Native to become serious reality, and you don't want to deal with the flakiness of Mono's "mkbundle" tool.
- Life's too short to install a couple gigabytes worth of Qt, or try to make wxWidgets build properly on a Windows machine, and become proficient with C++.
If at least a few of the bullet-points above apply to you, then Free Pascal and Lazarus are definitely worth a look!