 |
 | Don't Cut and Paste from Books.Write articles on your own
rp_chicago | 11:44 28 Jun '07 |
|
|
Most of this article is just a copy of CLR VIA C# books by Jeffrey Richter. If you copy from the books atleast list your source.
|
|
|
|
|
| Db2 connection??
trk_wakil | 6:09 19 Apr '05 |
|
|
Hi all, I am still searching for a solution to this problem of mine. It is probably a very simple one!
how do I open the connection to a Db2 database stored on an IBM server???
a database on my machine is easily done, but I would very much appreciate it if anyone has a sample source code for connecting to an IBM database.
Thanks all
E.T.
|
|
|
|
|
| This article is a -1 Troll
Foo _ Bar | 12:49 1 Aug '03 |
|
|
The whole purpose of this article appears to be to start a huge flame war on codeproject. And, apparently, it worked.
|
|
|
|
|
| Well Said!
Rai Umair | 5:42 24 Jul '03 |
|
|
Heres something interesting, that I was able to nab from Sam Gentile's Blog http://samgentile.com/blog/Story/1989.aspx[^] Don't forget to read the whole thing there.
Now, here's the drill. Forget about learning C#. Forget about learning VB.NET. Learn about the CLR and the BCL FIRST. That's the real .NET. The languages are just synatatic sugar. If you want 60% more verbosity, choose VB.NET. If you want the current media darling, choose C#. And if you're a real man (or woman) choose Managed C++-)). Only kidding. C# is a fine langauge. But for gosh sakes, its not whats important. As John Lam in his excellent BLOG on this topic: "Here's some C# resources. The reason why this is a brief list is that I honestly don't read C# books either. There's not enough complexity in this language to warrant reading a book on the language itself. All of your questions can be answered by judicious reading of the C# language spec." Its not that complex a language. Its the System Libraries (the BCL) and the CLR that are important. Learn them, learn how and why .NET is doing the things its doing. Then you won't have to ask those kind of questions and you will really understand what's going on.
Very well said indeed...
 , Happy Coding.
Rai Umair
What is now proved, was once only imagened...
|
|
|
|
|
| .NET Language Survey Results
Rai Umair | 4:32 24 Jul '03 |
|
|
What .NET Language are you using?
Total users voted 4895
C++.NET 3% - 175 Users
C#.NET 47% - 2323 Users
VB.NET 44% - 2158 Users
Jscript.NET 0% - 42 Users
J#.NET 0% - 35 Users
Perl.NET 0% - 34 Users
Cobol.NET 0% - 39 Users
Other 1% - 89 Users
Results taken from a survery at:
http://www.dnzone.com/showDetail.asp?TypeId=11&NewsId=138&ShowVotes=true[^]
, Happy Coding.
Rai Umair
What is now proved, was once only imagened...
|
|
|
|
|
| Only Cosmetic?
AlexH | 3:12 24 Jul '03 |
|
|
Your basic premise that the only difference between .NET languages is "cosmetic" is wrong.
J# for example lets one write against Microsoft's implementation of the JDK 1.1.4 libraries as well as the .NET FCL.
C# supports unsafe code unlike VB.NET or JScript.NET.
Managed C++ uniquely supports both IL and native compilation.
Both VB.NET and JScript.NET support typeless programming through late binding, unlike J#, C# or MC++.
For example, try writing the polymorphic code at http://weblogs.asp.net/ahoffman/posts/9924.aspx[^] in C# or J#?
|
|
|
|
|
|
|
Dear Alex Hoffman:
Very enlightening comments and quite true also.
But I entreat to distinguish that my premise is not mistaken as such.
Although I admit that .NET languages don’t have equal loads of features. But believe me I have not come across any situation where a built-in feature in one language could not be replicated (solved) by a custom feature in another language. Lastly the article relates to the managed thingy only and if you want to go for unsafe code JDK 1.1 like exotic stuff there is always a option of language interoperability.
I have been profoundly doing research on this topic and have found really surprising results and I will be updating the article with all the information I have collected, researched and learnt by experiment in a week from now.
Come back soon, as I consider the update will lay your doubts to rest.
Another thing, I read your blog and I was not able to clearly understand the topic at hand. Please if you could elaborate it in your next post.
Thank You for your opinion.
, Happy Coding.
Rai Umair
What is now proved, was once only imagened...
|
|
|
|
|
| C 'Sharper'
Anonymous | 8:40 21 Jul '03 |
|
|
Here's what C# is missing:
//- VBLIKE 'with' STATEMENT:
with oObject{
.Property1 = "value1";
.Property2 = "value2";
.CallMethod1();
}
//- ALLOW 1 CASE FOR MULTIPLE CONDITIONS USING BOOLEAN OR:
switch(myEnum){
case myEnum.Value1 | myEnum.Value2:
DoSomething();
break;
case myEnum.Value3:
DoSomethingElse();
break;
}
//- ADD DEFAULT PARAMATERS:
private void DoSomething(string myParam="My Default Value"){}
//- KEYWORDS FOR Inherits, Implements:
class myObject:inherits BaseClass,implements Iinterface{}
//- 'elseif' KEYWORD INSTEAD OF 'else if':
if(something){}
elseif{}
|
|
|
|
|
|
|
//- 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.)
|
|
|
|
|
|
|
|
| Is NET NEAT? What's the catch?
ted van gaalen | 13:00 17 Jul '03 |
|
|
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.
|
|
|
|
|
| My mistake was to use C#
aberglas | 9:38 17 Jul '03 |
|
|
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
|
|
|
|
|
