Ένα πολύ ενδιαφέρον blog entry σχετικά με το Static vs Dynamic typing. Τελικά για άλλη μια φορά φαίνεται ότι ο κόσμος δεν είναι μαύρος ή άσπρος...

Πάντως, όπως λέει και ο συγγραφέας του άρθρου, τώρα που το ζητούμενο είναι να ενσωματωθεί η υποστήριξη σε τύπους από τον XML και σχεσιακό κόσμο πιο βαθιά στο CLR, να που η "κληρονομιά" (μιλάω για το Option Strict) που έχει αφήσει το μαύρο πρόβατο που λέγεται VB βγαίνει σε καλό στη VB.NET...

Υ.Γ. Εκεί στο Panopticon, ρίξτε και μια ματιά σε αυτά τα απίθανα FAQs

Χωρίς να θέλω να αρχίσω κανένα καβγά ανάμεσα στους θιασώτες της VB.NET με αυτούς της C#, σημειώνω την άποψή μου ότι το άρθρο "static typing when possible and dynamic typing when needed" ναι μεν εξηγεί αναλυτικότατα και ορθώς το σκεπτικό του γράφωντος αλλά, δεν με κάνει να ξεχνάω ποτέ ότι η χρήση dynamic typing θα με αναγκάσει να κάνω επιπλέον διαχείριση με κώδικα πιθανών runtime type erros.Παράλληλα γνωρίζω ότι ο πολυμορφισμός στον αντικειμενοστρεφή προγραμματισμό (αχ πόσο δεν μου αρέσουν τα ελληνικά για αυτά τα θέματα) μου επιτρέπει να λύσω μάλλον όλα τα θέματα για τα οποία θα μπορούσα εναλλακτικά να καταφύγω σε dynamic typing.

