Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
What the actual fuck you on about?
atheist53084dA library is a collection of code that specialises in one thing, sure... But I worked on a computer vision library that did maths/ML stuff. Transferable knowledge.
By "legacy os level knowledge", do you mean "knowledge of how to code"?
In which case, yes. Fortunately, there's a whole industry built around that legacy knowledge...
C0D4681834dIt doesn't matter if you wrote the code 5 seconds ago, 5 years ago, or even 25 years ago.
It's always going to be legacy code and technical debt to someone.
Software evolves, and is usually more cost effective to take something you already have and improve it to do what you need it to do. Rather then rebuild the wheel every 6 months because "legacy" is bad.
You will always need to cater for something old in your compatibility requirements, either that's something physical or some lib/package that's been unsupported for 3 years.
There's no getting away from it, and we all live through it, well, usually.
Just don't be confusing "legacy" with "absolute donkey shit"
@C0D4 @100110111 @atheist I think am not very clear. There are companies like firebase/aws that make libraries for mobile/web/IoT etc for doing some specific task. the mentioned platforms evolve but their underlying technologies don't .android 12 brought a lot of changes but the aosp is still written in java, 99% of browsers still only support es6 and iot must also have its limitations
However, The b2c apps developed for these platforms can use modern wizardry to evolve faster than platforms. apps are built using latest versions kotlin/swift, websites are built using latest versions of react/TS/dart, etc.
But again most apps might not do that, and we codebases like telegram that are still using java and the legacy sqlite apis directly instead of better solutions like kotlin and ROOM
And from the library P.O.V, it has to cater to demands of both cutting edge apps and legacy crappy s/w. So it ends up in using pure/oldest apis of the platform and therby being an ugly codebase
i am about to join a company with similar portfolio, i.e making SDKs for platforms and catering to demands of very shitty codebases and therby having legacy codebases themselves.
They don't use kotlin, they don't use rx java, they don't use any DB orm, all is written on their own: Bitmap decoders, Video players, SQLITE queries, concurrency, everything!!!
I am a freshman , out of college with just an year of work experience. the company i previously worked with was aggressive about using the latest cutting edge solutions. so its quite a switch from a codebase POV and i am concerned weather this deeper interaction with system apis is worth it, in a time when we have libraries to do everything and better in every possible way
@prodigy214 I guess I get where you’re coming at… I used to think the new, shiny cutting edge tools were by default better than the old established ones - progress, an improvement. Well, here’s a thing you are likely going to learn at some point anyway: no it isn’t. Not by default, at least. In some cases, it could be. But in the world where your work has actual users, stability is the keyword. The ”legacy” tech is, more often than not, tried and tested and stable. The new shit may not be. When you make real-world shit, you want your tools mature. That’s just the way the cookie crumbles babe.
@100110111 I would add an important part...
You need the horsepower to be bale to stay "up2date".
Horsepower meaning all kinds of resources - test farms, developers, experts, infrastructure, ...
Example: Having several build pipelines to test for upcoming deprecations in libraries or the core language itself (e.g. proactively building with unstable JDK versions or nightly snapshots of common used libraries)… evaluating the test failures and deprecations... Preparing possible fixes while maintaining compatibility to current versions.
This is _a lot_ of work, but it pays off by having far easier migrations.
Another example are testing methods like fuzzy testing - extremely useful, but without the necessary hardware not doable.
A legacy toolstack doesn't have to be bad though - it depends entirely on how it's managed.
Regarding your example of decoding, concurrency etc - I'm curious to know more. Just as an example - Netflix has a lot contributed to the BSD network stack. I'm too lazy to look it up, but all in all I'd except that there is a whole own framework, tech stack, OS stack etc. hidden there...largely written by Netflix to match specifically the tech stack they have.
@IntrusionCM something similar to Netflix, yes. they have their own decoders and concurrency and its fairly advanced , but its not a seperate library. just an in-house solution being used in library as internal classes. the main purpose of the sdk is to provide analytics, and therefore does not use any other libraries except the platform classss
Hazarth44484dAre you saying, that every project written in C, C++, C#, Java8... today is automatically legacy, because it uses an "old" technology?
No idea where your "they don't use Kotlin complaint comes from"
Custom SQL queries over an ORM don't need to be bad either. Often ORMs do a worse job at building a query than a human that knows SQL will. See ORMs arent really "better", they are "easier to work with". That's a big difference. We usually do a mix of ORM and custom queries for this reason.
Not sure about custom Bitmap decoders. Those shouldn't be written from scratch but use an existing library, every operating system has one really...
As for video players, people are *still* making custom ones all the time today. Using an existing one if you don't need anything fancy is the way to go, but if you find yourself wanting to add features to it, you will have to rewrite it anyway. Nothing is so extensible that it can do anything you want
@Hazarth well i have worked with mostly small to medium startups with niche markets and fast development cycles, so i have a habit of delegating any trivial task to a library first than writing on my own, since libraries usually have 9/10 usecases solved as an offering.
i bet glide and gson are the world's most renowned and commonly used libraries for decoding and deserialization and it would be a real pain to recreate the wheel all over again just for the fact that my library needs to be size concious.
my library would actually be giving my client an interior code because no matter how good i am , I won't be able to keep up with the security and feature enhancements of those specific libraries by their creators .
the sise constraint for a library is a very stupid point . if 8/10 apps( a very realistic probability) are using gson and glide, the final versions of app will still have only 1 jar file of each lib and my library will be forced to use that too, thereby not adding to size
buy yours and others points are helpful, thanks. i think it might not be too bad either.my concern was that i will be working with a rotting knowledge and mostly maintenance, but i guess the would also be a learning experience for me
just the attitude of seeing at as "rotting knowledge" is already setting you back. You will never ever be able to see the advantages of those distinct approaches because you already decided for yourself that it's useless, lame and "rotting" and has no use or benefit at all ever... So reasonably, with that mindset, what can you expect to learn?
The proper engineering mindset is to make stuff work no matter what the constraints are... not to mention, old tech is still being updated today... Why do you think Wordpress is still so popular today? It's been literally released over 18 years ago, and it's still getting support and some love today, even though it's a steaming pile of shit in my personal opinion, it's still secure and up-to-date...
really the only thing that matters in the end is that you get paid a salary you're somewhat happy with
@Hazarth well i guess this will be a big learning for me, because i do have a mindset of ditching stuff due to various constraints.
However this mindset also justifies learning outdated stuff like assembly, bash, perl ,php, wordpress or floppy disks just because some company is still using those and willing to pay people for continuously maintaining them.
i personally think that those technologies are not worth learning (unless being absolute passionate about them) if i am able to give similar output using modern technologies like kotlin, java, js etc , and those learning them out of passion or other reasons will soon have to learn something new.
Additionally i think the advantage of working on cutting edge technologies is that we always stay in demand and our worth is tied with the growth of technology itself. the technology also evolves by fixing the mistakes of previous gen, so its fun to work with. today the experts in blockchain are in high demand, but perl? not so much
Assembly isn't outdated. It's so present in so many languages.
Java bytecode? Assembly.
Python bytecode? Assembly.
Web assembly? Assembly.
Just different abstractions. Different types of machine code.
Writing high performance code? You have to understand assembly, even if you can't write it.
Don't dismiss things until you understand what/why they're there. Wanna write ML code that doesn't run like a half dead dog? Understand assembly.
And if you think "working with cutting edge" makes you valuable, name one truly revolutionary thing from the last 10, 20 years. Microservices? Linux applications do one thing, and do it well. Lambdas? Algol68 (the year is in the name). Machine learning? I mean, these days neural networks are big clunky hammers that people throw at most problems, when there's a decent chance there's some old school DSP technique (that counts as ML) which would solve the problem better, faster, with less dev time. The only few exceptions to this are the likes of language and vision. Space X will be using the same concepts that put a rocket on the moon 50 years ago, just with more complexity, more detail.
Watch this: https://youtu.be/AbgsfeGvg3E
And blockchain vs perl, you think the perl programmers are suddenly redundant? No. They have transferable skills. Blockchain is just a new bubble, but it's still using a p2p network (oh hey, bit torrent? Tor?) operating in a mesh network (oh hey, they use loss resilient routing, just like old physical routers).
Don't dismiss stuff you don't understand, or you're gonna get schooled and made to look like an idiot by those that do.
In interviews, I don't bother talking about specific languages, because if they use it I probably have 6+ months experience in it or can pick it up in an afternoon.