09
Sep
14

Popularität Programmiersprachen – 2014-08

Hallo Leute,

hier sind die Statistiken des Monats August.

Popularität der Programmiersprachen für August 2014:
(Zuwachs oder Schrumpfung in Prozent über die 13 vorherigen Monate)

Popularität Programmiersprachen 2014-08 - Rangfolge

Popularität der Programmiersprachen für August 2014:
(Statistische Zahlen zu den Sprachen)

Popularität Programmiersprachen 2014-08 - Statistische Zahlen

INFO: Die Statistiken für den September und Oktober erscheinen Anfang November.

Viel Spasz weiterhin
Falk

09
Sep
14

Popularität Programmiersprachen – 2014-07

Hallo Leute,

hier sind die Statistiken des dritten Monats.

Popularität der Programmiersprachen für Juli 2014:
(Zuwachs oder Schrumpfung in Prozent über die 13 vorherigen Monate)

Popularität Programmiersprachen 2014-07 - Rangfolge

Popularität der Programmiersprachen für Juli 2014:
(Statistische Zahlen zu den Sprachen)

Popularität Programmiersprachen 2014-07 - Statistische Zahlen

Viel Spasz weiterhin
Falk

09
Sep
14

Popularität Programmiersprachen – 2014-06

Hallo Leute,

hier sind die Statistiken des zweiten Monats. Neben der Veränderung in Prozent und den statistischen Zahlen gibt es nun noch die Veränderung des Ranges. Eine Null steht dabei für keine Veränderung im Rang, positive Zahlen für ein Aufsteigen und negative Zahlen für ein Absteigen im Rang.

Popularität der Programmiersprachen für Juni 2014:
(Zuwachs oder Schrumpfung in Prozent über die 13 vorherigen Monate)

Popularität Programmiersprachen 2014-06 - Rangfolge

Popularität der Programmiersprachen für Juni 2014:
(Statistische Zahlen zu den Sprachen)

Popularität Programmiersprachen 2014-06 - Statistische Zahlen

Viel Spasz weiterhin
Falk

07
Sep
14

Popularität Programmiersprachen – 2014-05

Hallo Leute,

da dies meine erste Veröffentlichung auf diesem Blog ist, möchte ich mich kurz vorstellen. Mein Name Falk, ich bin 38 Jahre alt, komme aus Dresden und bin gerade mit meinem zweiten Studium der Informationstechnik fertig geworden. Ab jetzt bin ich Java-Entwickler in Dresden. Ich kenne Daniel seit zwei Jahren – der Grund hierfür war Scala.

Da ich mich seit längerem mit der Popularität von Programmiersprachen beschäftige und dazu eine Statistik führe, gab es von uns die Idee, diese Statistik hier auf diesem Blog zu veröffentlichen.

Die Quelle zu dieser Statistik ist lediglich die Seite stackoverflow.com, deren Genehmigung für die Erhebung und Veröffentlichung ich mir bereits eingeholt habe. Täglich um 14:00 mitteleuropäischer Zeit wird die Anzahl an Fragen von insgesamt 54 Programmiersprachen erfasst. Mit diesen Zahlen wird dann eine Statistik erstellt. Aus den Zahlen zum monatsletzten Tag, werden die durchschnittlichen Fragen pro Sprache und Tag für den Monat errechnet. Anschlieszend wird für jede Sprache der Anteil der Fragen von allen 54 Sprachen für einen Monat berechnet. Aus diesen monatlichen Prozentangaben, über den Zeitraum von 13 Monaten, werden dann die Parameter der Regressionsgerade bestimmt. Aus der Höhendifferenz der Regressionsgerade erhält man den Zuwachs oder die Schrumpfung des Prozentanteils von allen Sprachen. In Abhängigkeit von diesem Anteil, werden Sprachen mit wenigen Fragen von der weiteren Betrachtung ausgeschlossen. Aus diesem Grund ist die Summe der Prozentanteile nicht genau Null. Die übriggebliebenen Sprachen werden nach ihrem Anteil sortiert und in einem Diagramm dargestellt. Solch ein Diagramm soll monatlich erscheinen. Zusätzlich zu diesem Diagramm soll die durchschnittliche Fragenanzahl der letzten 13 Monate pro Tag angegeben werden und für jede übriggebliebene Sprache, die durchschnittliche Fragenanzahl pro Tag (über die letzten 13 Monate), die Differenz an Fragen über diese Zeit und der prozentuale Anteil dieser Differenz gegenüber der Fragenanzahl der letzten 13 Monate.

 

