Javascript is to Java as JScript is to J?



  • @blakeyrat said:

    nobody's ever told me a climb a tree. Or that I'm a fish.
    Go climb a tree. You're a fish.



  • @veggen said:

    @blakeyrat said:
    Cross-platform GUI programs is WHAT IT WAS BUILT TO DO!

    What? Where did you get that? You could say Swing was built for that, but Java... not so much.
    Well it was definitely built for cross-platform, and the problem with folders isn't specific to GUI stuff, so...



  • @blakeyrat said:

    IE/Visual Studio flags "set" as a reserved keyword, I'm not entirely sure why. I need to look into that. EDIT: Dojo ShrinkSafe also treats "set" as a reserved keyword. Nothing else I can find does... even including MSDN. Hm.

    SQL also. :)

    (Yes, I know you were talking about Java/JS.)



  • @Someone You Know said:

    @erikal said:

    True, the named folders are a platform specific thing and Java doesn't do platform specific things - at least not well. That has always been a misunderstanding among many beginning Java developers and one of the reasons Java client application development has always been a bit of a misery. Don't expect that platform specific shit to work or even be possible if you use Java.
     

    The language is supposed to be platform-independent. The Windows JVM is supposed to be platform-specific, and it should do Windows-specific things correctly. You seem to be suggesting that people should just be willing to accept that it doesn't. That attitude is why it's still broken.

     

    The only platform specific thing about it is that it is built to run on Windows. It is still supposed to deliver the exact same services as the builds for other platforms - garbage collection, bytecode interpretation / hotspot compilation, security, platform independence, etc. etc. Java is and always will be platform independent and will only ever support things that can be made abstract across platforms. I'm really sorry that this rule was apparently broken.

    I'm butting out now, this is turning into a pissing contest and I'm in no mood now nor will I ever be to preach about stuff people are not likely to understand after years of (mostly correct!) prejudice.

     



  • @morbiuswilters said:

    Those are useful ideas in Java/whatever, but I've mostly come to think of them as limitations imposed by the language rather than features of OO.

    I see them as both, in some regards.

    For example, keeping instance variables private and providing getter/setter methods (with appropriate sanitisation techniques at a centralised entry point) is a damage-limitation move, avoiding "action at a distance" when variable scope is unnecessarily exposed to external influence. Most Java code I've seen is quite anal with this encapsulation, living and breathing "black box" approach to the point of paranoia - whilst it could be considered an overkill, I see plenty of defensive programming techniques strong within Java (or OO in general?) and being constrained this way surely produces better quality code?

    Sometimes quality is shaped not by that which we can acheive but by that which we are restricted: a lot of systems deemed of "higher quality" are those where greater control is exhibited, reducing variance and risk.

    (or have I interpreted "limitations" wrongly as "constraints" ...?)

    @blakeyrat said:

    Cross-platform GUI programs is WHAT IT WAS BUILT TO DO!

    Was it? Citation, if you please, because I don't remember this point in its design ethos.

     



  • @Cassidy said:

    @blakeyrat said:

    Cross-platform GUI programs is WHAT IT WAS BUILT TO DO!

    Was it? Citation, if you please, because I don't remember this point in its design ethos.

    It doesn't matter.  If blakeyrat is right, then Java is bad at what it was designed for.  If blakeyrat is wrong, then Java is targeted at server environments where being cross-platform is almost irrelevant.  Who cares if I have I save a few hundred bucks on a server OS license, as long as the clients can be any OS.  The only believable reason for anyone to invent a write-once run-anywhere language is for client applications.



  • @erikal said:

    I'm really sorry that this rule was apparently broken.

    It seems some people here are trying to dismiss the folder location thing as windows-specific. It's not. Saving files is a common feature of all platforms, and depending on the type of file there are several default locations where it should go. On *nix platforms, the user's data files traditionally go in $HOME, and configuration files in $HOME/.application (or $HOME/.config/application by newer standards). On Windows there's $HOME/Documents and $HOME/Application Data or some such. Windows also provides API calls to find out the names of these folders, since they may change depending on the version of Windows, what language it is, and how the system administrator has set it up. So Java really should have some kind of getLocationForUserDocuments and getLocationForApplicationConfig methods to abstract this and provide the correct locations on any platform. On some platforms, certain folders (such as local and roaming config files) might map to the same path, but that doesn't mean the same is true everywhere.


  • ♿ (Parody)

    @Jaime said:

    If blakeyrat is wrong, then Java is targeted at server environments where being cross-platform is almost irrelevant.  Who cares if I have I save a few hundred bucks on a server OS license, as long as the clients can be any OS.  The only believable reason for anyone to invent a write-once run-anywhere language is for client applications.

    It's not necessarily about "saving a few hundred bucks on a server OS," and to say so is really pretty short sighted. It also allows development to be done on a different OS than on which you deploy. This may not matter to you, but that's not the same as "no reason." If you're selling your java app, it allows you to support your customer's platform of choice, which might save you thousands of dollars in sales.



  • @Jaime said:

    If blakeyrat is wrong, then Java is targeted at server environments where being cross-platform is almost irrelevant.

    Erm.. false.

    If Blakey is wrong, then Java is targetted at environments where it's write/compile once, run anywhere - for instance: a developer with a windows laptop creating JAR files that will get dropped to a staging server running Unix, Linux or Windows.

    (I hope you're not reading "non-GUI" as "server")

    @Jaime said:

    The only believable reason for anyone to invent a write-once run-anywhere language is for client applications.

    I think Larry Wall et al may disagree with that misconception.



  • @Cassidy said:

    a developer with a windows laptop creating JAR files that will get dropped to a staging server running Unix, Linux or Windows.

    Being that developer at this very moment.



  • @Cassidy said:

    @Jaime said:

    If blakeyrat is wrong, then Java is targeted at server environments where being cross-platform is almost irrelevant.

    Erm.. false.

    If Blakey is wrong, then Java is targetted at environments where it's write/compile once, run anywhere - for instance: a developer with a windows laptop creating JAR files that will get dropped to a staging server running Unix, Linux or Windows.

    Really?  You don't know what OS the server will run before the project starts?  I understand that as a Java developer you don't care that much, but I'm sure that somebody made that decision long before it came time to test the code.  That type of flexibility just isn't that valuable at the server level.



  • @veggen said:

    @Cassidy said:
    a developer with a windows laptop creating JAR files that will get dropped to a staging server running Unix, Linux or Windows.
    Being that developer at this very moment.
    You mean the developer that tested his code on the wrong platform, or the developer whom they keep in the dark and don't tell what the production runtime environment looks like? Sounds like unneccesary risk to me.



  • @Jaime said:

    Really?  You don't know what OS the server will run before the project starts?

    AIUI, The server OS is immaterial - for Java development, what version & edition of JVM is what counts.



  • @Cassidy said:

    @Jaime said:

    Really?  You don't know what OS the server will run before the project starts?

    AIUI, The server OS is immaterial - for Java development, what version & edition of JVM is what counts.

    Of course.  But was achieving that goal worth the price paid?  People who develop on single-platform frameworks get along just fine.  There really isn't a ton of value in developing on Windows for deployment on Linux -- just run Linux on your laptop (or in a VM).  Besides, you still need to test configuration and deployment, and those are usually platform specific.


  • @Jaime said:

    Of course.  But was achieving that goal worth the price paid?

    I don't know - I never set the project scope, so I didn't do a benefits analysis. All I know is that when I hunted down some JAR files to connect Java to SQL Server, I didn't have to go looking for platform-specific downloads.

    @Jaime said:

    People who develop on single-platform frameworks get along just fine.

    Perhaps they do, but I don't see that as an argument against development on cross-platform frameworks.

    @Jaime said:

    There really isn't a ton of value in developing on Windows for deployment on Linux -- just run Linux on your laptop (or in a VM).  Besides, you still need to test configuration and deployment, and those are usually platform specific.

    Funny you should mention that - I've developed a lot of HTML and PHP pages under Windows for a webserver running under Linux and not needed to run Linux in a VM nor requested that my company laptop be reimaged with a Linux desktop. To me, that was the value of an environment that's not OS-dependent.

    I understand your point that variances between staging and production directly affects testing confidence (and thus assurances it'll work when deployed live) but we live in a world where a layer can safely abstract away differences between disparate systems and provide us with a consistent environment to target. I mean, if I were a .net developer and I coded for a specific version, would you argue that I had to take the hardware configuration into account because the production environment was Dell but our staging servers were HP?



  • @Cassidy said:

    I mean, if I were a .net developer and I coded for a specific version, would you argue that I had to take the hardware configuration into account because the production environment was Dell but our staging servers were HP?
    What?



  • @Cassidy said:

    I don't know - I never set the project scope, so I didn't do a benefits analysis.

    You paid the price anyways in crappy GUI support, sub-par Generics, and a language that is falling behind its competitors.@Cassidy said:
    All I know is that when I hunted down some JAR files to connect Java to SQL Server, I didn't have to go looking for platform-specific downloads.

    With .Net, I never have to look for platform-specific downloads because all .Net components run on all environments that support .Net.
    @Cassidy said:
    Funny you should mention that - I've developed a lot of HTML and PHP pages under Windows for a webserver running under Linux and not needed to run Linux in a VM nor requested that my company laptop be reimaged with a Linux desktop. To me, that was the value of an environment that's not OS-dependent.
    All scripting languages are platform independent. Let's compare apples to apples.



  • Ok, here's the thing:

    1) I can't cite the "cross-platform GUI applications is what its for" thing for two reasons: a) I can't find any goddamned marketing material from 1996 to cite, and b) at that time I was so "in" the GUI mindset that I probably literally could not imagine creating a programming language for writing anything except GUI apps.

    2) Whatever the case, the point is that Java sucks at GUI applications, and yet people keep using Java to write GUI applications. These people are awful and need to be killed. The worst is Notch, who took a platform that was thankfully almost completely dead for the average user, and wrote an app that targets average users. Now the fucking JVM is being installed on machines (other than servers and developer workstations) again when for like 5 years it wasn't. What an ass. Google also gets a demerit for their Android shit, but Notch is worse.

    Conclusion: I hate you all. Especially you.



  • @blakeyrat said:

    1) I can't cite the "cross-platform GUI applications is what its for" thing for two reasons: a) I can't find any goddamned marketing material from 1996 to cite, and b) at that time I was so "in" the GUI mindset that I probably literally could not imagine creating a programming language for writing anything except GUI apps.

    Java has a long history of things it has failed at; desktop apps are only one of many. It started out as a platform for embedded systems, but found no traction there. Then it sought to become the GUI platform of the web, through applets (or downloaded desktop apps). It failed at this, too, and was finally relegated to the role of sever-side work. It should have died years ago but sadly it has limped along because the Apache project keeps churning out new libraries and software components for it.



  • @Cassidy said:

    I don't know - I never set the project scope, so I didn't do a benefits analysis. All I know is that when I hunted down some JAR files to connect Java to SQL Server, I didn't have to go looking for platform-specific downloads.

    How often do you encounter OS-specific libraries for any language?

    @Cassidy said:

    I understand your point that variances between staging and production directly affects testing confidence (and thus assurances it'll work when deployed live) but we live in a world where a layer can safely abstract away differences between disparate systems and provide us with a consistent environment to target.

    No, we do not live in such a world. No abstraction is perfect. If your staging/QA and production run two entirely different platforms then you suck at testing.

    @Cassidy said:

    I mean, if I were a .net developer and I coded for a specific version, would you argue that I had to take the hardware configuration into account because the production environment was Dell but our staging servers were HP?

    This is a really nonsensical statement. The brand of the OEM does not matter; however there are plenty of differences between different sets of hardware (AMD vs. Intel, or even different versions of the same Intel product line). Some of these are abstracted away, but not all. And what about different distributions of Linux (or even different releases of the same distro)? Different Windows versions probably have the same issues, too, although Microsoft prioritizes compatibility a lot more than Linux. See also: different database server software; different versions of the same database server; different versions of the language runtime; different versions of the compiler (for compiled languages); different versions of a third-party library... the list goes on and on.

    tl;dr All abstractions are leaky. If you aren't testing the same environment (as closely as humanly possible) between staging and production, then why are you bothering to test it at all?


  • ♿ (Parody)

    @morbiuswilters said:

    How often do you encounter OS-specific libraries for any language?

    This can't be a serious question. But the answer is, "All the time." But not, as mentioned, for Java. Certainly for C/C++. I haven't used much perl lately, but lots of those are OS-specific (usually due to dependency on C code, of course).



  • (since we're on a pissing contest level for a while now, might as well start "fixing" other people's posts)

    @morbiuswilters said:

    It should have died years ago but luckily it has too much value because the Apache project and others keep churning out awesome new libraries and software components (that other platforms can only dream of) for it.

    FTFY



  •  Hey, 5 million minecraft players can't be wrong.

     

     

    You know.

     

    I don't want to be wrong.



  • @Jaime said:

    You paid the price anyways in crappy GUI support

    Perhaps I did, but I don't know why you're hung up on this importance of GUI stuff - you seem to assume this is a design consideration for my choice of language.

    @Jaime said:

    and a language that is falling behind its competitors.

    .. and yet still seems to be in widespread use

    @Jaime said:

    With .Net, I never have to look for platform-specific downloads because all .Net components run on all environments that support .Net.

    So is the platform relevent or irrelevent in this case?

    @Jaime said:

    All scripting languages are platform independent. Let's compare apples to apples.

    Sorry, too busy writing some VBscript for someone's iPhone...

    @morbiuswilters said:

    This is a really nonsensical statement. The brand of the OEM does not matter; however there are plenty of differences between different sets of hardware (AMD vs. Intel, or even different versions of the same Intel product line). Some of these are abstracted away, but not all.

    Agreed, hence making that statement to draw the nonsensical part of it out.

    @morbiuswilters said:

    And what about different distributions of Linux (or even different releases of the same distro)?

    x86_64 packages don't actually seem to care if I've got AMD or Intel 64-bit chip. They do whinge about dependencies, mind. As do .noarch RPMs. But I digress...

    @morbiuswilters said:

    tl;dr All abstractions are leaky. If you aren't testing the same environment (as closely as humanly possible) between staging and production, then why are you bothering to test it at all?

    This is kinda my point: I think it's down to an understanding of what the environment is, and how close it needs to be between systems. Can .net developers test on their workstations running the same version of framework or do they need to deploy to a staging server that identically matches production?

    (yes, I know this is a disingenious argument, because there are different levels of testing that can use a mixture of both environments.)

    This whole discussion birthed from Java's aim of providing a Virtual Machine environment abstracted from the OS and hardware, thus facilitating portability between systems, not from Blakey's claims that it was developed for cross-platform GUI programs. As yet, I've not seen evidence that his claim is correct, only distractions that his claim doesn't require validation nor coding for a specific platform provides greater value.



  • @blakeyrat said:

    2) Whatever the case, the point is that Java sucks at GUI applications

    That. Bit of a Catch-22 situation: people don't use it for GUI stuff because it's so crap (and there are better ways out there), and because it's not used there's no pressure on Sun/Oracle/etc to improve it.

    Either Swing/AWT needs a proper revamp, or GUI stuff in Java ought to be shelved. I suspect Sun hoped for the latter, but it doesn't stop some games developers liberally applying leather flails to a deceased equine.

    @blakeyrat said:

    Conclusion: I hate you all. Especially you.

    All the love, baby.



  • @Cassidy said:

    @blakeyrat said:

    2) Whatever the case, the point is that Java sucks at GUI applications

    That. Bit of a Catch-22 situation: people don't use it for GUI stuff because it's so crap (and there are better ways out there), and because it's not used there's no pressure on Sun/Oracle/etc to improve it.

    Except it is used for GUI stuff. We already named examples in this thread, Eclipse, NetBeans, Minecraft-- all GUI applications.

    The reason Oracle doesn't fix it is because Oracle is shit. The reason Sun never fixed it is because Sun is shit. The reason Java is shit is that its development is guided by corporations which are shit.

    Look, I'm not a huge fan of Objective-C, but it's critical to Apple and so Apple does things like *gasp* fixing its flaws and adding features to it. Ditto C#, Microsoft has a huge interest in fixing its flaws and adding new features. Hell, for that matter, look at ActionScript and Adobe. It went un-cared-for a long time, until Silverlight was on the horizon, but now it's a pretty damned sharp language which its main weakness being its IDE is Java-based.

    That's because Apple and Microsoft are actual software companies that spend time writing actual software. Sun and Oracle are lawsuit companies that engage in lawsuits. Oh, also, they bribe C*Os of other companies to buy their shit. There's a big, big difference. Microsoft makes decisions based on developers, designers and (admittedly) marketing folks. Sun and Oracle make decisions based on their lawyers and a couple executives who are good at bribing other executives. They will never, ever, produce decent software. Ever. It's not in their DNA. They've never done it in the past. They'll never do it in the future. If you think otherwise, you are an idiot.

    IBM also is a lawsuit company, FYI.



  • @blakeyrat said:

    Except it is used for GUI stuff. We already named examples in this thread, Eclipse, NetBeans, Minecraft-- all GUI applications.

    Erm.. yeah. Busted. Okay, perhaps I should have clarified my words there - it's not renown for its graphical capabilities (or lack of them) so whilst it's been used to create graphical tools/software, I think the choice was driven more by cross-platform accessibility rather than the strength of Swing.

    ObDeparture: I was creating a simple graphical reporting tool and my initial choice was Java.  After managing to use a Java charting framework, I wrestled with Spring layouts and managed to get a form to capture data and a window that displayed it as a bar graph/pie chart.

    Then I threw it away and did the same thing using a Javascript framework. Took a fraction of the time and was fuck easier.

    @blakeyrat said:

    Sun and Oracle make decisions based on their lawyers and a couple executives who are good at bribing other executives.

    I've seen some stuff in Solaris that led me to believe design decisions were made by crack-addled marketeers who expected "ooh! Shiny!" to cause a upsurge in sales. And some stuff in Oracle, come to think of it, but then again Ellison's lifestyle is widely-reported so no surprises there.



  • @boomzilla said:

    This can't be a serious question. But the answer is, "All the time." But not, as mentioned, for Java. Certainly for C/C++. I haven't used much perl lately, but lots of those are OS-specific (usually due to dependency on C code, of course).

    As soon as I posted that I knew some pedantic fuckhead was going to bring up C/C++. Fine. How often do you encounter it in a high-level language?



  • @veggen said:


    (since we're on a pissing contest level for a while now, might as well start "fixing" other people's posts)

    @morbiuswilters said:

    It should have died years ago but luckily it has too much value because the Apache project and others keep churning out awesome new libraries and software components (that other platforms can only dream of) for it.

    FTFY

    Wow, retarded, ineffective trolling! Seriously, leave the real developers alone, kid.



  • @Cassidy said:

    @Jaime said:

    and a language that is falling behind its competitors.

    .. and yet still seems to be in widespread use

    A lot of people still wipe their ass with their bare hand, too.

    @Cassidy said:

    @morbiuswilters said:

    This is a really nonsensical statement.
    The brand of the OEM does not matter; however there are plenty of
    differences between different sets of hardware (AMD vs. Intel, or even
    different versions of the same Intel product line). Some of these are
    abstracted away, but not all.

    Agreed, hence making that statement to draw the nonsensical part of it out.

    What? It's nonsensical because hardware does matter.

    @Cassidy said:

    @morbiuswilters said:

    And what about different distributions
    of Linux (or even different releases of the same distro)?

    x86_64
    packages don't actually seem to care if I've got AMD or Intel 64-bit
    chip. They do whinge about dependencies, mind. As do .noarch RPMs. But I
    digress...

    Well, at that point I was referring to cross-distro compatibility (Red Hat to Ubuntu) or cross-release compatibility (Ubuntu 8.04 to Ubuntu 11.04). But Linux is really shitty about compatibility anyway, so maybe that's not the best example.

    @Cassidy said:

    This whole discussion birthed from Java's aim of providing a Virtual Machine environment abstracted from the OS and hardware, thus facilitating portability between systems, not from Blakey's claims that it was developed for cross-platform GUI programs. As yet, I've not seen evidence that his claim is correct, only distractions that his claim doesn't require validation nor coding for a specific platform provides greater value.

    Well, Java is meant to be cross-platform, but so are many other high-level languages. And, yes, Java was designed to write cross-platform GUI apps. It's since morphed into a bloated, painful server-side language as well, but that wasn't its original intent.



  • @blakeyrat said:

    They will never, ever, produce decent software. Ever. It's not in their DNA. They've never done it in the past. They'll never do it in the future. If you think otherwise, you are an idiot.

    Sun had a rough decade-and-a-half until its demise, but it did produce some decent software back in the day: SunOS, NFS... um..

    I'm not aware of Oracle doing anything useful, though.

    @blakeyrat said:

    IBM also is a lawsuit company, FYI.

    I don't know about that. IBM had an illustrious past, although it's been kind of shitty for awhile. Still, they have so many fingers in so many pies I'm tempted to believe they still produce some good software.



  • @morbiuswilters said:

    What? It's nonsensical because hardware does matter.

    @Jaime said:

    With .Net, I never have to look for
    platform-specific downloads because all .Net components run on all
    environments that support .Net.

    Tell you what, I'll leave you two to argue that point between you. Either the H/W or platform needs to be considered when coding for the framework, or the framework provides libraries/an environment that abstract away H/W and OS differences (to some extent).I ain't playing Berlin wall on this one.

    @morbiuswilters said:

    Well, at that point I was referring to cross-distro compatibility (Red Hat to Ubuntu) or cross-release compatibility (Ubuntu 8.04 to Ubuntu 11.04). But Linux is really shitty about compatibility anyway, so maybe that's not the best example.

    No, but I get your point. I learned that it wasn't enough to hunt down RPMs for my architecture and version, but distro also when dealing with SuSE and Mandrake.

    @morbiuswilters said:

    And, yes, Java was designed to write cross-platform GUI apps. It's since morphed into a bloated, painful server-side language as well, but that wasn't its original intent.

    Full circle! I remember being told that Java was a platform, an environment (the JVM), a set of libraries... but I don't recall the GUI part of it being mentioned as a design consideration. I'm happy to be corrected on that point, but... I'm with Blakey on this one: I don't seriously understand who in their right mind thought AWT was a great way to "sell" Java on cross-platform GUI apps.



  • @Cassidy said:

    @morbiuswilters said:

    And, yes, Java was designed to write cross-platform GUI apps. It's since morphed into a bloated, painful server-side language as well, but that wasn't its original intent.

    Full circle! I remember being told that Java was a platform, an environment (the JVM), a set of libraries... but I don't recall the GUI part of it being mentioned as a design consideration. I'm happy to be corrected on that point, but... I'm with Blakey on this one: I don't seriously understand who in their right mind thought AWT was a great way to "sell" Java on cross-platform GUI apps.

    I've heard that AWT was basically slopped together at the end, just before Java's release, more of an afterthought than anything. However, writing GUI apps (especially those launched from a browser) was a major selling point of Java in the early days. Eventually everyone realized that Java sucked for GUI apps and it found a home server-side.


  • ♿ (Parody)

    @morbiuswilters said:

    @boomzilla said:
    This can't be a serious question. But the answer is, "All the time." But not, as mentioned, for Java. Certainly for C/C++. I haven't used much perl lately, but lots of those are OS-specific (usually due to dependency on C code, of course).

    As soon as I posted that I knew some pedantic fuckhead was going to bring up C/C++. Fine. How often do you encounter it in a high-level language?

    I gave the example of perl. I'm somewhat disappointed that you didn't rant about perl not being high level or something. But how about python? I'm thinking about stuff like numpy and scipy. Basically, anything that uses native code will obviously require platform specific binaries. This is one advantage of using JIT compilers in .Net and Java, of course.

    I'll wait for you to revise your question again to make a non-argument against java.



  • @boomzilla said:

    @morbiuswilters said:
    @boomzilla said:
    This can't be a serious question. But the answer is, "All the time." But not, as mentioned, for Java. Certainly for C/C++. I haven't used much perl lately, but lots of those are OS-specific (usually due to dependency on C code, of course).

    As soon as I posted that I knew some pedantic fuckhead was going to bring up C/C++. Fine. How often do you encounter it in a high-level language?

    I gave the example of perl. I'm somewhat disappointed that you didn't rant about perl not being high level or something. But how about python? I'm thinking about stuff like numpy and scipy. Basically, anything that uses native code will obviously require platform specific binaries. This is one advantage of using JIT compilers in .Net and Java, of course.

    I'll wait for you to revise your question again to make a non-argument against java.

    Well, there are platform-specific libraries for almost every language, including Java. I guess a better point would be "How often do you need platform-specific libraries and how often is it a problem?" And many of these Python/perl/PHP/Ruby libraries compile on multiple systems which provides the same kind of abstraction to the developer that Java does. And in many cases the reason something is written in C is for performance.

    Being platform-agnostic has its disadvantages, too. Things have to be done in the lowest-common-denominator kind of way, which results in dumbed-down behavior. For example, not being able to use unix sockets in JDBC.

    I don't know where this argument is going. I guess some languages might require you to install a platform-dependent library or two, but that still doesn't make Java any less of a pain to develop on. It's usually more pain to install Java libraries because there are so fucking many of them needed. And God help you if you require two different versions of the same library.


  • ♿ (Parody)

    @morbiuswilters said:

    I don't know where this argument is going. I guess some languages might require you to install a platform-dependent library or two, but that still doesn't make Java any less of a pain to develop on. It's usually more pain to install Java libraries because there are so fucking many of them needed. And God help you if you require two different versions of the same library.

    I fully agree with this.


Log in to reply