5 ms·

Some months ago i started making a new game engine in Free Pascal[0]. D however was the language i considered the most of all alternatives due to its fast build

Some months ago i started making a new game engine in Free Pascal[0]. D however was the language i considered the most of all alternatives due to its fast build times (at least for DMD) and metaprogramming and compile time function evaluation and code generation abilities that would help a lot to minimize boilerplate and automate things. In fact i chose FPC less for the language and more for other reasons - as a language i think D would fit better. The two main reasons i chose Free Pascal are (both of which are important): 1. There is a strong aversion to breaking working code in FPC which to some extent is also part of the overall ecosystem. Code i wrote 20 years ago still compiles because any new features are made so that they don't break existing code. Exceptions exist, like when how string are handled changed, but that was a quick fix (in all of my programs i only had to apply a single line fix twice). I don't know D's story on that but i've heard that there were updates to the D compiler that broke code (but i don't know how severe that is - FPC also introduced theoretically breaking code almost every version but in practice it is usually extreme edge cases, compiler bugs or very internal things and these latter only change like per decade or so). In general i want code that i know it worked today to keep working in 10 years from today so i can focus on other things instead of babysitting it (i do copy/paste code i know that works from my existing projects all the time - even the engine i linked above contains a lot of code from older projects, the earliest bits being from 2007 or 2008). This is even more important if i decide to switch to a new language because i wouldn't be able to use much of my existing code so any new code i write i want it to be valid for years ahead. 2. Lazarus and LCL. Think open source Delphi or Visual Basic with a real framework and a strong language. Lazarus is a "real" IDE in that it isn't just a glorified text editor attached to a compiler but it knows the language and builds a database of the entire project in memory, which allows for it to manipulate the code for you (this avoids a lot of boilerplate that come out of the verbose syntax Free Pascal has). More importantly it provides a WYSIWYG visual editor for GUIs (very important for tools) and a rich application framework (LCL) that is designed around Lazarus - these aren't independent bits someone stuck together with some glue, they are all made with each other in mind, which provides a more coherent experience than if someone stitched things together (if anything most of the issues Lazarus/LCL has is from things outside of their control, like the backend GUI toolkits). I have used a lot of other GUI approaches, Lazarus beats them all hands down. And as a cherry on top Lazarus is a native app written in Free Pascal itself and is very responsive - it even runs on older Rasberry Pis with relatively low resource requirements. Sadly D doesn't seem to have a decent GUI story, let alone something like Lazarus and LCL. A promising library was dlangui[1], but that is a 3rd party library that looks like the author decided to abandon[2]. Honestly IMO without something that is adopted by the core D developers (and by extension the rest of the D community) i can't see anything flourishing there - it'll instead be a bunch of independent solo devs making their own half-baked stuff for eternity (btw, yes, Lazarus/LCL are technically a separate project but in practice there is strong overlap between the two projects' developers and they share resources). At best you get bindings to Gtk+ but that has its own share of issues and bindings to other toolkits (e.g. wxWidgets) look abandoned. I occasionally check out D to see what is the status wrt the above but for years things do not seem to change. I do hope that at some point D will have a good GUI application framework and a good native IDE that understands the language itself. [0] https://i.imgur.com/1Y5hL26.png https://i.imgur.com/1Y5hL26.png [1] https://github.com/buggins/dlangui https://github.com/buggins/dlangui [2] https://github.com/buggins/dlangui/issues/608 https://github.com/buggins/dlangui/issues/608

CodeSgt 4y ago
> There is a strong aversion to breaking working code Am I the only person who doesn't view this as a good thing? If you want to compile code your wrote 20 years ago, use a compiler version from 20 years ago. Forcing backwards compatability hinders a languages growth and forces it to stick by decisions that, in hindsight, may not have been the best.
- samatman 4y ago
  Reconstructing an obsolete toolchain is a nightmare. I think it's great that there are languages like FreePascal, C, and Common Lisp, which make an effort to think in terms of decades. The existence of these languages frees everyone else up to break compatibility when they want to, because projects which need strong stability guarantees can chose these languages for that project.
- badsectoracula 4y ago
  > If you want to compile code your wrote 20 years ago, use a compiler version from 20 years ago. I want to compile code i wrote 20 years ago alongside code i wrote 10 years ago and yesterday, not just compile some old project. Though even compiling some old project should be as friction free as possible too. The point is that once i write some code that i know works, it should keep working in future versions so i wont have to worry about updates (which is now the case with both Free Pascal and Lazarus/LCL - i even use the development versions directly from the repository). > Forcing backwards compatability hinders a languages growth and forces it to stick by decisions that, in hindsight, may not have been the best. And ignoring backwards compatibility forces all users of the language (which unless it is a toy project, are way more numerous than the developers of the language) to waste time keeping their projects up to date instead of working on new features and/or bugfixes for their projects. Also Free Pascal does have a way to avoid this (to some extent) using modes and modeswitches - the former affect the Pascal dialect being used for a file (which can be mixed with other files with other modes) and the latter enable/alter syntactical features that would otherwise break existing code, thus allowing it to be improved piecemeal without breaking anything else. AFAIK similar features exist for some other languages (i remember reading that Rust's epochs are meant to do something like that though i don't know if files from multiple epochs can be mixed).

CodeSgt 4y ago

> There is a strong aversion to breaking working code Am I the only person who doesn't view this as a good thing? If you want to compile code your wrote 20 years ago, use a compiler version from 20 years ago. Forcing backwards compatability hinders a languages growth and forces it to stick by decisions that, in hindsight, may not have been the best.

samatman 4y ago
Reconstructing an obsolete toolchain is a nightmare. I think it's great that there are languages like FreePascal, C, and Common Lisp, which make an effort to think in terms of decades. The existence of these languages frees everyone else up to break compatibility when they want to, because projects which need strong stability guarantees can chose these languages for that project.
badsectoracula 4y ago
> If you want to compile code your wrote 20 years ago, use a compiler version from 20 years ago. I want to compile code i wrote 20 years ago alongside code i wrote 10 years ago and yesterday, not just compile some old project. Though even compiling some old project should be as friction free as possible too. The point is that once i write some code that i know works, it should keep working in future versions so i wont have to worry about updates (which is now the case with both Free Pascal and Lazarus/LCL - i even use the development versions directly from the repository). > Forcing backwards compatability hinders a languages growth and forces it to stick by decisions that, in hindsight, may not have been the best. And ignoring backwards compatibility forces all users of the language (which unless it is a toy project, are way more numerous than the developers of the language) to waste time keeping their projects up to date instead of working on new features and/or bugfixes for their projects. Also Free Pascal does have a way to avoid this (to some extent) using modes and modeswitches - the former affect the Pascal dialect being used for a file (which can be mixed with other files with other modes) and the latter enable/alter syntactical features that would otherwise break existing code, thus allowing it to be improved piecemeal without breaking anything else. AFAIK similar features exist for some other languages (i remember reading that Rust's epochs are meant to do something like that though i don't know if files from multiple epochs can be mixed).