Με λίγα λόγια έχω την αίσθηση ότι αν σχεδιάσεις σωστά την αρχιτεκτονική της εφαρμογής σου μπορείς να τα κάνεις όλα μια χαρά με strongly typed γλώσσες (όπως ή C#) και να έχεις και το κεφάλι σου ήσυχο πως αυτά που γράφεις στον κώδικά σου είναι απολύτως αντίστοιχα με το μονέλο που σχεδίασες για την λύση που υλοποιείς.

Μια και το πιάσαμε το θέμα θα ήθελα πολύ να δω μια πραγματική συγκεκριμένη περίπτωση όπου πραγματικά μπορείς να δώσεις μια καλύτερη λύση χρησιμοποιώντας dynamic typing σε VB.NET από την αντίστοιχη λύση που μπορείς να δώσεις σε C#.

Α! Επίσης! Μόλις το είδα!

Δες στο παρακάτω post τι παθαίνει κανείς χωρίς strong typing

http://www.dotnetzone.gr/cs/forums/3275/ShowPost.aspx

(Πολύ ελαφρύ παράδειγμα για το θέμα που πιάσαμε αλλά σχετικότατο side-effect του ίδιου θέματος).

Η πραγματική και συγκεκριμένη περίπτωση που λες είναι ακριβώς αυτή η ανάγκη που περιγράφει ο Paul Vick στο blog, δηλαδή το πως θα γίνει το βαθύτερο integration των τύπων του XML και relational κόσμου (όπου οι συγκεκριμένοι τύποι είναι αρκετά διαφορετικοί σε σχέση με αυτούς του CLR) μέσα στο CLR. Και μάλιστα απ'ότι φαίνεται είναι κάτι που απασχολεί αρκετά και την ομάδα ανάπτυξης της C# ώστε να ψάχνονται προς αυτή την κατεύθυνση. Ενδέχεται τέτοιου είδους προβλήματα να λύνονται περνώντας στο dynamic typing ενώ η πλειοψηφία των εφαρμογών και δει του επιχειρηματικού κόσμου, να έχει περισσότερα να χάσει παρά να κερδίσει από το dynamic typing...

Πάντως, όπως και να έχει, υπάρχουν πλεονεκτήματα και μειονεκτήματα στο κάθε "στρατόπεδο" και γι αυτό έγραψα ότι ο κόσμος δεν είναι μαυρόασπρος... Σαφώς προτιμώ το static typing αλλά δε νομίζω ότι θα το προτιμούσε και κάποιος admin (αν ήξερε τι σημαίνει ο όρος τέλος πάντων) που μαθαίνει VBScript για να κάνει απλές δουλίτσες στον server του. Εξάλλου, θα πρέπει τελικά να υπάρχει και κάποιος λόγος που η Microsoft (έμμεσα ή άμεσα) αναπτύσσει ή/και υποστηρίζει γλώσσες όπως η IronPython, η JScript.NET και η Phalanger

Edit: Το είδα αφού έκανα το post... Αυτός ο κάποιος που αναφέρεσαι είμαι εγώ Δεν κατάλαβα, τι έπαθα; Και πως σχετίζεται με το strong typing;   

Καλημέρα,

Σχετικά με το αναφερόμενο post:

To for each loop σου ήταν γραμμένο σε VB.NET. Εάν η γλώσσα δεν υποστήριζε dynamic typing θα απαιτούσε να έχεις δηλώσει τον τύπο του item (for each <item> in <collection>). Αν το απαιτούσε φυσικά και δεν θα σου διέφευγε ούτε επίτηδες ούτε κατά λάθος

Σχετικά με το θέμα μας:

Συμφωνώ με το σκετπικό σου και κάπως έτσι είναι τα πράγματα. Προφανώς και χρειάζονται γλώσσες (ειδικά στους μη προγραμματιστές) που να αφαιρούν την "πολυπλοκότητα" που επιβάλει η "αυστηρότητα" του strong typing. Ακόμα και για τους προγραμματιστές είναι συχνά χρήσιμες. Απλά εγώ έχω συνηθίσει όταν αναφέρομαι σε προγραμματισμό να εννοώ compiled γλώσσες που φτιάχτηκαν για "πιο βαριές δουλειές"  ας το πούμε. Το argument όμως τοποθετείται στον χώρο της ανάπτυξης συστημάτων. Όταν δηλαδή ξεκινάς να φτιάξεις μια εφαρμογή που θα καταλήξει να έχει πολλές χιλιάδες γραμμές κώδικά και η οποία θα κληθεί να ανταπεξέλθει σε ζήτηση από πολλούς ταυτόχρονους χρήστες, θα αναπτυχθεί από πολλούς developers κλπ, τότε σίγουρα απαιτείται μια "αυστηρότητα" και κάποιοι στοιχειώδεις bottom-line κανόνες οι οποίοι θα σε βοηθήσουν όχι μόνο να μην την γεμίσεις λάθη και παραλέιψεις, αλλά και να μπορείς να κάνεις αλλαγές μετά από ένα χρόνο (π.χ.) χωρίς να χρειάζεται να την ξαναδιαβάσεις όλη από την αρχή.

Πριν ένα μήνα (για παράδειγμα) ξεκίνησα να κάνω μια αλλαγή στον Thesseus (το λογισμικό που τρέχει στα ΚΕΠ του Δήμου Αθηναίων) η οποία ήταν βαθιά διαρθρωτική αλλαγή. Άλλαξα όλα τα primary keys στην βάση δεδομένων από int/identity σε uniqueidentifier/rowguid. Η εφαρμογή έχει σχεδόν 300.000 γραμμές κώδικα. Αλλοίμονό μου αν έκανε compile πάραυτα! Μόλις τα άλλαξα, δεν έκανε πια compile. Διόρθωνα ένα ένα τα compilation errors τα οποία οφείλονταν στην αλλαγή του τύπου δεδομένων των πεδίων και όταν πια τα είχα διορθώσει όλα ήξερα ότι η εφαρμογή έτρεχε όπως πριν. Χωρίς την αυστηρότητα του compiler στα data types θα έπερεπε να την ψάχνω γραμμή γραμμή για να δω τι, που και πως πρέπει να αλλάξω ώστε να δουλέυει κανονικά χωρίς να αντιληφθούν οι χρήστες την παραμικρή αλλαγή (bug κλπ).

Η γνώμη μου σε σχέση με το XML/Relational integration στο CLR (αντίστοιχα και για το java runtime) δεν έχει να κάνει τόσο με το dynamic typing όσο με την δημιουργία μιας internetικής υποδομής αντίστοιχης με το DNS. Δηλαδή ένας συνδυασμός των πραγμάτων που ήδη ξέρουμε και χρησιμοποιούμε με αξιοποίηση των XML namespaces, των Web Services κλπ στην κατεύθυνση του να έχουν τα συστήματα πρόσβαση στον κατάλληλο κώδικα για την διαχείριση των κατάλληλων δεδομένων χωρίς να απαιτείται να κάνεις υποθέσεις πριν to compilation για το τι δομικές αλλαγές θα γίνουν στα δεδομένα σου μετά το compilation. Μεγάλη κουβέντα είναι τώρα αυτή που λέω αλλά ας πούμε ότι είναι ένα gut feeling ή η κατεύθυνση προς την οποία θα το έψαχνα εγώ αν συμμετείχα σε αυτές τις ομάδες. Για να καταλάβεις καλύτερα τι εννοώ σκέψου πως παιρνώντας στον OO προγραμματισμό από τον procedural φτιάξαμε κλάσεις για να εισάγουμε την ένοια του data hidding και encapsulation κλπ, έτσι αντίστοιχα μπορούμε να φτιάξουμε ένα μοντέλο το οποίο θα κάνει κάτι αντίσοιχο χρησιμοποιώντας web services (ας πούμε "web classes") οι οποίες θα μπορούν να εντοπίζουν η μία την άλλη μέσα από ένα σύστημα όπως το DNS αλλά με αναφορά τα XML namespaces και θα "μιλάνε" με την κατάλληλη version της κατάλληλης web class για διαχειριστούν δεδομένα που θα μπορούν να αλλάζουν δομή (άρα και type) μετά το compilation χωρίς recompilation.

That said,  δεκτό το XML/relational παράδειγμα αν και θολό ακόμα ως πεδίο. Όμως επέτρεψε μου να επιστρέψω στο θέμα που είχα θέσει αρχικά. Έχει κάποιος να μας δώσει κάποιο παράδειγμα όπου η λύση dynamic typing είναι καλύτερη από την λύση strong typing; Εννοώ δηλαδή κάτι πιο καθημερινό, πιο συγκεκριμένο και λιγότερο "μελλοντικό" από το XML/Relational data integration στo CLR το οποίο κατά τη γνώμη μου έχει να κάνει περισσότερο με Object/Relational integration (στις ίδιες databases και στο data layer), παρά με dynamic vs strong typing. Ένα παράδειγμα ας πούμε που θα μπορούσε να μας δώσει το συμπέρασμα ότι ίσως τελικά να πρέπει η C# να αποκτήσει dynamic typing.

rousso wrote:

Σχετικά με το αναφερόμενο post: To for each loop σου ήταν γραμμένο σε VB.NET. Εάν η γλώσσα δεν υποστήριζε dynamic typing θα απαιτούσε να έχεις δηλώσει τον τύπο του item (for each <item> in <collection>). Αν το απαιτούσε φυσικά και δεν θα σου διέφευγε ούτε επίτηδες ούτε κατά λάθος

Χμμμ... Ή εγώ δεν καταλαβαίνω τι θέλεις να πεις, ή δεν κατάλαβες κάτι στο παραπάνω post...

Στη VB.NET το dynamic/static typing υποστηρίζεται από το statement "Option Strict On/Off" ενώ είναι υποχρεωτική η δήλωση των μεταβλητών κατά το statement "Option Explicit On/Off" (τα λέω αυτά γιατί απ'ότι κατάλαβα είσαι C# developer). Έτσι λοιπόν, το θέμα του post ήταν ότι εγώ απλά πάντοτε χρησιμοποιούσα το

Dim a as apple
For Each a In ApplesList...

αντί του in-line declaration: For Each a as apple In ApplesList...

Και να μην υποστήριζε η VB dynamic typing, δεν θα άλλαζε τίποτα καθώς ο τύπος πάντοτε απαιτείται να δηλώνεται.

rousso wrote:

Σχετικά με το θέμα μας: Συμφωνώ με το σκετπικό σου και κάπως έτσι είναι τα πράγματα. Προφανώς και χρειάζονται γλώσσες (ειδικά στους μη προγραμματιστές) που να αφαιρούν την "πολυπλοκότητα" που επιβάλει η "αυστηρότητα" του strong typing. Ακόμα και για τους προγραμματιστές είναι συχνά χρήσιμες. Απλά εγώ έχω συνηθίσει όταν αναφέρομαι σε προγραμματισμό να εννοώ compiled γλώσσες που φτιάχτηκαν για "πιο βαριές δουλειές"  ας το πούμε. Το argument όμως τοποθετείται στον χώρο της ανάπτυξης συστημάτων. Όταν δηλαδή ξεκινάς να φτιάξεις μια εφαρμογή που θα καταλήξει να έχει πολλές χιλιάδες γραμμές κώδικά και η οποία θα κληθεί να ανταπεξέλθει σε ζήτηση από πολλούς ταυτόχρονους χρήστες, θα αναπτυχθεί από πολλούς developers κλπ, τότε σίγουρα απαιτείται μια "αυστηρότητα" και κάποιοι στοιχειώδεις bottom-line κανόνες οι οποίοι θα σε βοηθήσουν όχι μόνο να μην την γεμίσεις λάθη και παραλέιψεις, αλλά και να μπορείς να κάνεις αλλαγές μετά από ένα χρόνο (π.χ.) χωρίς να χρειάζεται να την ξαναδιαβάσεις όλη από την αρχή.

Εμ... Θα έπρεπε κι εσύ να βάλεις τα specifications εκ των προτέρων... Σου έδωσα δύο παραδείγματα και τα έκανες ...disqualified. Πάντως, όπως είδες, το είπα κι εγώ ότι σε enterprise/commercial development το dynamic typing συνεπάγεται περισσότερα προβλήματα απ'όσα λύνει, κύρια στο θέμα που έθιξες, αυτό της συντήρησης των εφαρμογών. Πάντως, δεν θα μπορούσα να τα πω καλύτερα από τον Διομήδη Σπινέλλη (αναφέρεται στη Java αλλά όλα αυτά ισχύουν και για το .NET): http://www.dmst.aueb.gr/dds/pubs/jrnl/2005-IEEESW-TotT/html/v22n3.html

rousso wrote:

Η γνώμη μου σε σχέση με το XML/Relational integration στο CLR (αντίστοιχα και για το java runtime) δεν έχει να κάνει τόσο με το dynamic typing όσο με την δημιουργία μιας internetικής υποδομής αντίστοιχης με το DNS. Δηλαδή ένας συνδυασμός των πραγμάτων που ήδη ξέρουμε και χρησιμοποιούμε με αξιοποίηση των XML namespaces, των Web Services κλπ στην κατεύθυνση του να έχουν τα συστήματα πρόσβαση στον κατάλληλο κώδικα για την διαχείριση των κατάλληλων δεδομένων χωρίς να απαιτείται να κάνεις υποθέσεις πριν to compilation για το τι δομικές αλλαγές θα γίνουν στα δεδομένα σου μετά το compilation. Μεγάλη κουβέντα είναι τώρα αυτή που λέω αλλά ας πούμε ότι είναι ένα gut feeling ή η κατεύθυνση προς την οποία θα το έψαχνα εγώ αν συμμετείχα σε αυτές τις ομάδες. Για να καταλάβεις καλύτερα τι εννοώ σκέψου πως παιρνώντας στον OO προγραμματισμό από τον procedural φτιάξαμε κλάσεις για να εισάγουμε την ένοια του data hidding και encapsulation κλπ, έτσι αντίστοιχα μπορούμε να φτιάξουμε ένα μοντέλο το οποίο θα κάνει κάτι αντίσοιχο χρησιμοποιώντας web services (ας πούμε "web classes") οι οποίες θα μπορούν να εντοπίζουν η μία την άλλη μέσα από ένα σύστημα όπως το DNS αλλά με αναφορά τα XML namespaces και θα "μιλάνε" με την κατάλληλη version της κατάλληλης web class για διαχειριστούν δεδομένα που θα μπορούν να αλλάζουν δομή (άρα και type) μετά το compilation χωρίς recompilation.

Χμμμ... Ναι ωραίο ακούγεται μόνο που ένα τέτοιο σύστημα θα έχει τρομερό overhead ενώ το XML/Relational integration στο CLR οδηγείται από την ανάγκη για performance...

rousso wrote:

That said,  δεκτό το XML/relational παράδειγμα αν και θολό ακόμα ως πεδίο. Όμως επέτρεψε μου να επιστρέψω στο θέμα που είχα θέσει αρχικά. Έχει κάποιος να μας δώσει κάποιο παράδειγμα όπου η λύση dynamic typing είναι καλύτερη από την λύση strong typing; Εννοώ δηλαδή κάτι πιο καθημερινό, πιο συγκεκριμένο και λιγότερο "μελλοντικό" από το XML/Relational data integration στo CLR το οποίο κατά τη γνώμη μου έχει να κάνει περισσότερο με Object/Relational integration (στις ίδιες databases και στο data layer), παρά με dynamic vs strong typing. Ένα παράδειγμα ας πούμε που θα μπορούσε να μας δώσει το συμπέρασμα ότι ίσως τελικά να πρέπει η C# να αποκτήσει dynamic typing.

Βασικά είναι η περίπτωση του Ελβετικού σουγιά... Κάποιοι τον θέλουν μόνο με τα τρία βασικά εργαλεία, κάποιοι τον θέλουν full με τιρμπουσόν και USB flash disk. Εγώ ανήκω στους δεύτερους, όχι μόνο επειδή είμαι gadgetάκιας αλλά και επειδή θέλω κατά την εξαιρετική περίπτωση που θα χρειαστεί να ανοίξω μια σαμπάνια στη μέση του δάσους, να έχω αυτό το τιρμπουσόν!

'Η, για να το επαναφέρω το πράγμα στην πραγματικότητα, είναι σαν το late binding (το αναφέρω γιατί από πίσω του κρύβεται το reflection το οποίο reflection κρύβεται και πίσω από το dynamic typing). Υπάρχει, και μου αρκεί που είναι εκεί έτσι ώστε αν παρουσιαστεί ανάγκη να το χρησιμοποιήσω. Ή τέλος, είναι σαν την περίφημη δυνατότητα για την οποία καυχιόνται οι developers της C#, να μπορείς να γράψεις unsafe code. Υπάρχει, είναι εκεί και μπορεί κάποιος, κάπου, κάποτε, αν παραστεί ανάγκη, πχ στη μέση ενός δάσους, να το χρησιμοποιήσει.

α) για το for each: ε... χμμ.. καλύτερα να μην λέω εξυπνάδες άλλη φορά διαβάζοντας vb κώδικα και μάλιστα χωρίς την δέσουσα προσοχή!!! το "παράδειγμά" μου ήταν ατυχές (και άσχετο με το θέμα μας). Το διάβασα αμέσως μετά το post στο παρόν θέμα και το μυαλό μου πήγε κατευθείαν στο κακό. (Όποιος βιάζεται...)

β) υποκλείνομαι... Συμφωνώ μαζί σου και δεν έχω λόγο να προσθέσω ή να αλλάξω κάτι σε όσα είπαμε. Μη βλέπεις που κάνω τον κακό, κατά βάθος συμφωνώ και με το σκεπτικό του dynamic typing  και με τις απόψεις που αναφέραμε γι' αυτό. Αν δεν "τραβήξεις" όμως λίγο το θέμα δεν γίνεται και συζήτηση.

