|
//- VBLIKE 'with' STATEMENT:
That's just pure lazyness. Writing things out long is much more understandable.
//- ALLOW 1 CASE FOR MULTIPLE CONDITIONS USING BOOLEAN OR:
Yees, this could be useful. Although I rarely use cases, but it seems like something that should already be possible... but I may be wrong
//- ADD DEFAULT PARAMATERS:
There is a reason these were left out. It's for version compatibility. You see, the default parameters would have to be compiled into the calling code and then if the parameter's default value changes in the module containing the function, the calling code still uses the old one.
Using multiple overloads that (usually) call the one with most parameters is a good solution.
//- KEYWORDS FOR Inherits, Implements:
And that's because... what? All it would do is make it odd and un-C#-like.
//- 'elseif' KEYWORD INSTEAD OF 'else if':
And that's because... what? I can't think of any reason this would be needed... you can't be too lazy to type that space, can you?
|
|
|
|
|
//- VBLIKE 'with' STATEMENT:
That's just pure lazyness. Writing things out long is much more understandable.
You say 'lazy' I say 'more productive'. There is no shame in wanting to write less code - no different from the principal of the 'using' statement
//- ADD DEFAULT PARAMATERS:
There is a reason these were left out. It's for version compatibility. You see, the default parameters would have to be compiled into the calling code and then if the parameter's default value changes in the module containing the function, the calling code still uses the old one.
Using multiple overloads that (usually) call the one with most parameters is a good solution.
Are you sure - how is this possible in VB.Net then ?
//- KEYWORDS FOR Inherits, Implements:
And that's because... what? All it would do is make it odd and un-C#-like.
No just un-C-like.
//- 'elseif' KEYWORD INSTEAD OF 'else if':
And that's because... what? I can't think of any reason this would be needed... you can't be too lazy to type that space, can you?
See above - isn't C# supposed to be less verbose than VB.net? Again, time to break away from the C heritage and do the right thing.
|
|
|
|
|
>> You say 'lazy' I say 'more productive'. There is no shame in wanting to write less code - no different from the principal of the 'using' statement <<
That code is confusing and unnecessarily complex. It takes very little extra time to just do the job right.
>> Are you sure - how is this possible in VB.Net then ? <<
It's most likely missing because it's missing in Java. I actually do like being able to specify default parameters, but it's hardly vital. Again, it requires very little extra time to add appropriate overloading.
>> No just un-C-like. <<
You're just complaining about style, but there's no fundamental reason that C# should use "Inherits" or "Implements". The functionality is the same, and besides, you were complaining about having to type the extra space in "else if" as opposed to "elseif". Rejoice. The C++ style syntax saves you an extra second. (C has no polymorphism, by the way, so C# is definitely not C-like.)
>> See above - isn't C# supposed to be less verbose than VB.net? Again, time to break away from the C heritage and do the right thing. <<
Less verbose? By adding a new, useless keyword? The else and if keywords already exist. Creating a new one adds nothing new. (And in the original would still exist.)
|
|
|
|
|
|
Thanks Rai,
I have been programming since the last ice age,
on any box that moves around process bits & bytes,
from mainframes to microcontrollers, using
languages like PL1, Cobol, about 5 basic dialects,
several assemblers, Delphi, C, C++, Java, you name
it.
I bought the MS VBNet standard edition an was amazed.
(Basic finally grown up and no longer Basick, )
Being a Borland RAD fan (Borland is probably
the only company that builds really good
RAD's) i also downloaded (for free) their
non commercial version of NET Personal C# builder.
I loaded these RAD's because i wanted to know more
about this NET thing.
Both RAD's are the best Rapid Devlopment Systems i have
ever seen! Excellent,with well designed GUIs' loads
of help and most things made really ease for the
developer.
NET is based upon the virtual machine principle or
at least on a in-between layer, which is more than
just that. So far so good.
So, what more does one want? one could ask..
Well... unfortunately..
There is a very, very big advantage of developing
software with the NET system:
--it's not portable--
That means that anything build in the NET
environment does only run on MSWindow systems.
You are therefore vendor dependent, in this case
Microsoft. So, anything you build in NET needs
practically to be rewritten from scratch when it
needs to run on Macs, Linux, Solaris and other
operating systems. For commercial reasons, perhaps
this is exactly what Microsoft wants, but this
topic is another matter.
What about using a "traditional" language, like C++
in NET then?
Even if i would use NET with C++, the coding
would contain too much NET specific parts to
convert it to other systems. Here also,
rewriting lots of code is necessary.
It would be another matter if the NET layer
was implemented on other operating systems
as well. However, that this will happen is
very unlikely, as NET, being a product owned
by Microsoft, will probably not become available
on those other systems.
to add it all up:
-NET software is not portable:
anything you write in NET runs only under NET
and therefore Windows.
-NET is a OS-dependent system. Now, i don't
think Windows will dissapear, however if i
just were to learn NET, this "specialism"
binds me to the Microsoft world.
-C# is not available on other systems.
-Any server side software build with net
will only run on Microsoft servers. Again,
for commercial reasons, perhaps this is
also exactly what Microsoft wants, but this
topic is another matter.
-it makes the IT world even more dependent
on Microsoft. if you can live with that, it's
ok. but you don't have to:
There are alternatives! Using Java is one of them.
Nearly everything written in Java runs on most
operating systems today, thanks to really good
virtual machines (VM's) that have become better
through the years and are now fast and reliable.
And oh, while your at it, for something
completely different (thanks to Monty Python
for the phrase ) download and wander around
in Squeak Smalltalk. This is really beatiful!
(be careful as you might want to stay in there
have a friend nearby to get you out, even if
that would need to switch of the PC )
Btw, Squeak runs on many OS's, even a Pocketpc.
Smalltalk is truly object oriented, everything
even numbers are objects. As some of the older wizards
and gurus among us know, this is where object oriented
programming came from in the first place!
The object structure existed in Smalltalk since the 80's.
And hey, this was in a time when the PC was not
invented yet and most of us worked with PL1, COBOL
and Fortran.
I first learned about Smalltalk while reading an article about it in the Byte magazine, in 1979 i think it was, and missed my station..
Check it out, the object hierarchy in Smalltalk
was without much alteration nearly mimiced
in C++, Delphi and Java...
Thanks, Ladies and Gentlemen
Whatever you do, have fun
Ted
Recommended links:
http://www.squeak.org
http://www.smalltalk.org
http://www.borland.com
Ted van Gaalen
a dutch IT-er, living and working
in Chur, Switzerland
Joooohhdeeellleeeeeh jooooooooheeeeeee, oops.. sorry.
|
|
|
|
|
Look at Mono[^]. It is an open-source version of .NET, and works on Windows, Linux, and (I think) Mac OS X.
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhi
|
|
|
|
|
Seen it.
It looks very promising
Thanks
Ted
Ted van Gaalen
|
|
|
|
|
Forget Mono.
The Mono group has no input into the specs. And the specs are not properly written down, it's just "Copy whatever Microsoft does, including the bugs" (I know there is supposed to be a standard, but ever read it?). And as Microsoft wildly adds new and often undocumented features, Mono has to try to keep up.
Compare this to Java, which has a fairly open JSR process for developing specs, a clear definition of what the standard actually is, compatibility suites etc.
You may be able to get a reasonable application to run under Mono, and then port it back to .Net. But not the other way.
We chose .Net because our application is very client oriented, and we needed good COM support. But we are under no illusion that we have signed our lives away to Microsoft.
Anthony
PS. That said, I'm very glad that there is a Mono project, who knows with a lot of pain it might be possible to port to it.
|
|
|
|
|
How could you port anything commercial with absence of strong signatures and GAC in MONO???
Your IL assemblies build on Windows will never be able to run on MONO, unless you rebuild them there...
Winform support on LINUX is another very, very questionable thing (no messaging). So, forget about your desktop solutions being movable there -unless you move them in source code... Is it what you want?
"...Ability to type is not enough to become a Programmer. Unless you type in VB. But then again you have to type really fast..."
Me
|
|
|
|
|
It would take more than just source code. I think you would have to make serious changes to the code to get it to run in Mono.
That said, the option to do it might prove very useful if you do later decide that supporting Linux (say) is important.
Mono is doomed in the sense that it will never be like Java -- ie. take an existing .Net ap and automatically run it on Mono.
Don't really understand your Messaging remark -- the basic .Net WinForms interface is pretty generic.
Anthony
|
|
|
|
|
Don't really understand your Messaging remark -- the basic .Net WinForms interface is pretty generic.
Anthony,
What I meant by "Messaging" is that Windows is Messaging based system, while Linux is event based. So, to be able to run any basic Winform Classes (like Form, or Control) MONO should simulate Message passimg to several message processing functions (all functions where Message is used usually by ref, like WndProc, PreProcessMessage and etc). That may require adding huge translation layer between LinuxOS and MONO CLR...
Regards
"...Ability to type is not enough to become a Programmer. Unless you type in VB. But then again you have to type really fast..."
Me
|
|
|
|
|
Did you actually Mono? Assemblies built on MS Windows run just fine on Mono without recompilation just like in Java. Of course, WinForms does not work currently (will change with Mono 1.2). Gtk# is the way to go if you want portability for now.
|
|
|
|
|
I followed the flow, C# seemed the most supported language. As the author points out, the differences are mainly syntactic. But VB has the following syntactic advantages:-
+ Keyword Optional parameters. Come on guys, this is a basic feature of just about every modern language ... except C/C++. Polymorphism is a painful and cryptic alternative.
+ No need to explicitly cast down, ie. no need for
MyType foo = (MyType)MyArrayList[x]
This casting is a pain if you start using more generalized data structures. And contrary to popular belief it adds very little. In C it is important because the runtime does not check and disaster easily results. But with managed code it is just a legacy idea.
+ End * syntax ragher than {}s. {}s are a pain if you get them wrong -- it can be hard to see what a "}" matches in a larger block of code.
+ dim x = new MyDataType(...)
avoids the redundancy of
MyDataType x = new MyDataType(...) // note the redundancy!
(And the Dim is normally redundant
etc.
The advantage of C# is
- unsafe code, if you really need it.
- Case sensitive identifiers, if you think that this is an advantage.
- ???
The pain is that you can NOT mix VB and C# code in the same project. (And if you use internal protection liberally like I do you cannot split the projects. (Java got this right with Package scope.))
It is safe to assume that the basic VB features will NEVER be added to C#, because C# has been designed by C programmers.
So I am stuck with C#, but it was a mistake.
Anthony
(And of course, .Net is just Java in disguise, and Java is just Lisp in disguise, and Lisp got it right 25 years ago.)
|
|
|
|
|
aberglas wrote:
and Java is just Lisp in disguise
|
|
|
|
|
Yes, Java is basically a dumbed down version of Lisp with a C-like syntax. The Java authors, Gossling and in particular Steele were Lisp men. The "Novel" Java technologies such as Generational Garbage Collection, JIT compiling are Lisp technologies. The Lisp object model(s) (CLOS) was much more powerful than Javas only model.
Pitty is that I don't think any of the C# designers knew this, so they just copied Java without adding any of the Lisp stuff back.
Anthony
|
|
|
|
|
Dear Aberglas:
My, My! What views! I truly loved reading your comments.
The only point I think contrary to you is language interaction.
You can have use VB.NET and C# in a single solution. All you have to do is to make all your classes based on VB.NET in one project and C# based classes in another.
Under the same ‘namespace’ the classes would love to interact and play together as siblings of the same family.
You said you made a mistake when you choose C#? I find it really interesting and would like to know what makes you think that way?
, Happy Coding.
Rai Umair
What is now proved, was once only imagened...
|
|
|
|
|
Yes you can mix these in one SOLUTION, but not in one PROJECT.
This is a problem because Internal scoped variables are only visible in one Project, as far as I am aware.
See opening post for advantages of VB of C#. But we should not need to choose.
Anthony
|
|
|
|
|
Why would you ever want to mix languages within a project? You might as well be mixing them in the same file.
|
|
|
|
|
aberglas wrote:
+ Optional parameters. Come on guys, this is a basic feature of just about every modern language ... except C/C++. Polymorphism is a painful and cryptic alternative.
There is a reason these were left out. It's for version compatibility. You see, the default parameters would have to be compiled into the calling code and then if the parameter's default value changes in the module containing the function, the calling code still uses the old one.
Using multiple overloads that (usually) call the one with most parameters is a good solution.
aberglas wrote:
+ No need to explicitly cast down, ie. no need for
MyType foo = (MyType)MyArrayList[x]
This casting is a pain if you start using more generalized data structures. And contrary to popular belief it adds very little. In C it is important because the runtime does not check and disaster easily results. But with managed code it is just a legacy idea.
Yea, it can be a bit annoying. I can't see why the compiler can't check for the validity of the conversion and just report an error if it is invalid... hmm or maybe...
aberglas wrote:
+ End * syntax ragher than {}s. {}s are a pain if you get them wrong -- it can be hard to see what a "}" matches in a larger block of code.
Well this is purely a matter of style, some like things different. I totally hate End *, but I guess you like it. Maybe someone can do a VS.Net plugin for turning the Ends into {}s automatically on build?
aberglas wrote:
+ dim x = new MyDataType(...)
avoids the redundancy of
MyDataType x = new MyDataType(...) // note the redundancy!
(And the Dim is normally redundant
Nono, that is bad.
dim x = 3; // What data type is this?
And of course assuming that pointers will only be used for the types that they are is bad also.
What if you want to make an interface pointer?
|
|
|
|
|
Locked Ghost wrote:
+ Optional parameters. Come on guys, this is a basic feature of just about every modern language ... except C/C++. Polymorphism is a painful and cryptic alternative.
There is a reason these were left out. It's for version compatibility. You see, the default parameters would have to be compiled into the calling code and then if the parameter's default value changes in the module containing the function, the calling code still uses the old one.
Using multiple overloads that (usually) call the one with most parameters is a good solution.
This is oft stated but wrong. There is absolutely no need for the default parameters to be compiled into the calling code. One easy way is to just retrieve the default values from defining class. And the JIT compiler can then optimize this away where appropriate. (What the C++ people miss is that the JIT works at run time, so it knows what the optional parameter values really are.)
Locked Ghost wrote:
Nono, that is bad.
dim x = 3; // What data type is this?
Integer, obviously. C++/Java/C# relies on the exact types of constants for expression evaluation, eg.
long lng = 1000000 * 1000000; // Bug!
(One of the few advantages of .Net over Java is that at least the above error will be trapped, iff you enable integer overflow detection (very cheap).)
But really, fixed precission arithmetic is a legacy idea most of the time. Lisp got this right -- the default is indefinite preciession, implemented very efficiently using the fixnum trick.
It seems like the legacy of bad ideas from C/C++ will outlive the languages. Eg. will comments ever nest (/*../*..*/..*/)?
|
|
|
|
|
I am sorry to hear of your displeasure with C# and a preference for VB. I'm a long-time VB guy and I initially objected when my company chose C# over VB when we began to study .NET. After a short time, to my amazement, I was quickly converted and have never looked back.
To comment on your comments:
+ Optional parameters.
Good in VB6 where there was no overloading, but now is just a lazy alternative to overloads. The parameters for a method indicate what's required. If it isn't required there shouldn't be a parameter. This creates confusion about how to properly call the method.
+ No need to explicitly cast down ...
Strongly typed languages are a Godsend. Numerous times have I seen bugs due to incorrect typing. Frankly, I want to know what types I'm working with, not what the runtime can figure out (implicit type casting). Dan Appleman talks/rants at length on this one aspect). Also, the compiler can enforce typing. I think it was a mistake for MS to have Option Strict Off by default.
+ End * syntax ragher than {}s.
Purely preference. I love the clean syntax of C#. The verbosity of VB annoys me to no end.
To add a real difference between the two languages, I'v found two technical areas that cannot be achieved with VB:
1. Operator Overloads - True many won't use this, but I did in implementing a custom structure in a recent app.
2. Adding NonSerializedAttribute to public events - Because of the syntax of VB surrounding events, the NonSerializedAttribute cannot be applied to a public event delegate. This is a critical problem when an instance of the class is serialized because the CLR tries to serialize the entire object graph, including any other classes that have delegates linked to the public event. If any object in the graph is not serializable, a SerializationException will be thrown.
The second point is the real clincher for me. I'm through with getting backed into technical corners because of shortfalls in a platform. I feel totally betrayed by classic VB and the way it was supposed to hide the technical details of Windows programming, only to find that even moderately sophisticated UIs required knowledge and useage of the Win32 API.
I appreciate your comments and enjoy the lively discussion that your article generated.
Good luck!
|
|
|
|
|
>... because C# has been designed by C
IIRC, C# was designed by the creator of DELPHI. This becomes obvious if you work with both languages.
|
|
|
|
|
>> + Optional parameters. Come on guys, this is a basic feature of just about every modern language ... except C/C++. Polymorphism is a painful and cryptic alternative. <<
Actually, C++ allows default parameters. And operator overloading has very bupkis to do with polymorphism. But operator overloading is clearer, for certain. It decreasesbugs on both ends when done properly.
>> + No need to explicitly cast down, ie. no need for
MyType foo = (MyType)MyArrayList[x]
This casting is a pain if you start using more generalized data structures. And contrary to popular belief it adds very little. In C it is important because the runtime does not check and disaster easily results. But with managed code it is just a legacy idea. <<
Strongly typed languages should not allow such trash. (And weakly typed languages are trash.)
>> + End * syntax ragher than {}s. {}s are a pain if you get them wrong -- it can be hard to see what a "}" matches in a larger block of code. <<
Meh. You need glasses if you can't see the '}'.
>> + dim x = new MyDataType(...)
avoids the redundancy of
MyDataType x = new MyDataType(...) // note the redundancy!
(And the Dim is normally redundant <<
Also trash.
|
|
|
|
|
I started into .Net (from Vb6) with VB.net but, have since found C# a much better development language for a lot of reasons. But I really do miss:
- optional parameters - sometimes much easier than overloaded functions
- the 'with' keyword
- VB's 'Select Case' - easier to work with then 'switch'
and in VS.net 2003:
- function divider bars in the editor window
and VS.net Whidbey:
- edit and continue
Will choosing C# over VB.NET or VB.NET over C# always be a compromise?
|
|
|
|
|
Dear Anonymous and ALL Developers:
It sure is difficult to unlearn one language and get steady with another. But look on the brighter side you have already managed to do so.
In VB.NET optional parameters are a definite plus... But you can also have optional parameters in C# methods using what is collectively called a “parameter-array”.
A parameter-array consists of an optional set of attributes, a params modifier, an array-type, and an identifier. A parameter array declares a single parameter of the given array type with the given name.
Read more about it on MSDN: "10.5.1 Method parameters"
This also supports the claim that languages have differences in syntax alone and a few in the IL too. (I say IL as it’s no longer a Microsoft only implementation).
The 'with' and 'select' syntax are respectively not used much or are actually not considered as good programming and therefore were ignored and not adopted in the design of C#. On the brighter side C# switch is much neater and allows mulitlpe fallthroughs.
INTERESTING FIND
Here’s an interesting find (I found this in one of my endless coding sessions) I am sure most of you might already be familiar with it but fot those who are not here it is.
Did you know... that C# and VB.NET have tons of things different at IDE level also. Let alone the syntax.
For example Visual Basic .NET IntelliSense feature will not show the Region or the ClientRectangle members of the Windows form. C# IntelliSense, on the other hand, exposes these members as expected.
This behavior can be taken care of by simply changing your options. To do this, select Options from Visual Studio's Tools menu, and then open the Text Editor item. Select All Languages (or just Basic if you want to limit the effects to VB.NET) and uncheck the "Hide advanced members" checkbox. Click OK to close the Options dialog. The change takes effect immediately.
Thank you for pointing to these issues.
, Happy Coding.
Rai Umair
What is now proved, was once only imagened...
|
|
|
|
|