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

[moukoublen]

@DirectX

Σωστά. Όμως ο Reflaction μηχανισμός (και ο Marshal και ο Interop κτλ) είναι προσβάσιμοι από το .net γενικότερα, οποτε και από C# η VB (*)

 

 

@defacer

Ναι όντως μάλλον είναι θέμα "αγκύλωσης" που έχω σε σχέση με το διαμάντι που λέγεται C++. (*)

 

(*) Ο λόγος τις όλης απορίας μου είναι καθαρά ακαδημαϊκός. Τίποτα παραπάνω (και τίποτα λιγότερο )

 

Και απεικονίζεται καλά στο ερώτημα που έθεσε ο migf που θα το αναπτύξω παραπάνω.

 

Όντως λοιπόν αν εξαιρέσουμε το ζήτημα συνήθειας - εμπειρίας (θα επανέλθω εδώ) μπορείς άραγε να κανεις πιο (να το πω έτσι) "βαθιά" πράγματα με την C++/CLI απ ότι με την C#;

 

Και αφήνω έξω την συνήθεια γιατί όντως ίσως για τον C++ developer να είναι πιο εύκολο να πάει προς C++/CLI παρά προς C# (αν και δεν είμαι βέβαιος για αυτό).

 

Απο κει και πέρα αυτό που δείχνει πολύ σημαντικό είναι αυτό που είπε ο defacer για τη μεταφερσιμότητα του c++ code base πιο ανώδυνα.

 

Και βασικότερα απ ότι καταλαβαίνω η δυνατότητα υποστήριξης και μεταφοράς των C++ developer μέσα στο .net

[Directx]

@DirectX

Σωστά. Όμως ο Reflaction μηχανισμός (και ο Marshal και ο Interop κτλ) είναι προσβάσιμοι από το .net γενικότερα, οποτε και από C# η VB (*)

[..]

Είναι τμήματα του framework οπότε..

Και βασικότερα απ ότι καταλαβαίνω η δυνατότητα υποστήριξης και μεταφοράς των C++ developer μέσα στο .net

Το δοκίμασε αυτό αλλά εκβιαστικά (με τον γνωστό τσαμπουκά του Ballmer ) στα WP7 όπου δεν παρείχε καμία δυνατότητα συγγραφής native κώδικα παρά μόνο managed C# και η προσπάθεια της δεν απέδωσε τα αναμενόμενα (ok, υπήρξαν και άλλοι παράγοντες υπαίτιοι) οπότε τώρα στα WP8 αναφέρει ρητά την υποστήριξη ανάπτυξης και σε native κώδικα (C/C++).

 

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

 

Από την άλλη πλευρά η Google στο Android έχει ακολουθήσει "τον δρόμο των Windows", δηλαδή έχεις Java αλλά και native C/C++ (από την 2.3+ η υποστήριξη C++ έχει βελτιωθεί αρκετά) οπότε κανονίζεις την πορεία σου με βάση τις ανάγκες που έχει η εφαρμογή σου.

[defacer]

Πάντως καθώς το .NET Framework συνολικά είναι πανίσχυρο (κενά πάντα θα υπάρχουν σε ορισμένες υπηρεσίες btw) σπάνια καταφεύγεις στο Reflection κλπ.

 

Τουναντίον, "πολύ συχνά"¹ καταφεύγεις στο reflection προκειμένου να μπορέσεις να υλοποιήσεις τα high-level interfaces της όποιας βιβλιοθήκης, γιατί είναι ο μόνος τρόπος να ξεφύγεις από τους περιορισμούς του static typing των C#, VB, C++/CLI. Αυτό είναι κάτι που δεν μπορεί να καλυφθεί με άλλο τρόπο (δηλαδή δεν είναι θέμα ότι αν είχαμε άλλες 1000 class δε θα χρειαζόμασταν το reflection).

 

¹ με την έννοια ότι θα το κάνεις τουλάχιστον σε ένα σημείο σε πάρα πολλά projects, όχι σε πάρα πολλά σημεία μέσα στο ίδιο project (κάτι που στη γενική περίπτωση δείχνει λάθος design).

 

Αν το ζητούμενο είναι το managed coding, τότε η C# δεν υποσκελίζει χαλαρά την C++/CLI;

 

Ναι, κυρίως γιατί η γραμματική της δημιουργήθηκε εκ νέου.

 

Όντως λοιπόν αν εξαιρέσουμε το ζήτημα συνήθειας - εμπειρίας (θα επανέλθω εδώ) μπορείς άραγε να κανεις πιο (να το πω έτσι) "βαθιά" πράγματα με την C++/CLI απ ότι με την C#;

 

