6 ms·

This is the main draw for me. Compared to Python, other languages (well, some) seem to require you to do so many things that just seem... unnecessary. I couldn

by nudge 16y ago

This is the main draw for me. Compared to Python, other languages (well, some) seem to require you to do so many things that just seem... unnecessary. I couldn't believe all the junk Java required of me when I took a stab at it. It's like being confronted with some unhelpful bureaucrat: I know what I mean, they know what I mean, but they're damn well going to make me trudge through all the nonsense so that what I mean is turned into something the bureaucracy understands. The linked NLP examples are great for illustrating this.

thedigitalengel 16y ago
Java is, as I said, a toy language. A language that needs you, the client programmer, to define getFoo () and setFoo () methods manually can't be right.
- exit 16y ago
  c++ feels incredibly bureaucrat to me too though. like separating definition from declaration into header files. what do you think of ooc-lang syntax? http://ooc-lang.org/ http://ooc-lang.org/
  - thedigitalengel 16y ago
    I think the header-file and source-file distinction was more of an architectural decision (so that you could implement an efficient compiling and linking system) than a language design decision. Just an opinion, though.
    - exit 16y ago
      of course it was architectural, but that's precisely the problem - why are we still using a language designed for an age of computational scarcity? another example: functions should be virtual by default.
      - tbrownaw 16y ago
        another example: functions should be virtual by default. No no no! C++ got this one right, and then C# did better ('virtual' to declare a virtual/overridable function in the base class, and 'override' to replace it in the subclass). http://www.artima.com/intv/nonvirtual.html http://www.artima.com/intv/nonvirtual.html Every time you say virtual in an API, you are creating a call back hook. As an OS or API framework designer, you've got to be real careful about that. You don't want users overriding and hooking at any arbitrary point in an API, because you cannot necessarily make those promises. And people may not fully understand the promises they are making when they make something virtual.
- dhimes 16y ago
  Java doesn't require you to define getFoo() and setFoo(). Some best practice advice suggests you do. But you can leave the vars public and just use the . operator, if you choose. It seems like Java wasn't defined in order to be an efficient for a three-person shop to hack in. It was meant to be efficient for a 40 person shop to build code as a team that they can maintain. That said, I dread going back to my Java projects and updating them, even though I tried to maintain best practices in order that updating be as simple as possible. I've been immersed in php and javascript lately, so we'll see what it's like to go back.
  - dfox 16y ago
    Java certainly was not designed to be this "enterprise language" it is now. It only was similar enough to Smalltalk to replace it. (and Smalltalk has this culture of "if it is repetitive then extend IDE to automate it", which to some extent influenced Java IDEs)
    - dhimes 16y ago
      My impression, although I'm not an insider and could be off base, is that it wasn't conceived to be an enterprise language, but its patterns were. I learned it when I started application programming for my startup (I had been doing scientific routines, i.e. FORTRAN and Mathematica), because I was curious about OO. A lot had changed since I hacked out a little C and assembler on my Mac+ many years ago, and the scale of the problems programmers and programming teams had to handle had changed significantly. It seemed OO became popular as a way to handle this scale of things. Java was presented as a solution for building maintainable apps, so I learned it. I also tried to stay close to the OO paradigms (of course, I was just learning them), as I built this 50000 line beast called "Egorg." Now, I get to maintain and update it, so we'll see if it paid off. On a side note, I have a real distaste for objects in Javascript. They seem clunky, almost like they were stuck on as an afterthought (I get a similar feel about Generics in Java). But the design of Javascript makes it quite easily to hammer out a script to do something cool. I'm worried about maintenance, though, because I feel like I'm evolving my own design patterns, so retracing my steps will likely be painful. You are correct about the IDE thing. That does ease a large burden in Java.
- TrevorBurnham 16y ago
  I don't get what you mean by "toy language." Clearly some big, powerful, practical stuff has been written in it. Usually the phrase "toy language" is used to refer to those with little practical use. Java is unwieldy, but it has a rich ecosystem and compiles to very efficient code across a broad range of platforms. If you want Java without the unwieldiness, try Groovy. It's Java with a ton of syntactic goodness added; for instance, the default variable scope is "create a getter and setter which I can optionally override." Groovy interoperates well with Java libraries. The downside is that it's a dynamic language, so there is a significant performance penalty.
  - thedigitalengel 16y ago
    As I said earlier. "Secondly I don't mean to criticize Java. By calling it a toy language, I was simply referring to the fact that Java tends to make writing bad code difficult, and in doing this takes away some of the flexibility and power that you tend to associate with other languages." Judging from the general reaction it seems I should not have used the term "toy language". My apologies if I ended up implying that Java has little practical use.
    - cabalamat 16y ago
      > Java tends to make writing bad code difficult I've known people who could write bad code in Java with the utmost ease! It'd probably be more accurate to say that Java deliberately limits its expressiveness, in order to make it harder for people to shoot themselves in the foot, and to make it easier for one programmer to understand what another has written.
      - thedigitalengel 16y ago
        > It'd probably be more accurate to say that Java deliberately limits its expressiveness, in order to make it harder for people to shoot themselves in the foot, and to make it easier for one programmer to understand what another has written. That is exactly what I meant. Bad programmers exist. They will write bad code, no matter what language they're made to use.
