Γλωσσες προγραμματισμου που δουλευουν αποκλειστικα με .net framework

[παπι]

Για τις αποδοσεις που λετε, σε γενικες γραμμες η .net (ολα τα υποσυστηματα της) χανει στο first run, επειτα ειναι πυραυλος. Aν ομως υπολογισεις τις βιβλιοθηκες της μαζι με τα διαφορα interface για async τοτε ειναι σχεδον σιγουρο οτι ενα πολυπλοκο προγραμμα γραμμενο σε .net θα ειναι γρηγοροτερο απο ενα native.

[ΠάρηςΓ]

Εξαρτάται πιστευω. Η .net στην αρχη ειναι θεοαργη πολλες φορες.

 

Για φαντασου browser σε .NET η Java ;;

 

Native

Οι καλες βασεις δεδομενων ειναι γραμμενες σε native...

OΙ καλοι browser επισης..

Το directX παιζει σε Native πλεον 100%, μπορεις και με αλλο τροπο αλλα για 100% εκμεταλευση

και αλλα πολλα... οπως βιβλιοθηκες επιστημονικες , matlab κτλ

 

Θεωρητικα το managed μπορει να ειναι γρηγοροτερο απο το Native αλλα αμφιβαλω αν ειναι στη πράξη.

Εξαρταται και πως θα το υλοποιήσεις.Θυμαμαι σε windows mobile το .net ειναι πολύ εως υπερβολικά αργο.

 

 

[ditsikts]

Εγώ που ασχολούμαι χομπιστικά δεν ασχολούμαι με .net γιατί με δένει με τα windows.

Gui εφαρμογές έκανα με Qt που φτιάχνεις γρηγορα εφαρμογές όπως και να ΄χει.

Επίσης στη c++ μπορείς να βρεις wrapper/library για το οτιδήποτε και γλιτώνεις πολύ κώδικα.

Ειδικά το Qt σε ένα input text box μπορείς από τα properties να του βάλεις να δέχεται μόνο αριθμούς, και έτσι δε χρείαζεται να κάνεις έλεγχο(extra κώδικας) π.χ. με float.TryParse για το αν ο χρήστης έβαλε νούμερο.

Επίσης το connect(SLOT SIGNAL) απλά τα "σπάει".

Προσωπική εμπειρία και γνώμη

[migf1]

...

Ο μόνος τρόπος που θα μπορούσα να το προσεγγίσω είναι να πάρουμε μία μία κάποιες δραστηριότητες και να εξετάσουμε αν σε κάθε μια απ' αυτές το native έχει κάτι να προσφέρει, ούτως ώστε στο τέλος (και αφού λάβουμε υπόψη και την "έκταση" κάθε δραστηριότητας) έχοντας αυτά τα δεδομένα να αποφανθούμε γενικά και για τη σημασία του native γενικότερα.

...

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

...

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

 

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

Μήπως εννοούμε άλλο πράγμα με τον όρο embedded; http://en.wikipedia....Embedded_system ;

 

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

 

Και δεν είναι μόνο τα ενσωματωμένα (συγκαταλέγω σε αυτή την κατηγορία και τους drivers, και το system programming), ήδη αρκετά παιδιά έθιξαν κι άλλες κατηγορίες (ακόμα κι από application programming) όπου resource-sensitive εφαρμογές επωφελούνται τα μέγιστα όταν γράφονται σε native κώδικα (π.χ. browsers, games, βιβλιοθήκες, γλώσσες, βάσεις δεδομένων, ... η λίστα είναι πραγματικά ανεξάντλητη).

 

Να και η γνωστή λίστα της C++ (για όσους δεν την ξέρουν) ως χαρακτηριστικό παράδειγμα που αν κι ενδεχομένως biased, δίνει μια πρώτη εικόνα για τη σημαντικότητα και το εύρος του native development: http://www2.research...plications.html

 

Για να είμαι ειλικρινής, δεν περίμενα με τίποτα να διαφωνήσεις για την γενικότερη σημασία και τον πολύτιμο ρόλο που παίζει το native coding σε αυτό το σύνθετο οικοδόμημα που ονομάζουμε μονολεκτικά "πληροφορική".

 

Δεν είμαι σίγουρος αν κατάλαβα τι λες.

 

Λες το native είναι σημαντικό επειδή τα programming tools είναι σε native?

 

Διαφωνώ διότι α) δεν ισχύει (π.χ. το VS πλέον είναι σε όλο και μεγαλύτερο τμήμα του managed, ενώ άλλοι ογκόλιθοι όπως Eclipse, Netbeans, Expression Blend κλπ είναι γραμμένοι εξολοκλήρου σε managed) και β) non sequitur

 

Λες ότι το native είναι σημαντικό επειδή κάποιες εταιρίες θεωρούν ότι αναπτύσσοντας native είναι πιο δύσκολο να τους μιμηθούν οι ανταγωνιστές ή να τους φύγουν οι χρήστες?

 

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

 