Δεν είμαι σίγουρος τι πρέπει να απαντήσω εδώ γιατί μπορώ να σκεφτώ μόνο 2 μεγάλα κεφάλαια της C++ που δεν υποστηρίζονται από τη C#:

 

1. pointers

2. templates

 

Το πρώτο βασικά είναι ψέμα γιατί μπορείς να γράψεις unverifiable κώδικα (μέσω του keyword "unsafe") όπου διαθέτεις pointers.

 

Για το δεύτερο ναι, δε μπορείς να κάνεις template metaprogramming σε C#. Αλλά αυτό είναι ένα language feature το οποίο έχει μάλλον περιορισμένο κοινό (εδώ ο περισσότερος κόσμος σκαλώνει στο να γράψει ένα απλό template, αμα ακούσουν για compile time programming θα εκραγεί το κεφάλι τους).

 

Πάντως στο 99% (στατιστικό επιστημονικά τεκμηριωμένο γιατί μόλις το έβγαλα απ' το μυαλό μου) των περιπτώσεων managed is the way to go γιατί έχει μόνο πλεονεκτήματα -- όχι αποκλειστικά στο τμήμα του προγραμματισμού αλλά σε όλο το οικοσύστημα που δημιουργείται (publishing, deployment, security κλπ κλπ).

 

Ναι όντως μάλλον είναι θέμα "αγκύλωσης" που έχω σε σχέση με το διαμάντι που λέγεται C++.

 

Δεν είμαι σίγουρος αν μπορεί κανείς να χαρακτηρίσει τη C++ "διαμάντι" με αντικειμενικά κριτήρια (σε θεωρητικό επίπεδο πάντα, έτσι? φυσικά και δεν αρνούμαι ότι η c++ έπαιξε τεράστιο ρόλο στην ιστορία του software development).

 

Κατά την άποψή μου δεν είναι τυχαίο πως οι χρήστες της c++ έχουν μικρή ως μηδενική επαφή με ολόκληρα κομμάτια language features (οπότε και καμία ιδέα για το πώς αυτά αλληλεπιδρούν με άλλα language features).

 

Επίσης, μη ξεχνάμε ότι η c++ κουβαλάει τα μπαγκάζια ολόκληρων δεκαετιών backward compatibility και ότι εξελίσσεται με ταχύτητα γεωλογικού μετασχηματισμού (αυτό είναι αναπόφευκτο λόγω του status της).

 

Και τέλος, η c++ δεν είναι object-oriented γλώσσα (παρόλο που φυσικά σου επιτρέπει να γράψεις object-oriented κώδικα).

 

Βάλε όλα αυτά τα θέματα μαζί από τη μία, και από την άλλη βάλε το LINQ στη C# -- κάτι που κατέστη δυνατό ακριβώς επειδή η C# είναι ακόμα νέα και πιο ευέλικτη σα γλώσσα προγραμματισμού. Αν δεν έχεις δοκιμάσει LINQ, δοκίμασε τώρα. Εγώ π.χ. μετά από εκτενή ενασχόληση έφτασα τώρα όταν πρέπει να προγραμματίσω σε άλλη γλώσσα να αισθάνομαι ότι είμαι Ν φορές λιγότερο αποδοτικός.

[migf1]

Γνωρίζει κανείς τους πραγματικούς λόγους για την ολοένα αυξανόμενη "απροθυμία" των εταιριών/προμηθευτών να υποστηρίξουν native development tools;

 

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

[defacer]

αλλά είναι μεγάλη η γκάμα δραστηριοτήτων στην πληροφορική που επωφελείται από το native development

 

Διαφωνώ. Κι αν έχω δίκιο, αυτό εξηγεί τα φαινόμενα που παρατηρείς. ;-)

[migf1]

Διαφωνώ. Κι αν έχω δίκιο, αυτό εξηγεί τα φαινόμενα που παρατηρείς. ;-)

Είχα στο μυαλό μου λίγο πιο αναλυτικές απαντήσεις όταν ρώταγα

 

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

 

Ο βασικός (και κυρίαρχος) λόγος είναι πως στην συντριπτική τους πλειοψηφία τα managed περιβάλλοντα/εργαλεία/κλπ είναι φτιαγμένα με unmanaged code. Αυτό με τη σειρά του νομίζω μας δίνει τουλάχιστον 2 ξεκάθαρα hints για τους λόγους που μια εταιρία δεν θα προτιμούσε να διευκολύνει αντίστοιχη ελευθερία publicly: διευκόλυνση του ανταγωνισμού και έλεγχος του user-base.

 

