7 ms·

Yesterday there was an interesting link on HN comparing NLP in Python vs. other languages: http://nltk.googlecode.com/svn/trunk/doc/howto/nlp-python.html http:/

• paulgrahamsmom 16y ago
  As my boy would say, if you aint using lisp yous using blub, and blub programmers get a spanking!
• 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).
• thedigitalengel 16y ago
  I agree that short python samples are as clear as a high level language can possibly be. Implementing algorithms, for instance, becomes incredibly easy in Python. I face problems when Python programs get above a certain length. I've done some Django programming in the past. A view gets a request object (pardon me if I'm wrong or if this has changed recently) and is supposed to then render the response (or something similar, I don't remember exactly). Now what is a request? If Django were in C, I would know what a request object really was, grep for it, and look up the header file. If request has a GHashTable named post_data, I don't think I need two guesses about what it exactly is. Same goes for C++ and C#. Then you've inconsistencies. The same method may return a string object or an integer on different calls. And this happens in practice - I remember when I was (trying to) model a relational database in Django, I found a ManyToMany field returning (when invoking values ()) a list of dictionaries instead of a list of Model objects (which I was expecting). Of course, if I was not dumb enough to not read the documentation I might not have stumbled; but the point is that Python allows this to happen. And since I don't have the benefits of a compiler, anything other than basic syntax errors (the ones I can catch by calling py.compile) explode at runtime. The thing I've begun to notice that scripting languages tend to require you to hold the entire structure of the program in your head as you code. In C++ you know that unless you've gone out of your way to do some casting magic, a string get_foo () will always return a string. And you can always do get_foo ().c_str (). In python you're never sure.
  • loup-vaillant 16y ago
    You sound that you will like Haskell. It's type system can be really paranoid (it lets you express many invariants through it), yet remain very flexible. And If you can't fathom the segregation of (side) effects, there's still Ocaml.
    • ldsa 16y ago
      OCaml is a dying, soon obsolete, language. Better use F# which has way better libraries and tools.
      • 16y ago
• grasshoper 16y ago
  Python for me is the language closest to pseudocode. There are no decorations and few gimmicks. You simply write your ideas down into code.
  • thedigitalengel 16y ago
    The above comment applies here as well.
  • i80and 16y ago
    On the contrary, it has had decorators since Python 2.4.
    • silentbicycle 16y ago
      "decorations", not "decorators". I think it's fairly clear from context that he/she means, "not a lot of red tape", rather than a reference to specific language features.
      • i80and 16y ago
        PEP-318 (http://www.python.org/dev/peps/pep-0318/ http://www.python.org/dev/peps/pep-0318/) refers to a decorated functions as a having a decoration. Counter-edit: My response was in jest. I deliberately misinterpreted the term for humorous purposes.
  • lelele 16y ago
    > Python for me is the language closest to pseudocode. Python for me is the imperative language (with some functional features) closest to pseudocode.
• phsoftnet 16y ago
  Why doesn't anyone ever mention my favorite language, Tcl? foreach line [read stdin] { foreach word [split $line] { if [string match *ing $word] { puts $word } } }
  • sigzero 16y ago
    One reason is that people haven't looked at Tcl in a while and so they "already know" what Tcl brings to the table. There have been a lot of changes/additions to Tcl in the last couple years alone. It is a very nice and consistent...and to borrow from Ruby...FUN language to program in. The one thing that gets me is the "it's already been done" mentality. If you love Tcl then you want to create things in Tcl for the world to use. I have thrown out a couple ideas like "mailman in Tcl" or "nagios in Tcl"...but I always get "it's already been done". Sure, I could have done it anyway, but it gets your spirit down when you hit that wall. I know they have been done with other languages. Let's do it in Tcl to see if it can be done better!
    • phsoftnet 16y ago
      Yeah .. I have not faced this kind of wall until now but I get your point. The whole scripting language issue is a complicated one imo.. People want to either use 100% scripting or 100% system (i.e., C), which is not alright. Combine scripting & system according to your needs. This is why I like Tcl the most: It prevents you from using it where there might be computational bottlenecks (e.g., in algorithms). It is meant to complement C, not replace it. Anyway this is a separate thread.
  • anon_d 16y ago
    Your code sample isn't quite right. [read stdin] returns a string (not a list of strings), which is parsed as a list when you try to loop over it. The parsing breaks the string into a list of words, so the second loop is redundant. The parsing could fail if the input file isn't valid list syntax (unmatching {}'s). [split _] makes it safe. foreach word [split [read stdin]] { if [string match *ing $word] { puts $word }} I love Tcl too! Tcl is a scripting language for C, Python is less-powerful version of Lisp.
• donw 16y ago
  Don't know why, but I feel the need to contribute a shorter Ruby sample that feels closer to conventional Ruby. :) ARGF.lines.each { |line| line.split.each { |word| word.match(/ing$/) and puts word } }
  • phsoftnet 16y ago
    Equally cryptic to perl syntax imo..
• carbon8 16y ago
  The ruby examples don't behave the same as the python version since they use ARGF in place of stdin. They are also non-idiomatic. Here is a correct, idiomatic Ruby version: $stdin.read.split.each do |w| puts w if w.match(/ing$/) end or as a single 57 column line: $stdin.read.split.each { |w| puts w if w.match(/ing$/) } we can also use the match operator: $stdin.read.split.each { |w| puts w if w =~ /ing$/ } I'm inclined to assume that the other language examples are also suspect.