How Oracle’s business as usual is threatening to kill Java

Oracle's silence about Java EE has brought developer community distrust to a fever pitch.

Read the whole story

 

[Joao Sousa]

cerberusTI[/url]":1wdg1ywr]

name99[/url]":1wdg1ywr]

cerberusTI[/url]":1wdg1ywr]

Viewer[/url]":1wdg1ywr]

cerberusTI[/url]":1wdg1ywr]

Viewer[/url]":1wdg1ywr]
Apple's new Swift language is free and open source and has a standard.

It has a specification published by apple, which is not at all the same thing.

Maybe at some point in the future, but as far as I can tell it has not even been proposed at this point. That may be because they want to wait until it is a bit more mature, or that they have no interest in doing it at all.

There is a completely independent implementation of Swift: https://ind.ie/about/vision/

Swift natively provides full Linux support. It's fully open source. Beyond that, who cares?

That is a good start, and it will no doubt see some use in platform specific code regardless as it is being pushed by an OS vendor.

The benefits of actual standardization over simple public disclosure have some similarity to publication and peer review in a scientific journal.

Others will take a look at how it works and there will be issues which get fixed, things which are unclear or missing in the specification will be clarified or added, formatting changes will be made so it uses well defined and common terms and layout (it will be edited, in short).

Licensing terms will be looked at, and a call will be made for anyone who thinks they have a patent or copyright on anything it includes to disclose this, and provide the terms under which they would license it for consideration (FRAND assurances, etc.).

The published standard will remain as is for a while, which is also of benefit as it gives a clearly defined set of functionality to target. Future versions will make changes, but those changes will be considered by multiple parties and will adhere to a public schedule (particularly important here, as Apple is not known for their long support periods).

ISO is also an international organization with a membership comprised of governments, and therefore has the ability to enforce their rules on this process to a degree a private organization cannot. This eases the legal concerns when dealing with a large amount of IP from many contributors, and a large number of different legal systems across the world.

The situation with Java is somewhat similar to Swift, Sun frequently claimed Java was open source software. Does nothing about the current situation with Oracle and Java make you nervous?

You're talking about something you know nothing about.
The direction of the Swift language IS open for all PRACTICAL purposes. There is a documented evolution process:
https://swift.org/contributing/#partici ... on-process
which involves people who want to evolve the language writing up explicit proposals which are then extensively discussed and finally voted upon.

This is not empty either --- Swift 3 is a dramatically different language from Swift 2, in large part thanks to the quality, variety, and wide scope of these proposals.
You can see the that has happened (and is on-going) here: https://github.com/apple/swift-evolution
It is very impressive, and very reminiscent of similar ISO repertoires for C++ or video codecs, with the exception of being a whole lot easier to deal with --- easier web site to deal with, easier process to navigate. This may have to change once there are more stake holders (eg five compilers that have to stay in sync rather than one compiler and one follower), but that's the way it is right now.

Basically the current Evolution process provides all the VALUE of a standardization process (ISO or something more lightweight) without the overhead and politics of the process.
IMHO there is no HONEST reason to complain about Swift not being standardized for the arguments you give (that outsiders do not have genuine voice in the language); to complain about the lack of standardization is to bitch for the sake of bitching, to complain because you hate Apple and/or Swift, not because you are genuinely trying to improve the world.

I do not think there is anything wrong with what they are doing, and even if they do choose to put this through the standards process at some point it is not ready yet.

Our needs are not the same here, for some projects I need to consider what things may look like twenty years from now. While going fully open source is admirable, and does go a long way, it is not equivalent to an ISO standard.

If you are arguing that what they are doing is the same thing without the bureaucracy, that is true. There are sometimes benefits to slowing things down, making the IP rules firmer, the specification more exact, less frequently revised, and not allowing anyone to control the process on their own.

ECMA6 took so damn long that you get fragmented implementations all over the place. And he has shown you that people do get input, don't know why you keep insisting that is one of the advantages of ISO.

 

[WaveRunner]

name99[/url]":1e489i0l]

cerberusTI[/url]":1e489i0l]

Viewer[/url]":1e489i0l]

cerberusTI[/url]":1e489i0l]

Viewer[/url]":1e489i0l]
Apple's new Swift language is free and open source and has a standard.

It has a specification published by apple, which is not at all the same thing.

Maybe at some point in the future, but as far as I can tell it has not even been proposed at this point. That may be because they want to wait until it is a bit more mature, or that they have no interest in doing it at all.

There is a completely independent implementation of Swift: https://ind.ie/about/vision/

Swift natively provides full Linux support. It's fully open source. Beyond that, who cares?

That is a good start, and it will no doubt see some use in platform specific code regardless as it is being pushed by an OS vendor.

The benefits of actual standardization over simple public disclosure have some similarity to publication and peer review in a scientific journal.

Others will take a look at how it works and there will be issues which get fixed, things which are unclear or missing in the specification will be clarified or added, formatting changes will be made so it uses well defined and common terms and layout (it will be edited, in short).

Licensing terms will be looked at, and a call will be made for anyone who thinks they have a patent or copyright on anything it includes to disclose this, and provide the terms under which they would license it for consideration (FRAND assurances, etc.).

The published standard will remain as is for a while, which is also of benefit as it gives a clearly defined set of functionality to target. Future versions will make changes, but those changes will be considered by multiple parties and will adhere to a public schedule (particularly important here, as Apple is not known for their long support periods).

ISO is also an international organization with a membership comprised of governments, and therefore has the ability to enforce their rules on this process to a degree a private organization cannot. This eases the legal concerns when dealing with a large amount of IP from many contributors, and a large number of different legal systems across the world.

The situation with Java is somewhat similar to Swift, Sun frequently claimed Java was open source software. Does nothing about the current situation with Oracle and Java make you nervous?

You're talking about something you know nothing about.
The direction of the Swift language IS open for all PRACTICAL purposes. There is a documented evolution process:
https://swift.org/contributing/#partici ... on-process
which involves people who want to evolve the language writing up explicit proposals which are then extensively discussed and finally voted upon.

This is not empty either --- Swift 3 is a dramatically different language from Swift 2, in large part thanks to the quality, variety, and wide scope of these proposals.
You can see the that has happened (and is on-going) here: https://github.com/apple/swift-evolution
It is very impressive, and very reminiscent of similar ISO repertoires for C++ or video codecs, with the exception of being a whole lot easier to deal with --- easier web site to deal with, easier process to navigate. This may have to change once there are more stake holders (eg five compilers that have to stay in sync rather than one compiler and one follower), but that's the way it is right now.

Basically the current Evolution process provides all the VALUE of a standardization process (ISO or something more lightweight) without the overhead and politics of the process.
IMHO there is no HONEST reason to complain about Swift not being standardized for the arguments you give (that outsiders do not have genuine voice in the language); to complain about the lack of standardization is to bitch for the sake of bitching, to complain because you hate Apple and/or Swift, not because you are genuinely trying to improve the world.