Μια και αναφέραμε όμως reflection, έχω εδώ και καιρό στο μυαλό μου μια ιδέα και προσπαθώ να βρω πως θα την υλοποιήσω. Το σχετικό της ιδέας είναι ότι χωρίς reflection δεν γίνεται... Θα σας πω λεπτομέρειες όταν το σχηματοποιήσω κάπως καλύτερα αλλά σε γενικές γραμμές η ιδέα έχει να κάνει με την δημιουργία ενός παιχνιδιού για .net programmers. Ενός strategy. Όπου αντί να έχεις στρατιές από sprites με απίθανες δυνατότητες που τι βάζεις να αλληλεπιδράσουν μεταξύ τους στο μοντέλο του παιχνιδιού έχεις κώδικα που ρίχνεις στο σύστημα. Θα είχε πολύ ενδιαφέρον αλλά από πρώτη ιδέα μέχρι να αρχίσει να το φτιάχνει κανείς έχει πολύ δρόμο. Μπορεί και να μην έχει και νόημα τελικά. Δεν ξέρω.

Τι λες;

rousso wrote:

Θα σας πω λεπτομέρειες όταν το σχηματοποιήσω κάπως καλύτερα αλλά σε γενικές γραμμές η ιδέα έχει να κάνει με την δημιουργία ενός παιχνιδιού για .net programmers. Ενός strategy. Όπου αντί να έχεις στρατιές από sprites με απίθανες δυνατότητες που τι βάζεις να αλληλεπιδράσουν μεταξύ τους στο μοντέλο του παιχνιδιού έχεις κώδικα που ρίχνεις στο σύστημα.

