Abo
  1. Foren
  2. Kommentare
  3. Software-Entwicklung
  4. Alle Kommentare zum Artikel
  5. › Ada und Spark: Mehr…
  6. T…

Es ist keine Frage der Programmiersprache

  1. Thema
  1. 1
  2. 2
  3. 3

Neues Thema Ansicht wechseln


  1. Re: Es ist keine Frage der Programmiersprache

    Autor: \pub\bash0r 11.06.19 - 14:26

    MrTridac schrieb:
    --------------------------------------------------------------------------------
    > Immer öfter höre und lese ich dass man "heutzutage" ja dies und jenes
    > "nicht mehr macht" weil sich ja Compiler und Runtime um alles kümmern.

    Das solltest du bitte mit konkreten Beispielen untermalen.
    Es gibt durchaus Fälle, wo das einfach mal stimmt, um das bestmögliche Ergebnis zu erzielen. Wenn ich zur Optimierung eine String-Konkatenation über Pointer Arithmetik abbilde ist das sicherlich augenscheinlich performant, verschlechtert aber die Lesbarkeit und führt potenzielle Sicherheitslücken ein. Schreibe ich hingegen eine ganz einfache Operator-Verkettete Zeile Code kümmert sich ein moderner Compiler darum, daraus den für die Situation besten Code zu erzeugen. Da der Compiler jetzt sogar versteht, dass ich da Strings zusammenbaue, kann er dieses Wissen auch in den Kontext rücken und dann entscheiden, ob jetzt memcpy, irgendein Builder Pattern, oder was auch immer geeignet ist (vlt. sind ja sogar die Längen und Inhalte schon bekannt und das kann direkt zur Compile-Time schon konkateniert oder zumindest allokiert werden). Oder ob etwas in den Stack oder auf den Heap gehört, etc. pp

    Wenn der Compiler den Kontext analysiert, vereinfacht man es dem Optimizer natürlich, den Kontext auch möglichst explizit zu machen.

  2. Re: Es ist keine Frage der Programmiersprache

    Autor: captain_spaulding 11.06.19 - 15:05

    Ich frage mich ja wie viel Realitätsabstand man haben muss, wenn man meint dass man nur gute Programmierer braucht und schon gibt es auch mit C keine Bugs.

    Die Realität ist:
    Alle C-Programmierer machen haufenweise Fehler. Fehler der Kategorie "Wäre mit Rust nicht passiert".

    Dagegen geht man aber nicht mit guten Programmierern vor, weil das aussichtslos wäre. Stattdessen gibt es Code-Analyse-Tools, Tests und Hardware, die mit fehlerhafter Software zurecht kommt.



    1 mal bearbeitet, zuletzt am 11.06.19 15:07 durch captain_spaulding.

  3. Re: Es ist keine Frage der Programmiersprache

    Autor: mnementh 11.06.19 - 15:12

    MrTridac schrieb:
    --------------------------------------------------------------------------------
    > Immer wieder lese ich diese Behauptung.
    > Aber das ist quatsch. Ich kann auch mit der besten und sichersten Sprache
    > scheiß Programme schreiben, die einen Fehler nach dem Anderen machen.
    >
    > Es ist immer einer Frage des Könnens.
    > Ein guter Programmierer schreibt in jeder Sprache gute Programme, ein
    > schlechter schreibt immer schlechte Programme egal in welcher Sprache.
    >
    > Sich auf die Fähigkeiten eines Compilers zu verlassen, Fehler zu finden
    > bzw. zu behandeln, ist fahrlässig.
    > Schon viel zu oft hab ich den Kommentar gehört: "Ich dachte da kümmert sich
    > der Compiler drum", wenn ich einen tief verborgenen Fehler aufgestöbert
    > habe.

    C ist ein Minenfeld, wo man das zehn Jahre studiert haben muss um kein verstecktes Problem einzubauen. Wer hat nur zum Beispiel diese idiotische Idee gehabt, Verhalten undefiniert zu lassen. Stichwort nasal demons.

    Bessere Sprachen könne da schon etwas verbessern. Und wenn man als Programmierer nicht zehtausend Fallstricke im Hinterkopf behalten muss, vielleicht sieht man dann auch den eigenen Fehler den man macht.

  4. Re: Es ist keine Frage der Programmiersprache

    Autor: mnementh 11.06.19 - 15:16

    carsti77 schrieb:
    --------------------------------------------------------------------------------
    > Leute wie du merken nicht mal was sie da sagen. Das Problem sind so Leute
    > Meinungsmacher wie Fefe, die noch nichtmal eine Teilschuld bei der
    > Programmiersprache (bzw. den fehlenden Zusicherungen die ein Compiler
    > machen kann) sehen.
    >
    > Und dann verbloedet es sich nicht solche Sachen zu sagen: blog.fefe.de
    >
    Vielleicht solltest den verlinkten Beitrag nochmal genauer lesen. Fefe stimmt Dir da nämlich zu, er sagt es ist eben nicht die Aufgabe des Nutzers Problem in der Software die er benutzt auszugleichen. Und ich habe ihn auch schon sicherere Programmiersprachen begrüßen sehen.



    1 mal bearbeitet, zuletzt am 11.06.19 15:17 durch mnementh.

  5. Re: Es ist keine Frage der Programmiersprache

    Autor: captain_spaulding 11.06.19 - 15:16

    mnementh schrieb:
    --------------------------------------------------------------------------------
    > C ist ein Minenfeld, wo man das zehn Jahre studiert haben muss um kein
    > verstecktes Problem einzubauen.

    Anmerkung: 10 Jahre studieren ist keinesfalls hinreichend um damit keine üblen Fehler zu machen. Man braucht noch dazu einiges an Glück oder so.

  6. Re: Es ist keine Frage der Programmiersprache

    Autor: mnementh 11.06.19 - 15:18

    captain_spaulding schrieb:
    --------------------------------------------------------------------------------
    > mnementh schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > C ist ein Minenfeld, wo man das zehn Jahre studiert haben muss um kein
    > > verstecktes Problem einzubauen.
    >
    > Anmerkung: 10 Jahre studieren ist keinesfalls hinreichend um damit keine
    > üblen Fehler zu machen. Man braucht noch dazu einiges an Glück oder so.

    "Als verantwortungsvoller Programmierer achte ich darauf meine Hasenpfote, mein vierblättriges Kleeblatt und mein Hufeisen bereitliegen zu haben, bevor ich die Entwicklungsumgebung starte."

  7. Re: Es ist keine Frage der Programmiersprache

    Autor: mnementh 11.06.19 - 15:24

    MrTridac schrieb:
    --------------------------------------------------------------------------------
    > > Oder anders gesagt: man BRAUCHT keine dieser Sprachen, um gute Software
    > zu
    > > entwickeln, aber es HILFT.
    > Problem ist, dass sich zu sehr auf diese "Hilfe" verlassen wird. Stichwort:
    > Trügerische Sicherheit.
    > Was letztenendes dazu führt, dass Tests vernachlässigt werden.
    OK, wir haben wir Fälle: guter Programmierer mit guten Werkzeugen, guter Programmierer mit schlechten Werkzeugen, schlechter Programmierer mit guten Werkzeugen, schlechter Programmierer mit schlechten Werkzeugen.

    Der gute Programmierer weiß, dass auch beim besten Werkzeug er noch aufpassen muss. Er wird qualitativ besseren Code mit dem guten Werkzeug abliefern, als mit dem schlechten. Der schlechte Programmierer hat mit dem schlechten Werkzeug Mist abgeliefert, und tut dies fortlaufend mit dem guten Werkzeug (a fool with a tool is still a fool).

    Insgesamt haben wir durch den Einsatz guter Werkzeuge nichts verloren aber in einigen Fällen etwas gewonnen.

  8. Re: Es ist keine Frage der Programmiersprache

    Autor: mnementh 11.06.19 - 15:30

    captain_spaulding schrieb:
    --------------------------------------------------------------------------------
    > Ich frage mich ja wie viel Realitätsabstand man haben muss, wenn man meint
    > dass man nur gute Programmierer braucht und schon gibt es auch mit C keine
    > Bugs.
    >
    > Die Realität ist:
    > Alle C-Programmierer machen haufenweise Fehler. Fehler der Kategorie "Wäre
    > mit Rust nicht passiert".
    >
    > Dagegen geht man aber nicht mit guten Programmierern vor, weil das
    > aussichtslos wäre. Stattdessen gibt es Code-Analyse-Tools, Tests und
    > Hardware, die mit fehlerhafter Software zurecht kommt.

    Mit anderen Worten: gute Programmierer wissen dass sie auch Fehler machen statt sich stolz auf ihre angebliche Kompetenz zu berufen. Und sie wissen daher auch, dass gutes Tooling ihnen hilft. Allerdings stehe ich auf dem Standpunkt, dass man seine verwendeten Tools auch verstehen sollte und wissen was sie tun und nicht tun.

  9. Re: Es ist keine Frage der Programmiersprache

    Autor: \pub\bash0r 11.06.19 - 15:33

    mnementh schrieb:
    --------------------------------------------------------------------------------
    > Mit anderen Worten: gute Programmierer wissen dass sie auch Fehler machen
    > statt sich stolz auf ihre angebliche Kompetenz zu berufen. Und sie wissen
    > daher auch, dass gutes Tooling ihnen hilft. Allerdings stehe ich auf dem
    > Standpunkt, dass man seine verwendeten Tools auch verstehen sollte und
    > wissen was sie tun und nicht tun.

    Dagegen sagt hier niemand - auch nicht im Artikel - etwas. Es wird lediglich ein weiteres Werkzeug mit bestimmten Eigenschaften vorgestellt. Der Thread kritisiert aber bereits die Existenz des Werkzeugs. DAS ist der Streitpunkt. Denn wie du ja selbst schreibst: die Werkzeuge sind nicht das Problem sondern helfen allenfalls bei der Lösung.

  10. Re: Es ist keine Frage der Programmiersprache

    Autor: captain_spaulding 11.06.19 - 15:41

    Ich sehe das ganze eher nicht von Programmierer-Seite.
    Wenn ich sichere Software brauche, werde ich möglichst eine Umgebung schaffen, in der Fehler unwahrscheinlicher sind.
    Das hat sich einfach besser bewährt als "Ich benutze blankes C und hoffe darauf dass die perfekten Programmierer keine Fehler machen".

  11. Re: Es ist keine Frage der Programmiersprache

    Autor: \pub\bash0r 11.06.19 - 16:05

    captain_spaulding schrieb:
    --------------------------------------------------------------------------------
    > Ich sehe das ganze eher nicht von Programmierer-Seite.
    > Wenn ich sichere Software brauche, werde ich möglichst eine Umgebung
    > schaffen, in der Fehler unwahrscheinlicher sind.
    > Das hat sich einfach besser bewährt als "Ich benutze blankes C und hoffe
    > darauf dass die perfekten Programmierer keine Fehler machen".

    Das klingt auch nicht sehr hilfreich. Geh doch zu den Profis (den guten Entwicklern die du angeheuert hast), gib ihnen deine Anforderungen, und lass dich beraten und einige dich mit ihnen. Wenn du ein Team von Senior C Developern hast, die die Sprache und Toolchain in und auswendig kennen weil sie seit 20 Jahren nix anderes machen und darin aufgehen, würdest du deinem Projekt einen Bärendienst erweisen, wenn du denen jetzt gegen ihr Empfehlung vorschreibst, Rust, Go oder sonstwas zu nehmen, weil es deiner Meinung nach sicherer ist.

    Wenn du natürlich nur mit Junior Devs arbeitest die dir dann sagen, dass sie deswegen C nehmen, weil das die ganzen Hacker da draußen tun, dann .... hol dir bitte Senior Devs dazu. Allerdings entscheide sowas auf gar keinen Fall ohne die "Programmierer-Seite". Management Entscheidungen ohne Experteninput tendieren dazu, katastrophale Ergebnisse zu erzielen mit denen keiner der Beteiligten zufrieden ist.

  12. Re: Es ist keine Frage der Programmiersprache

    Autor: caldeum 11.06.19 - 16:27

    \pub\bash0r schrieb:
    --------------------------------------------------------------------------------
    > captain_spaulding schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Ich sehe das ganze eher nicht von Programmierer-Seite.
    > > Wenn ich sichere Software brauche, werde ich möglichst eine Umgebung
    > > schaffen, in der Fehler unwahrscheinlicher sind.
    > > Das hat sich einfach besser bewährt als "Ich benutze blankes C und hoffe
    > > darauf dass die perfekten Programmierer keine Fehler machen".
    >
    > Das klingt auch nicht sehr hilfreich. Geh doch zu den Profis (den guten
    > Entwicklern die du angeheuert hast), gib ihnen deine Anforderungen, und
    > lass dich beraten und einige dich mit ihnen. Wenn du ein Team von Senior C
    > Developern hast, die die Sprache und Toolchain in und auswendig kennen weil
    > sie seit 20 Jahren nix anderes machen und darin aufgehen, würdest du deinem
    > Projekt einen Bärendienst erweisen, wenn du denen jetzt gegen ihr
    > Empfehlung vorschreibst, Rust, Go oder sonstwas zu nehmen, weil es deiner
    > Meinung nach sicherer ist.
    Wer 20 Jahre lang mit ein- und derselben Sprache seine Programme schreibt, hat es aber auch verpasst, seinen Horizont zu erweitern und ist erfolgreich ewiggestrig geworden. Ich bin selbst in erster Linie C-Programmierer und kenne die Gefahren, Vorzüge und Nachteile dieser Sprache mittlerweile ganz gut und kann auch bei mir im Unternehmen gut sehen, warum ausgerechnet Rust die Systementwickler anzieht. Ich sage mal dass die Hälfte unserer C-Entwickler nicht für diese Sprache (C) geeignet ist. Sie kennen zwar die Fallstricke aber vergessen diese oft. Ob aus Schusseligkeit oder fehlender Konzentration weiß ich ehrlichgesagt nicht. Die Leute, die schon mit C kein Problem hatten, werden mit Rust wohl auch keine kriegen. Und die die eh schon dauernd free, ref und unref versemmelt haben, würden mit Rust praktisch bessere Programme schreiben.



    1 mal bearbeitet, zuletzt am 11.06.19 16:28 durch caldeum.

  13. Re: Es ist keine Frage der Programmiersprache

    Autor: \pub\bash0r 11.06.19 - 16:45

    caldeum schrieb:
    --------------------------------------------------------------------------------
    > Wer 20 Jahre lang mit ein- und derselben Sprache seine Programme schreibt,
    > hat es aber auch verpasst, seinen Horizont zu erweitern und ist erfolgreich
    > ewiggestrig geworden. Ich bin selbst in erster Linie C-Programmierer und
    > kenne die Gefahren, Vorzüge und Nachteile dieser Sprache mittlerweile ganz
    > gut und kann auch bei mir im Unternehmen gut sehen, warum ausgerechnet Rust
    > die Systementwickler anzieht. Ich sage mal dass die Hälfte unserer
    > C-Entwickler nicht für diese Sprache (C) geeignet ist. Sie kennen zwar die
    > Fallstricke aber vergessen diese oft. Ob aus Schusseligkeit oder fehlender
    > Konzentration weiß ich ehrlichgesagt nicht. Die Leute, die schon mit C kein
    > Problem hatten, werden mit Rust wohl auch keine kriegen. Und die die eh
    > schon dauernd free, ref und unref versemmelt haben, würden mit Rust
    > praktisch bessere Programme schreiben.

    Ok, das "nix anderes machen" hätte ich mir schenken sollen. Das dürfte keinem Senior passieren (mMn). Siehe mein Post weiter oben bezüglich "Tellerrand".
    Der Punkt bleibt aber: wenn die Profis dir raten, eine "alte" Technologie einzusetzen, weil sie begründet an der Stelle gut ist, dann hör auf sie. Sonst bist du einfach nur derjenige, der einem Trend hinterherhüpft, auch wenn er an dieser Stelle wohl nicht gerechtfertigt ist.

    Es gibt z.B. gute Gründe, Java einzusetzen (bestehenden Code pflegen, SOAP, was auch immer), es gibt aber auch schlechte Gründe (wir haben nur Java Entwickler, Java ist Standard, etc. pp)

    Zugegebener Maßen kann je nach Constraints "wir können nix anderes" ein valider Grund sein. Allerdings sind Projekte mit solchen Constraints ohnehin für'n Po und können halt nur "bestmöglich" aber eben nicht "gut" oder gar "perfekt" umgesetzt werden.

  14. Re: Es ist keine Frage der Programmiersprache

    Autor: Quantium40 11.06.19 - 18:04

    mnementh schrieb:
    > "Als verantwortungsvoller Programmierer achte ich darauf meine Hasenpfote,
    > mein vierblättriges Kleeblatt und mein Hufeisen bereitliegen zu haben,
    > bevor ich die Entwicklungsumgebung starte."
    Ohne Segnung des Entwicklungsrechners mit dem Blut einer Jungfrau und rituellem Nackttanz bei Mondlicht vor jedem 7 Compilevorgang ist das trotzdem als hochgradig nachlässiges Verhalten zu betrachten.

  15. Re: Es ist keine Frage der Programmiersprache

    Autor: Steffo 11.06.19 - 20:49

    Viele die eine Weile in Rust entwickeln erzählen hinterher, dass sie dadurch bessere Entwickler geworden sind, weil Rust sie zu besserem Code gezwungen hat.

  16. Re: Es ist keine Frage der Programmiersprache

    Autor: captain_spaulding 11.06.19 - 21:11

    \pub\bash0r schrieb:
    --------------------------------------------------------------------------------
    > Der Punkt bleibt aber: wenn die Profis dir raten, eine "alte" Technologie
    > einzusetzen, weil sie begründet an der Stelle gut ist, dann hör auf sie.
    > Sonst bist du einfach nur derjenige, der einem Trend hinterherhüpft, auch
    > wenn er an dieser Stelle wohl nicht gerechtfertigt ist.
    >
    > Es gibt z.B. gute Gründe, Java einzusetzen (bestehenden Code pflegen, SOAP,
    > was auch immer), es gibt aber auch schlechte Gründe (wir haben nur Java
    > Entwickler, Java ist Standard, etc. pp)
    >
    > Zugegebener Maßen kann je nach Constraints "wir können nix anderes" ein
    > valider Grund sein. Allerdings sind Projekte mit solchen Constraints
    > ohnehin für'n Po und können halt nur "bestmöglich" aber eben nicht "gut"
    > oder gar "perfekt" umgesetzt werden.

    Ich bin selbst Profi mit 10 Jahren C-Erfahrung. Natürlich werden mir Leute, die immer C verwendet haben C empfehlen.
    Und man kann auch nicht aus einem Team von 50 C-Experten mal eben Rust-Experten machen. Wahrscheinlich wollen die das nicht mal.

    Es gibt viele gute Gründe C zu benutzen. Grund Nummer 1 ist bestehender Code, dicht gefolgt von Portierbarkeit und auf vielen Plattformen hat man eben nur die Wahl zwischen C und Assembler.

    Aber Sicherheit gehört auf keinen Fall dazu! Auch wenn die Experten sagen dass sie keine Fehler machen und wenn man ein Analyse-Tool über ihren Code laufen lässt bekommt man eine Liste mit hunderten potenziellen Fehlern. Wäre bei meinem Code genauso, also behaupte ich es gar nicht erst.

  17. Re: Es ist keine Frage der Programmiersprache

    Autor: ML82 11.06.19 - 23:24

    \pub\bash0r schrieb:
    --------------------------------------------------------------------------------
    > Aber Abstraktion spart Zeit
    > und damit Geld und macht es einfacher [...]

    liefert das ergebnis dem verwendetem kompiler auf gedeih und verderb aus, unabhängiger ist anders geschrieben.

  18. Re: Es ist keine Frage der Programmiersprache

    Autor: ML82 11.06.19 - 23:35

    warum soll ein member/type set nicht nach einander zwei typekonforme werte zugewiesen werden, klar macht das so keinen sinnen sinn, mit x zu belegen kann man sich sparen wenn danach immer mit y belegt wird, dass das nen typo in der angabe des members typesets sein könnte währe intelligent, nur ist das keine maschiene die ich kenne ...

  19. Re: Es ist keine Frage der Programmiersprache

    Autor: ML82 11.06.19 - 23:37

    das sagen 1, 2, viele über z.b. python auch ...

    die eigentliche frage für nicht eigebildete ist:

    unterstützt meine umgebung heute, morgen und übermorgen xyz-kacke, wie verbreitet ist diese kacke, wie lange wird diese kacke halten/wieviel aufand gibt es in der pflege ... essentiel: tut das weh und kann man das essen?!



    3 mal bearbeitet, zuletzt am 11.06.19 23:45 durch ML82.

  20. Re: Es ist keine Frage der Programmiersprache

    Autor: twothe 12.06.19 - 10:50

    Das ist immer eine Frage der Herangehensweise. Mein Chef sagt beispielsweise auch immer: "Einfach mal keine Fehler machen, dann passiert so was auch nicht." Hat er auch völlig Recht.
    Meine Theorie ist aber: Ich mache ständig Fehler und übersehe auch ständig welche, also sollte ich doch meine Werkzeuge so designen, dass sie mir möglichst viele Fehler im Vorhinein schon aufzeigen.

    Man kann natürlich in jeder Programmiersprache so arbeiten, dass man möglichst wenig Fehler benutzt, aber dann muss man eben auch auf viele Features verzichten. Wer sich beispielsweise mit den Features von JavaScript austobt, kann sehr schnell Code schreiben, der selbst gute Programmierer schnell mental überfordert. Leider haben aber Tests ergeben, dass die meisten Programmierer ihr Können massiv überschätzen. So ein Code führt also im Regelfall zu viel mehr Fehlern, als ein simpler, "dummer" Code.

    Aus der Konsequenz heraus hat sich nicht ohne Grund TypeScript in der JS-Welt durchgesetzt.

  1. Thema
  1. 1
  2. 2
  3. 3

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Dürr Systems AG, Bietigheim-Bissingen
  2. Berliner Verkehrsbetriebe (BVG), Berlin
  3. Techniker Krankenkasse, Hamburg
  4. ZIEHL-ABEGG SE, Künzelsau

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. 127,99€ (Bestpreis!)
  2. 349,00€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Ryzen 3900X/3700X im Test: AMDs 7-nm-CPUs lassen Intel hinter sich
