I used Pascal for the 80's and part of the 90's. Currently use Java. I almost tried Delphi, but my shop moved on to something else between Pascal and Java.
Now the string types have an encoding and the string themselves, too. When you assign a string to a string variable with a type of a different encoding, the string is automatically converted.
But it is causing a huge mess. Especially with existing code. When you have a library using utf-8 and one library using the default codepage, that is not valid anymore. Although you can manually override the encoding for each string, so any string might have any encoding regardless of its type.
I have a benchmark of various maps in freepascal. The benchmark creates strings of random bytes to use as keys.
A classic key-value store is the sorted TStringList.
Now the benchmark of the TStringList fails. Apparently, because it now assumes the keys are valid utf-8 when using the utf-8 codepage as default codepage.
The default codepage can be changed. When I start the benchmark with LANG=C .. it works with the random byte keys. On Windows, the default codepage is usually latin1, so it would work there, too.
Pretty much every shell has its own mechanism for updating the title - the parent comment just shared the `powershell` way of setting the title. I'm confident that if you search for "set title from <your shell here>", you'll find plenty of posts on how to do it.
I am not sure of which specific thing you wish me to give examples of, so I'll start with the positive aspects:
I like properties on objects. They are an elegant way of handling the get/set mess you see in Java. (Which subsequently is also why I dislike how interfaces in Object Pascal are designed, because they don't handle properties well.)
I kind of like the verboseness of the language. Which frankly makes none of the subsequent features, like generics, seem out of place. In a more terse language, like say Go, generics would look out of place in that syntax. But that's style.
As for bugs of Delphi, XE7 is a notorious example. It included a new syntax highlighter that would crash if you typed in a | anywhere in the IDE. And it would crash hard enough to crash the entire IDE.
Where I worked, we primarily used 32-bit programs, but every time you wanted to modify configuration for your project, it always defaulted to 64-bit, forcing you every time to manually switch it back to 32-bit to configure. The user interface has plenty of annoyances like that.
I could go on, as I am just grasping what's at the top of my head. But I don't need to make this entry too long.
EDIT: Can't post any more right now, so I'll add some specific IDE examples of missing features:
Basically, Delphi lacks a lot of 'quality of life' improvements, that other IDEs have seen over the past 20 years. It's mostly small quirks, some of them definitely bugs.
One that's rather unique to Pascal, since it's a one pass language, where you have an interface and an implementation division, is that when you write a method on a class definition, you can tell the IDE to create the implementation for those methods instantly. But if you write a public unit method (that's outside any class), it won't do the same thing.
Sometimes, it will stop suggestion completion, e.g. showing you a list of all methods and properties on a class where you are typing. I think when it cannot compile your project, it stops functioning. Which is often the case, when you are modifying your code.
But the biggest one - for me at least - is how slow it feels compared to other IDEs. It doesn't feel very optimised. Telling it to search for where a function is called (referenced) can take a bit.
Now that every supported Windows box ships with .NET, I would argue that C# + WinForms is the most convenient option to quickly put something together. And C# of the WinForms era was still recognizably a Delphi-like language with Java-like syntax.
Yes, and yes. I did Delphi and VB6 in late 90s before moving onto C#, and I remember being amused at how it was Delphi and not VB skills that transferred the most. A bunch of stuff in the .NET object model - notably, first-class properties and events - was clearly motivated by the desire to have native support for abstractions that were idiomatic in Delphi (but were done "by convention" in e.g. Java). And then WinForms itself is so much like VCL, you feel right at home.
And yeah, it is very specifically designed around rich designer support, which is also very similar to the Delphi designer in practice. Same drag-and-drop experience with controls, a property grid to edit properties and wire up events, anchor-based layout etc. Components can be designer-aware as well, plugging into the designer UX.
I also suggest that those people charged with designing this new unified CPU will have a progress quota. And if they do not meet this quota they will be send to a labour camp. This will surely speed things up!
And just to be sure all is fair you will in charged of defining this quota.
Well electron already allow you to use arbitrary language and acesss almost any native OS api.
So electron is the salvation for hybrid_native desktop development.
Your question would better be:
Is there a salvation for native and cross platform GUI frameworks other than chromium ?
The answer is probably no as chromium beat everything both feature wise, library wise and (yes) performance wise.
Really why native development isn't totally dead yet is because of inertia to learn new technologies and because of shared misconceptions about chromium performance and GUIs framework performance.
This growing gap could have been deduced so many years ago because of a simple fact:
The number of full time employees working at improving chromium vs the number of full time employees working at improving QT, or GTK, etc.
They are order of magnitudes more. And it has deeply increased since microsoft has joined chromium (they have moved a number of employee to chromium probably comparable as if all Gtk + QT devs moved to working on chromium.
Btw, as they both know they can't keep up, they progressively webify (QTwebengine, both use CSS for styling, etc)
We're uneasy enough with Google effectively turning the WWW into a platform under their control with them running Search, Chrome and Android - but this sounds as if the platform might actually extend to "any application with a GUI". (With Apple being the one competitor)
I can’t take this answer seriously. Assuming half of what you claim were true, it would still be terrible for us to cede control of the future to Google. Of course the grim reality is that none of your claims are even remotely true.
This is a classic case of worse is better amplified by Google being in a position of unprecedented power and abusing it to full effect.
Those of us who were old before Google even existed, can see very clearly where this road is leading. On the other hand this is a battle that has to be fought mainly by the younger generation. Alas, it does not seem that we are winning.
Your only point seems to be:
Chromium == Google
Google == evil
Therefore chromium == evil
Firstly chromium implementations détails decisions are just good engeener decisions
Features they intent to implement are just features devs want and or that solve a real limitation.
I defy you to name a few chromium features that made the web worse.
But more than anything, chromium is open source that you like it or not and Google is no longer the only major player I. Chromium since microsoft joined it.
Nothing stop mozilla and Apple to join chromium too.
If there's something you don't like about chromium (and indeed I can sociologicaly infer that it would be something privacy related and not something engeenering related (which is what we should mostly talk but that's not something hackernews understand much).
For such thing nothing stop you from using one of the many privacy focused chromium forks.
I really don't understand this line of reasoning unless you're shilling for Google.
"Nothing stop you from using..."
"Chromium is open source..."
"Nothing stop Mozilla and Apple.."
There is a behemoth in the room that makes all these arguments NULL and VOID. It's called Google and it's ruling its domain with an iron fist. We saw what these sort of arguments lead to in practice, the recent ad-blocking debacle being the icing on the cake. Open source means nothing if you have a colossal gate keeper that is not only in full control but has the power to _dictate future evolution_. All Open Source provides in this case, is an easy excuse, a shield to deflect criticism and this is exactly what you're doing here.
Did we really learn nothing from Microsoft's past that we are willing to overlook an entity that's orders of magnitude more powerful?
I worked in PL/1 for 4 years. Saying it is just "F&%ing works" made me laugh hard! The compilation never failed because the compiler assumed what you really wanted. I got many bizarre programs.
Must have had an odd code base then - I found it nice to work with.
And in my experience Primes pl1/g Compiler did properly assume what a sane developer would want - well there was that one time I had to recompile the entire Pl1 part of our MR system and push it out to all 17 systems :-)
People just don't have enough experience with Functional Programming to really know how awful it is. So now it is the new kid on the block (in terms of going mainstream) so people think it is the best thing ever.
The most telling sign is how many FP languages are in existence today. If it was such a good thing we wouldn't need them all. It is a mess that cause many other types of problems without any clear benefit.
I do get that many people like the FP paradigm, no two humans are alike and people will find different ways of thinking and reasoning about a problem more suitable. Which is OK. BUT it doesn't mean FP is a any better than OPP or vice versa.
Last I would like to point out how Python (OOP) obliterated R (FP) it the Data Science market although R enjoyed a head start of few years and was the Franca Lingua of statisticians.
R was used by statisticians, but python was used by every non-cs researcher who needed something more than matlab.
Python didn't beat R because it's OO. It won because of its existing popularity (with many people learning it in their intro programming class) and the massive amounts of open source software built for it.
> People just don't have enough experience with Functional Programming to really know how awful it is
This is just anecdotal, but I've used a FP language full-time for the last two years with several other engineers and ramped others up on the codebase. It has its own challenges but it's significantly easier for me to reason about than OOP - less bugs, easier to maintain, easier to parse. I can't see myself ever willingly going back.
It might be helpful to know what problems you think FP has, if you have a significant amount of experience with it.
My point that it beat R although it is OOP. This is to show that OOP is not inherently bad. Many people find it useful to the point the 'preserved' advantages of FP are not worth the effort.
> This is just anecdotal ...
My anecdote story is very different than yours. To the point if one of my engineers will ever suggest FP again he will get fired on the spot.
> The most telling sign is how many FP languages are in existence today. If it was such a good thing we wouldn't need them all.
This is a silly argument. FP means only first-class functions and immutable values, and the vast majority of FP languages agree on those.
But there are many other design decisions for a programming language - type system, laziness, purity, homoiconicity, and whatever other features, paradigms or constraints people might find desirable. THIS is what explains the diversity of FP languages.
Btw, there's the exact same phenomenon in OOP languages. They all agree on classes, and differ on hundreds of other aspects.
Python "winning" has more to do with it being taught at pretty much every university in into CS courses these days and less with it being a better suited language for it. Besides, outside data science R still reigns supreme when it comes to statistics. Data science is a hype right now, but 99% of what is called data science is basic statistics. Python is also rarely being taught in biology, or economy or psychology departments. Its either R or Stata or so.
We don’t have more FP languages than OOP languages, and several languages that are considered FP have their own implementation of OOP (OCaml, Common Lisp...) in addition, several OOP languages are now implementing classic FP features like lambdas and pattern matching.
Also, the question asked doesn’t actually care about FP. Go isn’t a functional language, bit neither is it OO.
You are right, it should have been a comment to another person on this thread. Not the OP.
My point regarding the number of FP languages that it is not a silver bullet, neither is OOP to be sure, but FP has its own set of problems hence the many different implementations.
Regarding OOP languages implementing classic FP features, which is true and a blessing! These are good features which IMHO gives more credit to OOP languages.
Regarding number of languages, I don’t agree that it signifies a problem. For instance, F# doesn’t exist because OCaml is bad, but because there was room for a functional language with good interop with .NET. Same story with Clojure vs Common Lisp.
Making a new language doesn’t automaticly imply that some other language got something wrong.
Go lets me do enough object oriented programming to keep me more productive, while not creating a pile of confusion.
Sadly, there seems to be almost no functional programming concepts supported that I'd use (map, filter, reduce, lambdas). I think the lack of generics and operator overloading might have something to do with that?
