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

Halb-OT: Prozedural oder OOP anfangen?

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Halb-OT: Prozedural oder OOP anfangen?

    Autor: Astorek 25.09.18 - 12:31

    Mich würde da wirklich die Meinung von anderen Mitforisten interessieren. Klar, die absoluten Grundlagen (Variablenzuweisung, Bedingungen, Schleifen, Funktionen/Unterprogramme) müssen sowieso geschaffen werden, aber wann ist es sinnvoll, explizit in OOP einzusteigen?

    Ich für meinen Teil habe den Fehler gemacht und bin ewiglange in QBasic (meine erste Sprache; nur prozedurale Programmierung möglich) steckengeblieben, bevor ich mich an andere Sprachen rantraute. Irgendwann bin ich über den Begriff OOP gestolpert und hatte beim Lernen einer neuen Sprache - neben der typischen Umgewöhnung der Syntax ansich, womit ich seinerzeit aber auch gerechnet hatte - zum Teil massive Probleme, mir "OOP-Denken" anzugewöhnen. Ich hab mich zu oft dabei ertappt, Probleme "klassisch-prozedural" zu lösen und unbewusst gegen OOP-Mechanismen zu verstoßen, was bei mir zu krudem Mischmasch-Code aus halb-prozedural, halb-OOP führte und bei größeren Projekten der Quelltext nahezu unwartbar war.

    Ich frage mich, ob man dem entgegensteuern könnte, wenn man relativ früh OOP ansich lernt? Wie gings anderen dabei?

    Ist einfach, was mir spontan beim Lesen des Artikels eingefallen ist und ich dachte, ich schreib das mal in diesem Beitrag auf^^...

  2. Re: Halb-OT: Prozedural oder OOP anfangen?

    Autor: aLpenbog 25.09.18 - 12:40

    Nun ich finde OOP ist ein schweres Thema. Das Konzept an sich ist schön, wenn wir auch wirklich in die Richtung gehen OOP für das zu nutzen, wo es eine Stärken hat, umkehren von Abhängigkeiten, dass dann so weit geht, dass nur neue Module kompiliert werden müssen und nicht die ganze Anwendung.

    In der Praxis tun aber sehr viele schlicht prozedural programmieren mit ein paar Schlüsselwörtern aus dem OOP-Bereich. Das sorgt dann meist für grausameren und unübersichtlicheren Code, ohne Vorteile.

    Ansonsten kommt OOP und Abstraktion für mich erst ganz am Ende drauf, da ich alles andere ebenfalls benötige, wenn ich im OOP Umfeld programmiere. Und OOP und die zugehörigen Schlüsselwörter sollte man denke ich auch nicht ohne entsprechende Konzepte lernen.

    Dazu sollte man auch aufhören aus OOP sowas besonderes zu machen, so gut wie alles gab es schon in anderen Sprachen und Konzepten zuvor, oft in besserer Form. Der eigentliche Vorteil ist und bleibt für mich Polymorphie und das Effektiv nutzen ist denke ich schon ziemlich tief in der Materie, das wäre sicher nicht das erste was ich lernen wollen würde.

    Selbe Probleme hat man aber bei Design Patterns, die dann häufig genutzt werden, obwohl das damit zu beheben Problem gar nicht existiert.

    Hinzufügen könnte man noch das Codequalität und entsprechende Richtlinien auch ein Thema sein sollten. Die meisten lernen nie, dass sie den Code auch schreiben, damit andere damit später arbeiten. Dass es kein großes Können ist etwas mit ternären Operatoren und int Arithmetik möglichst tief zu schachteln und in einer Zeile zusammenzufassen, wenn kein Mensch das jemals versteht, vermutlich man selbst in einigen Stunden nicht mehr.

    Die Kunst ist es komplexe Vorgänge simpel festzuhalten, nicht simple Vorgänge komplex.



    1 mal bearbeitet, zuletzt am 25.09.18 12:48 durch aLpenbog.

  3. Re: Halb-OT: Prozedural oder OOP anfangen?

    Autor: non_existent 25.09.18 - 12:43

    Astorek schrieb:
    --------------------------------------------------------------------------------
    > Mich würde da wirklich die Meinung von anderen Mitforisten interessieren.
    > Klar, die absoluten Grundlagen (Variablenzuweisung, Bedingungen, Schleifen,
    > Funktionen/Unterprogramme) müssen sowieso geschaffen werden, aber wann ist
    > es sinnvoll, explizit in OOP einzusteigen?
    >
    > Ich für meinen Teil habe den Fehler gemacht und bin ewiglange in QBasic
    > (meine erste Sprache; nur prozedurale Programmierung möglich)
    > steckengeblieben, bevor ich mich an andere Sprachen rantraute. Irgendwann
    > bin ich über den Begriff OOP gestolpert und hatte beim Lernen einer neuen
    > Sprache - neben der typischen Umgewöhnung der Syntax ansich, womit ich
    > seinerzeit aber auch gerechnet hatte - zum Teil massive Probleme, mir
    > "OOP-Denken" anzugewöhnen. Ich hab mich zu oft dabei ertappt, Probleme
    > "klassisch-prozedural" zu lösen und unbewusst gegen OOP-Mechanismen zu
    > verstoßen, was bei mir zu krudem Mischmasch-Code aus halb-prozedural,
    > halb-OOP führte und bei größeren Projekten der Quelltext nahezu unwartbar
    > war.
    >
    > Ich frage mich, ob man dem entgegensteuern könnte, wenn man relativ früh
    > OOP ansich lernt? Wie gings anderen dabei?
    >
    > Ist einfach, was mir spontan beim Lesen des Artikels eingefallen ist und
    > ich dachte, ich schreib das mal in diesem Beitrag auf^^...

    So früh wie möglich. Am Besten in OOP einsteigen bevor man überhaupt zu programmieren anfängt. Ich hatte auch große Probleme, weil meine Firma, bei der ich Azubi war, damals auch sehr prozedural gearbeitet hat und ich mir das nie anders angewöhnt habe (ich habe vorher mit C und AutoIt programmiert - beide habens nicht so mit Klassen) und die Firma hat das dann noch weiter gefördert. Meine Codes sahen absolut grässlich aus, und ich hatte auch einiges an Schwierigkeiten, mir eine ordentliche Arbeitsweise anzugewöhnen.

    Ich würde OOP in jedem Fall direkt am Anfang beibringen. Son bisschen prozedural am Anfang, völlig in Ordnung, aber sobald man Kontrollstrukturen durch hat, direkt mit OOP anfangen. Damit tut man den Betreffenden nur einen Gefallen.

  4. Re: Halb-OT: Prozedural oder OOP anfangen?

    Autor: Hanmac 25.09.18 - 12:43

    ich finde da ja Ruby interessant.

    ich meine du kannst darin auch Prozedural programmieren (lernen),
    um dann fest zu stellen das man schon die ganze Zeit mit Objekten gearbeitet hat ;P

  5. Re: Halb-OT: Prozedural oder OOP anfangen?

    Autor: zilti 25.09.18 - 12:46

    Denkt doch auch mal an functional programming! :)

  6. Re: Halb-OT: Prozedural oder OOP anfangen?

    Autor: lottikarotti 25.09.18 - 12:48

    Mein alter Gitarrenlehrer sagte immer: hard things first. Wenn dich etwas interessiert, dann lerne es. OOP verstehen und anwenden zu können ist in der Softwareentwicklung durchaus sinnvoll.

    R.I.P. Fisch :-(

  7. Re: Halb-OT: Prozedural oder OOP anfangen?

    Autor: Geistesgegenwart 25.09.18 - 12:50

    Astorek schrieb:
    --------------------------------------------------------------------------------
    > Mich würde da wirklich die Meinung von anderen Mitforisten interessieren.
    > Klar, die absoluten Grundlagen (Variablenzuweisung, Bedingungen, Schleifen,
    > Funktionen/Unterprogramme) müssen sowieso geschaffen werden, aber wann ist
    > es sinnvoll, explizit in OOP einzusteigen?

    Zum "lernen" würde ich was (schwach-) funktionales nehmen. Scheme ist ne beliebte Lernsprache z.B. Wer es anspruchsvoller mag, gerne auch Haskell. Wichtig: Nur zum lernen von Informatik und Programmieren allgemein, nicht zum schreiben von >1000 LOC Programmen!

    Warum? Weil ich auch heute noch zig Entwickler treffe die "alte Hasen" sind, aber massiv Probleme haben funktional zu denken, also z.B. mit Lambdas und Funktionen höherer Ordnung nicht zurechtkommen. Gleichzeitig haben die meisten "konservativen" Programmiersprachen in den letzten Jahren massiv funktionale Features übernommen - sogar Java hat Lambdas eingeführt, wenn auch recht spät. C# sowieso schon seit Version 2.0, und neuere Programmiersprachen wie Scala oder Kotlin sind ebenfalls massiv funktional. Gleiches gilt für neuere Frameworks, die dann auf funktionale Patterns setzen.

    Subjektiv sind OOP Patterns (nicht Programmiersprachen!) auf dem absteigenden Ast. Mutability und und tiefere Vererbungshierarchien sind zunehmend OOP Antipatterns geworden ("Prefer composition over inheritance" gilt ja mittlerweile als Gesetz).

  8. Re: Halb-OT: Prozedural oder OOP anfangen?

    Autor: CopyUndPaste 25.09.18 - 12:53

    Natürlich sollte es dem Einsatzzweck entsprechen. :D

  9. Re: Halb-OT: Prozedural oder OOP anfangen?

    Autor: MadCat_me 25.09.18 - 12:57

    zilti schrieb:
    --------------------------------------------------------------------------------
    > Denkt doch auch mal an functional programming! :)

    Volle Zustimmung. Muss ja auch nicht gleich Haskell sein. Man kann auch mit JavaScript oder Ruby einigermaßen funktional entwickeln, um mal in die Denkweise reinzukommen.

    OOP ist gut und schön, verleitet allerdings auch zu zu viel Abstraktion, was dann wirklich hässlich werden kann. Wenn man sich durch zig sinnlose Layer durchkämpfen muss, ist in der Architektur was schiefgelaufen.

  10. Re: Halb-OT: Prozedural oder OOP anfangen?

    Autor: Gonzo333 25.09.18 - 13:35

    du kannst in beiden Ecken viel Mist bauen - dementsprechend ist es eigentlich egal ;)

    Persönlich würde ich die OOP-Schiene bevorzugen, da man sich damit gleich eine vernünftigere Programmierung angewöhnt und nicht gleich in der "alles irgendwie global"-Ecke landet.
    (mein persönlicher Werdegang war aber anders herum - alter Sack und so... ;))
    Von OOP aus kann man dann relativ einfach auch in der Prozeduralen-Ecke arbeiten - auch wenn einem das dann überhaupt keinen Spass mehr macht ;)

  11. Re: Halb-OT: Prozedural oder OOP anfangen?

    Autor: pumok 25.09.18 - 13:53

    Ich würde das davon abhängig machen, wozu man überhaupt programmieren lernt.

    Wenn das Ziel eine hardwarenahe Programmierung ist, dann muss man OOP nicht zwingend verstehen. Wenns nicht hardwarenahe sein soll, dann ist OOP in meinen Augen schon sehr früh wichtig.

    Meine ersten Schritte waren übrigens in Assembler, dementsprechend habe ich nach wie vor meine Mühe mit OOP...
    Nach 10 Jahren hardwarenahem Programmieren hätte ich wohl am besten auf grüner Wiese neu begonnen. Learning by doing führte bei mir zu abenteuerlichem Code, welcher immer mal wieder beschmunzelt wird ;-)

  12. Re: Halb-OT: Prozedural oder OOP anfangen?

    Autor: Aluz 25.09.18 - 14:55

    Ich bin auch lange auf prozedualem haengengeblieben weil meine Ausbildung so das hauptsaechlich vermittelt hatte und dann als afterthought hinten dran irgendwie OOT dranpappte.
    Frei nach dem Motto: "Hier, nun schreiben wir sinnlose Kundenobjekte mit so tollen Funktionen wie Abrechnung usw. Und am Ende ist es nichtmal eine Anwendung sondern nur ein Konsolentool mit EVA, das wars, und nun gehts weiter zum borland Builder HUII klicki bunti!"
    Alles C++ btw.

    Ich konnte dann zwar verknuepfte Listen schreiben und mein Abschlussprojekt war ein A-Star Wegfinder, der die Wegfindung visualisiert hatte. Aber schoen war der nicht.

    Dann habe ich nach einem Jahr ein Buch geschnappt und noch einmal von vorne alles durchgemacht. Variablen, Schleifen, Funktionen usw. Dieses buch hat aber von Anfang an, selbst ohne Klassen direkt einzufuerhen die Informationen schon gruppert und das "Objekt" zumindest vom Konzept her im Verstand des Lesers gebildet. All das ohne dass dieser das mitbekommen haette. Dann kamen Klassen, Polymorphie und soooo viele Groschen sind dann fuer mich gefallen. Klassen machten ploetzlich so viel mehr Sinn.
    Ich hatte mir gewuenscht meine Ausbildung haette das so getan.

    Ich glaube das ist auch der beste Einstieg. Man lernt erst die Basics aber die Szenarien anhand derer diese erklaert werden vermitteln indirekt schon wie Dinge verknuepft sein sollten. Wenn dann Klassen und Objekte einherkommen macht es einfach nur Klick und das Konzept erschliesst sich von selbst.

    OOT Nachteile: OOT Programmierung hat uebrigends auch einige Nachteile. insbesondere kann OOT Programmierung einem die RAM und Cache Bandbreiten wegfressen wenn man nicht vosichtig ist. Wer dazu mehr wissen will, hier ein sehr sehr interessanter Talk zu CPU Caches. Viele Programmierer sind sich dem nicht bewusst oder denken "in meiner hoeheren Sprache irrelevant" aber oft ist das eben doch wichtig wenn es um Prtformance geht:
    CPU Caches and why you care - Youtube

  13. Re: Halb-OT: Prozedural oder OOP anfangen?

    Autor: pumok 25.09.18 - 15:07

    +1
    Genau das mit dem Buch hätte ich auch tun sollen ;-)

  14. Re: Halb-OT: Prozedural oder OOP anfangen?

    Autor: Aluz 25.09.18 - 15:13

    pumok schrieb:
    --------------------------------------------------------------------------------
    > +1
    > Genau das mit dem Buch hätte ich auch tun sollen ;-)

    Ganz vergessen, das Buch war uebrigends C++ Fuer Spieleentwickler.

    Sehr gut fuer besonders junge Menschen, da leuchten gleich die Augen wenn die das bekommen.
    Leider mittlerweile aber auch sehr in die Jahre gekommen. Sind noch vor c++11 Zeiten gewesen.

  15. Re: Halb-OT: Prozedural oder OOP anfangen?

    Autor: aLpenbog 25.09.18 - 15:14

    Das war das mit dem Space Shoot Em Up, dass da als Projektziel ist, woran man sich lang hangelt oder? Das fand ich auch sehr gut gemacht, da es mal nicht ein Sammelwerk war oder viele sinnfreie Miniaufgaben, sondern man sich an ein halbwegs großes Projekt rangetastet hat bzw. ein roter Faden der durchs Buch ging.



    1 mal bearbeitet, zuletzt am 25.09.18 15:15 durch aLpenbog.

  16. Re: Halb-OT: Prozedural oder OOP anfangen?

    Autor: Aluz 25.09.18 - 15:25

    aLpenbog schrieb:
    --------------------------------------------------------------------------------
    > Das war das mit dem Space Shoot Em Up, dass da als Projektziel ist, woran
    > man sich lang hangelt oder? Das fand ich auch sehr gut gemacht, da es mal
    > nicht ein Sammelwerk war oder viele sinnfreie Miniaufgaben, sondern man
    > sich an ein halbwegs großes Projekt rangetastet hat bzw. ein roter Faden
    > der durchs Buch ging.

    Japp, genau das. Und am Ende hat man ein "Asteroids", das aber eher einem Top Down Scroller aehnelt. Ohne Sound. Ohne Explosionen. Aber es war fuer das erste Projekt schon dicke viel Arbeit. Leider noch mit der SDL, haette mir da eine bessere 2D Library gewuenscht. Wie eben die SFML, dann ist die API an die man knuepft wenigstens auch OOT.

    Vonwegen schnelle und einfache Erlernbarkeit, ich kann "The Book of Shaders" empfehlen, ist undbeding nen Blick wert. Das Ding gibts online und das coole, man kann alle Codebeispiele einfach in der WebPage umschreiben und sieht, was dies mit dem Shader tut, realtime. Sehr Sehr klasse!
    The Book of Shaders - HelloWorld!
    Einfach mal in der letzten Zeile die Farbe abaendern, der AHA-Effekt den ich hatte als ich das einfach ausprobiert hatte war klasse. ^^

  17. Re: Halb-OT: Prozedural oder OOP anfangen?

    Autor: Trockenobst 25.09.18 - 16:09

    Astorek schrieb:
    --------------------------------------------------------------------------------
    > Funktionen/Unterprogramme) müssen sowieso geschaffen werden, aber wann ist
    > es sinnvoll, explizit in OOP einzusteigen?

    Am Anfang ist OOP gut. Alles hat seinen Sinn. Aber in der Praxis stellen sich dann Probleme.

    Beispiel: Du hast ein Objekt Person. Ein Objekt Anschrift. Wie stehen diese beiden Objekte in Beziehung? Eine Person kann mehrere Anschriften haben. Eine Anschrift kann mehrere Personen haben. Usw. Objektorientierung kann am Ende nicht helfen, wenn dein Topobjekt "Welt" heißt ;)

    Da kommt die Kritik an OO her. Sie hat immer lokalen Charakter, ist Usecase/Szenenbezogen und lehrt etwas, dass später in der Praxis, z.B. durch Injection-Modelle aufgebrochen wird (d.h. die Kombination zwischen Person und Anschrift ist nie wirklich technisch vorhanden, sie wird durch die Software nur simuliert damit der Entwickler es einfacher hat)

    In den einfachen Lehrbüchern wird auch Vererbung mit Fahrzeug->Auto und Fahrzeug->LKW und sowas gelehrt. Auch hier Ergeben sich in der späteren Praxis viele Probleme, z.B. im Test
    oder im Überfrachten von Modellbäumen.

    Person hat dann etwa ein Interface fürs CRUD (also Laden, Speichern, Anlegen, Löschen), später noch eins fürs schnelle Laden, für das erzeugen einer Test-Person und soweiter. Schnell hat man kräftige Monolithen mit hunderten von Interfaceklassen (siehe Java Spring Library) die auf dem Papier und nach Lehre schön aussehen, aber absolut unwartbar sind.

    Zunehmend trennen Projekte auch zwischen Input und Output sicht. Etwa Facebook als Beispiel.
    Nachrichten werden um den Faktor 50-100 eher gelesen, als geschrieben. In OO ist "speicher()" und "laden()" gleichwertig. In der Praxis wird Facebook 100 Server abstellen um zu lesen und 10 Server abstellen um Post zu speichern. Das ist in OO "pur" kaum abzubilden. Man macht das dann mit beschreibenden Tricks/Annotations usw. aber das zeigt dann die Limits der Technik.

    Funktionelle Programmierung ist für spezifische Datenverarbeitung schneller, Java kanns inzwischen über die Streams (oder gleich Scala ;), aber ich glaube dass es für einen Einsteiger gut ist, erst einmal einfache Objekte zu lernen. Aber dann sollte er sich seine Zielinteressen suchen und dann bei einer linie bleiben.

    Nichts ist schlimmer als 10 Jahre alten Javacode zu warten, wo ein wirrer Hipster in Patches Java 8 funktionale Streams reingewürgt hat :)

  18. Re: Halb-OT: Prozedural oder OOP anfangen?

    Autor: ronda-melmag 25.09.18 - 17:05

    Also der Umstieg von Prozedural auf OOP war für mich schwer - grade weil es ganz andre Denkansätze zugrunde liegen.

    Tendenz ist je grösser das Projekt umso eher ist man bei OOP besser aufgehoben.
    Im prinzip fängs man am besten mit PHP an, da geht beides.

    Lustigerweise wirst du eh mehre Sprachen lernen müssen :-)

    Und Murks / Unübersichtliches kann man in jeder Sprache erzeugen :-)

  19. Re: Halb-OT: Prozedural oder OOP anfangen?

    Autor: a user 25.09.18 - 17:16

    Meiner Ansicht nach: so früh wie möglich.

    Der Grund ist ganz einfach: das Grundkonzept ist schnell gelernt und verwendet und reicht für alles womit man einsteigt.

    Darüber hinaus wird es aber sehr philosophisch und komplex. Es ist gut sich langsam daran zu gewöhnen und reinzuwachsen. Deswegen sollte man die Grundlagen gleich mitmachen beim allgemeinen reinwachsen. Vieleicht nicht gleich sofort zu Beginn, aber nicht lange warten.

    Was Klassen und Objekte/Instanzen sind sollte man früh verinnerlichen. Wie man aber gut objektorientiert Programmiert, das ist eine andere Frage, mit einer mehrdeutigen und langwiergen Antwort.

  20. Re: Halb-OT: Prozedural oder OOP anfangen?

    Autor: Ymi_Yugy 25.09.18 - 17:28

    Also ich habe mit OOP angefangen und fand das Konzept am Anfang eigentlich super bis ich gemerkt habe, dass ich ständig alles in Klassen und Vererbungsbäume gepackt habe und am Ende zig Miniklassen und einzeilige Methoden hatte und OOP für mehr Code sorgte als die eigentliche Programlogik.
    Für große Projekte kann OOP sicher eine valide Strategie sein, wer eher kleine Hobbyprojekte erstellt verschwendet seine Zeit.

    Hinzu kommt, dass obwohl OOP in Unternehmen noch immer dominiert, sich die Forschung eher funktionales Konzepten zugewendet hat.
    Das dürfte auch damit zusammenhängen, dass OOP für erhebliche Probleme sorgt, wenn Concurrency in Spiel kommt.

  1. 1
  2. 2

