Έβλεπα προχτές αυτά τά καταπληκτικά video(1, 2) στο Channel9 απο το JAOO, όπου "πρωταγωνιστεί" ο κύριος (Dr) Joe Armstrong. Ο Joe λέει, δούλευε στα εργαστήρια της Ericsson, όπου δημιούργησαν μια γλώσσα προγραμματισμού, την Erlang, ή οποία είναι functional και dynamically typed, αλλά το κύριο χαρακτηριστικό της είναι ότι είναι τρελά concurrent-able. Παραλληλίζει απο φύσης ας πούμε.

Στο video λοιπόν, ο Joe υποστηρίζει ότι ο τρόπος με τον οποίο προγραμματίζουμε, δεν ανταποκρίνεται στο φυσικό κόσμο. Με την έννοια, ότι δεν υπάρχει shared state, κάποιο αντικείμενο ή ιδέα, το οποίο να μοιράζεται σε παραπάνω απο έναν.

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

Ακόμη κι αυτό ήταν δυνατό, τα μοντέλα θα ήταν ακόμη δύο. Δε μοιράζονται. όπως και τίποτα δε μοιράζεται, στην πραγματικότητα ... (καλό ε)

Λέει επίσης, ότι ο τρόπος που γράφουμε κώδικα, κατα συνέπεια, δεν είναι λογικός.

Σε μια μαθηματική "φράση", δε θα γράφαμε ποτέ χ = χ + 1. Μάλιστα κάποιος θα κοίταζε απορημένος την έκφραση αν δεν είχε προγραμματιστικό background.

Ο τρόπος του functional κόσμου είναι να μη μοιράζεις μεταβλητές μεταξύ λειτουργικότητας. Κομμένο το ByRef δηλαδή στη VB, και μόνο value types ή όλες οι μεταβλητές readonly και προσεχτικά, αν γράφεις C#. [**]

Η αλήθεια είναι ότι αν το σκεφτείς, συνήθως όταν βρίσκεις τον εαυτό σου πάνω απο ένα debugger τελικά κυνηγάς μια μεταβλητή της οποίας η τιμή είναι λάθος, και ψάχνεις να βρείς  π ο ι ό ς  και  π ό τ ε  έθεσε τη λάθος τιμή - λέει πάλι ο Joe κάπου στο video.

Το σκέφτηκα λίγο, κι έχει δίκιο ... :D




** - Δεν είναι τόσο hardcore όλοι, αυτή είναι η αρχή, αλλά αυτό δε σημαίνει ότι δεν υπάρχουν functional γλώσσες που να προσεγγίζονται απο θνητούς ... .

---

Angel
O:]

Όταν λέμε x = x + 1 στον προγραμματισμό στην πραγματικότητα ο συμβολισμός δεν είναι μαθηματικός άρα το να τον κοιτάξουμε με μαθηματικό τρόπο είναι τελείως λανθασμένος.

Στην συγκεκριμένη περίπτωσή όταν λέμε χ δεν εννοούμε κάποια άγνωστή μεταβλητή με τον μαθηματικό τρόπο σκέψεις. Εννοούμε κάποια καταχωρημένη θέση σε κάποιο μοντέλο αποθήκευσης. Όπως όταν γράφουμε χ = χ + 1 δεν εννοούμε αυτό που σημαίνει στο μαθηματικό τύπο. Αλλά ότι στην συγκεκριμένη θέση μνήμης (που έχει έναν αριθμό) προσθέτουμε στον αριθμό του + 1.

Ο τρόπος που προγραμματίζουμε μοιάζει πολύ με τις γλώσσες (πλην της ελληνικής κατά την δική άποψη). Η κάθε λέξη άπλα συμβολίζει κάτι και δεν είναι αποτέλεσμα ούτε μαθηματικών τύπων ούτε λογικής συνάρτησις

Δηλαδή ότι cat = ένα ζώο με συγκεκριμένες ιδιότητες , δεν έχει κάποια λογική . Απλά είπαμε στην τύχη ότι θα το ονομάζουμε έτσι . Βέβαια δεν μπορούμε να ξέρουμε αν η τύχη υπακούει σε κάποιους ανώτερους κανόνες που δεν μπορούμε να καταλάβουμε( Αυτό όμως είναι άλλο).

Έτσι ακριβός συμβαίνει και με τον προγραμματισμό ... έχουμε πει ότι "κάτι συγκεκριμένο" = "αυτό το πράγμα" . Δεν νομίζω ότι είναι κάτι το παράλογο.

Νομίζω κι εγώ το ότι να επιχειρήσεις να αλλάξεις τις υπάρχουσες γλώσσες, έτσι ώστε να υπακούουν ένα "μαθηματικό" συμβολισμό, είναι ουτοπικό. Τουλάχιστον για το mainstream κόσμο.

Το επιχείρημα όμως ότι τo να μή μοιράζεσαι state είναι πολύ καλή πρακτική τόσο για τα λιγότερα λάθη που θα προκύψουν, όσο και για τον πιθανό παραλληλισμό μιας διαδικασίας, είναι πιστεύω valid. Και μας σπρώχνουν "διακριτικά" προς τα 'κεί, δίνοντάς μας LINQ, Workflow και εύκολα services.

