A
Anonymous
Gast
Es ist immer wieder Amüsant 
Auf Arbeit mach ich mir schon seit Jahren immer mal wieder den Spaß und präsentiere ein awk oder sed Script für kleine Randproblemchen, das einwandfrei funktioniert, oft sogar einiges schneller ist als die professionellen Lösungen und nicht mal gestandene Softwareentwickler erkennen können warum das so ist, und wie es funktioniert. Damit provoziere ich dann immer wieder die gleiche Diskussion, hier im LC ist das ja noch vergleichsweise human, aber AWK und SED muss für einen heutigen Programmierer ein absolutes Teufelszeug sei. Als ob das die Existenz von anderen Programmiersprachen in Frage stellen würde.
Kann mit akw nicht passieren, das wird noch ewig konkurrenzlos weiterleben solange es noch 100tausende Scriptschreiber gibt, deren Lösungsansätze so hier aussehen
Jeder dieser Scriptschreiber kennt 100erte Shellbefehle mit 1000den von Optionen und hat schon Unmengen an Manpages gelesen. Aber keiner dieser 100tausenden Scriptschreiber wird aus [überspitzt und ketzerisch]übertriebener Lernresistenz[/überspitzt und ketzerisch] und weil ihm immer wieder aus allen Ecken suggeriert wird: "awk ist eine absolut unverständliche uralte und tote Sprache und man kann eh nur {print $....} gebrauchen" wird niemals auf die Idee kommen auch nur eine Zeile aus der AWK Dokumentation zu lesen, um nach 5 Minuten lesen und verstehens seinen Code auf
zu kürzen.
Der Perlprogrammierer ärgert sich erst gar nicht mit irgendwelchen winzigsten Problemchen auf der Shell rum und nutzt gleich Perl und der Java Programmierer lässt es gleich ganz bleiben weil diese Aufgabe so kompliziert ist das er wahrscheinlich eine oder zwei komplette Klassen neu programmiern müsste. Das lohnt sich dann gar nicht, dafür gibt es sowieso schon ein fertige SAP-Instanz mit der man mit Java zugreifen kann
Klar ist jeder Programmierer von "seiner" Sprache total überzeugt, wäre auch schlimm wenn nicht. Aber man darf nicht vergessen akw und sed sind zu einer Zeit für bestimmte Probleme entstanden als die Rechner noch nicht Maus,Tastatur und Bildschirm hatten und bevor es höhere Programmiersprachen gab mit standardisierten Modulen für alles mögliche. Bei AWK und SED muss man sich aus einem kleinem Vorrat an Möglichkeiten noch einen Lösungsweg selbst ausdenken, und kann sich nicht darauf verlassen, dass es schon einen universellen Lösungsweg gibt der neben einen Roboterfahrzeug auf dem Mars zu landen auch noch dieses kleine Problemchen lösen kann. Wenn man dann sich selbst einen Lösungsweg erstellt hat, dann hat man alle vorhandenen Gegebenheiten berücksichtigt und eingeplant, aber nicht mehr, und schon gar nicht ein Modul eingebunden bei dem man bei der Addition von zwei Zahlen auch noch Unmengen eventuelle und optiononaler Möglichkeiten und Erweiterungen hätte. (von der Möglichkeit das auch mit komplexen Zahlen zu machen , über Verschlüsselung bis hin zu eventuellen Abhängigkeiten aus der Relativitätstheorie und den Einfluss des Sonnenwindes). Das mit awk selbst erstellte Programm ist somit optimal für diese Aufgabe zugeschnitten und macht nur das was es soll, und berücksichtigt nichts was sowieso nicht da ist. Das macht die Lösung oft klein, schnell und effizient, aber unflexibel.
Wenn ein solches kleines isoliertes auf awk oder sed abgestimmtes Problem auftaucht, dann sind diese Sprachen durchaus und nach wie vor hoch effizient, hier und da vielleicht auch mal im Vorteil, auch wenn die Lösungswege für heutige Programmieralgorithmen absurd aussehen mögen. Die kleine Probleme sind heute die selben und Lösungen die man früher dafür hatte, funktionieren auch heute noch. Ob das noch modern ist oder nicht, sei mal dahingestellt.
Die alte Hacke mit der unsere Vorväter im Mittelalter ihre Rüben geerntet haben ist auch heute noch einer modernen Vollentemaschiene absolut überlegen wenn es darum geht das 5 x 8 Meter große Kartoffelbeet im eigenem Garten zu ernten. Und niemand der eine solche Hake in der Scheune hat wird jemals freiwillig mit seiner Hake auf hektargroßen Feldern arbeiten wollen, aber er weiß, im absolutem Notfall würde er mit einem haktargroßem Feld reifer Kartoffeln nicht verhungern.
Ob das so für den Fahrer, Verkaufer und Entwickler der Vollerntemaschiene auch zutrifft die ihre Haken vor 20 Jahren schon weggeschmissen haben und heute nur müde über solcher Art manuelle Arbeit lächeln... :???: und ob diese sich wirklich nicht Gedanken machen würden wie sie diese Monstermaschine über den Gartenzaum von der Oma bekommen würden..... :???:
robi
Auf Arbeit mach ich mir schon seit Jahren immer mal wieder den Spaß und präsentiere ein awk oder sed Script für kleine Randproblemchen, das einwandfrei funktioniert, oft sogar einiges schneller ist als die professionellen Lösungen und nicht mal gestandene Softwareentwickler erkennen können warum das so ist, und wie es funktioniert. Damit provoziere ich dann immer wieder die gleiche Diskussion, hier im LC ist das ja noch vergleichsweise human, aber AWK und SED muss für einen heutigen Programmierer ein absolutes Teufelszeug sei.
Als ob das die Existenz von anderen Programmiersprachen in Frage stellen würde.Da haben wir es schon. Die modernen Sprachen stehen sich untereinander so in Konkurrenz, das sie sich gegenseitig selbst abschaffen, oder sich selbst vor lauter Abhängigkeiten in den Versionen unkompatibel machen.abgdf schrieb:
Kann mit akw nicht passieren, das wird noch ewig konkurrenzlos weiterleben solange es noch 100tausende Scriptschreiber gibt, deren Lösungsansätze so hier aussehen
Code:
efficiency="$(cat efficiency.csv)"
timestamp3="$(echo "$efficiency" | head -4 | tail -1 | awk '{print $1 }')"
echo $timestamp3
Code:
awk 'NR==4{print $1}' efficiency.csvDer Perlprogrammierer ärgert sich erst gar nicht mit irgendwelchen winzigsten Problemchen auf der Shell rum und nutzt gleich Perl und der Java Programmierer lässt es gleich ganz bleiben weil diese Aufgabe so kompliziert ist das er wahrscheinlich eine oder zwei komplette Klassen neu programmiern müsste. Das lohnt sich dann gar nicht, dafür gibt es sowieso schon ein fertige SAP-Instanz mit der man mit Java zugreifen kann
Klar ist jeder Programmierer von "seiner" Sprache total überzeugt, wäre auch schlimm wenn nicht. Aber man darf nicht vergessen akw und sed sind zu einer Zeit für bestimmte Probleme entstanden als die Rechner noch nicht Maus,Tastatur und Bildschirm hatten und bevor es höhere Programmiersprachen gab mit standardisierten Modulen für alles mögliche. Bei AWK und SED muss man sich aus einem kleinem Vorrat an Möglichkeiten noch einen Lösungsweg selbst ausdenken, und kann sich nicht darauf verlassen, dass es schon einen universellen Lösungsweg gibt der neben einen Roboterfahrzeug auf dem Mars zu landen auch noch dieses kleine Problemchen lösen kann. Wenn man dann sich selbst einen Lösungsweg erstellt hat, dann hat man alle vorhandenen Gegebenheiten berücksichtigt und eingeplant, aber nicht mehr, und schon gar nicht ein Modul eingebunden bei dem man bei der Addition von zwei Zahlen auch noch Unmengen eventuelle und optiononaler Möglichkeiten und Erweiterungen hätte. (von der Möglichkeit das auch mit komplexen Zahlen zu machen , über Verschlüsselung bis hin zu eventuellen Abhängigkeiten aus der Relativitätstheorie und den Einfluss des Sonnenwindes). Das mit awk selbst erstellte Programm ist somit optimal für diese Aufgabe zugeschnitten und macht nur das was es soll, und berücksichtigt nichts was sowieso nicht da ist. Das macht die Lösung oft klein, schnell und effizient, aber unflexibel.
Wenn ein solches kleines isoliertes auf awk oder sed abgestimmtes Problem auftaucht, dann sind diese Sprachen durchaus und nach wie vor hoch effizient, hier und da vielleicht auch mal im Vorteil, auch wenn die Lösungswege für heutige Programmieralgorithmen absurd aussehen mögen. Die kleine Probleme sind heute die selben und Lösungen die man früher dafür hatte, funktionieren auch heute noch. Ob das noch modern ist oder nicht, sei mal dahingestellt.
Die alte Hacke mit der unsere Vorväter im Mittelalter ihre Rüben geerntet haben ist auch heute noch einer modernen Vollentemaschiene absolut überlegen wenn es darum geht das 5 x 8 Meter große Kartoffelbeet im eigenem Garten zu ernten. Und niemand der eine solche Hake in der Scheune hat wird jemals freiwillig mit seiner Hake auf hektargroßen Feldern arbeiten wollen, aber er weiß, im absolutem Notfall würde er mit einem haktargroßem Feld reifer Kartoffeln nicht verhungern.
Ob das so für den Fahrer, Verkaufer und Entwickler der Vollerntemaschiene auch zutrifft die ihre Haken vor 20 Jahren schon weggeschmissen haben und heute nur müde über solcher Art manuelle Arbeit lächeln... :???: und ob diese sich wirklich nicht Gedanken machen würden wie sie diese Monstermaschine über den Gartenzaum von der Oma bekommen würden..... :???:
robi
awk war fuer mich zu Anfang etwas gewoehnungsbeduerftig da es alle CodeZeilen zwischen BEGIN und END Bloecken auf die Eingabezeilen anwendet sofern man das nicht explizit unterbindet - aber das bietet auch ungeahnte neue Moeglichkeiten eine Textsuche und -bearbeitung sehr kurz und knapp durchzufuehren. Und trotz kurzem Code bleibt er leserlich.