Neues Thema Ansicht wechseln


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

Stellenmarkt
  1. über duerenhoff GmbH, Essen
  2. Fraunhofer-Institut für Arbeitswirtschaft und Organisation IAO, Stuttgart, Esslingen
  3. über Hays AG, Düsseldorf
  4. Fachhochschule Südwestfalen, Hagen bei Dortmund

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 38,90€ + Versand (Bestpreis!)
  2. (u. a. Sharkoon Skiller SGK4 für 19,99€ + Versand und Sharkoon SilentStorm Icewind Black 750 W...


Haben wir etwas übersehen?

E-Mail an news@golem.de


Gaming-Tastaturen im Test: Neue Switches für Gamer und Tipper
Gaming-Tastaturen im Test
Neue Switches für Gamer und Tipper

Corsair und Roccat haben neue Gaming-Tastaturen auf den Markt gebracht, die sich vor allem durch ihre Switches auszeichnen. Im Test zeigt sich, dass Roccats Titan Switch besser zum normalen Tippen geeignet ist, aber nicht an die Geschwindigkeit des Corsair-exklusiven Cherry-Switches herankommt.
Ein Test von Tobias Költzsch

  1. Azio RCK Retrotastatur wechselt zwischen Mac und Windows-Layout
  2. OLKB Planck im Test Winzig, gerade, programmierbar - gut!
  3. Alte gegen neue Model M Wenn die Knickfedern wohlig klackern

Mars Insight: Nasa hofft auf Langeweile auf dem Mars
Mars Insight
Nasa hofft auf Langeweile auf dem Mars

Bei der Frage, wie es im Inneren des Mars aussieht, kann eine Raumsonde keine spektakuläre Landschaft gebrauchen. Eine möglichst langweilige Sandwüste wäre den beteiligten Wissenschaftlern am liebsten. Der Nasa-Livestream zeigte ab 20 Uhr MEZ, dass die Suche nach der perfekten Langeweile tatsächlich gelang.

  1. Astronomie Flüssiges Wasser auf dem Mars war Messfehler
  2. Mars Die Nasa gibt den Rover nicht auf
  3. Raumfahrt Terraforming des Mars ist mit heutiger Technik nicht möglich

Google Nachtsicht im Test: Starke Nachtaufnahmen mit dem Pixel
Google Nachtsicht im Test
Starke Nachtaufnahmen mit dem Pixel

Gut einen Monat nach der Vorstellung der neuen Pixel-Smartphones hat Google die Kamerafunktion Nachtsicht vorgestellt. Mit dieser lassen sich tolle Nachtaufnahmen machen, die mit denen von Huaweis Nachtmodus vergleichbar sind - und dessen Qualität bei Selbstporträts deutlich übersteigt.
Ein Test von Tobias Költzsch

  1. Pixel 3 Google patcht Probleme mit Speichermanagement
  2. Smartphone Google soll Pixel 3 Lite mit Kopfhörerbuchse planen
  3. Google Dem Pixel 3 XL wächst eine zweite Notch

  1. Sega Classics angespielt: Sonic hüpft und springt auf dem Fire TV
    Sega Classics angespielt
    Sonic hüpft und springt auf dem Fire TV

    Keine Mini- oder Classic-Konsole, sondern mit einer App namens Sega Classics läuft Sonic auf dem Fire TV Stick 4K von Amazon. Insgesamt bietet die Sammlung 25 Retrogames, die einst auf dem Mega Drive erschienen sind. Golem.de hat ausprobiert, ob das Spielen immer noch Spaß macht.

  2. Anwaltspostfach: BeA-Klage erstmal vertagt
    Anwaltspostfach
    BeA-Klage erstmal vertagt

    Vor dem Anwaltsgerichtshof in Berlin fand heute die erste Verhandlung zu einer Klage statt, bei der Rechtsanwälte eine Ende-zu-Ende-Verschlüsselung im besonderen elektronischen Anwaltspostfach (BeA) erzwingen wollen. Das Gericht sieht aber noch viel Klärungsbedarf.

  3. Windows Sandbox: Nächste Windows-10-Version könnte Sandbox-Modus enthalten
    Windows Sandbox
    Nächste Windows-10-Version könnte Sandbox-Modus enthalten

    Microsoft könnte mit dem nächsten Windows-Update im Frühjahr 2019 einen Sandbox-Modus einführen, der Nutzern erlaubt, unsichere Programme zu starten, ohne ihre reguläre Windows-Installation zu gefährden.


  1. 18:18

  2. 16:58

  3. 16:40

  4. 15:37

  5. 15:19

  6. 15:04

  7. 14:35

  8. 14:23