Ίσως σε μερικά χρόνια, με τον ένα τρόπο ή τον άλλο, κάθε "node" λειτουργικότητας να έχει μειωθεί σε ένα input -> process -> output structure, υλοποιημένο ως ένα service. Χρησιμοποιώντας Workflow "δένεις" αυτά τα αυτόνομα nodes μεταξύ τους σε "αλυσίδες" ώστε να δημιουργήσεις έτσι με τη σύνθεση τη λύση στο πρόβλημά σου.

Ίσως όμως με τα features που θα έρθουν στις γλώσσες, να μπορείς σύντομα εύκολα να προγραμματίσεις έτσι, στο επίδεδο του source κώδικα που γράφεις κάθε μέρα. Έτσι ώστε, αν θές, το χ = χ + 1 να μην ισχύει πλέον - ή ακόμη καλύτερα, να μη χρειάζεται να ισχύει, γιατί δεν προγραμματίζεις πλέον έτσι !

---

Angel
O:]

anjelinio:

Σε μια μαθηματική "φράση", δε θα γράφαμε ποτέ χ = χ + 1. Μάλιστα κάποιος θα κοίταζε απορημένος την έκφραση αν δεν είχε προγραμματιστικό background.

Σε μια  μαθηματική φράση δεν θα βάζαμε ουτε το 1+1=10   και να ειχε προγραμματιστικο background ,θα το κοιτουσε απορημενος. αν δεν σκεφτοταν δυαδικά.
                                                                    

anjelinio:

Ο τρόπος του functional κόσμου είναι να μη μοιράζεις μεταβλητές μεταξύ λειτουργικότητας. Κομμένο το ByRef δηλαδή στη VB, και μόνο value types ή όλες οι μεταβλητές readonly και προσεχτικά, αν γράφεις C#. [**]

 Πιο ευκολα θα λυνω τα προβληματα μου, σχεδιαζοντας hardwares με πύλες NAND. :P


Ο τυπος ειναι fan του low-level programming.....

Διαβάζω το post σου, και χαμογελάω γιατί πριν 5 χρόνια θα έλεγα κι εγώ τα ίδια φίλε μου. Χρειάζεται να περάσεις απο ένα "complexity threshold"  και να ξανα-ανακαλύψεις αρκετούς functional τροχούς  πριν το "πιάσεις" - όχι ότι το έχω κι εγώ "πιάσει" ακόμα, έτσι;

Πάντως, οι περισσότερες εταιρίες που ασχολούνται με χρηματο-οικονομικά, derivatives, risk managment, physics, simulation και οτιδήποτε εμπλέκει βαρύ computation είναι κατα παράδοση functional, και η μαμά Microsoft έχει βγάλει μια functional γλώσσα για .NET, την F#, με την οποία παίζω τα βράδια σε VS 2005 & VS 2008.

Μεγάλες ( μέγιστες ) εταιρίες, τις οποίες όμως εμείς οι "ταπεινοί" προγραμματιστές δε θα μάθουμε ποτέ, γράφουν χρόνια σε OCaml και διατυμπανούν "F# Hackers welcome".


 ... αν κάποιος λοιπόν δε θέλει να δεί τα σημάδια ...

---

Angel
O:]

Μην σας φαίνεται περίεργη η λογική των functional γλωσσών, ούτε είναι low-level ο Armstrong. Ίσα-ίσα, είναι πολύ high level. Αυτό τον καιρό γίνεται πάρα, μα πάρα πολύ συζήτηση για τις functional γλώσσες στο χώρο του .NET, και ειδικά για την F#. Ο λόγος είναι ότι οι functional γλώσσες είναι η μόνη πρακτική επιλογή για τη δημιουργία εφαρμογών που θα εκμεταλλεύονται multi-core υπολογιστές. Σήμερα έχουμε quad-core τσιπάκια, αύριο θα έχουμε 8 ή 16, σε συστοιχίες 4+ επεξεργαστών, για ένα σύνολο 8 (σήμερα) μέχρι ...ήντα επεξεργαστές πολύ σύντομα.

Οι τεχνικές που χρησιμοποιούμε οι περισσότεροι για multi-threading επεξεργασία είναι εξαιρετικά αργές , βαρειές και δύσκολες στον προγραμματισμό - για δύο επεξεργαστές. Σε περιβάλλον περισσότερων επεξεργαστών καλά-καλά δεν υπάρχει μαθηματική απόδειξη ότι μπορούν να δουλέψουν σε παραπάνω από δύο επεξεργαστές (δηλαδή, μπορεί η εφαρμογή σου που δουλεύει φέτος, να έχει deadlock του χρόνου) ενώ δεν υπάρχει εύκολος τρόπος να χρησιμοποιήσεις όλους τους επεξεργαστές που έχει το μηχάνημα αν δεν ξέρεις εκ των προτέρων πόσοι είναι. Καθώς οι ταχύτητες των επεξεργαστών έπαψαν να αυξάνονται, οι επιδόσεις του multithreading χτύπησαν ταβάνι

