TOP 5 HIGHEST GEEK QUOTIENT HACKER NEWS COMMENTS FROM THE LAST MONTH
- Comment by thristian
A colleague was telling me yesterday that the official Apache Tomcat packages for CentOS/RHEL keep all their runtime temporary files in /usr/share/tomcat; that's the sort of thing that would never be allowed in a Debian package (runtime state belongs in /var). Another example: The Debian packaging guidelines demand that every executable have a man page available, even if the upstream project doesn't supply one. They're not always as complete and comprehensive as one might hope, but they're often enough to give you the general gist of what a command is supposed to do, and how to use it. Yet another example: Debian has an 'alternatives' system, by which you can configure the system and tell it that your preferred terminal emulator is 'xterm', your preferred text-editor is pico, etc. (this extends to man pages too - if you make "x-terminal-emulator" point at xterm, then "man x-terminal-emulator" will give you the xterm man page). Every package that Debian ships that is able to spawn a terminal emulator in some way is required to launch x-terminal-emulator rather than hard-coding xterm or rxvt or whatever. The downside to all this is that if you know how to configure/administer package X on RedHat or FreeBSD, you might get lost trying to find where the package keeps its stuff in Debian. The upside is that if you know how to configure/administer package X on Debian, you should find it pretty easy to configure/administer packages Y and Z as well. One more example: The last time I installed fetchmail on RedHat, I wound up having to create /root/.fetchmailrc and write my own cronjob to run it. The last time I installed fetchmail on Debian, it already came with an /etc/init.d script that would do all the periodic checking for me, all I had to do was create an "/etc/fetchmailrc" file (like any other system service) and start it up (like any other system service). Debian's integration goes far, far beyond any other distro I've seen.
- Comment by therockhead
I dont believe Duck typing and type inference are really the same thing.For duck typing the type is unimportant, it only cares about the operation, types matter for type inference. The behavior of structural typing in languages such as Scala are is closer to Duck typing IMHO.
- Comment by Dn_Ab
Excellent point there are many types of polymorhism (hehe) ad hoc, subtype etc. As a functional programmer when I hear polymorphism I default to parametric polymorphism. This guy is not talking about polymorphism at all but instead the limitation of late binding via dyanmic/single dispatch.
- Comment by briancarper
Many huge Java frameworks are painfully over-complex, but personally I make good use of a lot of "tiny" Java libraries. e.g. if I want to calculate an MD5 checksum or pluralize a word, there's usually a bit of Java out there for that already. Joda-Time is a good example of a clean Java library that's fairly painless to use from Clojure. And then sometimes people have written Clojure wrappers around Java frameworks. Ring/Compojure as a thin layer over Java servlets is a good example. clojure.contrib.sql is a thin wrapper around JDBC, so that Clojure can already talk to a wide variety of databases. In that case you get the benefit of a solid codebase as well as the benefit of a clean Lispy interface. Not sure how much more you could ask for. It would likely take years to reproduce all of that work in pure Clojure.
- Comment by rikthevik
I just cannot imagine that if you write something in 20 lines in any language I cannot write that in 40 lines in Java Try lisp. Hell, try Python or Ruby. You may be surprised. That being said, if you are determined to write Java-esque code in other languages, I'm certain you won't reduce the number of lines greatly
How does the scoring work?
We took a corpus of 25k Hacker News comments, and turned it into a matrix of comments and words. For example, Scala occurred in our corpus 88 times, in 59 distinct comments. Those 59 comments contained a total of 695 distinct words. Those 695 words have some relationship to 'Scala', and by analyzing in bulk across the 40k words in the corpus we were able to extract rich relationships. For example, we know that 'Scala' is close to 'Clojure', and to continue the example, when we put 'Scala' into a total of 4 clusters, it shared 3 of them with 'Clojure'. Then we used a seed of words that occurred frequently in the corpus, which we considered reasonably technical:
- CS
- Clojure
- Debian
- Haskell
- JavaScript
- Python
- Rails
- Scala
- algorithm
- compiler
- engineer
- frameworks
- jQuery
- macros
- open-source
- process
- servers
- stack
We took the centroid clusters of these 18 words, and compared each of the 40k words in the corpus to that centroid in order to compute a word score. Since 'Scala' was itself a member of the corpus, it was very close to the center, and received a high score. A less technical word like 'war' or 'government' or 'contrary' was much further away from our seed of technical words, and was assigned a low score. To compute comment scores we just viewed each comment as a collection of words. In fact, we exposed a Free-Form Geek Quotient Scorer that uses the same algorithm.
We have two dynamic goodies to share: