Scientific computing’s future: Can any coding language top a 1950s behemoth? | Ars Technica

Wherever you see giant simulations of the type that run for days on the world’s most massive supercomputers, you are likely to see Fortran code. Some examples are atmospheric modeling and weather prediction carried out by the National Center for Atmospheric Research; classified nuclear weapons and laser fusion codes at Los Alamos and Lawrence Livermore National Labs; NASA models of global climate change; and an international consortium of Quantum Chromodynamics researchers, calculating the behavior of quarks, the constituents of protons and neutrons. These projects are just a few random examples from a large computational universe, but all use some version of Fortran as the main language.


Σχόλια

  • από stassa πριν 1172 μέρες       

    Γλώσσα με την οποία έχω μηδενική εμπειρία, δόξα να έχει ο Μπάμπατζ και η Λάβλεις να βάλει το χέρι της να μην χρειαστεί ν' αποκτήσω.

    • από liby πριν 1172 μέρες 1       

      Εάν χρειαστει πάντως ειναι πολύ εύκολο να μαθεις ακόμη και modern fortran (που εχει πολύ πιο advanced features ας πούμε απο f77) Καμία σχεση με την προσπάθεια που χρειάζεται για να μαθεις C++.

      Eάν δουλεύεις στο industry στο UK, νομιζω οτι είναι πολύ λίγο πιθανό να τη δεις ακόμη και σε εταιρειες που κανουνε numerical computing ή και high performance computing. Από την άλλη στο UK national supercomputer -στον οποιο τρεχουνε ερευνητές scientific software δικό τους ή άλλων, αυτή τη στιγμη τρεχουνε κυρίως (μαλλον πάνω απο 90%) κώδικες σε Fortran.

    • από stassa πριν 1169 μέρες       

      «Εάν χρειαστει πάντως ειναι πολύ εύκολο να μαθεις ακόμη και modern fortran (που εχει πολύ πιο advanced features ας πούμε απο f77) Καμία σχεση με την προσπάθεια που χρειάζεται για να μαθεις C++.»

      Δεν διαφωνώ, απλά ελπίζω να μην χρειαστεί :)

      «Eάν δουλεύεις στο industry στο UK, νομιζω οτι είναι πολύ λίγο πιθανό να τη δεις ακόμη και σε εταιρειες που κανουνε numerical computing ή και high performance computing.»

      Σωστά, Fortran δεν έχω δει. Σε μια δουλειά που δουλεύανε μ' ερευνητικά κέντρα χρησιμοποιούσανε LabVIEW και σε ένα Phd που πήγα να δω τί παίζει μου είπανε για Matlab, αλλά Fortran δεν μου έχει τύχει στο φυσικό περιβάλλον. Απ' την άλλη, στο Χημικό στην Ελλάδα μια φίλη μου έκανε Fortran και τότε το είχα δει ως αναχρονισμό του Ελληνικόυ πανεπιστήμιου- λάθος μου.

      Επί τη ευκαιρία οι δουλειές που βλέπω εδώ γύρω (στο Brighton και μέχρι Λονδίνο) ζητάνε σε λίγο-πολύ σειρά πλήθους θέσεων C# & SQL, Html/Css/Javascript, Java, C++, Ruby on Rails και άντε καμμιά VB .Net. Μετά από 'κει έχω δει στις αγγελίες να αναφέρουνε Haskell και Python και λιγότερο συχνά Erlang, Clojure, Scala, Ocaml F# και άλλες τέτοιες αλλά μάλλον τις βάζουνε οι πράκτορες (recruiters) για να ψαρέψουν υποψήφιους με εξωσχολικό ενδιαφέρον στον προγραμματισμό. Το λέω επειδή απαντούσα πάντα σε τέτοιες αγγελίες, αλλά μόνο σε ένα μέρος που πήγα μου είπανε οτι όντως χρησιμοποιούσανε μια απ' αυτές τις γλώσσες (Erlang) και παρ' όλ' αυτά με θέλανε για Ruby (χωρίς Rails), ενώ σε μια δουλειά που πήγα για Python τελικά με πήρανε για Java και η αναφορά σε Python ήταν αυτοσχεδιασμός του recruiter. Ε, με όλα τα πανεπιστήμια να διδάσκουνε Computer Science με Java, κάπου χρειάζεσαι κάποιο κριτήριο για να ξεδιαλέξεις υποψήφιους.

      Απ' την άλλη πρέπει να παίζει και πολύ C και περισσότερη C++ αλλά δεν το έχω με τα pointers και δεν τις κυνηγάω.

    • από liby πριν 1168 μέρες       

      "Απ' την άλλη πρέπει να παίζει και πολύ C και περισσότερη C++ αλλά δεν το έχω με τα pointers και δεν τις κυνηγάω."

      A, pointers εχει και η modern fortran (και ετσι για να μπερδευόμαστε ειναι διαφορετικοι από αυτους της C/C++)

      Για High Performance Computing σε academia οι γλωσεες που χρησιμοποιολυνται in practice ειναι Fortran, C/C++ και ανεβαινει και η αργή python- Δες και άρθρο που ανεβασε ο Επ στο Tech

      'Εχω την εντυπωση οτι η python ειναι αρκετα διαδεδομενη και στο industry--περισσότερο απο ruby (την εχει αγαπήσει πολύ και η Google.)

      (Πολύ συχνα οι recruiters λενε και γραφουν άλλα αντ'αλλων από την εμπειρία μου)

    • από stassa πριν 1168 μέρες       

      «'Εχω την εντυπωση οτι η python ειναι αρκετα διαδεδομενη και στο industry--περισσότερο απο ruby (την εχει αγαπήσει πολύ και η Google.)»

      Ομολογώ οτι δεν έχω καταλάβει ακριβώς τί γίνεται. Στη google σίγουρα την χρησιμοποιούνε. Απ' έξω, έχω πετύχει αρκετούς που ασχολούνται και δηλώνουν Python developers αλλά δεν ξέρω κατά πόσο το μεγαλύτερο μέρος της δουλειάς τους είναι όντως με Python. Δυστυχώς το industry είναι λίγο νεοφοβικό και αν δεν έχεις μια μεγάλη εταιρία να σπρώχνει μια γλώσσα, όπως η Oracle τη Java ή η MS τη C#, ο ρυθμός υιοθέτησης είναι αργός. Εμένα μ' αρέσει πάντως η Python, πολύ περισσότερο από τη Ruby (που είναι της ίδιας γενιάς και παρόμοια από κάποιες απόψεις). Και βρίσκω και τους χρήστες της σαφώς λιγότερο ενοχλητικούς απ' της Ruby :)


      «A, pointers εχει και η modern fortran (και ετσι για να μπερδευόμαστε ειναι διαφορετικοι από αυτους της C/C++)»

      Δεν περίμενα κάτι διαφορετικό :P

      Πάντως δεν είναι άσκημη ιδέα να μάθω λίγη Fortran για να την έχω στο βιογραφικό μου, αλλά δεν περιμένω να χρειαστεί ποτέ να την χρησιμοποιήσω η ίδια. Το λέω αυτό γιατί έχω την εντύπωση οτι οι επιστήμονες κλπ που τη χρησιμοποιούνε γράφουνε τον κώδικά τους μόνοι τους και δεν περιμένω να με προσλάβει κανείς να το κάνω για λογαριασμό του, όσο καλά και να την μάθω.

  • από dkamen πριν 1172 μέρες 1       

    Βασικά δεν έχουν αλλάξει και πολύ οι αριθμητικές μέθοδοι από τον καιρό του Νεύτωνα οπότε δεν είναι παράλογο που ο κόσμος προτιμά να καλέσει έναν έτοιμο solver σε f77 που έχει δοκιμαστεί άπειρες φορές.
    Επίσης σε αυτόν τον κόσμο υπάρχουν στην πραγματικότητα δύο μόνο είδη γλωσσών, αυτές που τείνουν προς τη lisp και αυτές που τείνουν προς τη fortran.

    • από liby πριν 1172 μέρες 2       

      @dkamen "Βασικά δεν έχουν αλλάξει και πολύ οι αριθμητικές μέθοδοι από τον καιρό του Νεύτωνα" Aν με αυτο θες να πεις απλά οτι υπάρχει πολυ legacy code, βεβαίως, και οτι πολυ νεο functionality προστιθεται σε κωδικα που παρχει για δεκαετιες και ειναι δυσκολο να ξαναγραφτει ναι. Για αυτο και ο αντικαστατης της fortran θα πρεπει να ειναι οχι απλα καλύτερος αλλα αρκετά καλύτερος για να ξαναγραφτει ο κώδικας. Αλλά το statement κατα λέξη ειναι off. (Modern numerical analysis can be credibly said to begin with the 1947 paper ... http://history.siam.org/)
      Eπίσης και libarries να ειναι γραμμενα σε C (όπως το widely used fftw για FFT's ) ή σε C++ (όπως petsc και trilinos για parallel linear και non-linear solvers) έχουνε fortran interfaces ωστε να καλούνται ευκολα απο fortran code (ie σε καποιο βαθμό αντίθετο από αυτό που περιεγραψες)

    • από stassa πριν 1169 μέρες 1       

      «Πρώτον όταν λέει ότι η Lisp και η Haskell είναι της σχολής "lambda calculus" ενώ η Fortran είναι της σχολής "Turing machine" προφανώς εννοεί Von Neuman machine»

      Καλά λες κι εγώ δεν κατάλαβα τί ήθελε να πει εκεί ο ποιητής, μάλλον αυτό που λες είναι. Που είναι και λίγο αστείο γιατί ο ίδιος ο Backus είναι που έγραψε για το "Von Neumann bottleneck" και κίνησε το ενδιαφέρον προς τη Lisp και το συναρτησιακό προγραμματισμό (δες http://en.wikipedia.org/wiki/John_Backus).

      «Επίσης σε αυτόν τον κόσμο υπάρχουν στην πραγματικότητα δύο μόνο είδη γλωσσών, αυτές που τείνουν προς τη lisp και αυτές που τείνουν προς τη fortran.»

      Χμμ, δεν ξέρω. Η Lisp κι η Fortran μου φαίνονται πιο ίδιες απ' την άποψη οτι στηρίζονται σε μαθηματικές έννοιες και αδιαφορούν λίγο-πολύ για την αρχιτεκτονική του υπολογιστή, σε αντίθεση πχ με την C και τις γλώσσες τις οικογένειάς της που τις απασχολεί να βάλουνε τα bits στο σωστό register. Ας πούμε, μπορώ να φανταστώ μια Lisp να τρέχει σ' έναν υπολογιστή με μη ηλεκτρονική μνήμη, πχ έναν βιολογικό υπολογιστή ξέρω 'γω, παρομοίως και την Fortran, την Haskell, ML και τις συναφείς, την καλή μου την Prolog και τη SQL κοκ- αλλά όχι σίγουρα την C/C++.

    • από dkamen πριν 1169 μέρες       

      Κοίτα κάθε γλώσσα έχει ένα επίπεδο αφαίρεσης πρακτικά τεράστιο σε σχέση με τη γλώσσα μηχανής στην οποία καταλήγει και αυτό σίγουρα ισχύει και για την τωρινή Fortran, όμως η Fortran *αρχικά* ήταν απλά μια glorified assembly και ό,τι έξτρα abstractions απέκτησε τα απέκτησε πολύ σταδιακά, καθώς οι μηχανές γίνονταν πιο ισχυρές και/ή άλλες γλώσσες έδιναν καλές ιδέες.

      Για παράδειγμα τα 5-10 χρόνια δεν είχε την έννοια της υπορουτίνας και τα επόμενα 15-20 δεν είχε την έννοια του recursion (ή γενικότερα την έννοια μιας υπορουτίνας να καλεί οποιαδήποτε άλλη, συμπεριλαμβανομένου του εαυτού της). Αυτά τα απέκτησε καθώς τα μηχανήματα στα οποία έτρεχε άρχισαν να υποστηρίζουν λειτουργίες στοίβας.

      Υπάρχει δλδ μια ισομορφία ανάμεσα στις δυνατότητες της Fortran και στις δυνατότητες της μηχανής Von Neuman που οδηγά.

      Αντίθετα η Lisp από την αρχή-αρχή ήταν μια "μηχανή Lisp", εντελώς διαφορετική, με facilities υψηλοτάτου επιπέδου όπως garbage collection, τύπους δεδομένων όπως "σύμβολο" και "συνάρτηση", αληθινά συμβολικά conditionals αντίθετα με τα αριθμητικά της Fortran κλπ.

      Δηλαδή η Fortran είναι ο κατεξοχήν εκπρόσωπος της σχολής "performance/κοντά στο hardware" ενώ η Lisp είναι ο κατεξοχήν εκπρόσωπος της σχολής "abstraction/κοντά στις έννοιες". Όλες οι άλλες γλώσσες τείνουν είτε προς τη μία είτε προς την άλλη. Και οι ίδιες όπως εξελίχθηκαν, δλδ η Fortran έγινε αρκετά πιο υψηλού επιπέδου/κομψή αλλά και η Lisp (τουλάχιστον οι διάλεκτοι με πρακτική εφαρμογή) απέκτησε αρκετή "βρωμιά" υψηλών επιδόσεων.



      (σημειωτέον: ΚΑΜΙΑ γλώσσα δε φτάνει τη Fortran σε επιδόσεις και ΚΑΜΙΑ γλώσσα δε φτάνει τη Lisp σε ικανότητα αναπαράστασης εννοιών)

      Στην ουσία δεν έχει συμβεί κάτι συνταρακτικό στις γλώσσες από το 1950. Έχουν συμβεί πολλά καινούρια πράγματα βέβαια αλλά τίποτα τόσο *συνταρακτικό* όσο οι δύο αυτές προσεγγίσεις.

    • από stassa πριν 1168 μέρες       

      Στην ουσία δεν έχει συμβεί κάτι συνταρακτικό στις γλώσσες από το 1950. Έχουν συμβεί πολλά καινούρια πράγματα βέβαια αλλά τίποτα τόσο *συνταρακτικό* όσο οι δύο αυτές προσεγγίσεις.

      Ξέρεις τί θα πω: Logic programming :)

      «ΚΑΜΙΑ γλώσσα δε φτάνει τη Lisp σε ικανότητα αναπαράστασης εννοιών»

      Εξαρτάται πώς το εννοείς αυτό. Η εκφραστική ισχύ της Lisp είναι η εκφραστική ισχύ του lambada, με συγχωρείτε, lambda calculus. Άρα όλες οι γλώσσες του lambda calculus έχουν ισοδύναμη εκφραστική ισχύ με την Lisp. Δεν νομίζω ας πόυμε οτι η Haskell έχει μικρότερη ικανότητα αναπαράστασης εννοιών από τη Lisp.

      Μετά, είναι κι οι γλώσσες του λογικού προγραμματισμού (Prolog, Oz, Gödel, Mercury κλπ) που βασίζονται στις Horn clauses. Εδώ κάπου μου τελειώνει το θεωρητικό υπόβαθρο αλλά έχω την εντύπωση οτι η Horn clause logic είναι ισοδύναμη με τον typed lambda calculus που νομίζω είναι αυτός της Lisp κλπ. Που σημαίνει οτι κι αυτές είναι ισοδύναμες με την Lisp και τις άλλες. Κι αυτό πάντα au fur et a mesure που υφίσταται σύγκριση ανάμεσα σε λογικό και συναρτησιακό προγραμματισμό. Πάνω σ' αυτό έχει γίνει κάποια θεωρητική δουλειά, ή μάλλον γενικότερα στη σχέση μεταξύ συναρτήσεων και λογικής (πχ δες Curry-Howard correspondence), αλλά την ξέρω μόνο σπαστά και αποσπασματικά, οπότε αν τα ξέρεις εσύ καλύτερα, πες.

      Τέλος από πρακτικής άποψης βασικά όλες οι γλώσσες προγραμματισμού που είναι Turing equivalent έχουν την ίδια υπολογιστική κι άρα εκφραστική ισχύ. Κάποιες έχουν εκφραστικά σχήματα που διευκολύνουν την αναπαράσταση κάποιων εννοιών, με κάποιες άλλες πρέπει να κάνεις κωλοτούμπες για να πας πιο πέρα απ' τα βασικά αλλά γενικά όλες πρέπει να τρέξουν πάνω στην αρχιτεκτονική των υπολογιστών μας οπότε όλες είναι το πολύ το ίδιο ισχυρές με τους υπολογιστές μας, κατά βάση. Αυτό με κάποιο δισταγμό σε περίπτωση που παρεξήγησα τί εννοείς με το "αναπαράσταση εννοιών" αλλά μάλλον κατάλαβα τί εννοείς.

      Και πιό τέλος- πιθανόν να υπάρχουν γλώσσες πιο εκφραστικές από τη Lisp, το θέμα είναι πάντα κατά πόσο τρέχουν σε polynomial time. Απ' αυτήν την άποψη σωστά θέτεις τα άκρα στην εκφραστική ισχύ και στην ταχύτητα εκτέλεσης, γιατί μάλλον είναι ψιλοαντίθετα.

      Μ' αρέσει η Lisp btw, δεν τη θάβω, εννοείται. Για κάποιο λόγο μού 'χει κολλήσει η Haskel περισσότερο όμως. Ίσως επειδή είναι πιο καινούργια, ίσως λόγω type system.

      Έδιτ: ΟΚ, δεκτόν οτι από τα '50ς δεν έχουμε κάνει και τεράστια απόσταση. Οι μέηνστρημ γλώσσες μόλις πολύ πρόσφατα αρχίσαν να υιοθετούν συναρτησιακά στοιχεία και ακόμη μερικοί τα θεωρούν 'επαναστατικά', ή αιρετικά ξέρω 'γω.


      «ΚΑΜΙΑ γλώσσα δε φτάνει τη Fortran σε επιδόσεις»

      Αυτό είναι αρκετά ενδιαφέρον και δεν τον είχα συνειδητοποιήσει, ούτε το κατάλαβα διαβάζοντας το άρθρο (δίκιο έχεις, δεν είναι και τρελλά καλό άρθρο). Μιλάμε βέβαια υποθέτω για γλώσσες υψηλού επιπέδου, τουλάχιστον πάνω από assembly, σωστά;

    • από dkamen πριν 1168 μέρες       

      Κοίτα κι εγώ τις σκέφτηκα τις λογικές γλώσσες αλλά στην πραγματικότητα είναι αρκετά εύκολο να τις υλοποιήσεις σε Lisp (συνηθισμένη άσκηση δες λ.χ. κεφ. 24 του "On Lisp"). Και το αντίθετο βέβαια, που σημαίνει ότι δεν πρόκειται για τόσο διαφορετικά πράγματα.

      Βασικά έτσι εννοώ και την εκφραστικότητα, η Lisp όταν χρησιμοποιείται σωστά δεν είναι απλά μια γλώσσα για να γράψεις το πρόγραμμα, αλλά μια γλώσσα για να γράψεις τη γλώσσα στην οποία θα γραφτεί το πρόγραμμα με τον πλέον φυσικό (συντακτικά και εννοιολογικά) τρόπο. Τουλάχιστον αν δε σε πειράζει το notation και οι 500.000 παρενθέσεις.

      Και όπως σωστά παρατηρεί ο ημίθεος Paul Graham κάτι programming patterns για τα οποία επαίρονται οι κατώτερες γλώσσες (με κορυφαία τη Java όπου καταντάει πραγματικά αηδία) στη Lisp είναι δείγμα ότι δεν έχεις περιγράψει το πρόβλημα τόσο καλά όσο θα έπρεπε.

    • από stassa πριν 1167 μέρες       

      «Κοίτα κι εγώ τις σκέφτηκα τις λογικές γλώσσες αλλά στην πραγματικότητα είναι αρκετά εύκολο να τις υλοποιήσεις σε Lisp (συνηθισμένη άσκηση δες λ.χ. κεφ. 24 του "On Lisp"). Και το αντίθετο βέβαια, που σημαίνει ότι δεν πρόκειται για τόσο διαφορετικά πράγματα. »

      Χεχ χεχ χεχ, Prolog σε Lisp, ε; Σχετικά μ' αυτό υπάρχουν κάποιες ενστάσεις:

      -----------------------------------------
      Some online books show how to implement simple "Prolog" engines in Lisp. These engines typically assume a representation of Prolog programs that is convenient from a Lisp perspective, and can't even parse a single proper Prolog term. Instead, they require you to manually translate Prolog programs to Lisp forms that are no longer valid Prolog syntax. With this approach, implementing a simple "Lisp" in Prolog is even easier ("Lisp in Prolog in zero lines"): Manually translate each Lisp function to a Prolog predicate with one additional argument to hold the original function's return value. Done. This is possible since a function is a special case of a relation, and functional programming is a restricted form of logic programming.

      Here is a bit beyond that: lisprolog.pl

      These 157 lines of Prolog code give you an interpreter for a simple Lisp, including a parser to let you write Lisp code in its natural form.
      -----------------------------------------

      Από εδώ: http://www.logic.at/prolog/lisprolog/lisprolog.html


      «Βασικά έτσι εννοώ και την εκφραστικότητα, η Lisp όταν χρησιμοποιείται σωστά δεν είναι απλά μια γλώσσα για να γράψεις το πρόγραμμα, αλλά μια γλώσσα για να γράψεις τη γλώσσα στην οποία θα γραφτεί το πρόγραμμα με τον πλέον φυσικό (συντακτικά και εννοιολογικά) τρόπο. Τουλάχιστον αν δε σε πειράζει το notation και οι 500.000 παρενθέσεις. »

      Αυτό είναι που λέμε "meta-linguitsic abstraction" και θα έπρεπε να το διδάσκουνε στο Computer Science ως την 'φυσική' μέθοδο προγραμματισμού. Ίσως όχι με Lisp μόνο :)

      Και οι αντικειμενοστραφείς γλώσσες όμως έχουνε βοηθήματα γι' αυτό το στυλ προγραμματισμού. Βασικά όταν αρχίζεις να χτίζεις οντολογίες τάξεων και μεθόδων για να περιγράψεις το πρόβλημά σου, ε, με λίγα λόγια χτίζεις μια γλώσσα για να μιλήσεις για το πρόβλημα. Γι' αυτό νομίζω μας μαθαίνουνε να ονομάζουμε τις τάξεις και τα αντικείμενα ως ουσιαστικά και τις μεθόδους ως ρήματα.

      Για κάτι τέτοια όμως σούπερ αστέρι είναι η Prolog, χάρη στις Definite Clause Grammars, που βασικά είναι ισοδύναμες με Context Free Grammars, ή και non-CFG με την προσθήκη παραμέτρων. Δες στι Βίκι για μια γρήγορη ειαγωγούλα: http://en.wikipedia.org/wiki/Definite_clause_grammar

      Ας πούμε, ένα απλό πρόγραμμα σε Prolog που αναπαριστά τη γλώσσα L με αλφάβητο Σ = {a, b, c} είναι το εξής:

      ------------------
      l --> [].
      l --> [a], l.
      l --> [b], l.
      l --> [c], l.
      ------------------
      „
      Εκτελούμε με:

      ?- X = 2, length(L, X), l(L, []).
      L = [a, a] ;
      L = [a, b] ;
      L = [a, c] ;
      L = [b, a] ;
      L = [b, b] ;
      L = [b, c] ;
      L = [c, a] ;
      L = [c, b] ;
      L = [c, c].

      Και γενικότερα, με Χ = ν > 0 , λαμβάνουμε τις ν! λέξεις με μήκος ν που ανήκουν στη L.

      Πιό φυσικό απ' αυτό δεν γίνεται :)


      «Τουλάχιστον αν δε σε πειράζει το notation και οι 500.000 παρενθέσεις.»

      Ή, όπως λέει και το ανέκδοτο:
      A Chinese spy manages to steal the last 50MB of the program governing U.S. missile launches. Fortunately, it was all closing parentheses.

    • από stassa πριν 1167 μέρες       

      Και όπως σωστά παρατηρεί ο ημίθεος Paul Graham κάτι programming patterns για τα οποία επαίρονται οι κατώτερες γλώσσες (με κορυφαία τη Java όπου καταντάει πραγματικά αηδία) στη Lisp είναι δείγμα ότι δεν έχεις περιγράψει το πρόβλημα τόσο καλά όσο θα έπρεπε.

      Απ' την εμπειρία μου, ένα σημαντικό κομμάτι των επαγγελματιών προγραμματιστών θα πειθότανε πολύ δύσκολα να μάθει Lisp, έστω και με το επιχείρημα οτι δεν θα χρειάζεται να χρησιμοποιεί πια design patterns. Τί να μη χρειάζεται δηλαδή, αφού δεν τα χρησιμοποιούνε ήδη- επειδή είναι "complicated". Ας πούμε, το state είναι πιο μπελάς από πενήντα γραμμές switch statment με δυο-τρία conditionals σε κάθε case... και το κάθε conditional να σε πετάει σε μια μέθοδο με άλλα δυο-τρία conditionals ή ένα καινούργιο switch (αυτό τώρα ήτανε και καλά abstraction, που δεν τα είχανε όολα μέσα στο ίδιο switch). Εμένα πάντως αυτό το switch μου πήρε μια βδομάδα να το ξεμπλέξω (I got better). Το είχανε αφήσει μέσα στη μέση μιας εφαρμογής σχεδόν δέκα ετών, από καταβολής της και δεν τολμούσανε να το ακουμπήσουνε μην και χαλάσει τίποτα. Μια φρίκη, σαν τον Ούμπο-Σάθλα. Τί έχουνε δει τα μάτια μου... Φαντάσου τώρα να δώσεις και Lisp σε κάτι τέτοιους. Χαθήκαμε. Άσε, καλή είναι κι η Java.

    • από dkamen πριν 1166 μέρες       

      τι να σου πω εγώ έχω αντίθετη γνώμη, δε γίνεται να κόβεται η σύνδεση και να παίρνεις 500 γραμμές stack trace που οι πιο πολλές είναι για εντελώς άσχετα factories και builders που παρεμβάλλονται. Πολλά εργαλεία κόβουν το stack trace γύρω στο 30ο επίπεδο και το αντικαθιστούν με "..." με αποτέλεσμα να μην έχεις ιδέα τι διάολο δε δούλεψε :)

  • από dkamen πριν 1171 μέρες 1       

    Ok μόλις μόλις διάβασα το fa και είναι ανακριβες. Πρώτον όταν λέει ότι η Lisp και η Haskell είναι της σχολής "lambda calculus" ενώ η Fortran είναι της σχολής "Turing machine" προφανώς εννοεί Von Neuman machine (πάρα πολύ μεγάλη διαφορά γιατί το δεύτερο είναι μια abstract περιγραφή ενός κανονικού υπολογιστή σαν αυτούς που χρησιμοποιούμε, ενώ η μηχανή Turing είναι μια θεωρητική έννοια παρόμοια με το lambda calculus).

    Δεύτερον δεν ξέρω για τη Julia αλλά καμία από τις άλλες δύο γλώσσες που αναφέρει (Haskell και Clojure) δε σχεδιάστηκε με γνώμονα να αντιπαρατεθεί στη Fortran ή έστω να χρησιμοποιηθεί στα ίδια domains. Η Haskell χρησιμοποιείται κυρίως στην έρευνα πάνω σε compilers και τέτοια, η Clojure είναι απλά μια JVM υλοποίηση της Lisp.

    Επειδή έχουν "συναρτήσεις" αυτό δεν τις κάνει αυτομάτως πιο κατάλληλες για *υπολογισμούς* και σε αυτό το σημείο ο συγγραφέας δείχνει πάρα πολλή ρηχότητα (όπως και όταν επικαλείται το strict type checking της Haskell σαν κάτι που περιορίζει τα αριθμητικά λάθη).

    • από th.alys πριν 1171 μέρες 1       

      Δεν ξέρω για την Haskell και Clojure έχω δει μόνο μια φορά που έψαχνα να δω περίεργες γλώσσες για πλάκα. Η Julia όμως δημιουργήθηκε με σκοπό να χρησιμοποιηθεί σε υπολογιστικά προβλήματα. Βασικά σχεδιάζουν να επιτύχουν ταχύτητες Fortran(για την ώρα έχουν πιάσει C) με την ομορφιά του κώδικα της Python(το συντακτικό τους μοιάζει πολύ).

      Μοιάζει ωραίο εγχείρημα, το έχουν υιοθετήσει και geeks σε τυπικά geekομέρη, αλλά προς το παρόν δεν βλέπω γιατί να την προτιμήσω από την original Python, την R ή το Matlab/Octave. Και φυσικά Fortran αν έκανα κάτι που την απαιτούσε. Στα δικά μας πχ structural estimation δίχως Fortran δεν γίνεται.

      Μακάρι να πετύχει, αλλά εκτός συγκλονιστικού απροόπτου, θα περάσουν τουλάχιστον 10-15 χρόνια ακόμα στα οποία το τοπίο δεν θα αλλάξει δραματικά. Αν μη τι άλλο λόγω αδράνειας και κόστους της αλλαγής.

  • από dkamen πριν 1165 μέρες       

    ,


Log in για σχολιασμό ή γίνε μέλος εδώ.

Ποιά μέλη του buzz ψήφισαν αυτή την καταχώριση