• Το multithreading είναι αργό γιατί δεν εκμεταλλεύεται τους επεξεργαστές και την τοπολογία τους για ένα task, αλλά απαιτεί να σπάσει το task σε πολλά threads.
• Είναι βαρύ γιατί κάθε thread έχει ένα πολύ μεγάλο overhead και υπόκειται σε thread-switching το οποίο είναι επίσης βαρύ
• Δύσκολο ... δεν χρειάζεται να το πούμε αυτό. Η πολυπλοκότητα ενός προβλήματος αυξάνεται συνδυαστικά με τον αριθμό των επεξεργαστών. Και δεν μιλάμε να εκμεταλλευτεί κανείς NUMA αρχιτεκτονικές, όπου ο κάθε επεξεργαστής έχει ένα γρήγορο bus προς τη δική τουνήμη

Στην καρδιά του προβλήματος είναι ότι αντί να λέμε στον υπολογιστή τί θέλουμε να υπολογίσει, του λέμε πως να το υπολογίσει και μάλιστα πως να στήσει τη stack του, τα locks του, ένα κάρο πράγματα άσχετα με τον υπολογισμό. Ένα λάθος και έγινε χαμός. Οι functional γλώσσες λύνουν το πρόβλημα γιατί μας επιτρέπουν να πούμε τί θέλουμε να υπολογίσουμε και μετά η γλώσσα (o compiler, o interpreter, κάποιος optimizer) επιλέγει τον καλύτερο τρόπο να το κάνει αυτό. Εμείς λέμε π.χ. ότι ένας πίνακας είναι το γινόμενο δύο άλλων πινάκων. Η γλώσσα θα αναλάβει να σπάσει τους πίνακες στους 32 επεξεργαστές, να φροντίσει να μην υπάρχει locking, να φορτώνονται σωστά οι cache των επεξεργαστών κλπ.

Κλασσικό παράδειγμα functional γλώσσας είναι η .... SQL. Σε ένα select λέμε τί θέλουμε να μας φέρει, όχι πως, με ποια σειρά θα διαβάσει το σκληρό, ποιούς buffer θα χρησιμοποιήσει, ούτε καν ποιά indexes ή πως θα κάνει τα joins. Στο 99% των περιπτώσεων ένα σωστά φτιαγμένο select είναι δεκάδες ή εκατοντάδες φορές ταχύτερο από ένα cursor, ακριβώς γιατί η κάθε βάση καταφέρνει να βρει ένα πολύ καλύτερο τρόπο εκτέλεσης του query απ' ότι ο προγραμματιστής. Η βάση ξέρει και τί επεξεργαστές έχει, πόση διαθέσιμη μνήμη και πόσους χρήστες οπότε μπορεί να βρει ένα πολύ καλύτερο τρόπο εκτέλεσης.

Οι functional γλώσσες προβλέπεται να γίνουν mainstream σε μερικά χρόνια ... πως λέμε 1-2 και να παραμείνουν και ειδικά στο χώρο του .NET. Αυτό οφείλεται στο ότι η Microsoft έχει ήδη μία functional .ΝΕΤ γλώσσα, την F# η οποία μπορεί να δουλέψει μαζί με οποιαδήποτε άλλη γλώσσα του .NET στα πλαίσια μίας εφαρμογής. Μπορείς άνετα να φτιάξεις το GUI σε C# ή VB.NET (φτου, φτου) και τους αλγόριθμους σε F#

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

Άγγελε, κάντο αυτό οι σοβαρές εταιρείας που ασχολούνται με χρηματοοικονομικά. Εκτός Ελλάδος, αυτές οι εταιρείες χρησιμοποιούν ακόμα C++ και τα multithreading libraries της Intel για να πετύχουν τη μέγιστη δυνατή απόδοση - γιατί τους ενδιαφέρει ο πολύ γρήγορος κώδικας. Για φαντάσου να είσαι η JP Morgan και να πρέπει να πάρεις αποφάσεις σε real-time για συναλλαγές δις, υπολογίζοντας δείκτες για τις συναλλαγές της τελευταίας ώρας.

Εντός Ελλάδος, κάποιοι παραμένουν σε VB6 κι ας θέλει μέρες να βγάλουν ένα report γιατί ... φοβούνται να αλλάξουν τον κώδικα (Γειά σου Γιώργο! Και χαιρετίσματα σε όσους φάγαμε τις περσινές γιορτές στη δουλειά και τη Ρουμανία! )

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

Θα συμφωνήσω απόλυτα με τους φίλους Παναγιώτη και Άγγελο.

Ο συνδυασμός OOP + FP είναι το μέλλον... η F# είναι μια πολύ pragmatic υλοποίηση και πιστεύω ότι θα γίνει η elite γλώσσα στο .net

(Όσοι φίλοι παίζουν με JVM ας δουν και την Scala)

---

Palladinos Nick
Software Engineer
-----------------------
The limits of my language mean the limits of my world. (Ludwig Wittgenstein)