.Net vs Java

[Skeftomilos]

Παρακολούθησα από την αρχή τη συζήτησή σας και είμαι πραγματικά έκπληκτος από το υψηλό της επίπεδο. Ομολογώ πλήρη άγνοια των μισών τουλάχιστον από τους τεχικούς όρους που χρησιμοποιείτε. Τυχαίνει να είμαι καλός γνώστης των πρακτικών δυνατοτήτων του .NET και θέλω να πω ότι συμφωνώ απόλυτα με το 50% όσων είπε ο mikem4600. Για το υπόλοιπο 50% δεν μπορώ να έχω γνώμη καθώς με πιάνει αδιάβαστο! Με τη Java έχω μία μικρή επαφή μέσω ενός εισαγωγικού βιβλίου και αυτό που αμέσως μου χτύπησε στο μάτι ήταν η παντελής έλλειψη κάθε αναφοράς σε Properties. Δεν ήξερα πως να το εξηγήσω. Υπέθεσα ότι δεν τις ανέφερε θεωρώντας τες advanced feature ή ότι το βιβλίο ήταν παλιό και αφορούσε κάποια παλιά και ατελή έκδοση της γλώσσας. Διαβάζοντας αργότερα κάποια reviews άρχισα να συνειδητοποιώ ότι οι Properties δεν περιλαμβάνοντας στον πυρήνα της γλώσσας, πράγμα που μου έκανε μεγάλη εντύπωση. Πώς ήταν δυνατό μία σύγχρονη αντικειμενοστρεφής γλώσσα να εμφανίζει μία τόσο αξιοθρήνητη παράλειψη? Βέβαια - απ' όσο γνωρίζω - το concept των properties εμφανίστηκε για πρώτη φορά στη VB4, δηλαδή μετά την εμφάνιση της Java, αλλά αυτό δεν ήταν λόγος να μη φροντίσουν οι δημιουργοί της γλώσσας να ενσωματώσουν εκ των υστέρων μία τόσο σημαντική καινοτομία. Πάντως διατήρησα την αφελή εντύπωση ότι αυτή η παράλειψη είχε ήδη διορθωθεί, απλά κανείς δεν το είχε αναφέρει.

Και ξαφνικά τώρα ακούω τον HdkiLLeR να δηλώνει ότι προτιμάει το get/set, και ότι είναι περίπου υπερήφανος που η Java δεν έχει μολυνθεί απ' αυτό το βδελυρό χαρακτηριστικό καθώς είναι αντίθετο με τις αρχές της αντικειμενοστρέφειας!!! Συγνώμη αλλά εδώ δεν πρόκειται καθόλου για κολοκυθόπιτα. Αν δήλωνε ότι οι κατσαριδούλες είναι συμπαθητικά και φιλικά προς τον άνθρωπο εξάποδα κατοικίδια ζωάκια, με χαριτωμένες κεραιούλες και ναζιάρικο πισωγλεντζέδικο σκέρτσο, θα με είχε παραξενέψει λιγότερο. Προσωπικά γνώρισα τις Properties στη VB5 και μετά από ένα μικρό διάστημα αμφιβολιών τις ερωτεύηκα τρελά. Δεν υπάρχει περίπτωση να μην τις χρησιμοποιήσω έστω και στο πιο μικρό project. Μάλιστα στεναχωρήθηκα αρκετά με την αλλαγή σύνταξης από τη VB6 στη VB.NET, και κυρίως για την απώλεια της δυνατότητας για διαφορετικό accessibility μεταξύ του get και set. Για παράδειγμα ο παρακάτω κώδικας VB6 δεν έχει ευθεία αντιστοιχία σε VB.NET.

Code: Select all

Public Property Get ID() As Long
  ID = mCustomerID
End Property

Friend Property Let ID(ByVal xValue As Long)
  Debug.Assert (xValue > 0)
  mCustomerID = xValue
End Property

