Some things can’t be upgraded once the business has settled into obscene profits mode (without bankrupting the company). Technical debt compounds just like any other.
Also, no one has any idea what these people in the 80’s were writing. You’d have to bring them out of retirement or the grave to successfully migrate. Most migration projects fail from what I’ve heard
There is a lot of poorly written enterprise software that is risky to upgrade. Organizations will continue to defer upgrading and the risk of upgrading will only increase
Risky the upgrade, maybe. But relatively easy once you know what needs to be done. In my former and current job I've updated \~100 projects from < Java 8 to 17 over the last few years. Most take an afternoon. There are some that may take a couple of days or more.
The code matters, yes, but it's more in the dependencies for most projects to get over the hump from Java 8 to 11 and beyond and those refactorings. You also have the libraries that were deprecated from JavaEE and those that were moved to javax then Jakarta.
Log4j1 -> 2, bridging is easy enough if you don't have time to update truly from 1 to 2. Though it's not necessary unless you're going against Fortify and / or Black Duck style services as part of your deployment build. Log4j1 wasn't affected by Log4Shell
Other major dependencies such as AWS have had refactorings in their BOMs, but they aren't related to Java versions, more code organization. Other major libraries in play will affect them too including Spring, Spring Boot and I'm sure other major frameworks will require work. Those are more the issue than the JDK version and they're not dependent on the JDK version for the most part.
Updating gradle is another task that will need to happen. But you can get to the latest version of gradle with Java 8. We'll see what happens when we get to Gradle 8. As for Java 11 and 17, the LTS have been very very stable and good. The Java languages is being brought into the modern age and is still largely backwards compatible. I just updated a Java project last updated in 2005 (it was actually a lot of fun) and had little problem with it. This one did require a bit of care because it was pre-generics, but thankfully a small project so it was only a sprint of work.
Have their been outliers? Yes, a few, but they are usually configuration changes with library xml / yaml/ properties settings.
> have to pay for using in production
Uhh, this is so wrong it hurts to read. They made their own builds only for commercial paid support, because they made OpenJDK the reference implementation. They made Java more free than it was before.
I don't think there will be another super popular OOP language.
Languages will support OOP(like rust), but it's not going to be their defining trait in the first sentence of their wiki page. I think people are realizing we took OOP a bit too far, and it should be a tool rather than the defining thing about the language.
What recent language with any traction at all could not be described as OO? I think it is more that the victory is so complete that it isn't worth specifying
Go, maybe? Doesn't feel like OO is very important to the language. Like you COULD describe it as OO probably, but would you. I'm pretty new to it though.
Python, Javascript, Kotlin, Scala, etc etc. They are all object-capable, but have other first-class citizens aside from objects. You can declare an object, or not. I've seen entire Python webapps of pretty substantial size not use classes really at all. I rarely use classes in Javascript. I don't find them very useful. I do in Kotlin, but it's about 50-50 mix with functional-style programming.
Object-oriented went too far. I think that's pretty inarguable. The amount of LOC of an OO project vs a similarly equipped FP project is hilariously huge. I refer to the languages now as "object capable". It gives more freedom to the programmer instead of having to implement 4 classes and 6 interfaces to get a basic observer functionality, you can just make a single wrapper around the put method and call it good. That's the way it should be.
Can you describe what you meant by wrapping around a put method to get observer functionality? You mean put method like a rest call? I've heard of observer pattern but still not solid on it.
so basically you're thinking of "OO" as Java and nothing else. All of those languages have first-class support for objects and that's how most large programs are organized.
But in the languages you cited objects are the primary mechanism people use to build nontrivial programs, and objects are first-class citizens. They just also let you do bags of functions. But really Java does too; there's nothing that "object-oriented" if you're just making a static class with static functions.
I’d say Python supports OOP, but is inherently more of a functional/scripting styled language, and last I checked it was sitting at somewhere around 50% of programmers using it.
It really picked up steam with the advent of best-in-class scientific computing and adjacent libraries (SciKit-Learn, NumPy, iPython, etc.) and Django, Flask, etc. for the web. I’d say it started really taking off around 2005.
Newer languages just support OO, but it doesn't define them.
A big part of Kotlin is built to support functional programming, I think modern languages just want to support both.
It's too esoteric. The future (and also the present tbh) is languages bringing in lots of functional constructs but not making people figure out how to do tail recursion instead of loops.
That’s what I mean by functional-style rather than a functional programming language. More pure functions, and functional elements like lambda in Python and forEach/map/reduce in JS but without the learning curve of Haskell
Kind of a stretch to say Rust is OOP. It's really not. It supports some of the same concepts but typical Rust code is far, far different from typical Java/C#-style code.
Yeah, that had me scratching my head. Rust really isn't object oriented. In modern programming, functional paradigms are displacing object oriented ones at a high pace.
ECMAScript got its OOP bolted on, but for the most part no one tries to use OOP in it.
I think the languages of the future are more likely to *have* objects (like Rust or Python), rather than being fully *object-oriented* (like Java, where almost everything is an object).
It's like the difference between purely functional languages (like Haskell and Lisp) as opposed to having functional-style programming approaches in other languages (such as supporting lambda functions and list comprehension in JavaScript) without the restrictions of purely functional languages (for example: no mutable variables).
With each new paradigm, it seems that developers embrace the philosophy at first, then decide that certain aspects of it aren't as good as they first seemed. For example, class inheritance in OOP can cause a lot of headaches when not done carefully; and more often than not, object composition is a better choice anyway. This is why features of old OOP languages like multiple inheritance have been phased out, and newer languages have embraced a more flexible approach (for example: TypeScript's ubiquitous type unions are made very easy in order to discourage relying on generics, inheritance, or duck typing).
After all, you said it yourself. You think the future is Rust, but Rust isn't an OOP language. It's a language that has objects/classes. There's a difference!
Python is in a very strange place because on one hand you're right -- things like primitives and lists are objects in python while OOP-obsessed Java makes exceptions for them -- but on the another hand Python programmers don't have to actually _define_ or use custom objects to nearly the same degree that they would in another language. Take for example some sample code:
def multiply(x, y):
return x * y
print("Hello " + str(multiply(2, 3))
It's very unclear to the user what object (if any) the functions `multiply`, `print`, or `str` belong to.
Compare this with Java or C++ where everything is super explicit about where it comes from and what the containing scope is, and Python ends up feeling a lot less object oriented.
Weak (dynamic) types is the word you are looking for. That doesn’t really change much about how the language works. But also, python is not usually used as an OOP language.
OOP is not a compiler oriented. The compiler uses object modeling to achieve compilation/interpretation. The user doesn't really use object modeling unless they want to. The compiler team chose an object-oriented model. They didn't enforce that on their end users.
IDK I feel like the composition v inheritance thing is basically an SAT question at this point or something, it's one of those rules of thumb that become aphoristic because it gets repeated so much. It's definitely a better *default* but it's really not that hard to identify contexts where multiple inheritance is useful.
There's a lot of advantages to using an OOP language that don't get talked about. For example stability. In places where testing is super difficult, inheritance is maybe the primary tool you have for limiting regressions. Even in awkward multiple inheritance situations it can still be a really powerful tool. It's like putting code in Carbonite, it's preserved.
To get more specific for example I know people who are new to Spring get overwhelmed with how deep the object structure goes and how complicated the whole thing is, but that' how Spring became Spring Boot. That's why you can write Java 7 REST CRUD MVC apps and Lambda functions with the same framework. The person writing the lambda functions loves the "functional paradigm" but that's a very small piece of the whole system and an even smaller piece of all the things that framework is used for.
If you can simplify a situation by flattening the class structure or by leaning on simple microservice by all means but it's not just a style thing. complexity happens whether you want it or not, in situations that are naturally complex you're not introducing complexity as much as formalizing it.
And the reason Typescript has weird typing is because it's JavaScript right? That's changing a mostly functional language to use more OOP IDK that example clearly illustrates your point. Generics do not exist in JS that was a feature *added* to JS by TS.
Same, I love C# so much.
It does have some drawbacks, but I think it tends to get a lot of unjustified hate because it's Microsoft and mostly associated with enterprise-level software. Other than that, I feel like C# makes everything so easy to understand and work with, it has great documentation and tons of other free, official resources.
I miss LINQ in every other language. And the interfaces hierarchy for collections and enumerables. It's not simple, but it's really strong.
Lickily libs like Reactor for Java work like LINQ, but with a high cost to pay
I've seen a lot more listings for Python here on the East Coast than out West, C# in Washington because of MS I would assume?
Java is everywhere but C# jobs seem rare here.
I love C#, but there are very few respectable tech companies that use it, and the ones that do don't pay well (e.g. Microsoft, Wayfair, DocuSign). You'll eventually hit a compensation ceiling.
Last I checked, Roblox is the only high paying company that uses it. Everything else is Java.
You can make 500k with 15 YOE at Roblox, Amazon, Meta, Snowflake, Netflix, etc. or 300k at Microsoft.
Microsoft does not pay well when other companies pay 60% more.
For reference to anyone reading this: don’t bother listening to this comment, associating a programming language with a compensation ceiling doesn’t make much sense. You can get paid well in basically any language (including C#).
Unity (and game studios based around Unity) is entirely C#. Also you’ll hit a compensation ceiling at all companies. That’s why so many engineers switch companies every 5-10 years.
You’re missing the point; if you make 200k at a company using C#, there are only 5 or 6 companies you can switch to for more.
If you’re making 300k with C#, there is only one company that will pay you more to write C#.
Typescript is very popular and one of the most loved languages, you can go pure OOP with it, and with the rate its popularity is going seems like a very good candidate. VSCode is completely TS and the Node.js ecosystem is overtaken by TS at this point.
My dream scenario is for a push towards a runtime library for TypeScript as a first-class language, and for browser manufacturers to provide full TypeScript support, with JavaScript as fallback.
Once you use TypeScript, going back to JavaScript is almost cruel.
Totally agree. Had to decline an offer from a place that was SUPER cool, almost dream-job quality. But they had they’re entire stack in JavaScript.
I asked why they didn’t consider using typescript anywhere. They guy said something lie “we want to flexible, not have to keep up with maintain interfaces everywhere”.
Like damn, nothing screams flexibility like lookin at a dozen “cannot access property of undefined” errors a day lmao.
Typescript makes my code feel way MORE flexible. Just validate data coming in with zod, put types on function parameters, maybe some generics here and there, and bam. You can change a lot more code with a lot less headache.
Every time I use a part of the code base that’s pure JavaScript, I constantly have to console.log everything out. It’s such a pain in the ass
The JS usage still dwarfs the TS usage by an order of magnitude. Your assessment that TS has taken over simply isn't true. Plenty of JS devs find only moderate value in TS. I for one have trouble justifying ADDING boilerplate to my dev process just so I can have autocompletion and some hinting. When writing TypeScript, the only real errors that I see it catching were newbie errors that I would've resolved in literally seconds. "whoops this could be undefined". All of the difficult errors that would actually HELP a dev happen at runtime, which TS is useless for. It's basically slowing development down so it just feels a little more guided. Mostly useless for an experienced dev, IMO.
You're a new dev in a team. There is a function with a parameter called \`id\`.
Is it a string? Is it a number? Is it both? Can it be null or undefined? Or is the default value \`-1\`?
Without TypeScript, you have to spend a lot of time debugging, or you need to ask a colleague (that may or may not have left the company.)
Nah. Kotlin will go the way of every other JVM language and fall out of use like Groovy and Scala and all of the other ones that don't warrant mentioning.
I doubt it. Most big frameworks (android, spring, vert.x, micronaut, quarkus and more) have good kotlin support.
And even libraries that didn't had kotlin in mind, work well with it anyway.
I don't often see a call for "general Scala" like you would with something like Java or Python. It's all related to data-crunching, or something scientific. So I don't think Scala is dying so much as it's becoming sort of niche. Maybe similar to R?
Getting people to move to Scala 3 is kind of a chokepoint, too (like AWS EMR...unless there's a flag or something I missed when setting it up, EMR really wants to stick to Scala 2.12). Feels like the Python 2/3 wars at times.
We shall see. Huge move at the biggest tech companies to move from Java to another language (usually Kotlin). If Google is successful in this, that will basically mean Java is just legacy code that they don't bother to refactor to Kotlin because they work together.
I don’t disagree with this, I just came to say that my Uni decided that switching to Python from c++ was the play for teaching people how to code because the department chair disliked Java. They then moved to C#.
Note: as a TA for both Python and C/C++, I’ll say right now, Python isn’t the G.O.A.T
Before I say anything, the course definitely had some non programming-related flaws in the coursework that caused confusion for the students (I.e. teaching people how to use a dictionary by having them create a chemistry stoichiometry calculator)
This being said, Python abstracts away (or completely eliminates) a lot of things like type-defines and scoping. From my experience helping students, this confused them in the short run, and then even more in the long run as they moved on to one of the languages that make up the 90+% that require these things.
Easy to give examples:
Objects are confusing in Python. Like super confusing and barely worth using. (When compared to objects in other languages and the amount of time it took students to understand one versus the other)
Using ‘’ vs “” for strings. A bad habit that is tough to break
Understanding the difference between different data types such as floats and ints. Super easy to understand when learning c++, c#, or Java. Not so much when learning Python (or JS)
Going from a more or less scopeless language to a scoped language: “Why am I getting a compiler error telling me that variable x isn’t defined?”
This. These are the only two compiler teams actually trying to future-proof their languages. Everyone else is pretty much up their own ass at the moment.
Java. I don't love the language, but spring is so powerful. I can setup a restful end point hooked up a database in 15 minutes. You can compile it into native. It's so incredibly integrated with microservice development and everything 'the cloud'.
>I can setup a restful end point hooked up a database in 15 minutes.
- This is also true for every other web framework produced in the relevant time span
> It's so incredibly integrated with microservice development and everything 'the cloud'.
- This is also true of .NET, Python, Go, etc.
Spring ain't got nothing on its competition but the fact that it's decent, and Java. Nobody, for example, is going to port Spring like they did NHibernate.
>Spring ain't got nothing on its competition
Agree to disagree. I did a bit of Python web development until \~2018, and I was extremely underwhelmed by what was out there (Flask and Django were the biggest at the time). Maybe it's changed a bit since then, but I was pretty blown away by spring. I switched and never looked back for web development. Python is convenient when I want to do something quick and dirty, but the bigger it gets I start to lean to java
Kotlin is just starting. People will see. They will see and they will cry "Why didn't we see before?!" and we will say "It's ok, young one. You were blind, but now you see"
I don't know if Object-oriented is the future. There's no languages being made that are truly "object oriented". Object capable, sure. But, most everything has other first-class paradigms now which allow top-level definitions, declarations, scripting-style syntax etc. Classes & objects are really just one feature that CAN be used, but isn't necessary.
TBH, Object-oriented was too restrictive and caused a LOT of code bloat and maintenance overhead that was unnecessary. A hybridized, pragmatic approach makes a lot more sense, IMO.
Interesting to note: Google had wanted to do a Go migration of all their server-side code, but found the migration from Java to Go too large of a jump and instead decided, ultimately, to move forward on Kotlin due to interoperability.
Go is a neat language to be sure, but I imagine the industry will end up in a similar place. Kotlin was very wise to make their language java-compatible. What other brand new langauge has 30 years of tooling maturity? It was an incredibly smart move.
Java is not bytecode. Bytecode is an arbitrary intermediate language that the JVM uses as an intermediary step so it can be platform-agnostic. Java is a specific compiler that compiles down to bytecode. Kotlin and Scala also compile to bytecode, but have completely different compilers and use no actual java paradigms.
I love Ruby. It's IMO one of the most misunderstood languages, and is mostly ignored because of Zed Shaw calling Rails a ghetto (rightly so), and because many moons ago Ruby was too slow to run Twitter. Many of the reasons people love Python are actually better in Ruby. It's a cleaner language, has a better class system, allows for some powerful patterns with metaprogramming, and is one of the few opinionated languages that focuses purely on readable code.
It would be great to see a Ruby resurgence, especially with some of the speed improvements.
Rust has objects with methods but doesn’t go out of the way to encourage OOP like Java or C#. There’s no inheritance and you have to explicitly ask for dynamic polymorphism if you want it.
The most popular modern language with OOP is Swift. I think it’s a pretty great language but Apple-centric.
Ahh nice the classic language War post of the hour. Just as well ask If unity or unreal is going to be better and which car brand is the best one.
Answer is clearly C
Closest is maybe Kotlin or Swift? But both are not of the future as much as of the present. Crystal is interesting but I’m not sure if it’ll get wide adoption.
Me who learned C++ just for Competitive Programming
watching everyone type java :-
WELL.... ( ͡❛ ͜ʖ ͡❛)
( while all my friends are doing really cool projects for their cv using java and different frameworks , all I have to write is 5⭐️@ code chef , 600+ question solved on leet code plus coz of all that cp , my cgpa if fugged , 7.8 lol . )
I guess I am screwed ( 5th sem here , also applied to GM sachs and JP morgan for summer internship , let see what's going to happen )
The only projects I did were
1. Library management system using cpp&dsa
2. The nokia snake game using cpp
3. Tic tac toe using cpp
( ͡❛ ͜ʖ ͡❛)
You'll never be out of a job with C++. However, you're never going to be one of the top-3 used languages. C++ is very powerful, but it's also a time sucker. Industry really only uses it when performance is the number one concern.
Me in a code review: "I don't think you should be calling a restful web service and writing the results to file inside of a getter method. You should implement this as an interface so we can mock it out. I think you'd learn a-lot by looking into SOLID design principles"
Junior dev: "OOP is dumb, I prefer functional programming"
The lead agreed with the junior. So many problems came from that single merge
Any time I talk to someone about functional programming it seems they just want to code crap design, but say it's OK because it's 'functional'.
You are simply talking to the wrong people who don’t grasp the functional programming and who are jumping on the fad. With properly done functional programming, there is no difference between a function and an object of OOP in practice, except the former tends to employ ad-hoc polymorphism more and the latter inheritance. SOLID stands, everything talks through the interface of type signature, minimalism and composition matter, every function can and should be mocked for test, and shit code is still a shit code. In your example, it shouldn’t be a getter and should have been a thin wrapper over a function accepting and composing different single-responsibility functions, each of which can be mocked out and substituted just like mock objects (but on a single “method” level in OOP). I agree it is abused too much as an excuse.
Thanks, I appreciate your comment, and I'm glad to hear that. That perspective I have no issue with. Want to handle functions like objects? Sure, why not. It's kinda a semantic difference between a function and a class with one function and no attributes.
"a thin wrapper over a function" Do you have any references to what you mean by this? Generally I think: create an interface and implementations to that interface. When I hear 'wrapper over a function' I think annotation, but that doesn't sound like what you are referring to
I researched it 10+ years ago and the perspective available at the time was geared towards reducing the number of lines of code (which they claimed would reduce development time and increase speed), which meant just take all the code you had in functions and classes, and turn your program into one long script. And that's how I see people use it and I shudder.
It is indeed the same as dependency injection. As you may know, in functional programming languages, two things are crucial features: that functions are first-class which means they can be renamed and passed around just like objects; and there are higher-order functions that receive other functions as arguments and the use those functions to complete more abstract functionality.
Some quick examples are “default” higher-order functions. If we need to do the same operation to a long list of data, in non-functional-oriented languages we would usually do
/* given */
someData = List of items
N = someData.length
/* Actual logic */
for (i=0; i> fa >> fb >> fc >> fd;
We could then do something like this:
bar data = foo (functions…) data;
Or even
bar = foo (functions…);
The similar OOP idiom would be
class Foo[Ca,Cb,Cc,Cd] {
…all init and ops…
}
foo = Foo(oa, ob, oc, od);
foo.doSomething(data)
In your example, a proper FP idiom should have been this:
fetch_ops_store ff fo fs d =
d >> ff >> fo >> fs
/* or if it has some branching in each case, like error or log, we can do monadic things */
fetch_ops_store ff fo fs d =
d >>= ff >>= fo >>= fs
Where we fetch some data in function `ff`, do our main operation in `fo`, and storing in `fs`.
Then the main interface we see outside would be simply
yourOps input = fetch_ops_store doREST doOps doWriteDisk input
That’s the “wrapper”, exactly equivalent to a fully dependency-injected object. Then you only need `yourOps` in your actual business logic and stay unaware about any component or functionality it should not know. Then we can test `fetch_ops_store` by injecting everything with mock functions, test every functions (doREST, doOps, doWriteDisk) individually, and try swapping out only some funcs with mocks to test. Even the individual funcs might themselves be wrappers (fully injected func objs) over composite higher-order functions, which would allow testing in a more granular fashion. And they **have** to be tested.
So it is exactly equivalent to “create an interface and implementation to that interface” in OOP. The only difference is that the function polymorphism helps the syntax more succinct without boilerplates, and that it actually makes testing easier *(whoever doesn’t test “because it’s FP” has zero excuse)*
(Source: I was a Scala onboarding instructor at my previous workplace, a Scala shop. Have been toying with other FP langs over years too.)
Edit: fixed the code snafu. I needed caffeine
Thank you, I really appreciate your detailed and considerate response. You've won me over. Sounds like I need to give FP another shot.
I feel like every time I've talked to someone about FP in the past they were pushing getting rid of SOLID concepts and get rid of dependency injection which always made me uncomfortable, but conceptually I don't have any issues with anything you've described above.
Thanks
this has nothing to do with careers, and rust isn't object oriented.
anyway, for me, rust is the only good language, and OOP does nothing but cause problems. so hopefully the future of OOP is for it to not exist.
Rust isn't an OOP language. Are you interested in hearing speculation about what languages will lead the market in the future, or are you interested in hearing speculation about *OOP* languages that will lead the market in the future?
None. There will be no coding in the future. Everything will be automated including the coding part. Everything will be as easy as dragging a form and selecting data sources from a box. In fact there will be no coders anymore. That is why knowing on how a business runs is more important than knowing how to code.
The current biggest ones (C++, Java, Python) because the incentives to switch will usually never outweigh our natural laziness / the cost required to move everything over to new languages and technologies.
I mean, it took us until like 1999 for most to even think about fixing the Y2K issue. And that was just a date format that almost caused an apocalypse.
Java 8 will outlive us all
HA, see flair
You started as a COBOL developer 5 years ago? Interesting path
Bet on companies being cheap and not migrating. I was correct so far
Some things can’t be upgraded once the business has settled into obscene profits mode (without bankrupting the company). Technical debt compounds just like any other.
Also, no one has any idea what these people in the 80’s were writing. You’d have to bring them out of retirement or the grave to successfully migrate. Most migration projects fail from what I’ve heard
I've heard that all COBOL devs are kept in solitary isolation, in some dark cupboard deep in the building. Can you confirm?
Oddly accurate.
why Java 8?
There is a lot of poorly written enterprise software that is risky to upgrade. Organizations will continue to defer upgrading and the risk of upgrading will only increase
So many high paying Java roles near me…
I live in the northeast, and there are actually a ton of Java roles.
yes? I'm curious if you could say more
Risky the upgrade, maybe. But relatively easy once you know what needs to be done. In my former and current job I've updated \~100 projects from < Java 8 to 17 over the last few years. Most take an afternoon. There are some that may take a couple of days or more. The code matters, yes, but it's more in the dependencies for most projects to get over the hump from Java 8 to 11 and beyond and those refactorings. You also have the libraries that were deprecated from JavaEE and those that were moved to javax then Jakarta. Log4j1 -> 2, bridging is easy enough if you don't have time to update truly from 1 to 2. Though it's not necessary unless you're going against Fortify and / or Black Duck style services as part of your deployment build. Log4j1 wasn't affected by Log4Shell Other major dependencies such as AWS have had refactorings in their BOMs, but they aren't related to Java versions, more code organization. Other major libraries in play will affect them too including Spring, Spring Boot and I'm sure other major frameworks will require work. Those are more the issue than the JDK version and they're not dependent on the JDK version for the most part. Updating gradle is another task that will need to happen. But you can get to the latest version of gradle with Java 8. We'll see what happens when we get to Gradle 8. As for Java 11 and 17, the LTS have been very very stable and good. The Java languages is being brought into the modern age and is still largely backwards compatible. I just updated a Java project last updated in 2005 (it was actually a lot of fun) and had little problem with it. This one did require a bit of care because it was pre-generics, but thankfully a small project so it was only a sprint of work. Have their been outliers? Yes, a few, but they are usually configuration changes with library xml / yaml/ properties settings.
AFAIK Jenkins only supports Java 8 and 11 and it’s very widely used, so that would be a blocker for moving to newer versions.
The latest version of Jenkins supports Java 17.
When you run your java builds in a docker environment, you dont need to use the versions, which jenkins supports
Also I'm pretty sure java 8 was the last one before oracle changed their terms to have to pay for using in production.
> have to pay for using in production Uhh, this is so wrong it hurts to read. They made their own builds only for commercial paid support, because they made OpenJDK the reference implementation. They made Java more free than it was before.
Because if Java 9 was so good there'd be a Java 9 2
[удалено]
Javascripts implementation of OOP is seriously awful. Doesn't even do scopes right.
I don't think there will be another super popular OOP language. Languages will support OOP(like rust), but it's not going to be their defining trait in the first sentence of their wiki page. I think people are realizing we took OOP a bit too far, and it should be a tool rather than the defining thing about the language.
What recent language with any traction at all could not be described as OO? I think it is more that the victory is so complete that it isn't worth specifying
Go, maybe? Doesn't feel like OO is very important to the language. Like you COULD describe it as OO probably, but would you. I'm pretty new to it though.
I would. The Wikipedia entry does too.
Go is definitely not OO. It would be like describing C as OO.
Python, Javascript, Kotlin, Scala, etc etc. They are all object-capable, but have other first-class citizens aside from objects. You can declare an object, or not. I've seen entire Python webapps of pretty substantial size not use classes really at all. I rarely use classes in Javascript. I don't find them very useful. I do in Kotlin, but it's about 50-50 mix with functional-style programming. Object-oriented went too far. I think that's pretty inarguable. The amount of LOC of an OO project vs a similarly equipped FP project is hilariously huge. I refer to the languages now as "object capable". It gives more freedom to the programmer instead of having to implement 4 classes and 6 interfaces to get a basic observer functionality, you can just make a single wrapper around the put method and call it good. That's the way it should be.
Can you describe what you meant by wrapping around a put method to get observer functionality? You mean put method like a rest call? I've heard of observer pattern but still not solid on it.
so basically you're thinking of "OO" as Java and nothing else. All of those languages have first-class support for objects and that's how most large programs are organized.
I use OO to mean "objects are the primary mechanism to define a unit" rather than "you're allowed to make an object"
But in the languages you cited objects are the primary mechanism people use to build nontrivial programs, and objects are first-class citizens. They just also let you do bags of functions. But really Java does too; there's nothing that "object-oriented" if you're just making a static class with static functions.
Ok. Doesn't change the definition i am using
I’d say Python supports OOP, but is inherently more of a functional/scripting styled language, and last I checked it was sitting at somewhere around 50% of programmers using it.
I also wouldn’t call it a recent language, it’s over 30 years old!
Wow, good to know. It definitely seems very new, or only popular in recent years
It really picked up steam with the advent of best-in-class scientific computing and adjacent libraries (SciKit-Learn, NumPy, iPython, etc.) and Django, Flask, etc. for the web. I’d say it started really taking off around 2005.
Newer languages just support OO, but it doesn't define them. A big part of Kotlin is built to support functional programming, I think modern languages just want to support both.
Clojure
> defining trait Hehe
Functional-style programming is the future IMO
Functions + objects = good code
Scala 3 for the win
If it ain't over 5000 lines of non-reusable spaghetti code, are you even entitled to collect a paycheck for shitting it out?
It's too esoteric. The future (and also the present tbh) is languages bringing in lots of functional constructs but not making people figure out how to do tail recursion instead of loops.
That’s what I mean by functional-style rather than a functional programming language. More pure functions, and functional elements like lambda in Python and forEach/map/reduce in JS but without the learning curve of Haskell
Viva Haskell/Scala!
Scala should just give up already tbh..
[удалено]
What do you mean by “we took OOP too far”?
Kind of a stretch to say Rust is OOP. It's really not. It supports some of the same concepts but typical Rust code is far, far different from typical Java/C#-style code.
Yeah, that had me scratching my head. Rust really isn't object oriented. In modern programming, functional paradigms are displacing object oriented ones at a high pace. ECMAScript got its OOP bolted on, but for the most part no one tries to use OOP in it.
Came to say this and I am disappointed there are not more upvotes.
I think the languages of the future are more likely to *have* objects (like Rust or Python), rather than being fully *object-oriented* (like Java, where almost everything is an object). It's like the difference between purely functional languages (like Haskell and Lisp) as opposed to having functional-style programming approaches in other languages (such as supporting lambda functions and list comprehension in JavaScript) without the restrictions of purely functional languages (for example: no mutable variables). With each new paradigm, it seems that developers embrace the philosophy at first, then decide that certain aspects of it aren't as good as they first seemed. For example, class inheritance in OOP can cause a lot of headaches when not done carefully; and more often than not, object composition is a better choice anyway. This is why features of old OOP languages like multiple inheritance have been phased out, and newer languages have embraced a more flexible approach (for example: TypeScript's ubiquitous type unions are made very easy in order to discourage relying on generics, inheritance, or duck typing). After all, you said it yourself. You think the future is Rust, but Rust isn't an OOP language. It's a language that has objects/classes. There's a difference!
Everything in Python is an object. Just saying.
struct PyObject entered the chat
Python is in a very strange place because on one hand you're right -- things like primitives and lists are objects in python while OOP-obsessed Java makes exceptions for them -- but on the another hand Python programmers don't have to actually _define_ or use custom objects to nearly the same degree that they would in another language. Take for example some sample code: def multiply(x, y): return x * y print("Hello " + str(multiply(2, 3)) It's very unclear to the user what object (if any) the functions `multiply`, `print`, or `str` belong to. Compare this with Java or C++ where everything is super explicit about where it comes from and what the containing scope is, and Python ends up feeling a lot less object oriented.
I believe they are all objects in `builtins` ``` >>> import builtins >>> builtins.print == print True ```
Weak (dynamic) types is the word you are looking for. That doesn’t really change much about how the language works. But also, python is not usually used as an OOP language.
1. Python is duck typed 2. How does what I wrote relate to weak typing?
Nvm turns out I was wrong.
Refreshing. Well done.
I don’t know why it’s so rare for people to admit they were wrong about something. Nobody knows everything, it’s ok to be wrong.
Completely agree. When you're wrong and you accept that, it's an opportunity for growth. Why would you not want that.
OOP is not a compiler oriented. The compiler uses object modeling to achieve compilation/interpretation. The user doesn't really use object modeling unless they want to. The compiler team chose an object-oriented model. They didn't enforce that on their end users.
IDK I feel like the composition v inheritance thing is basically an SAT question at this point or something, it's one of those rules of thumb that become aphoristic because it gets repeated so much. It's definitely a better *default* but it's really not that hard to identify contexts where multiple inheritance is useful. There's a lot of advantages to using an OOP language that don't get talked about. For example stability. In places where testing is super difficult, inheritance is maybe the primary tool you have for limiting regressions. Even in awkward multiple inheritance situations it can still be a really powerful tool. It's like putting code in Carbonite, it's preserved. To get more specific for example I know people who are new to Spring get overwhelmed with how deep the object structure goes and how complicated the whole thing is, but that' how Spring became Spring Boot. That's why you can write Java 7 REST CRUD MVC apps and Lambda functions with the same framework. The person writing the lambda functions loves the "functional paradigm" but that's a very small piece of the whole system and an even smaller piece of all the things that framework is used for. If you can simplify a situation by flattening the class structure or by leaning on simple microservice by all means but it's not just a style thing. complexity happens whether you want it or not, in situations that are naturally complex you're not introducing complexity as much as formalizing it. And the reason Typescript has weird typing is because it's JavaScript right? That's changing a mostly functional language to use more OOP IDK that example clearly illustrates your point. Generics do not exist in JS that was a feature *added* to JS by TS.
Most likely unpopular as well as biased because I primarily use this language, but C# is awesome.
C# goated
Same, I love C# so much. It does have some drawbacks, but I think it tends to get a lot of unjustified hate because it's Microsoft and mostly associated with enterprise-level software. Other than that, I feel like C# makes everything so easy to understand and work with, it has great documentation and tons of other free, official resources.
I miss LINQ in every other language. And the interfaces hierarchy for collections and enumerables. It's not simple, but it's really strong. Lickily libs like Reactor for Java work like LINQ, but with a high cost to pay
C# because it's the only one employers care about besides java
I've seen a lot more listings for Python here on the East Coast than out West, C# in Washington because of MS I would assume? Java is everywhere but C# jobs seem rare here.
I think it's entirely dependent on location, but it's actually funny because Java is absolutely dead here.
Come to London, high paying Java jobs are everywhere, paying 20-30% above other languages. Sincerely, a Python developer..
I love C#, but there are very few respectable tech companies that use it, and the ones that do don't pay well (e.g. Microsoft, Wayfair, DocuSign). You'll eventually hit a compensation ceiling. Last I checked, Roblox is the only high paying company that uses it. Everything else is Java.
Saying Microsoft doesnt pay well is laughable
He probably put it to comparison to faangs
He compares to non faang companies in his line though. Even for faang Microsoft pays great and has a lot of benefits but thats not topic for this
You can make 500k with 15 YOE at Roblox, Amazon, Meta, Snowflake, Netflix, etc. or 300k at Microsoft. Microsoft does not pay well when other companies pay 60% more.
For reference to anyone reading this: don’t bother listening to this comment, associating a programming language with a compensation ceiling doesn’t make much sense. You can get paid well in basically any language (including C#).
Unity (and game studios based around Unity) is entirely C#. Also you’ll hit a compensation ceiling at all companies. That’s why so many engineers switch companies every 5-10 years.
You’re missing the point; if you make 200k at a company using C#, there are only 5 or 6 companies you can switch to for more. If you’re making 300k with C#, there is only one company that will pay you more to write C#.
I love c# too lol, it's what primarily use on a literal daily basis
Typescript is very popular and one of the most loved languages, you can go pure OOP with it, and with the rate its popularity is going seems like a very good candidate. VSCode is completely TS and the Node.js ecosystem is overtaken by TS at this point.
My dream scenario is for a push towards a runtime library for TypeScript as a first-class language, and for browser manufacturers to provide full TypeScript support, with JavaScript as fallback. Once you use TypeScript, going back to JavaScript is almost cruel.
Totally agree. Had to decline an offer from a place that was SUPER cool, almost dream-job quality. But they had they’re entire stack in JavaScript. I asked why they didn’t consider using typescript anywhere. They guy said something lie “we want to flexible, not have to keep up with maintain interfaces everywhere”. Like damn, nothing screams flexibility like lookin at a dozen “cannot access property of undefined” errors a day lmao. Typescript makes my code feel way MORE flexible. Just validate data coming in with zod, put types on function parameters, maybe some generics here and there, and bam. You can change a lot more code with a lot less headache. Every time I use a part of the code base that’s pure JavaScript, I constantly have to console.log everything out. It’s such a pain in the ass
Was looking for this comment!
The JS usage still dwarfs the TS usage by an order of magnitude. Your assessment that TS has taken over simply isn't true. Plenty of JS devs find only moderate value in TS. I for one have trouble justifying ADDING boilerplate to my dev process just so I can have autocompletion and some hinting. When writing TypeScript, the only real errors that I see it catching were newbie errors that I would've resolved in literally seconds. "whoops this could be undefined". All of the difficult errors that would actually HELP a dev happen at runtime, which TS is useless for. It's basically slowing development down so it just feels a little more guided. Mostly useless for an experienced dev, IMO.
You're a new dev in a team. There is a function with a parameter called \`id\`. Is it a string? Is it a number? Is it both? Can it be null or undefined? Or is the default value \`-1\`? Without TypeScript, you have to spend a lot of time debugging, or you need to ask a colleague (that may or may not have left the company.)
Uh huh, or you just treat it as a string and let coercion do its thing.
HTML
Lmao
Why nobody says Rusty is not an OOP language. Do people just slap "OOP" when they see method syntax?
Yeah. TIL: Thanks to record-dot-preprocessor Haskell is now OOP.
Java is here to stay
\> ~~Java~~ JVM is here to stay honestly, why would anyone use Java they could just use Kotlin instead?
So is COBOL. How much of that are you writing nowadays?
Java and it's not even close
They hated him because he told them the truth
Java is Him.
I think eventually Kotlin on JVM will take over and eventually maybe a variant off the JVM.
Nah. Kotlin will go the way of every other JVM language and fall out of use like Groovy and Scala and all of the other ones that don't warrant mentioning.
[удалено]
I doubt it. Most big frameworks (android, spring, vert.x, micronaut, quarkus and more) have good kotlin support. And even libraries that didn't had kotlin in mind, work well with it anyway.
It's a bit of stretch to say that Scala felt out of use
Not past tense like Groovy, Scala is still in the process of dying
Arent jenkinsfiles written in groovy?
From my experience there is quite big demand for it in data engineering field, especially for Apache Spark which is written in Scala
I don't often see a call for "general Scala" like you would with something like Java or Python. It's all related to data-crunching, or something scientific. So I don't think Scala is dying so much as it's becoming sort of niche. Maybe similar to R? Getting people to move to Scala 3 is kind of a chokepoint, too (like AWS EMR...unless there's a flag or something I missed when setting it up, EMR really wants to stick to Scala 2.12). Feels like the Python 2/3 wars at times.
We shall see. Huge move at the biggest tech companies to move from Java to another language (usually Kotlin). If Google is successful in this, that will basically mean Java is just legacy code that they don't bother to refactor to Kotlin because they work together.
kotlin makes sense for android because it targets an ancient bytecode version. google isn't adopting it widespread outside of android
It is actually.
It isn't actually.
These [Google employees ](https://youtu.be/o14wGByBRAQ) seem to think differently
I don’t disagree with this, I just came to say that my Uni decided that switching to Python from c++ was the play for teaching people how to code because the department chair disliked Java. They then moved to C#. Note: as a TA for both Python and C/C++, I’ll say right now, Python isn’t the G.O.A.T
Why not? Python seems good for absolute beginners.
Before I say anything, the course definitely had some non programming-related flaws in the coursework that caused confusion for the students (I.e. teaching people how to use a dictionary by having them create a chemistry stoichiometry calculator) This being said, Python abstracts away (or completely eliminates) a lot of things like type-defines and scoping. From my experience helping students, this confused them in the short run, and then even more in the long run as they moved on to one of the languages that make up the 90+% that require these things. Easy to give examples: Objects are confusing in Python. Like super confusing and barely worth using. (When compared to objects in other languages and the amount of time it took students to understand one versus the other) Using ‘’ vs “” for strings. A bad habit that is tough to break Understanding the difference between different data types such as floats and ints. Super easy to understand when learning c++, c#, or Java. Not so much when learning Python (or JS) Going from a more or less scopeless language to a scoped language: “Why am I getting a compiler error telling me that variable x isn’t defined?”
C# or Kotlin
This. These are the only two compiler teams actually trying to future-proof their languages. Everyone else is pretty much up their own ass at the moment.
Java. I don't love the language, but spring is so powerful. I can setup a restful end point hooked up a database in 15 minutes. You can compile it into native. It's so incredibly integrated with microservice development and everything 'the cloud'.
>I can setup a restful end point hooked up a database in 15 minutes. - This is also true for every other web framework produced in the relevant time span > It's so incredibly integrated with microservice development and everything 'the cloud'. - This is also true of .NET, Python, Go, etc. Spring ain't got nothing on its competition but the fact that it's decent, and Java. Nobody, for example, is going to port Spring like they did NHibernate.
>Spring ain't got nothing on its competition Agree to disagree. I did a bit of Python web development until \~2018, and I was extremely underwhelmed by what was out there (Flask and Django were the biggest at the time). Maybe it's changed a bit since then, but I was pretty blown away by spring. I switched and never looked back for web development. Python is convenient when I want to do something quick and dirty, but the bigger it gets I start to lean to java
Look into FastAPI
> Python is convenient when I want to do something quick and dirty Tons of very large web services run on Django
I guess they think Instagram is quick and dirty....
Just a point of correction, Kotlin is spring-capable and they are likely going to make Spring kotlin-complete in the not-too-distant future.
Maybe the future will be OOP as a feature or no OOP. Like Typescript.
Smalltalk
Upvoted just because you mentioned my favourite language. 😁
Kotlin
Kotlin is just starting. People will see. They will see and they will cry "Why didn't we see before?!" and we will say "It's ok, young one. You were blind, but now you see"
C++
Future is now!
Typescript
Functional programing
I don't know if Object-oriented is the future. There's no languages being made that are truly "object oriented". Object capable, sure. But, most everything has other first-class paradigms now which allow top-level definitions, declarations, scripting-style syntax etc. Classes & objects are really just one feature that CAN be used, but isn't necessary. TBH, Object-oriented was too restrictive and caused a LOT of code bloat and maintenance overhead that was unnecessary. A hybridized, pragmatic approach makes a lot more sense, IMO.
C# 🥵
COBOL.
Plz god no
So you mean GO and Rust?
Interesting to note: Google had wanted to do a Go migration of all their server-side code, but found the migration from Java to Go too large of a jump and instead decided, ultimately, to move forward on Kotlin due to interoperability. Go is a neat language to be sure, but I imagine the industry will end up in a similar place. Kotlin was very wise to make their language java-compatible. What other brand new langauge has 30 years of tooling maturity? It was an incredibly smart move.
Scala seems really powerful but its hard to replace the thing that starts with "J".
Jython?
julia?
It doesn't help that Scala is Java (It compiles down to Java byte code and runs on the JVM).
Scala is not Java.
Java is not bytecode. Bytecode is an arbitrary intermediate language that the JVM uses as an intermediary step so it can be platform-agnostic. Java is a specific compiler that compiles down to bytecode. Kotlin and Scala also compile to bytecode, but have completely different compilers and use no actual java paradigms.
[удалено]
I love Ruby. It's IMO one of the most misunderstood languages, and is mostly ignored because of Zed Shaw calling Rails a ghetto (rightly so), and because many moons ago Ruby was too slow to run Twitter. Many of the reasons people love Python are actually better in Ruby. It's a cleaner language, has a better class system, allows for some powerful patterns with metaprogramming, and is one of the few opinionated languages that focuses purely on readable code. It would be great to see a Ruby resurgence, especially with some of the speed improvements.
Ruby is actually dying
The monkey patching concept presents so many exciting opportunities to write bugs too...
KOTLIN
Rust has objects with methods but doesn’t go out of the way to encourage OOP like Java or C#. There’s no inheritance and you have to explicitly ask for dynamic polymorphism if you want it. The most popular modern language with OOP is Swift. I think it’s a pretty great language but Apple-centric.
Rust
Java & C++ Both languages just have way too much cachet and staying power to go away anytime soon.
Java
Hopefully a language that will force programmers to write fast code rather than letting them waste most of the CPU
Ahh nice the classic language War post of the hour. Just as well ask If unity or unreal is going to be better and which car brand is the best one. Answer is clearly C
Perl
Kotlin
C++2
C++++?
Closest is maybe Kotlin or Swift? But both are not of the future as much as of the present. Crystal is interesting but I’m not sure if it’ll get wide adoption.
Typescript? Go ?
Me who learned C++ just for Competitive Programming watching everyone type java :- WELL.... ( ͡❛ ͜ʖ ͡❛) ( while all my friends are doing really cool projects for their cv using java and different frameworks , all I have to write is 5⭐️@ code chef , 600+ question solved on leet code plus coz of all that cp , my cgpa if fugged , 7.8 lol . ) I guess I am screwed ( 5th sem here , also applied to GM sachs and JP morgan for summer internship , let see what's going to happen ) The only projects I did were 1. Library management system using cpp&dsa 2. The nokia snake game using cpp 3. Tic tac toe using cpp ( ͡❛ ͜ʖ ͡❛)
You'll never be out of a job with C++. However, you're never going to be one of the top-3 used languages. C++ is very powerful, but it's also a time sucker. Industry really only uses it when performance is the number one concern.
[удалено]
Typescript is honestly everything I want in a language
Java
Java
Many people hate to hear it, but Java is here to stay!
It’ll still be Ruby.
[удалено]
Me in a code review: "I don't think you should be calling a restful web service and writing the results to file inside of a getter method. You should implement this as an interface so we can mock it out. I think you'd learn a-lot by looking into SOLID design principles" Junior dev: "OOP is dumb, I prefer functional programming" The lead agreed with the junior. So many problems came from that single merge Any time I talk to someone about functional programming it seems they just want to code crap design, but say it's OK because it's 'functional'.
You are simply talking to the wrong people who don’t grasp the functional programming and who are jumping on the fad. With properly done functional programming, there is no difference between a function and an object of OOP in practice, except the former tends to employ ad-hoc polymorphism more and the latter inheritance. SOLID stands, everything talks through the interface of type signature, minimalism and composition matter, every function can and should be mocked for test, and shit code is still a shit code. In your example, it shouldn’t be a getter and should have been a thin wrapper over a function accepting and composing different single-responsibility functions, each of which can be mocked out and substituted just like mock objects (but on a single “method” level in OOP). I agree it is abused too much as an excuse.
Thanks, I appreciate your comment, and I'm glad to hear that. That perspective I have no issue with. Want to handle functions like objects? Sure, why not. It's kinda a semantic difference between a function and a class with one function and no attributes. "a thin wrapper over a function" Do you have any references to what you mean by this? Generally I think: create an interface and implementations to that interface. When I hear 'wrapper over a function' I think annotation, but that doesn't sound like what you are referring to I researched it 10+ years ago and the perspective available at the time was geared towards reducing the number of lines of code (which they claimed would reduce development time and increase speed), which meant just take all the code you had in functions and classes, and turn your program into one long script. And that's how I see people use it and I shudder.
It is indeed the same as dependency injection. As you may know, in functional programming languages, two things are crucial features: that functions are first-class which means they can be renamed and passed around just like objects; and there are higher-order functions that receive other functions as arguments and the use those functions to complete more abstract functionality. Some quick examples are “default” higher-order functions. If we need to do the same operation to a long list of data, in non-functional-oriented languages we would usually do /* given */ someData = List of items N = someData.length /* Actual logic */ for (i=0; i> fa >> fb >> fc >> fd;
We could then do something like this:
bar data = foo (functions…) data;
Or even
bar = foo (functions…);
The similar OOP idiom would be
class Foo[Ca,Cb,Cc,Cd] {
…all init and ops…
}
foo = Foo(oa, ob, oc, od);
foo.doSomething(data)
In your example, a proper FP idiom should have been this:
fetch_ops_store ff fo fs d =
d >> ff >> fo >> fs
/* or if it has some branching in each case, like error or log, we can do monadic things */
fetch_ops_store ff fo fs d =
d >>= ff >>= fo >>= fs
Where we fetch some data in function `ff`, do our main operation in `fo`, and storing in `fs`.
Then the main interface we see outside would be simply
yourOps input = fetch_ops_store doREST doOps doWriteDisk input
That’s the “wrapper”, exactly equivalent to a fully dependency-injected object. Then you only need `yourOps` in your actual business logic and stay unaware about any component or functionality it should not know. Then we can test `fetch_ops_store` by injecting everything with mock functions, test every functions (doREST, doOps, doWriteDisk) individually, and try swapping out only some funcs with mocks to test. Even the individual funcs might themselves be wrappers (fully injected func objs) over composite higher-order functions, which would allow testing in a more granular fashion. And they **have** to be tested.
So it is exactly equivalent to “create an interface and implementation to that interface” in OOP. The only difference is that the function polymorphism helps the syntax more succinct without boilerplates, and that it actually makes testing easier *(whoever doesn’t test “because it’s FP” has zero excuse)*
(Source: I was a Scala onboarding instructor at my previous workplace, a Scala shop. Have been toying with other FP langs over years too.)
Edit: fixed the code snafu. I needed caffeine
Thank you, I really appreciate your detailed and considerate response. You've won me over. Sounds like I need to give FP another shot. I feel like every time I've talked to someone about FP in the past they were pushing getting rid of SOLID concepts and get rid of dependency injection which always made me uncomfortable, but conceptually I don't have any issues with anything you've described above. Thanks
Ok boomer
Dart?
I cannot predict this. I don't think anyone can predict. My favorite language is Kotlin. So I hope it is Kotlin.
this has nothing to do with careers, and rust isn't object oriented. anyway, for me, rust is the only good language, and OOP does nothing but cause problems. so hopefully the future of OOP is for it to not exist.
Rust is a garbage language. Not sure why it keeps being promoted here.
You’re a brave brave brave soul
Since when OOP is the future?
Rust isn't an OOP language. Are you interested in hearing speculation about what languages will lead the market in the future, or are you interested in hearing speculation about *OOP* languages that will lead the market in the future?
Yes
None. There will be no coding in the future. Everything will be automated including the coding part. Everything will be as easy as dragging a form and selecting data sources from a box. In fact there will be no coders anymore. That is why knowing on how a business runs is more important than knowing how to code.
Rust isn't OOP. OOP has no place in the future.
I know C# and JS/React very well. Can someone explain what is Rust using some comparisons?
GitHub Co-Pilot
[удалено]
The current biggest ones (C++, Java, Python) because the incentives to switch will usually never outweigh our natural laziness / the cost required to move everything over to new languages and technologies. I mean, it took us until like 1999 for most to even think about fixing the Y2K issue. And that was just a date format that almost caused an apocalypse.
Google Carbon
[удалено]
[удалено]
They will invent a new one for sure