Leaderboard

Hello, this is to let you know that there was a open source collaboration project started to create a formal specification of the Delphi language in Backus-Naur format (https://en.wikipedia.org/wiki/Backus–Naur_form). It is hosted on GitHub here: https://github.com/MHumm/DelphiGrammar David Hoyle contributed his Delphi 10.3 version as a starting point. If you want to participate in this endeavor, which might help developers of language tools, just drop me a message with your GitHub account name and I'll give you commit permission. Either via this forum or as an issue on that GitHub project. Currently I picked Apache 2.0 as license, but if necessary we can discuss to use something else. Cheers TurboMagic

I'm working on this demo, which will be in the next update.

There was a new WebSocket server in SVN last week, sharing much code with the new client since WebSocket is a symmetrical service, and built into the existing web server samples running on port 443, rather than a separate port. Most of the methods and events are the same for client and server. The OverbyteIcsSslMultiWebServ and OverbyteIcsDDWebService samples should respond to these WebSocket URLs: wss://localhost/WebSocket/Echo (echoes messages received) wss://localhost/WebSocket/EchoPing (echo and send keep alive pings) wss://localhost/WebSocket/Chat?MyName (multi user chat server) There is a new websocketclient.html page listed on the main demo.html page that allows testing these WebSocket servers. The new client component will also access these URLs. I also have similar URLs on my public web server and anyone wants to test the client alone, but email for the full URL, I don't want it indexed. Angus

If you're after something that does both (generate the doc, and parse it), there's this: https://github.com/paolo-rossi/OpenAPI-Delphi

hehe, yeah, 3 years later! 🙂 I noticed that when it was released and thought ... where were you back when I need this? 🙂

By "translating" are you referring to importing and generating client for it? If yes, I have provided a tool for that: https://github.com/landgraf-dev/openapi-delphi-generator

Any company would add such a disclaimer when releasing unofficial "patches". It means: If it didn't work, don't blame us.

Why would LSPServer affect anything that dcc32/64 do?

I've had zero success recruiting delphi developers in the last few years - devs here in Australia do not want to work with delphi. I have found most devs also only apply for jobs that state the toolset they will be using (or they ask when applying) - advertising a job that doesn't mention that doesn't generally help. I tried doing that once and had people walk out of interviews when I told them we use Delphi - sadly most said they had never heard of it plus the odd "oh is that still around" . Younger devs want to work with what ever is the current flavour of the month (js react, go, rust etc) and I can't really blame them for that. Unfortunatly delphi suffers from many issues which are a turn off for employers and prospective employees. Poor quality - this has been an issue for a very long time (since the Inprise era). Each release improves a little, but then bring new issues, and many issues remain unresolved for years. Lack of language evolution - the language has barely changed - where other languages like C# etc have - yes there has been some tinkering around the edges, but apart from generics not much really. Lack of investment - in the early days Delphi sold like hotcakes - but that income was syphoned off to other "enterprise" products that never went anyway (Inprise era). I don't see any evidence of that ever recovering. Imho the poor quality is what has really turned many people away. TBH I would be embarrassed training a new dev on Delphi, having to explain all the work arounds etc that I use almost without thinking (like restarting the IDE many times each day), it would be just too time consuming and frustrating. Some days the frustration levels have me looking for career change! So is it any wonder that delphi jobs are few and far between. Here in Australia I see one or two a year advertised - and then those usually worded to suggest the job involves migrating their projects to other languages like C#.

I know, it's very odd to me as well. When I graduated from college I got hired by Intel. They tended to hire EEs; my degree was in math / computer science. Everything I worked with there was proprietary. I got caught up in their first layoff 5-1/2 years later. Looking for what was next, people kept telling me, "Well, you've got a CS degree ... you can learn anything pretty quickly, right?" I ended up getting hired at a Motorola division and they wanted me to learn C and Unix. C++ was just coming to the fore as well. After the world didn't come to an end on Jan 1, 2000 (Y2K) the market was flooded with about one million excess programmers, most of whom were here on H-1B visas. That changed the entire complexion of hiring practices across the software and IT industry. Jobs that used to get 5-10 job applicants were now getting hundreds. Executive Recruiters who used to have the ear of hiring managers disappeared, and everything was moved to automated systems. Job descriptions became more standardized and HR people didn't really have any clue what any given job entailed. People learned they could "keyword stuff" their resumes to improve their chances of getting a call-back, if not an interview, whether they knew what the jobs were or not. Things have devolved to the point where it hardly matters what your educational background is -- if you don't have 3-5 years immediate experience with whatever platform or stack a project is using, they won't consider you. Nobody wants to pay for on-the-job training any more. I was at the event when Delphi was announced in 1995 and got a free copy of it. I started playing with it and was quite amazed. Unlike VB, you could build Delphi extensions (components) in Delphi itself, you didn't need to use another language. And unlike VB and other things where all "extensions" were DLLs, Delphi's components could be linked into the EXE as normal library code, so there was no run-time penalty to use them. Over the next 5 years, I switched my focus from C++ to Delphi, mainly because Delphi was so much easier to work with, especially for UI-based apps. Since 2005, I've had a bunch of different roles that I got mainly because of my Delphi expertise. Every one of them had fairly complex systems that took many months to learn and were in application domains that were new to me and had very little in common other than they were all built in Delphi. Most of them were, in the words of one colleague, "keeping a comatose patient alive until the new system was built", usually that meant "porting" it over to C#/.NET. I never saw any of those "ports" get completed. The last place I was at, I kept hearing people at all levels of the organization say things like, "Well, you're the Delphi expert, so you understand how all of this stuff works, right?" (IOW, since I knew Windows, I obviously must also know how ALL Windows apps work.) This was an incredibly complex system and it took most of a year to start making sense to me. A guy they hired 8 months after I'd started didn't know much about Delphi but had 10 years of app domain experience, and he was able to come up to speed much faster than I did because of his extensive domain expertise. I discovered that the entire (Delphi) dev team quit in 2011, although very little had changed since 2009. My first day on the job I was told, "Do not touch ANY of the code!" It has always struck me as odd that hiring managers seem to think there's more relevance in knowing a given programming language / platform versus an application domain. The app domains are usually far more complicated and take a lot longer to learn than a new programming language / platform. I mean ... at some point programming is programming. Every imperative programming language is pretty much the same, and they all tend to have the same structure, so learning one more isn't a big deal. (Actually, they're all easy to read; writing new code takes a little more time.) I'm semi-retired now so I don't have to deal with this crap any more. I can do what I want with my time now.

Broken eco-system. On the Danish job-sites I can see the same Delphi jobs being posted again and again and I've had something in the neighborhood of 10 unsolicited Delphi related job offers during the past 12 months. The last one, this past Friday, need 2-3 Delphi developers. "Unfortunately" I'm fully booked, overbooked actually, and there's only one of me 🙂

It's my file using extended backus-naur format. It's easier for me to maintain these files along side my parsers than using diagrams. The Object Pascal files started from the grammar that was included in the Delphi 7's Object Pascal Guide.