1. Foren
  2. Kommentare
  3. Software-Entwicklung
  4. Alle Kommentare zum Artikel
  5. › Mozillas…

Hässlich

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Hässlich

    Autor: lyom 16.07.15 - 11:19

    Ist mein erster Eindruck. Die Wartbarkeit wird eine Katastrophe, aber bei Mozilla ist eh schon klar dass die Entwickler machen was sie wollen, und mit dem Zug über alles drüber fahren.

    fn hallo()->i32 {...}

    sieht einfach nur schrecklich aus. Jeder Buchstabe wird gespart. Soll sich das ein Mensch nochmals ansehen? Wieso nicht gleich Assembler?

    Die letze Auswertung ist der Rückgabewert? Grauenhaft. Viel Spaß beim Debuggen. Und

    fn hallo() {
    a = b + 1;
    ...
    b
    }

    sieht auch übel aus. Ist "b" ein Fehler? Steht das einfach nur so da? War das beabsichtigt? In C++ ist das ein "Statement without effect." - eine Compilerwarning für gcc. Bei

    int hallo() {
    a = b + 1;
    ...
    return b;
    }

    sehe ich sofort was der Entwickler da machen wollte. Wieso zwei Methoden wie man Werte zurückgeben kann? Ist die heutige Generation schon so schreibfaul? Wenn's am "return" schon scheitert, dann kann ich mir schon vorstellen wieviel Dokumentation am Code sein wird.

    Und das erlaubte fehlende ";" in der letzten Zeile sieht schlampig aus. Kommt da noch was? Oder ist es das ganze Statement das der Entwickler geschrieben hat? Oder ist der gerade aufgestanden und hat auf den Rest vergessen? Das ist ungefähr so, als wenn ich in meinem letzten Satz die Satzzeichen weglasse, weil ihr könnt es eh parsen aber



    1 mal bearbeitet, zuletzt am 16.07.15 11:20 durch lyom.

  2. Re: Hässlich

    Autor: esgeh 16.07.15 - 11:34

    Ich finde, das ist ein "Argument", was ausgerottet gehört. Natürlich findet irgendwer eine bestimmte Sprache hässlich und eine andere schön. Das hat hauptsächlich was mit deinem Hintergrund zu tun, also mit welchen Sprachen du bisher warm geworden bist.

    Und überhaupt finde ich "Kritiken" von Leuten, die eine Sprache nicht mal ausprobiert haben, kaum lesenswert. Das ist nie viel mehr als "sieht anders aus als ich es gewohnt bin". Bevor Du irgendwelche Gefahren herbeischwörst, die gar nicht da sind (z.B. die Debugunfreundlichkeit aufgrund eines "fehlenden returns") solltest du dich vergewissern, ob dieses Problem tatsächlich besteht. Ähnliches gilt z.B. auch für "implizite Moves". Habe von anderen auch schon gehört, dass sie darin eine Gefahr sehen. Aber Movesemantik funktioniert in Rust ganz anders als in C++. Und das muss man erst mal verstehen.

    Die Welt kann auf vorschnelle Urteile verzichten.

  3. Re: Hässlich

    Autor: yoyoyo 16.07.15 - 12:56

    Dass du das Argument nicht magst, ändert nichts daran, dass es wichtig ist. (siehe die ganzen Sprachen, ihrer Konkurrenz weit überlegen waren und im Wesentlichen oder auch wegen 'komischer' Syntax nicht im Mainstream angekommen sind. (Smalltalk z.B.))

    Wer sich 2015 hinstellt und eine Sprache vorstellt, die auf weite Teile der Anwender komisch wirkt, fordert es ja geradezu heraus. (es ist natürlich nicht der einzige Faktor)

  4. Re: Hässlich

    Autor: Trockenobst 16.07.15 - 12:56

    lyom schrieb:
    --------------------------------------------------------------------------------
    > fn hallo() {
    > a = b + 1;
    > ...
    > b
    > }
    > sieht auch übel aus. Ist "b" ein Fehler? Steht das einfach nur so da? War
    > das beabsichtigt?

    "Die letzte Zeile des Funktionsrumpfes darf auf return verzichten."

    Mach halt ein return hin wenn du eine Lusche bist :D

    > schreibfaul? Wenn's am "return" schon scheitert, dann kann ich mir schon
    > vorstellen wieviel Dokumentation am Code sein wird.

    Bei fast jeder Sprache gibt Codequalität-Analysetools, wo man sowas festlegt
    Wir haben das in Java seit 10 Jahren in jedem Projekt und da haben wir sehr schreibfaule Menschen. Wenn etwa die Doku der Funktion nicht jeden Parameter beschreibt (z.B. mit Referenzcode auf eine Doku, XSD etc) dann wird der Checkin nicht angenommen. Man kann technisch nicht alles Lösen was Menschen richtig machen müssen.

    > vergessen? Das ist ungefähr so, als wenn ich in meinem letzten Satz die
    > Satzzeichen weglasse, weil ihr könnt es eh parsen

    Dein Gras vor dem Haus ist genau bei 2,2cm geschnitten oder? Wo kämen wir da hin? :D

    In vielen Funktionalen Sprachen, aber auch bei modernen Closures ist es nicht unüblich den Returnwert gar nicht anzugeben. Pseudocode

    def func(a, b) -> { a+b } // Der Wert von a+b wird hier zurückgegeben

    for (a in array_x) -> (a+1) // In dem array_x wird jedem wert eine 1 hinzugefügt

    Wenn man also fn hallo() { b } schreibt (und exakt ohne ";") ist dies die Kurzschreibw eise dass b der return Wert ist. Man könnte dies aber auch so schreiben

    func hallo() returns b {
    a = b + 1;
    }

    Wäre dass dann klarer für dich?

  5. Re: Hässlich

    Autor: igor37 16.07.15 - 13:49

    Ich hatte mal ähnliche Gedanken. Zumindest bis ich ein wenig damit herumprobiert habe, und jetzt finde ich es recht gut durchdacht, und lesbar ist der Code definitiv wenn man sich mal ein paar Tage beschäftigt hat. Das System mit der Fehlerbehandlung ist gelungen.
    Und im Fall von Switch-Case, die in Rust jetzt durch Match ersetzt wurden, hat man endlich die redundanten Teile entfernt und die Lesbarkeit verbessert imho.

  6. Re: Hässlich

    Autor: Hotohori 16.07.15 - 14:23

    Das letzte Beispiel ist aber etwas unglücklich, a berechnen lassen aber b, das sich gar nicht ändert, zurückgeben. ;)

  7. Re: Hässlich

    Autor: Lala Satalin Deviluke 16.07.15 - 14:29

    Kann dem nur voll und ganz zustimmen.

    Grüße vom Planeten Deviluke!

  8. Re: Hässlich

    Autor: pythoneer 16.07.15 - 14:58

    lyom schrieb:
    --------------------------------------------------------------------------------
    > Ist mein erster Eindruck. Die Wartbarkeit wird eine Katastrophe,

    Warum? Begründung?

    > fn hallo()->i32 {...}
    >
    > sieht einfach nur schrecklich aus. Jeder Buchstabe wird gespart. Soll sich
    > das ein Mensch nochmals ansehen? Wieso nicht gleich Assembler?

    Dein persönliche Meinung. Nur ist das alles andere als ungewöhnlich und man sieht das in zig anderen Sprachen auch, vielen wird es daher bekannt vorkommen. Nur was dir fremd ist muss nicht für alle anderen gelten.

    > Die letze Auswertung ist der Rückgabewert? Grauenhaft. Viel Spaß beim
    > Debuggen.

    Warum? Begründung?

    > Und
    >
    > fn hallo() {
    > a = b + 1;
    > ...
    > b
    > }
    >
    > sieht auch übel aus. Ist "b" ein Fehler? Steht das einfach nur so da? War
    > das beabsichtigt? In C++ ist das ein "Statement without effect." - eine
    > Compilerwarning für gcc.

    Du triffst hier einfach völlig falsche Annahmen. Du gehst davon aus, dass Rust sich wie C++ verhalten soll. Das ist aber doch gar nicht das Ziel von Rust. Damit hat nämlich sowas hier auch eine Bedeutung:

    let a = if(b < c) { 5 } else { 3 };

    In Rust sind nämlich viele Sachen expressions im Gegensatz zu anderen Sprachen.

    let y = { 2 * x };

    Und nur weil du das nicht verstehst, ist es nicht schlecht, oder?


    > Bei
    >
    > int hallo() {
    > a = b + 1;
    > ...
    > return b;
    > }
    >
    > sehe ich sofort was der Entwickler da machen wollte. Wieso zwei Methoden
    > wie man Werte zurückgeben kann? Ist die heutige Generation schon so
    > schreibfaul? Wenn's am "return" schon scheitert, dann kann ich mir schon
    > vorstellen wieviel Dokumentation am Code sein wird.

    Was versteifst du dich denn so auf das return? Man braucht es halt nicht und beim funktionalen Programmieren (high oder functions) stört es halt und so kennt man das auch aus anderen funktionalen Sprachen also wieder eher ein "was der Bauer nicht kennt" Fall.

    > Und das erlaubte fehlende ";" in der letzten Zeile sieht schlampig aus.
    > Kommt da noch was? Oder ist es das ganze Statement das der Entwickler
    > geschrieben hat? Oder ist der gerade aufgestanden und hat auf den Rest
    > vergessen? Das ist ungefähr so, als wenn ich in meinem letzten Satz die
    > Satzzeichen weglasse, weil ihr könnt es eh parsen aber

    das ";" hat nun mal eine andere semantische Bedeutung. Ich frage mich warum du das ständig mit anderen Programmiersprachen vergleichst. In Rust ist halt alles ein Ausdruck (liefert einen Wert zurück) man kann Ausdrücke zu Statements (liefert kein Wert zurück) in dem man nen Semikolon dran hängt, das liefert dann ein () "Unit type". Das einzige Problem was ich hier sehe, ist das du gar nicht versuchst die Sprache zu verstehen um sie zu kritisieren. Du vergleichst sie einfach 1:1 mit anderen und dabei machst du halt falsche Annahmen.

  9. Re: Hässlich

    Autor: esgeh 16.07.15 - 15:18

    yoyoyo schrieb:
    --------------------------------------------------------------------------------
    > Dass du das Argument nicht magst, ändert nichts daran, dass es wichtig ist.

    Das Problem dabei ist, dass "Schönheit" eine sehr subjektive Sache ist, die auch viel mit Gewöhnung zu tun hat. Ich sage nicht, dass Syntax generell keine Rolle spielt. Aber wenn du die Sprache nie ausprobiert hast und du dann über irgendwelche Merkmale inklusive Syntax lästern willst, dann ist der Nutzen dieser vorschnellen und subjektiven Meinung, die ich in diesem Fall nicht mal nachvollziehen kann, nahezu Null.

    > Wer sich 2015 hinstellt und eine Sprache vorstellt, die auf weite Teile der
    > Anwender komisch wirkt, fordert es ja geradezu heraus. (es ist natürlich
    > nicht der einzige Faktor)

    Möchtest Du behaupten, dass das bei Rust der Fall ist? Wenn ja, hast du Belege? Rust scheint mir mit seiner Syntax primär C++ Entwickler ansprechen zu wollen. Und das ist auch gar nicht so verkehrt, wenn man sich anguckt, wie sich die Ziele der Programmiersprachen überlappen. Das heißt aber eben nicht, dass Rust bestimmte Fehler aus der C/C++ Sprachwelt wiederholen muss. Um mal bei einem konkreten Beispiel zu bleiben: Der OP findet

    fn hallo() -> i32 {...}

    aus irgendeinem Grund hässlich, Warum? Weil ... Geschmack! Nichts weiter. Selbst in C++ hat man erkannt, dass die von C geerbte Deklarationssyntax einfach Scheiße ist. Statt

    typedef int mein_alias[5];
    int (*funktionsname())[5];

    kannst Du ab C++11 schreiben

    using mein_alias = int[5];
    auto funktionsname() -> int(*)[5];

    was übrigens noch andere Vorteile hat.

  10. Re: Hässlich

    Autor: twothe 16.07.15 - 16:23

    Optik ist sicherlich nicht primär-Grund eine Sprache abzulehnen, aber die Punkte die der OP nennt sind schon stichhaltig. Man stelle sich nur mal vor ich tacker auf die Enter-Taste für die neue Zeile und komm dabei noch auf einen Buchstaben den ich irgendwo vorher als Variable verwendet habe. Den Fehler sieht keiner, der die Funktion nicht ursprünglich geschrieben hat.

    Jetzt gibt es Leute die sagen "Dann mach halt keine Fehler!", aber wenn das so einfach wäre, dann würde wir nicht täglich was über Sicherheitslücken lesen oder Updates einspielen.

  11. Re: Hässlich

    Autor: esgeh 16.07.15 - 16:40

    twothe schrieb:
    --------------------------------------------------------------------------------
    > Optik ist sicherlich nicht primär-Grund eine Sprache abzulehnen, aber die
    > Punkte die der OP nennt sind schon stichhaltig. Man stelle sich nur mal vor
    > ich tacker auf die Enter-Taste für die neue Zeile und komm dabei noch auf
    > einen Buchstaben den ich irgendwo vorher als Variable verwendet habe. Den
    > Fehler sieht keiner, der die Funktion nicht ursprünglich geschrieben hat.

    Hmm... du müsstest versehentlich ein Semikolon und danach einen anderen Ausdruck hinschreiben, der denselben Typ hat. Wie wahrscheinlich wäre das? Wenn zu hoch vielleicht längere Variablennamen benutzen? ;)



    1 mal bearbeitet, zuletzt am 16.07.15 16:57 durch esgeh.

  12. Re: Hässlich

    Autor: m_jazz 16.07.15 - 21:08

    Ich kann dem voll zustimmen. Ich finde die Sprache ebenfalls hässlich.

    Und nein, Schönheit liegt nicht wirklich im Auge des Betrachters. Seit Jahrtausenden beschäftigt sich die Menschheit mit dem Thema "Schönheit" im Sinne der Ästhetik. Und dort gibt es klare Gesetze. Und im Prinzip wird das Argument "Schönheit liegt im Auge des Betrachters" immer nur auf solchen "Werken" angewandt welche von der "gesetzmäßigen" Schönheit abweichen. Dann betritt man nämlich einen Übergangsbereich. Einen Bereich in dem nicht mehr "quasi alle", sondern nur noch viele, wenige, oder nur noch einzelne etwas als "schön" empfinden.

    Man kann mit diesen Grenzbereichen bewusst spielen, sie bewusst einsetzen um ein schönes Gesamtwerk interessanter zu machen. Denn pure harmonische Schönheit wird oft auch als langweilig empfunden (Als Beispiel sei hier der berühmte "Schönheitsfleck" einer Frau angemerkt). Aber das wird hier nicht getan.

    Hier wird schlicht versucht jeden Buchstaben und jedes Schlüsselwort einzusparen, was der Compiler nicht unbedingt braucht um die Anweisung zu verstehen. Es ist effizient, ja. Und wenn man sich darauf eingestellt hat, kann man damit wohl auch ganz gut arbeiten. Aber es ist vor allem eines: Es ist hässlich.

  13. Re: Hässlich

    Autor: pythoneer 17.07.15 - 00:24

    m_jazz schrieb:
    --------------------------------------------------------------------------------
    > Ich kann dem voll zustimmen. Ich finde die Sprache ebenfalls hässlich.
    >
    > Und nein, Schönheit liegt nicht wirklich im Auge des Betrachters.

    Doch, genau und nichts anderes ist der Fall.

    > Seit Jahrtausenden beschäftigt sich die Menschheit mit dem Thema "Schönheit" im
    > Sinne der Ästhetik. Und dort gibt es klare Gesetze. Und im Prinzip wird das
    > Argument "Schönheit liegt im Auge des Betrachters" immer nur auf solchen
    > "Werken" angewandt welche von der "gesetzmäßigen" Schönheit abweichen. Dann
    > betritt man nämlich einen Übergangsbereich. Einen Bereich in dem nicht mehr
    > "quasi alle", sondern nur noch viele, wenige, oder nur noch einzelne etwas
    > als "schön" empfinden.

    Aha, fassen wir also zusammen. Schön ist genau jenes "Werk", bei dem sich Alle™ einig sind, dass es schön ist, weil es den "Gesetzmäßigkeiten" der Schönheit™ folgt. Alles andere muss demnach etwas anderes als schön sein. Da bei dir nur der Begriff hässlich fällt und deine einzige Begründung warum Rust hässlich ist diejenige ist, dass Rust nicht schön ist, muss daraus folgen, dass alles was nicht schön ist hässlich sein muss.

    Ich behaupte: Du wirst nichts finden bei dem sich Alle™ einig sind, dass es schön ist. Somit muss alles hässlich sein. Deine Aussage: "Rust ist hässlich" ist demnach ein Axiom/Dogma. Wie alle Axiome und Dogmen sind diese nicht falsifizierbar und bedürfen deshalb keiner Begründung. Ziemlich schwache argumentative Grundlage, sagt sie doch im Kern aus:
    "Alles ist hässlich, darum ist auch Rust hässlich"

    > Man kann mit diesen Grenzbereichen bewusst spielen, sie bewusst einsetzen
    > um ein schönes Gesamtwerk interessanter zu machen. Denn pure harmonische
    > Schönheit wird oft auch als langweilig empfunden (Als Beispiel sei hier der
    > berühmte "Schönheitsfleck" einer Frau angemerkt). Aber das wird hier nicht
    > getan.

    Aha, wir relativieren also wieder alles um unsere Aussage nicht angreifbar zu machen. Jetzt haben wir also ein Axiom (Alles ist hässlich) verknüpft mit einer Relativierung, falls doch noch ein dahergelaufener Idiot – wie ich – kommt und versucht dagegen zu Argumentieren. Tut mir leid, rhetorisch leider durchgefallen.

    > Hier wird schlicht versucht jeden Buchstaben und jedes Schlüsselwort
    > einzusparen, was der Compiler nicht unbedingt braucht um die Anweisung zu
    > verstehen. Es ist effizient, ja. Und wenn man sich darauf eingestellt hat,
    > kann man damit wohl auch ganz gut arbeiten. Aber es ist vor allem eines: Es
    > ist hässlich.

    Und dein Kommentar ist vor allem eines: Er ist Unsinnig.
    Hättest du mal echten Rust-Code gesehen, dann wäre dir ziemlich schnell aufgefallen, dass die Sprache extrem "geschwätzig" ist. Man schreibt ziemlich viel explizit auf, da wird ganz sicher nicht mit Tipparbeit gespart. Das dir persönlich Rust nicht gefällt haben wir nun verstanden. Aber hör doch bitte auf erklären zu wollen, warum deine Meinung – mehr ist das nicht – richtig™ sein soll.

  14. Re: Hässlich

    Autor: m_jazz 17.07.15 - 09:40

    Schau über den Tellerrand der Programmierung und der Mathematik hinaus und beschäftige dich zum Beispiel mit Grafikdesign. Lies über Konzepte wie dem goldenen Schnitt, Farbharmonien und Ästhetik. Versuche das ganze auch zu versehen und lerne es an zu wenden. Nach ein paar Jahren wenn du fertig bist lies meinen Kommentar noch einmal durch und du wirst genauso herzlich über deine Antwort lachen wie ich. :-)

  15. Re: Hässlich

    Autor: Schnarchnase 17.07.15 - 09:47

    Wohl eher weinen. Du kannst auch den Anforderungen des goldenen Schnitts genügen und trotzdem hässlichen Mist produzieren.

    Davon abgesehen hat sowas mit einem Sprachdesign nichts zu tun.

  16. Re: Hässlich

    Autor: pythoneer 17.07.15 - 09:50

    m_jazz schrieb:
    --------------------------------------------------------------------------------
    > Schau über den Tellerrand der Programmierung und der Mathematik hinaus und
    > beschäftige dich zum Beispiel mit Grafikdesign. Lies über Konzepte wie dem
    > goldenen Schnitt, Farbharmonien und Ästhetik. Versuche das ganze auch zu
    > versehen und lerne es an zu wenden. Nach ein paar Jahren wenn du fertig
    > bist lies meinen Kommentar noch einmal durch und du wirst genauso herzlich
    > über deine Antwort lachen wie ich. :-)

    Nein danke, ich lache einfach jetzt schon über deinen. Ist leichter.

  17. Re: Hässlich

    Autor: d0p3fish 17.07.15 - 10:00

    Ich stimme dem voll und ganz zu.
    Finde die Sprache auch ziemlich hässlich.
    Entfallen von Semikolons, aber nur evtl.
    Entfallen von return, kannste zwar so machen aber dann isses halt kacke.
    Die Lesbarkeit verbessert sich dadurch m.E. nicht.

  18. Re: Hässlich

    Autor: m_jazz 17.07.15 - 10:17

    @schnarchnase:
    Das du die Kunst der Ästhetik auf den goldenen Schnitt reduzierst zeigt das du keine Ahnung hast wo von ich Rede. Und natürlich hat so etwas auch viel mit Sprachdesign zu tun. Die Gesetze der Ästhetik gelten in jeder Kunst gleichermaßen. Man muss halt in der Lage sein sie auf so etwas wie eine Programmiersprache zu projizieren, was ein intuitives Verständnis voraus setzt.

    Auch wenn das einigen vielleicht nicht gefallen mag, aber es gibt jenseits der Compiler, Syntaxregeln und der Algorithmen noch eine ganze Welt voller spannender unglaublicher Dinge die es Wert sind ergründet zu werden. Geh zu den Grafikern in der Abteilung nebenan, zu den Concept Artists oder 3D Artists. Und lerne das was sie tun. Dann wirst du auch eine Programmiersprache anders sehen als vorher.



    1 mal bearbeitet, zuletzt am 17.07.15 10:21 durch m_jazz.

  19. Re: Hässlich

    Autor: Baron Münchhausen. 17.07.15 - 10:29

    Die Überschrift und deine Beschwerden zeigen, dass es dir stark an Sachverstand mangelt. Ich wollte eine ausführliche Antwort schreiben. Allerdings ist das was du schreibst so komplett falsch, dass ich schwierigkeit hatte einen passenden einstiegspunkt zu finden, da immer gleich etwas in "Kettenreaktion" wiederum falsch war. Es iet einfach durch und durch falsch. Als würde sich einer, der nicht ein mal weis wie eine schleife funktioniert, sich über die vorteile der betroffenen sprache sprechen. Man stellt schnell fest, dass es eine totale Zeitverschwendung ist und man theoretisch eine ganzheitliche Unterweisung machen müsste, bevor man hier weiter macht.



    1 mal bearbeitet, zuletzt am 17.07.15 10:33 durch Baron Münchhausen..

  20. Re: Hässlich

    Autor: Schnarchnase 17.07.15 - 10:54

    Das ist kompletter Schwachsinn. Bei einer Programmiersprache kommt es darauf an einen Zweck zu erfüllen, in sich schlüssig und konsequent zu sein und alle nötigen Werkzeuge zu bieten. Das hat mit Kunst und Ästhetik genau nichts gemein.

    Ich kann die Meinung Rust wäre hässlich durchaus nachvollziehen, ich fand die Sprache vom ersten Eindruck her auch sehr – nennen wir es mal – merkwürdig. Die Aufgabe einer Programmiersprache ist es aber nicht meinem ästhetischen Empfinden zu entsprechen, sondern meine Probleme möglichst gut zu lösen. Nachdem ich also den ersten Eindruck beiseite geschoben und einfach mal ein paar Dinge in Rust geschrieben hatte, musste ich einfach anerkennen, dass sie ihren Job verdammt gut macht.

    Ich glaube diejenigen die hier so laut schreien sind schlicht und ergreifend nicht bereit sich auf etwas Neues einzulassen.

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. ASB Informationstechnik GmbH, Duisburg
  2. STRABAG Innovation & Digitalisation, Wien (Österreich)
  3. Interhyp Gruppe, München
  4. INIT Group, Karlsruhe

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote


Haben wir etwas übersehen?

E-Mail an news@golem.de


Logistik: Hamburg bekommt eine Röhre für autonome Warentransporte
Logistik
Hamburg bekommt eine Röhre für autonome Warentransporte

Ein Kölner Unternehmen will eine neue Elbunterquerung bauen, die nur für autonom fahrende Transporter gedacht ist.
Ein Bericht von Werner Pluta

  1. Intelligente Verkehrssysteme Wenn Autos an leeren Kreuzungen warten müssen
  2. Verkehr Akkuzüge sind günstiger als Brennstoffzellenzüge
  3. Hochgeschwindigkeitszug JR Central stellt neuen Shinkansen in Dienst

iPad Air 2020 im Test: Apples gute Alternative zum iPad Pro
iPad Air 2020 im Test
Apples gute Alternative zum iPad Pro

Das neue iPad Air sieht aus wie ein iPad Pro, unterstützt dasselbe Zubehör, kommt mit einem guten Display und reichlich Rechenleistung. Damit ist es eine ideale Alternative für Apples teuerstes Tablet, wie unser Test zeigt.
Ein Test von Tobias Költzsch

  1. Tablet Apple stellt neues iPad und iPad Air vor

The Secret of Monkey Island: Ich bin ein übelriechender, groggurgelnder Pirat!
The Secret of Monkey Island
"Ich bin ein übelriechender, groggurgelnder Pirat!"

Das wunderbare The Secret of Monkey Island feiert seinen 30. Geburtstag. Golem.de hat einen neuen Durchgang gewagt - und wüst geschimpft.
Von Benedikt Plass-Fleßenkämper