All DotNet Languages Are Equal?

Status
Not open for further replies.
Joe Mamma said:
Still, my advice to new programmers is don't build a dependence on VB. Learn to program with a robust language.
Click to expand...

I absolutely agree. The same goes for any language, not just VB. God forbid a new programmer builds a dependence on Pascal syntax and Delphi objects rather than learning language-neutral programming concepts.

You seem to be arguing against a point I never made. So far I have only taken issue with your generalisations about "vb programmers" and their skills. You throw out comments like "VB'ers need not apply", "A VBer only knows how to enable and disable menu items" and "learn to program!!!". You have yet to clarify what makes a "VB'er", but if you're talking about a programmer who knows VB (as would be the logical assumption) then your statements are wildly inaccurate.

I'm sure I don't need to remind anyone here that the most pointless arguments of all are the "my language is better than yours" arguments. They further nobody. Remember that how useful a language is goes beyond what features it does or doesn't have, to how appropriate it is for development in the workplace (the same applies for hobbyists only less so).
 
PlausiblyDamp said:
However in a show of goodwill have you looked here in this forum's code library for an example of how to use aspx pages and templates?
Click to expand...

Thanks, haven't looked at it, but from looking at the topic text, I think thats it!!!

joe- ma-mooie
 
PlausiblyDamp said:
However in a show of goodwill have you looked here in this forum's code library for an example of how to use aspx pages and templates?
Click to expand...


hrmmmm. . . thats close,
only that leaves the templated objects only visible at browse time.

I will post to that forum and see if he has any ideas, thanks.

joe
 
Ok, Joe Mamma. Stop blaming vb. If you still think that delphi is better, then **Prove it**, writing the most advance delphi code, and post it here, right here. Please write a complete thing, not a function, not a few lines of code, not a feature, not a junk, or whatever. In addition, post a note when you start wring the code, in order to compare the time consuming of delphi.

Let's see if vb developers can write better that or not.
 
Visual Basic can produce powerful, excellent code, or it can produce crap. It's the programmer, not the language, that determines the quality of the final product. Making wide generalizations and biases against Visual Basic programmers will do nothing but aggrivate people. Some of the best programmers I know are Visual Basic programmers.

I think this thread is getting dangerous... :)
Click to expand...
I agree, and I will be keeping an eye on the thread.
 
Time to get in my $.02. I'm just now moving from VB6 to VB.Net. I won't get on about Delphi because I know less than nothing on the subject. But, VB I can comment on. If you want to diss the most popular programming language for the Windows OS, go right ahead. Also, I wouldn't say that VB lacks as much as it does.

While it is true that VB.Net does lack in comparison to C# in certain areas, it doesn't mean that the entire language and all the people that code and use it should be sentenced to death... VB.Net, and its predecessors (VB and Basic) are the way they are because of what Basic was intended for. It was to be a language for beginners to programming to work with.

Now, that has evolved. If you write anything more complex than Hello World! in VB.Net, you will soon realize that it's more than just a newbie programmers language. It has evolved, as have the technology, to let computer programmers accomplish what they need to do with tools provided.
 
dragon4spy said:
Ok, Joe Mamma. Stop blaming vb. If you still think that delphi is better, then **Prove it**, writing the most advance delphi code, and post it here, right here. Please write a complete thing, not a function, not a few lines of code, not a feature, not a junk, or whatever. In addition, post a note when you start wring the code, in order to compare the time consuming of delphi.

Let's see if vb developers can write better that or not.
Click to expand...


I already did, a few times

the key one is class types

You CANNOT do that in VB6, you can in VB.NET using Type reflection

Class Variables are not a feature but a standard quality of a 4GL.
Their use is critical in creating class factories (not COM Class factories, though they could be used in COM creation)

But you asked so here we go. . . Got Delphi? Compile this mo-fo :)

this is a trivial example of something that cant be done in VB6. read the comment in the button click event

Joe Mamma. . .

PS. I guess I was a little harsh saying 'Learn To Program!!!'
what I mean is, 'Concentrate on Learning to Program not Learning a Language.'

Lexicon, not Syntax


PPS Remember Rule 62!!! It is the most important rule!!!
 
An interesting example, which would indeed be cumbersome if at all possible in VB6. Far more important than the lack of a Type type/class is the lack of inheritance. Trivial is indeed the key term here, since although the structure or style of the program code may be impossible to replicate in VB, the actual functionality of it is not.

