Διαβάστε μια ενδιαφέρουσα άποψη για τις διαφορές C# και VB.NET με τίτλο "VB.Net ruined my day: Part 1". Συνοπτικά, ο αρθρογράφος ανακαλύπτει ότι όταν κάνεις cast ένα double σε int η VB.Net τον στρογγυλοποιεί στον πλησιέστερο ζυγό αριθμό. Η κατάληξή του (με την οποία συμφωνώ μόνο στο 50%): "Like all strange VBisms, this one has a historical reason for existing. It's because historically VB was created by a bunch of drunken monkeys."

Κάποτε πίστευα κι εγώ ότι δεν υπάρχει σημαντική διαφορά μεταξύ C# και VB.Net. Έχω αρχίσει να αλλάζω γνώμη και οι λόγοι δεν έχουν άμεση σχέση με τη γλώσσα. Ναι, κάτι περίεργα σαν τη στρογγυλοποίηση ή το Option Explicit έχουν σχέση, αλλά υπάρχουν για ιστορικούς λόγους. Δυστυχώς, όλο και κάποιος επιμένει να έχει το Option Explicit Off ή κάποια στιγμή ξεχνάς την περίεργη συμπεριφορά του cast και μετά ψάχνεσαι και δεν φτάνεις ...

Υπάρχει όμως και άλλοι, σοβαρότεροι λόγοι.
    Πρώτον, τα εργαλεία και addins, κυρίως τα open-source, φτιάχνονται σε C#. Αλλά και εμπορικά όπως το Resharper, φτιάχνονται σε C# ενώ είναι δύσκολο να φτιαχτούν για VB.Net, κυρίως λόγω των "παραδοσιακών δυστροπιών" της γλώσσας. Από την άλλη, μπορούν να χρησιμοποιηθούν οι αλγόριθμοι που φτιάχτηκαν για C++ ή Java για code metrics, refactoring, beautifying κλπ με ελάχιστες αλλαγές.
    Δεύτερον, οι ενδιαφέρουσες εξελίξεις γίνονται σχεδόν όλες στη C#! Generics, Cω, aspects, αλλά και ports από τη Java όπως το nHibernate και το nSpring.

Λοιπόν, ως τώρα δεν είχα λόγους να επιλέξω τη VB.Net. Σίγά-σιγά όμως αρχίζω να αποκτώ λόγους να την αποφύγω ...

---

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

Νομίζω ότι τα πράγματα περιγράφονται τραγικά...

Για μένα που είμαι VB προγραμματιστής η χρήση του CInt() και του Int() δεν είναι ταυτόσημη και δεν πρόκεται να εξισωθεί. Οχι, ότι η VB δεν έχει 2 συναρτήσεις που κάνουν την ίδια δουλειά με άλλα ονόματα... Αλλά το CInt() κάνει μετατροπή σε ακέραιο και νομίζω ότι σωστά κάνει το 1,5 σε 2 και το Int() τραβάει το ακέραιο μέρος από το 1,8 το 1.

Οσο για το Option Expicit δεν κάταλαβαίνω την διαφωνία! H BASIC σαν γλώσσα δεν έχει την απαίτηση να δηλώνονται οι μεταβλητές. Δημιουργούνται την πρώτη φορά που καλείς το όνομά τους. Αυτό το feel έχει μεταφερθεί στην VB1, VB2, ..., VB6 και VBScript δεν μπορώ να καταλάβω το λόγο που πρέπει να αλλάξει στην VB.NET. Γιατί για να γίνει πιο κατανοητή στους C++/Java προερχόμενους προγραμματιστές; Για να μην ξεχνάνε να το γράφουν ή να το ενεργοποιήσουν;

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

 
Dim dNumber As Double
Dim iNumber As Integer
dNumber = CDbl(nudRoundNumber.Text)
iNumber = CInt(dNumber)
txtNumber.Text = iNumber.ToString()
 

George J.

---

George J. Capnias: Χειροπρακτικός Υπολογιστών, Ύψιστος Γκουράρχης της Κουμπουτερολογίας w: capnias.org, t: @gcapnias, l: gr.linkedin.com/in/gcapnias

pkanavos wrote:

Συνοπτικά, ο αρθρογράφος ανακαλύπτει ότι όταν κάνεις cast ένα double σε int η VB.Net τον στρογγυλοποιεί στον πλησιέστερο ζυγό αριθμό.

Το θέμα του rounding μπερδεύει πολύ κόσμο εδώ και καιρό.  Κατ' αρχήν, θέλω να ξεκαθαρίσω ότι αν ο τύπος ήθελε να είναι σωστός, θα έπρεπε αντί για την Cint να χρησιμοποιεί την Math.Round, ή την Convert.ToIntXX.  Αυτός είναι ο σωστός τρόπος στο .NET - όλα τα άλλα είναι για το (δυστυχώς απαραίτητο) backward compatibility.

