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 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.
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.
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.
25 comments
[ 17.9 ms ] story [ 73.9 ms ] threadBesides 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/
[1]: https://github.com/junit-team/junit5/issues/147
I think you misread that bug report.
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.
There is something rather magical about solving almost any problem in a single line of code.
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.
[1]: http://i.imgur.com/zRwFzSC.png
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.
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...