Furthermore, it would be interesting to view a disassembly of your Delphi program after compilation. I would expect the instancing of a genereric 'Type' class just involved the use of a lookup table to select which class to instantiate (since all calls to this member can be resolved at compile time). If this were the case, replicating the functionality would be pretty easy with an enumeration or anything which could uniquely identify each class. I'm guessing the C# example would be more complex than that with much of the inner workings hidden away within the framework.

How do you think VB/COM's CreateObject works? All classes implement a known interface (in this case IUnknown). Since VB does support interfaces, it would be possible to write a class factory object/function.
 
Would this be it?

Visual Basic: 
'*********************************
'In a module
Public Enum ProcessorType
    Processor_VB = 0
    Processor_Delphi = 1
End Enum

'*********************************
'Interface IProcessor
Public Sub Process()
End Sub

'*********************************
'Class ProcessorVB
Implements IProcessor

Private Sub IProcessor_Process()
    MsgBox "VB sucks!!"
End Sub

'*********************************
'Class ProcessorDelphi
Implements IProcessor

Private Sub IProcessor_Process()
    MsgBox "Delphi rocks!!"
End Sub

'*********************************
'Class UniversalGenerator
Friend Function Create(ProcType As ProcessorType) As IProcessor
    If (ProcType = Processor_VB) Then
        Set Create = New ProcessorVB
    ElseIf (ProcType = Processor_Delphi) Then
        Set Create = New ProcessorDelphi
    End If
    'Could also invoke the .Process method directly if needed
End Function
 
Squirm said:
Would this be it?

'Class UniversalGenerator
Friend Function Create(ProcType As ProcessorType) As IProcessor
If (ProcType = Processor_VB) Then
Set Create = New ProcessorVB
ElseIf (ProcType = Processor_Delphi) Then
Set Create = New ProcessorDelphi
End If
'Could also invoke the .Process method directly if needed
End Function[/CODE]
Click to expand...


No, that wouldnt be it.

You see the problem is, lets say we wanted to add a new processor that says "C# also rules", it means we would have to change the 'Create' function to handle the new enumeration.

Code: 
Friend Function Create(ProcType As ProcessorType) As IProcessor
    If (ProcType = Processor_VB) Then
        Set Create = New ProcessorVB
    ElseIf (ProcType = Processor_Delphi) Then
        Set Create = New ProcessorDelphi
    ElseIf (ProcType = Processor_CSharp) Then
        Set Create = New ProcessorCSharp
    End If
End Function
[/CODE]

The beauty of the UniversalGenerator is it never has to be changed, it operates on the Class Type CustomProcessor and calls the constructor of what ever ProcessorType you send. ProcessorType isnt an enumeration but a Type Definition. If you look at the C#/Pas constructor of the UniversalGenerator it does no comparison of ProcessorType, it just calls ProcessorType.Create;

The idea is, derive from CustomProcessor and UniversalGenerator knows how to use it.

This is a very trivial example, but its strengths, with a little bit of creativity can be exploited to in some real neat ways. Delphi uses this to implement Typed Collections. Attached is a CSharp port of delphi's TCollection/TCollectionItem classes

The problem with COM Objects is that COM does not support inheritance. This was the domain driver for the .NET assemblies.
Yes you can inherit interfaces, but you can't inherit COM objects that implement them.

As far as seeing how Delphi implements it, that is the best thing about delphi, you get the source code. You might say 'aw but who wants to see Delphi Code?' but its not about syntax, its about lexicon. For some neat ideas, D/L the delphi package and take alook at their implementation of ADO Component wrappers for the ADO Type Library. . . hmmm. . . let me attach the port I did of ADO 2.8 and OLEDb (Delphi 7 only wrapped ADO 2.5 as that was what was available at release time)

Someone wondered about what the mother language of the visual studio package was -
The mother of Delphi was . . . Delphi

Joe Mamma
 

Attachments

Yes indeed the enumeration and the Create function need to be changed if we add a new class. Big deal. It isn't exactly a huge problem, 3 lines of code at the most. This is a small proportion compared to the amount of code which would go into writing the new class. Is it enough for someone who is confident and proficient in VB to learn a new language? Probably not. Does this make him/her a bad programmer? No. In addition, anyone who has properly planned the development of their application will know in advance all or most of the classes which will be needed within the enumeration so any modifications will be small.

You can take it further. Lets say you want to use template classes or template functions. As far as I know, these are not supported in Delphi. Is it worth learning C++ for this? Probably not. This is a good comparison since the code savings of templates are comparable to those you are demonstrating above with this code factory idea, perhaps even greater. You choose the right tools for the job. 99% of VB programmers do fine without template classes and without type classes. Does this make them bad programmers? No it doesn't.
 