Popularität der Programmiersprachen für Mai 2014:
(Zuwachs oder Schrumpfung in Prozent über die 13 vorherigen Monate)

Popularität Programmiersprachen 2014-05 - Rangfolge

Popularität der Programmiersprachen für Mai 2014:
(Statistische Zahlen zu den Sprachen)

Popularität Programmiersprachen 2014-05 - Statistische Zahlen

Für diesen Monat und für jeden Dezember, wird der Verlauf der Fragenanzahl der 54 Fragen auf stackoverflow.com in einem Diagramm dargestellt:

Popularität Programmiersprachen 2014-05 - Fragen auf stackoverflow.com (54 Sprachen)

Viel Spasz weiterhin
Falk

29
Aug
14

Casts mit zusätzlichen Bounds in Java 8

Immer wieder beschert mir Java wundervolle WTF-Momente, so auch heute. Eine Syntaxerweiterung in Java 8, die komplett an mir vorbeigegangen ist, sind Casts mit zusätzlichen Bounds:

LinkedList<String> list = new LinkedList<>();
List<String> list1 = (List & Queue) list; //OK
List<String> list2 = (List & RandomAccess) list; //ClassCastException

Die JLS schreibt dazu recht lakonisch :

If the cast operator contains a list of types – that is, a ReferenceType followed by one or more AdditionalBound terms – then all of the following must be true, or a compile-time error occurs.

Stellt sich die Frage ist, wozu das Ganze gut sein soll. Der einzige sinnvolle Anwendungsfall, den ich gefunden habe, ist die Spezifizierung zusätzlicher Interfaces bei Lambdas:

Runnable r = (Runnable & Serializable) () -> System.out.println("Serializable!");

Lambdas haben ja eigentlich keinen Typ, sie sind ein wenig wie Schrödingers Katze: Erst wenn man etwas mit ihnen anstellt – etwa die Zuweisung zu einer Variablen – entscheidet sich, was ihr Typ ist. Durch den vorgelagerten Cast wird diese Typbestimmung vorgezogen, so dass das Objekt r nicht nur Runnable, sondern auch Serializable ist, und später auch problemlos serialisiert werden kann.

Wie findet ihr dieses etwas obskure Feature? Seht ihr noch andere sinnvolle Anwendungsmöglichkeiten?

02
Jun
14

Pattern-Matching in Java 8

In Scala ist Pattern-Matching ein beliebtes Feature mit fast unbegrenzten Anwendungsmöglichkeiten. Nicht umsonst wird es oft als “switch auf Steroiden” bezeichnet. Im Rahmen eines kleinen Projekts habe ich überlegt, ob man das nicht auch in Java 8 nachbauen kann.

Man kann, mit einigen Einschränkungen. Hier einmal ein kleines Anwendungsbeispiel:

String string = ...
String s = match(string,
   StartsWith("foo", () -> "found foo..."),
   EndsWith("bar", () -> "found ...bar"),
   Contains("baz", () -> "found ...baz..."),
   EqualsIgnoreCase("blubb", () -> "found blubb"),
   Default(() -> "nix gefunden")
);
System.out.println(s);

Wie funktioniert das? Zuerst braucht man für die einzelnen Fälle ein Interface:

import java.util.Optional;

public interface Case<T,R> {
    Optional<R> accept(T value);
}

Es ist im Prinzip eine Art Funktion, die für einem Ausgangswert ein Resultat liefert, allerdings in einem Optional. Wir haben also eine Art Funktion, die eventuell etwas zurückliefert – genau dann, wenn der zu überprüfende Wert “passt”. Hier eine der verwendeten Case-Implementierungen (man verzeihe mir bitte die an Scala angelehnte Großschreibung der Methodennamen):

public static <R> Case<String, R> StartsWith(String prefix, Supplier<R> supplier) {
    return t -> t.startsWith(prefix)
            ? Optional.of(supplier.get())
            : Optional.<R>empty();
}

