The Lounge - CodeProject

Shows the difference between natural languages and computer languages.

But you don't want to admit it.

So for them all modern await (which in fact runs operation in separate thread and waits on event together with message processing using MsgWaitForMultipleObjects) are useless for them. And of course, if you can use .Net Synchronizationb Context in Delphi or in C++ (especially with Visual Studio 2005) it would be great. This is the real development world.

I bolded the bit not understanding tasks, which do not necessarily spawn a thread, nor does await necessarily use MsgWaitForMultipleObjects.

This is what support looks like for one of my products we purchased.

Real programmers use butterflies

I'm not entirely sure what your entire complaint is about; but after seeing that the Sunshine | [little ray of sunshine]

s involved not only are using Delphi as an excuse, but also Elephant | [mastadon]

ing VS05 I know everything I need to know:

Run away!

Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius

Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt

I would but BTFramework is the only game in town for now. The attitude though? It makes me want to release a competing offering into the public domain just to undercut their bottom line. Mad | :mad:

Real programmers use butterflies

honey the codewitch wrote:
It makes me want to release a competing offering into the public domain

Is my prediction coming true? OMG | :OMG:

Wrong is evil and must be defeated. - Jeff Ello

I mean, probably not. I don't have time to research the ridiculous UWP bluetooth interface and tap into it from regular windows, which is apparently the only way to do it short of interfacing with the drivers directly.

Besides, I don't code out of spite. I may threaten to though. Laugh | :laugh:

Real programmers use butterflies

honey the codewitch wrote:
Besides, I don't code out of spite. I may threaten to though.

I see where I've been wrong. Wink | ;)

Wrong is evil and must be defeated. - Jeff Ello

For small, well written packages, it's fine.

But the latest horror story is that I installed Quartz against my better judgement, to test it out. Quartz is a general purpose "job runner" and my first warning sign was that it was ported from Java.

Rule #1: Never install any package ported from Java.

The next thing I discovered is that whoever maintains Quartz decided that every single API method should be async, including initialization. Which, because I'm not calling the initialization from an awaitable method, meant I had to wrap the call in a Task(async () => initialize) call. WTF.

What made this worse was that the examples I found online were all written before this atrocity, so I had no idea what I was getting into.

Rule #2: Never trust online documentation, even the documentation provided by the package.

Furthermore, finding anything useful about why I have to do things "the Quartz way" was completely absent. Of course, the main reason for that is because it's a Java port.

Rule #3: If you can't find good examples explaining "why" in the package's online documentation, run.

Ultimately, yes, it worked. Seemed to work quite well. My coworker, who was pushing to use it (he loves packages rather than rolling-your-own) liked some of the features, but neither of us could figure out how to use those features, like error reporting / handling.

Rule #4: If it isn't obvious, it isn't worth it.

In the back of my mind, I kept wondering why I'm adding a package to our already bloated project that consists of thousands and thousands of lines of code, for 99% of features that I won't be using and can't figure out how to use, instead of writing my own KISS CRON job processor in about 200 lines of code, and one that is tailored to what I need in terms of querying what it thinks it should be doing, error handling, testing, etc. I'll post an article, BTW.

Rule #5: The KISS principle should be the first consideration when evaluating a package.

Which gets me to my point.

After making the command decision to ditch it, I uninstalled the package.

Unbeknownst to me, the NuGet package did not cleanly revert. I should have simply rolled back the entire set of commits to the branch. Stupid me. Instead, it left breadcrumbs in a config file that included various .NET framework packages, the most scary of which included a DLL for running unsafe code.

WTF does Quartz need to use unsafe code for?

