Was würde sich anbieten?



  • Ich habs empfohlen, weil es halt auch auf der JVM läuft, man auf Java-Kram zugreifen kann, aber nicht zu OOP gezwungen wird, sondern auch funktionale Sachen benutzen kann. Und man kann sich etwas biolerplate code einsparen.

    edit: http://steve-yegge.blogspot.de/2006/03/execution-in-kingdom-of-nouns.html 😃





  • likefirewood schrieb:

    Warum empfehlen hier so viele Scala, statt Java?

    Weil:
    "Smart developers and development managers are learning that Scala does offer real business benefits."
    "In a world where software is notoriously unreliable, Scala's advanced type system provides code verification which makes software more dependable and adaptable."
    "A rich set of features gives Scala a very dynamic syntax which allows developers to embed domain-specific languages within Scala code, allowing them to express themselves effectively in the code they write."
    "Migrating an existing development environment to Scala might seem daunting, but the language is right at home in a mixed environment, smoothing the migration process."
    Das überzeugt mich total.



  • Erstmal Danke.

    Ich würde kein größeres Projekt in einer Scriptsprache schreiben wollen

    Sagen wir so: für die Größe wäre PHP eigentlich geeignet. Hauptsache arbeitet die Applikation sehr intensiv mit der Datenbank zusammen, die Sprache selbst würde performancetechnisch aber ausreichen. Lediglich die Notifications machen mir etwas Kopfweh.

    Für realtime Notification brauchst du keine WebSockets.
    Du kannst z.B. einfach über JavaScript nen Request "get event" machen, und der Server beantwortet diesen Request einfach erst wenn's was zu melden gibt

    Ist das nicht Long Polling? D.h. ich hätte für jeden Request eine Instanz des Interpreters laufen - laut diversen Quellen braucht mir dann ein so ein Request ewta 15 MB an Speicher. Bei 100 Benutzern bräuchte die Applikation schon 1.5 GB Speicher, was irgendwo doch viel ist.

    Scale muss ich mir mal näher anschauen, dass hatte ich bisher nicht in Anbetracht gezogen.



  • volkard schrieb:

    likefirewood schrieb:

    Warum empfehlen hier so viele Scala, statt Java?

    Weil:
    "Smart developers and development managers are learning that Scala does offer real business benefits."
    "In a world where software is notoriously unreliable, Scala's advanced type system provides code verification which makes software more dependable and adaptable."
    "A rich set of features gives Scala a very dynamic syntax which allows developers to embed domain-specific languages within Scala code, allowing them to express themselves effectively in the code they write."
    "Migrating an existing development environment to Scala might seem daunting, but the language is right at home in a mixed environment, smoothing the migration process."
    Das überzeugt mich total.

    Ach Volkard... Du kannst damit funktional programmieren und dessen Vorteile nutzen. Aber selbst OO mit Scala ist eleganter, kürzer und lesbarer. Außerdem stehen dir auch unter OO typische funktionale, ausdrucksstarke Funktionen zur Verfügung.



  • floomi schrieb:

    Ich würde kein größeres Projekt in einer Scriptsprache schreiben wollen

    Sagen wir so: für die Größe wäre PHP eigentlich geeignet. Hauptsache arbeitet die Applikation sehr intensiv mit der Datenbank zusammen, die Sprache selbst würde performancetechnisch aber ausreichen.

    Mir gehts nicht um Performance. Ich will einfach nicht auf die zusätzlichen Vorteile verzichten, die ein Compiler bietet. Keine Lust, ewig nach irgendwelchen Bugs zu suchen, die einfach durch Tippfehler reingekommen sind, oder weil man nicht genau wusste, was man an der Hand hat, und die dann erst sehr viel später im laufenden Betrieb auffallen, weil der Code sehr selten durchlaufen wird. Alles schon erlebt. Außerdem kann man (oder kann ich) saubere objektorientierte Programmierung mit Sprachen wie Java oder C++ besser durchziehen, als mit einer Scriptsprache, erst recht einer wie PHP.



  • Sachen wie Python kann man auch kompilieren und Haskell kann man auch interpretieren lassen. Interpreter können auch schon beim Laden vom Modul Fehler verraten.
    Oder gehts dir eher um statische vs. dynamische Typisierung? Hört sich so ein Bischen für mich danach an.

    OOP-mäßig sind halt viele GoF-Patterns in Sprachen wie Ruby und co. gar nicht mehr nötig. Das kann sich bestimmt dann auch erstmal unsauber anfühlen. Ich denke, das meiste ist einfach Gewohnheit.
    Quelle: Ich bin schlecht in Java und Ruby. 😉



  • floomi schrieb:

    Für realtime Notification brauchst du keine WebSockets.
    Du kannst z.B. einfach über JavaScript nen Request "get event" machen, und der Server beantwortet diesen Request einfach erst wenn's was zu melden gibt

    Ist das nicht Long Polling?

    Ah, es gibt einen schönen Namen dafür 🙂
    Wusste ich gar nicht. Und ja, genau das meine ich.

    D.h. ich hätte für jeden Request eine Instanz des Interpreters laufen - laut diversen Quellen braucht mir dann ein so ein Request ewta 15 MB an Speicher. Bei 100 Benutzern bräuchte die Applikation schon 1.5 GB Speicher, was irgendwo doch viel ist.

    Ob pro Request ein eigener Interpreter läuft, und wie viel Speicher das braucht ist ganz von der verwendeten Sprache/Technologie abhängig.
    Bei PHP halte ich es für leicht möglich dass es so ist wie du schreibst - damit hab' ich keine Erfahrung. Das wäre dann natürlich ungünstig.

    Mit anderen Technologien sieht es allerdings schon wesentlich günstiger aus. Da bewegen wir uns pro Request im Bereich von ein paar KB bis vielleicht ein paar zig KB.



  • Dobi schrieb:

    Oder gehts dir eher um statische vs. dynamische Typisierung?

    Ja.

    Dobi schrieb:

    OOP-mäßig sind halt viele GoF-Patterns in Sprachen wie Ruby und co. gar nicht mehr nötig. Das kann sich bestimmt dann auch erstmal unsauber anfühlen. Ich denke, das meiste ist einfach Gewohnheit.

    Mir gings nicht unbedingt um die GoF Patterns, wobei ich auch einige davon öfter verwende, sondern eher um eine sauber durchgezogene und einheitliche Gesamtarchitektur. Und ja, "nicht nötig" kann sich unsauber anfühlen 😉 Bei einem Script mit weniger als 1000 Zeilen ist es super, da will ich auch keinen Boilerplate haben. Aber bei Projekten mit hundert tausenden oder Millionen Zeilen Code finde ich sauber definierte Schnittstellen und Vorgehensweisen (oder von mir aus Patterns) viel wichtiger als "braucht man nicht, kann man einfach irgendwas eintippen und es funktioniert". Dieses "irgendwas" funktioniert, ohne dass man genau weiß, was man hat und was man damit machen kann und ob sich das nicht irgendwann ändert, ohne dass man es merkt, mag ich überhaupt nicht. Und bei Scriptsprachen kann man das sehr schwer automatisch testen.
    Dass es Gewohnheitssache ist, hab ich ja gleich gesagt. Mir ist schon klar, dass es viele Entwickler gibt, denen dynamisch typisierte Sprachen viel lieber sind und die damit auch erfolgreich sind.



  • OK, mir persönlich gefällt static typing auch besser, vorallem wenn es so wie in Haskell oder Elm ist, und nicht wie in C++ oder Java. 😉



  • Ich hab mir jetzt Ruby etwas genauer angesehen - gibt es da irgendwas besonderes? Irgendwie siehts interessant aus.



  • Da du Python schon kennst, kannst du dir ja das hier mal durchlesen: https://www.ruby-lang.org/en/documentation/ruby-from-other-languages/to-ruby-from-python/
    Aber wenn schon so Kleinigkeiten wie "It’s elsif instead of elif." darin Platz finden, kannst du dir ja Denken, dass es nicht so ein großer Unterschied ist wie z.B. Ruby<->Java, C++<->Haskell, IO<->Prolog usw. 😉



  • Gestern Abend hatte ich mich ein wenig mit Notifications beschäftigt - und irgendwie stellt sich mir inzwischen die Frage, wie die eigentlich in der Realität umgesetzt werden.

    Ob WebSockets, Polling oder was auch immer - im Endeffekt kommen die Daten aus einer Datenbank und müssen folglich abgefragt werden. D.h. unabhängig der Technik die dem Client Bescheid gibt, müsste eigentlich die Datenbank "reden" können - sonst kommt man nicht mehr an Realtime, oder?

    Immerhin: (Long) Polling oder WebSockets laufen in einer Endlosschleife und benachrichtigen dann irgendwann den Client. Man kann aber wohl schwer innerhalb der Schleife ganze Zeit Datenbankabfragen machen - das würde der Datenbank wohl nicht gefallen. Folglich müsste man ein wait/sleep einbauen, wodurch "Realtime" wieder hinfällig wäre.

    Wie wird denn sowas wirklich gemacht?



  • Ah, ich hatte glaub einen Denkfehler drin:
    Man könnte doch dem Server bevor man in die Datenbank schreibt sagen "Benachrichtige den mal!", oder? Wird das so gemacht?



  • Gibt natürlich verschiedene Möglichkeiten und es kommt stark aufs Umfeld an, wie man das macht. Im Endeffekt wird die Datenbank natürlich nicht gepollt, außer es geht aus irgendeinem Grund nicht anders. Meist gibts irgendeine vorgeschaltete Logikschicht, z.B. Application Server, die das macht. Oder wie geschrieben hast, wird einfach bevor die Daten in die Datenbank geschrieben werden (oder danach) auch eine Benachrichtigung verschickt. Sollte man aber entsprechend kapseln, Verschicken von Nachrichten hat erstmal nichts mit dem Schreiben in die Datenbank zu tun und sollte im Code auch klar abgegrenzt werden.
    Eine Möglichkeit wäre auch, Events von der Datenbank zu bekommen, die meisten Datenbank können das auch. Aber wenn du eh eine zentrale Stelle hast, wo neue Nachrichten generiert werden, brauchst du den Umweg nicht.


Anmelden zum Antworten