Wir liefern also den durch den Supplier vorgegebenen Wert (in ein Optional verpackt) zurück, aber nur, wenn der zu testende String den richtigen Präfix hat.

Die match-Methode ist auch recht unspektakulär (MatchException ist eine gewöhnliche Laufzeit-Exception):

@SafeVarargs
public static <T,R> R match(T value, Case<T,R> ... cases) throws MatchException {
    for(Case<T,R> c : cases) {
        Optional<R> result = c.accept(value);
        if (result.isPresent()) {
            return result.get();
        }
    }
    throw new MatchException();
}

Interessanterweise kann dieser Mechanismus auch die Arbeit mit Optional vereinfachen. Wenn wir einmal so tun, als hätte Optional wie in Scala die Unterklassen Some (die einen Wert enthält) und None (die “leer” ist), könnte uns das zu dieser Verwendung anregen:

Optional<Integer> opt = ...
String s = match(opt,
        None(() -> "leer"),
        Some(42, () -> "die Antwort!"),
        SomeIf(a -> "gerade", a -> a % 2 == 0),
        Default(() -> "nix gefunden")
);

Selbst “geschachteltes” Pattern-Matching ist möglich:

Optional<Optional<Integer>> opt = ...
String s = match(opt,
        None(() -> "leer"),
        Some(None(() -> "leer eingetütet")),
        Some(SomeIf(a -> "gerade", a -> a % 2 == 0)),
        Default(() -> "nix gefunden")
);

Hier die verwendeten Case-Implementierungen:

import static java.util.Optional.*;
...

public static <T,R> Case<Optional<T>,R> None(Supplier<? extends R> supplier) {
    return t -> t.isPresent()
            ? Optional.<R>empty()
            : of(supplier.get());
}

public static <T,R> Case<Optional<T>,R> Some(T value, Supplier<? extends R> supplier) {
    return t -> t.isPresent() && t.get().equals(value)
            ? of(supplier.get())
             : Optional.<R>empty();
}

public static <T,R> Case<Optional<T>,R> Some(Case<T,R> caseT) {
    return t -> t.isPresent()
            ? caseT.accept(t.get())
            : Optional.<R>empty();
}

public static <T,R> Case<Optional<T>,R> Some(Function<? super T, ? extends R> fn) {
    return t -> t.isPresent()
            ? of(fn.apply(t.get()))
            : Optional.<R>empty();
}

public static <T,R> Case<Optional<T>,R> SomeIf(Function<? super T, ? extends R> fn, Predicate<T> predicate) {
    return t -> t.isPresent() && predicate.test(t.get())
            ? of(fn.apply(t.get()))
            : Optional.<R>empty();
}

public static <T,R> Case<T,R> Default(Supplier<R> supplier) {
    return value -> of(supplier.get());
}

Ich will nicht verhehlen, dass wir hier haarscharf an den Grenzen von Javas Typ-Inferenz operieren, und auch leicht Eindeutigkeitsprobleme bei gleichnamigen statischen Methoden mit Lambda-Argumenten auftreten können. Ob diese kleine DSL wirklich “brauchbar” ist, muss sich erst noch zeigen. Spaß macht es auf jeden Fall.

07
Mai
14

Typsicheres Builder-Pattern mit Java

Der folgende Code ist eine ziemlich direkte Übersetzung des typsicheren Builder-Patterns aus Scala nach Java. Es gibt mehrere Versionen, aber mir gefällt die Variante von Daniel Sobral am besten, weil damit auch bei der “Verkabelung” im Builder weniger Fehler möglich sind. Etwas kürzer ist die ursprüngliche Version von Rafael Ferreira, aber dort ist die Zuordnung von Typparametern zu den Werten “willkürlich”, so dass man beim Builder-Schreiben eher etwas falsch machen kann.

Zuerst zu unserer zu bauenden Klasse und einem kleinen Anwendungsbeispiel:

public class Person {

  private String firstName;
  private String lastName;
  private int age;

  public Person(String firstName, String lastName, int age) {
    this.firstName = firstName;
    this.lastName = lastName;
    this.age = age;
  }

  public String getFirstName() { return firstName; }

  public String getLastName() { return lastName; }

  public int getAge() { return age; }