zepolen 16y ago
You don't really appreciate Python until you try and program in something like Java again. The following code is readable and I have required a variation of it in a program before: sorted([ord(c) for c in set('letters in this sentence') & set('and this one')], reverse=True) Doing it in Java would be a chore now.
- mcav 16y ago
  Here's a translation of that to Clojure, since I'm learning that now: (use 'clojure.set) (reverse (sort (map int (intersection (set "letters in this sentence") (set "and this one"))))) Edit: Take two... (use 'clojure.set) (->> (intersection (set "letters in this sentence") (set "and this one")) (map int) sort reverse) (experienced lispers, feel free to make this more idiomatic)
  - mattrepl 16y ago
    Here's one using a list comprehension to make it more closely resemble the Python example. (require ['clojure.set :as 's]) (-> (for [c (s/intersection (set "letters in this sentence") (set "and this one"))] (int c)) sort reverse)
  - sreque 16y ago
    Not sure why we are posting alternative language implementations, but here is the Scala version :). You could say that this was an exercise for me in learning 2.8, which I am unfamiliar with. A for comprehension isn't needed because Scala already treats Strings as a sequence of characters. (Set("letters in this sentence":_* ) & Set("and this one":_* )).toSeq.sorted.reverse Or you, can take advantage of Scala's rich choice of collections. import scala.collection.immutable.TreeSet import scala.math.Ordering._ TreeSet("letters in this sentence":_* )(Char.reverse) & Set("and this one":_* ) toSeq The machinery Scala has in place to make the second example work is quite impressive, and I was pleased to see that it worked. Even though the intersection method returns a brand new set, using implicit arguments it correctly creates a set of the correct type (TreeSet) with the correct ordering function (Char.reverse), without any duplication of code in the standard library (like overriding '&' in every sub-class).

by nudge 16y ago

thedigitalengel 16y ago

Java is, as I said, a toy language. A language that needs you, the client programmer, to define getFoo () and setFoo () methods manually can't be right.

exit 16y ago
c++ feels incredibly bureaucrat to me too though. like separating definition from declaration into header files. what do you think of ooc-lang syntax? http://ooc-lang.org/ http://ooc-lang.org/
- thedigitalengel 16y ago
  I think the header-file and source-file distinction was more of an architectural decision (so that you could implement an efficient compiling and linking system) than a language design decision. Just an opinion, though.
  - exit 16y ago
    of course it was architectural, but that's precisely the problem - why are we still using a language designed for an age of computational scarcity? another example: functions should be virtual by default.
    - tbrownaw 16y ago
      another example: functions should be virtual by default. No no no! C++ got this one right, and then C# did better ('virtual' to declare a virtual/overridable function in the base class, and 'override' to replace it in the subclass). http://www.artima.com/intv/nonvirtual.html http://www.artima.com/intv/nonvirtual.html Every time you say virtual in an API, you are creating a call back hook. As an OS or API framework designer, you've got to be real careful about that. You don't want users overriding and hooking at any arbitrary point in an API, because you cannot necessarily make those promises. And people may not fully understand the promises they are making when they make something virtual.