Ryzen 3900X/3700X im Test
AMDs 7-nm-CPUs lassen Intel hinter sich

Das beste Prozessor-Design seit dem Athlon 64: Mit den Ryzen 3000 alias Matisse bringt AMD sehr leistungsstarke und Energie-effiziente CPUs zu niedrigen Preisen in den Handel. Obendrein laufen die auch auf zwei Jahre alten sowie günstigen Platinen mit schnellem DDR4-Speicher.
Ein Test von Marc Sauter

  1. Ryzen 3000 BIOS-Updates schalten PCIe Gen4 für ältere Boards frei
  2. Mehr Performance Windows 10 v1903 hat besseren Ryzen-Scheduler
  3. Picasso für Sockel AM4 AMD verlötet Ryzen 3400G für flottere iGPU

FPM-Sicherheitslücke: Daten exfiltrieren mit Facebooks HHVM
FPM-Sicherheitslücke
Daten exfiltrieren mit Facebooks HHVM

Server für den sogenannten FastCGI Process Manager (FPM) können, wenn sie übers Internet erreichbar sind, unbefugten Zugriff auf Dateien eines Systems geben. Das betrifft vor allem HHVM von Facebook, bei PHP sind die Risiken geringer.
Eine Exklusivmeldung von Hanno Böck

  1. HHVM Facebooks PHP-Alternative erscheint ohne PHP