Επιπλέον, ακόμα κι αν ισχύει και πάλι η οποιαδήποτε εταιρία μπορεί να γράψει σε native αποκλειστικά εκείνο το τμήμα της εφαρμογής που περιέχει την όποια "μυστική συνταγή" -- αυτό δεν είναι επιχείρημα για το να γράψεις σε native όλη την εφαρμογή.

 

Τέλος, το πρόβλημα "πώς θα γίνει να μη με αντιγράψουν" είναι business πρόβλημα και όχι software development πρόβλημα. Επομένως στην καλύτερη περίπτωση το native έχει σημασία μόνο όταν δεν υπάρχουν άλλοι τρόποι να λύσεις τα business προβλήματά σου (που υπάρχουν: free market forces και δικηγόροι).

 

Ελπίζω να σε κάλυψα.

Από την απάντησή σου κατάλαβα ότι δεν κατάλαβες τι λέω

 

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

 

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

 

Αυτά τα 2 λοιπόν χαρακτήρισα ως μάλλον ξεκάθαρα hints του γιατί π.χ. η Microsoft ωφελείται προωθώντας, προτείνοντας, σπρώχνοντας αν προτιμάς το managed coding έναντι του native (προφανώς δεν είναι μόνο η Microsoft,, η Apple είναι ένα άλλο χαρακτηριστικό παράδειγμα).

 

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

[defacer]

Για να είμαι ειλικρινής, δεν περίμενα με τίποτα να διαφωνήσεις για την γενικότερη σημασία και τον πολύτιμο ρόλο που παίζει το native coding σε αυτό το σύνθετο οικοδόμημα που ονομάζουμε μονολεκτικά "πληροφορική".

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

 

Όπως τώρα έχουμε τη "διαμάχη" native vs. managed, παλιότερα υπήρχε η αντίστοιχη διαμάχη assembly vs. high-level language η οποία μάλιστα έχει πάρα μα πάρα πολλά κοινά στοιχεία μ' αυτά που λέμε εμείς τώρα. Σα χαρακτηριστικό παράδειγμα αναφέρω το επιχείρημα "assembly με το χέρι είναι πιο γρήγορη", κάτι που όντως ίσχυε παλότερα και κάτι που όντως γινόταν σε όλες τις intensive εφαρμογές τις οποίες τώρα και εσύ φέρνεις σαν παραδείγματα (games, λειτουργικά κλπ). Μέχρι που η τεχνολογία των high-level languages ωρίμασε αρκετά και φτάσαμε σήμερα να λέμε "μη κάνεις micro-optimizations και παπαριές γιατί το μόνο που καταφέρνεις είναι να δυσκολεύεις τον compiler που κάνει αυτή τη δουλειά καλύτερα απο σένα".

 

