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

Es ist keine Frage der Programmiersprache

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

Neues Thema Ansicht wechseln


  1. Es ist keine Frage der Programmiersprache

    Autor: MrTridac 11.06.19 - 12:56

    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.

  2. Re: Es ist keine Frage der Programmiersprache

    Autor: \pub\bash0r 11.06.19 - 13:09

    Einige Sprachen machen es dir sehr leicht, beschissenen Code zu schreiben (C), andere machen es dir deutlich schwerer (Rust).
    Wenn das Ziel von einem Entwickler ist, gute, sichere Software zu schreiben, ist es - unabhängig von seinem Können - in seinem Interesse, eine Sprache zu haben, die ihn dabei unterstützt.
    Man greift ja auch so gut wie nicht mehr zu Assembler, obwohl man damit natürlich ebenfalls jedes Problem lösen kann. Aber Abstraktion spart Zeit und damit Geld und macht es einfacher, überhaupt noch zu verstehen, was da an Code vor einem liegt, was wiederum Reviews vereinfacht und damit die Sicherheit erhöht.

    Oder anders gesagt: man BRAUCHT keine dieser Sprachen, um gute Software zu entwickeln, aber es HILFT. Und genau darum geht es doch bei Werkzeugen, oder?

  3. Re: Es ist keine Frage der Programmiersprache

    Autor: Enyaw 11.06.19 - 13:14

    ++ gut zusammengefasst

  4. Re: Es ist keine Frage der Programmiersprache

    Autor: Das Osterschnabeltier 11.06.19 - 13:14

    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.

    Und das alles stimmt vermutlich, geht aber leider am Thema vorbei.
    Ein schlechtes Programm ist nicht zwingend ein unsicheres Programm. Post/Preconditions, asserts, type checking, range checking, typenvalidierung etc. kann man alles auch zu Fuß Prüfen, nur leider wird ab einem Gewissen Grad an Zeremonie der Code einfach nicht mehr Lesbar. Der bloat versteckt dann die eigentliche Semantik.

    Man muss kein schlechter Programmierer sein um ein Detail zu übersehen. Denke den folgenden Fehler hat in der ein oder anderen Form schon jeder gemacht:
    this.coordX = x
    this.coordX = y
    this.coordZ = Z

    Natürlich gibt es auch Leute, die "keine Bugs" schreiben. Die muss ich im real life erst zwar finden, aber laut dem Internet gibt es sie ja überall.
    "Ich dachte da kümmert sich der Compiler drum" <- Aber ja , das ist ein Zeichen von inkompetenz :P
    Je nach Sprache hätte aber das Konstrukt um das es ging vielleicht nicht einmal kompiliert (Stichwort Rust).

    Fehler sind einfach menschlich. Aber je einfacher eine Programmiersprache es macht einen lesbaren Code mit schlanker Semantik zu haben desto unwahrscheinlicher werden auch Fehler übersehen.

  5. Re: Es ist keine Frage der Programmiersprache

    Autor: Quantium40 11.06.19 - 13:20

    \pub\bash0r schrieb:
    > Oder anders gesagt: man BRAUCHT keine dieser Sprachen, um gute Software zu
    > entwickeln, aber es HILFT. Und genau darum geht es doch bei Werkzeugen,
    > oder?

    Wenn man die genutzte Programmiersprache ständig wechselt, um der zweifelhaften Sicherheit hinterherzulaufen, die die neuen Sprachen bieten sollen, verfehlt man das eigentliche Ziel.
    Wenn man ein Problem beim Einschlagen von Nägeln hat, wechselt man doch auch nicht ständig den Hammer, nur weil der neue Hammer noch besseren Schutz für den Daumen bietet. Stattdessen lernt man besser, mit dem verdammten Hammer umzugehen.

  6. Re: Es ist keine Frage der Programmiersprache

    Autor: Xander 11.06.19 - 13:24

    Da ist schon was dran, aber auch der beste Programmierer macht Fehler oder muss schnell etwas programmieren und übersieht dabei etwas.

    Deswegen ist die Hilfe durch den Compiler oder einer guten IDE schon praktisch, ob eine "sichere" Sprache wie ADA jetzt so viel dazu beiträgt ist eine Frage, aber ich denke schon mal für jedes Einsatzgebiet ist ADA auch nicht geeignet ohne Mehraufwand.

  7. Re: Es ist keine Frage der Programmiersprache

    Autor: Quantium40 11.06.19 - 13:24

    Das Osterschnabeltier schrieb:
    > Denke den folgenden Fehler hat in der ein oder anderen Form schon jeder
    > gemacht:
    > this.coordX = x
    > this.coordX = y
    > this.coordZ = Z
    Wobei gerade diese Sorte Fehler in jeder noch so sicheren Sprache immer durchgeht.
    Sowas würde höchstens dem Optimzer des Compilers auffallen, weil er die erste Zuweisung zu this.coordX einsparen kann.

  8. Re: Es ist keine Frage der Programmiersprache

    Autor: bark 11.06.19 - 13:26

    Ohne know how kommst du trotzdem nicht weiter. Und das Ergebnis ist eher, dass sich ein grosser Teil der Entwickler auf die Hilfen verlässt und weiter schlechten code schreibt. Weil er sich denkt ahh das wird schon korrigiert.


    \pub\bash0r schrieb:
    --------------------------------------------------------------------------------
    > Einige Sprachen machen es dir sehr leicht, beschissenen Code zu schreiben
    > (C), andere machen es dir deutlich schwerer (Rust).
    > Wenn das Ziel von einem Entwickler ist, gute, sichere Software zu
    > schreiben, ist es - unabhängig von seinem Können - in seinem Interesse,
    > eine Sprache zu haben, die ihn dabei unterstützt.
    > Man greift ja auch so gut wie nicht mehr zu Assembler, obwohl man damit
    > natürlich ebenfalls jedes Problem lösen kann. Aber Abstraktion spart Zeit
    > und damit Geld und macht es einfacher, überhaupt noch zu verstehen, was da
    > an Code vor einem liegt, was wiederum Reviews vereinfacht und damit die
    > Sicherheit erhöht.
    >
    > Oder anders gesagt: man BRAUCHT keine dieser Sprachen, um gute Software zu
    > entwickeln, aber es HILFT. Und genau darum geht es doch bei Werkzeugen,
    > oder?

  9. Re: Es ist keine Frage der Programmiersprache

    Autor: \pub\bash0r 11.06.19 - 13:27

    Quantium40 schrieb:
    --------------------------------------------------------------------------------
    > \pub\bash0r schrieb:
    > > Oder anders gesagt: man BRAUCHT keine dieser Sprachen, um gute Software
    > zu
    > > entwickeln, aber es HILFT. Und genau darum geht es doch bei Werkzeugen,
    > > oder?
    >
    > Wenn man die genutzte Programmiersprache ständig wechselt, um der
    > zweifelhaften Sicherheit hinterherzulaufen, die die neuen Sprachen bieten
    > sollen, verfehlt man das eigentliche Ziel.
    > Wenn man ein Problem beim Einschlagen von Nägeln hat, wechselt man doch
    > auch nicht ständig den Hammer, nur weil der neue Hammer noch besseren
    > Schutz für den Daumen bietet. Stattdessen lernt man besser, mit dem
    > verdammten Hammer umzugehen.

    Hat ja auch niemand gesagt. Weder im Artikel noch in den Kommentaren. Auf der anderen Seite wäre es fahrlässig, eben NIE über den Tellerrand zu schauen. Siehe Assembler, COBOL, etc.

    Es kann auch durchaus hilfreich sein, neben der Hauptentwicklung kleinere Sachen in unterschiedlichen Sprachen zu implementieren, um ein Gefühl dafür zu bekommen. Selbst wenn man die Sprachen nicht in der Hauptentwicklung einsetzt, können Lektionen daraus trotzdem nützlich sein und in die andere Sprache übertragen werden. (Geht mir z.B. mit Go und Java so. Seit ich Go entwickle wird auch mein Java Code "einfacher".)

    Ebenso kann es sinnvoll sein, verschiedene Probleme mit verschiedenen Werkzeugen zu bearbeiten. Du musst eine SOAP Schnittstelle bedienen? Nimm Java oder .NET. Du musst hochperformante Berechnungen durchführen? C++ oder Fortran könnten eine gute Idee sein. Leichtgewichtige Backend-Entwicklung? Go. Hochverteilte System? Elixir. Und und und.
    MUSS man nicht machen. Aber zumindest zu wissen, dass es außer dem Hammer auch noch Schraubendreher, Zange, etc. gibt könnte einige Probleme vereinfachen ... nicht, dass man nicht auch mit einem Hammer eine Schraube in die Wand bekommen würde, aber ...

  10. Re: Es ist keine Frage der Programmiersprache

    Autor: MrTridac 11.06.19 - 13:31

    \pub\bash0r schrieb:
    --------------------------------------------------------------------------------
    > Man greift ja auch so gut wie nicht mehr zu Assembler, obwohl man damit
    > natürlich ebenfalls jedes Problem lösen kann.
    Assembler ist ein schlechtes Beispiel, weil der Grund kein bzw. wenig Asm zu programmieren ist nicht weil Asm unsicher ist, sondern umständlicher und unübersichtlicher, bzw. sehr schlecht portierbar.

    > 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.

  11. Re: Es ist keine Frage der Programmiersprache

    Autor: \pub\bash0r 11.06.19 - 13:34

    bark schrieb:
    --------------------------------------------------------------------------------
    > Ohne know how kommst du trotzdem nicht weiter. Und das Ergebnis ist eher,
    > dass sich ein grosser Teil der Entwickler auf die Hilfen verlässt und
    > weiter schlechten code schreibt. Weil er sich denkt ahh das wird schon
    > korrigiert.

    Was hat das jetzt damit zu tun? Ist deine Konsequenz, dass die Sprache dir GAR NICHTS abnehmen darf (ergo Assembler) damit ja die Nulpen direkt aussortiert werden? Sich dann wochenlang an einfachsten Problemen aufhalten können dann die zurecht hoch bezahlten Profis die noch wissen wie die Maschine tickt.
    Mit so einer Einstellung wären wir noch in der IT Steinzeit.
    Gute und schlechte Entwickler gibt es so oder so. Egal wie viel oder wenig Hilfe sie vom Tooling bekommen. Dass ich Feuer auch mit trockenem Holz und Reibung erzeugen kann heißt nicht, dass ich nicht zum Kochen lieber einen Ofen mit Ceranfeld verwende. Oder einen Microwellenofen.

  12. Re: Es ist keine Frage der Programmiersprache

    Autor: carsti77 11.06.19 - 13:34

    Oh Gott. Was fuer ein Quatsch.

    Ich fahre seit vielen Jahrzehnten Auto. Fehlerfrei. Kein Unfall. Warum brauch ICH also einen Sicherheitsgurt, ABS, Anti-Einschlaf-Systeme, Alkoholkontrollen, Elch-Tests und Crash-Tests? Abschaffen!
    Leute die fehleranfaellig fahren, fahren mit dem sichersten Auto fehleranfaellig. Die sollen mal alle Oldtimer fahren!

    Ich bin sooooo gut beim Auto fahren, ich sollte mich eigentlich regelmaessig zusaufen um es fuer die anderen Verkehrsteilnehmer spannender zu machen <Zwinkersmiley>

    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: https://blog.fefe.de/?ts=a207d583

    Zitat: Und "die Leute schulen" hilft auch nicht.

    Also den Menschen kann man nur begrenzt verbessern? Aha! Das ist ja mal eine Erkenntnis. Wir Software immer noch von Menschen geschrieben, ja? D.h. wir muessen uns also damit abfinden, dass dann Fehler passieren koennen.
    Warum also nicht ALLES tun, damit die Programmiersprache/IDE/Compiler/Toolchain den Grossteil der Fehler schlicht ausschliessen oder wenigstens Hilfestellung geben, dass ein Problem vorliegen koennte.

    An einer Stelle hat Fefe recht: wenn man die Firmen die fehlerhafte Software schreiben in die Haftung nehmen wuerde fuer entstandene Schaeden, waere von Heute auf Morgen vieles besser. Ich bin davon ueberzeugt, es wuerde zu einem Boom fuer Rust, Ada und Spark fuehren. Keine Versicherung wuerde C/C++ Code versichern wollen. Das ist genau wie bei AKWs. Die will ja auch keiner versichern.

    Aber ja, Fefe ist da ja noch nie konsistent gewesen. Regt sich zu recht auf, dass BILD Rezo doxxt: https://blog.fefe.de/?ts=a213df1b hat aber vor Jahren auch schon selbst Leute gedoxxt. Zum Beispiel einen ehemaligen Telekom-Mitarbeiter der fehlerhaften Code geschrieben hat :)



    1 mal bearbeitet, zuletzt am 11.06.19 13:43 durch carsti77.

  13. Re: Es ist keine Frage der Programmiersprache

    Autor: EWCH 11.06.19 - 13:35

    Quantium40 schrieb:
    --------------------------------------------------------------------------------
    > Das Osterschnabeltier schrieb:
    > > Denke den folgenden Fehler hat in der ein oder anderen Form schon jeder
    > > gemacht:
    > > this.coordX = x
    > > this.coordX = y
    > > this.coordZ = Z
    > Wobei gerade diese Sorte Fehler in jeder noch so sicheren Sprache immer
    > durchgeht.
    > Sowas würde höchstens dem Optimzer des Compilers auffallen, weil er die
    > erste Zuweisung zu this.coordX einsparen kann.

    der gcc meldet 'set but not used' Fehler.

  14. Re: Es ist keine Frage der Programmiersprache

    Autor: \pub\bash0r 11.06.19 - 13:38

    MrTridac schrieb:
    --------------------------------------------------------------------------------
    > 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.

    Das löst du nicht durch schlechtere Sprachen. Ignorante und kurzsichtige Entwickler wirst du in jeder Sprache finden. Besagtes C nimmt dir bereits sehr wenig ab und verlangt viel vorausschauendes Denken, und doch findet sich haufenweise Code mit absurd dämlichen Leaks oder Overflows. Sowas kann in Eile, durch Unwissen oder vlt. auch beim Refactoring entstanden sein.
    Dass (beispielsweise) viele Java Entwickler einen Scheiß auf Speicheroptimierung geben ist schade, aber kein Problem der Sprache. Würde sich aber z.B. dadurch beheben lassen, indem diese Leute eben auch mal ANDERE Sprachen nutzen. Lass sie doch mal eine Weile mit Rust arbeiten oder mit C und Valgrind eine Weile herumhantieren, danach sehen die die Welt in Java auch anders.

  15. Re: Es ist keine Frage der Programmiersprache

    Autor: MrTridac 11.06.19 - 13:46

    Das Osterschnabeltier schrieb:
    --------------------------------------------------------------------------------
    > MrTridac schrieb:
    > ---------------------------------------------------------------------------
    > > 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.
    >
    > "Ich dachte da kümmert sich der Compiler drum" <- Aber ja , das ist ein
    > Zeichen von inkompetenz :P

    Ganz genau. Das Problem ist, dass das immer Studenten waren, im letzten Semester, oder grad "fertig gemacht".
    Es sind schon die Universitäten die den Programmierern von morgen das Märchen von sicheren Programmiersprachen eintrichtern.

  16. Re: Es ist keine Frage der Programmiersprache

    Autor: carsti77 11.06.19 - 13:50

    Quantium40 schrieb:
    --------------------------------------------------------------------------------
    > Das Osterschnabeltier schrieb:
    > > Denke den folgenden Fehler hat in der ein oder anderen Form schon jeder
    > > gemacht:
    > > this.coordX = x
    > > this.coordX = y
    > > this.coordZ = Z
    > Wobei gerade diese Sorte Fehler in jeder noch so sicheren Sprache immer
    > durchgeht.
    > Sowas würde höchstens dem Optimzer des Compilers auffallen, weil er die
    > erste Zuweisung zu this.coordX einsparen kann.

    Gute IDEs und Compiler koennen das auch Heute schon nicht nur anzeigen sondern auch wenn man will das Kompilieren verhindern. Das funktioniert 1:1 wie Dead-Code detection und ist super nuetzlich. Klar passiert so ein Fehler nicht oft aber die meisten Menschen stolpern auch praktisch nie aber jeder der laeuft ist schon mal gestolpert.

  17. Re: Es ist keine Frage der Programmiersprache

    Autor: tsp 11.06.19 - 13:56

    > Und das alles stimmt vermutlich, geht aber leider am Thema vorbei.
    > Ein schlechtes Programm ist nicht zwingend ein unsicheres Programm.
    > Post/Preconditions, asserts, type checking, range checking,
    > typenvalidierung etc. kann man alles auch zu Fuß Prüfen, nur leider wird ab
    > einem Gewissen Grad an Zeremonie der Code einfach nicht mehr Lesbar. Der
    > bloat versteckt dann die eigentliche Semantik.

    Wobei das - weil das oft untergeht - auch nur bedingt eine Frage der verwendeten Programmiersprache ist. Dort wo man das will kann man ja z.B. auch mit Tools wie Frama-C auf C Code losgehen (Problematisch wird's leider bei Nutzung von z.B. function pointern) und entsprechend verifizieren ... wobei der Aufwand natürlich auch entsprechend steigt, wenn man damit entsprechende Ergebnisse erzielen will

  18. Re: Es ist keine Frage der Programmiersprache

    Autor: MrTridac 11.06.19 - 13:59

    carsti77 schrieb:
    --------------------------------------------------------------------------------
    > Oh Gott. Was fuer ein Quatsch.
    >
    > Ich fahre seit vielen Jahrzehnten Auto. Fehlerfrei. Kein Unfall. Warum
    > brauch ICH also einen Sicherheitsgurt, ABS, Anti-Einschlaf-Systeme,
    > Alkoholkontrollen, Elch-Tests und Crash-Tests? Abschaffen!

    Das ist ziemlich bescheuerter Vergleich.
    Programmieren ist Entwicklungsarbeit. Das ist nichts was man einfach lernt und dann nur ausführt. Beim Software entwickeln kreiert man etwas was es vorher nicht gab. Die Verkehrsregeln hat jemand für Dich kreiert, die führst Du nur aus.

    > Leute die fehleranfaellig fahren, fahren mit dem sichersten Auto
    > fehleranfaellig.

    Das bestätigt meinen Punkt, dass schlechte Programmierer auch mit einer "sicheren" Sprache schlechte Programme schreiben.

  19. Re: Es ist keine Frage der Programmiersprache

    Autor: schap23 11.06.19 - 14:08

    Ja, ja. Wie wir schon vor 30 Jahren gesagt haben: Richtige Programmierer schreiben in jeder Programmiersprache FORTRAN IV-Programme.

  20. Re: Es ist keine Frage der Programmiersprache

    Autor: MrTridac 11.06.19 - 14:13

    \pub\bash0r schrieb:
    --------------------------------------------------------------------------------
    > bark schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Ohne know how kommst du trotzdem nicht weiter. Und das Ergebnis ist
    > eher,
    > > dass sich ein grosser Teil der Entwickler auf die Hilfen verlässt und
    > > weiter schlechten code schreibt. Weil er sich denkt ahh das wird schon
    > > korrigiert.
    >
    > Mit so einer Einstellung wären wir noch in der IT Steinzeit.

    Das ist ein unsinniges "totschlag"-Argument.
    Niemand ist gegen Fortschritt und Weiterentwicklung. Das darf nur nicht dazu führen, dass Ingenieure nachlässig werden. Das ist aber meine Beobachtung.
    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.
    Mit dieser Vorstellung purzeln mehr und mehr Studenten aus der Uni.
    Ich will nur eins: Kompetenz.

  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. inovex GmbH, verschiedene Standorte
  2. ING-DiBa AG, Nürnberg, Frankfurt
  3. Dataport, Bremen, Berlin, Magdeburg, Hamburg, Rostock, Altenholz bei Kiel, Halle (Saale)
  4. OEDIV KG, Bielefeld

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 2,99€
  2. 4,99€
  3. (-72%) 16,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Physik: Den Quanten beim Sprung zusehen
Physik
Den Quanten beim Sprung zusehen

Quantensprünge sind niemals groß und nicht vorhersehbar. Forschern ist es dennoch gelungen, den Vorgang zuverlässig zu beobachten, wenn er einmal angefangen hatte - und sie konnten ihn sogar umkehren. Die Fehlerkorrektur in Quantencomputern soll in Zukunft genau so funktionieren.
Von Frank Wunderlich-Pfeiffer


    Digitaler Knoten 4.0: Auto und Ampel im Austausch
    Digitaler Knoten 4.0
    Auto und Ampel im Austausch

    Auf der Autobahn klappt das autonome Fahren schon recht gut. In der Stadt brauchen die Autos jedoch Unterstützung. In Braunschweig testet das DLR die Vernetzung von Autos und Infrastruktur, damit die autonom fahrenden Autos im fließenden Verkehr links abbiegen können.
    Ein Bericht von Werner Pluta

    1. LTE-V2X vs. WLAN 802.11p Wer hat Recht im Streit ums Auto-WLAN?
    2. Vernetztes Fahren Lobbyschlacht um WLAN und 5G in Europa
    3. Gefahrenwarnungen EU setzt bei vernetztem Fahren weiter auf WLAN

    Elektromobilität: Wohin mit den vielen Akkus?
    Elektromobilität
    Wohin mit den vielen Akkus?

    Akkus sind die wichtigste Komponente von Elektroautos. Doch auch, wenn sie für die Autos nicht mehr geeignet sind, sind sie kein Fall für den Schredder. Hersteller wie Audi testen Möglichkeiten, sie weiterzuverwenden.
    Ein Bericht von Dirk Kunde

    1. Proterra Elektrobushersteller vermietet Akkus zur Absatzförderung
    2. Batterieherstellung Kampf um die Zelle
    3. US CPSC HP muss in den USA nochmals fast 80.000 Akkus zurückrufen

    1. Videostreaming: Netflix und Amazon Prime Video locken mehr Kunden
      Videostreaming
      Netflix und Amazon Prime Video locken mehr Kunden

      Der Videostreamingmarkt in Deutschland wächst weiter. Vor allem Netflix und Amazon Prime Video profitieren vom Zuwachs in diesem Bereich.

    2. Huawei: Werbung auf Smartphone-Sperrbildschirmen war ein Versehen
      Huawei
      Werbung auf Smartphone-Sperrbildschirmen war ein Versehen

      Besitzer von Huawei-Smartphones sollten keine Werbung mehr auf dem Sperrbildschirm sehen. Der chinesische Hersteller hatte kürzlich Werbebotschaften auf seinen Smartphones ausgeliefert - ungeplant.

    3. TV-Serie: Sky sendet Chernobyl-Folge mit Untertiteln einer Fanseite
      TV-Serie
      Sky sendet Chernobyl-Folge mit Untertiteln einer Fanseite

      Der Pay-TV-Sender Sky hat die Serie Chernobyl in der Schweiz mit Untertiteln ausgestrahlt, die von einer Fan-Community erstellt wurden. Wie die inoffiziellen Untertitelspur in die Serie gelangt ist, ist unklar.


    1. 12:24

    2. 12:09

    3. 11:54

    4. 11:33

    5. 14:32

    6. 12:00

    7. 11:30

    8. 11:00