Sinn von Lambdas?

[Bela B.]

Ich verstehe ehrlich gesagt nicht, was an Lambdas so besonders sein soll? Irgendwie erschließt sich mir nicht, was man damit besser/eleganter machen kann als mit "normalem" Code.

Kann mich da vielleicht einer von euch aufschlauen oder ist eurer Meinung nach das Verstehen von Lambdas nicht (so) wichtig?

 

[mrBrown]

Mein Lieblingsbeispiel: Entfernen von Elementen mit bestimmten Eigenschaften aus einer Liste.

Wie würdest du das ohne Lambdas umsetzen?

Spoiler

ints.removeIf(i -> i != 42)

 

[Thallius]

Int Index = 0;
while (index < ints.size())
{
   If (ints.get(Index) != 42)
        Ints.remove(index);
    else
        index++;
}

 

[Meniskusschaden]

Ja, der Vergleich zeigt den Nutzen ziemlich eindrucksvoll.

 

[Thallius]

Ja, der Vergleich zeigt den Nutzen ziemlich eindrucksvoll.

Stimmt in dem Fall finde ich die Lambas auch fein.

Aber aber in vielen Fällen sind diese Verkürzungen alles nur nicht hilfreich. Nehmen wir mal Annotations und Beans. Hier werden durch irgendwelche „Magic Keys“ komplette Code Teile ersetzt und kaum einer der Programmierer die diese benutzen weiß eigentlich was da passiert. So etwas finde ich nicht hilfreich und auch nicht fortschrittlich. Sowas finde ich gefährlich...

 

[mrBrown]

Annotations und Beans (was meinst du damit überhaupt) haben allerdings nichts mit Lambdas am Hut.

Erstere sind *das* Ding für jegliches Framework, auf die will ich absolut nicht verzichten.
Das ein Programmierer noch alles in's kleinste Detail überblickt ist sowieso Wunschdenken

 

[Thallius]

Annotations und Beans (was meinst du damit überhaupt) haben allerdings nichts mit Lambdas am Hut.

Erstere sind *das* Ding für jegliches Framework, auf die will ich absolut nicht verzichten.
Das ein Programmierer noch alles in's kleinste Detail überblickt ist sowieso Wunschdenken

Genau wie du sagst Wunschdenken. Also wünscht man sich das. Warum sollte man also nicht versuchen dem zumindest so nahe wie möglich zu kommen?
Statt dessen geht die aktuelle Entwicklung genau in die andere Richtung. Einfach weil es billiger in der Entwicklung ist. Das ist genau wie alles andere in der heutigen globalen Welt. Billig muss es sein. Nicht gut. Also schreiben wir Software indem wir Module zusammen klicken von denen wir nicht den Ansatz einer Ahnung haben was sie machen, von denen wir nur 10% brauchen und welche wir nur sehr schwer an individuelle Verhältnisse anpassen können.
Das Ergebnis ist total überladene, inperformante software mt grauenhafter Usability.
Das macht wirtschaftlich auf den ersten Blick Sinn, denn man spart bei der Entwicklung der Software sehr viel Geld. Leider bedenkt keiner, dass wenn ich bei der Entwicklung ein paar Millionen spare dann aber hunderte von Millionen verschwende weil meine Tausende von Angestellten die diese Software nutzen bei jedem Klick auf einen Button 30s nutzlos auf eine Reaktion warten, ich irgendwo einen Denkfehler habe...

Aber da werden wir beide uns sowieso nie einig werden. Du bist halt anders gepolt...

 

[mrBrown]

Genau wie du sagst Wunschdenken. Also wünscht man sich das. Warum sollte man also nicht versuchen dem zumindest so nahe wie möglich zu kommen?

Oder anders gesagt, eine Sichtweise, die nichts mit Tatsachen zu tun hat.

Man kann ein paar Tausend Zeilen nicht mehr als einzelner im Detail überblicken - wohlgemerkt ein paar tausend Zeilen unter Nutzung eines Frameworks mit ein paar hunderttausend.

Oder wie stellst du dir das vor?

Statt dessen geht die aktuelle Entwicklung genau in die andere Richtung. Einfach weil es billiger in der Entwicklung ist. Das ist genau wie alles andere in der heutigen globalen Welt. Billig muss es sein. Nicht gut.

