|
|
Coming from you that doesn't surprise me. 
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 .... 
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
Nothig more and nothing less
[Edit]
Most probably hard to understand what written above 
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. 
Real programmers use butterflies
|
|
|
|
|
test the test you seems to be same paranoid like me 
modified 27-Mar-21 21:01pm.
|
|
|
|
|
They keep adding ketchup and yellow mustard to my language. It'll be mayonnaise next. 
|
|
|
|
|
All three together will end in a good taste
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.
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. 
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;
}
|
|
|
|
|
No. I mean like this:
struct myForward;
std::unordered_map<std::string,myForward*> m;
...
Except I'd even go as far as to eliminate the forward declaration entirely.
The above won't work, BTW on most implementations of the STL, although there's nothing in the spec that says it won't work but nor does it guarantee it does. It works in Boost's unordered_map, but because they went out of their way to make it work in how they implemented unordered_map.
Strangely enough, the above will usually work if you replace it with std::map
Real programmers use butterflies
|
|
|
|
|
This is supported by all compilers I use, clang, gcc and msvc.
Just curious, what did you use that didn't support this?
BTW, if you don't like forward declaration, perhaps you need an untyped language.
Here, the type of "m" depends on the type "myForward", there's no way around this, and it's not just in C++.
|
|
|
|
|
I wouldn't say C++ has gotten more complicated. Au contraire - I would say it's never been as easy to learn and use as it is now, I almost never have to rely on raw pointers, manual memory management, and all the stuff that C++ haters love.
The problem of C++ is that it has become so feature rich, that it's virtually impossible to know all of it, and there really are a lot of features, which, although I'm sure somebody out there uses, but I don't see them as belonging in the standard.
It's just so freaking huge.
But, of course, you don't really need to know and use all of it. Unless you're a C++ compiler developer.
|
|
|
|
|
afigegoznaet wrote: But, of course, you don't really need to know and use all of it. Unless you're a C++ compiler developer.
Or need to read someone else's code (or your own, later). Oops.
|
|
|
|
|
Well, that's not really language specific.
I find myself reading online documentation even when reading bash scripts.
|
|
|
|
|
Hey now. Bash scripts get arcane. I just got done writing a "bash course" for a client of mine (technically a client of an outfit i work for from time to time) who is trying to educate their own customers on how to use it. Talk to me after you've passed what bash calls an "array" to a function. 
Real programmers use butterflies
|
|
|
|
|
Of course, I had to do some lookup.
Nevertheless:
my_array=(foo bar)
print_array(){
for i in $*
do echo $i
done
}
print_array ${my_array[*]}
|
|
|
|
|
I'd argue that this *is* added complexity.
Every layer you use to abstract away pointers and other C++ arcana removes you that much further from what your code is doing.
And you know, std::auto_ptr works fantastic, until it doesn't. And when it doesn't you better know exactly how it's spec'd to function.
Things can be complicated and easy to use at the same time. Hell, that describes the average IoT device these days.
Real programmers use butterflies
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