Anyways, while everything worked fine on our development server, without my realizing what was going on with the config file, on the production server, the app blew up -- wouldn't even start. This was really my bad. I didn't realize (lack of inspecting the change logs) coupled with my own failure to not roll back but instead trust the NuGet uninstall process, that our production build was doing something (still don't know what) that was causing the runtime loader to fail. Possibly flags disallowing anything having to do with unsafe code. Possibly missing framework DLL versions that config was expecting specific version of. .NET did not fix DLL hell.

So between my errors, and NuGet package "management", and Quartz being bloatware, it's what Kirk says about Klingons: "I don't trust them and never will."

Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread Subscriptions

Now you get it!
$Shucks | :-\$

Hangfire is an alternative you might want to look at.

And as a bonus: it's available as a NuGet package!
It needs a database to work however ...
net-tools~hangfire[^]

It has lots of storage options, wouldn't surprise me if there's a file-based one or you could just use the memory based one if you weren't too bothered about persistence.

Marc Clifton wrote:
various .NET framework packages, the most scary of which included a DLL for running unsafe code

Guess: Performance.

I notice to my surprise that an open source .NET library I have used for certain jobs relies on unsafe code. Why? Performance on potentially large amounts of data.

The author is a .NET expert. I am certain he wouldn't have done it unless it was critical. I was disappointed.

I've noticed a trend (at least in South Africa) that a lot of developer job postings are looking for junior to mid level developers. Posts for senior level developers are scarcer. Companies are looking for young, energetic people. It seems like it gets more difficult to find work as an older developer, even though I would think that you would be valued for your experience. I think part of the reason is also that the salary for junior and mid level developers are less and companies are trying to save money. Perhaps there is also a stigma that older developers skills are not up to date?

Younger ones are cheaper: and there is an impression that this is a Young Man's Game.

Problem is the ones that can code are generally those that are still in the industry after 30 years, not those who just escaped from college ...

"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!

Agreed - if only the employers can see it this way.

There's also the notion that developers must move on and become managers, which is not something I'm keen to do. I'd rather keep on developing software. I could start to look at other non people management paths like design / architecture.

I did that (retired now)! I purposely avoided a management roll since the designing and coding are the fun job activities. I will admit to being a team lead now and then but that's not really a management job.

I have also worked with developers over 60, who can't remember how to tie their shoe, yet, they are still on my f***ing team being as worthless as they can be.

I have also seen developers out of college that are naturals, and a great asset to my team.

It's all relative.

In my experience the older ones are less likely to want to learn new technologies and move with the times. Their memory and cognition can be a liability at times.

I am 49 year's old. My memory and cognition is not what it used to be when I was 25 or 30. Eventually, I too will have to be put to pasture. Such is life.

And yes, younger usually equates to cheaper labor costs, but you usually get more output then with grandpa who needs a 2 hour nap in the afternoon.

Kids imagine what life will be like at forty

Quote:
My memory and cognition is not what it used to be when I was 25 or 30.

Hear! Hear!

Mircea

Many years ago the company I worked for (as an operator, but learning programming) would recruit programmers only from the graduate pool. So we had programmers with first or second class degrees who could not write a decent program to save their life. Largely because there were no CS degrees then, so they all had degrees in totally irrelevant subjects. It took a few years for that to change.

But my overall experience is that age has no bearing whatsoever. I have worked with people of all ages who were useless, and some whose skills were excellent. The main thing I did notice about the good ones, was their attitude to doing the job, and learning new skills.

Richard MacCutchan wrote:
age has no bearing whatsoever.

I have to disagree with you on this. Age does have a bearing on your overall effectiveness as developer/programmer, outside the realm of "experience".

“Experience is what keeps you from making mistakes. Making mistakes is what gives you experience.”

I’m not sure who said it first, but over the years I’ve certainly gained a lot of experience.

"Time flies like an arrow. Fruit flies like a banana."

Slacker007 wrote:
I have to disagree with you

Fine, but that just means that your experience and generalisations are different to mine.

I will leave this discussion with this fact. It is a medical and scientific fact (not opinion) that as we age, our memory and cognitive function declines.

Welcome to the Lounge