yes in this over simplified application, it only entails 3 lines of code, lets take this to a reasonable extension. . . a service class with 6 (n) basic operations on the wrapped class:

Start, stop, pause, resume, install and uninstall. . .

you now have 18 (3n) changes that have to be managed.

bear in mind, you're example only dealt with the creation of the wrapped class, not the process itself, if the managed class were anymore complex, that complexity will be be propagated on the order of n.

And that is for just one class. now lets consider the effect of working in an environment with many developers. Three different developers are charged with implementing a service to be run in our 'universal server,' management of the project now becomes more involved than actual implementation. You can see why, in any situation outside the most trivial, using VB would become unwieldly.

And the point of the exercise was to create a universal class.

Reflection is a critical aspect of OOP not implemented in VB6. Yes it is implemented in vb.net, but this goes back to my orginial point, that seems to have touched a nerve, lack of experience in a paradigm.

As far as Template Classes, Template Classes are a neat feature of C++. The are dual to the universal class I demonstrated. In a template, you specify a type argument and act accordingly to a set of common method declarations. While delphi doesn't have template keyword, the 'class of' specification allows you to implement classes that are, for all intents and purposes, equivalent, not workarounds.

Now, do I need to show you what is extremely limiting in VB in that it lacked delegates?

In delphi, I could do the following:

Code: 
type
   TProcedure = procedure;
   TProcedureArray = Array[1..2] of TProcedure;

procedure DoSomething;
begin
   ShowMessage('VB Sucks!');
end;

procedure DoThis;
begin
   ShowMessage('Delphi Rocks');
end;

procedure DoThat;
begin
   ShowMessage('C# Sucks!');
end;

procedure InitializeProcesses(RunDoThat: Boolean; 
Processes: TProcessArray);
begin
   Processes[1] := DoSomething;
   if RunDoThat then
     Processes[2] := DoThis
  else
     Processes[2] := DoThat
end;  

var
   MyProgram: TProcessArray;
   i: Integer;
begin
   InitializeProcesses(true, MyProgram);
   for i:= Low(MyProgram) to High(MyProgram) do
       MyProgram[i];

   InitializeProcesses(false, MyProgram);
   for i:= Low(MyProgram) to High(MyProgram) do
       MyProgram[i];
end.

You couldn't do that in VB. does this mean you should learn delphi? No. it just means that VB sucks. and it means that VB devotees wont know how to domething that is critical.

So let me ask you something. . . be objective here.
Doesn't delphi code look easy to read?

My examples have and will continue to ellicit responses along the lines of 'why do I have to know how to do that?'

Come on now. . . use your imagination!!!
Don't make me pull out my TCustomThread classes. :eek:

But this leads me back to my initial point, I have no need for VB programers as they, IN GENERAL, don't get it. :-\

Smile! Dont be so thin skinned!!! most of my language is just to ruffle your feathers!
You know, get you to think critically?

I mean if everyone just agreed with everyone else where would we be?

Joe Joe
 
Squirm said:
No. In addition, anyone who has properly planned the development of their application will know in advance all or most of the classes which will be needed within the enumeration so any modifications will be small.
Click to expand...

You hold on to this one as long as you can!

joe mamma. . . waxing sentimental to when I, too, was young and naive
 
Forgive us if we get a little irritated if you say that VB (a language that many of us spent multiple years mastering) sucks, as you so blatantly put it, but I see no reason to make such a harsh and inaccurate statement. You may not have a need for a VB program, but a VB programmer might also know other languages (as I do). Would you turn away a C++ programmer who is a Visual Basic guru as well? I know a few. A good programmer is language independant.

If I recall correctly, Pascal was originally designed as a teaching tool rather than a practical programming language. That would explain its (and concequently Delphi's) cleanliness and emphasis on correct programming concepts. VB was not designed as a learning tool, but rather a rapid application development tool. While I agree that a beginner should not rely on VB (or any other single language for that matter) to learn the concepts of OOP and other things, it is not a bad language. I think a true beginner should learn the concepts of OOP and programming seperately from any language. The rest is just syntax.

VB does have its limits and it can get messy and sometimes kludges may be necessary, but it can do almost anything you want it to do (short of low level applications such as device drivers, but you wouldn't want VB for that anyway) as long as you know how to do it.

I think this thread has almost run its course. If there is nothing more to be added except arbitrary snippets of code to prove how much better Delphi is than VB, I'm going to lock it.
 
Last edited:
Status
Not open for further replies.
Back
Top