[RalphS]

Naja, Scripting ist schon ein bißchen was anderes als Programmieren.

Obwohl, zugegeben, man mit Powershell die Grenzen ziemlich verwischt bekommt.

~ Jedenfalls, an Scriptsprachen bevorzuge ich bash für den Hausgebrauch und PHP für alles, was mit Datenbanken zu tun hat.

Und Datenbanken sind natürlich SQL. Kein dämliches SparQL für mich. Fürchterbares Zeugs, das

[def]

Mir ist grad wieder was untergekommen, was ich schon länger beobachte: Das Wort "gegen" an Stellen, an denen es eigentlich nicht passt. Z.B. "gegen eine bestimmte Bibliothek linken". Oder hier:

Wenn du gegen .NET programmierst bist du immer an MS gebunden.
Quelle: Ist Qt noch gefragt?

Wie bitte? "Gegen" .NET programmieren? Das kann nicht gutgehen!

Ist das vielleicht eine Formulierung aus dem Englischen, die einige Leute ins Deutsche übernommen haben ("link against a library" oder so)...?

[Holger_N]

Naja "gegen" heißt ja eigentlich sinngemäß "in eine bestimmte Richtung. Andersrum ist ja "entgegen".

Zum Beispiel im Satz "Die Funktion tendiert gegen Null."

[RalphS]

Yes. "Linking against a library" is what you say to express, 'well, I had to do a gcc -o zip zip.c -lbz2 -lz".

Of course, while it's okay to link against a *library* such as zlib or bzip2 (as in the example above) it's just plain nonsense to link against a language (such as C or C++) -- or a family of languages (such as .NET CLR).

As an aside: there's no such thing as /coding/ or /programming/ against anything.

To the best of my knowledge, the "link against" stems from the *directed* nature of link being created ( the library doesn't know - and isn't told - that anything is being done to it).

Dieser Beitrag wurde von RalphS bearbeitet: 31. Mai 2013 - 18:38

[def]

Danke für eure Antworten. @RalphS: Irgendein Grund, dass du auf Englisch geantwortet hast? (nur so interessehalber)

[RalphS]

Nö, nicht wirklich. Hatte mich grad nur auf englischen Seiten rumgetrieben, um Näheres zum 'link against' rauszufinden und war halt noch voll drin.

[def]

Ich hab gerade einen schönen Beitrag in den Kommentaren zu einem Ars-Technica-Artikel entdeckt. Im Artikel, der schon ca. zwei Jahre alt ist, geht es um die damals neu vorgestellte Web-Programmiersprache "Dart" von Google, die nach dem Willen von Google irgendwann JavaScript ablösen soll (mehr dazu im genannten Artikel, falls es jemanden interessiert).
Einer der Leser kommentiert diese neue Sprache mit einer erfrischenden Ehrlichkeit (ich hab's mal so ungefähr ins Deutsche übersetzt):

---

Mir ist gerade klar geworden, dass ich inzwischen jener alte, mürrische Chefprogrammierer bin, den ich so sehr gehasst habe, als ich ich vor 15 Jahren in die Industrie einstieg. Dieser Kerl hasste neue Programmiersprachen und hatte nicht genug Vorstellungskraft und nicht genügend Zukunftsambitionen, um durch das Erlernen von JavaScript, CSS und HTML seinen Arbeitsplatz zu sichern. Jetzt bin ich dieser Kerl. Ich hab mehr als die Hälfte meines Lebens damit verbracht, JavaScript zu beherrschen und lehne den Gedanken ab, dass dass nun alles hinfällig wird durch so ein Entwickler-Wunderkind von Google. (...) Scheiß auf deinen Fortschritt, Google.

---

Englisch: I've just realized that I'm the old, crusty senior programming lead that I hated so much when I got into the industry 15 years ago. That guy hated new languages and had no imagination or forward-looking ambitions enough to save his own employment by learning some javascript, css, and html.
I am now that guy. I've spent more than half of my life mastering javascript and refuse to believe that it's going to be obsoleted by some engineering wunder-kind from google. (...) F*ck your progress, Google.

---

Quelle: Google aims Dart at “the Visual Basic of the Web”

[Ludacris]

Zitat (svene: 03. Dezember 2013 - 21:53)

Genau das selbe kann ich shon manchmal an mir entdecken....also beide Seiten. Der Typ jetzt und vor 15 Jahren.

Naja, es ist halt immer doof erstmal, wenn was gut funktioniert und dann soll es auf einmal über den Haufen geworfen werden. Es sollte schon eindeutig Vorteile bringen bei einem "Wechsel".

"...etwas Neues hinzugefügt hat, so ist doch Fortschritt allein um des Fortschritts Willen auf keinen Fall zu unterstützen." (Dolores Umbridge HP5)

Fortschritt und Neuerungen sind ja schön und gut aber ich denke das Zitat fasst meine Meinung recht gut zusammen - was mich immer wieder ärgert ist, wenn APIs die super funktionieren in der nächsten Version komplett entfernt oder überarbeitet werden und der ganze Aufruf nicht mehr funktioniert... Das war zuletzt bei der API meiner FH so, da haben sie ein Jahr an der API herumgedoktort und dann über die Ferien alles neugemacht (ohne neue Funktionen einzubaun) - zum glück hab ich mir einen Wrapper in PHP geschrieben der mir die Daten für die Apps bereitgestellt hat sonst hätt ich 3 Apps überarbeiten dürfen.

[RalphS]

Ich bin und bleib der Meinung: wer APIs über den Haufen werfen muß, macht beim Programmieren etwas GRUNDLEGEND falsch.

APIs haben abstrakt zu sein - dürfen mit dem Code selber möglichst gar nichts zu tun haben. So wird es möglich, unabhängig von irgendwelchen Änderungen und Neuerungen die bestehende API-Infrastruktur vollständig zu erhalten.

Natürlich wird das irgendwann unhandlich. Dann klassifiziert man diese APIs halt als deprecated und sieht zu, daß die Nutzung möglichst zurückgeht (kann man ja prima überwachen, falls nötig). Notfalls baut man irgendwelche Bremsen und/oder Warnmeldungen ein, um die Nutzer zum Wechsel zu ermuntern.


Änderungen in der Verzeichnisstruktur einer Website ist ganz genau dasselbe. Diese ist *virtuell* - es gibt genau NULL Grund, da was dran zu ändern, aber TROTZDEM passiert es immer und immer wieder, daß man 404s bekommt.

Dieser Beitrag wurde von RalphS bearbeitet: 11. Dezember 2013 - 21:46

[Ludacris]

Ja gut aber das mit den Strukturen einer Webseite ist tricky einzuhalten - ich hab zum Beispiel je nach Lust und Laune manchmal ein Blogsystem am laufen, manchmal ein komplett selbstentwickeltes System, manchmal einen "One Pager" und da wird's schwer - klar ich könnt über mod Rewrite arbeiten aber das ist am IIS auch immer so eine Sache.

[RalphS]

mod-rw? Das braucht man doch nur für die internen Links und dann auch nur, wenn sich da was ändert (was es "normal" nicht sollte).

Nur, was sollte es denn für einen Grund geben, die logische Struktur der Freigabe zu ändern? Natürlich mal davon abgesehen, daß man den Zugriff vereinfachen will und, sagen wir, von /app.asp?p1=a&p2=b auf /app/a/b/ umsteigen will.

Hier wäre das Dateisystem aber nicht nur "normal" virtuell, sondern vollständig abstrahiert. Das wäre ja dann nur die eine Datei (app.asp) die dem Frontend ein Dateisystem vorspiegelt, das es aber überhaupt nicht gibt.

[Holger_N]

Zitat (RalphS: 12. Dezember 2013 - 17:21)

…
Nur, was sollte es denn für einen Grund geben, die logische Struktur der Freigabe zu ändern?
…

Der Kunde sagt, ich will es anders?

[RalphS]

Ja, okay. Klar.

Reichen wir die Frage eben weiter: abgesehen von "weil ich es halt so will", warum sollte es *der Kunde* anders wollen?

Nicht mal bei einen Wechsel der Plattform gibt es einen Grund. Man kann auch PHP-Code in .aspx-Dateien haben und umgekehrt, ebenso wie man Python-Code in .html-Dateien haben kann.

[Holger_N]

Naja man macht doch nie alles immer gleich und von Anfang an immer alles komplett richtig. Irgendwann hat man auch mal eine neue Idee und ändert was. Oder jemand ist für irgendetwas technisch verantwortlich und geht in Rente und der Nachfolger favorisiert eine andere Struktur. Da gibts doch immer Punkte, die dann plötzlich nicht mehr passen, sonst würde ja alles immer super funktionieren.