Ακριβώς όπως λοιπόν ακόμα και συ δε βγαίνεις σήμερα να εξάρεις τις χάρες τις assembly (η οποία αναμφισβήτητα έπαιξε έναν ιστορικά αναντικατάστατο ρόλο) έτσι και γω πιστεύω ότι η τεχνολογία των managed περιβαλλόντων έχει ωριμάσει/είναι στα πρόθυρα της ικανής ωρίμανσης για να περάσει το native σε δεύτερη μοίρα. Κι αυτό διότι τα "παραδοσιακά" του πλεονεκτήματα έχουν εξαλειφθεί σε πολύ μεγάλο βαθμό, ενώ από την άλλη το managed παρέχει μια σειρά από πλεονεκτήματα τα οποία το native ποτέ δε θα μπορέσει να παρέχει (γιατί απλά δε σχεδιάστηκε μ' αυτά τα πράγματα υπόψη).

 

That said, περνάω στο παρασύνθημα.

 

Μήπως εννοούμε άλλο πράγμα με τον όρο embedded; http://en.wikipedia....Embedded_system ;

Το ίδιο πράγμα εννοούμε.

 

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

 

Και δεν είναι μόνο τα ενσωματωμένα (συγκαταλέγω σε αυτή την κατηγορία και τους drivers, και το system programming), ήδη αρκετά παιδιά έθιξαν κι άλλες κατηγορίες (ακόμα κι από application programming) όπου resource-sensitive εφαρμογές επωφελούνται τα μέγιστα όταν γράφονται σε native κώδικα (π.χ. browsers, games, βιβλιοθήκες, γλώσσες, βάσεις δεδομένων, ... η λίστα είναι πραγματικά ανεξάντλητη).

Κατ' αρχήν οφείλω να πώ ότι το να συγκαταλέγεις στην κατηγορία embedded τους drivers και το system programming είναι τελείως αυθαίρετο και παρόμοιο με το να συγκαταλέγεις στην κατηγορία αυτοκινήτων τα αεροπλάνα. Νομίζω είναι τελείως προφανές και από το link που εσύ ο ίδιος έδωσες.

 

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

 

Η λίστα που δίνεις στη συνέχεια είναι κατά την άποψή μου μια μεγάλη γενικότητα (no offense) εφόσον υπάρχουν παραδείγματα για όλες τις κατηγορίες εφαρμογών που αναφέρεις σε managed περιβάλλοντα. Έχεις παίξει Bastion (αν όχι, παίξε!)? Το ξέρεις ότι είναι γραμμένο σε managed? Σε 10 χρόνια λοιπόν να δεις που θα είναι γραμμένο σε managed και το Doom 6. Και ο Internet Explorer θα γίνει managed πολύ πριν απ' αυτό. Αν είσαι δύσπιστος, φαντάσου τι θα απαντούσες πριν 5 χρόνια σε κάποιον που θα σου έλεγε ότι από την επόμενη έκδοση του Visual Studio θα ξεκινήσει η σταδιακή επανα-υλοποίηση της εφαρμογής σε managed.

 

Να και η γνωστή λίστα της C++ (για όσους δεν την ξέρουν) ως χαρακτηριστικό παράδειγμα που αν κι ενδεχομένως biased, δίνει μια πρώτη εικόνα για τη σημαντικότητα και το εύρος του native development: http://www2.research...plications.html

 

Αυτή είναι μια λίστα εφαρμογών με το κοινό χαρακτηριστικό "γραμμένες σε C++", το οποίο δεν έχει καμία σχέση με το χαρακτηριστικό "εν έτει 2012 πρέπει αναγκαστικά για τεχνικούς λόγους να γραφούν σε C++". Για να το αναλύσω περισσότερο, η λίστα αυτή (και κάθε άλλη λίστα τέτοιου είδους) μπορεί να περιλαμβάνει εφαρμογές οι οποίες:

 

• Όταν γράφτηκαν υπήρχαν τεχνικοί λόγοι οι οποίοι τώρα πια δεν υπάρχουν (π.χ. το 2000 δεν υπήρχε .net και η Java ήταν αστείο)
  
• Προορίζονται για συστήματα στα οποία η ύπαρξη managed περιβάλλοντος δεν είναι δεδομένη
  
• Γράφτηκαν σε C++ για μη-τεχνικούς λόγους (π.χ. εγγυημένο portability σε όλες τις πλατφόρμες που έχουν C++ compiler)
  
• ...φαντάζομαι υπάρχουν και άλλα που δε μου έρχονται τώρα στο μυαλό
  

 

Από την απάντησή σου κατάλαβα ότι δεν κατάλαβες τι λέω

 

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

 

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

 

Αυτά τα 2 λοιπόν χαρακτήρισα ως μάλλον ξεκάθαρα hints του γιατί π.χ. η Microsoft ωφελείται προωθώντας, προτείνοντας, σπρώχνοντας αν προτιμάς το managed coding έναντι του native (προφανώς δεν είναι μόνο η Microsoft,, η Apple είναι ένα άλλο χαρακτηριστικό παράδειγμα).

 

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

 

Δε νομίζω ότι είναι σκόπιμο να αναλύσω αυτό το παραπάνω όσο περισσότερο θα μπορούσα γιατί απλά έισαι factually wrong. Για παράδειγμα, τόσο η C# όσο και το ίδιο το CLI είναι εδώ και χρόνια τυποποιημένα διεθνή standard (κάτι που έγινε με πρωτοβουλία της Microsoft φυσικά).

 

Με άλλα λόγια: και το τι είσοδο πρέπει να παίρνει ο compiler και το τι είσοδο πρέπει να βγάζει και το πώς πρέπει να συμπεριφέρεται το runtime είναι ανοιχτά σε όλους (και φυσικά έτσι άνοιξε ο δρόμος για το Mono).

 

Και για να μην αφήσω τη Java παραπονεμένη: η τρέχουσα επίσημη υλοποίηση της Java είναι open source και φυσικά αυτό έγινε με πρωτοβουλία της Sun, κάτι που άνοιξε το δρόμο για το GNU classpath. Επίσης ανοιχτό σε όλους είναι το specification του JVM, πράγμα που επέτρεψε μεταξύ άλλων το Dalvik. Υπάρχουν πολλά ακόμα παραδείγματα.

 

Από τη στιγμή λοιπόν που είναι λάθος τόσο τα δεδομένα σου όσο και τα συμπεράσματά σου (προφανώς αν MS και Sun/Oracle όντως ήθελαν να αποθαρρύνουν όπως λες δε θα γινόταν όλα αυτά τα πράγματα) πιστεύω ότι οφείλεις να αναθεωρήσεις.

[moukoublen]

@defacer και @migf

Νομίζω ότι υπάρχει ένα σημείο στο οποιο δε διαφωνείτε.

 

Δε νομίζω ότι υποστηρίζει κανεις πως ο native προγραμματισμός θα πάψει ποτε οριστικά. (ε?)

 

Είναι άλλο πράγμα το (σχεδόν οριστικό) πέρασμα από Assembly σε high-level γλώσσες οι compilers των οποίων παραγουν assebly που εκτελείται (σχεδόν άμεσα) από τον υλικό επεξεργαστή.

 

Και είναι άλλο πράγμα η pseudo-assembly CLI η Java-byte-code που εκτελείται από λογισμικό.

Αυτό το δεύτερο, το λογισμικό, είναι πασιφανές ότι είναι και θα είναι πάντα native.

 

Και αυτό είναι ένα παράδειγμα. Οι browsers όπως είπε πάνω ένας φίλος και οι βάσεις δεδομένων είναι ένα άλλο παράδειγμα.

 

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

 

Έτσι κι αλλιώς τα πράγματα αλλάζουν κατευθύνσεις.

 

Για παράδειγμα τώρα με την HTML5 παρα πολλές εφαρμογές θα γραφτούν εκεί. Ακόμα και ολόκληρα λειτουργικά (βλέπω windows 8) την υποστηρίζουν εγγενώς για την ανάπτυξη εφαρμογών.

 

Το runtime όμως, η μηχανή που θα εκτελεί την javascript, προφανώς θα είναι ένας native πυρήνας.

 

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

[migf1]

...

Από τη στιγμή λοιπόν που είναι λάθος τόσο τα δεδομένα σου όσο και τα συμπεράσματά σου (προφανώς αν MS και Sun/Oracle όντως ήθελαν να αποθαρρύνουν όπως λες δε θα γινόταν όλα αυτά τα πράγματα) πιστεύω ότι οφείλεις να αναθεωρήσεις.

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

 

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

 

Μερικά κατά τη γνώμη μου χρήσιμα links (που απλώς φωτίζουν με μια ματιά απλώς την κορυφή του παγόβουνου):

 

http://www.bccresear...ts-ift016d.html

http://www.digitimes...ages=PR&seq=211

http://ww.vdcresearch.com/

 

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

 

α) Τους drivers & το system programming το έβαλα μαζί με τα ενσωματωμένα όχι μόνο χάριν συντομίας αλλά κι επειδή μοιράζονται κοινές προσεγγίσεις. Μπορείς να τα βάλεις και σε ξεχωριστές κατηγορίες, αυτό δεν αλλάζει ούτε τελεία από το argument του επιχειρήματος περί χρησιμότητας του unmanaged code.

 