dhimes 16y ago
Java doesn't require you to define getFoo() and setFoo(). Some best practice advice suggests you do. But you can leave the vars public and just use the . operator, if you choose. It seems like Java wasn't defined in order to be an efficient for a three-person shop to hack in. It was meant to be efficient for a 40 person shop to build code as a team that they can maintain. That said, I dread going back to my Java projects and updating them, even though I tried to maintain best practices in order that updating be as simple as possible. I've been immersed in php and javascript lately, so we'll see what it's like to go back.
- dfox 16y ago
  Java certainly was not designed to be this "enterprise language" it is now. It only was similar enough to Smalltalk to replace it. (and Smalltalk has this culture of "if it is repetitive then extend IDE to automate it", which to some extent influenced Java IDEs)
  - dhimes 16y ago
    My impression, although I'm not an insider and could be off base, is that it wasn't conceived to be an enterprise language, but its patterns were. I learned it when I started application programming for my startup (I had been doing scientific routines, i.e. FORTRAN and Mathematica), because I was curious about OO. A lot had changed since I hacked out a little C and assembler on my Mac+ many years ago, and the scale of the problems programmers and programming teams had to handle had changed significantly. It seemed OO became popular as a way to handle this scale of things. Java was presented as a solution for building maintainable apps, so I learned it. I also tried to stay close to the OO paradigms (of course, I was just learning them), as I built this 50000 line beast called "Egorg." Now, I get to maintain and update it, so we'll see if it paid off. On a side note, I have a real distaste for objects in Javascript. They seem clunky, almost like they were stuck on as an afterthought (I get a similar feel about Generics in Java). But the design of Javascript makes it quite easily to hammer out a script to do something cool. I'm worried about maintenance, though, because I feel like I'm evolving my own design patterns, so retracing my steps will likely be painful. You are correct about the IDE thing. That does ease a large burden in Java.
TrevorBurnham 16y ago
I don't get what you mean by "toy language." Clearly some big, powerful, practical stuff has been written in it. Usually the phrase "toy language" is used to refer to those with little practical use. Java is unwieldy, but it has a rich ecosystem and compiles to very efficient code across a broad range of platforms. If you want Java without the unwieldiness, try Groovy. It's Java with a ton of syntactic goodness added; for instance, the default variable scope is "create a getter and setter which I can optionally override." Groovy interoperates well with Java libraries. The downside is that it's a dynamic language, so there is a significant performance penalty.
- thedigitalengel 16y ago
  As I said earlier. "Secondly I don't mean to criticize Java. By calling it a toy language, I was simply referring to the fact that Java tends to make writing bad code difficult, and in doing this takes away some of the flexibility and power that you tend to associate with other languages." Judging from the general reaction it seems I should not have used the term "toy language". My apologies if I ended up implying that Java has little practical use.
  - cabalamat 16y ago
    > Java tends to make writing bad code difficult I've known people who could write bad code in Java with the utmost ease! It'd probably be more accurate to say that Java deliberately limits its expressiveness, in order to make it harder for people to shoot themselves in the foot, and to make it easier for one programmer to understand what another has written.
    - thedigitalengel 16y ago
      > It'd probably be more accurate to say that Java deliberately limits its expressiveness, in order to make it harder for people to shoot themselves in the foot, and to make it easier for one programmer to understand what another has written. That is exactly what I meant. Bad programmers exist. They will write bad code, no matter what language they're made to use.

zepolen 16y ago

You don't really appreciate Python until you try and program in something like Java again. The following code is readable and I have required a variation of it in a program before: sorted([ord(c) for c in set('letters in this sentence') & set('and this one')], reverse=True) Doing it in Java would be a chore now.

mcav 16y ago
Here's a translation of that to Clojure, since I'm learning that now: (use 'clojure.set) (reverse (sort (map int (intersection (set "letters in this sentence") (set "and this one"))))) Edit: Take two... (use 'clojure.set) (->> (intersection (set "letters in this sentence") (set "and this one")) (map int) sort reverse) (experienced lispers, feel free to make this more idiomatic)
- mattrepl 16y ago
  Here's one using a list comprehension to make it more closely resemble the Python example. (require ['clojure.set :as 's]) (-> (for [c (s/intersection (set "letters in this sentence") (set "and this one"))] (int c)) sort reverse)
- sreque 16y ago
  Not sure why we are posting alternative language implementations, but here is the Scala version :). You could say that this was an exercise for me in learning 2.8, which I am unfamiliar with. A for comprehension isn't needed because Scala already treats Strings as a sequence of characters. (Set("letters in this sentence":_* ) & Set("and this one":_* )).toSeq.sorted.reverse Or you, can take advantage of Scala's rich choice of collections. import scala.collection.immutable.TreeSet import scala.math.Ordering._ TreeSet("letters in this sentence":_* )(Char.reverse) & Set("and this one":_* ) toSeq The machinery Scala has in place to make the second example work is quite impressive, and I was pleased to see that it worked. Even though the intersection method returns a brand new set, using implicit arguments it correctly creates a set of the correct type (TreeSet) with the correct ordering function (Char.reverse), without any duplication of code in the standard library (like overriding '&' in every sub-class).