Dr. Mario World im Test: Spielspaß für Privatpatienten
Dr. Mario World im Test
Spielspaß für Privatpatienten

Schlimm süchtig machendes Gameplay, zuckersüße Grafik im typischen Nintendo-Stil und wunderbare Dudelmusik: Der Kampf von Dr. Mario World gegen böse Viren ist ein Mobile Game vom Feinsten - allerdings nur für Spieler mit gesunden Nerven oder tiefen Taschen.
Von Peter Steinlechner

  1. Mobile-Games-Auslese Ein Wunderjunge und dreimal kostenloser Mobilspaß
  2. Mobile-Games-Auslese Magischer Dieb trifft mogelnden Doktor
  3. Hyper Casual Games 30 Sekunden spielen, 30 Sekunden Werbung

  1. Streaming: Netflix' Kundenwachstum geht zurück
    Streaming
    Netflix' Kundenwachstum geht zurück

    Netflix hat im zweiten Quartal die eigenen Erwartungen verfehlt. Auch der Gewinn fiel niedriger aus als im Vorjahresquartal.

  2. Coradia iLint: Alstoms Brennstoffzellenzüge bewähren sich
    Coradia iLint
    Alstoms Brennstoffzellenzüge bewähren sich

    Zwei Züge, 100.000 Kilometer, keine Probleme: Nach zehn Monaten regulärem Einsatz in Niedersachsen ist das französische Unternehmen Alstom zufrieden mit seinen Brennstoffzellenzügen.

  3. Matternet: Schweizer Post pausiert Drohnenlieferungen nach Absturz
    Matternet
    Schweizer Post pausiert Drohnenlieferungen nach Absturz

    Blutkonserven oder Gewebeproben müssen unter Umständen schnell zu ihrem Bestimmungsort gebracht werden. Die Schweizer Post setzt für solche Transporte Drohnen ein. Doch nach vielen problemlosen Flüge ist ein Copter abgestürzt. Das Drohnenprogramm wurde daraufhin vorerst gestoppt.


  1. 23:00

  2. 19:06

  3. 16:52

  4. 15:49

  5. 14:30

  6. 14:10

  7. 13:40

  8. 13:00