Modularisierung, Encapsulation und Information Hiding sind seit Jahrzehnten Grundprinzipen von Softwareentwicklung. Nicht weil sie billig sind, sondern weil sie gut sind.

Also schreiben wir Software indem wir Module zusammen klicken von denen wir nicht den Ansatz einer Ahnung haben was sie machen, von denen wir nur 10% brauchen und welche wir nur sehr schwer an individuelle Verhältnisse anpassen können.
Das Ergebnis ist total überladene, inperformante software mt grauenhafter Usability.

Schlechte Software hat nichts mit Modularisierung zu tun, eher das Gegenteil ist das Problem, sondern mit schlechten Entwicklern.

Das macht wirtschaftlich auf den ersten Blick Sinn, denn man spart bei der Entwicklung der Software sehr viel Geld. Leider bedenkt keiner, dass wenn ich bei der Entwicklung ein paar Millionen spare dann aber hunderte von Millionen verschwende weil meine Tausende von Angestellten die diese Software nutzen bei jedem Klick auf einen Button 30s nutzlos auf eine Reaktion warten, ich irgendwo einen Denkfehler habe...

Stattdessen lieber Software, die ein einzelner noch vollständig überblicken kann, die deshalb aber genau einen Knopf ohne Funktion hat, der aber immerhin schnell reagiert?

 

[Thallius]

Oder anders gesagt, eine Sichtweise, die nichts mit Tatsachen zu tun hat.

Man kann ein paar Tausend Zeilen nicht mehr als einzelner im Detail überblicken - wohlgemerkt ein paar tausend Zeilen unter Nutzung eines Frameworks mit ein paar hunderttausend.

Oder wie stellst du dir das vor?


Modularisierung, Encapsulation und Information Hiding sind seit Jahrzehnten Grundprinzipen von Softwareentwicklung. Nicht weil sie billig sind, sondern weil sie gut sind.


Schlechte Software hat nichts mit Modularisierung zu tun, eher das Gegenteil ist das Problem, sondern mit schlechten Entwicklern.


Stattdessen lieber Software, die ein einzelner noch vollständig überblicken kann, die deshalb aber genau einen Knopf ohne Funktion hat, der aber immerhin schnell reagiert?

Wie ich schon sagte wir werden nie auf einen Nenner kommen. Solange ich aber überdurchschnittlich gut bezahlt werde für meine schlechte Software die nur einen Knopf ohne Funktion hat, diese aber Software ersetzt die von Leuten wie dir geschrieben wurden weil die User damit absolut unzufrieden sind, solange ist die Welt für mich noch in Ordnung. Und du darfst gerne auch weiter in deiner Welt programmieren denn du sorgst ja damit dafür dass ich immer neue Aufträge bekommen.

Achja und vielleicht sollte ich dafür einfach mal Danke sagen....

 

[mrBrown]

Ernstgemeinte Frage: wie viele Zeilen kannst du noch im Detail überblicken und was für Programme werden das, für die du weder Framework noch Library nutzt?

 

[Thallius]

Also mein aktuelles Projekt ist eine komplette wartungsplanungs Software im medizintechnschen Bereich für ganz Europa. Größenordnung weis ich gerade nicht aber gepackt sind die Sourcen ca. 35MB. Entwiclungszeit bisher ca. Ein halbes Mannjahr.

Geschrieben in JQuery als Frontend und PHP als Webservice für die Oracle DB ohne jegliches Framework.

Du kannst gerne mal vorbei kommen und dir die Software ansehen....

 

[mrBrown]

Du kannst also 35MB an Sourcen im Detail überblicken? Respekt...

Geschrieben in JQuery als Frontend und PHP als Webservice für die Oracle DB ohne jegliches Framework.

Allerdings drei Dinge, deren Interna du nicht kennst, sondern einfach nur nach Contract nutzt...

 

[Flown]

Kann mich da vielleicht einer von euch aufschlauen oder ist eurer Meinung nach das Verstehen von Lambdas nicht (so) wichtig?

Lambdas sind nichts weiter als Implementierungen von SAM-Interfaces (Single-abstract-method). Dies wird dann verwendet um den Boileplatecode zu verkleinern:

