|
Given that the question implies that we've experienced improvement in the past ("continue to evolve"), I think the question is flawed. 
Latest Article - A 4-Stack rPI Cluster with WiFi-Ethernet Bridging
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
I am pretty sure that you don't want to go back to the ABI used by ENIAC, so there must have been at least some improvement...
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
For those of us who actually have to release a product under deadlines, stable tools are essential. We don't want to waste our time using the latest "shiny", just because some whiz-kid has discovered a new way to produce a new operator out of the characters ->*~=.!
If you are one of the aforementioned whiz-kids, go away. The adults are trying to get some work done!
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Totally agree. C++ of late has been a huge victim of this IMHO (c++11, 14, 17 and now 20). Particularly if you work in a team with differing levels of experience. Within reason in the real world, you should code to the lowest common denominator, otherwise not everyone is able to maintain the software well, particularly in the real commercial world, where the luxury of time out for training, or to experiment in non-business, non-critical projects with new language features, rather than risking messing up the project.
I saw this in a project, which was stable and working well, with no apparent leaks, memory related crashes etc, using native pointers and the only smart pointers were COM smart pointers.
Then someone decided we should all move arbitrarily to smart pointers from C++11 and the introduction of them, without understanding the nuances, took time away from developing features and fixing long standing bugs, and for a time actually made the software much LESS stable, because of the subtle nuances and gotchas with smart pointers.
Newer is often not better, particularly if subtleties are not understood, and/or others are "left behind".
|
|
|
|
|
For me stability is the priority. Releases that fix bugs and support new hardware are obviously essential. I also appreciate having new language features that actually make my life easier or my code more readable. The introduction of LINQ into .NET 3.5 made some great improvements for example. Like everything, a language needs to continue to evolve, or else it dies.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
I examine the feature list each time a "new" version of C# is announced. In the last few releases, 90% of the features are nothing useful. Changing syntax so 1 line of code can be eliminated is (IMO) pointless. As others have noted, it makes the code harder to read and harder to debug.
|
|
|
|
|
|
I'm guessing this survey was inspired by one of those "useless stuff coming in C# 9 articles" and I feel the same way!
C# is in serious danger of having so many possible styles and approaches embedded into it that we're rapidly heading to the point where C# code won't be immediately recognisable as being in C#.
It simply doesn't need a pinch of F# here and a bit of Haskell there, it needs to settle down. Yes, the framework will always change but the language should have been signed off as finished a long time ago.
Whenever you find yourself on the side of the majority, it is time to pause and reflect. - Mark Twain
|
|
|
|
|
ONE singular Swiss army knife language that does all things for all people really well.
Imagine all developers learning a single common language in depth. Today, it seems like you need to know 2 languages and 3 frameworks just to get a project done.
Ahh, but which one should win? There in lies the rub.
“The palest ink is better than the best memory.” - Chinese Proverb
|
|
|
|
|
There's an expression used to describe people talented in the manner in which you'd like a language to excel:
"Jackass of all trades, master of none".
Swiss Army Knives rapidly become junk as they become fatter with more and more blades. I'm waiting, as we converse, for a Japanese version that includes all possible imaginable blade and an enema bag.
OK - crude - but hopefully makes the point. If you've used tools, you know there's multiple types of saw blades - some specialize in metal, some cutting wood with the grain, some against. They are the result of necessary divergence . . . not awaiting convergence. The idea of one blade that does an all-around mediocre job or several specialist that do excellent work.
Even VB6 has a use - knowing which developers are deserving of ceaseless ridicule.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
W∴ Balboos wrote: Even VB6 has a use - knowing which developers are deserving of ceaseless ridicule.
Or sympathy. Not all those who use VB6 chose to.
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
That blade is double sided (pun intended)
Either the tool is master of none
or the developer is master of none
and this poses the further question of how many developers know the best language for a given job (and how many companies give them the freedom to pursue it)
You learn a certain tool set / language, and then you spend a portion of your time trying to bend the language to do what you need. Ever use a screw drive handle as a hammer, or a butter knife as a screw driver?
And don't they (all languages) bloat over time, thus the "evolve indefinitely" part of the question?
Another approach... Think of the CLR. The computer doesn't speak our language. Every language coded in is just syntax that ultimately leads to something else that can be used by the computer. If the end result is the same, why do we need so many different starting points? Why curly brackets here, indent five space there? Why BEGIN END? When coding have you ever accidentally written the wrong syntax (of a different language)? Over my lengthy career, I've used; Smalltalk, Lisp, Python, Pascal, Fortran, C, C++, C#, JS, probably some others I forgot and yes, even VB6. All I'm saying is that it is like language soup in my head and a single syntax would have made for an easier life. 
“The palest ink is better than the best memory.” - Chinese Proverb
|
|
|
|
|
littleGreenDude wrote: or the developer is master of none
Just check Q&AlittleGreenDude wrote: you spend a portion of your time trying to bend the language to do what you need
In fact, that's the name of the game.
The language doesn't do anything - you have to do it. Think of each language as a mathematical basis set to describe the solution to some problem. If they are complete basis sets for the space they could all describe any point (i.e., solve any problem) in their space. However, some will have a lot more complex of a solution than others.
But, for different problems, different basis sets will be easier to use to describe the answer. One (i.e, the universe of developers) needs numerous basis sets to solve the diverse problems that arise in a reasonably simple manner. Capping this universe of basis sets isn't sensible. Sure, there's endless junk turning up that soon disappears, but eventually, something better will turn up. "C" was built to write operating systems. FORTRAN for doing mathematics. Each makes that easier life when used for it's purpose.
So, perhaps what your really looking for, deep down inside, is not a freeze on language development but, instead, more frequent and thorough house-cleaning.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
I've considered making a language that allows you to modify its syntax, mainly so you can create "domain specific sub-languages" from it to solve a particular problem.
That way it would provide your desired unity while also remaining optimal for whatever problem you're using it with.
Parsing it would be complicated.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
You would also need to modify the compiler to it knows what to do with your new syntax/keywords.
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
Of course, but that's easier than it sounds. In fact, I started there when I was building a proto of the thing. Dynamic parsing is trickier than getting the compiler to consume "new types"
for example, describing to the compiler what a "collection" is tends to be easier than describing to the parser - at least for the end user, if the compiler can consume a base class and a parse tree and the parser produces the syntactic sugar for it. On top of that, you need a mechanism for coroutines and bob's your uncle.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
|
|
Really, he is spot on 100%. The basic concepts are the same and there is no real reason to dance around them with syntactic sh...ugar.
IMHO language syntax should be as terse and concise as possible (hence my unfailing love for C and my growing disappointment with C++/11 and following).
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
So new features are nice, but in most cases used only YEARS after being released, if ever.
We still have .net code that would easily compile with 3.5, so yes, lambdas and LINQ are used by now, but many other operators are not.
There is simply no time to rewrite and beautify code to the latest syntax sugar.
And more often than not we tend to "do it as we already did" before using newer features, simply because we can trust our way to do things.
We still use threads and not the task library, no async/await. no one really needs that. if you grew up with thread management, locks and syncing this is not a problem, everybody knows what to do and the solutions are stable.
when i only see code of .run()..then..else..thenafter or how that crazy chains are named... no way.
absolutely unnecessary. If you think in good-old-patterns, your code is stable as a rock.
valid for all platforms. we don't use futures in android either. threads do what they do since 25 years, and they will still do it in another 25.
that's good enough.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