β) Ένας από τους βασικούς λόγους που η assembly "κατέρρευσε" έναντι της C (αρχικά, και των άλλων γλωσσών αργότερα) ήταν η απόλυτη εξάρτησή του κώδικά της με το εκάστοτε hardware. Αυτό σήμερα ισχύει σε (πολύ πολύ πολύ) μικρότερο βαθμό, μιας και οι κατεξοχήν unmanaged γλώσσες που είναι η C και C++ είναι κατά πάρα πολύ μεγάλο ποσοστό στανταρισμένες για όλες τις πλατφόρμες. Και προφανώς εδώ αναφέρομαι πολύ περισσότερο στο app programming.

 

Αν το TIOBE index είναι έστω και κατά το ήμισυ ενδεικτικό, τόσο η C όσο και η C++ βρίσκονται μονίμως στο top-3 της δημοφιλίας επί ολόκληρες 10ετίες (τουλάχιστον 3).

Αυτό από μόνο του αν μη τι άλλο αρκεί για να καταλάβει κανείς πως το unmanage code δεν απεικονίζει μόδα, τάση, πυροτέχνημα αλλά ουσία και προοπτική.

 

γ) Στην αρχή του link με τα apps της C++ που έδωσα παραπάνω, υπάρχει το link Major industry applications and tools στο οποίο απεικονίζονται και περιπτώσεις όπου απόπειρες των κατασκευαστών για managed code κρίθηκαν ανεπαρκείς, με αποτέλεσμα να επιστρέψουν στο managed.

 

Τελειώνοντας, εγώ προσωπικά δεν διαφωνώ για τα πλεονεκτήματα του managed code, διαφωνώ με την εσφαλμένη κατά την άποψή μου αντίληψη που καλλιεργείται και διαδίδεται (συχνά εντέχνως, από τους ίδιους τους κατασκευαστές, οι οποίοι συμπαρασύρουν ηθελημένα ή αθέλητα την κοινή γνώμη) πως αποτελούν ένα είδος πασπαρτού για την πλειονότητα των αναγκών.

 

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

 

...

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

...

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

...

Είναι έως και αδύνατον να μπορέσουμε να αναλύσουμε όλες τις κατηγορίες στις οποίες έχει εφαρμογή ο προγραμματισμός. Ίσως να μην μπορούμε ούτε καν να τις απαριθμήσουμε

