|
|
The language needs to change as marketing decrees; otherwise it looks like it has halted in it's development. They can't sell something that is tested and tried, something that is reliable. It has to be shiny and new, not boring.
That is also the reason VB6 did not die yet. It is tested, tried, reliable and doesn't change. As hard as we try, we cannot kill the beast.
Bastard Programmer from Hell 
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: As hard as we try, we cannot kill the beast.
Or can't we kill the beast because some of us aren't trying?
I know a developer who'd still start new VB6 projects in 2022 because that's all he knows, it works and clients are satisfied.
Why learn something new when the old still works?
This person also uses hidden controls on a form to store values, instead of using variables like the rest of us do.
Also, because it works, so why try harder?
He'll be retiring later this year and he gets to keep all of his software and clients because no one, and I mean no one, could ever unearth whatever it is that he built.
There are plenty of people like that, sort of technical quakers.
We had technology in 1999, which is what God intended, and we need nothing newer.
|
|
|
|
|
Sander Rossel wrote: I know a developer who'd still start new VB6 projects in 2022 because that's all he knows, it works and clients are satisfied.
Why learn something new when the old still works?
Well, that's the entire problem; it is reliable, doesn't change, and does exactly as intended for years on end. If his clients are satisfied, then they'll pay, even if the language is not "officially" supported. To make it worse; this person will have experience, and will have solved these problems before, where we are confronted with changes to the language each six months.
Sander Rossel wrote: This person also uses hidden controls on a form to store values, instead of using variables like the rest of us do.
Also, because it works, so why try harder?
I worked for someone who wrote our new flagship in C#, while I maintained the VB6 version, who put 31 booleans in a string-field in the database and claimed it to be efficient. You can be an idiot in any language, and I met some academically trained idiots too.
Sander Rossel wrote: He'll be retiring later this year and he gets to keep all of his software and clients because no one, and I mean no one, could ever unearth whatever it is that he built.
You might want to learn from that 
Sander Rossel wrote: There are plenty of people like that, sort of technical quakers.
We had technology in 1999, which is what God intended, and we need nothing newer.
We do not change for change's sake. Improvements, very welcome; but both the UI-changes since beveled components and the changes to the language specification (with breaking cost-inducing changes) are mostly changes without improvements.
There's a cost to everything
Bastard Programmer from Hell
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Further down in this thread;
obermd wrote: Don't use it if you don't want to
That's exactly what happened and why VB6 still exists.
Bastard Programmer from Hell
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: The language needs to change as marketing decrees; otherwise it looks like it has halted in it's development.
Actually, if you look at the arc of the language changes (particularly the earlier ones) you can see how they evolved to add functional programming capabilities which was definitely needed to support mixed C#/F# programming styles. I tend to think that was the overall plan by Anders Hejlsberg rather than being driven by market forces. That said, yeah, lately it seems there's more of a "what can we change to keep it looking fresh" attitude, though again, I still think Anders is at the helm and wanting to push C# into what might be considered uncharted territories, though still, much of what he's doing has already been done, even if obscurely in languages like APL.
|
|
|
|
|
If Anders had better idea's, he should have proposed and explained them. Then we'd talk about it. C# and F# are rather distinct languages; you can use both in the same runtime, so no problem there. You don't even want C# to be F#, they're not meant to do the same thing.
He's not at the helm, Marketing is.
Bastard Programmer from Hell 
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
to me it seams, what C# programmers at the beginning used to point out as strong points of the language vs JavaScript have all been silently masked. pushed under the carpet. but, maybe that's only superficial and maybe it's only in my head. much like windows is becoming more linux like, at least in the shell.
probably the first joke a C# developer would make to a JavaScript kid was how they are allowed to write var person = new Person, instead of the C# more precise and knowledgeable Person person = new Person(). because only a good programmer knows that from a Person constructor you get a Person object and if you are that good, you also have to declare it in code. but, that's history now.
what always has struck me as odd, in stiff languages like Java and C#, was the need to write new in front of the constructor. like they were trying to say, look WE KNOW that this thing goes on the stack. alas, instances of class have nowhere else to go, unlike in C++ where you need to specify. but, maybe some day that also will be gone... only the thousands of pre 2010 articles by OOP zealots mocking JavaScript "kids" will remain, making a person scratch it's head in year 2030 that there was a time of the venerable Java/C# programmer and the rogue JavaScript kid that had it so much easier(ignoble) to do things. at least that would be great, but then again thousands of those shameful articles will be erased "for the good of the country" as they say.
|
|
|
|
|
Machine Learning demands it! We're being asked to be more expressive when talking to machines. Expand our vocabulary; so as to speak.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Syntactic sugar. Don't use it if you don't want to but some of these are useful.
|
|
|
|
|
obermd wrote: Don't use it if you don't want to
You'll have to learn them, if you want to read new and foreign code-bases, so little choice there.
There's a trade-off though, and I can't see how much value they add that can justify the confusion and the costs. As an industry, we'd be better of with consistency and fewer changes, saving them up for a few years and come with a decent change.
Not just more sugar every umpteen months; if it were as interesting as animated icons on the desktop, then I'd be all for it, but it not even half that good, if anything, it's contra-productive and generating more costs than it is adding in value.
Bastard Programmer from Hell
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
This C# discussion is an age old one.
Remember:
if it ain't broke don't fix it.
Change is the enemy of working.
Better is the enemy of good.
Perfection is the enemy of good.
Static = no growth, no growth = death
....
on the other hand
when a fix corrects something broken, its a good thing.
When change = easier, its a good thing (sometimes)
....
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
jmaida wrote: When change = easier, its a good thing (sometimes)
Hmm, rarely.
And something which merely "saves keystrokes" is best avoided. I can save an awful lot of keystrokes just by not writing comments and documentation.
|
|
|
|
|
agree
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
Agree. However they do not just save keystrokes, hence I like the features listed here.
Reducing the risk of errors (like the switch expressions) and reducing the amount of code that is not clearly expressing the intend of your algorithm (like ?. and ??) Is a clear benefit for me.
I can even get behind the minimalistic stuff, once they expand it to cover all classes. I have no need for one single class to look completely different. But I guess they will eventually realize the main use case for C# is not only doing cool demos at conferences and expand it to us who have "complicated" programs needing two or more classes.
|
|
|
|
|
Speak for yourself. I, for example, love ?? and switch expressions for making the syntax more readable, actually. They are concise, that is, there's less syntax to achieve the same thing, meaning less overhead to parse when reading.
|
|
|
|
|
I believe they are competing with JS and python, because programming Meme always noted that python is fast in a single hello world sample, And others are not. The things I'm not sure about is why companies such as JetBrains also support those bad manners, and force users to change code to some of these style, while they just could ignore the user style (that may depend on the surranding and could change readability regarding to that)
|
|
|
|
|
i hope it does not sound patronizing for me to i say that i "love" the discussion of "I hate recent C# versions" what a pleasure for an old man about to get new eyes, to savor the illuminations of many of CP's brightest-bulbs.
Kornfeld's signature quote from Einstein: "Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid."
Did make me chuckle ... as I thought of the tree-climbing mudskipper fish whose evolutionary history is detailed in Richard Dawkins' magisterial survey, "The Ancestor's Tale." (see "The Lungfishes' Tale").Quote: Another common name, ‘climbing fish’, comes from their habit of climbing mangrove trees looking for prey. They cling to the trees with the pectoral fins, aided by a kind of sucker which is made by bringing the pelvic fins together under the body.
That boomeranging thought leads me to ponder if the evolution of C# ... leads us to believe we ... are ... smart.
Is the "destiny" of C# (my favorite grab-bag of syntax and functionality masquerading as a "computer language") to have as much junk in its DNA as we, Homo Saps, do ?
cheers, Bill
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
If you don’t like more succinct code I would just stick with COBOL
|
|
|
|
|
Yes! One language to rule them all
|
|
|
|
|
Some of the new features I really like. Some I don't. The issue for me is not about what I may or may not like, but the ever-increasing complexity.
People say 'just don't use the features if you don't like them'. This is fine if you mainly work on your own, but what if you work in a team? Or worse, lead one? You're likely to have a mix of people, some of whom want to explore all the new features, and some who are just learning. The latter group will really struggle because of the former - their learning curve will be much steeper, they will require more support, and they may even lose confidence and decide this isn't for them.
There's a good article here[^] that explores this. TL;DR: langauge design is a balance between keeping up, and overloading with complexity. If you don't add new features, the language dies; but new features eventually make the langauge die from complexity.
Personally, I understand the need to keep evolving the langauage, and really appreciate some of the additions, but I would prefer a slower, more measured evolution.
|
|
|
|
|
I missed the latest stuff, as we are still using Visual Studio 2017. But in my opinion, null propagation, named arguments and lambdas are useful and increase readability. I haven't tried switch expression, but they look like the same goes for them. I'm not familiar with ?[] and (_, _, area)=...! Does it mean you can return multiple values? Looks a little untidy compared to returning an object.
|
|
|
|
|
null conditional in variables im still nah about var x = object?.value?.pointer1;
tuples and tuple deconstructions are enjoy mainly from article from I think team creator about why he does not see many use tuples, and always just pairs which then is key/value pair, but tuples a bit more then that, and the syntax need to set and the deconstruct, so made it much easier. Can't find article but something like this C# - Tuple Trouble: Why C# Tuples Get to Break the Guidelines | Microsoft Docs
switch expression, similar, once know it clicks why would use instead of some other form makes sense. For me I dislike the syntax of most switch/break, is it : or brace  , so I prefer if/else setups.
then switch expression, for assigning a value, ohhh, yes. in comparison to if/else for value assign.
|
|
|
|
|
Yes! I don't program for PCs any more any just stick to embedded in C largely because all the higher level languages have been similarly afflicted.
|
|
|
|
|
I do embedded C mostly also.
However I had a fairly hairy embedded project that I ended up writing a C# wrapper around to permit faster testing (I was processing recorded data files).
The only thing I really missed from C is the preprocessor.
Why is this not a thing in C#?
#define FOOT_PER_MILE 5280.0
#define INCH_PER_FOOT 12.0
#define INCH_PER_MILE (FOOT_PER_MILE * INCH_PER_FOOT)
double miles = 12.54;
double inches;
...
inches = miles * INCH_PER_MILE;
In a lot of embedded applications you don't have GB of ram to use. Sometimes you are stuck with KB of RAM. It is hard to beat inline constants when squeezing a program into a resource limited processor.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
