Phantastisch was mir JavaScript mittlerweile alles möglich ist, die Geschwindigkeit ist super (nonBlockingIO) Da kommt Python leider nicht annähend ran. Nichtmal mit pypy.
3 News binnen der letzten 3 Jahre... Da wurde aber Emacs öfter genannt Übrigens: Nutze Atom nicht. Habe die App nur den Screenshots wegen heruntergeladen Ist ein Service
Du hast nie Quellcode-Dateien geladen die mehrere 100.000 Zeilen haben. Das sind fast alle Java-IDE's mit überfordert. Atom ist alles andere als überflüssig.
Du hast nie Quellcode-Dateien geladen die mehrere 100.000 Zeilen haben
Das stimmt allerdings.
Mir erschliesst sich jedoch nicht, warum man das besser hinbekommen sollte, indem man auf einen Webbrowser und dieses node.js-Gelumpe aufsetzt.
Und - dass diese Spezialexperten da 50% Startzeitverkürzung rausholen und auch noch stolz drauf sind, scheint anzudeuten, dass die sich auch nicht so wirklich auskennen.
Warten wir einfach, bis es heißt, die Startzeit sei auf ein Fünfzigstel des Wertes von Ende April 2017 verringert worden. Und wenn die Angabe des absoluten Wertes in Sekunden nur eine 0 vor dem Komma hat, kann man sich das Ganze ja vielleicht mal ansehen.
class MySuperOmicronDeltaHyper3DVizualizationClass extends AbstractUnrealAbstractionSuperClassFromHell implements BullshitBingoHandler, UselessCrapCompatibilityInterface, ClonableClusterFuckManager, OptimusPrimeMetatronAndMeganFoxHavingAThreesomeInTheBackyardGameManager {
// This code was auto generated by your lovely swap file torturing Java IDE! Please do not edit! Otherwise the Duke will roast you in Guantanamo Bay! ... // Paste more shitty code from stackoverflow.com here ... DON'T read it just PASTE it!!! ... }
Als bei mir ist Atom schon bei asciidoc Dateien von rund 2000 Zeilen abgestürzt. Und mit Quellcode Dateien von mehr als 100.000 Zeilen muss weder eine IDE noch ein Editor zurecht kommen sondern nur der Papierkorb.
Mir ging's mehr darum, dass die Aussage des lin sachlich falsch ist und das der Anwendungsfall, den er genannt hat schlicht und einfach unsinnig ist. Mir kommen auch von Zeit zu Zeit Log-Dateien unter, die ein paar GB groß sind und die mir den meisten Editoren nicht mehr geöffnet werden können. (Und blöderweise kommen die von einem Windowssystem und mein Arbeitsplatzrechner ist auch Windows was eine ganze Menge von Kommandozeilentools schwer einsetzbar macht). Allerdings ist das nicht unbedingt das einzige Kriterium nach dem ich einen Editor beurteile. Für Atom spricht z.B. die große Anzahl an Plugins für alle möglichen Sprachen wehalb ich ihn z.B. benutze wenn ich mit Elixir rumspiele.
>Und blöderweise kommen die von einem Windowssystem und mein Arbeitsplatzrechner ist auch Windows was eine ganze Menge von Kommandozeilentools schwer einsetzbar macht. UltraEdit/101 Editor/EmEditor kann man sich ja auch vom Arbeitgeber bezahlen lassen, wenn das wirklich ein Problem ist...
Dateien mit über 100.00 Zeilen können allenfalls Logs oder Datenbanken sein. Wenn eseinzelne Quellcodedateien in der Größe gibt, ist in der Entwicklung der Software gehörig was falsch gelaufen.
Es gibt auch noch andere Dinge. Satzdateien zum Beispiel. Und man muss schon dankbar sein, wenn es dann Zeilen viele aber kurze sind, denn erstaunlich viele Editoren kommen mit langen Zeilen nicht klar.
Phantastisch was mir JavaScript mittlerweile alles möglich ist, die Geschwindigkeit ist super (nonBlockingIO) Da kommt Python leider nicht annähend ran. Nichtmal mit pypy.
Ich weiß auch wie man die Startgeschwindigkeit erhöhen könnte: man zeichnet die GUI zuerst.
In Anbetracht der Häufigkeit, mit der hier Atom als neuer Editor auftaucht, könnte man meinen, der Autor wäre mit emacs und vi unzufrieden.
Die haben halt den Nachteil, dass sie mit 10 oder 5 Prozent der Ressourcen auskommen.
So was hat man heutzutage einfach nicht mehr zu wollen.
ja, Adipositas, SUVs ... wir sind die Größten ...
3 News binnen der letzten 3 Jahre... Da wurde aber Emacs öfter genannt Übrigens: Nutze Atom nicht. Habe die App nur den Screenshots wegen heruntergeladen Ist ein Service
Cheers,
demon
... auf Basis von Chrome und node.js ist ungefähr so sinnvoll, wie mit einer Planierraupe zum Nordpol fahren zu wollen.
Ich bin schon ganz gespannt, mit welch noch monströserer Idee "Atom" demnächst getoppt werden wird.
Du hast nie Quellcode-Dateien geladen die mehrere 100.000 Zeilen haben. Das sind fast alle Java-IDE's mit überfordert. Atom ist alles andere als überflüssig.
Du hast nie Quellcode-Dateien geladen die mehrere 100.000 Zeilen haben
Das stimmt allerdings.
Mir erschliesst sich jedoch nicht, warum man das besser hinbekommen sollte, indem man auf einen Webbrowser und dieses node.js-Gelumpe aufsetzt.
Und - dass diese Spezialexperten da 50% Startzeitverkürzung rausholen und auch noch stolz drauf sind, scheint anzudeuten, dass die sich auch nicht so wirklich auskennen.
Warten wir einfach, bis es heißt, die Startzeit sei auf ein Fünfzigstel des Wertes von Ende April 2017 verringert worden. Und wenn die Angabe des absoluten Wertes in Sekunden nur eine 0 vor dem Komma hat, kann man sich das Ganze ja vielleicht mal ansehen.
100 000 Zeilen in einer Quellcode Datei, wer macht so was?
Seihe Oben: Java-Programmierer.
class MySuperOmicronDeltaHyper3DVizualizationClass extends AbstractUnrealAbstractionSuperClassFromHell implements BullshitBingoHandler, UselessCrapCompatibilityInterface, ClonableClusterFuckManager, OptimusPrimeMetatronAndMeganFoxHavingAThreesomeInTheBackyardGameManager {
// This code was auto generated by your lovely swap file torturing Java IDE! Please do not edit! Otherwise the Duke will roast you in Guantanamo Bay!
...
// Paste more shitty code from stackoverflow.com here ... DON'T read it just PASTE it!!!
...
}
Viel zu wenig...
Als bei mir ist Atom schon bei asciidoc Dateien von rund 2000 Zeilen abgestürzt.
Und mit Quellcode Dateien von mehr als 100.000 Zeilen muss weder eine IDE noch ein Editor zurecht kommen sondern nur der Papierkorb.
Naja, ein Editor sollte meiner Meinung nach schon mit Dateien von bis zu 300 GB umgehen können.
Vielleicht bin ich nicht die Norm, aber als FE-Berechner hat man schon hin und wieder solche Monster zu bearbeiten.
Meiner Meinung nach am besten kann das derzeit der nedit, gefogt von kate (ja, das Ding von KDE, Überraschung!).
Allerdings sollte für so einen Stunt der Computer so zwischen 64 und 128 GB RAM haben, mein Laptop hebt sowas nicht.
Mir ging's mehr darum, dass die Aussage des lin sachlich falsch ist und das der Anwendungsfall, den er genannt hat schlicht und einfach unsinnig ist.
Mir kommen auch von Zeit zu Zeit Log-Dateien unter, die ein paar GB groß sind und die mir den meisten Editoren nicht mehr geöffnet werden können. (Und blöderweise kommen die von einem Windowssystem und mein Arbeitsplatzrechner ist auch Windows was eine ganze Menge von Kommandozeilentools schwer einsetzbar macht). Allerdings ist das nicht unbedingt das einzige Kriterium nach dem ich einen Editor beurteile. Für Atom spricht z.B. die große Anzahl an Plugins für alle möglichen Sprachen wehalb ich ihn z.B. benutze wenn ich mit Elixir rumspiele.
Das Ausweichargument der Programmierer lautet dann "Wer hat schon 300GB große Dateien, so ein Handling brauchen wir nicht." Der Bug ist ein Feature.
>Und blöderweise kommen die von einem Windowssystem und mein Arbeitsplatzrechner ist auch Windows was eine ganze Menge von Kommandozeilentools schwer einsetzbar macht.
UltraEdit/101 Editor/EmEditor kann man sich ja auch vom Arbeitgeber bezahlen lassen, wenn das wirklich ein Problem ist...
Dateien mit über 100.00 Zeilen können allenfalls Logs oder Datenbanken sein. Wenn eseinzelne Quellcodedateien in der Größe gibt, ist in der Entwicklung der Software gehörig was falsch gelaufen.
Es gibt auch noch andere Dinge. Satzdateien zum Beispiel. Und man muss schon dankbar sein, wenn es dann Zeilen viele aber kurze sind, denn erstaunlich viele Editoren kommen mit langen Zeilen nicht klar.
https://www.sublimetext.com/ RULEZ!