I'd rather not comment on current popularity of Delphi, Free Pascal and family. I won't touch commercial situation with a ten feet pole either.
But I would like to mention what exactly made Delphi so nice to work with: language enabling design-time information, run-time type information, flexible memory management (some of it automatic, but also possible to do it manually), 95% of time safety but still possible to mess with internals, component architecture, clear exception handling and a very nice community.
Of course, I only mentioned language-level goodies. But then there was the best database access, rich GUI applications, etc. And my favourite: compiling big projects in seconds.
yes/and the superb GUI designer .. Now look at QtCreator or how we build web apps .. it's all a joke, in comparison.
That said ... the other product with similar GUI design system was/is ... VB :)
Yes, the Delphi GUI designer was and still is the best there was (unless I have some kind on nostalgia glasses on accidentally). I started my dev career on a Delphi CRM project in 2006, then years later when I had to work on an Android application the first thought was "You have to be joking, this is how you desing an UI?". Also used Qt a lot between these two.. So, currently the best UI designer and framework is Qt for me. Everything else seems atrociously complicated and just.. developer-unfriendly, needlessly complex.
I've also worked on a Delphi based CRM and I've wasted man months of my life time on a task we called "checking forms". You see, Delphi's UI designer is (was?) pixel based (widgets have fixed x/y/w/h), but strings translated to different human languages have different lengths (in pixel). (Complicated by dynamically calculated and variable length strings.)
And so for every release, for every language version (of which there were like 15), engineers would click through every single form in this product. Then fix any widgets were the text was cut off specifically for that language manually in a shitty commercial i18n tool that can show you Delphi forms, but only the outlines of controls.
It took an engineer about 3 weeks of effort to go through the product in one language. I may never forget what "Ok" and "Cancel" mean in several languages I otherwise do not know at all.
Java and C# changed everything for me with their constraint based layouts. I believe later Delphi versions added that, but it was definitely after others lead the way.
(Maybe there was a better way to do it with Delphi, but this was >10 years ago ago, and the product was _old_ even back then, and it was my first job and I didn't question why things were done this way.)
Delphi was first released in 1995. Screen real estate at the time was very different. When people started using measures other than pixels there was a huge codebase using them already.
The translation systems were really atrocious. I had to develop one myself because the ones that I evaluated were useless.
It took me a couple of weeks, but once I found the right (and only reasonable) way, with the help of library introspection features it was very easy to add new automated translations.
I wrote it down in my defunct blog, 15 years ago. I guess you didn't find it at the time.
Lazarus IDE is stuck in its Delphi 7 interface for years while Delphi was seeing fast iterations past years. Have you seen latest Delphi (10.4.2 from Feb. this year)? But most importantly did you tried its godly compiling speed?
You can try its Community Edition. If you're a business building a commercial application then I doubt the license fee, while expensive for small developers, is expensive for the business too.
Having worked extensively with both WinForms and Delphi GUI designers, I consider WinForms far better.
WinForms designer is actual C# code, you can copy and execute that code outside of the designer. It's possible to search for references to a control in the designer, just the same as any other code. Often in Delphi, trying to accomplish the same thing in code as in the designer had a very obscure relationship. WPF feels much closer to the way Delphi did things, where your GUI is defined in different format than your code.
In WinForms, creating a new control requires, well, just write a class that descends from Control, compile, and then you can start using it. In Delphi, creating a new control means you need an independent project, compile it into a package, and figuring out how to install it. I remember fighting Delphi trying to understand the package management system, and it was way more complicated.
In WinForms, when you design a new control, it actually executes your code, so design time behaviors actually reflect what will happen at runtime. I remember having stuff in Delphi where a large control would be collapsed into a single line, and you couldn't actually tell what you were working with until you run it.
Things changed very quickly. I was writing a warehouse management app around 2000 and my first version was in Delphi. The sql components did require additional install and libraries. But v2 was in PHP and served over the Internet as that could run with no client install whatsoever- just a browser. It was much easier to manage the dependencies on my side and not worry about customer antivirus blocking the install etc.
There was a joke about Delphi convention being canceled because one dev got sick, second had a funeral and third one could go but, what would he do on his own?
> I won't touch commercial situation with a ten feet pole either.
Why?
I mean, Delphi seems a good language... what prevent you from developing with it?
I think the parent commenter’s issue with Delphi wasn’t technological but rather the “commercial situation” - that Delphi is proprietary and a bit expensive, which is both an annoyance and potentially a serious liability. Especially given that Delphi, while far from dead, is in a tenuous market position.
The community version of are Remobjects Elements is a joy to use. I am using it in a professional/commercial manner to write closed source libraries for iOS, Android and Wasm all written in Swift.
>Lazarus is pretty good, although somewhat unstable
The most serious problem I have with it (I can't afford Delphi, or I would buy my way out) is the lack of actual documentation. Sure, there is a wiki, but it is just the output of a program stripping docstrings, nothing actually useful when you just need to use a part from a given library.
There are no working code examples, or tips about corner cases, etc.
Turbo Pascal had very good documentation, and it got better over time.
“In Search of Stupidity” has a chapter on Borland if I remember correctly.
Basically they decided that they did not want to serve millions of developers that loved their product but to instead focus on fewer, bigger enterprise accounts.
This left the market open for Jetbrains to take over the loved-by-devs position and they learned that the books were right: in tech, the low end always eats the high end.
I wrote a hypertext system in Turbo Pascal - this was before NCSA Mosaic. What sold me was that it was one of the first IDEs. A friend mentioned that, when the compiler found an error, it would bring up the editor and position you at the error. This was huge! Plus, it selling for maybe 1/10th the price of other compilers.
I also wrote a hypertext-like front-end with Turbo Pascal, pre-Internet, back in the day .. there was a 3rd-party UI framework that made it so reasonable to mix graphics and GUI elements in MSDOS, so .. we made a bunch of internal company apps that rendered the data off the network, allowed the execs to point and click things, change graphs, etc.
I remember seeing a plethora of amazing GUI plugins for Delphi too ..
One language feature from Delphi (or Pascal?) that I wish modern languages had is class properties
No getter/setter bs. When creating a class you declared a field a property, it looked like this
type
private
FBar: Integer;
procedure SetBar(Value: Integer);
published
property Bar read FBar write SetBar
so you specified what method was to be called when assigning to the propery and when reading from it. You could start with both read and write accessing the field directly and then later make them use getters-setters while keeping the class interface the same. Somehow this knowledge got lost by designers of modern languages unfortunately :(
In python nowadays you use data classes for that. Essentially nice with the frozen attribute. Before that there were named tuples - still useful to subclass instead of frozen data classes, as long as you don't need inheritence or any of the advanced data class field attributes.
Lazarus is nowhere near as polished and nice as Delphi, despite having years to get it to that point.
There are no native GUI components, everything is the same old and ancient custom Lazarus VCL design. Why can't I just drag, drop, and use a native Qt5 component?
They struggled for years getting a dockable interface, and it's still shockingly bad bordering unusable. The community seems stuck in the Delphi 7-interface era.
I used to love and use Delphi. It was my first "proper" programming language, and it's what I learned. But I just cannot advocate for its use in the current climate, especially after having been exposed to other developer communities and the superior tooling and availability. I try to go back every couple of years or so and try to use it, but it's just not there.
Last time I used Lazarus I could figure out how to layout controls. I was also disappointed by the control selection, although it was interesting watching the entire IDE recompile when I pulled in a 3rd party control.
That sounds great, any pointers to get started writting more complex apps? In particular I can't seem to find a proper description of the memory system (when do I need to manage memory myself) and strings (it looks like those are managed automatically, but not? And there are like 4 types of them? Which would I need for UTF8?)
I couldn’t figure out how to do API calls, get tokens, etc. Stuff that is necessary for most applications today. Would love to see more example apps that involve networking
But it doesn't really have the sort of structure that one would expect from a mature web framework, feels a bit worse than PHP (no automatic (de)serialization of objects, path variable and query parameter expansion, middleware etc.).
Is there anything like Spring/Django/Express.js/ASP.NET Core in the world of Lazarus/FreePascal?
Of course it's unfair to expect that Lazarus would have support for everything out of the box, so are there any external frameworks that are as mature as any of the above?
So, to the best of my knowledge, the answer here is "sort of" (don't expect things to be as polished as something like Xamarin or Kotlin, or even Dart/Flutter, but with enough time you could knock something together).
> Today Delphi is still extremely successful compared to Oberon
Yes, but not compared with just about anything else. I used to make some of my living as a Delphi consultant, but I had to give it up as you couldn't make any money doing it, particularly when compared with C#, C++ and Java.
Do you suppose Delphi would have wider adoption if it were open-source? E.g. are the Delphi language features and ecosystem compelling when compared with more widely adopted languages with a community governance structure?
Delphi would have a much wider adoption if the compiler was open source and the IDE was propietary and sold only as a subscription, that is, similar to Jetbrains Kotlin model.
Unfortunately it will not happen because Embarcadero current strategy revolves around milking their existing enterprise customers while their IT policies require that an aplication in production is built with components that have a support contract in place.
Ironically, when I watched the Kotlin conf, that seems exactly where JetBrains is trying to drive Kotlin, boosted by Android's adoption, trying to make a Kotlin eco-system out of it.
- if you’re alluding to the idea that Kotlin would be driven in the direction of closed source compilers and tooling in order to “milk” enterprise adopters: that would require a bizaare set of changes, including changing the license of both the tooling and the compiler - neither of which require copyright assignment, so JetBrains are not even free to do.
- if you’re betting on an open compiler but closed tooling, again that would require changing the license of the tooling, which JetBrains is not entirely free to do since it does not get assigned copyright on contributions.
I don’t know what agreement JetBrains has in place with Google, but I’d wager it precludes making Kotlin proprietary.
I am alluding to the tooling features only available in Clion and Enterprise version, alongside the comprising language design to be able to satisfy JVM, JS, Native, ART and WebAssembly.
And the active role to make it a InteliJ language for most part, withdrawing support for Eclipse.
I don't understand what you and grandparent are trying to say; can you explain in more detail about the parallels you see between JB/Kotlin and Borland/Delphi?
Delphi fall apart because Borland trying to grow bigger than they could chew, ignored their independence developer customer base and turned into enterprise customers as their main selling target.
Now after a couple of changing hands, about 4 of them, they are trying to grow back the numbers of the small shops.
Likewise JetBrains seems to have forgotten the JVM roots of Kotlin and is now trying to go beyond JVM, comprising language design choices on features that don't have the same semantics, e.g. value types on JVM vs JS/ART/Native, or the incompatible memory semantics of immutable types on Kotlin/Native.
I meant that it gives Kotlin adopters the sense that there is no vendor lock-in on the code they write, while at the same time they keep a strong bind on the present and future market IDE for Kotlin (if a competitor appears, Jetbrains will be first to market for everything Kotlin so they will have a persistent edge), capturing with the IDE the dollars of those who seriously plan to develop for Kotlin.
The fact that they have a freemium model is irrelevant to that goal of owing the Kotlin IDE space.
The free offering you mention is used both for funnelling or for having customers do the market segmentation themselves, as there are customers that want to pay for everyone in the team, there are customers who want to pay for only some of members of the team and those who do not want to pay for anyone in the team.
> The next thing is also fairly straightforward: we expect Kotlin to drive the sales of IntelliJ IDEA. We’re working on a new language, but we do not plan to replace the entire ecosystem of libraries that have been built for the JVM. So you’re likely to keep using Spring and Hibernate, or other similar frameworks, in your projects built with Kotlin. And while the development tools for Kotlin itself are going to be free and open-source, the support for the enterprise development frameworks and tools will remain part of IntelliJ IDEA Ultimate, the commercial version of the IDE. And of course the framework support will be fully integrated with Kotlin.
I don't see it getting wide adoption, but it's not bad for open source. But compared with C# (which is basically Delphi as it should originally have been, by the same designer) - nah.
Viral expansion of any tool depends on (pardon the pandemic reference) a super spreader event or 10.
Success needs:
1 A killer app. Pascal/Turbo Pascal, Email/nascent Internet, VisiCalc/Apple II, 123/IBM PC.
2 decade long over night success like Python
I acquired my "10K hour" badge with Pascal in the late 70s (CDC Cyber 6600) and Mid 80s (PC) and then again with Perl (late 80s to early 2Ks) when each of these
peaked. Coming back to the 2015+ versions (Lazarus / Perl 5.24+) of both was nostalgic but the communities were in the backwaters of programming due to viral success of some many others.
A compelling event would have to happen to elevate them again. It could happen: Something pushed Ada to almost triple its "popularity" ( to < 1%.) According to PYPL (https://pypl.github.io/PYPL.html) in the last year.
It will get it, eventually. It can produce native executables without cross compiling on ARM systems too, which is a huge selling point to me. Think Raspberry PI, other small ARM boards, etc. and the PinePhone too.
C# does not compile to native apps by default unless you're using dotnet core or whatever it is called. Powerful language sure, but there is definitely a bit of a divide between the languages just because of that even if they have a similar syntax and high level design
Well, Microsoft did and do make money from selling development tools and programming language products. Sun of course nearly went bust and were taken over by Oracle. So, maybe not good examples?
Java had a massive push by Sun.
If you have a old java codebase, it is easy to "wrap" around a big proxy and continue to expand it in Java, without learning a new language.
Language library is quite well optimized.
I like Pascal but its scope rules are Crazy compared to C/Java/C#, nerveless Pascal compiler is reported faster than Java one
> I like Pascal but its scope rules are Crazy compared to C/Java/C#, nerveless Pascal compiler is reported faster than Java one
Admittedly a long time since I used Pascal proper, but my recollection (and a quick search seems to confirm) that its scope rules are "simply" lexical scoping. Variables are visible only within the area they are declared and not outside, and variables can shadow variables from a higher level. So a global variable can become shadowed by a procedure variable. That's pretty much the same as the other languages use.
At least in Germany there is still enough to be made, that guaranteed an yearly conference (pre-covid) and regular presence on Windows and .NET developer magazines.
Pascal to this day remains one of the most readable languages around. It's not fancy, it's verbose, and very clear. I think the only reason it fell from grace is the simple fact that it came from an era when best implementations of it were commercial, and that's not something that is acceptable in this day and age.
> I think the only reason it fell from grace is the simple fact that it came from an era when best implementations of it were commercial, and that's not something that is acceptable in this day and age.
I love Lazarus, and Delphi before it, and Pascal before that ... but I gotta say, the language, readable though it is, is a pain in the rear to write.
An instance of a class is not the same thing as an object.
By default, the file open/read/write/close routines don't return error values so the caller has to do extra work to check statuses after each use of these functions (IIRC, those error codes from Assign(), Reset(), etc weren't thread-safe either!)
Some conditional expressions cannot have parenthesis (compilation error) while other conditional expressions must have parenthesis (also a compilation error).
Some builtin functions can't be easily 'wrapped' because while the function may take variadic arguments, the language doesn't allow the programmer to write variadic argument functions.
It's death by a thousand cuts; each little problem, surmountable on its own, adds to the overall friction when developing.
What I really like in Pascal:
1. Programmer-defined range types: enums are not a replacement for those.
2. Bounds checking on arrays; I'd rather crash with an exception than silently overrun the array.
3. Nested functions (although, now with almost all languages supporting anonymous functions nested functions probably aren't really needed).
> An instance of a class is not the same thing as an object.
I have no idea what you mean here, sorry.
> By default, the file open/read/write/close routines don't return error values
Those file IO methods are for backwards compatibility with Turbo Pascal. They haven't changed semantics since DOS. They don't support Unicode. They are heavily deprecated. Today, try using TFileStream.
> while the function may take variadic arguments, the language doesn't allow the programmer to write variadic argument functions
Now, granted, my knowledge on Pascal, Delphi and Lazarus is qite old and I've not used any of them for a long time, so if I'm making errors in anything I say below, then please accept my apologies in advance :-)
>> An instance of a class is not the same thing as an object.
I have used it and was not as unhappy with it as I was with the Standard Pascal file IO functions. I was never able to figure out from the exception why a TFileStream method failed. The most you could infer was that an error occurred, but not what error.
This makes for a very poor interface to the user in the resulting application, as they have no idea what to do to fix the error before retrying. In most other languages (that Delphi and Lazarus compete with) you can let the user know what they should do to fix the error before retrying.
> You can consume variadic methods written in a C library,
That doesn't apply to what I was saying. I meant that a programmer could not write a Pascal procedure that wrapped a variadic-args Pascal procedure. C has nothing to do with this.
This is occasionally useful (say, for logging), and its ommission is one of those tiny things that add friction.
With all that being said, I still prefer doing native GUI apps in Lazarus to almost everything else out there. It's insanely readable even after a prolonged period.
I am not sure how Lazarus implements stuff behind the scene but I can tell you 100% for sure that in Delphi every declared class has TObject as ancestor class, so when you instantiate a class in Delphi, you are creating an object.
> I am not sure how Lazarus implements stuff behind the scene but I can tell you 100% for sure that in Delphi every declared class has TObject as ancestor class, so when you instantiate a class in Delphi, you are creating an object.
Like I said, my experience is quite old (circa 2004 with Delphi), but last I used Delphi, it functioned identically to the way that link for Lazarus said it did.
You could create your own class, then instantiate it, and what you got was different from creating an instance of an object.
Lazarus doesn't have GC, but strings are handled by automatic reference counts, and everything complex is an object with create/delete, so manual memory management isn't really a chore.
There is a hierarchical namespace based on units, and also there is lexical scope.
When I first tried Java, 25 years ago, after learning Pascal/C/C++ at Uni first, my first pet-peeve with it was the fact that I could not declare global variables. Coming from Pascal and C/C++ that was a bummer. I had to declare a class then inside that class go declare my global variables. Imagine my frustration that instead of just typing "globalHandle = 25" I had to write instead "mumuClass.globalHandle = 25". Real productivity bump right there!
What killed delphi were its proprietary closed roots. With a single vendor with erratic market history behind it, it was risky to use it for anything that was needed to be updated frequently and last long.
Partly. But let's not forget Microsoft actively kicked Borland in the guts by withholding API information, and hiring away Borland's key figures. Everybody saw it and accounting for Msft weight (especially at that time) it was safer to bet on Borland's demise. I think it played bigger role then any erratic behavior.
Betting on a single OS which they didn't control, soon abandoning kylix, would not help either. Combine this with license prices and delphi lasting so much is both a miracle and testament to their quality. But definitely not something recommend today.
They need to provide tooling at the same level, otherwise they will only succeed in niche areas where security is the top level concern, and good enough static analysers aren't acceptable.
Think of Qt, WinUI, CUDA, Unreal, Visual Studio debugger, C++ Builder kind of tooling.
Hmm, but aren't these languages easily compatible with C and C++. I know in Ada++ you just have to link the library at build time and generate a pkg based on a header file.
I suppose though that you are right. A majority of modern programmers probably view sophisticated tools and pre-built packages (a la NPM) as necessities and hardly care about performance or code quality.
It's now 3 April, Ada++ was announced on 1 April. If you're the author, congrats on the commitment, but it literally just changes begin and end to { and }, is to :, and a few keywords, like procedure to proc. I mean, it's more obvious when you look at the case example:
case Variable:
when 0 => Put_Line ("Zero");
when 1 .. 9 => Put_Line ("Positive Digit");
when 10 | 12 | 14 | 16 | 18 =>
Put_Line ("Even Number between 10 and 18");
when others => Put_Line ("Something else");
}
Where's the { to go with that }? Oh, that's right, the : is replacing is:
case Variable is -- was : above
..
end case; -- replaced by } above
and there is no {. It may have made more sense to go Python-style and use significant whitespace.
And regarding package management, Alire does exist and is starting to become interesting for Ada users. The list of crates is still small, but it's functional and (somewhat) easier than managing it manually.
"Sometimes I wonder if the failure of languages like these - along with Ada is purely aesthetic one."
Possibly part of the reason. Pascal has a very readable syntax, but for some (most?) programmers it is too "verbose" and that is enough for them to never consider it. This is probably true of any language labelled "verbose".
Python and Ruby advocates probably feel these languages have found the right level of conciseness and readability. But everyone has a different opinion. Of new languages, Nim and Julia seem aiming for the same balance: not too terse, but still easy to read. Have they succeeded?
I find it fascinating that C's influence on language syntax continues today with new languages (e.g. Rust, Zig) in a way that Pascal does not.
Turbo Pascal, Borland Pascal and Delphi all suffered from the curse of units. Units were great, way superior to C/C++ compilation allowing fast compiles and efficient stripping of unused code. But they were version incompatible. If you lacked the source code for a compiled unit, you could never move to a later version with it.
But give it its due, the stuff you could do with Delphi for example COM made it probably the only Win 32 compatible language to compete with C++. It was the Betamax to the VHS of VB...
Units between versions were mostly not a problem due to the culture.
Virtually all third party commercial libraries had source available, which had a raft of benefits (even if you often needed to pay more for the library to get the source.)
Meanwhile for other languages, libraries were often sold without any source, and you were royally screwed if you had a problem later.
The forerunner for Delphi was Turbo Pascal. Before it became Turbo Pascal it was called Compass Pascal and then Poly Pascal (it was sold by a danish shop/company called Poly Data).
Anders Hejlsberg wrote the first Compass Pascal compiler when he was 16. And it still lives on in Delphi so many years later. Anders is now driving TypeScript development at Microsoft.
I have written at length, in past Pascal posts, about my affinity for the language in my early days... specifically Borland Turbo (later Borland) Pascal[0].
I ended up hacking on some leaked Telegard source code, decided to scrap it after discovering something I thought was suspicious and realizing I couldn't expect to understand every detail of these thousands of lines of code that I shouldn't have had in the first place. I ended up completely rewriting it in time to run it on my own, and a few friends' BBSes for about two years until we all found romance, the internet or both.
Just thinking about one of the reasons why I did the rewrite reminds me of how incredible that language/ecosystem was--given the early-90s when I used it. The "final nail in the coffin" for me was the code that authenticated a user. Bear in mind, this is the early 90s. You had a "handle" and a number, which a 16-bit unsigned integer (0-65535), assigned sequentially with the admin always being "0", and you could login with the number. Passwords were not only stored in plain-text in a relatively readable format in a file on the drive, but the Admin panel helpfully displayed the user's password every time a 'sysop' viewed a user's account. The background is provided to make clear: this was not a complicated login routine designed to avoid side-channel attacks, perform string comparisons in deterministic times, etc -- if they were, it'd be an amazing waste of time given the total disregard for security throughout the code (and most projects of this era)... and if it were, I wouldn't have been a good enough developer to even identify it.
However, this code had a few `goto` statements, and some inline assembly. The three places that had inline assembly in this code were the ANSI implementation, that I wrote, the 16550 UART driver, that I wrote and this login routine that I did not write and as far as I could tell had absolutely no good reason to be there. After hours of refactoring, I broke the code out into "code that logs a user in" and "code that makes something"; That "something", IIRC, was a round-about way to generate a "master password" that could be used to login with any account (and `0` was `root`). During testing, I discovered that my "skipping the code that makes something" part resulted in an empty string value which meant I could login with no password to any account. I rewrote the whole login routine, and then the whole thing.
Would kind of love to look into that, now, since I'd actually be able to understand what is going on, now (maybe!).
[0] IIRC, the IDE fit on a 5.25" floppy, and Version 5.0 had a whole bunch of new, elaborate, syntax highlighting. It was amazing.
Wirth's article also "ignores" Ada. But that's fine, the article is a personal account, not a survey of all Pascal family languages. The penultimate sentence:
"The sequence Pascal—Modula—Oberon is witness to my attempts to achieve [perfection]."
I seriously view OCaml as a descendant of Pascal. If you look at some of its imperative syntax (for loops, while loops, mutable assignment), comments (* ... *), modular programming style (distinguishing interfaces and implementations), and fast compilation speed, it's clear that the OCaml engineers took a lot of Pascal's (and its descendant Modula-2) lessons to heart.
At the same time, OCaml's ML heritage greatly simplifies the majority of the syntax (getting rid of semicolons, making identifiers case-sensitive), and bringing the expressive power of functional programming.
It fuses together the best of both worlds. It's why I often say that OCaml is like a midpoint between Haskell and Go. The 'Go parts' are from their common ancestor, Pascal.
Go is influenced by several languages, and Modula and Oberon are at the top of that list. Robert Griesemer, one of the designers of Go, worked on Oberon at ETH Zürich.
The famous "Why Pascal is Not My Favorite Programming Language" article was written by Brian Kernighan, not by Ken Thompson (who created Go). Kernighan wrote the books about C and Go.
I think that very much depends on your definition of "descendant", given how many language designers mention how much they were inspired by Oberon, Modula, or even just Wirth's writings in general. This is both on a technical level and on a language design level.
Historically speaking Go would qualify as being descended from Oberon, philosophically none of the current crop of languages would qualify, most of them being too complex and brining in elements Wirth wasn't too fond of (like most of FP).
But I would like to mention what exactly made Delphi so nice to work with: language enabling design-time information, run-time type information, flexible memory management (some of it automatic, but also possible to do it manually), 95% of time safety but still possible to mess with internals, component architecture, clear exception handling and a very nice community.