Of course is not the same as ISO. Calling the "evolution" process open, and then saying people get to vote is just complete rubbish. Read the evolution process, only CORE TEAM members get to vote. Every single CORE TEAM member works for Apple. So at this point it seems Swift is no more open then any other piece of software that has a UserVoice webpage.

 

[cerberusTI]

Joao Sousa[/url]":19l58x7t]
ECMA6 took so damn long that you get fragmented implementations all over the place. And he has shown you that people do get input, don't know why you keep insisting that is one of the advantages of ISO.

If you wanted an example of a crappy standardization effort, I would have chosen HTML before HTML 5 (which is related, the entire thing was bad).

I also definitely have preferences among standards organizations. ISO is top tier, and the IETF is close to it despite much less formality.

The ECMA I hold in less regard, same with the W3C.


As an aside, can someone at Ars please do something about the quote limit... Just remove some if it will go over. It is simply too much for my inebriated self to deal with, and it impedes my drunken posting to use the preview tab.

 

[larsd]

JustQuestions[/url]":1tzo86js]

larsd[/url]":1tzo86js]
I fail to see the difference: if the masses chose to adopt C++ (and Java) over all the other languages coming before, then C++ and Java are the languages which brought OO programming to the masses. I did acknowledge that OO programming had been around long before then - but what good is a methodology if it isn't being used?

The difference is that the masses choose which language to adopt.

C++ didn't get forced onto the masses, which would then make your statement sensible. Since that didn't happen, no, C++ didn't "bring OOP to the masses." The masses chose to adopt C++, not the other way around.

A better choice of phrasing would be something like:

"The first massively used OOP language was C++."

If you want to get nit-picky like that - ok.

 

[CraigJ ✅]

This is why we are transitioning to MariaDB in the short term - just waiting on them to try and start collecting license fees from everyone using MySQL.

 

[Deleted member 192806]

CraigJ[/url]":1xcx8z2z]This is why we are transitioning to MariaDB in the short term - just waiting on them to try and start collecting license fees from everyone using MySQL.

During the PostgreSQL/MySQL wars, didn't most move to PostgreSQL already?

 

[larsd]

WaveRunner[/url]":el51xaxk]

larsd[/url]":el51xaxk]

JustQuestions[/url]":el51xaxk]

larsd[/url]":el51xaxk]

WaveRunner[/url]":el51xaxk]

larsd[/url]":el51xaxk]
To be fair: C# sat back for 7 years, letting Java and C++ do the dirty work of figuring out what does and what doesn't work in the then scary new world of OO programming (yes, I know, there have been other OO languages before, but these two became mainstream enough to shred the envelope). Benefit of the hindsight, and all that.

...and now I'm wondering: C# on the JVM - that could be a nice little project...

Huh C++ was trailblazing... right....

C++ was one of the few languages which brought OO programming to the masses - being trailblazing in features as such was not a requirement for that.

You have the cause-effect backwards.

OOP has been around since the 1960s. The groupthink with programming language choice is fairly unpredictable.

The masses chose to adopt C++, which had OOP features. It didn't "bring them to the masses." OOP was already available to the masses for a very long time, it's just that the masses chose not to use those languages.

I fail to see the difference: if the masses chose to adopt C++ (and Java) over all the other languages coming before, then C++ and Java are the languages which brought OO programming to the masses. I did acknowledge that OO programming had been around long before then - but what good is a methodology if it isn't being used?

Yeah except what brought OO to C# was more than likely the lessons that came from Turbo Pascal and not influenced at all by either of the languages you claim. Maybe you should wiki Anders Hejlsberg to see the lineage. But even that is in accurate, the truth is language developers tend to be influenced by EVERY language that came beforehand, that's their field of expertise.

(Emphasis mine)

Exactly. It is easy to make statements like "C# does right what Java does wrong" (which is what triggered my original comment), based on the loads of experience we have gathered with OO programming in the last two decades; but that ignores the fact that back when Java and C++ became popular, this corpus of experience didn't exist. It would in fact be quite embarrassing if C# did not conceptually improve upon Java and the other early OO languages, having been developed almost a decade later, but it took making the mistakes of the early OO languages to shape C# as it is now.

 

[GuyClinch]

Exactly. It is easy to make statements like "C# does right what Java does wrong" (which is what triggered my original comment), based on the loads of experience we have gathered with OO programming in the last two decades; but that ignores the fact that back when Java and C++ became popular, this corpus of experience didn't exist. It would in fact be quite embarrassing if C# did not conceptually improve upon Java and the other early OO languages, having been developed almost a decade later, but it took making the mistakes of the early OO languages to shape C# as it is now.

I totally agree - the C# designer/community did learn a lot from previous languages - but that's why its so nice right now. I am told Swift is excellent as well.. I can't really comment on it since I haven't really tried it out much.. But its modern - and fairly close to C#..

C# allows you to now write for almost any platform and its pretty good for all of those platforms. My perhaps naive view right now is that C# and Swift should have simply been combined.. But maybe Microsoft wasn't ready to share its language back when Swift development started.. I dunno.

 

[WaveRunner]

larsd[/url]":1iozdafn]

WaveRunner[/url]":1iozdafn]

larsd[/url]":1iozdafn]

JustQuestions[/url]":1iozdafn]

larsd[/url]":1iozdafn]
C++ was one of the few languages which brought OO programming to the masses - being trailblazing in features as such was not a requirement for that.

You have the cause-effect backwards.

OOP has been around since the 1960s. The groupthink with programming language choice is fairly unpredictable.

The masses chose to adopt C++, which had OOP features. It didn't "bring them to the masses." OOP was already available to the masses for a very long time, it's just that the masses chose not to use those languages.

I fail to see the difference: if the masses chose to adopt C++ (and Java) over all the other languages coming before, then C++ and Java are the languages which brought OO programming to the masses. I did acknowledge that OO programming had been around long before then - but what good is a methodology if it isn't being used?

Yeah except what brought OO to C# was more than likely the lessons that came from Turbo Pascal and not influenced at all by either of the languages you claim. Maybe you should wiki Anders Hejlsberg to see the lineage. But even that is in accurate, the truth is language developers tend to be influenced by EVERY language that came beforehand, that's their field of expertise.

(Emphasis mine)

Exactly. It is easy to make statements like "C# does right what Java does wrong" (which is what triggered my original comment), based on the loads of experience we have gathered with OO programming in the last two decades; but that ignores the fact that back when Java and C++ became popular, this corpus of experience didn't exist. It would in fact be quite embarrassing if C# did not conceptually improve upon Java and the other early OO languages, having been developed almost a decade later, but it took making the mistakes of the early OO languages to shape C# as it is now.

Look at this way, lets say C# 1.0 borrows heavily from C++ class hierarchy/inheritance model. As well C# 1.0 borrows the everything is an Object, not object from Java. You have a base syntax and pretty much your message passing system that handles the OOP is not at all that much different from it predecessors.

But once you get to the C# 2.0 phase, you start to have all these features that require you to rewrite parts of that message passing system. And that trend continues up to version 3.0 and you end up with something like LINQ-to-SQL and now you no longer just have message passing within your program, but through out the operating system layers.

