5 ms·

beauty of threading? shudder anyways. I have some reasons for my strong dislike of Java: a) checked exceptions, b) no method pointers or something similar and

by pilif 16y ago

beauty of threading? shudder anyways. I have some reasons for my strong dislike of Java: a) checked exceptions, b) no method pointers or something similar and c) lots of the code produced by the community out there (and in the standard library itself) is full of FactoryFactoryFactories and other typing intensive, mind-bending and ultimately useless abstractions (most of them not DRY at all either). Back in 2004 I did strongly consider Java though, but ultimately, I didn't have time to implement this web application AND learn a new library (learning the language is easy. learning the library is what makes you slow in the beginning). As a side note: Said web application also accesses locally connected barcode scanners over the local serial port. Unfortunately the only way to do this (aside of a locally installed client) is still using a Java Applet which I've also written back in 2004. So I do have the Java experience to know that I don't quite like it :-)

bigiain 16y ago
"beauty of threading? shudder" Indeed, this whole thread's reminding me of: "Combining the sanity of threads with the robustness of web development" http://wearehugh.com/public/2010/08/html5-web-workers/ http://wearehugh.com/public/2010/08/html5-web-workers/
brown9-2 16y ago
lots of the code produced by the community out there is full of FactoryFactoryFactories and other typing intensive, mind-bending and ultimately useless abstractions (most of them not DRY at all either So what? Why does the code produced by others in "the community" affect your perception of the language and/or tools, if you aren't using their code?
- AndyKelley 16y ago
  Because when we call Java "ugly" or "stupid," it's the community we're talking about. My room mate is an extremely talented Java programmer, and he can fly around Eclipse[1] like a giant rainbow steamroller[2]. He uses Java like it should be used, and it's great. But I don't think he represents the community. He tells me horror stories of code he refactors at work written by people in his own office, or worse, outsourced companies, and it's bad. It seems to me that that kind of code is more representative of the community. When you're going to join a project, you have a better chance of encountering code not sucking if the overall culture of that language is better. [1]: http://www.youtube.com/results?search_query=eclipse+sorcery http://www.youtube.com/results?search_query=eclipse+sorcery [2]: http://theoatmeal.com/comics/literally http://theoatmeal.com/comics/literally
  - instcode 16y ago
    Ha, if you are thinking that way, I would suggest VB.NET or C# instead. Why? I remember the first time I was creating an MFC project using Project Wizard, I felt like I'm a fool looking at a bunch of auto-generated text & having no clue what it is about. And once again, I was in the same situation when I was using VS.NET to generate code for my first ASP.NET web app. But I still completed that webapp without even knowing what code is for. Does that make VB.NET/C# community more stupid than Java? Does that mean C#/VB.NET should be the ugly & stupid thing other than Java? So, you should better have another way to explain that.
- raganwald 16y ago
  Whether you fall in line or not, the culture around Java is around writing code to a certain style. Agree or disagree, there's an argument that by writing in a style that is familiar to Java programmers, your code is easier to read and maintain. If you're one guy off in a corner, write however you want. But if you're not, you have to take the culture into consideration. And if you are one guy in a corner, why are you using Java?
  - Periodic 16y ago
    I just started working for a large enterprise corporation (one of the biggest financial companies in the world). We have a lot of old code written in Java that needs to be maintained. I've been trying to advocate new ways of doing things, but almost every time the other developers will respond with, "that's just not how we do things here." Java has a very strong culture around it. I worked in academia and startups previously and I didn't realize that there is a huge number Java programmers who do nothing but program in Java. They aren't interested in learning new languages and will only grudgingly learn a new framework. Their biggest concern making sure the lowest common denominator can still maintain the (unmaintainable) code. An example is unit testing. Our current "unit" tests start up a JBoss instance, connect to the development databases, and take ~5 minutes to run just one test. But I've been told not to waste my time working on anything more modular and that if I'm going to put in any time working on unit tests, I should contribute to the framework everyone else is already using. It can be quite soul crushing.
    - cruise02 16y ago
      Where do you sit? I'm on the 5th floor, by the stairwell.
      - raganwald 16y ago
        I was on two, but Lumburgh asked me to go ahead and move my desk downstairs into the storage locker.
        16y ago
- mattmcknight 16y ago
  I think for web applications, most people use a "community" provided framework, various libraries, etc. Java has been a locus for that mindset (as in the classic: http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12 http://discuss.joelonsoftware.com/default.asp?joel.3.219431.... ) It's not just parody though: http://www.docjar.org/docs/api/org/outerj/pollo/xmleditor/FactoryFactory.html http://www.docjar.org/docs/api/org/outerj/pollo/xmleditor/Fa...
jsvaughan 16y ago
do you think you'd have been better off with a statically typed language though?
- pilif 16y ago
  personally, I prefer the dynamically typed languages. but I hate. No. HATE PHP's type conversions with its == operator. 0 == 'foobar' but true == 'foobar' && 0 == false so true == false ? eek. Yeah. I know === exists. But if you have to compare strings and numbers, why is the default conversion method you do the lossy one? If you compare a number to a string, why can't you convert the number into a string and compare the two strings? Why convert the string into a number which will be lossy in most cases?
  - mgkimsal 16y ago
    There's == and === - they do separate things. http://stackoverflow.com/questions/359494/javascript-vs http://stackoverflow.com/questions/359494/javascript-vs It's not that hard to get your head around, and at least one other major language does it this way.
    - perlgeek 16y ago
      agreed, but == being a non-associative operator is still just sick.
      - mjw 16y ago
        I think you mean non-transitive. But yes.
  - invisible 16y ago
    Sometimes it is "easier" to just type: if (isThisReturningEmpty()) {} instead of typing: if (isThisReturningEmpty() === "") {} And if you know something could return 0 (which is not empty), you should know to do a type-sensitive check). You are trading off HAVING to set types with HAVING to check types when needed (I think the latter is better).
dgabriel 16y ago
Since when are there pointers in PHP?
- pilif 16y ago
  there are none, but to implement a callback you also wouldn't have to declare an inner class implementing some interface that in turn declares tens of methods just to react to that one callback. In PHP 5.3 you'd just pass the function (which of course will pass a pointer to that function) and in earlier versions you'd hack something with eval or variable-variables which, while bad, is still better than either writing half a screen full of empty methods or inheriting an inner class from some meaninglessly named class that only exists for you not to have a screenful of empty methods.
  - wvenable 16y ago
    In all versions of PHP, callbacks are extremely easy (no eval or variable-variables required). You just have to pass the name of function or method around and use the call_user_func() function to call it.
RodgerTheGreat 16y ago
Java throwables come in two flavors: Exceptions like IOException which must be checked, and Errors like AssertionError which do not need to be checked. If you really, really don't like checked exceptions you can easily build libraries and write code that rely exclusively upon unchecked exceptions. I wouldn't personally recommend this design methodology.
- pedanticfreak 16y ago
  Errors and unchecked Exceptions in Java should not be confused. An Error is typically reserved for the runtime environment for a "this ship is sinking, abandon all hands" kind of unrecoverable error. More properly Exceptions in execution that aren't checked in Java extend RuntimeException and not Error. The stigma that Java has too many checked exceptions is no longer true with modern Java code. Everyone is using unchecked children of RuntimeException almost exclusively. Of course, there is still plenty of legacy code out there using outdated checked exception paradigms.

by pilif 16y ago

bigiain 16y ago

"beauty of threading? shudder" Indeed, this whole thread's reminding me of: "Combining the sanity of threads with the robustness of web development" http://wearehugh.com/public/2010/08/html5-web-workers/ http://wearehugh.com/public/2010/08/html5-web-workers/

brown9-2 16y ago

lots of the code produced by the community out there is full of FactoryFactoryFactories and other typing intensive, mind-bending and ultimately useless abstractions (most of them not DRY at all either So what? Why does the code produced by others in "the community" affect your perception of the language and/or tools, if you aren't using their code?

AndyKelley 16y ago
Because when we call Java "ugly" or "stupid," it's the community we're talking about. My room mate is an extremely talented Java programmer, and he can fly around Eclipse[1] like a giant rainbow steamroller[2]. He uses Java like it should be used, and it's great. But I don't think he represents the community. He tells me horror stories of code he refactors at work written by people in his own office, or worse, outsourced companies, and it's bad. It seems to me that that kind of code is more representative of the community. When you're going to join a project, you have a better chance of encountering code not sucking if the overall culture of that language is better. [1]: http://www.youtube.com/results?search_query=eclipse+sorcery http://www.youtube.com/results?search_query=eclipse+sorcery [2]: http://theoatmeal.com/comics/literally http://theoatmeal.com/comics/literally
- instcode 16y ago
  Ha, if you are thinking that way, I would suggest VB.NET or C# instead. Why? I remember the first time I was creating an MFC project using Project Wizard, I felt like I'm a fool looking at a bunch of auto-generated text & having no clue what it is about. And once again, I was in the same situation when I was using VS.NET to generate code for my first ASP.NET web app. But I still completed that webapp without even knowing what code is for. Does that make VB.NET/C# community more stupid than Java? Does that mean C#/VB.NET should be the ugly & stupid thing other than Java? So, you should better have another way to explain that.
raganwald 16y ago
Whether you fall in line or not, the culture around Java is around writing code to a certain style. Agree or disagree, there's an argument that by writing in a style that is familiar to Java programmers, your code is easier to read and maintain. If you're one guy off in a corner, write however you want. But if you're not, you have to take the culture into consideration. And if you are one guy in a corner, why are you using Java?
- Periodic 16y ago
  I just started working for a large enterprise corporation (one of the biggest financial companies in the world). We have a lot of old code written in Java that needs to be maintained. I've been trying to advocate new ways of doing things, but almost every time the other developers will respond with, "that's just not how we do things here." Java has a very strong culture around it. I worked in academia and startups previously and I didn't realize that there is a huge number Java programmers who do nothing but program in Java. They aren't interested in learning new languages and will only grudgingly learn a new framework. Their biggest concern making sure the lowest common denominator can still maintain the (unmaintainable) code. An example is unit testing. Our current "unit" tests start up a JBoss instance, connect to the development databases, and take ~5 minutes to run just one test. But I've been told not to waste my time working on anything more modular and that if I'm going to put in any time working on unit tests, I should contribute to the framework everyone else is already using. It can be quite soul crushing.
  - cruise02 16y ago
    Where do you sit? I'm on the 5th floor, by the stairwell.
    - raganwald 16y ago
      I was on two, but Lumburgh asked me to go ahead and move my desk downstairs into the storage locker.
      - 16y ago
mattmcknight 16y ago
I think for web applications, most people use a "community" provided framework, various libraries, etc. Java has been a locus for that mindset (as in the classic: http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12 http://discuss.joelonsoftware.com/default.asp?joel.3.219431.... ) It's not just parody though: http://www.docjar.org/docs/api/org/outerj/pollo/xmleditor/FactoryFactory.html http://www.docjar.org/docs/api/org/outerj/pollo/xmleditor/Fa...

jsvaughan 16y ago

do you think you'd have been better off with a statically typed language though?

pilif 16y ago
personally, I prefer the dynamically typed languages. but I hate. No. HATE PHP's type conversions with its == operator. 0 == 'foobar' but true == 'foobar' && 0 == false so true == false ? eek. Yeah. I know === exists. But if you have to compare strings and numbers, why is the default conversion method you do the lossy one? If you compare a number to a string, why can't you convert the number into a string and compare the two strings? Why convert the string into a number which will be lossy in most cases?
- mgkimsal 16y ago
  There's == and === - they do separate things. http://stackoverflow.com/questions/359494/javascript-vs http://stackoverflow.com/questions/359494/javascript-vs It's not that hard to get your head around, and at least one other major language does it this way.
  - perlgeek 16y ago
    agreed, but == being a non-associative operator is still just sick.
    - mjw 16y ago
      I think you mean non-transitive. But yes.
- invisible 16y ago
  Sometimes it is "easier" to just type: if (isThisReturningEmpty()) {} instead of typing: if (isThisReturningEmpty() === "") {} And if you know something could return 0 (which is not empty), you should know to do a type-sensitive check). You are trading off HAVING to set types with HAVING to check types when needed (I think the latter is better).

dgabriel 16y ago

Since when are there pointers in PHP?

pilif 16y ago
there are none, but to implement a callback you also wouldn't have to declare an inner class implementing some interface that in turn declares tens of methods just to react to that one callback. In PHP 5.3 you'd just pass the function (which of course will pass a pointer to that function) and in earlier versions you'd hack something with eval or variable-variables which, while bad, is still better than either writing half a screen full of empty methods or inheriting an inner class from some meaninglessly named class that only exists for you not to have a screenful of empty methods.
- wvenable 16y ago
  In all versions of PHP, callbacks are extremely easy (no eval or variable-variables required). You just have to pass the name of function or method around and use the call_user_func() function to call it.

RodgerTheGreat 16y ago

Java throwables come in two flavors: Exceptions like IOException which must be checked, and Errors like AssertionError which do not need to be checked. If you really, really don't like checked exceptions you can easily build libraries and write code that rely exclusively upon unchecked exceptions. I wouldn't personally recommend this design methodology.

pedanticfreak 16y ago
Errors and unchecked Exceptions in Java should not be confused. An Error is typically reserved for the runtime environment for a "this ship is sinking, abandon all hands" kind of unrecoverable error. More properly Exceptions in execution that aren't checked in Java extend RuntimeException and not Error. The stigma that Java has too many checked exceptions is no longer true with modern Java code. Everyone is using unchecked children of RuntimeException almost exclusively. Of course, there is still plenty of legacy code out there using outdated checked exception paradigms.