I'm not sure what the rationale is for maintaining the text mode FP IDE. It seems kinda quaint in 2022 to maintain a recreation of the old Turbo Pascal editor, but I'm so glad that it's there.
I think you just answered your own question. It's there because it's functional and works on most if not all of the supported developer desktops. Of course, it won't win any beauty contest but I suspect most of those using it probably won't either.
It handily wins a beauty contest among TUI IDEs, though. The only reasonable alternative that even supports a similar workflow (with CUA-style keyboard bindings and all) is Emacs, and text-mode Emacs while fully supported is quite clunky.
One of the things I found interesting about TUIs is that it forces your design to be on a grid, defined in units of characters. It's easy to make a column of fields that all line up on edge. If you want any spacing between fields at all, it forces you to make that spacing fit to character-width grid cells. So, in a way, it's a little easier to semi-accidentally end up with a clean, good-looking design in a TUI, if someone is being just a little thoughtful about their layout, than it is to be in a full raster-based GUI with pixel- or percentage-based positioning.
What I'd like to see are TUIs that embrace terminals running on large, high-resolution displays. We don't need to be constrained to 80 columns by 25 rows, or whatever.
There's a lot to be said in favor of gridded designs. Not only do they default to a clean look, they bias you towards static sizing, which means spending effort on the defaults.
80x25 grids with monospaced characters are pretty arbitrary of course. But you can use grids on top of other systems, it just gets more fiddly.
Every time I fire up fpc to fool around and think about whether I would actually do something non-trivial in Pascal (the answer is 'no') I also fantasize about a very opinionated, very non-standard, text-mode Linux distribution loaded with DOS-style TUI utilities and applications. Something like that would be fun to run on devices like old routers.
A long time ago, a guy created a theme for gtk+ which used text characters to draw all the widgets. He also created a text mode gdk backend. Combine both: you have gtk+ apps running on the terminal.
I mean small and really opinionated - the goal would be a look and feel more like a bells-and-whistles DOS setup than like Unix.
Inspired in part by https://prog21.dadgum.com/74.html
You could hack the code of your favourite IDE (e.g. add a macro, modify the source) to google whatever is currently selected (e.g. WriteLn) by you with
an additional qualifier
site:stackoverflow.com
for instance
WriteLn site:stackoverflow.com
So it would open up the top result of Google's SERP, i.e.
Good to see Pascal/Object Pascal getting some renewed love, after all the C/C++/C# wars. Way too many act like "there can only be one", versus explore and appreciate what various languages and tools have to offer.
I use Delphi and Lazarus just fine. Delphi for windows GUI applications and Lazarus for multiplatform GUI applications. I use multiple languages for various tasks and Delphi / Lazarus are hard to beat for quickly whipping out lean and mean GUI apps. As for "language being "cool" - I do not care what the general public thinks and use what gives me the best ROI for particular situation. Operating as a business really clears one's mind.
First learned programming in Turbo Pascal and have fond memories of that IDE. Thanks for posting this. Would love to learn of a framework for reconfiguring this UX to do whatever I want (menus, scripting, etc).
Ha, I remember ages ago, some guy in my computer science class was being a jerk to me, so when he wasn't looking, I leaned over to his Turbo Pascal IDE and spaced out past the right margin of the first line, and typed begin end. Which made everything below that in the entire file a comment. His program executed quickly, and never did anything, and you had to really pay attention to see the UI hint that suggested there was text to the right of whatever column was the edge.
I thought it would be a good prank as a form of revenge, but he kept getting angrier and angrier and eventually I was too afraid to confess. The teacher had wandered over and was getting exasperated too. I think eventually they assumed he had a corrupted network drive and just nuked his entire network account and set up a new one with a new username, and now suddenly his compiler "worked" again. Heh.
Welcome to Delphi 1. My first job was using Delphi and it was 1.0 we used to do most of the dev till we managed to go 32bit (circa 1998) and the IDE had absolutely no autocompletion nor did it have any suggestions. You needed to know what you were typing. I think it was Delphi 3 that introduced Borland's version of code completion (I want to say it was called "Code Sense", but that might be the Microsoft tools.) Even that was terrible till Delphi 5.
I think a lot of modern coders really forget how much you used to need to know. Even stuff like "jump to definition" wasn't a thing IIRC back then.
> I think a lot of modern coders really forget how much you used to need to know. Even stuff like "jump to definition" wasn't a thing IIRC back then.
Also came through that era, I don't miss it, modern tools are abstractions for the brain (and a logical progression from what we had before).
Everything is so much bigger and more complex than it was (mostly because things are bolted together from a large number of libraries from different places with their own subtle or not so subtle conventions).
In days of you had the languages standard libraries and libraries you wrote yourself and very rarely some Hallowed Third Party Library that was handed down on stone tablets by the Prophets of the Finance Department.
Autocomplete requires CPU cycles for the lookup and "jump to definition" requires an index to be built somewhere (CPU again, but also mem/disk space). Modern computers can handle both efficiently nowadays, but not a simple task back then.
My memories of circa 1998 are rather different from OP. That's the year when Visual Basic 6 shipped, and that IDE had code completion working perfectly. Delphi 5 was out in 1999, and also worked great in that regard. Even C++ IDEs had code completion which worked decently well so long as templates weren't in the picture.
Pascal/Delphi is actually almost a perfect language to write a smart editor around: the grammar is highly regular and requires minimal lookahead to parse, and definitions always precede usage.
You need to remember - 1998, no Windows software was particularly "free". If you wanted to upgrade, you paid. The company I was working for was stuck at Delphi 1 (as the code was 16bit and had an in house 16bit DLL that needed to be replaced and was core to the application.) Some of the other products were on Delphi 2 or 3. Once we reengineered the DLL (it was using pure 16bit assembler to implement a look-up tree in memory, so it took them a while to make a 32bit version), we moved on. I think we were on Delphi 4 by the time I left around 2000.
Next 3 companies I worked for were using Delphi 5, despite Delphi 6, 7 and 8 existing by that point. Same reason - if it isn't broken, you don't need to jump to the next best thing.
Also worth noting - the company I directly worked for after the one above was a Borland partner in the UK and Borland outsourced training and consultancy to them (I was under Borland NDA) and we therefore had access to pretty much all the Borland software (I have a copy of the first Kylix Beta somewhere still I think)
I used to hack away with Delphi back in the day. I tried getting back into it with Lazarus, but I really find Pascal syntax painful to work with again for some reason. It just has some strange conventions and I feel like I'd have to actually read a book to become proficient. A very different experience than learning, say, Kotlin where I could essentially pick it up knowing other OO languages and having a good IDE
I also worked with Delphi many moons ago and loved it, therefore also like Lazarus a lot, although I agree Pascal syntax could be made more modern.
I recall one day I had to access data packets using the equivalent of C unions; the language allowed them, but the syntax was quite odd.
Should one day Lazarus and the LCL be converted to other more popular languages, it would easily become a killer product.
Pascal equivalent of C union is a variable record. Nowadays in Delphi (Free Pascal still doesn't have that) records can be used as classes, with their own members and just like classes, their functionality can be expanded using some sort of inheritance mechanism called "helper". Actually, in Delphi, the only difference between a class object and a record object is that classes allow dynamic allocation while records are instantiated on stack from beginning all the way to the end of the program.
You should try Delphi nowadays, it has plenty of modern languages concepts implemented. Not to mention the compiler speed and the cross platform capability for all OS'es that matter.
I just looked it up. The lowest-priced package is $1,599. A "Free Demo" doesn't interest me. I assume Embarcadero has some really good customers who are very satisfied with what they deliver. But they're not exactly cultivating a new user base with those terms.
And yes, Delphi has a small but loyal following. But personally, I feel more comfortable relying to standardized languages (preferred: ISO) and among those a pick with easily recruitable talent. So I wouldn't recommend a new production development in Delphi myself.
"Records as classes" are different from "variant records". And they do exists in either Delphi and FreePascal. In FreePascal those are called "advanced records". You can get better help on those here: https://wiki.freepascal.org/Record .
> when you want to do more than quickly update a few files, you need a full Integrated Development Environment (IDE).
I remember that when I was developing with compiled languages ages ago (C and Java) I had an emacs configuration to compile and debug from within the editor. Eventually I gaved up emacs when writing Java and switched to Netbeans and Eclipse. Then I switched to interpreted languages (Ruby, Node, Python) and I'm using emacs again. Plain modes for those languages, no autocompleters except a very basic language indipendent one and it works like a charm. It also works like that with Elixir and Phoenix, which autocompiles itself. It's been probably 10 years since I installed an IDE on one of my computers.
I think the main problem with trying to program Java in a text editor is the fact that we need to import every single package separately, or even worse: every class seperately.
Doing Java programming in, say, Emacs would be fine if it weren't for import hell.
Some notes. I assume this is for Linux, based on the beginning of the article.
> It used to be possible to run a terminal session 'attached' to Lazarus, so that it could be debugged from the IDE, but since a previous update this always seems to fail on my PC.
There could be some lingering settings. In my Lazarus build (from git, so it has the latest and greatest features and bugs) it is possible to run a program using a separate "launcher" from Run -> Run Parameters -> Check the "Use launching application" and then type something like "xterm -e some command that runs your app". In fact in my PC it pre-fills "/usr/bin/xterm -T 'Lazarus Run Output' -e $(LazarusDir)/tools/runwait.sh $(TargetCmdLine)"
This should allow for debugging terminal programs from Lazarus.
> I'm not sure what the rationale is for maintaining the text mode FP IDE. It seems kinda quaint in 2022 to maintain a recreation of the old Turbo Pascal editor.
It provides a basic IDE wherever Free Pascal is available. Note that, e.g., Free Pascal runs on DOS, OS/2, AmigaOS, etc and the IDE works in those environments too (DOS support is also why the IDE "embeds" the compiler instead of calling out fpc.exe).
It also works as a showpiece for Free Vision (also part of Free Pascal) which provides a TUI framework. Sadly, as it is based on the original Turbo Vision, it uses the old "object"-based types instead of "class"-based types, so it misses a lot of useful functionality for programming - but from a user's perspective it is IMO a perfectly fine TUI.
> I'm not sure why this is the default setup, but you need to tell the IDE where to find the Free Pascal files on your system.
This might be some installation problem, on a fresh install FP should be able to work out of the box. Perhaps some distro issue? Try to use the generic tar-based installer from the Free Pascal site and install it system-wide.
> One of the main differences in the interface, compared to Lazarus, is that instead of a tabbed interface it has a series of windows. With the right font size, I actually prefer this interface as it means that I can see several related files on screen at once.
Note that you can have multiple source windows with Lazarus too, right click on any tab and select "Clone in new window" and it will create a new source window you can have side by side with other windows (sadly you can't use Alt+number to switch between them though - but your window manager might be able to do that for you). This way you can have both tabbed and floating windows if you want.
> The biggest thing that I'm missing so far is a good auto complete. The IDE will offer suggestions for completing Pascal keywords but, unlike Lazarus, it won't try to autocomplete your own variables or procedure names.
And auto-completing function/procedure definitions, etc in interfaces section to the implementation section, and symbol renames, and a quick jumps to declarations or between the interface and implementation section for a function/procedure, and a bunch of other stuff :-P. It'd be neat if those were added at some point though.
But i'm not sure how many people really work on the IDE nowadays, IIRC it used to be an external project that was merged with Free Pascal early in Free Pascal's history. I think nowadays even main FPC developers use Lazarus instead (note that despite being joined at the hip, Free Pascal and Lazarus are technically two different projects with each having its own development team).
But having said that and regardless of the limitations, i wrote a very large part of Post Apocalyptic Petra[0]'s code in Free Pascal and the game can be compiled and debugged from the IDE just fine. I did eventually switch to using Lazarus when i started working on the editor though (since i needed the GUI bits) and the standalone "Petra Engine"[1] (which contains only the engine part of the game, slightly modified) is really meant to be used with Lazarus for development (you can build the standalone example game with just FPC though).
Yeah it's horrible. Autocomplete randomly doesn't work. Debugging symbols randomly disappear, and you get thrown into an assembler view. Or even if it works, you can't see the values of variables sometimes. Sometimes it gets better by restarting the IDE...
In a lot of ways neovim can be a TUI VSCode. It supports the language server spec and all that. It does require (kinda complicated) config. But you can steal examples from the internet. There's also the ecosystem of plugins to do fancier stuff like code snippets, menus, status bars, etc.
But I don't do things like jumping to declarations with it. That's likely a thing with some plugin, I just don't know. I generally try to avoid traditional OO languages when I can. I used to use IntelliJ for those, but I have actually switched to VSCode for them and some of the things I've always used vim/neovim for, like larger Go projects.
I make any IDE act like vim because my hands want to do modal editing. That's a thing where my habits impact my perceived ergonomics. If it doesn't support that, I won't use it. It's just too frustrating.
I don't use Javascript except when I have to. If that's part of a TUI VSCode for you, then this may not be helpful.
The LSP, treesitter parsing, debug protocol etc. are good developments, but everything else in neovim is just way different from VSCode. And the vim modal editing pattern is nice for a basic text editor but has pretty poor extensibility compared to a menu-driven program - at some point you just can't do everything with single letters, you need actual, complex commands. So a real T-Vision/TUI conversion of VS Code might still be very worthwhile.
And the vim modal editing pattern is nice for a basic text editor but has pretty poor extensibility…
Nothing could be further from the truth. There are tons of plugins, scripts, tutorials for literally every scenario you can imagine since Vim has (never mind its predecessor Vi) has been around since 1991.
at some point you just can't do everything with single letters, you need actual, complex commands
Vim’s power is its composability. Once you understand text objects (word, sentences, paragraphs) and motions, you can do anything you want.
If you need to repeat a string of commands together, you can record macros on the fly, create an autocommand or a plugin if that’s what needed.
Neovim in particular has LSP support built-in, which gives the editor semantic knowledge of your code, just like an IDE. So renaming, refactoring, formatting, syntax highlighting work better.
This is your annual reminder than vim and eMacs are fully featured and extensible IDEs that support code completion, folding, and navigation by default.
Or, no, you don’t need to use a graphical IDE to develop code, as TFA states.
Thank you for coming to my Ted talk.
EDIT: Don't believe me that VIM is an IDE? Read the threads for elucidation. :)
> vim [...] extensible IDEs that support code completion, folding, and navigation by default.
If "by default", you mean "with the default vim configuration", then this assertion is wrong.
Vim does have a definition-search" feature, but it needs hand-made configuration for each language, and since it relies on regexp instead of parsing the language, it's useless outside of micro projects.
To enable real code completion and navigation, vim needs plugins and external tools. The modern way is to use one of the LSP implementations for vim (I've tried ALE and CoC), but that's clearly not "out of the box" for vim.
It works perfectly well with C by default - with no addons. I will agree, you do need a tags file (though it's is not even remotely hand-made (emacs uses these too)), but the rest is handled automatically, including code completion based on the contents of the tags file.
Code completion, syntax highlighting, goto definition, goto tags... these are all core functions of VIM. Addons just help it work with languages other than C.
In the case of Free Pascal, may I remind you that there is a fully featured IDE called Lazarus which offers all of that plus an intuitive user experience (i.e. you don't have to memorize all the keystrokes before you can be productive, you can find the available commands in them menu and if you use one particular command a lot, you can memorize the keyboard shortcut) and a graphical tool to build your UI and connect it to your code.
In the case of Free Pascal, may I remind you that there is a fully featured IDE called Lazarus…
That’s cool, but if you already use Neovim for other things, there’s a Free Pascal Language Server Protocol (LSP) server for it too [1]. You’ll many of the same features that Lazarus has, like code completion, diagnostics, etc. In fact, it’s the same LSP that’s available for VS Code [2] and it uses Lazarus as a backend.
Too much is being made about how hard Neovim is to configure; if you’re new to it or to Lua, just use LSP Zero [3] that takes care of all of the details of installing LSP, linters, etc.
int foo ()
{
return 3;
}
int bar()
{
return foo();
}
put your cursor somewhere on the "foo" identifier in the second to last line and type "gD" (without the quotes). It should jump to the definition of foo. It's not perfect but works for much code without crazy preprocessor stuff. By default it's file-local, but you can give vim a list of include files to search as well.
Specifically it's one of the 'g' commands (like gg which goes to the top of the file and gG goes to the bottom). Just put your cursor on an identifier and gD (goto definition is the mnenomic).
Vim works perfectly fine with multiple files out of the box, it just wants a tag file for jumping between multiple files and letting autocomplete work with those tags.
This is hardly unique to vim (and emacs) - you can't work on a project in IntelliJ without first setting up a workspace and letting IntelliJ index all those files. The only difference is how the index is generated.
Oh, and `:help cscope` (again, thanks aidenn0). In vim >=9.0 a tagging tool is now incorporated into the base vim install.
I'm so confused. Vim has ctags, and it works, across multiple files.
Granted I don't think vim is an IDE, but you'd demonstrate that better by pointing to the IDE stuff it doesn't do (like debugging, I think, but I debug with printf and only rarely fire up gdb so for all I know it does support it).
Vi is just an editor, but vim is "Vi improved", and the improvements include the sorts of programmability that Emacs is known for, which allow modes to include syntax highlighting, code completion, and so on. It's not quite the same (the beauty of Emacs is that the executable is mostly a Lisp interpreter and the editor is written in the same Lisp you can write your extensions in), but close.
I think you just answered your own question. It's there because it's functional and works on most if not all of the supported developer desktops. Of course, it won't win any beauty contest but I suspect most of those using it probably won't either.