Απλώς δεν ξέρω κατά πόσο αυτά τα 2 αρκούν ή έστω κατά πόσο ωφελούν ή ζημιώνουν τελικά τον κλάδο.

[geo1st487]

Αν φτιαξεις την ιδια εφαρμογη χρησιμοποιωντας .net με C++, C#, VB, Delphi, ποια απο ολες θα τρεχει γρηγοροτερα και γιατι;

 

Μπορεις με .net να φτιαξεις εφαρμογη που να εκτελειται σε πραγματικο χρονο;

[moukoublen]

Δεν είμαι σίγουρος αν μπορεί κανείς να χαρακτηρίσει τη C++ "διαμάντι" με αντικειμενικά κριτήρια (σε θεωρητικό επίπεδο πάντα, έτσι? φυσικά και δεν αρνούμαι ότι η c++ έπαιξε τεράστιο ρόλο στην ιστορία του software development).

 

Κατά την άποψή μου δεν είναι τυχαίο πως οι χρήστες της c++ έχουν μικρή ως μηδενική επαφή με ολόκληρα κομμάτια language features (οπότε και καμία ιδέα για το πώς αυτά αλληλεπιδρούν με άλλα language features).

 

Επίσης, μη ξεχνάμε ότι η c++ κουβαλάει τα μπαγκάζια ολόκληρων δεκαετιών backward compatibility και ότι εξελίσσεται με ταχύτητα γεωλογικού μετασχηματισμού (αυτό είναι αναπόφευκτο λόγω του status της).

 

Και τέλος, η c++ δεν είναι object-oriented γλώσσα (παρόλο που φυσικά σου επιτρέπει να γράψεις object-oriented κώδικα).

 

Βάλε όλα αυτά τα θέματα μαζί από τη μία, και από την άλλη βάλε το LINQ στη C# -- κάτι που κατέστη δυνατό ακριβώς επειδή η C# είναι ακόμα νέα και πιο ευέλικτη σα γλώσσα προγραμματισμού. Αν δεν έχεις δοκιμάσει LINQ, δοκίμασε τώρα. Εγώ π.χ. μετά από εκτενή ενασχόληση έφτασα τώρα όταν πρέπει να προγραμματίσω σε άλλη γλώσσα να αισθάνομαι ότι είμαι Ν φορές λιγότερο αποδοτικός.

 

Η αλήθεια είναι πως δε θα διαφωνήσω.

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

 

Ναι η C# έχει στοιχεια που και εμενα με έχουν ενθουσιάσει.

Και θα αναφέρω εκτος από το LINQ (το οποιο βρίσκω πολύ πετυχημένη έμπνευση δεν ξέρω αν "κατάγεται" από κάπου αλλου) anonymous functions, lambda expressions κτλ. (Αν και στη C++11 έχουν εισαχθεί).

 

-

 

@geo1st487

Δε νομίζω οτι μπορεί να μετρηθεί έτσι απλά αυτό.

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

 

Ο χρόνος που ανέφερες είναι ένα απο τα ζητήματα που επίσης αν δε ξεκαθαρίσουμε για τι εφαρμογή μιλάμε δεν μπορεί να απαντηθεί το αν έχει σημασία.

 

Το RealTime που αναφέρεις λοιπόν είναι ενα συγκεκριμένο πλαίσιο. Και εκεί ίσως το .net να μην είναι καλή λύση, δε είμαι βέβαιος.

[defacer]

Είχα στο μυαλό μου λίγο πιο αναλυτικές απαντήσεις όταν ρώταγα

 

Το φαντάζομαι, αλλά απάντησα έτσι βάσει προηγούμενης εμπειρίας.

 

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

 

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

 

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

 

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

 

 

 

Εδώ άθελά μου θυμάμαι μια άλλη πρόσφατη κουβέντα, όπου θέλοντας να υποστηρίξω πως δε μπορείς να κάνεις parse command line με regular expression χωρίς να χάσεις τα λογικά σου, είπα "είμαι στη διάθεσή σου να μου δίνεις regular expressions που κάνουν parse command lines και γω να σου βρίσκω παραδείγματα όπου δε δουλεύουν" και η απάντησή σου ήταν "γιατί το λες αυτό?".

 

Όπως καταλαβαίνεις δε γίνεται να περάσουμε στο δια ταύτα αν δε βάλεις στο τραπέζι κάτι πιο συγκεκριμένο από την προσωπική σου άποψη.

 

 

 

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

 

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

 

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

 