At what point do you concede that even though the front end syntax may look similar, the backend compiler spitting out that code has zero input from C++ or Java? Maybe I've over emphasized the message passing aspect of OOP, which is surprisingly something they never even discussed in my CS102 class, but am I wrong to focus more on what the compiler is outputting versus the syntax? In fact by the time of CS201 came around before we learned C++ we had to implement the message passing within a C program, so I guess we could appreciate "syntactic sugar".

And that's why I reject the notion especially of C++ being all that influential because it remained stagnant for almost 8 years while all this was going on, we could even say the parts borrowed from C++ were also found in Java to begin with.

 

[larsd]

WaveRunner[/url]":309taoy8]

(Quotes trimmed)
Exactly. It is easy to make statements like "C# does right what Java does wrong" (which is what triggered my original comment), based on the loads of experience we have gathered with OO programming in the last two decades; but that ignores the fact that back when Java and C++ became popular, this corpus of experience didn't exist. It would in fact be quite embarrassing if C# did not conceptually improve upon Java and the other early OO languages, having been developed almost a decade later, but it took making the mistakes of the early OO languages to shape C# as it is now.

Look at this way, lets say C# 1.0 borrows heavily from C++ class hierarchy/inheritance model. As well C# 1.0 borrows the everything is an Object, not object from Java. You have a base syntax and pretty much your message passing system that handles the OOP is not at all that much different from it predecessors.

But once you get to the C# 2.0 phase, you start to have all these features that require you to rewrite parts of that message passing system. And that trend continues up to version 3.0 and you end up with something like LINQ-to-SQL and now you no longer just have message passing within your program, but through out the operating system layers.

At what point do you concede that even though the front end syntax may look similar, the backend compiler spitting out that code has zero input from C++ or Java? Maybe I've over emphasized the message passing aspect of OOP, which is surprisingly something they never even discussed in my CS102 class, but am I wrong to focus more on what the compiler is outputting versus the syntax? In fact by the time of CS201 came around before we learned C++ we had to implement the message passing within a C program, so I guess we could appreciate "syntactic sugar".

And that's why I reject the notion especially of C++ being all that influential because it remained stagnant for almost 8 years while all this was going on, we could even say the parts borrowed from C++ were also found in Java to begin with.

Maybe I should have made it clearer: I am not looking at what the compiler spits out in the end, nor am I looking at syntax. I am trying to look at usage patterns instead.

For example, C++ tries to be all things to all people, and is suffering for it. As much as I love that language, it is to me what Assembler used to be. To give just one example: C++ allows multiple inheritance, and promptly ran into problems - hence the introduction of virtual inheritance. Other languages looked at the mess and noped out, inventing Interfaces and Mix-ins in the process. Similar with properties: if it hadn't been for Java, the concept of a Java Bean, and the notion of preferring accessor methods over publicly accessible structure/class fields, I don't think that the C# implementation of properties would have come to pass.

And let's not forget that it took living through the initial OO craze to realize that deep object inheritance trees have their own problems.

But if you want a tl;dr: C++ is influential because it demonstrates what not to do, and why.

 

[larsd]

(Duplicate Post when I intended mere edit)

 

[WaveRunner]

larsd[/url]":14syzzrb]

WaveRunner[/url]":14syzzrb]

(Quotes trimmed)
Exactly. It is easy to make statements like "C# does right what Java does wrong" (which is what triggered my original comment), based on the loads of experience we have gathered with OO programming in the last two decades; but that ignores the fact that back when Java and C++ became popular, this corpus of experience didn't exist. It would in fact be quite embarrassing if C# did not conceptually improve upon Java and the other early OO languages, having been developed almost a decade later, but it took making the mistakes of the early OO languages to shape C# as it is now.

Look at this way, lets say C# 1.0 borrows heavily from C++ class hierarchy/inheritance model. As well C# 1.0 borrows the everything is an Object, not object from Java. You have a base syntax and pretty much your message passing system that handles the OOP is not at all that much different from it predecessors.

But once you get to the C# 2.0 phase, you start to have all these features that require you to rewrite parts of that message passing system. And that trend continues up to version 3.0 and you end up with something like LINQ-to-SQL and now you no longer just have message passing within your program, but through out the operating system layers.

At what point do you concede that even though the front end syntax may look similar, the backend compiler spitting out that code has zero input from C++ or Java? Maybe I've over emphasized the message passing aspect of OOP, which is surprisingly something they never even discussed in my CS102 class, but am I wrong to focus more on what the compiler is outputting versus the syntax? In fact by the time of CS201 came around before we learned C++ we had to implement the message passing within a C program, so I guess we could appreciate "syntactic sugar".

And that's why I reject the notion especially of C++ being all that influential because it remained stagnant for almost 8 years while all this was going on, we could even say the parts borrowed from C++ were also found in Java to begin with.

Maybe I should have made it clearer: I am not looking at what the compiler spits out in the end, nor am I looking at syntax. I am trying to look at usage patterns instead.

For example, C++ tries to be all things to all people, and is suffering for it. As much as I love that language, it is to me what Assembler used to be. To give just one example: C++ allows multiple inheritance, and promptly ran into problems - hence the introduction of virtual inheritance. Other languages looked at the mess and noped out, inventing Interfaces and Mix-ins in the process. Similar with properties: if it hadn't been for Java, the concept of a Java Bean, and the notion of preferring accessor methods over publicly accessible structure/class fields, I don't think that the C# implementation of properties would have come to pass.

And let's not forget that it took living through the initial OO craze to realize that deep object inheritance trees have their own problems.

But if you want a tl;dr: C++ is influential because it demonstrates what not to do, and why.

Pretty pedestrian stuff.... you really aren't making much of a case...

 

[CraigJ ✅]

Ostracus[/url]":2hgfucq0]

CraigJ[/url]":2hgfucq0]This is why we are transitioning to MariaDB in the short term - just waiting on them to try and start collecting license fees from everyone using MySQL.

During the PostgreSQL/MySQL wars, didn't most move to PostgreSQL already?

Unfortunately we developed a lot of stuff that only works with MySQL, even though we use PDO. THe long term plan is to build a more agnostic DAL and support MtSQL/Maria, Postgre and SQL Server.

 

[pcluddite]

Viewer[/url]":2pu18cyb]
.NET has shrunk largely because it was designed for Windows only

This is completely false. C# and other .NET languages were designed to be platform agnostic, and they compile into bytecode so their executables are platform agnostic too (exactly like Java). It just hasn't been until recent years the development landscape for .NET apps on Linux and OS X (via Mono) has improved.

 

[psd]

cerberusTI[/url]":1to1859h]

psd[/url]":1to1859h]

Joao Sousa[/url]":1to1859h]

psd[/url]":1to1859h]

The Taxpayer[/url]":1to1859h]Java is a zombie for several years now.

Not funded properly, full of legal problems, lacking innovation, etc.

Forget Java. Long live .NET/Rails/Ruby/Python/Rust/Haskel/Swift and even PHP (ya, even PHP...).

