|
Just need better shoes...
|
|
|
|
|
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.
Sorry for the rant, feeling my age this morning.
|
|
|
|
|
Matt McGuire wrote: When you get bombarded with "here's 6 languages you need to know this year" articles, it's pure BS.
I agree.
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 ...
|
|
|
|
|
Well If I ever have to develop for web, at least it looks like typescript corrects most of the mistakes of ecmascript (javascript) but best of all, we have webassembly and you'd hardly have to leave the holy ASM/C/C++ trinity to code seriously for the web.
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.
And furthermore Get off my lawn 
|
|
|
|
|
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.
So you see I have rejected all of them.
Stella!
|
|
|
|
|
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.
|
|
|
|
|
i think everything comes from the fact that a lot of people need to justify their jobs. they make changes all the time, like everybody is working something.
they take the up-directory button on windows explorer, then they return it. they take the start button on windows UI, then they will return it...
you enter a 3yr project and work in whatever popular language, when the project finishes the language had 6 revisions and you are 'no more competent' in it.
"if this frameworks are so great and helpful why do we need another one? why didn't the last 27 frameworks solve the problem? they didn't so you need the 28th framework, right?"
Jonathan Blow on Software Quality at the CSUA GM2
it's nothing but chaos
|
|
|
|
|
I saw on TV that in Arizona, if you produce a vaccination card to prove you have been vaccinated, they give you free marijuana! Yeah! I may move there, but I have only one question:
What the heck is marijuana? 
Get me coffee and no one gets hurt!
|
|
|
|
|
I'm not sure but it smells funny.
Uhhh
|
|
|
|
|
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...
|
|
|
|
|
I can't speak to that, but I could look into it.
|
|
|
|
|
Quote: What the heck is marijuana?
It seems to be some kind of hashing method 
|
|
|
|
|
Didn't it pre-date hashing? Story I heard is that all the left over crud was used to assemble it. 
|
|
|
|
|
I've begun the journey of Learning Rust with this book, Programming Rust: Fast, Safe Systems Development 2nd Edition[^]
So far, I like:
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.
Interesting Thing
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.
|
|
|
|
|
Started to learn RUST a while back then got side tracked and am about 10 levels down in the stack. When I finally do unwind I will pick it up again. A lot of promise in the language!
The less you need, the more you have.
Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?
JaxCoder.com
|
|
|
|
|
same here, I really want to get back to learning more Rust. I just can't find the time to squeeze it in this last year.
|
|
|
|
|
|
raddevus wrote: 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.
Software Zen: delete this;
|
|
|
|
|
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.
|
|
|
|
|
raddevus wrote: 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.raddevus wrote: 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.
<OldFartWarStory>
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.
</OldFartWarStory>
Software Zen: delete this;
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