[Directx]

Μήπως εννοούμε άλλο πράγμα με τον όρο embedded; http://en.wikipedia....Embedded_system ;[..]

Πολύ ενδιαφέρουσα λίστα, αλλά για να ευθυμήσουμε λίγο, από προσωπική εμπειρία πάντα.. η χρήση της C++ από το SYMBIAN (μιλώ για την κλασσική *SYMBIAN C++ όχι την SYMBIAN QT C++) ήταν μάλλον δυσφήμιση για την γλώσσα καθώς επρόκειτο για μια άθλια, εξαιρετικά ιδιωματική εκδοχή της, αν είχε υπόψη του ο Stroustrup έστω και ελάχιστα για τι πράγμα μιλάμε.. θα την έκρυβε κάτω από το χαλάκι

 

*μια ακόμα αιτία που οδήγησε το SYMBIAN στον θάνατο

[migf1]

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

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

[Directx]

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

Μακάρι να έμοιαζε με καθαρή C (θα έκανα ειλικρινά πάρτι τότε, σαν δεις την SYMBIAN C++ εκτιμάς την απλότητα της C και ας μην έχει τίποτε έτοιμο )! Για να σώσουν μνήμη (στο SYMBIAN πριν το v3 τα 128MB θεωρούνταν υπέρ αρκετά - εδώ υπήρχαν SYMBIAN συσκευές με μόλις 10MB ελεύθερα για τις εφαρμογές - paging δεν υπήρχε αρχικά μετά υπήρχε μόνο για το CODE SEGMENT και όχι για το DATA SEGMENT κλπ) είχαν κάνει διάφορα κόλπα που καθιστούσαν την ανάπτυξη έναν εφιάλτη (δεν είχαμε exceptions, θέλαμε 2 phase constructors, καθαρισμός του stack χειροκίνητα, αντί για strings υπήρχε ένα ανάλογο σύστημα πολύ compact ονόματι descriptor, για multitasking υπήρχε το ιδιωματικό Active Objects (!), STL αρχικά πουθενά - το SYMBIAN είχε κάποια δικά του ανάλογα containers που ήταν .. άστα να πάνε ..), βάλε τώρα ότι το σύστημα γράφηκε αρχές του '90 όταν ακόμα το πρότυπο της C++ δεν ήταν πλήρες + ότι ως νεόφυτοι στην C++ οι σχεδιαστές του (οι ίδιοι το παραδέχονται στον οδηγό αναφοράς του SYMBIAN) έπεσαν στην παγίδα του υπέρ OOP (2 & 3 class derived μεταξύ τους για να κάνεις αυτό που θες..), καταλαβαίνεις. . . Δυστυχώς η NOKIA άργησε να ενδιαφερθεί για αυτό το μπάχαλο (το έκανε εξ ανάγκης του iPhone) και έτσι όταν άρχισε το port του QT στο SYMBIAN για να καλύψει την ασχήμια της SYMBIAN C++ και να προσελκύσει τους αηδιασμένους developer πίσω (αλλά και για να ενοποιήσει τις πλατφόρμες που είχε τότε η εταιρία και να καταστήσει transparent τον προγραμματισμό των κινητών της ανεξαρτήτως Λ. Σ.) ήταν μάλλον αργά...

[παπι]

Γιατι θεωρειτε οτι τα games θα ετρεχαν πιο γρηρορα σε native;

[migf1]

Γιατι θεωρειτε οτι τα games θα ετρεχαν πιο γρηρορα σε native;

Η απάντηση δεν είναι απλή, ούτε τρέχουν πάντα πιο γρήγορα τα native. Κατά κανόνα όμως τρέχουν πιο γρήγορα, κυρίως λόγω του έξτρα layer που μεσολαβεί στο runtime των managed (με όλα το overhead που αυτό συνεπάγεται, π.χ. garbage-collection, bound-checking, κλπ).

 

Αν συγκρίνουμε ακριβώς ίδιες αλγοριθμικά υλοποιήσεις σε managed και unmanaged κώδικα, προσαρμοσμένες προφανώς στα πλεονεκτήματα της κάθε γλώσσας, τότε το unmanaged είναι νομοτελειακά πιο γρήγορο.

 

Υπογράμμισα το παραπάνω, για να μη συγκρίνουμε ας πούμε μια υλοποίηση managed που χρησιμοποιεί parallelization με μια unmanaged που δεν χρησιμοποιεί. Ή για να μη συγκρίνουμε μια cross-platform unmanaged υλοποίηση με μια JIT target optimized managed υλοποίηση. Ή π.χ. για να μη συγκρίνουμε μια εξορισμού cached managed υλοποίηση με μια uncached unmanaged.

 

Πέρα από αυτό, με τον unmanaged κώδικα έχεις πολύ μεγαλύτερες ελευθερίες (π.χ. δεν χρειάζεται να χρησιμοποιήσεις υποχρεωτικά garbage collector, ούτε ας πούμε χρειάζεται να κάνεις new/delete για ΚΑΘΕ object στην heap).

 