Ναι, το Terrarium! Είχα παίξει μαζί του όταν πρωτοβγήκε... Θα μπορούσαμε να φτιάξουμε ένα DNZ ecosystem και να αρχίσουμε τις κόντρες!

Ο Διομήδης Σπινέλλης έγραψε στη μόνιμη στήλη του στο IEEE Software του Μαΐου-Ιουνίου ένα άρθρο ακριβώς για την αξία των δυναμικών γλωσσών, και μάλιστα έχει το draft στο site του: Java makes scripting languages irrelevant? Το συμπέρασμα? Rumors of the death of scripting langages ... are greatly exaggerated! (αν και πιστεύω ότι το demise αντί για το death θα ήταν πιο κουλτουριάρικο  )

Πρέπει ο-πωσ-δή-πο-τε να πάτε να διαβάσετε το άρθρο, αλλά για όσους δεν προλαβαίνουν (βαριούνται) τα κύρια πλεονεκτήματα των δυναμικών γλωσσών είναι:

• A more flexible or imaginative syntax
• Less fuss about types
• A more aggressive use of reflection
• Tighter integration with command-line tools
• Viability as a command language
• A shorter build cycle

Και μιας και θα πάτε να διαβάσετε το άρθρο αυτό, θα βρείτε και τα υπόλοιπα άρθρα του http://www.dmst.aueb.gr/dds/pubs/#column

