Das längste Thema

  • Was meinst Du mit rangeklatscht wirkende Objektorientierung? Da gibt es deutlich schlimmeres z. B. PHP, auch Java ist weniger Objektorientiert.

    Die mitgeschleifte Objektreferenz. Erster Parameter einer Methode eines Objektes ist immer der this Zeiger, frei benennbar. Warum?

    -> Sprachkerndefizit


    PHP 7 hat eine saubere Objektorientierung, aus sicht des Programmierers.

    Java ist ebenfalls sauber in der Objetkorientierung, inklusive polymorphen Verhaltens.


    Java ist neben C++ eine der Referenzimplementierung von moderner OOP. Kein Vergleich zu Python.


    Was meinst Du genau mit Pragmatischmus, fand eigentlich Python Code auch meistens recht pragmatisch

    Pragmatisch heißt in dem Zusammenhang die einfachste, schnellste und speicheroptimierteste Lösung zu finden. Das sieht nicht unbedingt schön aus, funktioniert aber Rock-Solid.


    Ein flüssiges Lesen von Python Code ist oft nicht möglich. Da fehlt die Schnittstelle zwischen "gut aussehen", "leserlich" und "funktionell". Siehe Arrays, Maps etc. im Sprachkern.

  • Die mitgeschleifte Objektreferenz. Erster Parameter einer Methode eines Objektes ist immer der this Zeiger, frei benennbar. Warum?

    -> Sprachkerndefizit

    Ja das ist in der Tat nervig, da habe ich mich am Anfang auch gefragt, warum das so gemacht wurde. Hat vermutlich wie immer irgendwelche Kompatibilitätsgründe. Wie ja auch so vieles bei anderen Sprachen.

    Zitat

    PHP 7 hat eine saubere Objektorientierung, aus sicht des Programmierers.

    Java ist ebenfalls sauber in der Objetkorientierung, inklusive polymorphen Verhaltens.

    Ich finde es z. B. als totaler PHP Anfänger seltsam, dass ich auf Eigenschaften eines Objekts, die ich vorher mit $ vorne dran deklariert habe, dann bei einem Objekt ohne $ mit dem Pfeiloperator zugreifen.


    Auch benötigt man bei PHP für viele String Operationen und Array Operationen externe Funktionen, da es keine Objekte sind


    Zitat

    Java ist neben C++ eine der Referenzimplementierung von moderner OOP. Kein Vergleich zu Python.


    Kann man natürlich darüber streiten, da nicht alles dort ein Objekt ist, ob die dann wirklich eine Referenzimplementierung von modernem OOP sind.


    Zitat

    Pragmatisch heißt in dem Zusammenhang die einfachste, schnellste und speicheroptimierteste Lösung zu finden. Das sieht nicht unbedingt schön aus, funktioniert aber Rock-Solid.

    Einfach und schnell und speicher optimiert sind aber teilweise konträr zueinander. Gerade, was einfachen Code angeht, ist Python da schon ganz nett. Bei schnell und speicheroptimiert, natürlich nicht mehr so gut ;).


    Schnellste und speicheroptimierteste Lösung wäre wohl Assembler, aber das wäre wohl nicht mehr einfach und auch nicht schnell im Sinne von Entwicklungszeit


    Zitat

    Ein flüssiges Lesen von Python Code ist oft nicht möglich. Da fehlt die Schnittstelle zwischen "gut aussehen", "leserlich" und "funktionell". Siehe Arrays, Maps etc. im Sprachkern..

    Ist halt wieder subjektiv, da kann ich Dir deine Meinung nicht ausreden, ich persönlich finde Python Code meist gut lesbar.


    Ich bin übrigens weder Python noch Java, noch Fan einer anderen Programmiersprache. Ich finde diese Diskussionen werden oft zu emotional geführt. Letztlich hat so gut wie jede Sprache eine Daseinsberechtigung und so gut wie jede Sprache hat irgendwelche komische Syntax, die nicht logisch erscheint.

  • Letztlich hat so gut wie jede Sprache eine Daseinsberechtigung und so gut wie jede Sprache hat irgendwelche komische Syntax, die nicht logisch erscheint.

    Besser kann man es nicht zusammenfassen :thumbup:

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Ich finde es z. B. als totaler PHP Anfänger seltsam, dass ich auf Eigenschaften eines Objekts, die ich vorher mit $ vorne dran deklariert habe, dann bei einem Objekt ohne $ mit dem Pfeiloperator zugreifen.

    $ ist immer eine Referenz auf eine Variable. Objekteigenschaften adressierst du ja mit $this->property


    Auch benötigt man bei PHP für viele String Operationen und Array Operationen externe Funktionen, da es keine Objekte sind

    Ich finde die Standardbibliothek ist sehr umfangreich. Ob letztendlich die Operation via Operator oder Funktion durchgeführt wird, hat in der Zend Engine nur wenig Einfluss auf die Geschwindigkeit. php.net bietet dafür eine der umfangreichsten Dokumentationen, die es bei einer Sprache nur gibt. Besonders die Kommentare sind oftmals viel Wert.



    Kann man natürlich darüber streiten, da nicht alles dort ein Objekt ist, ob die dann wirklich eine Referenzimplementierung von modernem OOP sind.

    Eine OOP Sprache muss auch funktionale und prozedurale Paradigmen unterstützen; nicht alles ist immer gut in Klassen aufgehoben (Vergleich: Gottklasse).

    Deswegen darf es auch Sprachelemente geben, die kein Objekt sind.



    Einfach und schnell und speicher optimiert sind aber teilweise konträr zueinander.

    Richtig. Deswegen auch pragmatisch, weil man immer das richtige Gleichgewicht finden sollte.


    Schnellste und speicheroptimierteste Lösung wäre wohl Assembler, aber das wäre wohl nicht mehr einfach und auch nicht schnell im Sinne von Entwicklungszeit

    Dem einem Assembler, dem anderen Fortran. Ich möchte über moderne Sprachen im Jahre 2018 reden (Ansi-C / C-99 / GNU-99 gehören dazu, außer man zwingt die Variablendefinitionen zum Kuscheln)



    Ist halt wieder subjektiv, da kann ich Dir deine Meinung nicht ausreden

    Programme werden immer noch von Menschen erstellt. Nicht umsonst führt man im Python Forum eine Diskussion über "Master-Slave - weg damit aus der IT, das sind Begriffe aus der Sklaverei und diskriminiert Menschen".


    Ich bin übrigens weder Python noch Java, noch Fan einer anderen Programmiersprache. Ich finde diese Diskussionen werden oft zu emotional geführt.

    Ist halt die Gleiche Diskussion wie Apple oder Anti-Apple. Meiner Meinung nach ist es ein Fehler, dass Python so Einsteigerfreundlich gestaltet ist.

    Keiner sollte anhand von Python, PHP oder JavaScript programmieren lernen. Ich habe mit PHP angefangen (früher TM; vermutlich mir 12 Jahren) und das war IMHO ein Fehler.


    Meine Lieblinge sind C, PHP und Go "ich bin Fan davon" im Sinne von: das sind gute Arbeitsmittel.

  • Das ist das Problem, die Version aus dem Repo von nginx.org wurde mit noch mit dem Paket openssl 1.1.0f kompiliert, daher keine TLS1.3 Unterstützung.

    Wenn du aber nginx mit TLS1.3 Unterstützung brauchst, dann nimm das Paket von deb.sury.org/nginx-mainline/. Diese Version wurde mit openssl 1.1.1 kompiliert.


    nginx Version aus dem nginx.org Repo:

    Code
    nginx version: nginx/1.15.7
    built by gcc 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) 
    built with OpenSSL 1.1.0f  25 May 2017 (running with OpenSSL 1.1.1  11 Sep 2018)

    nginx Version aus dem deb.sury.org/nginx-mainline/ :

    Code
    nginx version: nginx/1.15.6
    built with OpenSSL 1.1.1  11 Sep 2018 (running with OpenSSL 1.1.1a  20 Nov 2018)

    Gegenbericht - Die folgenden Pakete - obwohl gegen 1.1.0f kompiliert, liefern TLSv1.3

    deb http://nginx.org/packages/debian/ stretch nginx

    deb-src http://nginx.org/packages/debian/ stretch nginx


    benutzte Cipherlist: TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-256-GCM-SHA384:TLS13-AES-128-GCM-SHA256:EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH:ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384


    Nur TLSv1.2 und TLSv1.3 - auch Qualys ssltest ist zufrieden.

    # nginx -V

    nginx version: nginx/1.14.1

    built by gcc 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)

    built with OpenSSL 1.1.0f 25 May 2017 (running with OpenSSL 1.1.1 11 Sep 2018)

    TLS SNI support enabled

    configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt='-g -O2 -fdebug-prefix-map=/data/builder/debuild/nginx-1.14.1/debian/debuild-base/nginx-1.14.1=. -specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fPIC' --with-ld-opt='-specs=/usr/share/dpkg/no-pie-link.specs -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -pie'


  • Kann man natürlich darüber streiten, da nicht alles dort ein Objekt ist, ob die dann wirklich eine Referenzimplementierung von modernem OOP sind.

    man sollte hier ganz schnell vergessen, daß C++ der OOP Aufsatz zu C ist, denn vieles das in C++ möglich ist, und C nicht kennt, hat mit OOP rein gar nichts zu tun ...

    auch unterscheiden sollte man bei OOP ob es ausschließlich eine einfache Vererbung oder eine ob auch eine mehrfache Vererbung existiert;

    und Java und Sauber kann ich definitiv nicht bestätigen;

    Eine OOP Sprache muss auch funktionale und prozedurale Paradigmen unterstützen; nicht alles ist immer gut in Klassen aufgehoben (Vergleich: Gottklasse).

    Deswegen darf es auch Sprachelemente geben, die kein Objekt sind.

    Ja und Nein, ist eher eine Frage was man als Output erwartet, mit vollständigem OOP gibt es kaum Sprachen, Smalltalk wäre ein Vertreter davon: die Schleife ist hier eine Methode der Integer Klasse; dafür ist diese auch nicht kompilierbar¹;

    das 2te gilt hier in C++, die nicht OOP Elemente heissen C;


    um was es sich hierbei handelt

    void ( C1::* pfunc ) ( const C2& c2 )

    sollte man daher als C++ Programmierer ebenfalls vertraut sein;


    ¹ kompilierbar im Sinne von Unwandlung in reinen nativen Maschinencode der zu 100% dem imperativen Paradigma gehorcht und selbst keinen integrierten Interpreter² darstellt


    ² bei Microsoft gab es das mal, hier wurde ein sogenannter p-code generiert, und der dafür notwendige Interpreter seitens des Linkers mit in den ausführbaren File gepackt;



    Dem einem Assembler, dem anderen Fortran. Ich möchte über moderne Sprachen im Jahre 2018 reden (Ansi-C / C-99 / GNU-99 gehören dazu, außer man zwingt die Variablendefinitionen zum Kuscheln)

    dann führt aber kein Weg an FORTRAN 90/95 vorbei

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • Was ist eure Hauptprogrammiersprache?

    hast Du hier Dinge gemischt?


    VB.NET ist doch nur eine andere Ausprägung von VB (Visual Basic)


    'Shell Code' ist eher ein allgemeiner Begriff f.

    - Linux: C-Shell (csh, tcsh), Korn-Shell (ksh), Bourne-Shell (sh, bash), ...

    - Windows: Powershell, ...


    von Delphi hab auch sowas wie 'Borland's / Embarcadero's ObjectPascal' gehört;

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)