EDIT:

 

Έριξα μια ματιά στο google, για links με πιο εξειδικευμένες γνώσεις από τις δικές μου (κυρίως στο managed) και (με χαρά) διαπίστωσα πως και σε αυτά πάνω-κάτω τα ίδια points θίγουν.

 

Για παράδειγμα: http://stackoverflow...anaged-native-c

 

Είναι λίγο πιο παλιό βέβαια (2010) οπότε δεν ξέρω τι είδους έξτρα βελτιστοποιήσεις ενδέχεται να έχουν προστεθεί στα σημερινά VMs.

[defacer]

@defacer και @migf

Νομίζω ότι υπάρχει ένα σημείο στο οποιο δε διαφωνείτε.

 

Δε νομίζω ότι υποστηρίζει κανεις πως ο native προγραμματισμός θα πάψει ποτε οριστικά. (ε?)

 

Ούτε και γω, πολύ απλά γιατί για να φορέσεις ένα managed runtime environment σε κάποια πλατφόρμα είναι παραπάνω δουλειά. Απο τη στιγμή που στην πλατφόρμα Χ δεν υπάρχει ήδη managed runtime και που για οποιοδήποτε λόγο δεν είναι οικονομικά σκόπιμο να αναπτυχθεί κάτι τέτοιο, η πλατφόρμα Χ ποτέ δε θα αποκτήσει managed runtime.

 

Είναι άλλο πράγμα το (σχεδόν οριστικό) πέρασμα από Assembly σε high-level γλώσσες οι compilers των οποίων παραγουν assebly που εκτελείται (σχεδόν άμεσα) από τον υλικό επεξεργαστή.

 

Και είναι άλλο πράγμα η pseudo-assembly CLI η Java-byte-code που εκτελείται από λογισμικό. Αυτό το δεύτερο, το λογισμικό, είναι πασιφανές ότι είναι και θα είναι πάντα native.

 

Νομίζω πως έχεις λάθος ιδέα στο μυαλό σου. Το οποιουδήποτε είδους bytecode πριν εκτελεστεί μετατρέπεται σε machine code από τον εκάστοτε Just-in-time compiler (aka "jitter"). Η μόνη τεχνική διαφορά ανάμεσα στο native και το managed όπως τα εννοούμε σ' αυτή την κουβέντα είναι ότι στην πρώτη περίπτωση εμπλέκεται ένας compiler που παράγει κατευθείαν machine code ενώ στη δεύτερη αυτό γίνεται σε περισσότερα του ενός στάδια (και βέβαια μεσολαβούν και άλλες διαδικασίες αλλά αυτό δεν έχει να κάνει μ' αυτό που ανέφερες).

 

Όταν φτάσει η ώρα να εκτελεστεί machine code, και το native και το managed (σχεδόν) το ίδιο πράγμα θα κάνουν. Αυτό ισχύει πλέον σε μεγάλο βαθμό ακόμα και για τη Javascript η οποία "στα χαρτιά" δεν είναι καν compiled language! (πόσο μάλλον για Java, C# κλπ)

 

@migf1: Για το πρώτο τμήμα της απάντησής σου το μόνο που έχω να πω είναι ότι το να παραθέτεις marketing links (αν είναι) που λένε ότι η αγορά για embedded software το 2015 θά είναι $6.1b εμένα μου λέει ότι με δουλεύεις όταν π.χ. το MW3 έκανε τζίρο μέσα σε 16 μέρες πάνω από $1b.

 

Σοβαρά τώρα, δεν έχω να πώ τίποτα παραπάνω. Συνειδητοποιείς ότι το ετήσιο μέγεθος όλου του embedded software market (με βάση το νούμερο από το link σου) είναι συγκρίσιμο με το "ετήσιο μέγεθος" του market του MW3 ΜΟΝΟ? Αυτή είναι η ιδέα σου περί σημαντικής αγοράς?

 

Μου φαίνεται μπερδέψαμε τις βούρτσες με κάτι άλλο.

 

α) Τους drivers & το system programming το έβαλα μαζί με τα ενσωματωμένα όχι μόνο χάριν συντομίας αλλά κι επειδή μοιράζονται κοινές προσεγγίσεις. Μπορείς να τα βάλεις και σε ξεχωριστές κατηγορίες, αυτό δεν αλλάζει ούτε τελεία από το argument του επιχειρήματος περί χρησιμότητας του unmanaged code.

 