Μια που το αναφέραμε ένα πολύ κοινό παράδειγμα μιας γλώσσας που ζει ανάμεσά μας και είναι πολύ σχετική με το θέμα μας, είναι αυτό της JavaScript.

Διάβασα πρόσφατα ένα άρθρο για το πόσο παρεξηγημένεη είναι η JavaScript και το πόσο δυναμική μπορεί να είναι. Το άρθρο το βρήκα πολύ ενδιαφέρον και θα σας πρότεινα να το διαβάσετε. Ίσως είναι το καλύτερο παράδειγμα για το πόσο object oriented μπορεί να είναι η JavaScript ενω παράλληλα να είναι και scripting γλώσσα (interpreted) και typless (αν μπορεί να το πει κανείς έτσι).

Δείτε το άρθρο εδώ: JavaScript the most misunderstood programming language

και επίσης μη χάστε το κομμάτι στο οποίο αναφέρεται σε multiple inheritance στην JavaScript.

rousso

patrick wrote:

Έχεις δει το Terrarium?

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

Ας πούμε ότι φτιάχνεις μια τελείως abstract class, descendants της οποίας αποδέχεσαι μόνο στο σύστημά σου. Αυτό για να έχεις μόνο ένα βασικό interaction interface και ένα σημείο στο οποίο μπορείς να επιβάλεις κανόνες ασφάλειας του κώδικα. Όλο το υπόλοιπο πρέπει να λειτουργήσει χαοτικά.

Όταν έκανα το μεταπυχιακό μου μας είχε δώσει ένας ωραίος τύπος που είχα καθηγητή (Micheal McCullagh) μια άσκηση για C++ όταν μιλάγαμε για θεωρία του χάους η οποία είχε να κάνει με ένα ηλεκτρικό σύστημα από τυχαία συνδεδεμένες μεταξύ τους συσκευές (λάμπες ας πούμε) οι οποίες αλληλεπιδρούσαν με ένα χαόδη τρόπο αλλά πάραυτα μπορούσες γραφικά να εντοπίσεις patterns που δημιουργούνταν κατά τη διάρκεια της αλληλεπίδρασης. Anyway να μην μπαίνω σε λεπτομέρειες. Η λογική είναι ότι από το χάος μπορεί να προκύψει μια τάξη. Αυτό θα ήθελα να το δω στην πράξη σε ένα τέτοιο παιχνίδι.

Επίσης καλό το terrarium αλλά αυτό μου ενδιαφέρει είναι κυρίως να φτιάξω το παιχνίδι περισσότερο από όσο με ενδιαφέρει να το παίξω.

Ακόμη, το terrarioum είναι demo για .net windows forms, directX, web services, auto-updates κλπ. Εγώ έχω στο μυαλό μου πιο πολύ reflection, interoperability, patterns κλπ..

