The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
you're not wrong; things are changing stupid fast, and I'm not exactly seeing the benefit of it.
I feel that frameworks get updated (too quickly) to try to stay ahead of all the other competition to keep their market share, but at the cost of developers getting burned out.
New languages are fun, when you have enough time to play with them and fully understand the concepts that that new language offers and how it can be best used. When you get bombarded with "here's 6 languages you need to know this year" articles, it's pure BS. You might have the time to take a quick course on all 6, but you won't really know them or be able to put them to good practice.
When I got started professionally, Java was brand new, classic VB was the go to for desktop, C++ was for the hard core crowd, and C was the old friend. With C you could memorize most of the standard libraries and a few purchased ones, and work happily all day occasionally checking a reference book. There were other languages out there, but pretty fringe and would only show up in magazines once in a while.
Today, when jumping through a few languages to just get the daily work done, I find that a good portion of the day is just spent looking things up online, for what framework -> version -> feature you are trying to use, or the weird compiler/runtime error that's breaking everything, or what was all the options you can put in this type of configuration file? The list goes on.
In the older days you could know almost everything about your environment and language of choice and be able to use the leftover brain power to get creative to work around the short comings of that language. Now you have to know at least 10x the amount of information to just get started, and you will never have the time to truly dig deep in to a language.
When you get bombarded with "here's 6 languages you need to know this year" articles, it's pure BS.
As a young developer in the consulting/contracting market in the late 80's/early 90's, I got shoved into project after project, learning new technologies several times each year. It was fun and exciting! I rode that bleeding edge!
After 15 years of professional work, I had a huge breadth of experience but relatively little depth with the exception of C, SQL, and VB 4/5/6. And I was exhausted by the churn. I've seen tool after tool rise and fall, sometimes within just a couple of years. Sure, I learned new stuff faster than most, but learning something only to drop it for the next one got very old.
Now? My decision to learn a new language depends on market share and the local availability of jobs using that skillset. If I don't see a long-term use for a skillset, I pass on it. I don't have the enthusiasm I had and gained the wisdom to focus on what will benefit me in the long run. And my employer in the short term.
I read the "6 new languages to learn!" articles, then check the local jobs. Unless a language is trending, I ignore it. I'm ok with letting others ride that bleeding edge ...
Otherwise there's nothing new under the sun. Young people are anxious for C++ 20 but I've been coding in version '94 (and a bit of the one after that) since always and I mix a lot of C into it (mind you I write them in .c files, not .cpp)
I don't think it is planned anything. It's more like "framework baseball." Every author wants a turn at bat. 3/4 of the time they strike out. Sometimes they get a hit. More rarely a home run. You only see the hits.
Well, the real joke is that in the end, it is all assembly or turned into machine code.
What I don't like is that in a lot of cases, most of the "new, cool kid things" are created by people that don't want to learn how to use the existing tools that actually work far better on the long term. Example? People that think LINQ is freaking awesome and refuse to learn SQL. Someone showed me LINQ and I just chuckled. (Keep in mind that I am a corporate internal apps and DB developer; full stack)
C and the primary C variants have been around for a VERY long time and deserve to keep on keeping on. Approaches like that taken with Java or Python are interesting and do have some degree of place but I stand by my position that most of these trendy things over the last 20 years are from people that just don't want to learn something or can't so they concoct something that does what was already amply doable in existing languages.
I bet you've never said "I won't learn it" about any technology required for any task that's been shoved your way. So let's not hear anything about getting old ...etc. And for that matter - not everything is something that even should be kept up with, rather fashionable chaff blown away by the wind generated by the next perceived cash-in opportunity.
In fact I had a course in BASIC in college (business school). You worked on a teletype machine logged in to the University's main computer.
I worked in Apple BASIC on an Apple2e clone computer and did an accounting application (Payroll and Inventory control) for the company I worked for.
Next, after moving to Charlotte, I wrote a check printing application in Microsoft VB 1.0.
I believe you are starting to see the trend here. I've moved through every version of VB since, up to and including VB6 ('84 to current supporting legacy apps for customers) and VB.Net (developing a website). I looked a C once for a monthor so and decided that you had to be a masochist to use it (way to low level). I rejected it out of hand. I have looked at C# but don't see any advantages over VB.net.
On the data side went from flat file, to MS Access, to SQL server.
Planned obsolescence has been around for a long time now, in modern times, some time in the 1960's it began to pick up again. You see it in almost everything that could be made to last longer, especially things with moving parts. Its all about short term profit. Long range and broad thinking are out, short range and narrow thinking are in.
For some reason this comment reminded me of The Poison Garden of Alnwick - where they have plants so toxic that touching them will kill you, but there's only one plant deadly enough to be locked in a cage...
1) builds binaries that need no additional runtime to be installed -- produces exe which runs natively. 2) Cargo packaging system is actually quite nice. 3) very C/C++-like so easy to learn, but I can already tell there is quite a bit of protection there so you don't shoot yourself in foot. 4)libraries are named similar to std c libaries so easy to find 5 Unit testing is built-in just decorate method with #[test] and you're ready to go. then run with $ cargo test --- AMAZING 6 syntax is very similar to Kotlin (which I know from Android dev) so at least there is some cross-over learning.
Types are like u64, u32 (unsigned), i32 (integer) f32 (float).
Made me laugh because it took me back to the days of hungarian notation[^] which was beat up by C# and VisualStudio and all the people said, "stop using hungarian notation!!" and I finally gave it up. Now, in Rust, it's kind of back. 😆🤓
Hungarian notation is fine for low-level types. The Rust names are even shorter than their analogues in C++'s <cstdint>. But it's an abomination for user-defined types and data in a type-checked language.
Types are like u64, u32 (unsigned), i32 (integer) f32 (float). Made me laugh because it took me back to the days of hungarian notation[^]
I don't see a connection between the type names you listed and Hungarian notation. The type names are simple, short, and yet meaningfully describe the type.
Hungarian notation on the other hand attempts to encode information about the value's type in the value's name. Microsoft adopted this as a standard, which caused a fair amount of the programming community to follow suit.
Personally I don't like it. The cardinal complaint is that if the type changes, then the value name should change with it. The problems with Hungarian notation are worse than an inconvenience, however. To my mind Hungarian notation violates principles like implementation hiding, since it exposes implementation details in the names. I also find that the prefixes are visual clutter and make the code harder to read. I have a body of code I maintain with hundreds of classes, all of whose names are prefixed by "cls". Utterly worthless clutter.
You mean you didn't like lpszWindowText (long ptr to null terminated string)???
Man, I know how to troll on CP, just mention Hungarian Notation.
I think back in the day when people printed out code to do code reviews (hahahahaha as if anyone prints code now or does code reviews) that Hungarian was kind of nice cuz you knew the type when you looked at it. But I'm glad it's gone too. Put me down for "Happy with the present situation of variable names." Just thought it was funny that the intrinsic types are a slight throwback to Hungarian.
Man, I know how to troll on CP, just mention Hungarian Notation
No kidding. That's almost as much of a blitzkreig in the forums as a brace style debate.
as if anyone prints code now
I will admit to occasionally printing code fragments. Most of the time lately it's to compare struct definitions against interface specifications. I've got one interface now that has these lovely C struct's in the interface spec. The only problem is the compiler being used forces 4 byte alignment, which isn't documented in the struct's. My corresponding definitions therefore have to insert pad bytes to make things line up.
A few years ago the Infernal Revenue Service accused my company of padding their R&D costs, and they wanted proof of the work we'd done. Part of that proof was supposed to be a listing of all versions of all software produced over the preceding five years. Said source code, copied to CD's (this was a while ago), occupied around 120 discs. We make commercial ink-jet printing systems, so we're good at figuring out how much paper will be needed for a job. We estimated a paper listing of the contents of those discs would have required a little over 9 rolls of paper, at 40,000 feet per roll. When we asked them where they wanted the 9+ rolls delivered (each weighing several hundred pounds, and about 5 ft in diameter), they backed off. Just to be a smart ass, I did print out a directory listing of each of the discs. The directory listing alone was an entire case of office paper (2000 sheets).
Oh, and not to brag, but we could have printed those 9+ rolls of paper in about 1 day. We ain't your mama's DeskJet.