Τώρα, όσο για το rounding στον πλησιέστερο ζυγό, αυτό ακριβώς κάνει και η Math.Round, την οποία όλως τυχαίως χρησιμοποιεί και η C# αλλά και όλες οι γλώσσες που κάνουν target το CLR.  Ο λόγος είναι απλός:  έχουμε αποφασίσει ότι όλα τα .5 νούμερα (το 1.5, το 2.5, κλπ) θα τα στρογγυλοποιούμε πάντα προς τα πάνω, παρόλο που η απόσταση του 1.5 από το 1 και το 2 είναι ίση.  Με ποια λογική λοιπόν τα στρογγυλοποιούμε όλα προς τα πάνω?  Και τι θα γίνει αν όλα αυτά τα στρογγυλοποιημένα νούμερα τα αθροίσεις?

Εδώ θα βρείτε πληροφορίες για τις διάφορες μεθόδους rounding.  Αυτό που κάνει η VB και το .NET Framework λέγεται "Banker's Rounding" και είναι και IEEE Standard (Παναγιώτη).

---

Patrick

Χίχι. Με αυτό τον τρόπο αποκάλυψες την ηλικία σου. Πόσος κόσμος κάτω από τα 30 θυμάται ότι η VB έκανε το rounding με αυτό τον τρόπο επειδή κάποτε η Microsoft ήθελε να την προωθήσει στον επιχειρηματικό κόσμο? Γιατί οπουδήποτε αλλού το round απαιτείται να είναι συγκεκριμμένο, ή πάνω ή κάτω. Φαντάσου να συμπεριφερόταν έτσι ένας αλγόριθμος MP3 ... 

Το πρόβλημα του τύπου ήταν ότι ήθελε να κάνει cast σε Int, όχι round. Και η VB δεν έχει κάποιο τρόπο να κάνεις cast χωρίς round, τουλάχιστον χωρίς να καταφύγεις στο Framework και την Convert. Και το CType και το CInt καλούν πρώτα την Round και μετά κάνουν cast σε Integer. Πέρα από το αναπάντεχο αποτέλεσμα, αυτή η συμπεριφορά σημαίναι ότι καλείται ένα παραπανίσιο function σε κάθε cast, κάτι που μπορεί να έχει επίπτωση όταν μετατρέπονται πολλοί αριθμοί, π.χ. ένας πίνακας με doubles.
 
  Αυτό είναι ένα από τα πιο αθώα παραδείγματα για το πως η VB παραβαίνει το principle of least surprise. Είναι μάλιστα τόσο παλιό που θα στοιχημάτιζα ότι ο αρθρογράφος έχει πολύ καιρό να δουλέψει με VB.

Η C# πάντως δεν χρησιμοποιεί τη round όταν κάνεις cast. Ο IL κώδικας για τον παρακάτω κώδικα:

public static void Main()
 {
  double fi=1.5;
  int i=(int)fi;
 } 

είναι:

.method public hidebysig static void Main() cil managed { .entrypoint    // Code Size: 14 byte(s)    .maxstack 1    .locals ( float64 num1, int32 num2)    L_0000: ldc.r8 1,5    L_0009: stloc.0    L_000a: ldloc.0    L_000b: conv.i4    L_000c: stloc.1    L_000d: ret } Προφανώς, η C# κάνει κανονικό cast, ενώ η VB πρώτα καλεί την Round και μετά κάνει cast: .method public static void Main() cil managed {    .custom instance void [mscorlib]System.STAThreadAttribute::.ctor()    .entrypoint    // Code Size: 21 byte(s)    .maxstack 1    .locals ( float64 num1, int32 num2)    L_0000: nop    L_0001: ldc.r8 1,5    L_000a: stloc.0    L_000b: ldloc.0    L_000c: call float64 [mscorlib]System.Math::Round(float64)    L_0011: conv.ovf.i4    L_0012: stloc.1    L_0013: nop    L_0014: ret }

---

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

Σωστά - η VB είναι αναγκασμένη να το κάνει αυτό για να μπορέσει να κρατήσει το compatibility.  Η C£ (χμ, το laptop της γυναίκας μου δεν έχει κάγκελο!) δεν έχει τέτοια θέματα!  Δεν μπορούμε να τα έχουμε όλα δικά μας.  Συμφωνώ ότι η VB έχει διάφορα τέτοια, και γι αυτό το λόγο είναι και δίκοπο μαχαίρι για τους δήθεν developers που κυκλοφορούν:  Μπορούν με ελάχιστες γνώσεις να βγάλουν κάτι που να μοιάζει με πρόγραμμα, αλλά αν αρχίσουν να έχουν προβλήματα, αρχίζουν να πιστεύουν ότι η VB κάνει ό,τι θέλει!

---

Patrick

Το οτι η C# υποστηρίζει - έστω και οριακά - pointers είναι από τα πιο σημαντικά εργαλεία που δίνει στον developer σε σχέση με την VB.NET κατά την γνώμη μου. Προσωπικά αυτό μου έχει λύσει σοβαρά προβλήματα που είχα προσπαθώντας να  καλέσω συναρτήσεις από C functions (από ένα παλιό dll). Θεωρώ το ζήτημα του cast δευτερεύον και πιστέυω οτι ο παλιός VB προγραμματιστής το γνωρίζει σαν πρόβλημα/θέμα. Το option explicit ποτέ δεν κατάλαβα γιατί είναι καλό για μία γλώσσα...
Η σύνταξή της είναι σπαρτιατική αλλά προτιμώ το "}" από το "End if". Αυτό βέβαια είναι θέμα συνήθειας και γούστου. Φαντάζομαι οτι δεν τίθεται θέμα για διαφορά ταχύτητας (από όσα λέει η Microsoft τουλάχιστον).

PS: ... και είμαι υποχρεωμένος να την χρησιμοποιώ καθημερινά....

Ένα ενδιαφέρον άρθρο σχετικά με αυτό το θέμα μπορείτε να διαβάσετε στο Blog του Darell http://codebetter.com/blogs/darrell.norton/archive/2003/07/07/382.aspx πάντως μετά απο ένα χρόνο στο .ΝΕΤ (ερασιτέχνικά) πιστεύω πως το πλήρη έλεγχο τον έχει κάποιος χρησιμοποιώντας C++ και managed extensions για .NET. Απο μία κουβέντα που είχα με έναν απο το Redmond μου είπε πώς ο C++ του Studio2005 δίνει αρκετά καλούδια για όσους επιθυμούν να προγραμματίσουν σε ένα τέτοιο επίπεδο (πολύ λίγοι ...)

Τα Generics υποστηρίζονται από το .NET Framework 2 και όχι από την C#, οπότε είναι προσβάσιμα και από την VB.NET.

---

Dimitris Papadimitriou Software Development Professional

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Διαβάστε επίσης τους όρους χρήσης.

Παίδες ίσως πικράνω μερικούς, αλλά μεταξύ C# και VB.NET η απάντηση είναι αβλεπεί C#.

Το κείμενο που έχω επισυνάψει εξηγεί τους λόγους. Είναι από το Gartner Symposium του 2003, και δεν ασχολείται με pointers και τεχνικά φρου-φρου κι αρώματα, αλλά με την business πλευρά του ζητήματος.
Συνοπτικά λέει τα εξής:

1. Το πέρασμα ενός προγραμματιστή VB6 σε VB.NET κοστίζει 9 ανθρωπομήνες, ενώ σε C# 10 ανθρωπομήνες. Τουτέστιν το ότι είναι πιο εύκολο ένας VB προγραμματιστής να περάσει σε VB.NET αντί για C# είναι ΜΥΘΟΣ.
2. Μέχρι το 2007 τα μερίδια των γλωσσών προγραμματισμού .ΝΕΤ θα είναι 55% για τη C#, 30% VB.NET, 10% C++ και 5% τα υπόλοιπα, και η τάση θα είναι αυξητική για τη C# και μειωτική για τη VB.NET.
   Αυτό σε απλά ελληνικά σημαίνει ότι στην αγορά θα υπάρχει "διαθέσιμη" τεχνογνωσία C#, δηλαδή θα βρίσκεις προγραμματιστές C# πολύ πιο εύκολα από προγραμματιστές VB.NET. Επιπλέον οι προγραμματιστές C# θα έχουν και καλύτερο επίπεδο.

Λέει και άλλα ενδιαφέροντα βέβαια.

Πέρσυ που είχα πάει στην TechEd στο Άμστερνταμ, είχα παρακολουθήσει μια παρουσίαση του Program Manager της Visual C++ 8.0 (ο τύπος ήταν άπαικτος!). Εν ολίγοις είπε ότι η Microsoft έφαγε πολύ "ξύλο" (για να το θέσω διπλωματικά) από τους μεγάλους ISVs οι οποίοι είχαν επενδύσει πολύ σε C++ και είχαν σοβαρότατο πρόβλημα με την υποστήριξη C++ που έδινε το VS.NET 2003.

Έτσι η M$ αποφάσισε να κάνει την C++ την "preferred" γλώσσα ανάπτυξης σε .ΝΕΤ.

Σύμφωνα με τον τύπο αυτόν, η C++ 8.0 θα παράγει κώδικα IL περίπου 30% πιο γρήγορο από τον αντίστοιχο κώδικα C#, εξαιτίας του ότι θα υποστηρίζει Unmanaged CLR C++ classes, δηλαδή κλάσεις που είναι μεν κώδικας IL αλλά οι οποίες δεν παίζουν με τον Garbage Collector, αλλά με τα κλασσικά C++ runtime libraries.

Have Fun!

---

The fact that the program works is irrelevant.

Χρήσιμα τα στοιχεία αυτά Δημήτρη. Δεν μας λεει όμως (η τουλάχιστον δεν πρόσεξα) πόσο χρόνο θέλει ένας VB.NET developer για να περάσει σε C#. Πραγμα ενδιαφέρον για μένα προσωπικά μια και *ειμαι* VB.NET....

---

Σωτήρης Φιλιππίδης

DotSee Web Services

Κοίτα καλύτερα, το λέει. 3 μήνες.

---

The fact that the program works is irrelevant.

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

---

Σωτήρης Φιλιππίδης

DotSee Web Services

Δεν είναι μεγάλο διάστημα οι 3 μήνες. Μάλιστα αν κοιτάξεις και το legend με τα χρωματάκια, τρεις μήνες είναι ο απαιτούμενος χρόνος για να γίνεις Proficient στη C#. Παραγωγικός είσαι από την πρώτη ημέρα, δεδομένου ότι έχεις ένα καλό background σε .ΝΕΤ.

Αυτό που λες για τις εκ των προτέρων προσεκτικές αποφάσεις είναι απόλυτα σωστό, και ισχύει τόσο σε επίπεδο μεμονωμένων developers όσο και σε επίπεδο εταιριών. Δηλαδή το να ανοίξει κάποιος μια εταιρία software και να επιλέξει σαν γλώσσα ανάπτυξης την VB.NET, κατά τη γνώμη μου είναι σοβαρό ατόπημα και δείχνει έλλειψη στοιχειώδους μελέτης σχετικά με το πώς κινείται η βιομηχανία.

Αντιγράφω από το Gartner:

The preference of C# will not be driven by technical merits of one language over the other, but rather by significant political and cultural bias against the older VB product line. In particular, C# will have a dominant market share with departmental and larger-scope projects, while VB.NET will dominate the lower-end workgroup-scale projects.

Αν λοιπόν θέλεις να κινείσαι σε workgroup-scale projects, γράφε σε VB.NET, στο καλό και με την ευχή μου!

Αν όμως θέλεις να φτιάξεις ERP και γράφεις σε VB.NET, τότε το μόνο που έχω να πω είναι "Δεν ήξερες, δε ρώταγες;".

---

The fact that the program works is irrelevant.

BruteForce wrote:

Αντιγράφω από το Gartner: The preference of C# will not be driven by technical merits of one language over the other, but rather by significant political and cultural bias against the older VB product line. In particular, C# will have a dominant market share with departmental and larger-scope projects, while VB.NET will dominate the lower-end workgroup-scale projects.

I couldn't agree more...

Εξορισμού παλικάρια η VB.NET περιέχει συμβιβασμούς. Όταν ήταν καιρός να πάει κανείς σε .net καλά θα έκανε να πήγαινε κατευθείαν σε  C#. Τώρα που όσοι ήταν να γυρίσουν σε .net γύρισαν, καλό θα είναι όποιος θέλει να το ψάξει λίγο παραπάνω να αρχίσει να προσαρμόζεται στην C# αν δεν το κάνει ήδη.

Έχω βαρεθεί τις ατέλειωτες συζητήσεις για το πια γλώσσα είναι καλύτερη. Καμία δεν είναι καλύτερη. Όμως η μια φιτάχτηκε για το .net ενώ η άλλη προσαρμόστηκε στο .net. Και κατά την αποψή μου κιόλας (κα συμφωνώ και σε αυτό με τον Στάικο) οι καλύτεροι μιλάνε C#. Όσοι είστε από τους καλύτερους και δεν μιλάτε C#, ξεπεράστε το! Θα σας πάρει πολύ λιγότερο από τρείς μήνες.Στο κάτω κάτω θα είστε πολύ πιο ευέλικτοι από κάτι τύπους σαν κι εμένα που αποφεύγουν την VB.NET.

Think about it...

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

φιλικά
rousso

υ/γ: Και που είστε παλικάρια... Μην αρπαχτείτε από τα γραφόμενά μου κι αρχίσετε τις παρεξηγήσεις... Δεν έχω τίποτα με τους VB.NET developers, ούτε με την VB.NET. Με το κόλημα στην VB.NET είναι που δεν τα πάω καλά...

 

---

rousso

Δεν έχω δουλέψει πολύ με VB.NET αλλά από όσο γνωρίζω η Microsoft υποστηρίζει περισσότερο την C#