Αν το βρίσκει κανείς ανδιαφέρον μπορούμε να το βάλουμε κάτω και να το φτιάξουμε. Το πάμε και στο sourceforge άμα θέλετε...

Θυμήθηκα αυτήν την κουβέντα που είχαμε κάνει παλιότερα εδώ.

WOW! 29/7/2005 και πλέον αυτά τα πράγματα σήμερα ΓΙΝΟΝΤΑΙ. XML και relational κόσμος ενσωματώνονται στο CLR!

Kαι με αφορμή αυτήν την ερώτηση που πέτυχα στο MSDN "Jasper" forum Is Jasper useable from c#?, έγραψα ένα blog-post, κουβέντα να γίνεται...

Καλά, τη μία λέμε για τα extension methods και το type inferencing της C#, και την άλλη μας λένε ότι φτιάξανε το Jasper ειδικά για late binding, συνεπώς δεν παίζει σε C#? Δεν μπορώ να πω ότι καταλαβαίνω την εξήγηση αυτή. Δεν είναι δα και τίποτε πρωτοποριακό αυτό που κάνει το Jasper, έχει ξαναγίνει ακόμα και σε C++. Γιατί χρειάζεται τόσο πολύ το late binding? Εδώ υπάρχουν τόσα ORM και πλατφορμες, οι οποίες επιτυγχάνουν τα ίδια πράγματα χωρίς να απαιτούν late binding και χωρίς να προκαλούν καθυστερήσεις. Αν κρίνω και από την πιο λεπτομερή εξήγηση, μάλλον ο λόγος ήταν η κακή συνεννόηση, παρά κάποια ουσιαστική ανάγκη. Όσον αφορά τα περί "agile development", ένα χώρο όπου χρησιμοποιείται κατά κόρον η C# ....

Κάτι μου λέει ότι το Jasper θα έχει ... ενδιαφέρουσα ... υποδοχή από όσους ασχολούνται με ORMs και agile development.