Με συγχωρείς αλλά αυτό είναι τελείως αναληθές και παραπλανητικό γιατί αλλάζει όλο το argument. Δε μπορεί να μου λες ότι το embedded μεγέθους 1kg (όπου συμπεριλαμβάνεις λειτουργικά και της παναγιάς τα μάτια με το έτσι θέλω, συνολικού μεγέθους περίπου κανα εκατομμύριο τόνους) είναι "βαρύ", κι όταν σε διορθώνω λέγοντας πως όχι, δεν περιλαμβάνει αυτό το εκατομμύριο τόνους, να λες ότι "δεν αλλάζει τίποτα". Θεωρώ ότι οποιοσδήποτε νοήμων άνθρωπος μπορεί να το αντιληφθεί.

 

β) Ένας από τους βασικούς λόγους που η assembly "κατέρρευσε" έναντι της C (αρχικά, και των άλλων γλωσσών αργότερα) ήταν η απόλυτη εξάρτησή του κώδικά της με το εκάστοτε hardware. Αυτό σήμερα ισχύει σε (πολύ πολύ πολύ) μικρότερο βαθμό, μιας και οι κατεξοχήν unmanaged γλώσσες που είναι η C και C++ είναι κατά πάρα πολύ μεγάλο ποσοστό στανταρισμένες για όλες τις πλατφόρμες. Και προφανώς εδώ αναφέρομαι πολύ περισσότερο στο app programming.

 

Όντως το portability (που στην assembly ήταν μηδενικό) ήταν σημαντικός παράγοντας. Σημαντικότερος όμως ήταν το ότι προγραμμάτιζες σε υψηλότερο επίπεδο έκφρασης, οπότε νομίζω ότι αυτό που λες περνάει σε δεύτερη μοίρα. Απόδειξη? Διάβασε τον ορισμό του third-generation programming language -- γνωστής και ως "high-level language" και όχι "portable language".

 

Αν το TIOBE index είναι έστω και κατά το ήμισυ ενδεικτικό, τόσο η C όσο και η C++ βρίσκονται μονίμως στο top-3 της δημοφιλίας επί ολόκληρες 10ετίες (τουλάχιστον 3).

Αυτό από μόνο του αν μη τι άλλο αρκεί για να καταλάβει κανείς πως το unmanage code δεν απεικονίζει μόδα, τάση, πυροτέχνημα αλλά ουσία και προοπτική.

 

The TIOBE Programming Community index is an indicator of the popularity of programming languages.

 

Επομένως σε μια συζήτηση με θέμα το ποιές γλώσσες είναι δημοφιλείς το link σου θα ήταν σχετικό. Σε μια συζήτηση με θέμα το αν το development σε native languages ή το development σε managed είναι "the way forward" είναι άσχετο. Για να εξετάσει κανείς αν το managed είναι επίκαιρο τώρα, θα πρέπει να δει το TIOBE index σε καμιά εικοσαριά χρόνια (γιατί φυσικά ο καθένας ψηφίζει τη γλώσσα που του αρέσει, πράγμα που προϋποθέτει πρώτα να την έχει μάθει, και στη συντιπτική πλειοψηφία μαθαίνει κανείς γλώσσες επειδή είναι ήδη θρονιασμένες, όχι επειδή είναι ανερχόμενες).

 

Update: Παρεμπιπτόντως, βλέπω ότι στο top 10 οι 7 γλώσσες είναι managed και ότι από τις 3 που δεν είναι η μία βρίσκεται εκεί απλά και μόνο γιατί έτσι είπε η Apple.

 

Κλείνοντας θέλω να πω ότι απογοητεύομαι από το γεγονός ότι συστηματικά αποφεύγεις να αναφερθείς στα επιχειρήματά μου (προφανώς εννοώ με προοπτική να τα καταρρίψεις) πέραν αναφορών του στυλ "δε συμφωνώ" και αντί γι' αυτό ακολουθείς την τακτική "άλλα λόγια ν' αγαπιόμαστε", δηλαδή παραθέτεις νέες απόψεις/links κλπ. Όταν ασχοληθώ μαζί τους (προφανώς με προοπτική να τα καταρρίψω) απλά συνεχίζεις σα να μην έγινε τίποτα και παραθέτεις κι άλλα. Δεν έχω διάθεση να συνεχίσω το whack-a-mole.

 

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

 

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

 

Όπως είπε και ο Directx, αυτό που συνέβη ήταν κυρίως πως εκείνη την εποχή δεν υπήρχε κάν standard για τη C++! Επομένως αναγκαστικά στο Symbian αναγκάστηκαν να κάνουν implement κάτι ψιλοπράγματα όπως exceptions με δικό τους τρόπο (εκείνο το leave όποτε το θυμάμαι έχω εφιάλτες) και ας πούμε ότι... δεν ήταν τόσο καλό το αποτέλεσμα.

 

By the way είχα και γω σαν παιδί μια επαφή με embedded συστήματα.

 

Η απάντηση δεν είναι απλή, ούτε τρέχουν πάντα πιο γρήγορα τα native. Κατά κανόνα όμως τρέχουν πιο γρήγορα, κυρίως λόγω του έξτρα layer που μεσολαβεί στο runtime των managed (με όλα το overhead που αυτό συνεπάγεται, π.χ. garbage-collection, bound-checking, κλπ).

 

