Login
Newsletter
Werbung

Thema: Gawk 5.0 unterstützt Namensräume

5 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von klopskind am Do, 18. April 2019 um 18:27 #

Das ist mal wieder ein Paradebeispiel für die dümmliche, verlogene Art von Argumentation, die heutzutage im Internet anscheinend üblich ist.
Ich bin mir nicht sicher, ob Sie Brooke (s.o.) an dieser Stelle
Ja so ist es richtig! Was ich nicht benutze ist schließlich überflüssig.
richtig verstanden haben. Ich bin mir sicher, dass Brooke das sarkastisch meint, und das somit Kritik an der Argumentation des OP ist.
Was ist daran "dümmlich" oder "verlogen"?

OP stützt seine Argumentation nämlich im Wesentlichen darauf, dass er selbst keine Verwendung für Gawk oder anderen Implementierungen von AWK habe und sehe. Dabei schließt er von sich auf andere (siehe u.A. Titel des OP: "Braucht doch seit [sic] keiner mehr"). Deshalb ist es für eine Kritik seiner Argumentation an dieser Stelle unerheblich, wie er letzteres Argument begründet {mit der Existenz & Verwendung einer (für ihn) "flexibler"en und weniger "umständlich"en Alternative (Zitat: "normale Scriptsprache"}.

Der OP hat awk nicht kritisiert, weil er es nicht benutzt, [...]
Doch! OP schrieb (Hervorhebungen meinerseits):
Dieses Paradigma dass sich erst mal alles auf eine Zeile bezieht
ist vielleicht recht sinnvoll wenn man nur Textdateien durchnudelt.
Für was anderes ist es dann aber nicht zu gebrauchen bzw. wird schnell umständlich. Da ist eine normale Scriptsprache flexibler und auf Zeilen greife ich dort auch einfach zu und bin Längen flexibler.
Davon ausgehend schließt er von sich auf andere. So lautet die Überschrift des OP (bezogen auf den Artikel, d.h. Gawk oder AWK): "Braucht doch seit [sic] keiner mehr". Am Ende des Eingangskommentars schrieb er außerdem: "Sowas braucht und will keiner, ausser die Entwickler von gawk als reiner Selbstszeck zum dran rumentwickeln."

Daher ist Brookes Kritik berechtigt.

Unabhängig davon liegt der OP damit richtig, dass der beabsichtigte Haupteinsatzzweck von AWK hauptsächlich Einzeiler oder sehr kurze Programme waren/sind.

Aber weiter:

[...], sondern weil der Funktionsumfang von awk schon seit vielen Jahren in anderen Sprachen enthalten ist, einschließlich dem Kram, der jetzt hinzugefügt wurde.
Das stimmt soweit. Aber ist das die einzige Metrik, auf deren Grundlage Entscheidungen über die Wahl der zu verwendenden Werkzeuge (z.B. Programmiersprache) getroffen werden (können/sollten)?

Wie dem auch sei, betreffend der Kritik an der Argumentation des OP ist es nachrangig, womit der OP sein Argument begründet, wenn er gleichzeitig alle anderen Argumente, die für die Verwendung von Gawk/AWK statt möglicher Alternativen sprechen, unterschlägt, indem er fahrlässig von sich auf andere schließt.

Da stellt sich eben schon die Frage, warum man das noch brauchen sollte.
Eine Antwort auf diese Frage hängt von vielerlei Faktoren ab und ist äußerst anwendungsspezifisch. D.h. sie enthält stets eine Portion Subjektivität und ist quasi nie objektiv. Daher schlage ich vor, dass wir diese Frage besser denjenigen überlassen sollten, die eine konkrete Verwendung von Gawk/AWK erwägen oder umsetzen, ohne sie gleichzeitig zu einer Rechtfertigung zu zwingen.

Es gibt aber kein Anwendungsgebiet, das awk wesentlich besser abdeckt als beispielsweise Perl (oder Python, Ruby oder was auch immer).
Das ist eine Behauptung, die es zu beweisen gälte. Wer sollte diesen Beweis nun führen? Ich schlage vor, dass diejenigen Personen hierfür verantwortlich sind, die diese Behauptung aufstellen. In diesem Fall wären das Sie und der OP.

Trotzdem halte ich Folgendes gegen diese Behauptung:
1) AWK findet in der ein oder anderen Implementierung (z.B. Gawk) noch reichlich Anwendung. Nicht nur das, aber Entwickler auf der ganzen Welt schreiben auch heute noch Code in dieser Sprache oder passen bestehenden an, statt diesen zu ersetzen (siehe z.B. GitHub oder hier, Appendix B). Man denke auch an all' die weiterhin gepflegten und weiterentwickelten unixoiden Umgebungen (bzw. jede, die POSIX implementiert).

2) In einigen Umgebungen, in denen keine geeigneten Alternativen zur Verfügung stehen, sind die Entwickler auf die Verwendung von AWK angewiesen. Das kann mehrere Gründe haben: Implementierungen von AWK (z.B. Gawk) sind vergleichsweise schlank (weniger Abhängigkeiten), portierbar (Initialaufwand), wartbar (laufende Kosten), ressourcensparend (kostensenkend, bspw. in Embedded-Produkten) etc.
Perl ist bspw. nicht Teil des Basissystems von FreeBSD.

3) Im Gegensatz zu Perl (seit 1987), Python (seit 1990) oder Ruby (1995) und vielen anderen Skript- oder Interpretersprachen, wie z.B. Tcl (1987), existiert AWK schon deutlich länger (seit 1977). Es fand mit Version 7 Unix (1979) erstmals Verbreitung. Nach grundlegenden Überarbeitungen der Sprache erschien das Buch The AWK Programming Language (1988), womit die Sprache de-facto vollständig spezifiziert und dokumentiert wurde. Seitdem blieb sie weitestgehend stabil (relativ gesehen zu den genannten Alternativen und deren Implementierungen). Direkt darauf folgte GNU awk aka gawk aka Gawk. Damit genoss es lange Zeit eine hohe Verbreitung und Popularität für Textverarbeitung.
Ältere Entwickler sind also u.U. besser mit AWK vertraut als mit den Alternativen.

4) Seit 1985 ist AWK zudem Teil eines Standards (POSIX), was die meisten Alternativen bis heute nicht von sich behaupten können (JavaScript ausgenommen). Diese Dinge können bei einer Wahl der Umsetzungssprache zum Ausschluss aller Alternativen führen.

--
Übrigens: Was heißt "wesentlich besser" in diesem Kontext, und wer darf das beurteilen?
Ich schlage vor, dass die Bewertung und Entscheidung über die Eignung, Präferenz, Wahl oder Verwendung eines Werkzeugs (etwas anderes ist AWK oder eine andere Sprache - bzw. deren Implementierung - nicht) jedem Entwickler individuell obliegt. Die Entwickler sollten natürlich auch mit den Konsequenzen ihrer Entscheidungen, u.A. gerechfertigte Bewertungen des Ergebnisses und angemessene Kritik durch Dritte, rechnen.

Daher denke ich, dass der Einsatz von AWK je nach Anwendungsfall auch heute noch sinnvoll im Sinne pragmatischer Lösungen führen kann und eingesetzt wird, was die Relevanz dieser Sprache, deren Implementierung und Erweiterungen auch weiterhin rechtfertigt.

Es gibt aber kein Anwendungsgebiet, das awk wesentlich besser abdeckt als beispielsweise Perl (oder Python, Ruby oder was auch immer).
Konkrete Beweise bitte!

Und auf der anderen Seite stehen für diese Sprachen Tausende Module für jeden erdenklichen Zweck bereit (CPAN, PyPI etc.), während awk nichts vergleichbares zu bieten hat.
Das kann man genauso als Vorteil werten. So ist AWK deutlich einfacher, kompakter und prägnanter (nicht so geschwätzig), weil bestimmte, für Programmbibliotheken nötige Konzepte, z.B. Module oder Linking, fehlen, und die Implementierungen von AWK sind deutlich simpler, portierbarer, schlanker, wartbarer und ressourcenschonender als die der erwähnten Alternativen.
Es ist immer eine Abwägung einer Vielzahl an Faktoren und hängt vom Anwendungsfall ab.

Zeig bitte mal ein Beispiel, wo awk wesentliche Vorteile gegenüber Perl bietet.
Die Antwort darauf ist vielfältig, facettenreich und subjektiv.

Neben den oben bereits erwähnten Beispielen kann ein möglicher Vorteil die Lizenzierung ggü. Perl attraktiver sein, jenachdem welche Implementierung von AWK wir betrachten; vergleiche bspw. Perls Lizenz(en) mit dieser Lizenz.

Darüber hinaus wäre es hilfreicher, denke ich, wenn Sie etwaige AWK-Gurus einfach selbst fragen nach ihren Ansichten fragen.

  • 0
    Von AWK heisst mein Rollator am So, 21. April 2019 um 20:12 #

    Das Zeug ist einfach primitiv. So Trivialzeugs wie zeilenweise Texte einzulesen
    erschlage ich mit jeder anderen Scriptsprache die mehr kann und verbreiteter ist als awk.

    Also wozu brauche ich dann heute noch awk? Ob das Zeug auf FreeBSD läuft oder schlanker ist interessiert heute keinen mehr. Hört sich an als argumentieren hier Greise für awk als ob das etwas einfachere zeilenwerise einleisen von Textdateien für Trivialfälle heute noch ein Hammerargument sei. Leute wacht mal auf im Altersheim, wir haben 2019 nicht 1977.

    • 0
      Von klopskind am Mo, 22. April 2019 um 21:37 #

      Ich habe mein Bestes gegeben, Ihnen all' dies darzulegen; offenbar erfolglos.

      Zudem schreiben Sie hier Ihre subjektive Meinung und schließen von sich auf andere. Sie gehen in keiner Weise auf meine Argumente ein, oder versuchen diese zu entkräften.

      Auf dieser Grundlage werde ich diese Diskussion nicht fortführen.

    0
    Von Anonymous Coward am Mo, 22. April 2019 um 20:09 #

    Ich bin mir nicht sicher, ob Sie Brooke (s.o.) an dieser Stelle

    Ja so ist es richtig! Was ich nicht benutze ist schließlich überflüssig.
    richtig verstanden haben. Ich bin mir sicher, dass Brooke das sarkastisch meint, und das somit Kritik an der Argumentation des OP ist.
    Was ist daran "dümmlich" oder "verlogen"?
    Ich habe sehr wohl verstanden, was geschrieben wurde, Sie haben mich dagegen missverstanden. Was daran verlogen ist, dazu komme ich gleich.

    Der OP hat awk nicht kritisiert, weil er es nicht benutzt, [...]
    Doch!
    Ihr Zitat ist völlig aus dem Kontext gerissen. Das vollständige Zitat lautet:

    Der OP hat awk nicht kritisiert, weil er es nicht benutzt, sondern weil der Funktionsumfang von awk schon seit vielen Jahren in anderen Sprachen enthalten ist
    Ich bestreite also nicht, dass der OP awk kritisiert hätte, sondern ich bestreite, dass die Motivation für die Kritik der Nichtgebrauch von awk wäre. Und es gab auch keinen Grund, das anzunehmen, und deswegen ist es auch unehrlich und verlogen, ihn dafür zu kritisieren.

    Das stimmt soweit. Aber ist das die einzige Metrik, auf deren Grundlage Entscheidungen über die Wahl der zu verwendenden Werkzeuge (z.B. Programmiersprache) getroffen werden (können/sollten)?
    Wenn Werkzeug A alles kann, was Werkzeug B kann und noch mehr, und Werkzeug B in seinem Einsatzbereich gegenüber A keine wesentlichen Vorteile bietet, dann ist Werkzeug B überflüssig. Und ja, aufgrund von Synergieeffekten wäre es dann auch gut, wenn Werkzeug B baldmöglichst verschwinden würde.

    indem er fahrlässig von sich auf andere schließt.
    Hat er nicht getan (der Gebrauch des Wortes „ich“ steht dem nicht entgegen, genauso gut hätte er „man“ schreiben können).

    Das ist eine Behauptung, die es zu beweisen gälte. Wer sollte diesen Beweis nun führen? Ich schlage vor, dass diejenigen Personen hierfür verantwortlich sind, die diese Behauptung aufstellen. In diesem Fall wären das Sie und der OP.
    Man kann das sehr einfach am Funktionsumfang der Programmiersprachen festmachen. awk bietet schlichtweg keine Features, die es nicht auch in vergleichbarer Form in Perl gäbe.

    Ich schlage vor, dass die Bewertung und Entscheidung über die Eignung, Präferenz, Wahl oder Verwendung eines Werkzeugs (etwas anderes ist AWK oder eine andere Sprache - bzw. deren Implementierung - nicht) jedem Entwickler individuell obliegt
    Ich kann mich nicht erinnern, dass irgendjemand hier ein gesetzliches awk-Verbot befürwortet hätte.

    • 0
      Von klopskind am Mo, 22. April 2019 um 22:15 #

      Soweit, so gut!

      Ich kann allerdings Folgendes nicht ganz nachvollziehen:

      Wenn Werkzeug A alles kann, was Werkzeug B kann und noch mehr, und Werkzeug B in seinem Einsatzbereich gegenüber A keine wesentlichen Vorteile bietet, dann ist Werkzeug B überflüssig.
      Was heißt hier "alles"? Das ist mMn in jedem Fall anwendungsspezifisch also nicht rein objektiv zu verstehen.

      Die Formulierung dieses Sachverhalts und der dahinterstehenden Fragen ist mMn zu beschränkt.

      Tolle Sprachfeatures, Entwicklertools und Sprachökosysteme sind die eine Seite der Medaille. Es gibt aber noch andere Maßstäbe, die ein solches Werkzeug ggf. erfüllen müssen dürfte.
      Wie ich oben schon schrieb, kann es mitunter auch (oder gar vorrangig) um Abwägungen in anderen Dimensionen gehen, z.B.: vorhandene Kenntnisse (ggf. im Team), Größe des zusätzlichen Administrationsaufwands im Einsatz, Portierbarkeit, Minimalität und Ressourceneffizienz etc. pp.

      Meines Erachtens nach ist also die Komplexität einer solchen Abwägung (awk vs Alternative wie bspw. universelle Skript- o. Interpretersprache) deutlich höher als der OP mir zu verstehen gibt. Diese "Eindimensionalität" in der "Abwägung" des OPs kann ich demnach nicht teilen.


      Ich möchte mich an diesem Punkt nicht streiten, ob der OP von sich auf andere schließt. Da werden wir uns offenbar nicht einig.
      Für mich jedenfalls liest es sich eindeutig. Die einschlägigen Stellen hatte ich bereits zitiert.
      Eine schlüssige und gültige Argumentation auf so einer Grundlage aufzubauen, halte ich sachlich für äußerst gewagt und unprofessionell, sowie auf anderer Ebene sogar egozentrisch, ignorant und provokant.

      Man kann das sehr einfach am Funktionsumfang der Programmiersprachen festmachen. awk bietet schlichtweg keine Features, die es nicht auch in vergleichbarer Form in Perl gäbe.
      Das ist quasi das selbe Argument von oben.

      Was sind denn (Sprach-)Features für Sie? Zählen Verfügbarkeit mit extrem geringer zusätzlichem Administrationsaufwandes, Portierbarkeit, Leichtgewichtigkeit oder Ressourceneffizienz etwa nicht dazu? (Diese Faktoren können ggf. wichtig sein.) Falls nein, wieso nicht? Falls ja, welche Alternativen schlagen hier awk signifikant? Perl, Python oder Ruby sind es ja offensichtlich nicht, oder?

      Ich kann mich nicht erinnern, dass irgendjemand hier ein gesetzliches awk-Verbot befürwortet hätte.
      Ganz danach wirken die Kommentare des OP. Zitat: "Braucht doch seit keiner mehr" (Betreff) und "Sowas braucht und will keiner [...]"

Pro-Linux
Unterstützer werden
Neue Nachrichten
Werbung