25 comments

[ 17.9 ms ] story [ 73.9 ms ] thread
For the Java version I would seriously consider not using JUnit 4's assertThat and instead rely on AssertJ [1].

Besides AssertJ being easier to use and IMO more elegant than Hamcrest, JUnit 5 will be removin `assertThat`.

I contemplated filing a bug/request but its more of a conversation point than an issue.

[1]: http://joel-costigliola.github.io/assertj/

According to this issue[1], JUnit5 will still allow the use of Hamcrest's 'assertThat' in the next major revision.

[1]: https://github.com/junit-team/junit5/issues/147

How is that possibly if Hamcrest isn't going to be put in?

I think you misread that bug report.

   >Closing this issue since there are no plans to include direct dependencies on third-party assertion libraries within JUnit 5.
You are probably missing the point of this exercise.
I am not. That is exactly why I did not file a bug and instead posted here.

The OP shows examples assertions using JUnit 4 and hamcrest assertThat. The OP could use the builtin assert for all I care but I sort of got the gist they were trying to show the canonical approach. This is not to critique but rather to inform.

I've never used Haskell, but it seems like everything in Haskell can be done in one line :).
It helps that everything in haskell is an expression
Everything but declarations, anyway.
Try APL/K/Q/J sometime. Anything can be done in one line. (Note: does not mean should be done in one line....)

There is something rather magical about solving almost any problem in a single line of code.

when I read that headline: "... but a B*tch ain't one!"
I'm guessing people are downvoting this comment because they don't want the Redditization of HN.

If it's any consolation, that was the first thing I thought as well. I even thought the problems would make some joke reference to the song.

However, it seems as if Werner Hett at the Berner Fachhochschule came up with this independently of Jay-Z.

Ice-T, Jay-z copied it about 10 years (probably more) later
Everyone always forgets about Brother Marquis.
I find the language percentage information (~ Java 57%, Scala 37%, Haskell 5%)[1] a bit scary (and admittedly hilarious), given that I have only serious experience with Java among the three.

[1]: http://i.imgur.com/zRwFzSC.png

That is super interesting; I would love to see how Clojure compares.
(comment deleted)
Well the 99-problems were originally in Prolog, and many have to do with list manipulation, something that Haskell has built in. Additionally, Haskell will benefit from its lazy, functional nature, which makes dynamic programming, searching, and even some data structures a little cleaner.

I haven't worked with Java in quite a while, but I imagine that it still requires a lot of boilerplate and set up for trivial things in other languages. I'm sure if C were also included it would be the most verbose.

Java does still include some boilerplate for setting up classes — though that may go away in 10 when they add scripting. However, it is a lot more terse than in 7:

  package com.shekhargulati.ninetynine_problems._02_arithmetic;

  import java.util.stream.LongStream;

  /**
   * (**) Determine whether a given integer number is prime.
   */
  public class P31 {

    public static boolean isPrime(long number) {
        return !LongStream.rangeClosed(2, Math.round(Math.sqrt(number))).anyMatch(n -> number % n == 0);
    }
  }
I was curious about this and took a look at the repositories. If you look at the Java repository and the Scala repository there seem to be a lot of additional folders as compared to the Haskell problem set. I'm sure Haskell would still come out ahead, but it's not clear that you can get an accurate picture from just looking at the amount of code as reported by github.
The github numbers are correct:

  $ find ./java8 -name \*.java | xargs wc -c | tail -1
    123903 total
  $ find ./scala -name \*.scala | xargs wc -c | tail -1
     80516 total
  $ find ./haskell -name \*.hs | xargs wc -c | tail -1
     11234 total
(comment deleted)
Maybe someone who knows more about logic programming can correct me, but it seems that these are just imperative solutions to problems designed to be solved in a logical programming context.

For example, take a look at problem 2.07 from the original 99-problems for [Prolog][1] and compare it to the [Java][2] solution in the linked repo. In Prolog, you're defining relations, so with GCD defined, you can compute the GCD (g) given two integers a and b, but you can also compute possible values for b, given a and g, for example. The Java solution doesn't allow for anything like that.

So, given the README information, I expected to see the implementations in different language platforms utilize some prolog-esque logic programming library (like core.logic for Clojure), but that isn't the case.

[1]: https://sites.google.com/site/prologsite/prolog-problems/2 [2]: https://github.com/shekhargulati/99-problems/blob/master/jav...