The beautiful thing about computers is the million alternatives you have. If you don't like any, create your own!

Bye Java. Bye Oracle (who still invests in Oracle with those licences costs and conditions??????).

Hello XXI Century!

Those are messy and undisciplined programming languages, if they can even be called that.

C# is "messy"?

It is undisciplined because the language allows "unsafe" code and pointers

It is messy because it hangs on to pointless features like structs when the language already has a decent class-based object oriented feature set.

Which are two very practical and highly useful features, and I think they help make C# a better language...

The alternative is to go write some C code and figure out an interface mechanism when I need pointers, which is a pain to do in many cases. Sometimes I need to work with a lot of data and do not want the extra baggage of a class, but I do want to group data (some things really are just a group of related data, no reason to throw code into that unless you want a class for the sake of having a class).

Structures are particularly useful when using pointers by the way, as it allows you to reference the group as a single block, and you can still easily calculate pointer values when using structures.

None of that is persuasive. No one should have to deal with pointers in a properly designed run time a programming language is targeting.

 

[pcluddite]

psd[/url]":1cxwfa5g]

cerberusTI[/url]":1cxwfa5g]

psd[/url]":1cxwfa5g]

Joao Sousa[/url]":1cxwfa5g]

psd[/url]":1cxwfa5g]

The Taxpayer[/url]":1cxwfa5g]Java is a zombie for several years now.

Not funded properly, full of legal problems, lacking innovation, etc.

Forget Java. Long live .NET/Rails/Ruby/Python/Rust/Haskel/Swift and even PHP (ya, even PHP...).

The beautiful thing about computers is the million alternatives you have. If you don't like any, create your own!

Bye Java. Bye Oracle (who still invests in Oracle with those licences costs and conditions??????).

Hello XXI Century!

Those are messy and undisciplined programming languages, if they can even be called that.

C# is "messy"?

It is undisciplined because the language allows "unsafe" code and pointers

It is messy because it hangs on to pointless features like structs when the language already has a decent class-based object oriented feature set.

Which are two very practical and highly useful features, and I think they help make C# a better language...

The alternative is to go write some C code and figure out an interface mechanism when I need pointers, which is a pain to do in many cases. Sometimes I need to work with a lot of data and do not want the extra baggage of a class, but I do want to group data (some things really are just a group of related data, no reason to throw code into that unless you want a class for the sake of having a class).

Structures are particularly useful when using pointers by the way, as it allows you to reference the group as a single block, and you can still easily calculate pointer values when using structures.

None of that is persuasive. No one should have to deal with pointers in a properly designed run time a programming language is targeting.

No one ever said you "have to". Dealing with pointers is completely optional. It's up to the developer to decide if it's a worthwhile trade-off. If you are designing a method that is called frequently and is too slow for your needs with the runtime overhead, unsafe code might be a good choice. You sacrifice readability with performance, but sometimes (albeit rarely), that's really important.

Java never even gives you the option, and you're forced with unnecessary overhead.

As for structs not being useful, why? Honestly, if deterministic destruction of objects helps your memory footprint, why not? Suppose I need to create a new object in every iteration of a loop. With classes, you create more and more objects that don't get discarded until the garbage collector thinks it's okay to clean them up. If you have structs, you know (with some exceptions*) that it will be cleaned up after each iteration, and you aren't stuck with a million extra objects either waiting to be destroyed or being destroyed and slowing down your program because of it.

* The exception would be if you had a reference to a class object in your struct. That object would not be deterministicly destructed.

 

[psd]

Viewer[/url]":1wmuxfsc]

psd[/url]":1wmuxfsc]
It is undisciplined because the language allows "unsafe" code and pointers

It is messy because it hangs on to pointless features like structs when the language already has a decent class-based object oriented feature set.

Both of these things are coming to Java.

Better C-based FFI is coming to Java with Project Panama (http://openjdk.java.net/projects/panama/)

Value types, which are similar to structs, are well on their way to Java with Project Valhalla (http://openjdk.java.net/projects/valhalla/)

JVM Value types are better than C# structs, btw, which they better be coming no sooner than 2017. First, they are completely immutable. C# mutable structs is widely considered a mistake. Secondly, I expect JVM value types to be faster than similar features in similar languages.

It would make a mess of Java the language, that is for sure. IMHO, lambda expressions have already made a mess of the Java language. Strangely, I don't feel the same of lambda expressions in C# because I already accept that C# is a mess. Lambda expressions are a mess in general when shoehorned into class based object oriented programming.

I like a programming language that hews close to a philosophy instead one that try to salve everyone's coding belly ache.

 

[Nostromo21]

rtsanchez42[/url]":22ygizxc]Threatening to kill? Dude it is already dead. Let's all move on.

Yeah, the only mystery here is that java still exists as an open platform after 6 years. It's only open about a nanometre crack still, but nonetheless...what are the real alternatives? LibreOffice has flourished after the OO debacle, MySQL is still kicking (limping?) along. Is there anything else to fill the java vacuum if & when it disappears in a puff of smoke finally? :-/

 

[Urethramancer]

Nostromo21[/url]":34hecmil]Is there anything else to fill the java vacuum if & when it disappears in a puff of smoke finally? :-/

There are many options. The usual ones are Pyhon, Ruby (where the bulk of ex-Java people flee, it seems) and Erlang, I think. Go is getting there, with some high-profile use (CloudFlare and Google themselves of course). We'll see how C# and .NET goes, as the bad blood between Linux users and MS has made many unwilling to even look at it. Nice language if you can be arsed though.

All of the above can do the same things Java is often used for, particularly application servers, maybe with built-in CMS-like features, connecting to some popular database. If you're looking for number-crunching and statistics stuff there are other dedicated languages for that, like R. Even Fortran is still in use, because it has highly optimised code for the popular uses.

 

[Viewer]

With this debate about OOP and what language is credited... I think OOP is largely a bad idea. Specifically, the idea of "classes", where you mix your data types, your data structures, and your code. Obviously Java and C# fully are based on the C++ notion of classes and to a lesser extent the Python way uses lots of classes.

I would credit C++ for OOP and "classes", but I think it was a bad idea. Haskell has a much nicer model: you have data types, functions, modules, and type classes which are not like C++ classes but like Java/C# interfaces for data types.

 

[Viewer]

psd[/url]":2ghwi2vr]

Viewer[/url]":2ghwi2vr]

psd[/url]":2ghwi2vr]
It is undisciplined because the language allows "unsafe" code and pointers

It is messy because it hangs on to pointless features like structs when the language already has a decent class-based object oriented feature set.

Both of these things are coming to Java.

Better C-based FFI is coming to Java with Project Panama (http://openjdk.java.net/projects/panama/)

Value types, which are similar to structs, are well on their way to Java with Project Valhalla (http://openjdk.java.net/projects/valhalla/)

JVM Value types are better than C# structs, btw, which they better be coming no sooner than 2017. First, they are completely immutable. C# mutable structs is widely considered a mistake. Secondly, I expect JVM value types to be faster than similar features in similar languages.

It would make a mess of Java the language, that is for sure. IMHO, lambda expressions have already made a mess of the Java language. Strangely, I don't feel the same of lambda expressions in C# because I already accept that C# is a mess. Lambda expressions are a mess in general when shoehorned into class based object oriented programming.

I like a programming language that hews close to a philosophy instead one that try to salve everyone's coding belly ache.

Value types would make a mess of Java? Lambdas made a mess of Java? I haven't heard those arguments before.

All major programming languages have full lambdas and (unfortunately) OOP classes and such.

So, Java always had crappy lambdas in the form on anonymous inner classes. All the major IDEs would auto-pretty them so they looked like lambdas. Java 8 just cleaned up the core syntax, cleaned up byte code implementation, and added full standard library support...

 

[Viewer]

Nostromo21[/url]":3pgw0ugt]Is there anything else to fill the java vacuum if & when it disappears in a puff of smoke finally? :-/

The Java crowd is mostly happy with Java. Consider Spark. There are probably more Spark programmers using Python, but I don't think most of them are deeply bothered by the JVM nature of the ecosystem.

This crowd, especially the Ars editors, are hating on Java, most of the people using it, actually like it.

Urethramancer[/url]":3pgw0ugt]There are many options. The usual ones are Pyhon, Ruby (where the bulk of ex-Java people flee, it seems) and Erlang, I think. Go is getting there, with some high-profile use (CloudFlare and Google themselves of course).

Ruby was initially all disgruntled ex-Java types, but it seems to have died off.

Python has really exploded. You mention R for number crunching. Much of the R community has just moved to Python. The Python library Pandas is basically a direct port of major R features. R's famous graphics library ggplot2 has been ported to Python. R, has awesome statistics libraries and community, but the core language itself isn't necessarily worth keeping.

Python is the dominant language in much of academia and data science.

I'm skeptical about major Erlang or Go growth.

Urethramancer[/url]":3pgw0ugt]
We'll see how C# and .NET goes, as the bad blood between Linux users and MS has made many unwilling to even look at it. Nice language if you can be arsed though.

It's not just bad blood, C# really doesn't have any killer features to win over Java developers. I've seen teams switch from Java to Python because Python is so much simpler for making REST servers that talk to a database. I've seen teams switch to Scala/Clojure/Haskell because they are fancier functional languages. C# doesn't have killer features like that.

C#'s one killer use case is the Unity game engine. C# or .NET aren't particularly magical as technologies, but the Unity engine is, and they chose C# for game devs to author in. They could have used Java, it would have worked, but they didn't.

Urethramancer[/url]":3pgw0ugt]
All of the above can do the same things Java is often used for, particularly application servers, maybe with built-in CMS-like features, connecting to some popular database.

_everything_ can do basic web/rest server that talks to a database.

Java has some killer app areas, like Spark and similar big data, event processing technologies. Storm, Kafka, Cassandra, DynamoDB, Hadoop, tons of very hot technologies are JVM centric.

Urethramancer[/url]":3pgw0ugt]
Even Fortran is still in use, because it has highly optimised code for the popular uses.

This is true, but Fortran is a niche use thing and no one expects it to explode as a general purpose language.

 

[Viewer]

Nostromo21[/url]":1ubne7bw]LibreOffice has flourished after the OO debacle, MySQL is still kicking (limping?) along.

Has it? LibreOffice has always been the lower-quality imitation of Microsoft Office. It's free an it's mutli-platform.

Much of the world has been moving away from Microsoft Office and imitations.

 

[Peevester]

psd[/url]":2dp56ny0]

cerberusTI[/url]":2dp56ny0]

psd[/url]":2dp56ny0]

Joao Sousa[/url]":2dp56ny0]

psd[/url]":2dp56ny0]

The Taxpayer[/url]":2dp56ny0]Java is a zombie for several years now.

Not funded properly, full of legal problems, lacking innovation, etc.

Forget Java. Long live .NET/Rails/Ruby/Python/Rust/Haskel/Swift and even PHP (ya, even PHP...).

The beautiful thing about computers is the million alternatives you have. If you don't like any, create your own!

Bye Java. Bye Oracle (who still invests in Oracle with those licences costs and conditions??????).

Hello XXI Century!

Those are messy and undisciplined programming languages, if they can even be called that.

C# is "messy"?

It is undisciplined because the language allows "unsafe" code and pointers

It is messy because it hangs on to pointless features like structs when the language already has a decent class-based object oriented feature set.

Which are two very practical and highly useful features, and I think they help make C# a better language...

The alternative is to go write some C code and figure out an interface mechanism when I need pointers, which is a pain to do in many cases. Sometimes I need to work with a lot of data and do not want the extra baggage of a class, but I do want to group data (some things really are just a group of related data, no reason to throw code into that unless you want a class for the sake of having a class).

Structures are particularly useful when using pointers by the way, as it allows you to reference the group as a single block, and you can still easily calculate pointer values when using structures.

None of that is persuasive. No one should have to deal with pointers in a properly designed run time a programming language is targeting.

For crap's sake. Pointers and Structs exist in C# almost entirely so that the language can talk to the Windows API. The only time I've ever had to use them (and the only time I've wanted to use them) is when doing a Pinvoke to some windows or hardware function that had no managed equivalent.

If you've ever done windows Mobile/Pocket PC work, you find yourself doing Pinvokes a lot to set up the hardware or change a setting.

 

[Benjymouse]

Viewer[/url]":1ar1te0a]
I can only guess into what specifically you think is missing. I know about C# await/async and C++ async/future which hides explicit threads. Java ExecutorService has been around for a while and does basically the same thing.

Java ExecutorService is nothing like async/await.

Java ExecutorService is a queue/threadpool abstraction.

Async/await is about building inherent non-blocking future-oriented code. That is almost impossible using Java and Javas Future - especially as Javas futures do not even support callbacks and continuations.

Async/await allows the developer to compose futures (the continuation-aware variety) using regular control flow statements such as if, while, do, throw, try-catch-finally, using etc.

 

[fwaris]

Under Nadella, MS commitment to open source is very a refreshing development. Witness .Net Core https://dotnet.github.io/

 

[Voo42]

pcluddite[/url]":8cwalnty]
As for structs not being useful, why? Honestly, if deterministic destruction of objects helps your memory footprint, why not? Suppose I need to create a new object in every iteration of a loop. With classes, you create more and more objects that don't get discarded until the garbage collector thinks it's okay to clean them up. If you have structs, you know (with some exceptions*) that it will be cleaned up after each iteration, and you aren't stuck with a million extra objects either waiting to be destroyed or being destroyed and slowing down your program because of it.

Structs are indeed very useful (in very rare situations), but for completely different reasons. No, having millions of short-lived dead objects around doesn't slow down the program at all. That's a common misconception, but any modern GC algorithm depends on the number of life objects (or the total heap size). Furthermore escape analysis does a pretty good job of allowing us to avoid heap allocations to begin with.

The real advantage of structs is that they allow us to much easier arrange memory in an optimal manner. While you can do similar things in Java, it's exceedingly awkward to do so.

At the same time structs introduce lots of problems: Particularly it makes atomic variables much harder and people who don't know what they're doing can easily get really bad performance that's not at all obvious on first glance (what happens in C# if you call a function on a struct?)

 

[WaveRunner]

Viewer[/url]":3sme2q9l]With this debate about OOP and what language is credited... I think OOP is largely a bad idea. Specifically, the idea of "classes", where you mix your data types, your data structures, and your code. Obviously Java and C# fully are based on the C++ notion of classes and to a lesser extent the Python way uses lots of classes.

I would credit C++ for OOP and "classes", but I think it was a bad idea. Haskell has a much nicer model: you have data types, functions, modules, and type classes which are not like C++ classes but like Java/C# interfaces for data types.

Why does that statement make me think that you are in fact Joe the Plumber's cousin, Joe the Programmer.

 

[WaveRunner]

Viewer[/url]":nk7tlh8j]
It's not just bad blood, C# really doesn't have any killer features to win over Java developers. I've seen teams switch from Java to Python because Python is so much simpler for making REST servers that talk to a database. I've seen teams switch to Scala/Clojure/Haskell because they are fancier functional languages. C# doesn't have killer features like that.

No it doesn't have any of those killer features, nope WebAPI and EF are not a thing!

Dude C# has been the leading language as far a features go for the past decade. There is no other language or ecosystem that provides more.

And yet you are somehow responsible for project decision.... dude I don't even know you are a programmer with your last statement on OOP, let alone an architect you spew so much shit.

 

[remoran111]

Open Source in all things relating to software is inevitable, somethin Oracle seems to ignore at their peril. They lost to HP and they lost to Google and they will lose, in the end, to open source. Java, under the auspices of Sun and Gosling, was awesome, under Oracle, not so much. Greed and the need to try to control is not how the net works, something Oracle will eventually find out as tech, like life, evolves on it's own, not by entities that strive to control like Oracle.

Nuff said.

 

[cerberusTI]

WaveRunner[/url]":qb4tedoj]

Viewer[/url]":qb4tedoj]
It's not just bad blood, C# really doesn't have any killer features to win over Java developers. I've seen teams switch from Java to Python because Python is so much simpler for making REST servers that talk to a database. I've seen teams switch to Scala/Clojure/Haskell because they are fancier functional languages. C# doesn't have killer features like that.

No it doesn't have any of those killer features, nope WebAPI and EF are not a thing!

Dude C# has been the leading language as far a features go for the past decade. There is no other language or ecosystem that provides more.

And yet you are somehow responsible for project decision.... dude I don't even know you are a programmer with your last statement on OOP, let alone an architect you spew so much shit.

For every project I have seen which fits naturally into a set of objects, I see someone awkwardly write a bunch of unnecessary code because they must have a class anywhere they can, and make a mess of what should have been a very simple program.

The benefit of OOP overall is unclear, and may depend upon what kind of code you are writing for the most part. There are successful languages based on that style of programming, and successful languages which are not.

Most people mean class based object oriented when they say OOP though, and if you mean that I would agree with him that this has been of questionable benefit. If I have a large program or something I am otherwise going to spend a lot of time on anyway, I really want a clean separation between code and data. OOP practices encourage mixing this in a way I would not, and ends up being more work for dubious benefit.

The classless OOP languages such as JavaScript are fine for high level scripting, as it deals with my major complaint (which is that I am lazy and prefer not to write code unless it directly contributes to getting the answer I want.)

The answer I go with is that when you make a programmer use a style they do not want to use, you will frequently get code you do not want to have. I therefore allow this choice by project, and try not to impose my preferences on everyone unless I have a good reason to do so.

 

[WaveRunner]

cerberusTI[/url]":gl28zy6k]

WaveRunner[/url]":gl28zy6k]

Viewer[/url]":gl28zy6k]
It's not just bad blood, C# really doesn't have any killer features to win over Java developers. I've seen teams switch from Java to Python because Python is so much simpler for making REST servers that talk to a database. I've seen teams switch to Scala/Clojure/Haskell because they are fancier functional languages. C# doesn't have killer features like that.

No it doesn't have any of those killer features, nope WebAPI and EF are not a thing!

Dude C# has been the leading language as far a features go for the past decade. There is no other language or ecosystem that provides more.

And yet you are somehow responsible for project decision.... dude I don't even know you are a programmer with your last statement on OOP, let alone an architect you spew so much shit.

For every project I have seen which fits naturally into a set of objects, I see someone awkwardly write a bunch of unnecessary code because they must have a class anywhere they can, and make a mess of what should have been a very simple program.

The benefit of OOP overall is unclear, and may depend upon what kind of code you are writing for the most part. There are successful languages based on that style of programming, and successful languages which are not.

Most people mean class based object oriented when they say OOP though, and if you mean that I would agree with him that this has been of questionable benefit. If I have a large program or something I am otherwise going to spend a lot of time on anyway, I really want a clean separation between code and data. OOP practices encourage mixing this in a way I would not, and ends up being more work for dubious benefit.

The classless OOP languages such as JavaScript are fine for high level scripting, as it deals with my major complaint (which is that I am lazy and prefer not to write code unless it directly contributes to getting the answer I want.)

The answer I go with is that when you make a programmer use a style they do not want to use, you will frequently get code you do not want to have. I therefore allow this choice by project, and try not to impose my preferences on everyone unless I have a good reason to do so.

Yeah... ok... sure. Let's not encapsulate logic and data within it's own unit. I know every time I call the method, I should just pass in the object reference that holds the data into every function call, and hopefully I get it's size correct! Better yet let me forget about this huge heap of data I just allocated in one section, because I somehow needed it elsewhere, oh but silly me I never ever cleaned it up.

If you want shitty C code with security bugs and memory leaks, go ahead ignoring OOP is a great starting point. In fact why not just ignore every pattern that's proven useful while you are at it. Just useless complications!

 

[Viewer]

Benjymouse[/url]":13quepm7]

Viewer[/url]":13quepm7]
I can only guess into what specifically you think is missing. I know about C# await/async and C++ async/future which hides explicit threads. Java ExecutorService has been around for a while and does basically the same thing.

Java ExecutorService is nothing like async/await.

Java ExecutorService is a queue/threadpool abstraction.

Async/await is about building inherent non-blocking future-oriented code. That is almost impossible using Java and Javas Future - especially as Javas futures do not even support callbacks and continuations.

Async/await allows the developer to compose futures (the continuation-aware variety) using regular control flow statements such as if, while, do, throw, try-catch-finally, using etc.

WaveRunner said, "elimination of explicit threading", which suggests implicit hidden multi-threading. I was trying to guess which feature he was referencing.

On second look at async/await, I was wrong (I haven't used them): Those are async, they don't cover up multi-threading. Scala has the same thing: https://github.com/scala/async

 

[Voo42]

WaveRunner[/url]":1ntmsfpx]

cerberusTI[/url]":1ntmsfpx]

WaveRunner[/url]":1ntmsfpx]

Viewer[/url]":1ntmsfpx]
It's not just bad blood, C# really doesn't have any killer features to win over Java developers. I've seen teams switch from Java to Python because Python is so much simpler for making REST servers that talk to a database. I've seen teams switch to Scala/Clojure/Haskell because they are fancier functional languages. C# doesn't have killer features like that.

No it doesn't have any of those killer features, nope WebAPI and EF are not a thing!

Dude C# has been the leading language as far a features go for the past decade. There is no other language or ecosystem that provides more.

And yet you are somehow responsible for project decision.... dude I don't even know you are a programmer with your last statement on OOP, let alone an architect you spew so much shit.

For every project I have seen which fits naturally into a set of objects, I see someone awkwardly write a bunch of unnecessary code because they must have a class anywhere they can, and make a mess of what should have been a very simple program.

The benefit of OOP overall is unclear, and may depend upon what kind of code you are writing for the most part. There are successful languages based on that style of programming, and successful languages which are not.

Most people mean class based object oriented when they say OOP though, and if you mean that I would agree with him that this has been of questionable benefit. If I have a large program or something I am otherwise going to spend a lot of time on anyway, I really want a clean separation between code and data. OOP practices encourage mixing this in a way I would not, and ends up being more work for dubious benefit.

The classless OOP languages such as JavaScript are fine for high level scripting, as it deals with my major complaint (which is that I am lazy and prefer not to write code unless it directly contributes to getting the answer I want.)

The answer I go with is that when you make a programmer use a style they do not want to use, you will frequently get code you do not want to have. I therefore allow this choice by project, and try not to impose my preferences on everyone unless I have a good reason to do so.

Yeah... ok... sure. Let's not encapsulate logic and data within it's own unit. I know every time I call the method, I should just pass in the object reference that holds the data into every function call, and hopefully I get it's size correct! Better yet let me forget about this huge heap of data I just allocated in one section, because I somehow needed it elsewhere, oh but silly me I never ever cleaned it up.

If you want shitty C code with security bugs and memory leaks, go ahead ignoring OOP is a great starting point. In fact why not just ignore every pattern that's proven useful while you are at it. Just useless complications!

You might want to look up functional programming, since you seem to assume that the only option apart from OOP is "shitty C code with security bugs and memory leaks".

There are in fact many situations where OOP isn't the optimal pattern, which is why most current object oriented languages are introducing more and more functional features. Hell this is particularly obvious in C#'s and Java's case.

 

[cerberusTI]

WaveRunner[/url]":1f8fuulm]

cerberusTI[/url]":1f8fuulm]

WaveRunner[/url]":1f8fuulm]

Viewer[/url]":1f8fuulm]
It's not just bad blood, C# really doesn't have any killer features to win over Java developers. I've seen teams switch from Java to Python because Python is so much simpler for making REST servers that talk to a database. I've seen teams switch to Scala/Clojure/Haskell because they are fancier functional languages. C# doesn't have killer features like that.

No it doesn't have any of those killer features, nope WebAPI and EF are not a thing!

Dude C# has been the leading language as far a features go for the past decade. There is no other language or ecosystem that provides more.

And yet you are somehow responsible for project decision.... dude I don't even know you are a programmer with your last statement on OOP, let alone an architect you spew so much shit.

For every project I have seen which fits naturally into a set of objects, I see someone awkwardly write a bunch of unnecessary code because they must have a class anywhere they can, and make a mess of what should have been a very simple program.

The benefit of OOP overall is unclear, and may depend upon what kind of code you are writing for the most part. There are successful languages based on that style of programming, and successful languages which are not.

Most people mean class based object oriented when they say OOP though, and if you mean that I would agree with him that this has been of questionable benefit. If I have a large program or something I am otherwise going to spend a lot of time on anyway, I really want a clean separation between code and data. OOP practices encourage mixing this in a way I would not, and ends up being more work for dubious benefit.

The classless OOP languages such as JavaScript are fine for high level scripting, as it deals with my major complaint (which is that I am lazy and prefer not to write code unless it directly contributes to getting the answer I want.)

The answer I go with is that when you make a programmer use a style they do not want to use, you will frequently get code you do not want to have. I therefore allow this choice by project, and try not to impose my preferences on everyone unless I have a good reason to do so.

Yeah... ok... sure. Let's not encapsulate logic and data within it's own unit. I know every time I call the method, I should just pass in the object reference that holds the data into every function call, and hopefully I get it's size correct! Better yet let me forget about this huge heap of data I just allocated in one section, because I somehow needed it elsewhere, oh but silly me I never ever cleaned it up.

If you want shitty C code with security bugs and memory leaks, go ahead.

Structures take care of the encapsulation, and the size in many cases. Somehow the world still manages to go on when programmers are allowed access to memory, some of us even see this as desirable.

A lack of OOP is not total anarchy in the code (hopefully), it is using an alternate design of some sort (some have names, some are custom to a project).

I have never understood why some people think there is a huge difference between
some_object.some_function()
and
some_function(some_structure)

You can even assign the function pointer to a variable in the struct and do
some_structure.some_function()

I get that there are many people who while being competent and useful programmers, are best kept away from anything to do with managing the address space. It is not a difficulty for everyone though, and there are benefits to doing this yourself.

Really I could accuse many programs in high level languages with garbage collection of leaking memory. I am sure most people who have been around for a while have seen that server that needs a restart every day or two, despite all of the code being in languages which are supposed to clean up after themselves.

When you get right down to it, automatic memory management is not all that great. It is also extremely easy to beat it if performance is a metric at all. This is a big reason why almost all of the code anyone reading this comment is running was written in C or C++.

 

[WaveRunner]

Voo42[/url]":1f2gznfk]

WaveRunner[/url]":1f2gznfk]

cerberusTI[/url]":1f2gznfk]

WaveRunner[/url]":1f2gznfk]

Viewer[/url]":1f2gznfk]
It's not just bad blood, C# really doesn't have any killer features to win over Java developers. I've seen teams switch from Java to Python because Python is so much simpler for making REST servers that talk to a database. I've seen teams switch to Scala/Clojure/Haskell because they are fancier functional languages. C# doesn't have killer features like that.

No it doesn't have any of those killer features, nope WebAPI and EF are not a thing!

Dude C# has been the leading language as far a features go for the past decade. There is no other language or ecosystem that provides more.

And yet you are somehow responsible for project decision.... dude I don't even know you are a programmer with your last statement on OOP, let alone an architect you spew so much shit.

For every project I have seen which fits naturally into a set of objects, I see someone awkwardly write a bunch of unnecessary code because they must have a class anywhere they can, and make a mess of what should have been a very simple program.

The benefit of OOP overall is unclear, and may depend upon what kind of code you are writing for the most part. There are successful languages based on that style of programming, and successful languages which are not.

Most people mean class based object oriented when they say OOP though, and if you mean that I would agree with him that this has been of questionable benefit. If I have a large program or something I am otherwise going to spend a lot of time on anyway, I really want a clean separation between code and data. OOP practices encourage mixing this in a way I would not, and ends up being more work for dubious benefit.

The classless OOP languages such as JavaScript are fine for high level scripting, as it deals with my major complaint (which is that I am lazy and prefer not to write code unless it directly contributes to getting the answer I want.)

The answer I go with is that when you make a programmer use a style they do not want to use, you will frequently get code you do not want to have. I therefore allow this choice by project, and try not to impose my preferences on everyone unless I have a good reason to do so.

Yeah... ok... sure. Let's not encapsulate logic and data within it's own unit. I know every time I call the method, I should just pass in the object reference that holds the data into every function call, and hopefully I get it's size correct! Better yet let me forget about this huge heap of data I just allocated in one section, because I somehow needed it elsewhere, oh but silly me I never ever cleaned it up.

If you want shitty C code with security bugs and memory leaks, go ahead ignoring OOP is a great starting point. In fact why not just ignore every pattern that's proven useful while you are at it. Just useless complications!

You might want to look up functional programming, since you seem to assume that the only option apart from OOP is "shitty C code with security bugs and memory leaks".

There are in fact many situations where OOP isn't the optimal pattern, which is why most current object oriented languages are introducing more and more functional features. Hell this is particularly obvious in C#'s and Java's case.

Last time I checked the functional languages also used encapsulation. Can you show me where that is not the case.

 

[Viewer]

WaveRunner[/url]":u97i4l32]

Viewer[/url]":u97i4l32]
It's not just bad blood, C# really doesn't have any killer features to win over Java developers. I've seen teams switch from Java to Python because Python is so much simpler for making REST servers that talk to a database. I've seen teams switch to Scala/Clojure/Haskell because they are fancier functional languages. C# doesn't have killer features like that.

No it doesn't have any of those killer features, nope WebAPI and EF are not a thing!

Dude C# has been the leading language as far a features go for the past decade. There is no other language or ecosystem that provides more.

And yet you are somehow responsible for project decision.... dude I don't even know you are a programmer with your last statement on OOP, let alone an architect you spew so much shit.

The "leading language as far a features go"? First, it's not a race for quantity of features.

Even in the .NET space, F# is Microsoft's more advanced language and C# is their more accessible, every man language.

Lastly, I know and talk to lots of programmers. I don't hear anyone talking about WebAPI. It looks like yet another HTTP REST framework... There are hundreds of those. There are new REST frameworks coming out every day.

I presume EF is Entity Framework, which is the .NET ORM? Jeez, there are dozens of ORMs in every language.

You need more than a REST framework and an ORM to be a killer language. Seriously, every language has those things.

And my criticism of OOP is completely widespread.

 

[cerberusTI]

WaveRunner[/url]":2glj0do3]

Voo42[/url]":2glj0do3]

WaveRunner[/url]":2glj0do3]

cerberusTI[/url]":2glj0do3]

WaveRunner[/url]":2glj0do3]

Viewer[/url]":2glj0do3]
It's not just bad blood, C# really doesn't have any killer features to win over Java developers. I've seen teams switch from Java to Python because Python is so much simpler for making REST servers that talk to a database. I've seen teams switch to Scala/Clojure/Haskell because they are fancier functional languages. C# doesn't have killer features like that.

No it doesn't have any of those killer features, nope WebAPI and EF are not a thing!

Dude C# has been the leading language as far a features go for the past decade. There is no other language or ecosystem that provides more.

And yet you are somehow responsible for project decision.... dude I don't even know you are a programmer with your last statement on OOP, let alone an architect you spew so much shit.

For every project I have seen which fits naturally into a set of objects, I see someone awkwardly write a bunch of unnecessary code because they must have a class anywhere they can, and make a mess of what should have been a very simple program.

The benefit of OOP overall is unclear, and may depend upon what kind of code you are writing for the most part. There are successful languages based on that style of programming, and successful languages which are not.

Most people mean class based object oriented when they say OOP though, and if you mean that I would agree with him that this has been of questionable benefit. If I have a large program or something I am otherwise going to spend a lot of time on anyway, I really want a clean separation between code and data. OOP practices encourage mixing this in a way I would not, and ends up being more work for dubious benefit.

The classless OOP languages such as JavaScript are fine for high level scripting, as it deals with my major complaint (which is that I am lazy and prefer not to write code unless it directly contributes to getting the answer I want.)

The answer I go with is that when you make a programmer use a style they do not want to use, you will frequently get code you do not want to have. I therefore allow this choice by project, and try not to impose my preferences on everyone unless I have a good reason to do so.

Yeah... ok... sure. Let's not encapsulate logic and data within it's own unit. I know every time I call the method, I should just pass in the object reference that holds the data into every function call, and hopefully I get it's size correct! Better yet let me forget about this huge heap of data I just allocated in one section, because I somehow needed it elsewhere, oh but silly me I never ever cleaned it up.

If you want shitty C code with security bugs and memory leaks, go ahead ignoring OOP is a great starting point. In fact why not just ignore every pattern that's proven useful while you are at it. Just useless complications!

You might want to look up functional programming, since you seem to assume that the only option apart from OOP is "shitty C code with security bugs and memory leaks".

There are in fact many situations where OOP isn't the optimal pattern, which is why most current object oriented languages are introducing more and more functional features. Hell this is particularly obvious in C#'s and Java's case.

Last time I checked the functional languages also used encapsulation. Can you show me where that is not the case.

That depends upon if you consider encapsulation to be grouping, or information hiding.

Information hiding is mostly an OOP thing.

 

[Viewer]

cerberusTI[/url]":1cx1uhzh]
Structures take care of the encapsulation, and the size in many cases.

You don't need OOP or OOP classes for encapsulation. Look at Haskell. Every .hs source file is a module, you can have private functions, and you can have data types with their internal structures private and inaccessible to other modules. That is full encapsulation.

cerberusTI[/url]":1cx1uhzh]
A lack of OOP is not total anarchy in the code (hopefully), it is using an alternate design of some sort (some have names, some are custom to a project).

The Haskell model is _far_ more elegant. That's the whole point. I bet you haven't used it. I've never met anyone with basic knowledge of Haskell who didn't think it was more elegant than the mainstream OOP model.

cerberusTI[/url]":1cx1uhzh]
I have never understood why some people think there is a huge difference between
some_object.some_function()
and
some_function(some_structure)

In Haskell it's always the latter. IMO, that's the way it should always be. Just types and functions.

The reason for the former is mainly to facilitate OOP encapsulation with access to private values. As I said, there are other ways to provide this.

A secondary reason is to assist auto-complete IDE tools, but the tool makers can adapt and deliver auto-complete functionality to the second style.

Also, note that C# extension methods basically just make func(o, arg) look like o.func(arg), which is pretty petty, IMO.

 

[Viewer]

cerberusTI[/url]":3w0dv9ab]
Information hiding is mostly an OOP thing.

No. Modeul private functions and module private data type implementations are common information hiding encapsulation strategies in FP.