Ο βασικός (και κυρίαρχος) λόγος είναι πως στην συντριπτική τους πλειοψηφία τα managed περιβάλλοντα/εργαλεία/κλπ είναι φτιαγμένα με unmanaged code. Αυτό με τη σειρά του νομίζω μας δίνει τουλάχιστον 2 ξεκάθαρα hints για τους λόγους που μια εταιρία δεν θα προτιμούσε να διευκολύνει αντίστοιχη ελευθερία publicly: διευκόλυνση του ανταγωνισμού και έλεγχος του user-base.

 

Απλώς δεν ξέρω κατά πόσο αυτά τα 2 αρκούν ή έστω κατά πόσο ωφελούν ή ζημιώνουν τελικά τον κλάδο.

 

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

 

Λες το 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 και δικηγόροι).

 

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

 

 

Αν φτιαξεις την ιδια εφαρμογη χρησιμοποιωντας .net με C++, C#, VB, Delphi, ποια απο ολες θα τρεχει γρηγοροτερα και γιατι;

 

Μπορεις με .net να φτιαξεις εφαρμογη που να εκτελειται σε πραγματικο χρονο;

 

α) Εξαρτάται από 1002 παράγοντες όπως το τι ακριβώς κάνει η εφαρμογή, το πόσο καλοί είναι οι compilers που εμπλέκονται και φυσικά το πόσο καλό είναι το implementation των άπειρων έτοιμων classes που θα χρησιμοποιήσεις.

 

Αν πιστεύεις ότι native == faster "γιατί έτσι" δεν έχω να προσθέσω τίποτα παραπάνω. Διαφορετικά μπορείς να δεις κάποια άρθρα όπως αυτό εδώ (διάβασε και το conclusion) -- παρόλο που ο άνθρωπος έφαγε δεν ξέρω πόσες μέρες να το κάνει, και παρόλο που το συμπέρασμα συμφωνεί μαζί μου, είμαι ο πρώτος που θα σου πει ότι τέτοιου είδους συνθετικά benchmarks δε σημαίνουν και πολλά όταν μιλάμε για πραγματικές εφαρμογές που είναι idle σχεδόν πάντα.

 

β) Δεν ξέρω, δε δοκίμασα ποτέ. Εσύ έχεις δοκιμάσει να γράψεις real time εφαρμογή σε οποιαδήποτε γλώσσα για να μοιραστείς τα συμπεράσματά σου μαζί μας; Αν όχι, μπορείς να με κατατοπίσεις δίνοντας κάποιο link σε σχετική ανάλυση;

[Directx]

Γνωρίζει κανείς τους πραγματικούς λόγους για την ολοένα αυξανόμενη "απροθυμία" των εταιριών/προμηθευτών να υποστηρίξουν native development tools;

 

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

Δεν νομίζω ότι υπάρχει κάποια απροθυμία, απλά ακολουθούν την τάση κάθε εποχής. Στις αρχές του 1990 η τάση ήταν γενικά το OOP, είχαμε την Borland C++ με την OWL, ύστερα η MS απάντησε με την C++ MFC, μετά ήρθε η εποχή του οπτικού προγραμματισμού με την Visual BASIC, απάντησε η Borland με την Delphi και ύστερα με τον C++ Builder. Στα μέσα των '90s μπήκε δυναμικά στο παιχνίδι και η Java στρέφοντας το ενδιαφέρον στον managed κώδικα, και τελικά η MS απάντησε τόσο στην Borland (οπτικός προγραμματισμός RAD) όσο και στην SUN (VM/managed κώδικας) μέσο του .NET Framework και των γλωσσών του.

 

Υ.Γ.

Εδώ είναι το Singularity ένα πειραματικό Λ. Σ. από την MS γραμμένο σχεδόν εξολοκλήρου σε managed κώδικα (ένα ελάχιστο τμήμα του είναι σε ASM & C).

 

[..]

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

 

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

Υπάρχουν πάντα Obfuscators που όσο να' ναι βοηθούν (δεν είναι πανάκια αλλά βοηθούν) - τώρα αν μιλάμε για κάτι εξαιρετικά πρωτοποριακό πας για Πατέντα και τέλος.

[defacer]

Υπάρχουν πάντα Obfuscators που όσο να' ναι βοηθούν (δεν είναι πανάκια αλλά βοηθούν).

 

