The Lounge - CodeProject

Agree.

"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle

Yes - just the thought of it makes my stomach go Squiqqy...

If you can't laugh at yourself - ask me and I will do it for you.

I think there are Shotz for that.

"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle

( she said ( welder in the shop )) "You are showing your age with that" - " NO, we're much older than that"

Shirley that's a Leslie. Smile | :)

Wrong is evil and must be defeated. - Jeff Ello

Reports of Leslie's death are entirely premature: Poke tongue | ;-P

2013[^]
2017[^]
2020[^]

"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer

Why did you call her Shirley? Surely you could have avoided it?

Bastard Programmer from Hell Suspicious | :suss:

"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.

I'm not a fan of LINQ. I love functional programming but .NET's enumerator paradigm is not up to the task. It creates too many objects too quickly to be a real grown up functional language, whose iteration is highly optimized because it's a first class operation.

I've benched LINQ against hand written pseudo-functional operations that do the same thing. It was not encouraging. For things that make heavy use of functional computation like parser generators, where your LINQ query might be half a page, it's a Bad Idea(TM)

Worse, I think its use has been over encouraged by Microsoft. It makes green developers write even worse code, and makes it harder for a seasoned developer to understand the performance implications of the code they are writing (and I'm not talking about bit twiddling here, I'm talking about figuring out your Big O expression)

I tend to avoid its use, preferring - at least in C# - to make my iteration operations explicit and long hand. If .NET had truly optimized iteration paradigm - one that didn't create new objects for every single iteration operation** - i might consider using it.

** yes i understand that LINQ combines multiple operations into a single iteration *sometimes* - in practice it's not often enough to make up for the overhead of enumerators.

Now, there's a case where all of the above doesn't matter, and that's PLINQ.

Theoretically, for a large enough operation, that can be highly parallelized, the overhead of enumerators suddenly isn't the biggest part of the performance equation. What I mean is it essentially pays for itself. Also, given the issues with synchronization and other cross task communication (is your operation clustered over a network?) enumerators are actually not a bad idea since you can lock behind them or RPC behind them. Contrast that with C++ iterators that are usually lightly wrapped pointer ops and you realize their limitations fast: In order to enable all of the stuff you need to make iteration operations work with each other in parallel you have to wrap every iterator operator anyway, making it as "heavy" as an enumerator in .NET, not counting the general overhead of running managed code.

So basically, PLINQ is where LINQ finally covers its costs - where it reaches the point where its advantages outweigh its disadvantages.

All of this of course, is one developer's opinion.

And some of this doesn't necessarily apply to business software, where performance almost doesn't matter for most scenarios.

Real programmers use butterflies

I agree.

Coming from you that doesn't surprise me. Smile | :)

You strike me as someone that has an almost ruthless contempt for "frilly" things as they apply to programming.

Real programmers use butterflies

*lol* you mean a consultant accepts everything .... Wink | ;)

modified 27-Mar-21 21:01pm.

Now what is the big advantage of linq?
It is smart to query things like one queries in SQL.
But more it is smart it allows to query in a kind which is tested. Of course we rely on that test the same we rely on the compiler that it compiles correctly Wink | ;)

Nothig more and nothing less
[Edit]
Most probably hard to understand what written above Confused | :confused:

modified 27-Mar-21 21:01pm.

That testing aspect is definitely one advantage, but I'd just as soon write the "functional" code long-hand and write the *tests* using LINQ to verify them. Poke tongue | ;-P

Real programmers use butterflies

test the test Poke tongue | ;-P

you seems to be same paranoid like me Laugh | :laugh:

modified 27-Mar-21 21:01pm.

They keep adding ketchup and yellow mustard to my language. It'll be mayonnaise next. Mad | :mad:

All three together will end in a good taste Laugh | :laugh:

modified 27-Mar-21 21:01pm.

That's like putting it on steak!

C++ i have mixed feelings about. I love the flexibility. Almost every feature has an actual purpose. You'd think that wouldn't be an exceptional thing, but consider C#8 and parameter "deconstruction" and all that other nonsense we don't need. But C++ has gotten so complicated that it's about as bad C# has gotten if not worse now. So even if it is purposeful, it's hell to navigate.

Real programmers use butterflies

honey the codewitch wrote:
C++ i have mixed feelings about. I love the flexibility. Almost every feature has an actual purpose. ... But C++ has gotten so complicated that it's about as bad C# has gotten if not worse now. So even if it is purposeful, it's hell to navigate.

I agree about the complexity. But the nice thing about C++ is that if you don't use it, you don't pay for it.

Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.

Definitely. That's one thing I love.

Until developers abuse it with cross code interdependencies, making selective linking useless.

Like the ESP-IDF's bluetooth LE stack depending on its bluetooth stack despite them being *entirely* different protocols (BLE was bought from another outfit by bluetooth - it wasn't designed by them) - on an embedded device where every kilobyte of program code space counts.

Mad | :mad:

Real programmers use butterflies

honey the codewitch wrote:
Until developers abuse it with cross code interdependencies, making selective linking useless.

As someone said, you can write poorly-crafted code in any language. Sigh | :sigh:

Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.

It's frustrating that this is basically system level code - driver code necessary to use the hardware for the proprietary** SoC it runs on.

** how it works isn't actually a secret, but nor is it easy to dig through a mountain of technical specs written in chinese to write a custom DDK and SDK package for this hardware.

Real programmers use butterflies

This reminds me of Flon's Axiom from 45 years ago: "There does not now, nor will there ever, exist a programming language in which it is the least bit hard to write bad programs."

I like how it was phrased in one of the Star Trek movies. I think it was #3. Anyway, the president of the Federation said, "Let us define progress to mean just because we can do a thing does not mean we must do that thing." I take that approach to a large amount of stuff when it comes to programming. Especially new language features. So far, I have seen exactly one thing in C++17 that I really, really like and use often : inline static variables with initialization.

"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"

I hear you. The one "must have" feature in C++ that isn't actually in C++ but should be is real forward type declarations.

Remove the restriction where I can only declare things like a pointer to a type before the type itself is fully declared.

It might require using a GLR parser or something equally complicated to parse your code (like C# does) but given the complexity of a standards compliant C++ compiler already, what's changing the parsing engine used by most C++ compilers to something more advanced in the big scheme of things?

Basically to bottom line it, I want to be able to declare my types anywhere in my files and use them anywhere in my files.

Real programmers use butterflies

You mean like this?:

class FWD;

struct STR {
FWD *fwdPtr;
};

int main() {
STR tst;
return 0;
}

Welcome to the Lounge