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. Wilhelm Geiger GmbH & Co. KG, Oberstdorf, Herzmanns
  2. Wirecard Issuing Technologies GmbH, Aschheim bei München
  3. Transdev GmbH, Berlin
  4. Scheidt & Bachmann GmbH, Mönchengladbach

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 4,60€
  2. 2,99€
  3. 2,22€
  4. 0,49€


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


    5G-Auktion: Warum der Preis der 5G-Frequenzen so hoch war
    5G-Auktion
    Warum der Preis der 5G-Frequenzen so hoch war

    Dass die Frequenzen für den 5G-Mobilfunk teuer wurden, lasten Telekom, Vodafone und Telefónica dem Newcomer United Internet an. Doch dies ist laut dem Netzplaner Kai Seim nicht so gewesen.
    Eine Analyse von Achim Sawall

    1. Funklöcher Hohe Bußgelder gegen säumige Mobilfunknetzbetreiber
    2. Bundesnetzagentur 5G-Frequenzauktion erreicht 6,5 Milliarden Euro
    3. 5G-Auktion Etablierte wollen Preis für 1&1 Drillisch hochtreiben

    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

    1. Graue Flecken: Kabelnetzbetreiber fürchten Überbauen durch gefördertes Glas
      Graue Flecken
      Kabelnetzbetreiber fürchten Überbauen durch gefördertes Glas

      Die Förderung des Ausbaus in grauen Flecken, wo schon ein Netzbetreiber Anschlüsse mit mindestens 30 MBit/s anbietet, alarmiert die Kabelnetzbetreiber. Sie fürchten einen Überbau mit Glasfaser, obwohl Koaxialkabel Gigabitdatenraten liefern kann.

    2. Störung: Google Kalender war weltweit ausgefallen
      Störung
      Google Kalender war weltweit ausgefallen

      Google hatte ein größeres Problem mit seinem Kalender: Nutzer berichteten, dass die Funktion weltweit ausgefallen war. Die Webseite und die Synchronisation zu mobilen Apps waren ausgefallen, mittlerweile scheint aber wieder alles zu funktionieren.

    3. Netzbau: United Internet vor finalen Gesprächen mit 5G-Ausrüstern
      Netzbau
      United Internet vor finalen Gesprächen mit 5G-Ausrüstern

      United Internet sucht sich gegenwärtig einen 5G-Netzausrüster, die finalen Gespräche haben noch nicht begonnen. Doch ab wann kann das neu versteigerte Spektrum eigentlich genutzt werden?


    1. 18:14

    2. 17:13

    3. 17:01

    4. 16:39

    5. 16:24

    6. 15:55

    7. 14:52

    8. 13:50