|
Is it just me, or have the vendors/definers of programming languages fallen into the product mentality of 50% more crunchy than last month marketing? Does it really serve this community of developers to have these languages moving forward so fast and adding endless syntactic sugar and complexity? I see so many people who seem to completely turned inwards, and who seem to spend more time worrying about the language and keeping up with the language than about writing code for people to use. It's like it's become about itself as an end, instead of a means which all programming languages really should be.
Ultimately, if you want to create something significant, you have to stop and select some tools and techniques and stick with them. If that effort goes on for a few years or more, by the time you come back the whole landscape may have changed while the door was closed.
And there's always this pressure that you have to be up on the latest and greatest things, whether they really offer any demonstrable advantages or not, or whether hardly any companies out there doing real products have even caught up to two revisions back yet. But, if you aren't, then you aren't hip or even maybe even hirable, despite the fact that you were the one who was actually creating product for people to use (and the experience thereof) instead of studying to be a language lawyer, and that no customer gives a crap what version of the language the product was written in, just that it's good.
Does all this extra complexity and book length specifications lead to better code, to a better understanding of what is actually happening as opposed to waving a wand to manipulate machines you don't really understand? And I feel sorry for younger developers coming into the world of C++ or C# and others, which have gotten so much complicated to use as an entry point into programming.
Anyway, my caffeine pressure is up to operating levels now, so moving on...
Explorans limites defectum
|
|
|
|
|
|
Right on
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
You have a misunderstanding companies don't want better, They just want simpler, so they can hire some dipwad off the street for half of minimum wage to press a button and know that something will happen and sometimes it might be right.
CQ de W5ALT
Walt Fair, Jr., P. E.
Comport Computing
Specializing in Technical Engineering Software
|
|
|
|
|
Your not far off the nail on the head.
This really is the main reason, or at least the main reasons revolve around this point.
We've spend so long now on this "Everyone must learn to code" thing, because the industry has convinced everyone that we have a severe shortage of coders, that most folks now think writing software as as simple as acquiring a simple life skill.
The premise that coding can "just be picked up" from exposure to it, in the same way we learn to read/write/walk etc is giving the average person on the street that "coding is easy", on top of that, they all see the thousands of £££££/$$$$$$ that us developers make and how rich we are (Yea right) and think... "I'll have me some of that"
This in turn actually turns things around so that we do actually have a lack of good developers, because now no one believes they need to study and learn to get a job in the industry, and thus companies really are now panicking, and looking genuinely for a way to make use of these many 1000's of low brow developers.
Case fact, let's take PHP.
Well known for having a million ways of doing the same thing, just a cursory glance of the basic's of the zend library and you can find multiple functions for achieving the same objective, look at the single most used platform by businesses large & small for rolling out a front end presence... wordpress... written in.... PHP.
Now look at the market where a large portion of commodity programmers can be found.... PHP....
Why?
Simply because PHP over the years added multiple things to accommodate and make things easier for it's audience, PHP started out as an easy to use web tempting language for "beginners", and that "keeping it easy" and "adding things believed to be needed, even if it was duplicate functionality" steam rolled the language into the state that it's in today.
|
|
|
|
|
Same can be said for JavaScript.
|
|
|
|
|
I've been out of the game professionally for about a decade, and took it up again recently as a hobby after the burnout passed.
And I feel your comment so hard. What the hell happened to C#?
I mean, I like some of it. "var" is cool, but you can keep linq.
i've already been doing functional query things for years without it.
on a related note, I wish the C# team would spend some time optimizing their bits first, in terms of changing the language.
For example, adding a yield <sub-iterator> statement to avoid extra object overhead in iterator routines - something at least some of the microsoft dev staff have been asking for too.
instead I get "pattern matching" - what's wrong with "as?"
meh.
Edited to add: Huge win on ref fields though (enabling things like Span) - a much needed feature. More like this plz
|
|
|
|
|
codewitch honey crisis wrote: For example, adding a yield <sub-iterator> statement to avoid extra object overhead in iterator routines
I guess the main problem is that for every revision of the language, there are a couple hundred such proposals that all should be done before any of the others. If ten out of two hundred new features are added in a revision, the backers of the one hundred and ninety will be barking about the uselessness of the update.
For software of all sorts I have read through the revision log describing some new feature, shrugging "Fair enough - but I am not going to spend any time to learn how to use that properly; I see now need for it in my work.
Is there a single person in this world who makes use of, or even knows how to make use of, every single feature provided by MS-Word? Is there a single programmer who has ever as much as tried out every single call line option of gcc? (If you actually did: Was that part of some bet or competition, like "I have visited more countries than you have, so there!"? "I have used more gcc options than you have!"...)
So what? I can live with a tool providing features that I don't need, but others do, as long as it doesn't strangle me. If someone tells you that the reason why you can't have what you want, or in the way you want, because that would conflict with another mechanism that you do not use, then is the time to consider if your chosen tool is the right one for you. (It still may be the least bad one, even after the consideration.)
Lots of tools today - languages, editors, debuggers - are so complex that even if you consider yourself fluent in its use, you shouldn't be ashamed of admitting "No, I never used that feature".
|
|
|
|
|
> I guess the main problem is that for every revision of the language, there are a couple hundred such proposals that all should be done before any of the others.
I totally understand that. I guess the main point I'm trying to make here is it seems the language is getting a lot of sugar but not nearly as many core improvements to the language itself.
Sugar is great to a point, it helps you write less code. But it's sugar.
|
|
|
|
|
My argument for C++ is that they've spent years and years creating a cathedral to containers, but they've ignored the most important thing, which is that, unlike C#, you can't just install C++ and write realistic applications. You are immediately into a world of having to select third party tools to do even a fairly modest realistic program, even a back end one without UI issues.
That's a vast advantage that languages like Java or C# have over C++, and it's just not addressed at all, and probably never will be. So C++ remains fractured in a fundamental way, where any given developer might come into a company and never even have seen half the tools they are using.
I've spent most of my life addressing that problem, so I know what it's like to have a full featured, tightly integrated system in C++ that is very much like what C# has. And it's a whole other world.
But the C++ community has been this way so long, that they actually will react negatively to a system such as mine and start yelling about not invented here syndrome. They consider it the normal state of things to have to piece and part together a system to write a real program.
Explorans limites defectum
|
|
|
|
|
I kind of disagree about C++. I think it's shockingly elegant language.
The main issue is lack of memory management, but there's no way to do that without fundamentally changing what C++ is even used for.
The thing about C++ is it is fantastically flexible. And horribly flexible. They are the same thing only depending on whether the language is doing what you want or not. =)
You *could* use something like the boehm collector in your projects but again that's 3rd party.
But frankly, as long as you code with STL and the standard library, that's "good enough" for most purposes.
The way I prefer to think about C++ is it's "not even a language" - C++ & the STL and standard library are what it take to make a full language.
The upside is flexibility (you don't have to use those libs, you can make your own, which is really useful if you're creating the libs themselves or if you're writing systems code or embedded code)
The tradeoff is complexity. C++ without the STL and standard libraries is an entirely different animal than C++ with them.
Frankly, Accelerated C++ by Barbara Moo and Andrew Koenig is the first book someone should get acquainted with C++ with. It helps.
|
|
|
|
|
I have created everything for myself. However, sub-optimally in my opinion, they have more and more begun to tie the language to the libraries, so that fundamental features are not available unless you use their libraries. That really sort of undermines one of the things that was always nice about the language, that it could be used in tabula rasa mode to create something unique and consistent.
And some of the template stuff is just really bad. A lot of it isn't actually supported by the language, it's dependent on knowing how the compiler fails. And a lot of the way you have to do things (generic templatized callback parameters for instance) can cause enormous lists of errors that have little to do with the actual problem.
Explorans limites defectum
|
|
|
|
|
I'm not as familiar with C++11 and later as I'd like to be.
Can you give me an example of a language feature that's tied to the libraries?
I share your concern there, I just can't think of one.
|
|
|
|
|
There are a number of bits related to determining types of things and type traits and such that are now tied to the standard libraries, i.e. they are in library headers, not intrinsic parts of the language. But they are required to do various fancy template'ish type things. So you can't do those unless you include the standard library stuff.
Explorans limites defectum
|
|
|
|
|
it sounds like they're relying on RTTI or something.
that's troubling.
|
|
|
|
|
Actually, it's more advanced static type info, for doing template stuff at compile time really. Basically to let you do a certain amount of logic at compile time to select this or that bit of template code, set that size value, etc...
Explorans limites defectum
|
|
|
|
|
hmm, well that's neat, actually. the only question is do you have to use the libraries or are they only invoked if you use that language feature? (you don't have to answer) - if it's not, then i am hesitantly okay with it.
The rationale being that the more you can get a C++ compiler to do for you, the better.
I love that it can solve equations for you and the like, but more importantly, it's critical for offloading absolutely as much as possible to the compiler.
a little bit of special knowledge of the standard libraries is about as much of a hack as parsing C languages is in general, see for example, the "type problem" requires a backchannel from the syntax analyzer back into the lexer, and these are as old as C itself.
if it's targeted and optional to use, and helps the compiler do more at compile time, I'd side-eye it, but i think the pros can outweigh the cons. I'm guessing the standards committee came to more or less the same rationale.
|
|
|
|
|
Better to ask: what will it do for me.
|
|
|
|
|
Here's a different take on this problem -- the IDE vendors have run out of real additions to the languages so they are pushing their people to create snazzy new but ultimately unnecessary "features" to sell the next version of the IDE. That explains languages like C# -- every time I see a list of new "features" I find a small percentage that is actually useful.
Open source has a different part of that same problem -- they need to be seem as making progress. If they are not adding features, the language is seen as stagnant and falling behind, which results in a software version of "keeping up with the Jones". Like IDE vendors, they have run out of real things to add, so they add "features" that impress the vocal fanbois.
I just searched for "C# new features" and looked at a few "top 10" features in C 7#. The lists were virtually identical and each contained 2 things of real use, 2 things of interest, and 6 that made me scratch my head.
|
|
|
|
|
|
C++ has this problem, and it isn't even a product from some corporation. I like many of the new features of C++, but some leave me shaking my head (any, variant, lambdas). They seem to be solutions looking for a problem. And what else they do is shake my mastery of the language, so I don't know any longer if there is a better way.
I think each new generation of PhDs and young professors wants to make a mark on C++ by copying bits from some research language into C++ so it feels more "advanced". That's great for the people who learn C++ with these tools already baked in, but kinda sucks for more experienced developers who already know C++.
I'd like to see the tempo of new features reduced. Maybe a new standard every 5 years is enough?
|
|
|
|
|
I think part of it C++'s problem is that it is in danger of entering a death spiral, and maybe a lot of folks think that if it doesn't appear to be moving forward quickly to become 'more modern' that it will just get worse.
Ultimately, I think that may be counter-productive, because it's now so complicated that it probably puts off a lot of new developers looking at it.
Lambdas I get. They can obviously be abused, but they have the one massive advantage in that they can be capturing. So it allows for a range of things that couldn't otherwise easily be done in the way of callbacks.
The downside is that, capturing lambdas cannot be passed to a function pointer parameter. So you can't strictly define the parameter if you want to pass capturing lambdas, you have to use a generic templatized parameter. So you can only use them with other templatized code which is sub-optimal, and you get immediately into 'million errors that mean nothing' land any time you make a mistake, because the compiler has no idea what you really are trying to do.
Explorans limites defectum
modified 27-Mar-19 13:11pm.
|
|
|
|
|
People have predicted the imminent death of C++ since 2003 or so. Instead of dying, it just gets more users, and remains near the top of the TIOBE index.
The people who think about C++ have observed since 2011 that it is becoming two languages: one very sophisticated language for creators of template libraries, and another language for ordinary users. I'm not sure this is a healthy evolution.
Some day, Rust may overtake C++, but I don't see any other contender today.
|
|
|
|
|
There's dying and there's dying. Looking through the job listings out there, C++ seems to me to be suffering, mainly because it's not well suited for the projects that are getting lots of investment. Often C++ seems to be often only even in a listing because it's in the 'experience in one or more of these languages' list, but it's probably not the one you are going to be using, it's just that at least you would have OO development experience if you know it.
I mean I think that the browser and the phone have been amongst the worst things to happen to programming in a long time (let's throw out all of the work done over decades and go back through the exact same ridiculously long and painful process again but even worse), but the fact is that so many development jobs are there. Or maybe they are on the back-end but they related to how can we collect as much data on people as possible and apply AI to exploit that data as much as possible and that's usually not C++ related either. It's more likely to be SQL or Hadoop or Azure experience or some such.
Don't get me wrong. I have a HUGE investment in C++ and it would be to my benefit if it were doing better. But I just really get the impression that it's on a precipice.
Explorans limites defectum
|
|
|
|
|
I think you are exactly correct. C++ is not the go-to language for writing web pages, web servers, or phone apps. Apple had an investment in Object Pascal, and then Swift, to create a typical Apple lock-in. Google chose Java for Android, probably to take advantage of the many programmers who knew Java and the Spring graphics library, but found C++ difficult.
C++ is always going to be the language for implementing embedded things, for writing operating systems, compilers and databases, and for any place performance is critical.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