  @Override
  public String toString() {
    return "Person{" +
      "firstName='" + firstName + '\'' +
      ", lastName='" + lastName + '\'' +
      ", age=" + age +'}';
  }
}

...

Person person = build(NEW.withLastName("Mustermann").withAge(62).withFirstName("Heinz"));

//das compiliert *nicht*
Person person = build(NEW.withLastName("Mustermann").withAge(62));

Zentral für Daniel Sobrals Idee ist ein Wrapper-Typ mit zwei Ausprägungen (“da” und “nicht da”) für die zu sammelnden Werte. Leider hat Optional in Java 8 keine Unterklassen wie Option in Scala, deshalb brauchen wir unsere eigene kleine Hierarchie. Und dann können wir auch gleich andere Namen verwenden, die unserem Zweck eher entsprechen:

public interface Value<T> {}

public final class Without<T> implements Value<T> {
  private final static Without<?> WITHOUT = new Without<>();

  private Without(){}

  @SuppressWarnings("unchecked") 
  public static <T> Without<T> without() { 
    return (Without<T>) WITHOUT; 
  }
}

public final class With<T> implements Value<T> {
  private final T t;

  public With(T t) { this.t = t; }

  public T get() { return t; }
}

Man könnte die Without-Klasse auch hübscher (also ohne Cast) schreiben, aber mit meiner Variante kommt man mit einem einzigen Objekt aus. Nun zur eigentlichen Magie, dem Builder. Ich bitte zu beachten, dass die Klasse mit ihrem Generic-Verhau zwar ziemlich länglich aussieht, der Nutzer davon aber nichts mitbekommt (siehe Anwendungsbeispiel oben).


import static builder.Without.without;

public class PersonBuilder<FirstName extends Value<String>,
          LastName extends Value<String>,
          Age extends Value<Integer>> {

  public static final PersonBuilder<Without<String>, Without<String>, Without<Integer>> NEW =
    new PersonBuilder<Without<String>, Without<String>, Without<Integer>>(without(), without(), without());

  private FirstName firstName;
  private LastName lastName;
  private Age age;

  private PersonBuilder(FirstName firstName, LastName lastName, Age age) {
    this.firstName = firstName;
    this.lastName = lastName;
    this.age = age;
  }

  public PersonBuilder<With<String>, LastName, Age> withFirstName(String firstName) {
    return new PersonBuilder<>(new With<>(firstName), lastName, age);
  }

  public PersonBuilder<FirstName, With<String>, Age> withLastName(String lastName) {
    return new PersonBuilder<>(firstName, new With<>(lastName), age);
  }

  public PersonBuilder<FirstName, LastName, With<Integer>> withAge(int age) {
    return new PersonBuilder<>(firstName, lastName, new With<>(Integer.valueOf(age)));
  }

  public static Person build(PersonBuilder<With<String>, With<String>, With<Integer>> builder) {
    return new Person(builder.firstName.get(), builder.lastName.get(), builder.age.get());
  }
}

Das Prinzip ist trotz der Generic-Orgie recht einfach zu verstehen: Ausgehend von einem Builder mit lauter Withouts werden letztere schrittweise durch With-Typparameter mit den zugehörigen Werten ersetzt. Und nur ein Builder mit lauter With-Typparametern kann verwendet werden, um am Ende eine Person zu erzeugen (deshalb muss das auch eine statische Methode statt wie üblich eine Instanzmethode sein). Man sieht in der build-Methode, wie die Generics (im Gegensatz zu Rafael Ferreiras Version) wirklich mit den internen Werten gekoppelt sind: Nur mit With als Typparametern sind die get-Methoden verfügbar.

Natürlich erscheint der vorgestellte Code erst einmal ziemlich umfangreich. Dabei sollte man aber berücksichtigen, dass der Unterschied zu einem “normalen” Builder ohne Compilezeit-Test von erforderlichen Argumenten nicht besonders groß ist: Da die Value-Hierarchie wiederverwendet werden kann, kommen im Prinzip nur die Generics im Builder hinzu. Ich denke, wenn man sich sowieso schon dazu entschieden hat, einen Builder zu verwenden, ist es naheliegend, gleich diese Version zu verwenden, wenn es in der zu erzeugenden Klasse “Pflichtfelder” gibt.




Folgen

Erhalte jeden neuen Beitrag in deinen Posteingang.