Runnable r = () -> doSomething();
//oder
Runnable r = this::doSomething;
//vs.
Runnable r = new Runnable() {
  public void run() {
    doSomething();
  }
}

Weiter gedacht ermöglicht es Verhalten (also Implementierungen) leichter und übersichtlicher zu übergeben (wie z.B. Stream-API). Was jetzt noch zusätzlich hinzukommt ist, dass die JVM jetzt auch under-the-hood Optimierungen durchführen kann (z.B. Objectpool, Inlining, etc.).

Um jetzt nochmal auf die Stream-API einzugehen: Diese ermöglicht dir einen Workflow zu erstellen, der dir sagt was gemacht wird und nicht wie es gemacht wird. Beispiel von oben:

List<Integer> ints = ...;
List<Integer> filtered = new ArrayList<>();
for (int i : ints) {
  if (i == 42) {
    filtered.add(i);
  }
}

Erläuterung: Hier wird explizit mit einer for-Schleife iteriert, eine Implementierung für List (eine ArrayList) angegeben und dieser Code lässt sich nur mit Mehraufwand parallelisieren.

List<Integer> filtered = ints.stream().filter(i -> i == 42).collect(Collectors.toList());

Erläuterung: Hier wird angegeben, dass es sich um einen Stream handelt, das alle Elemente auf ein bestimmtes Predikat getestet und dann in eine Liste gesammelt ird.
Das lest sich fast wie ein Satz und man kann einfach ein parallel() reinwerfen und schon passiert die Magie .

Es gibt sehr viele Einsatzgebiete, wo Lambdas eingesetzt werden könnten, aber da das in der Sprache Java leider noch nicht so lange vorhanden ist, wird es noch eine Weile dauern, bis das Umdenken bei allen Frameworks und Entwickler angekommen ist.

Wie würdest du das ohne Lambdas umsetzen?

for(Iterator<Integer> iterator = ints.iterator(); iterator.hasNext();) {
  if (iterator.next() != 42) iterator.remove();
}

 

[Bela B.]

Danke schon mal an alle! Ich wollte damit jetzt übrigens keinen Glaubenskrieg auslösen

Habe erst kürzlich das Kapitel Lambdas im Buch "Der Weg zum Java-Profi" durchgearbeitet und da wurde mir jetzt nicht so klar, was daran so extrem toll sein soll.

Mit den ganzen Umwegen beim Exception-Handling erschien mir das irgendwie suspekt.

Bei der Liste macht das deutlich mehr Sinn. So 100% verstehen tue ich die Syntax allerdings noch nicht
Aus diesem Grund fällt es mir daher aktuell auch schwer, selbst Einsatzgebiete dafür zu finden, damit ich mir die Sache ein bisschen aneignen kann.

 

[Flown]

So 100% verstehen tue ich die Syntax allerdings noch nicht

Es ist ganz einfach:

i -> i == 42;
// <=>
(i) -> i == 42;
// <=>
(Integer i) -> i == 42;
// <=>
(Integer i) -> {
  return i == 42;
}
// <=>
new Predicate<Integer>() {
  @Override
  public boolean test(Integer i) {
    return i == 42;
  }
}

(Liste von Parameter) -> Statement
Parameter können mit Typ angeführt werden, einzelne Parameter können mit () umgeben werden.

Was du hier siehst sind alles äquivalente Ausprägungen und letzteres ware vorher der way-to-go.

 

[MiMij]

Was ich sehr praktisch finde bei den Lambdas ist vor allem der Gebrauch bei zb Listen

final List<XYZ> listConverted= new ArrayList<>();
allPrograms.forEach(program -> listConverted.add(convertList(program)));

oder sowas hier

Collections.sort(list, (a, b) -> b.compareTo(a));

statt

Collections.sort(list, new Comparator<Integer>() {
    @Override
    public int compare(Integer a, Integer b) {
        return b.compareTo(a);
    }
})

 

[Flown]

Was ich sehr praktisch finde bei den Lambdas ist vor allem der Gebrauch bei zb Listen
oder sowas hier

Erstes Snippet würde ich mit Folgendem lösen:

List<XYZ> listConverted = allPrograms.stream().map(this::convertList).collect(Collectors.toList());