Βοηθούν μέχρι το σημείο όπου θα πάρεις crash report από τον πελάτη και θα πρέπει να το κάνεις debug. Απο κει και μετά θα χρειαστεί να βοηθήσει και η Παναγία. (βασικά στην πράξη είσαι αναγκασμένος να χρησιμοποιήσεις και δικό τους crash reporting).

[moukoublen]

Γενικότερα συμφωνώ με την υπέρ-του-managed τοποθέτηση.

 

Οφείλω να πω όμως (αν κατάλαβα καλά, αν όχι sorry) οτι ο migf1 λέγοντας

"τα managed περιβάλλοντα/εργαλεία/κλπ είναι φτιαγμένα με unmanaged code."

εννοούσε το ίδιο το περιβάλλον που "εκτελεί"-"επιβλέπει" (δε μου έρχεται η κατάλληλη λέξη τώρα) τον managed code (πχ CLR ή java runtime enviroment κτλ).

 

Και έχει δίκιο. Αυτά όντως φτιάχνονται native για την κάθε πλατφόρμα.

 

Αυτό όμως δεν λέει κάτι.

 

Δε νομίζω ότι υποστηρίζει κανείς πως το unmanaged θα πρέπει να πάψει συνολικά. Θα ήταν χαζό κάτι τέτοιο. Πάντα θα υπάρχει. Απλά για άλλα πράγματα και σε μικρότερο ίσως βαθμό.

[Directx]

Βοηθούν μέχρι το σημείο όπου θα πάρεις crash report από τον πελάτη και θα πρέπει να το κάνεις debug. Απο κει και μετά θα χρειαστεί να βοηθήσει και η Παναγία. (βασικά στην πράξη είσαι αναγκασμένος να χρησιμοποιήσεις και δικό τους crash reporting).

Ε.. εντάξει.. αλλά οι περισσότεροι (ή πιο σωστά οι καλοί αν θες) προσφέρουν δυνατότητα de-obfuscation των σφαλμάτων της εφαρμογής σου (για τέτοιες περιπτώσεις - ο πελάτης δεν θα καταλάβει τίποτα βέβαια από το κρυπτογραφημένο report..) ενώ παράλληλα σπεύδουν να σε προειδοποιήσουν στην τεκμηρίωση τους για το τι θα πρέπει να προσέξεις όταν τους χρησιμοποιείς και ποία options τους θα πρέπει να ρυθμίσεις και που για να ξεπεράσεις τα όποια προβλήματα (πχ. σπάνια τα καταφέρνουν με Reflection ή ορισμένους getter/setter κλπ).

 

Από το ολότελα όμως ... (μόστρα του κώδικα στον Reflector )

[defacer]

Από το ολότελα όμως ... (μόστρα του κώδικα στον Reflector )

 

Ε ναι Πιο πολύ για την ατάκα/κράξιμο ήταν το σχόλιο

[georgemarios]

Από προσωπική εμπειρία, ο χρόνος που χρειάζεται για το development σε managed γλωσσα είναι ΠΟΛΥ συντομότερος και πιο "στρωτός" απο το να γράφεις σε native. Όποιος έχει νοιωσει τον πόνο του να ψαχνει για βδομαδες γιατι το τεραστιο του προτζεκτ αποφάσισε στο ασχετο να πετάει corrupted stack exceptions μάλλον καταλαβαίνει τι λέω.

Οι μόνοι λόγοι για τους οποίους κάποια εταιρια θα επελεγε να κανει native development οι εξής:

1. Embedded devices. Πάσο, εκέι θα γράψεις στη γλώσσα που υποστηρίζεται απο το OS της συσκευης. Και πάλι όμως, τα desktop εργαλεια που θα διαχειρίζονται/επικοινωνουν με τη συσκευη είναι πολυ πιθανο πως θα γραφτουν σε .ΝΕΤ/java

2. Tons of legacy code. Και εδώ πάλι, είναι πολυ λογικο να κάνεις managed εφαρμογες που απλα χρησιμοποιουν τον legacy κωδικα με marshalling οπου ειναι αυτο εφικτο.

3. Συγκεκριμενες περιπτώσεις που χρειάζεται απόλυτο "ξεζουμισμα" των δυνατοτήτων CPU/GPU. Μιλάμε για εφαρμογές παιχνιδιών / CAD / Virtual Reallity (ισως και άλλες, δε μου ερχεται κατι τωρα). Και εδώ πάλι όμως, το πιθανότερο ειναι η χρηση του native code να περιοριστει στα modules που ασχολουνται με τα συγκεκριμενα σημεία, ενω η υπολοιπη εφαρμογή να είναι managed.

 

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