Αν συγκρίνουμε ακριβώς ίδιες αλγοριθμικά υλοποιήσεις σε managed και unmanaged κώδικα, προσαρμοσμένες προφανώς στα πλεονεκτήματα της κάθε γλώσσας, τότε το unmanaged είναι νομοτελειακά πιο γρήγορο.

 

Η πρώτη παράγραφος είναι παραπλανητική. Το αν ο κώδικας είναι provably safe, ή το αν χρησιμοποιεί garbage collection σε καμία περίπτωση δεν έχει να κάνει με το αν το περιβάλλον εκτέλεσης είναι managed ή όχι. Για παράδειγμα, μπορείς να βάλεις μια χαρά garbage collector σε unmanaged C++ (προφανώς, το έχουν όλες οι Javascript engines) και επίσης μπορείς αν θέλεις να χρησιμοποιείς vector.at αντί για vector.operator[].

 

Το γεγονός ότι οι σχεδιαστές managed γλωσσών επέλεξαν να θυσιάσουν by default (γιατί βεβαίως μπορείς και να απενεργοποιήσεις κάποια από αυτά τα features, πχ δες unsafe και unchecked στη C#) ένα μέρος performance για να κερδίσουν stability έχει να κάνει με το γεγονός ότι πλέον έχουμε αρκετό performance για να μας παίρνει να θυσιάσουμε ένα μέρος του προκειμένου να κερδίσουμε άλλα πράγματα πιο σημαντικά. Ακριβώς όπως και στις απαρχές της C με τους τραγικούς compilers οι σχεδιαστές θεώρησαν ότι μας παίρνει να θυσιάσουμε ένα μέρος performance προκειμένου να γράφουμε αλγορίθμους σαν άνθρωποι. Ακριβώς όπως (παραλληλίζω: αξία χρημάτων == αξία γρήγορης εκτέλεσης) αν ρωτήσεις έναν άστεγο και έναν techie πόσο σημαντικό είναι το κινητό στη ζωή θα σου απαντήσουν και οι δύο "την παλεύεις?" -- για διαφορετικό όμως λόγο.

 

Με άλλα λόγια, τα features στα οποία αναφέρεσαι έμμεσα είναι κάτι που επιλέχθηκε εσκεμμένα από τους σχεδιαστές των περιβαλλόντων, όχι κάτι που είναι "έμφυτο" στο DNA του managed.

 

Όσο για το "νομοτελειακά" πιο γρήγορο: έτσι για να κάνω το δικηγόρο του διαβόλου, έχεις υπόψη ότι ας πούμε ένας jitter μπορεί να μετατρέψει IL σε ο,τι πιο σύγχρονο instruction set υποστηρίζει η CPU στην οποία τρέχει, ενώ από την άλλη σε ένα native binary επιλέγεις target CPU at compile time και τέλος;

 

Δε διαφωνώ με το "πολλές φορές" πιο γρήγορο (αν και όπως είπα διάλεξε τι προτιμάς: λίγο πιο αργό ή undefined behavior?) αλλά το "νομοτελειακά" απλά δεν ισχύει.

[moukoublen]

Νομίζω πως έχεις λάθος ιδέα στο μυαλό σου. Το οποιουδήποτε είδους bytecode πριν εκτελεστεί μετατρέπεται σε machine code από τον εκάστοτε Just-in-time compiler (aka "jitter"). Η μόνη τεχνική διαφορά ανάμεσα στο native και το managed όπως τα εννοούμε σ' αυτή την κουβέντα είναι ότι στην πρώτη περίπτωση εμπλέκεται ένας compiler που παράγει κατευθείαν machine code ενώ στη δεύτερη αυτό γίνεται σε περισσότερα του ενός στάδια (και βέβαια μεσολαβούν και άλλες διαδικασίες αλλά αυτό δεν έχει να κάνει μ' αυτό που ανέφερες).

Σύμφωνοι. Δικια μου αστοχία.

 

Επι της ουσίας όμως αυτό που θέλω να πω είναι ότι για να δημιουργηθεί το οποιοδήποτε managed περιβάλλον - αρχιτεκτονική τα "εργαλεία"-"μέρη" του (ο compiler, ο just-in-time compiler - runtime σύστημα η ο,τι άλλο) θα έχουν φτιαχτεί -αναγκαστικά θεωρώ- natively.

 

Π.χ. το Java virtual machine για windows x86 είναι γραμμένο (π.χ.) σε C/C++ (τέλος πάντων native). Σωστά;

 

Και θέλω με αυτό να πω πως η αίσθηση που μου δίνεται είναι οτι η native ανάπτυξη δε χάνεται απλά μετατοπίζεται αλλού.

[defacer]

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