Παρατηρείστε ότι το get είναι Public ενώ το set Friend (internal στη C#, package στη Java). Αυτό είναι ιδιαίτερα χρήσιμο για ιδιότητες όπως η ID που δεν πρέπει να τις "πειράζει" ο έξω κόσμος. Όμως στο .NET η νέα σύνταξη το κάνει αδύνατο καθώς πακετάρει το get και το set σε ένα higher level container:

Code: Select all

Public Property ID() As Integer
  Get
    Return mCustomerID
  End Get

  Set(ByVal xValue As Integer)
    If (xValue <= 0) Throw New Exception("Invalid property value.")
    mCustomerID = xValue
  End Set
End Property

Anyway, δεν είναι και το τέλος του κόσμου. Στο .NET συνεχίζω να χρησιμοποιώ Properties σε κάθε ευκαιρία. Public Properties, Friend Properties, Protected Properties, Private Properties, MustOverride Properties (abstract στη C#) κ.λπ. Με την εξοικίωση διαπιστώνω ότι πολλές ρουτίνες μπορούν να μετατραπούν σε Properties βελτιώνοντας την αναγνωσιμότητα του κώδικα και την εσωτερική συνεκτικότητα των αντικειμένων. Θα δώσω ένα απλό παράδειγμα που γνωρίζουν όλοι όσοι έχουν φτιάξει data-entry forms. Σχεδόν πάντα υπάρχει μία ρουτίνα με όνομα όπως ToggleButtons() ή ChangeEnabled() ή BeginEdit() ή όποιο άλλο, η οποία καλείται για να αλλάξει τα κουμπιά της φόρμας όταν ο χρήστης περνάει από τη φάση View στη φάση Edit και αντίστροφα. Αντί λοιπόν γι'αυτή την ξεκάρφωτη Private Sub μπορεί να χρησιμοποιηθεί μία κομψή Private Property τύπου Boolean με το όνομα Editing. Τι προτιμάτε από τα παρακάτω?

Code: Select all

ToggleButtons()

ή

Code: Select all

Me.Editing = True

Τα κουμπία αλλάζουν στο τμήμα set της ιδιότητας Editing, και επιπλέον ο προγραμματιστής αποκτά ένα νέο τρόπο να γνωρίζει ανά πάσα στιγμή αν ο φόρμα είναι ή όχι σε φάση Editing:

Code: Select all

If Me.Editing Then ...

Μία άλλη πολύ συνηθισμένη χρήση των properties είναι στα business objects του middle-tier μίας database εφαρμογής. Μου φαίνεται απίστευτο ότι μπορεί κάποιος να προτιμάει τον δεύτερο από τους δύο παρακάτω κώδικες για λόγους ιδεολογίας ή αισθητικής ή όποιους άλλους:

Code: Select all

Dim P As New Person()
P.Name = "John"

Code: Select all

Dim P As New Person()
P.setName("John")

Όσο για το μέλλον των δύο τεχνολογιών (.NET - Java), δύσκολο να πει κανείς. Πολύ γερά άλογα και τα δύο, με σκληρότατο ανταγωνισμό μεταξύ τους. Άραγε είναι δυνατόν να επιβιώνουν και τα δύο ταυτόχρονα για πολύ? Νομίζω πως όποιο καταφέρει να πάρει ένα καθαρό προβάδισμα, θα οδηγήσει τον αντίπαλό του σε γρήγορο αφανισμό. Περιμένω να δω με ανυπομονησία τις συνέπειες από το release του super VS 2005. Θα καταφέρει η Java να ανταπεξέλθει το χτύπημα? Προσωπικά δε θα στοιχημάτιζα υπέρ της. Όπως έχω γράψει και αλλού, τα μουσεία ιστορίας λογισμικού θα πρέπει μάλλον να ετοιμάζουν από τώρα τα ειδικά βάθρα που θα στηρίξουν μία σπουδαία γλώσσα που τάραξε τα νερά, καινοτόμησε, άλλαξε την πορεία του προγραμματισμού, αλλά ατύχησε να βρεθεί στο ίδιο κλουβί με μία τίγρη 800 κιλών. Βέβαια προς το παρόν το παιχνίδι ακόμα παίζεται.

[Einherjar]

Μου φαίνεται απίστευτο ότι μπορεί κάποιος να προτιμάει τον δεύτερο από τους δύο παρακάτω κώδικες για λόγους ιδεολογίας ή αισθητικής ή όποιους άλλους

...και όμως πραγματικό

[AnINffected]

Ταπεινή μου άποψη είναι πως τα properties δεν είναι αντικείμενα, άρα δεν είναι σύμφωνα με το αντικειμενοστρεφές μοντέλο της Java η οποία χειρίζεται μόνο αντικείμενα, γι'αυτό και η απουσία τους από τη γλώσσα.

Προσωπικά μ'αρέσει που η Java εμμένει σε αυτό, διότι είμαι υπέρ της ποικιλίας άσχετα απ'το ποια γλώσσα προτιμώ.
Ποικιλία = περισσότερες επιλογές.

[Einherjar]

βασικά τα properties σε είναι αντικείμενα, είναι ιδιότητες των αντικειμένων που έχουν δυική υπόσταση (ακούστηκε κάπως ε?). Εμπεριέχουν δηλαδή τα set/get και κάθε φορά χρησιμοποιείται η ανάλογη υπόσταση αυτόματα

[Skeftomilos]

Χμ, νομίζω πως ίσως δεν έχετε καταλάβει ακριβώς τι είναι οι ιδιότητες (Properties). Ομολογώ ότι και εγώ με το background από Pascal που είχα τις είχα παρεξηγήσει στην αρχή. Οι ιδιότητες μίας κλάσης δεν έχουν καμία σχέση με τα ξέμπαρκα πεδία (Fields) τα οποία μπορεί να αλλάξει ο έξω κώδικας χωρίς κανέναν έλεγχο. Οι ιδιότητες δεν είναι τίποτα περισσότερο από μία συντακτική διευκόλυνση. Το framework εσωτερικά αναλύει την κάθε ιδιότητα που γράφουμε (π.χ. Name) σε δύο μεθόδους (get_Name, set_Name). Έτσι, πριν μεταγλωττιστεί η παρακάτω εντολή ...

Code: Select all

P.Name = "John"

... μετατρέπεται σε ...

Code: Select all

P.set_Name("John")

Η ύπαρξη ιδιοτήτων σε καμία περίπτωση δεν περιορίζει τις επιλογές μας, αντίθετα τις διευρύνει. Μπορείτε αν σας αρέσει να γράφεται .NET κώδικα χωρίς να κάνετε χρήση ιδιοτήτων (χάνοντας βέβαια κάθε ελπίδα να σας προσλάβω ως φανταστικός εργοδότης!), ή μπορείτε να τις χρησιμοποιείτε. Στην Java όμως δεν έχετε επιλογή. Επομένως AnINffected αν όντως σου αρέσει η ποικιλία και η ευρυχωρία των επιλογών μάλλον θα πρέπει να στείλεις ένα email στη Sun ζητώντας να προσθέσει ιδιότητες στη Java το ταχύτερο!

Μία ακόμα παρατήρηση. Μία ιδιότητα δεν αποτελεί κατ' ανάγκη αντανάκλαση ενός εσωτερικού πεδίου. Μπορεί κάλιστα να είναι μία calculated ιδιότητα. Π.χ. η ιδιότητα Person.LuckyNumber μπορεί απλά να επιστρέφει έναν τυχαίο αριθμό. Μία άλλη πολύ συνηθισμένη περίπτωση είναι οι ιδιότητες BirthDate και Age οι οποίες επιστρέφουν με διαφορετικό τρόπο την τιμή του εσωτερικου πεδίου m_BirthDate, η πρώτη άμεσα, η δεύτερη υπολογιστικά. Αυτή είναι η ομορφιά των ιδιοτήτων. Ο έξω κώδικας δε χρειάζεται να ξέρει τα εσωτερικά του αντικειμένου, πώς προκύπτει δηλαδή η τιμή της κάθε ιδιότητας.

BTW υπάρχει μία σύσταση της Microsoft να μην περιλαμβάνεται CPU hungry κώδικας στο τμήμα get των ιδιοτήτων. Οι περισσότεροι προγραμματιστές δεν περιμένουν κάτι τέτοιο και μπορούν όντας ανυποψίαστοι να γράψουν client κώδικα που να κάνει σπάταλες κλήσεις ιδιοτήτων.

[HdkiLLeR]

Προσωπικά να σου πώ δεν είμαι 100% υπέρ κανενός. Να σου πώ πως θα το έφτιαχνα ώστε και να ήταν γρήγορο αλλά και δομικά σωστό. Θα δήλωνα το attribute ώστε να έχει protected/friend access και στον κάωδικα των τάξεων του ιδίου πακέτου θα το χρησιμοποιούσα κατευθείαν χωρίς κλήση function ώστε να μην γίνεται σπατάλη στης στοίβας και να μην χάνω CPU Cycles πχ

Code: Select all

me.attribute = true;

Σε κάθε άλλη τάξη εκτός του package τότε αναγκαστικά επιλέγω το tradeoff να έχω κλήση function πχ

Code: Select all

me.setatribute(true);

ώστε να είμαι σωστός ως προς την δόμηση του code. Αλλιώς χάνεις το νόημα της απόκρυψης/ενθυλάκωσης που είναι βασικό στο OOP, οι άσχετες κλάσεις αντιμετωπίζουν τις κλάσεις που δεν γνωρίζουν σαν black boxes.

Δεν έχω γράψει πάνω απο 5000-6000 γραμές code max ποτέ μέχρι στιγμής οπότε δεν θεωρώ πως είμαι και καλός coder οπότε δεν είναι κατανάγκην σωστά αυτά που λέω, αλλά εάν γράφεις με τον τρόπο που αναφέρω και πιο εύκολο στην κατανόηση είναι και σχετικά γρήγορο.

[mikem4600]

Μιας και άρχισε να ζεστένεται και πάλι το θέμα...

Μου φαίνεται απίστευτο ότι μπορεί κάποιος να προτιμάει τον δεύτερο από τους δύο παρακάτω κώδικες για λόγους ιδεολογίας ή αισθητικής ή όποιους άλλους

...και όμως πραγματικό

Βασικά, τα εργαλεία που χρησιμοποιώ τα χωρίζω σε δύο κατηγορίες, αυτά για που τα χρησιμοποιώ για "research" και αυτά που χρησιμοποιώ για "production". Στα "reaserch" εργαλεία με ενδιαφέρει να δω το εργαλείο αυτό καθ' αυτό πως δουλεύει, και όχι τόσο ο στόχος στον οποίο θέλω να φτάσω με χρήση του εργαλείου αυτού. Σε αυτή την περίπτωση, εξετάζω το αν ένα εργαλείο είναι ελεύθερο ή όχι, αλλά μόνο σε συνάρτηση του τι μου προσφέρει ως τέτοιο (π.χ. και ο Mozilla είναι open-source, αλλά δεν μου προσφέρει κάτι άμεσα, καθώς για να βγάλω άκρη από τον κώδικά του πρέπει να φάω κάποια χρόνια, και θεωρίες της κατηγορίας "είναι πιο ασφαλές" ή απλώς "είναι καλύτερο" δεν έχουν αποδειχθεί ότι ισχύουν επειδή κάτι είναι - ή δεν είναι - OSS). Τα production εργαλεία είναι αυτά που τα χρησιμοποιώ για να φέρω εις πέρας κάτι, και πρώτη προτεραιότητα είναι η επίτευξη ενός στοχου (π.χ. η ολοκλήρωση μίας εργασίας). Σε αυτή τη φάση δεν με ενδιαφέρει καθόλου αν κάτι είναι open source, closed source ή ο,τιδήποτε άλλο - αν το εργαλείο δεν κάνει αρκετά καλά τη δουλειά του αντικαθίσταται άμεσα. Γενικά, κάτι περνάει πρώτα από την πρώτη φάση, και μετά φτάνει στην δεύτερη. Δυστυχώς, η Java (και το Debian for that matter) για εμένα ανήκει ακόμα στην πρώτη κατηγορία, καθώς γενικά δεν αρκεί να θες να λύσεις ένα πρόβλημα, αλλά πρέπει να υπερπηδάς και τα ίδια τα εμπόδια που σου βάζει η πλατφόρμα...

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

Ξέρω ακριβώς τι εννοείς... Εγώ, πάλι, μέχρι πριν από λίγα χρόνια θεωρούσα αδιανόητο να φτιάχνεις γραφικές διεπαφές χωρίς designer της προκοπής. Αργότερα ανακάλυψα, με τον λάθος τρόπο μάλλον (δηλ. γράφοντας resources με το χέρι...), ότι η δημιουργία GUI με designer είναι η εξαίρεση, όχι ο κανόνας...

Όσο για το μέλλον των δύο τεχνολογιών (.NET - Java), δύσκολο να πει κανείς. Πολύ γερά άλογα και τα δύο, με σκληρότατο ανταγωνισμό μεταξύ τους. Άραγε είναι δυνατόν να επιβιώνουν και τα δύο ταυτόχρονα για πολύ? Νομίζω πως όποιο καταφέρει να πάρει ένα καθαρό προβάδισμα, θα οδηγήσει τον αντίπαλό του σε γρήγορο αφανισμό. Περιμένω να δω με ανυπομονησία τις συνέπειες από το release του super VS 2005. Θα καταφέρει η Java να ανταπεξέλθει το χτύπημα? Προσωπικά δε θα στοιχημάτιζα υπέρ της. Όπως έχω γράψει και αλλού, τα μουσεία ιστορίας λογισμικού θα πρέπει μάλλον να ετοιμάζουν από τώρα τα ειδικά βάθρα που θα στηρίξουν μία σπουδαία γλώσσα που τάραξε τα νερά, καινοτόμησε, άλλαξε την πορεία του προγραμματισμού, αλλά ατύχησε να βρεθεί στο ίδιο κλουβί με μία τίγρη 800 κιλών. Βέβαια προς το παρόν το παιχνίδι ακόμα παίζεται.

Συμφωνώ και επαυξάνω. Καθοριστική εξέλιξη νομίζω θα είναι το πως θα παίξει τα χαρτιά της η Microsoft στα Longhorn και τον IE7+ (η Sun δεν νομίζω ότι είναι σε θέση να κάνει τη δραματική αλλαγή στην Java που χρειάζεται για να την φέρει σε πιο ευρύ κοινό).

Για τα properties δεν έχω να προσθέσω κάτι πέρα από αυτά που αναφέρει ο προλαλήσαντας.

Για τα περί CPU cycles... έλεος, τόσος κόσμος χρησιμοποιεί πράγματα όπως την Perl, που είχε αναφέρει και ο AST . Το αν θα κάνει το invocation 1 cycle ή 3 cycles ή 5, σε βαθμό που δεν επηρεάζει τους στόχους μίας εφαρμογής, μου είναι πλέον παντελώς αδιάφορο, και θέμα των VM/runtime/hardware. Πολύ πιο σημαντική, νομίζω, είναι η "ανθρωποκεντρική" πλευρά του κώδικα, δηλ. η αναγνωσιμότητα, "συντηρησιμότητα" κτλ. Έχω δει υπερβολικά πολύ κώδικα ο οποίος ίσως είναι πολύ έξυπνος, αλλά δεν έχει κανένα νόημα για άλλους πέρα από αυτόν που τον έγραψε (κι αυτό για τις πρώτες 2-3 εβδομάδες από το γράψιμο - hint hint Erev... ).

Και μιας και εξαντλήσαμε τα properties, τι λέτε να θάψουμε και το autoboxing; Το χαρακτηριστικό αυτό επιτρέπει σε μία γλώσσα να μετατρέπει τους primitive τύπους (π.χ. int) σε αντικείμενα (π.χ. Integer στην Java) και αντίστροφα, implicitly (δηλ. χωρίς να το κάνει ο ίδιος ο χρήστης). Υπήρχε στην VB και στο .NET από... πάντα και πρόσφατα έφτασε και στην Java 1.5. Έχει το μειονέκτημα ότι η μετατροπή αυτή εισάγει overhead (μερικών εντολών) για κάθε μετατροπή "εν αγνοία" του χρήστη. Είναι και αυτό το χαρακτηριστικό κατακριτέο, ή επειδή υιοθετήθηκε και από τη Sun είναι χρήσιμο; Βασικά περιμένω επιχειρήματα τύπου "Tι; Γι' αυτό σέρνονται τα Windows! Ποιος ξέρει πόσο μας κοστίζει κάθε εντολή της C#!"

[Einherjar]

Καθοριστική εξέλιξη νομίζω θα είναι το πως θα παίξει τα χαρτιά της η Microsoft στα Longhorn και τον IE7+ (η Sun δεν νομίζω ότι είναι σε θέση να κάνει τη δραματική αλλαγή στην Java που χρειάζεται για να την φέρει σε πιο ευρύ κοινό).

τι σχέση έχουν τα παραπάνω με τη java/sun. αυτά είναι σε άλλο επίπεδο, δεν είναι προγραμματιστικές πλατφόρμες.

Γενικά, κάτι περνάει πρώτα από την πρώτη φάση, και μετά φτάνει στην δεύτερη. Δυστυχώς, η Java (και το Debian for that matter) για εμένα ανήκει ακόμα στην πρώτη κατηγορία

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

Υπήρχε στην VB και στο .NET από... πάντα και πρόσφατα έφτασε και στην Java 1.5. Έχει το μειονέκτημα ότι η μετατροπή αυτή εισάγει overhead (μερικών εντολών) για κάθε μετατροπή "εν αγνοία" του χρήστη. Είναι και αυτό το χαρακτηριστικό κατακριτέο, ή επειδή υιοθετήθηκε και από τη Sun είναι χρήσιμο;

το overhead αυτό δεν είναι εν αγνοία του προγραμματιστή (δεν θα έπρεπε τουλάχιστον). ίσως το overhead αυτό να είναι μικρότερο απ'ότι αν το έκανε manually ο προγραμματιστής. Το θέμα είναι όμως ότι αυτό είναι πραγματική βοήθεια και δεν αντιτίθεται σε κάποια αρχή του αντικειμενοστραφούς προγραμματισμού όπως τα properties. αν είμαι λάθος παρακαλώ διορθώστε με!

[mikem4600]

Καθοριστική εξέλιξη νομίζω θα είναι το πως θα παίξει τα χαρτιά της η Microsoft στα Longhorn και τον IE7+ (η Sun δεν νομίζω ότι είναι σε θέση να κάνει τη δραματική αλλαγή στην Java που χρειάζεται για να την φέρει σε πιο ευρύ κοινό).

τι σχέση έχουν τα παραπάνω με τη java/sun. αυτά είναι σε άλλο επίπεδο, δεν είναι προγραμματιστικές πλατφόρμες.

Κι όμως... Βλέποντας λίγο πιο μακριά από το VS 2005 (και .NET 2.0) η επόμενη στάση για το .NET είναι τα επόμενα Windows. Και ο IE (ή ο Mozilla) δεν είναι προγραμματιστική πλατφόρμα; Ρίξε μια ματιά σε κάποια demos του Avalon (ή next generation Windows.Forms), όπου πλήρως rich client εφαρμογές (τύπου XUL σε ορολογία Mozilla), όπως ένας rich client για το Amazon.com, έτρεχαν μέσα στον browser (IE) - μάλιστα κάποια νομίζω χρησιμοποιούσαν μέρος του 3D API του Avalon από τον ίδιο τον browser.

Γενικά, κάτι περνάει πρώτα από την πρώτη φάση, και μετά φτάνει στην δεύτερη. Δυστυχώς, η Java (και το Debian for that matter) για εμένα ανήκει ακόμα στην πρώτη κατηγορία

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

Δεν έχω καμία αμφιβολία και ούτε είπα το αντίθετο (μάλιστα αρκετές φορές κάνουν την δουλεία τους καλύτερα από άλλες λύσεις). Αυτό στο οποίο προσπαθώ να καταλήξω είναι το ότι δεν είναι σχεδιασμένα σαν a means to an end, αλλά περισσότερο σαν μια συλλογή εργαλείων και κώδικα που κάποιος τα μάζεψε, τα πακέταρε και τα διανέμει.

[HdkiLLeR]

Για τα περί CPU cycles... έλεος, τόσος κόσμος χρησιμοποιεί πράγματα όπως την Perl, που είχε αναφέρει και ο AST . Το αν θα κάνει το invocation 1 cycle ή 3 cycles ή 5, σε βαθμό που δεν επηρεάζει τους στόχους μίας εφαρμογής, μου είναι πλέον παντελώς αδιάφορο, και θέμα των VM/runtime/hardware. Πολύ πιο σημαντική, νομίζω, είναι η "ανθρωποκεντρική" πλευρά του κώδικα, δηλ. η αναγνωσιμότητα, "συντηρησιμότητα" κτλ. Έχω δει υπερβολικά πολύ κώδικα ο οποίος ίσως είναι πολύ έξυπνος, αλλά δεν έχει κανένα νόημα για άλλους πέρα από αυτόν που τον έγραψε (κι αυτό για τις πρώτες 2-3 εβδομάδες από το γράψιμο - hint hint Erev... ).

Μα και εγώ χρησιμοποιώ Perl είναι η πιο γρήγορη iterpreted γλώσσα αυτή την στιγμή και η καλύτερη όσον αφορά εφαρμογές pattern matching. Εαν καθόμουν να τα κάνω αυτά που κάνω με την Perl με μία γραμμή σε C# ή Java θα έβγαζα τα μάτια μου. Επίσης το core του διερμηνέα και όλα τα βασικά Modules(βλ. Zlib) είναι γραμμένα σε C, ούτε σε C++ ούτε σε οτιδήποτε άλλο μόνο και μόνο για να είναι fast. Σίγουρα αυτό έχει effect σε άλλα θέματα γιατί για να βάλω ένα module χωρίς make ήθελα μία εβδομάδα αλλά είναι tradeoff διαλέγεις. Ο καθένας έχει άλλα standarts mike. Εσύ γουστάρεις κάποια πράγματα άλλος άλλα. Δεν είναι μόνο η C# σωστή,άριστα δομημένη γλώσσα και η πανάκεια σε όλα. Άλλο να λές εγώ σαν coder δεν γουστάρω αυτό, δεν με βολεύει εκείνο κλπ και άλλο να θέτεις generic ταμπέλες. Στο κάτω κάτω της M$ πράγμα δεν θα φτάσει ποτέ το άριστο...εξ΄ ορισμού

[Skeftomilos]

Η ιδέα σου HdkiLLeR σχετικά με τη χρήση Friend Protected class members για τη βελτίωση της απόδοσης του κώδικα εντός του package είναι σωστή θεωρητικά. Την έχω δοκιμάσει στην πράξη και διαπίστωσα ότι απαιτούσε αυξημένη διανοητική προσπάθεια κατά την υλοποίηση, κάτι όχι ευχάριστο όταν το project είναι ήδη απαιτητικό και οι ιεραρχία των κλάσεων αρκετά περίπλοκη. Επιπλέον αποδείχτηκε πηγή σφαλμάτων. Γι αυτό σκέφτομαι ότι ίσως δεν αξίζει τον κόπο, και πως υπάρχουν συνήθως καλύτεροι τρόποι για να επιτευχθεί αύξηση της απόδοσης. Για παράδειγμα η σωστή και λογική χρήση caching υπόσχεται πολύ πιο εντυπωσιακό performance boost.

5.000 - 6.000 γραμμές κώδικα δε μου φαίνονται καθόλου λίγες. Πριν καιρό είχα διαβάσει ένα review (PDF, 188KB) που σκοπό είχε να συγκρίνει τον όγκο του απαιτούμενου κώδικα για την υλοποίηση ενός συγκεκριμένου project (Pet shop) με τρεις διαφορετικές τεχνολογίες. J2EE, .NET και .NET με DeKlarit code generation. Το τελικό αποτέλεσμα ήταν (συνολικός αριθμός γραμμών):

J2EE Pet Store : 14.273
.NET Pet Shop : 3.484
DeKlarit Pet Shop : 2.196

Το παραπάνω review το βρήκα ως τμήμα του promotion του tool DeKlarit οπότε η αξιοπιστία του είναι συζητήσιμη. Αν ωστόσο περιέχει μία δόση αλήθειας, τότε 5.000 - 6.000 γραμμές κώδικα Java μπορούν πράγματι να θεωρηθούν λίγες.

Το autoboxing στο .NET μπορεί να είναι αρκετά πονηρή υπόθεση. Αν και είχα διαβάσει αρκετά βιβλία για το .NET και τις build-in συλλογές του Framework, από πουθενά δεν είχα προειδοποιηθεί για το performance hit που συνεπάγεται η αποθήκευση value-types στις συλλογές ArrayList και HashTable. Μόνο όταν διάβασα άρθρα του MSDN αφιερωμένα αποκλειστικά στην Performance έμαθα σχετικά με αυτό το χαρακτηριστικό. Η σύσταση να χρησιμοποιούνται Arrays για την αποθήκευση των value-types δεν είναι πολύ ικανοποιητική καθώς αυτά δεν παρέχουν όλες τις ευκολίες του ArrayList. Μία άλλη ιδέα είναι η κατασκευή custom type-specific ArrayLists. Ο κώδικας που χρειάζεται δεν είναι καθόλου λίγος, αλλά ευτυχώς υπάρχουν έτοιμα templates και με code-generation είναι θέμα δευτερολέπτων. Όμως και αυτή η λύση έχει τα προβλήματά της καθώς το κέρδος από την αυξημένη απόδοση του custom ArrayList πρέπει να πληρωθεί με πιθανή αύξηση του χρόνου εκκίνησης της εφαρμογής καθώς όλοι αυτοί οι τόνοι MSIL που παράγουν οι code-generators πρέπει να περάσουν από τον JIT compiler κάποια στιγμή. Η τελική λύση μάλλον είναι τα generics οπότε ας κάνουμε λίγη υπομονή ακόμα.

[janag79]

Σύμφωνω ότι το κύριο κομμάτι της συζήτησης οφείλει να είναι τεχνικό..

Θα διαφωνήσω ωστόσο ότι το gui developement είναι πιο γρήγορο σε .Net

Όλα τα gui development tools είναι άχρηστα, αν αυτός που κατασκευάζει το gui δεν ξέρει να γράφω "καλό κώδικα"

Εγώ θα θέσω και το οικονομικό ζήτημα της υπόθεσης. Σκεφτείτε τι κόστος απαιτείται σε μία επιχείριση μία θέση development με Visual Studio .Net και τι στην ίδια επιχείριση μία θέση εργασίας με Java. To σενάριο, αφορά εργαζόμενους ίδιους δυναμτικότητας-γνώσεων....Η διαφορά είναι 1500$-0$

Για να μην αναφέρω updates, πρόσθετα licences κτλ...

[Erevodifwntas]

οκ... και αν ένα προϊόν θέλει 2πλάσιο χρόνο για developing μόνο και μόνο για να έχει ένα αξιοπρεπες interface (και πάλι κατώτερο του .Net... δυστυχώς)... αυτό δεν έχει πολύ μεγαλύτερο κόστος για την επιχείρηση?

[janag79]

To οτι δεν έχεις ασχοληθεί με Swing (Java GUI) δεν σημαίνει ότι δεν είναι και καλό,ή ότι παράγει χειρότερα αποτελέσματα ποιοτικά.

Διπλάσιος χρόνος δεν είναι σε καμία περίπτωση..(είπαμε συγκρίνουμε developers ίδιας δυναμικότητας και ο καθένας στο αντικείμενο του) Το διπλάσιο είναι μέγεθος το οποίο το λες εσυ και δεν υπάρχει καμία μέτρηση για αυτό που να το αποδυκνύει.!

όσοι φτιάχνουν gui στα τυφλά, μπορούν πολύ δύσκολα να αλλάξουν ή να παραμετροποιήσουν πράγματα..

Οπότε δεν πιστεύω ότι έχει κάτι να ζηλέψει. Και στην τελική, ξέρεις ότι τα Windows και τα καλύτερα παιχνίδια στο κόσμο έχουν φτίαχνει σε C,C++.. και όχι με Visual .Net ή Delphi...

[mikem4600]

Θα διαφωνήσω ωστόσο ότι το gui developement είναι πιο γρήγορο σε .Net (...)

To οτι δεν έχεις ασχοληθεί με Swing (Java GUI) δεν σημαίνει ότι δεν είναι και καλό,ή ότι παράγει χειρότερα αποτελέσματα ποιοτικά.

Διπλάσιος χρόνος δεν είναι σε καμία περίπτωση..(είπαμε συγκρίνουμε developers ίδιας δυναμικότητας και ο καθένας στο αντικείμενο του) Το διπλάσιο είναι μέγεθος το οποίο το λες εσυ και δεν υπάρχει καμία μέτρηση για αυτό που να το αποδυκνύει!

Είχα την τύχη (ή την ατυχία...) να παίξω εκτενώς με Swing και AWT φτιάχνοντας ένα applet για μια εργασία... και οφείλω να συμφωνήσω με τον Erevodifwnta... Μου έχει μείνει το ότι το debug ήταν απλώς ένας εφιάλτης... (ναι, ναι η java έχει portability... απλώς μην πας σε διαφορετικές VMs πέρα από αυτήν που έκανες το development... επίσης, by default το Swing ξεχωρίζει σαν τη μύγα μεσ' το γάλα καθώς δεν ακολουθεί το γενικό LaF του λειτουργικό (εκτός κι αν το ενεργοποιείς εσύ χειροκίνητα, αλλά και πάλι ξεχωρίζει))

Εγώ θα θέσω και το οικονομικό ζήτημα της υπόθεσης. Σκεφτείτε τι κόστος απαιτείται σε μία επιχείριση μία θέση development με Visual Studio .Net και τι στην ίδια επιχείριση μία θέση εργασίας με Java. To σενάριο, αφορά εργαζόμενους ίδιους δυναμτικότητας-γνώσεων....Η διαφορά είναι 1500$-0$

Για να μην αναφέρω updates, πρόσθετα licences κτλ...

Απ' ότι φαίνεται, δεν τα γράφω αρκετά εμφανώς... Aς τα επαναλάβω σε αυτό το topic.

#develop (GPL): http://www.icsharpcode.net/OpenSource/SD/
MonoDevelop (GPL): http://www.monodevelop.com/
SDKs (δωρεάν): http://msdn.microsoft.com/netframework/ ... fault.aspx
Mono project (GPL): http://www.mono-project.com/
C++ optimizing compiler με υποστήριξη managed extentions (δωρεάν): http://msdn.microsoft.com/visualc/vctoolkit2003/

Αντίστοιχα:
NetBeans (SPL): http://www.netbeans.org/
Eclipse (open-source): http://www.eclipse.org/
JDKs (δωρεάν): http://java.sun.com/j2se/corejava/index.jsp

Που είναι το κόστος;

[AnINffected]

Εγώ, πάλι, μέχρι πριν από λίγα χρόνια θεωρούσα αδιανόητο να φτιάχνεις γραφικές διεπαφές χωρίς designer της προκοπής. Αργότερα ανακάλυψα, με τον λάθος τρόπο μάλλον (δηλ. γράφοντας resources με το χέρι...), ότι η δημιουργία GUI με designer είναι η εξαίρεση, όχι ο κανόνας...

Όταν λές designer εννοείς IDE για τη δημιουργία GUI, ε;
Άν είναι έτσι, τότε εγώ ακολούθησα αντίθετη πορεία από'σένα!Ξεκίνησα προσπαθώντας να γράψω resource files δια χειρός, δεν άντεξα, τα παράτησα και από τότε χρησιμοποιώ μόνο designers.
Επειδή μάλλον βρίσκεσαι κάτι χρόνια μπροστά από εμένα-δεν το λέω ειρωνικά-πές μου με ποιον τρόπο μπορείς να σχεδιάσεις GUI χωρίς να "ζωγραφίζεις" (με εξαίρεση το Swing API); Εσύ τι εργαλείο/α χρησιμοποιείς πιά;

Βλέποντας λίγο πιο μακριά από το VS 2005 (και .NET 2.0) η επόμενη στάση για το .NET είναι τα επόμενα Windows.

Όντως, απ'ότι έχω διαβάσει, τα Longhorn θα είναι γραμμένα σε .NET, ή με απατά η μνήμη μου;
Απορία: Τί είναι rich client;

Για τα περί CPU cycles... έλεος, τόσος κόσμος χρησιμοποιεί πράγματα όπως την Perl, που είχε αναφέρει και ο AST Very Happy . Το αν θα κάνει το invocation 1 cycle ή 3 cycles ή 5, σε βαθμό που δεν επηρεάζει τους στόχους μίας εφαρμογής, μου είναι πλέον παντελώς αδιάφορο, και θέμα των VM/runtime/hardware. Πολύ πιο σημαντική, νομίζω, είναι η "ανθρωποκεντρική" πλευρά του κώδικα, δηλ. η αναγνωσιμότητα, "συντηρησιμότητα" κτλ. Έχω δει υπερβολικά πολύ κώδικα ο οποίος ίσως είναι πολύ έξυπνος, αλλά δεν έχει κανένα νόημα για άλλους πέρα από αυτόν που τον έγραψε (κι αυτό για τις πρώτες 2-3 εβδομάδες από το γράψιμο - hint hint Erev... Razz ).

Το πόσο βάρος θα ρίξεις σε CPU cycles ή στο ανθρωποκεντρικό κομμάτι εξαρτάται από την εκάστοτε εφαρμογή.Όπως λέει και ο κ. Μαλεύρης στα Θέματα Τεχν.Λόγ. στο σύστημα ενός αεροδρομίου που βρίσκεται σε συνθήκες κανονικής λειτουργίας σ'ενδιαφέρουν οι κύκλοι και όχι το interface ή πόσο καθαρογραμμένος είναι ο κώδικας.!Χωρίς αυτό να σημαίνει οτι η αναγνωσιμότητα και η συντηρισιμότητα έρχονται σε δεύτερη μοίρα, καθώς παίζουν σημαντικότατο ρόλο σε κάθε έργο.
Όμως ο έξυπνος προγραμματισμός σε καμία περίπτωση δεν υπάρχει μόνο για τα μάτια του συγγραφέα του: υπάρχει για να επαναχρησιμοποιείται και για να προωθεί την εξέλιξη!Αντίθετα η συντηρησιμότητα, η αναγνωσιμότητα κλπ. δεν είναι εξελίξιμοι τομείς από project σε project (δεν είναι static ) .Γι'αυτό και νομίζω πως απο τη μεριά του ο HdkiLLeR πολύ καλά κάνει και ενδιαφέρεται για την ταχύτητα.
Άσε που δεν πρέπει να υποτιμούμε τα κυκλάκια...Με κάθε γραμμή κώδικα, τα συνολικά CPU cycles στην ουσία πολλαπλασιάζονται!Όπως δεν πρέπει να υποτιμάς εναν αλγόριθμο που έχει εκθετικό χρόνο εκτέλεσης.

[AmmarkoV]

Hfreepascal (με την οποία ασχολούμαι εγώ) εκτός του οτι μπορεί να παράγει,διαβάσει,μεταφράσει αυτόματα C/C++ headers/dll`s (οπότε είναι πολύ! συμβατή με C) υποστηρίζει και inline σε assembly ,για core components που εκτελούνται συνέχεια..!
Είμαι πολύ σίγουρος πως δεν υπάρχει γρηγορότερος τρόπος για να τρέξει εφαρμογή!
(Μιλώντας για ταχύτητα την Java ουτε κάν την συζητάω.. )
Επίσης λόγω της μικρής κοινότητας προγραμματιστών υπάρχει στοιχειώδες documentation και προσωπικά αναγκάστηκα να γράψω gui στα τυφλά ,όπως έγραψε κάποιος , και μόνο με low level Win32 API calls. Παρότι δική μου εφεύρεση όμως είναι και όμορφο και πρακτικό, εκτός του οτι επειδή έχει την μορφή βιβλιοθήκης ξέρω τι αλλαγές να κάνω για να μην επιρρεάζω τα προγράμματα μου και όταν τις κάνω , αρκεί ένα re-compile και είναι όλα ενημέρωμένα χωρίς καμμία αλλαγή και ψάξιμο!
Επίσης επειδή κάποιος μπορεί να πεί ναι αλλά το έτοιμο το gui όσο να ναι θα είναι καλύτερο, συμφωνώ , αλλά δεν ανταποκρίνεται στις ανάγκες μου , πχ ζήλεψα την βοήθεια ταχύτερης πληκτρολόγησης του Internet Explorer (βλέπε και λεξικό Τ9 στα κινητά) και την ενσωμάτωσα στα textboxes με ένα μικρό λεξικό.. Άλλο να το κάνεις αυτό κάθε φορά στο πρόγραμμα (που θές να είναι μικρό και κατανοητό) μέσω των λειτουργιών του GUI και άλλο πίσω από το GUI όταν ακριβώς πρέπει δεν συγκρίνεται ούτε η ταχύτητα , ούτε η πρακτικότητα..

[Erevodifwntas]

(προσωπικά μου αρέσει ο designer για τα resources -ναι είναι πραγματικά θεϊκό με τρία κλικ να έχεις έτοιμα όλα τα resources- ωστόσο... συνήθως τα γράφω με το χέρι... Έχει και αυτό τη γοητεία του

[mikem4600]

Εσύ τι εργαλείο/α χρησιμοποιείς πιά;

Ξεκίνησα με VB6. Εκείνη την εποχή, ό,τι δεν ήταν αντικείμενο με ιδιότητες απλώς δεν υπήρχε για εμένα. Στη συνέχεια αναβάθμισα στο Visual Studio .NET και πραγματικά έμεινα έκθαμβος από τους νέους designers. Τότε έμαθα και C#. Κάποια στιγμή χρειάστηκε να μάθω να φτιάχνω GUIs σε Visual C++ και MFC για μία εργασία στο μάθημα των Γραφικών. Εκεί ήταν η πρώτη μου επαφή με "μη-πραγματικούς" designers. Ναι, μεν, μπορούσες να κουνάς τα controls πέρα-δώθε, όπως στην VB6, αλλά δεν ήταν αντικείμενα. Τα events και η μεταβίβαση των τιμών των controls ήταν μία νέα, ξεχωριστή εμπειρία... Επίσης, χρειάστηκαν μερικές πολύ μικρές επεμβάσεις χειροκίνητα στα resources...

Παράλληλα, για μία άλλη εργασία για το μάθημα των Αλγορίθμων, χρειάστηκε να φτιάξω ένα applet σε Java. Προφανώς applet χωρίς GUI δεν νοείται. Ξεκίνησα να δω το πιο cutting-edge GUI API της Java, το Swing, το οποίο ήταν ένα μπάχαλο (π.χ. είχε τις constants με all-caps, αντίθετα με άλλα σημεία του API της Java, τα παράθυρα ΔΕΝ έκλειναν by default όταν έκανες κλικ στο Χ τους, και το να τους βάλεις ένα εικονίδιο ήταν ολόκληρη οδύσσεια). Πάλεψα αρκετά με τον designer του NetBeans (3.5 τότε) μέχρι που απογοητεύτηκα, και ξεκίνησα να γράφω το GUI με το χέρι. Αγανάκτησα με τους layout managers, οι οποίοι λες και είχαν δικά τους αισθητικά κριτήρια, άλλαζαν κατά το δοκούν την εμφάνιση της φόρμας. Σε εκείνο το σημείο, δούλευα όντως με αντικείμενα, αλλά καθόμουν και χειριζόμουν όλα τα events με το χέρι (το οποίο δεν μπορώ να πω ότι το χαιρόμουν και ιδιαίτερα). Επίσης το Swing εμφανισιακά ήταν... πολύ κάτω των προσδοκιών μου (Java 1.4.1 τότε κι όλας γαρ) και το γύρισα σε AWT, που τουλάχιστον ήταν κάπως πιο native (και δούλευε και με την Microsoft VM που τότε είχε το 95% του κόσμου), αλλά αυτό είχε άλλες τραγικές ελλείψεις (π.χ. δεν είχε MsgBox!! ). Κάπου εδώ τελείωναν τα αντικείμενα για εμένα...

Κάποια στιγμή της ζωής μου με είχε πιάσει μία κρίση με το DirectX, και ξεκίνησα και έγραφα κώδικα σε απλή ταπεινή C, και χύμα στο Win32 API. Εκεί ανακάλυψα ότι ακόμα και τα controls δεν ήταν στην πραγματικότητα controls αλλά... παράθυρα, και μάλιστα πλήρη, με χερούλια (hWnds)... Ευτυχώς, αυτή η παραζάλη μου πέρασε γρήγορα (τότε έγραφα πλέον όλα τα resources με το χέρι, και για να φτιάξω ένα, μοναδικό, άδειο, ταπεινό παραθύρι, το οποίο να έχει απλώς ένα ελεεινό title bar έπρεπε να γεμίσω 3 structs και να καλέσω καμιά ντουζίνα συναρτήσεις ). Πέρασα φευγαλέα και από το Qt toolkit και το KDevelop, και το Gtk+ και το Glade, καθώς και άλλα λιγότερο γνωστά toolkits για Linux.

Αργότερα ασχολήθηκα με εφαρμογές με GUI σε Symbian OS & Series 60. Εκεί μόνο editor υπήρχε, και καθόλου designer (αργότερα βγήκε ένας ποταπός από την Borland, ο οποίος δεν δουλεύει και πολύ καλά). Τα resources όλα με το χέρι, το ίδιο και ο κώδικας, το documentation ανύπαρκτο (η φτάση trial and error περιγράφει πλήρως την development phase), αλλά τουλάχιστον όλα είναι αντικείμενα σε C++ και όχι structs σε C. Αν έπρεπε να διαλέξω κάτι από τα παραπάνω, αυτό θα ήταν η C# και το VS.NET, χωρίς δεύτερη σκέψη.

Απορία: Τί είναι rich client;

Μία εφαρμογή για rich client είναι αυτή που τρέχει natively (ή, τέλος πάντων, σχεδόν natively) πάνω από ένα "πλήρες" λειτουργικό, και έχει στη διάθεσή της ένα ευρύ φάσμα τάξεων για να χρησιμοποιήσει, για παράδειγμα το Microsoft Word. Έτσι μεταφέρεται ένα μεγάλο μέρος της πολυπλοκότητας στον client. Άλλες εφαρμογές, που αναφέρονται καμιά φορά ως thin client, είναι εφαρμογές που για να εκτελεστούν, ο πελάτης διαθέτει ένα bare-bones λειτουργικό & shell και το μόνο που μπορεί να κάνει είναι Remote Desktop Connection σε έναν server (π.χ. ο client τρέχει Windows CE και ο server Windows Server 2000/2003). Σε αυτή την περίπτωση η πολυπλοκότητα μεταφέρεται στον server. Άλλο παράδειγμα είναι οι περισσότερες web εφαρμογές που εκτελούνται στο "σπαρτιάτικο" περιβάλλον ενός browser, όπως τα διάφορα webmail services. Εξαίρεση, η οποία θολώνει το τοπίο και δεν ξεκαθαρίζει τι είδους είναι αποτελεί το GMail και τα Google Maps.

Το πόσο βάρος θα ρίξεις σε CPU cycles ή στο ανθρωποκεντρικό κομμάτι εξαρτάται από την εκάστοτε εφαρμογή.Όπως λέει και ο κ. Μαλεύρης στα Θέματα Τεχν.Λόγ. στο σύστημα ενός αεροδρομίου που βρίσκεται σε συνθήκες κανονικής λειτουργίας σ'ενδιαφέρουν οι κύκλοι και όχι το interface ή πόσο καθαρογραμμένος είναι ο κώδικας.!Χωρίς αυτό να σημαίνει οτι η αναγνωσιμότητα και η συντηρισιμότητα έρχονται σε δεύτερη μοίρα, καθώς παίζουν σημαντικότατο ρόλο σε κάθε έργο.
Όμως ο έξυπνος προγραμματισμός σε καμία περίπτωση δεν υπάρχει μόνο για τα μάτια του συγγραφέα του: υπάρχει για να επαναχρησιμοποιείται και για να προωθεί την εξέλιξη!Αντίθετα η συντηρησιμότητα, η αναγνωσιμότητα κλπ. δεν είναι εξελίξιμοι τομείς από project σε project (δεν είναι static ) .Γι'αυτό και νομίζω πως απο τη μεριά του ο HdkiLLeR πολύ καλά κάνει και ενδιαφέρεται για την ταχύτητα.
Άσε που δεν πρέπει να υποτιμούμε τα κυκλάκια...Με κάθε γραμμή κώδικα, τα συνολικά CPU cycles στην ουσία πολλαπλασιάζονται!Όπως δεν πρέπει να υποτιμάς εναν αλγόριθμο που έχει εκθετικό χρόνο εκτέλεσης.

Δεν είπα ότι θα χρησιμοποιούσα ποτέ εκθετικούς αλγορίθμους ελαφρά τη καρδία, ή ότι θα τα άφηνα όλα στην τύχη τους, γι' αυτό άλλωστε τόνισα σε βαθμό που δεν επηρεάζει τους στόχους μίας εφαρμογής ότι θα προτιμούσα την συντηρησιμότητα/αναγνωσιμότητα. Αντίστοιχα προβλήματα με αυτά που αναφέρεις υπάρχουν και στην αντίθετη περίπτωση (π.χ. θυμάμαι στην Επικοινωνία Ανθρώπου Υπολογιστή μας είχαν πει για ένα πυρινικό εργοστάσιο στις ΗΠΑ που οδηγήθηκε σε meltdown επειδή δεν είχε προσεγμένο interface η εφαρμογή διαχείρισής του).

[Skeftomilos]

Γεια σου mikem4600 με τα παραθύρια σου! Πολύ-πολύ σωστά αυτά που λες. VB6? Τι μου θύμησες τώρα. Θα περίμενε κανείς ότι θα έχει βρει τη νέα και οριστική της θέση στο μουσείο, αλλά με έκπληξή μου βλέπω ότι κάποιοι δυσκολεύονται τόσο πολύ να κάνουν το άλμα στη VB.NET ώστε εξακολουθούν και σήμερα να ξεκινάνε νέα projects με αυτό το bug-circus.

Σχετικά με την ταχύτητα εκτέλεσης μίας εφαρμογής, αυτή σε καμία περίπτωση δεν είναι απόλυτη αξία. Είναι μία από τις συνιστώσες κατά την παραγωγή του λογισμικού και ανταγωνίζεται άλλες προτεραιότητες. Ένα πρόγραμμα δεν φτιάχνεται στο κενό, υπάρχει ημερομηνία παράδοσης και διαθέσιμο budget. Ο manager του έργου είναι υπεύθυνος για τη σωστή κατανομή πόρων προκειμένου να παρουσιάσει τελικά το καλύτερο δυνατό προϊόν σε σχέση με τους παραπάνω περιορισμούς. Ο νούμερο ένα πολύτιμος πόρος δεν η CPU αλλά ο χρόνος εργασίας του/των προγραμματιστών. Μάλιστα η συγκριτική αξία αυτού του πόρου εμφανίζει μόνιμη και ταχεία αύξηση καθώς η ανθρώπινη παραγωγικότητα μένει σταθερή ενώ το hardware γίνεται συνεχώς φθηνότερο και αποδοτικότερο. Στο παράδειγμα με το αεροδρόμιο π.χ. εάν μία διαδικασία μπορεί να επιταχυνθεί το ίδιο με 30 ώρες πρόσθετης προγραμματιστικής εργασίας ή με την προσθήκη μίας κάρτας μνήμης 256M, τι θα πρέπει να προτιμήσουμε? Είναι μάλλον απίθανο να μη μπορέσουμε να βρούμε καλύτερους τρόπους αξιοποίησης του πολύτιμου ανθρωποχρόνου. Ένα ενδιαφέρον άρθρο επί του θέματος με εύγλωττο τίτλο είναι το Optimizing Person-time, Not Computer-Time.

η συντηρησιμότητα, η αναγνωσιμότητα κλπ. δεν είναι εξελίξιμοι τομείς από project σε project,
δεν είναι static

Ο συλλογισμός αυτός έχει πολύ ενδιαφέρον. Φοβάμαι όμως ότι ίσως δεν τον κατανοώ απολύτως. Αν ένας προγραμματιστής φτιάξει ένα μη συντηρήσιμο - μη αναγνώσιμο πρόγραμμα, μάλλον και το επόμενο που θα φτιάξει θα έχει τα ίδια χάλια. Η προχειρότητα εθίζει και το κουσούρι πρέπει να κόβεται με το μαχαίρι όσο είναι νωρίς.

AmmarkoV βλέπω με φοβερή συμπάθεια την προσπάθειά σου με την custom GUI library. Είμαι σίγουρος ότι αν μη τι άλλο σε έκανε πολύ καλύτερο προγραμματιστή. Έχω και ο ίδιος ασχοληθεί με την ανακάλυψη του τροχού και γνωρίζω από πρώτο χέρι πόσο διασκεδαστικό μπορεί να είναι. Όμως το super textbox που επινόησες θα μπορούσες να το υλοποιήσεις πολύ ευκολότερα ως .NET custom control επεκτείνοντας το build-in System.Windows.Forms.TextBox, δανειζόμενος πλούσια υπάρχουσα λειτουργικότητα, αποφεύγοντας πιθανά κρυμμένα bugs και κυρίως σε ένα κλάσμα του χρόνου που χρειάστηκες για την υλοποίηση με χρήση native Win32 API. Θα μπορούσες έπειτα να πακετάρεις το νέο control σε ένα αυτόνομο Assembly, να το προσθέσεις στην ToolBox μαζί με τα υπόλοιπα controls, να το ξαναχρησιμοποιήσεις σε όλα τα επόμενα προγράμματά σου, να το κάνεις διαθέσιμο σε μία τεράστια κοινότητα προγραμματιστών και - γιατί όχι? - να το εκμεταλλευτείς εμπορικά.

[AmmarkoV]

... controls δεν ήταν στην πραγματικότητα controls αλλά... παράθυρα, και μάλιστα πλήρη, με χερούλια (hWnds) ...

Τhat`s what I am talking about..

Ο πιο δύσκολος/γρήγορος τρόπος για να φτιάξει κανείς GUI είναι με κατευθείαν πρόσβαση στο Video backbuffer ,τώρα για τη διαδικασία με την οποία μπορεί να έχει κάποιος το ίδιο αποτέλεσμα μέσω Win32 calls δεν μπορώ να πώ πως είναι πάρα πολύ χρονο-απαιτητική και όντας κατευθείαν portable σε Win98/ME/NT/2000/XP (και ακόμα και σε 64bitα από ότι γνωρίζω..) έχει και το ατού του αυτοσχεδιασμού αλλά και portability,τα προγράμματα δε που χρησιμοποιούν τις βιβλιοθήκες δεν απαιτούν πρόσθετη δουλειά από την στιγμή που δημιουργείς μόνος σου κ έναν designer σαν κερασάκι στην τούρτα..

Τώρα το θέμα των bugs είναι άλλη ιστορία και τα προγράμματα μου έχουν προς το παρόν μπόλικα ακόμα Το κύριο πρόβλημα για την μη διόρθωσή τους αλλά και γενικότερα στο να ξαναανακαλύπτεις τον τροχό είναι οτι ανοίγουν πολλά μέτωπα για τον προγραμματιστή.. Τι θα κάνεις πρώτα , υποστήριξη για extra image formats? , φίλτρα? , βελτίωση κώδικα? ,δουλειά σε ποιό από όλα ?
Αλλά τι να κάνει κανείς , αφού ο υπάρχων τροχός είναι τετράγωνος (Όχι πραγματικά )

Παρακάτω παραθέτω ένα (!πολύ χαζό-ενδεικτικό!) demo για να φανεί το πνέυμα της συναρτησιοστρεφούς μου βιβλιοθήκης..
Η Pascal-Delphi είναι υπόδειγμα user-friendly συντακτικού,και χωρίς καθόλου comments!
Ο παρακάτω κώδικας περιέχει και γρήγορη πληκτρολόγηση στις λέξεις "hell", "Text" ή "Demo"
Demo.pas <- Source
Demo.zip - 714KB <- ZIP file

Πάντως χαίρομαι που έχουμε μια τέτοια αμιγώς προγραμματιστική συζήτηση..!

To μέγεθος των βιβλιοθηκών-untis είναι 4227 γραμμές ,σας φαίνονται πολλές / λίγες?
Με .Net Skeftomilos (επειδή από ότι καταλαβαίνω έχεις ασχοληθεί) ένα 2D πρόγραμμα βγαίνει γρηγορότερα , απλότερα ?

[Skeftomilos]

Υποθέτω ότι 2D εννοείς ένα πρόγραμμα που εμφανίζει γραφικά (ευθείες, κύκλους, bitmaps) πάνω στη φόρμα ή καλύτερα σε ένα PictureBox. Είναι σαφώς ευκολότερο στο .NET από τη χρήση Win32 API στη VB6 που έχω δοκιμάσει. Η εμπειρία μου με VB6 ήταν εφιαλτική. Δεκάδες εντολές Declare για τις API functions, ορισμός αλλόκοτων structs και αναζήτηση των κατάλληλων constants από τις χιλιάδες διαθέσιμες. Ακόμα και όταν μετά από πολλούς κόπους και βάσανα κατάφερα να κάνω το πρόγραμμα να δουλέψει, διαπίστωσα έντρομος ότι ρουφούσε τη RAM του μηχανήματος με απίστευτο ρυθμό. Το memory lick προκαλούσε η λάθος σειρά κλήσης των εντολών DeleteDC και DeleteObject, όπως ανακάλυψα ύστερα.

Η εμπειρία που αποκόμισα με .NET είναι πολύ πιο συνεκτική. Αντί για structs υπάρχουν αντικείμενα με τις σχετιζόμενες μεθόδους, ο συντονισμός των οποίων δεν είναι ιδιαίτερα δύσκολος. Η γνώση του Win32 API με βοήθησε γιατί τα αντικείμενα αντιστοιχούν σε μεγάλο βαθμό στην υφιστάμενη υποδομή. Η ασφάλεια δεν είναι θέμα καθώς οι finalizers των disposable αντικειμένων φροντίζουν αυτόματα για την αποδέσμευση την handlers, αν και η explicit κλήση των μεθόδων dispose έχει ευεργετικές συνέπειες για την ομαλή λειτουργία του garbage collection. Ο object browser και το πολύ καλό documentation του VS κάνουν ακόμα πιο ευχάριστη την κατάσταση. Βέβαια δεν είναι σε καμία περίπτωση piece of cake και η συγγραφή του κώδικα απαιτεί προσοχή και συγκέντρωση. Μπορείς να δεις ένα screenshot από ένα μοντέλο μοχλού που έφτιαξα πριν αρκετό καιρό. Θα ήθελα να ακούσω ανάλογες εμπειρίες από κάποιον που έχει ασχοληθεί με δημιουργία γραφικών με Java.