<snip>
>-I want you people to think out of the box!  C# was done by people thinking out of the box.  D has functions, so for those that want to use functions, let them. -I like OO (used functions once), but found OO better.
</snip>

What you seem to not understand is that once someone else has done it, it's no longer "outside the box".

Also, doing something simply because it's "outside the box" is bad. Walter has made his decisions based on many years of experience, not simply to be different. And putting in a feature simply because some other popular new language has it is also bad. Yes, if there were nothing different it wouldn't be a new language, so there must be some new stuff, and there is. D maintains a delicate balance between easily porting existing C code and fixing some of the "flaws" of C, while also adding "new" technology (most of which isn't actually new, just not in ANSI C).

I, personally, would rather that more of the "flaws" of C were fixed or fixed differently, but that's not going to happen in D. So I stopped arguing my points and have shut up (hint hint).

P.S. Poor grammar and spelling and profanity hurt your case.

> You don't understand me.

I think I(/we) do.

>  I don't evangelize .NET; I evangelize some
> features of C#/.NET that should be in D.

If that is true, you need to rethink your presentation style, since to me your posts smack of the former, despite being individually presented as the latter

> -I want D to succeed, because I want a native C# (since I don't know what mono is going to be, and it always is 2 years behind Microsoft).

Good. Here's some common ground.

> -I want you people to think out of the box!

Don't be ridiculous, not to say insulting. You have some of the smartest people in the industry on this NG.

>  C# was done by people
> thinking out of the box.

That's partly true. Another aspect was political (with both big and small
P).

Another aspect was, and I say this with some regret, to make programming more accessible to less competent people. I have witnessed this myself, whereby folks on C# and Java projects are happy to play with threads and other non-trivial concepts more than they would be in C/C++ because .NET/Java makes it easier for them to do so without making basic mistakes. However, the level of mistakes just moves to a higher level, evincing itself in bad design as opposed to broken code. To my mind, this barely represents a postive step.

Writing software is the most complex activity man has undertaken. (It was quoted at the time that the Win2K os was the most complex machine ever created.) Do we really want less-talented people to be doing it?

>  D has functions, so for those that want to use
> functions, let them. -I like OO (used functions once), but found OO
better.

You used functions once. ROFL.

Seriously, do you have any idea how that sounds? You just cut the legs out from any of your arguments.

It's like someone who only speaks, say, Italian, saying that Italian is the only language worth knowing. "Oh sure, I learned a few phrases in French once, but you can't say as much in French as you can in Italian".


> -I want D to have a library like delphi/.net has, full OO and component based (modern design of class libraries). For C++ you have vcf.sourceforge.net

Can you explain why OO is better?

I'm not saying a free-functions approach is better, or a fully generic approach, or whatever. But you are clearly making the point that an OO is superior, and I'm still waiting for you to offer some proof

> -In .NET you can have classes in dlls, D can have them too, no one is forcing you to use the dll format dictated by MS before .NET was arround.

I don't understand the point you're making here.

> -Becaues C\C++ have been arround for a lot of time, it doesn't mean that it is the best thing and stuff should still be done like that (that is why D has been invented).  Most people use Internet Explorer, is that the best browser? No.

What has C/C++ got to do with anything? Are you saying that an OO approach cannot be supported by either of these languages, and/or that use of these languages forces one to adopt an entirely procedural approach? None of those are true. I have written object-oriented code in C, and modern C++ is an even balance between OO (including ADTs and runtime-polymorphism) and generics, with just a dash of procedural thrown in for good measure

<ASIDE>C++ remains the best language at the moment because it ably supports *all* current programming paradigms (apart from functional, I guess, although some of the more abstruse meta techniques are moving in that direction). No other widely-used language can claim this, and the watered down attempts for generics in C# and Java are not going to come anywhere near allowing them to join the club. D aims to be the second one, and IMHO it stands a very good chance at doing so. If you would care to point out where this statement is wrong, I'll fry up my undies with a little extra virgin olive oil and eat them for dinner.</ASIDE>

> - D isn't perfect, but it can be close to perfect if you people think out of the box for a minute.

Again, you're being ridiculous, insulting and making fatuous blanket statements.

At this point I've exhausted my reserve of interest. Apologies if you have some good points further down.

Cheers

Matthew



> - The delegate/event model of C# should be included in D because, it makes
> it very easy to work with event based programming.
> - Methods/Properties should be PascalCase, it doesn't force you to use
> _var m_var and other types of decoration.
> - Indexers are cool since they allow you to use a class/struct like an
> array:
>
> public class Building
> {
>      Story[] stories;
>
>      public  Story this[int index] //doesn't have to be int eg: HashTable
>      {
>          get { return stories[index];
>          set
>          {
>              if (value != null)
>                  stories[index] = value;
>          }
>      }
> }
>
> public class Test
> {
>      public static void Main()
>      {
>          Building myHouse = new Building();
>          myHouse[10] = new Story("The last story");
>      }
> }
>
> - Operator overloading: It is easier to use the operators instead of
> functions (eg: opAdd()) when overloding.
>
>   public static bool operator != (Bar x, Bar y) {
> return x.value != y.value;
>   }
>
> - Attributes: Attributes are super cool and developers should be able to
> extend the language using attributes.
>    Attributes in D should have a better syntax to show that those things
> are different.  The reason why in C# they are [MyAttribute()] is
> MyAttribute is a class and you can have [MyAttribute(argument1, argument2,
> argument3)]
> class MyAttribute : FoobarAttribute
> {
>    // extend it
> }
>
> [MyAttribute()]
>   expression
>
> - C# has nailed a lot of good stuff, they looked at many languages when
> they made it. So D should have them too.
> - Namespaces and strong named assemblies (with metadata about the types)
> in dll format.  It is very anoying that you have to use the file system.
> - No header files (assemblies with meta data that support classes).
> - No more dozens of lines of ugly code to include a dll dynamically, take
> a look at the examples  Assembly.Load("mydll.dll"), use the classes in it
> with no problem.  A framework like that would be super cool in D.
> - Take a look at this article
> http://genamics.com/developer/csharp_comparative.htm and at the C#
> Language Reference.  All that cool stuff should be included.  If there is
> another cool thing that another language has that isn't in C#, included it
> too. But C# is perfect in a lot of ways.  Right now D is doing it the C
> way.
> - You can't build apps as fast in C++/C/D as you can do in .NET with any
> language (not as fast in Managed C++ since it has a lot of quircks).
> - Learn from .NET, and make D development as easy as it is in .NET.  It
> currently isn't. It is less complicated than C++ but with the library
> thing, it is just as worse (eg hard to load dlls, no classes, still, libs,
> headerfiles. ).
>
>
> I have attached those files that were posted, even though they look fine in Opera 7.5.  How come you can't see the tabs?
>
> This is the earlier post:
>
> Dude, in .NET you can do all that. For example at compile time i can have a dll with objects in it.  For example DigitalPlay.dll.
>
> namespace Test
> {
> using DigitalPlay.FoobarClient;
>
> class Testing
> {
>      public static void Main() {
>       DigitalPlay.FoobarClient.Client foo = new
> DigitalPlay.FoobarClient.Client();
>       // or shortcut it since i sayed using...
>       Client foo = new Client();
> }
> }
>
> csc.exe Test.cs /resources:DigitalPlay.dll
>
> The compiler looks for types in the resources provided and links them, No *.lib, header files no nothing. For late binding, it is a little more complicated:
>
> Interfaces.cs (dll)
> PluginServices.cs (dll)
> Plugin.cs (dll)
> Main.cs (exe)
> ***Attachment***
>
> Compilation
> 1) Interfaces.dll
> 2) PluginServices.dll (csc /target:library /resources:Interfaces.dll)
> 4) Plugin.dll (csc.exe /target:library
> /resources:Interface.dll;Pluginservices.dll)
> 3) Main.exe (csc.exe Main.cs /resources:Interfaces.dll;PluginServices.dll)
>
>
> The code is self explanatory.
>
> I could have showed you this in a few lines, but insted I showed you a full plugin system.  This also shows you the power of .NET types and how they describe themselves.  If you do this crap the same as it has been done before C-Like, that what is the point? Show some progress, damn it. D has potential, but you have to create a nice class library like .NET and stop doing the C-way of doing things. D, a 21st century language with the mentality of 1970s.
>
> For a system api call i'd use
> namespace Testing
> {
>    // using isn't import, it is a shortcut so you won't have to type the
> whole thing
>    using System.Runtime.InteropServices;
>
>    public class Tester
>    {
>      [DllImport("kernel32.dll")]
>      private static extern bool FreeConsole();
>      public static void Main()
>      {
>         FreeConsole();
>      }
>    }
> }
>
> So yes, you can use CLASSES in DLLS and no shitty header files or lib files.
>
> - This is for now, I'll post anything else that I forgot some other time.
> - I don't evangalize C# as something that should be used over D, I want C#
> features to be in D.
> - There is one feature in D, that i'd like in C#, so i'll use for instead:
>    foreach (int i, char c; a)
>    { ]
>    In C# you don't have access to the index.
>
>    C#
>    foreach (ElementType element in collection) { // statement}
>
>    translates into
>
>    IEnumerator enumerator =
> ((System.IEnumerable)(collection)).GetEnumerator();
>     try {
>     while (enumerator.MoveNext()) {
>        ElementType element = (ElementType)enumerator.Current;
>        statement;
>     }
>    }
> finally {
>     IDisposable disposable = enumerator as System.IDisposable;
>     if (disposable != null) disposable.Dispose();
> }

You just, stopped at reading the good part, features of C# that I want in D.
Did you look at those attachments, that asked for?
My target isn't you anyway, it is Mr. Walter Bright.
I appologize for any spelling mistakes.  As for why I haven't backed some of points like OO vs. procedural, those have already been backed up all over the net.

You have a right to state your opinion, just as I do.

On Sun, 22 Feb 2004 16:27:48 +1100, Matthew <matthew.hat@stlsoft.dot.org> wrote:

>> You don't understand me.
>
> I think I(/we) do.
>
>>  I don't evangelize .NET; I evangelize some
>> features of C#/.NET that should be in D.
>
> If that is true, you need to rethink your presentation style, since to me
> your posts smack of the former, despite being individually presented as the
> latter
>
>> -I want D to succeed, because I want a native C# (since I don't know what
>> mono is going to be, and it always is 2 years behind Microsoft).
>
> Good. Here's some common ground.
>
>> -I want you people to think out of the box!
>
> Don't be ridiculous, not to say insulting. You have some of the smartest
> people in the industry on this NG.
>
>>  C# was done by people
>> thinking out of the box.
>
> That's partly true. Another aspect was political (with both big and small
> P).
>
> Another aspect was, and I say this with some regret, to make programming
> more accessible to less competent people. I have witnessed this myself,
> whereby folks on C# and Java projects are happy to play with threads and
> other non-trivial concepts more than they would be in C/C++ because
> .NET/Java makes it easier for them to do so without making basic mistakes.
> However, the level of mistakes just moves to a higher level, evincing itself
> in bad design as opposed to broken code. To my mind, this barely represents
> a postive step.
>
> Writing software is the most complex activity man has undertaken. (It was
> quoted at the time that the Win2K os was the most complex machine ever
> created.) Do we really want less-talented people to be doing it?
>
>>  D has functions, so for those that want to use
>> functions, let them. -I like OO (used functions once), but found OO
> better.
>
> You used functions once. ROFL.
>
> Seriously, do you have any idea how that sounds? You just cut the legs out
> from any of your arguments.
>
> It's like someone who only speaks, say, Italian, saying that Italian is the
> only language worth knowing. "Oh sure, I learned a few phrases in French
> once, but you can't say as much in French as you can in Italian".
>
>
>> -I want D to have a library like delphi/.net has, full OO and component
>> based (modern design of class libraries). For C++ you have
>> vcf.sourceforge.net
>
> Can you explain why OO is better?
>
> I'm not saying a free-functions approach is better, or a fully generic
> approach, or whatever. But you are clearly making the point that an OO is
> superior, and I'm still waiting for you to offer some proof
>
>> -In .NET you can have classes in dlls, D can have them too, no one is
>> forcing you to use the dll format dictated by MS before .NET was arround.
>
> I don't understand the point you're making here.
>
>> -Becaues C\C++ have been arround for a lot of time, it doesn't mean that
>> it is the best thing and stuff should still be done like that (that is why
>> D has been invented).  Most people use Internet Explorer, is that the best
>> browser? No.
>
> What has C/C++ got to do with anything? Are you saying that an OO approach
> cannot be supported by either of these languages, and/or that use of these
> languages forces one to adopt an entirely procedural approach? None of those
> are true. I have written object-oriented code in C, and modern C++ is an
> even balance between OO (including ADTs and runtime-polymorphism) and
> generics, with just a dash of procedural thrown in for good measure
>
> <ASIDE>C++ remains the best language at the moment because it ably supports
> *all* current programming paradigms (apart from functional, I guess,
> although some of the more abstruse meta techniques are moving in that
> direction). No other widely-used language can claim this, and the watered
> down attempts for generics in C# and Java are not going to come anywhere
> near allowing them to join the club. D aims to be the second one, and IMHO
> it stands a very good chance at doing so. If you would care to point out
> where this statement is wrong, I'll fry up my undies with a little extra
> virgin olive oil and eat them for dinner.</ASIDE>
>
>> - D isn't perfect, but it can be close to perfect if you people think out
>> of the box for a minute.
>
> Again, you're being ridiculous, insulting and making fatuous blanket
> statements.
>
> At this point I've exhausted my reserve of interest. Apologies if you have
> some good points further down.
>
> Cheers
>
> Matthew
>
>
>
>> - The delegate/event model of C# should be included in D because, it makes
>> it very easy to work with event based programming.
>> - Methods/Properties should be PascalCase, it doesn't force you to use
>> _var m_var and other types of decoration.
>> - Indexers are cool since they allow you to use a class/struct like an
>> array:
>>
>> public class Building
>> {
>>      Story[] stories;
>>
>>      public  Story this[int index] //doesn't have to be int eg: HashTable
>>      {
>>          get { return stories[index];
>>          set
>>          {
>>              if (value != null)
>>                  stories[index] = value;
>>          }
>>      }
>> }
>>
>> public class Test
>> {
>>      public static void Main()
>>      {
>>          Building myHouse = new Building();
>>          myHouse[10] = new Story("The last story");
>>      }
>> }
>>
>> - Operator overloading: It is easier to use the operators instead of
>> functions (eg: opAdd()) when overloding.
>>
>>   public static bool operator != (Bar x, Bar y) {
>> return x.value != y.value;
>>   }
>>
>> - Attributes: Attributes are super cool and developers should be able to
>> extend the language using attributes.
>>    Attributes in D should have a better syntax to show that those things
>> are different.  The reason why in C# they are [MyAttribute()] is
>> MyAttribute is a class and you can have [MyAttribute(argument1, argument2,
>> argument3)]
>> class MyAttribute : FoobarAttribute
>> {
>>    // extend it
>> }
>>
>> [MyAttribute()]
>>   expression
>>
>> - C# has nailed a lot of good stuff, they looked at many languages when
>> they made it. So D should have them too.
>> - Namespaces and strong named assemblies (with metadata about the types)
>> in dll format.  It is very anoying that you have to use the file system.
>> - No header files (assemblies with meta data that support classes).
>> - No more dozens of lines of ugly code to include a dll dynamically, take
>> a look at the examples  Assembly.Load("mydll.dll"), use the classes in it
>> with no problem.  A framework like that would be super cool in D.
>> - Take a look at this article
>> http://genamics.com/developer/csharp_comparative.htm and at the C#
>> Language Reference.  All that cool stuff should be included.  If there is
>> another cool thing that another language has that isn't in C#, included it
>> too. But C# is perfect in a lot of ways.  Right now D is doing it the C
>> way.
>> - You can't build apps as fast in C++/C/D as you can do in .NET with any
>> language (not as fast in Managed C++ since it has a lot of quircks).
>> - Learn from .NET, and make D development as easy as it is in .NET.  It
>> currently isn't. It is less complicated than C++ but with the library
>> thing, it is just as worse (eg hard to load dlls, no classes, still, libs,
>> headerfiles. ).
>>
>>
>> I have attached those files that were posted, even though they look fine
>> in Opera 7.5.  How come you can't see the tabs?
>>
>> This is the earlier post:
>>
>> Dude, in .NET you can do all that. For example at compile time i can have
>> a dll with objects in it.  For example DigitalPlay.dll.
>>
>> namespace Test
>> {
>> using DigitalPlay.FoobarClient;
>>
>> class Testing
>> {
>>      public static void Main() {
>>       DigitalPlay.FoobarClient.Client foo = new
>> DigitalPlay.FoobarClient.Client();
>>       // or shortcut it since i sayed using...
>>       Client foo = new Client();
>> }
>> }
>>
>> csc.exe Test.cs /resources:DigitalPlay.dll
>>
>> The compiler looks for types in the resources provided and links them, No
>> *.lib, header files no nothing. For late binding, it is a little more
>> complicated:
>>
>> Interfaces.cs (dll)
>> PluginServices.cs (dll)
>> Plugin.cs (dll)
>> Main.cs (exe)
>> ***Attachment***
>>
>> Compilation
>> 1) Interfaces.dll
>> 2) PluginServices.dll (csc /target:library /resources:Interfaces.dll)
>> 4) Plugin.dll (csc.exe /target:library
>> /resources:Interface.dll;Pluginservices.dll)
>> 3) Main.exe (csc.exe Main.cs /resources:Interfaces.dll;PluginServices.dll)
>>
>>
>> The code is self explanatory.
>>
>> I could have showed you this in a few lines, but insted I showed you a
>> full plugin system.  This also shows you the power of .NET types and how
>> they describe themselves.  If you do this crap the same as it has been
>> done before C-Like, that what is the point? Show some progress, damn it. D
>> has potential, but you have to create a nice class library like .NET and
>> stop doing the C-way of doing things. D, a 21st century language with the
>> mentality of 1970s.
>>
>> For a system api call i'd use
>> namespace Testing
>> {
>>    // using isn't import, it is a shortcut so you won't have to type the
>> whole thing
>>    using System.Runtime.InteropServices;
>>
>>    public class Tester
>>    {
>>      [DllImport("kernel32.dll")]
>>      private static extern bool FreeConsole();
>>      public static void Main()
>>      {
>>         FreeConsole();
>>      }
>>    }
>> }
>>
>> So yes, you can use CLASSES in DLLS and no shitty header files or lib
>> files.
>>
>> - This is for now, I'll post anything else that I forgot some other time.
>> - I don't evangalize C# as something that should be used over D, I want C#
>> features to be in D.
>> - There is one feature in D, that i'd like in C#, so i'll use for instead:
>>    foreach (int i, char c; a)
>>    { ]
>>    In C# you don't have access to the index.
>>
>>    C#
>>    foreach (ElementType element in collection) { // statement}
>>
>>    translates into
>>
>>    IEnumerator enumerator =
>> ((System.IEnumerable)(collection)).GetEnumerator();
>>     try {
>>     while (enumerator.MoveNext()) {
>>        ElementType element = (ElementType)enumerator.Current;
>>        statement;
>>     }
>>    }
>> finally {
>>     IDisposable disposable = enumerator as System.IDisposable;
>>     if (disposable != null) disposable.Dispose();
>> }
>
>



-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

There is no conclusive decision anywhere in the world that OO programming is inherently better than procedural.  It is a lot more hyped, certainly, and it is definitely better at representing some kinds of problems.  But for a large class of problems, it is simply not necessary, and forcing it on those problems is a horrible corruption of the whole idea of OO.

Point in case: public static void main (String[] args)

There is no reason in the world why the main function should be part of a class. It makes absolutely no sense, and completely breaks the idea of OO being used to represent OBJECTS.

The point is, then, that there is no need for any sensible language to be as rigidly OO as, say, Java.  Forcing some things in OO is just stupid, and some problems are better off solved procedurally.

Another example:  I just today what a utility in procedural C to do some statistical analysis on datasets.  There was no need for OO: it just read values, did some math on them, and wrote them back out.  Now, in Java or another rigidly OO system, I would have had to define a class just to stick my procedural function in.  Where is the logic in that?

It is far more useful and flexible, especially for a language like D which claims to be a systems language as well, NOT to rigidly OO.

-Owen

In article <opr3rbgpw61s9n15@saturn>, SpookyET says...
>
>You just, stopped at reading the good part, features of C# that I want in
>D.
>Did you look at those attachments, that asked for?
>My target isn't you anyway, it is Mr. Walter Bright.
>I appologize for any spelling mistakes.  As for why I haven't backed some
>of points like OO vs. procedural, those have already been backed up all
>over the net.
>
>You have a right to state your opinion, just as I do.
>
>On Sun, 22 Feb 2004 16:27:48 +1100, Matthew <matthew.hat@stlsoft.dot.org> wrote:
>
>>> You don't understand me.
>>
>> I think I(/we) do.
>>
>>>  I don't evangelize .NET; I evangelize some
>>> features of C#/.NET that should be in D.
>>
>> If that is true, you need to rethink your presentation style, since to me
>> your posts smack of the former, despite being individually presented as
>> the
>> latter
>>
>>> -I want D to succeed, because I want a native C# (since I don't know
>>> what
>>> mono is going to be, and it always is 2 years behind Microsoft).
>>
>> Good. Here's some common ground.
>>
>>> -I want you people to think out of the box!
>>
>> Don't be ridiculous, not to say insulting. You have some of the smartest people in the industry on this NG.
>>
>>>  C# was done by people
>>> thinking out of the box.
>>
>> That's partly true. Another aspect was political (with both big and small
>> P).
>>
>> Another aspect was, and I say this with some regret, to make programming
>> more accessible to less competent people. I have witnessed this myself,
>> whereby folks on C# and Java projects are happy to play with threads and
>> other non-trivial concepts more than they would be in C/C++ because
>> .NET/Java makes it easier for them to do so without making basic
>> mistakes.
>> However, the level of mistakes just moves to a higher level, evincing
>> itself
>> in bad design as opposed to broken code. To my mind, this barely
>> represents
>> a postive step.
>>
>> Writing software is the most complex activity man has undertaken. (It was quoted at the time that the Win2K os was the most complex machine ever created.) Do we really want less-talented people to be doing it?
>>
>>>  D has functions, so for those that want to use
>>> functions, let them. -I like OO (used functions once), but found OO
>> better.
>>
>> You used functions once. ROFL.
>>
>> Seriously, do you have any idea how that sounds? You just cut the legs
>> out
>> from any of your arguments.
>>
>> It's like someone who only speaks, say, Italian, saying that Italian is
>> the
>> only language worth knowing. "Oh sure, I learned a few phrases in French
>> once, but you can't say as much in French as you can in Italian".
>>
>>
>>> -I want D to have a library like delphi/.net has, full OO and component based (modern design of class libraries). For C++ you have vcf.sourceforge.net
>>
>> Can you explain why OO is better?
>>
>> I'm not saying a free-functions approach is better, or a fully generic approach, or whatever. But you are clearly making the point that an OO is superior, and I'm still waiting for you to offer some proof
>>
>>> -In .NET you can have classes in dlls, D can have them too, no one is forcing you to use the dll format dictated by MS before .NET was arround.
>>
>> I don't understand the point you're making here.
>>
>>> -Becaues C\C++ have been arround for a lot of time, it doesn't mean that
>>> it is the best thing and stuff should still be done like that (that is
>>> why
>>> D has been invented).  Most people use Internet Explorer, is that the
>>> best
>>> browser? No.
>>
>> What has C/C++ got to do with anything? Are you saying that an OO
>> approach
>> cannot be supported by either of these languages, and/or that use of
>> these
>> languages forces one to adopt an entirely procedural approach? None of
>> those
>> are true. I have written object-oriented code in C, and modern C++ is an
>> even balance between OO (including ADTs and runtime-polymorphism) and
>> generics, with just a dash of procedural thrown in for good measure
>>
>> <ASIDE>C++ remains the best language at the moment because it ably
>> supports
>> *all* current programming paradigms (apart from functional, I guess,
>> although some of the more abstruse meta techniques are moving in that
>> direction). No other widely-used language can claim this, and the watered
>> down attempts for generics in C# and Java are not going to come anywhere
>> near allowing them to join the club. D aims to be the second one, and
>> IMHO
>> it stands a very good chance at doing so. If you would care to point out
>> where this statement is wrong, I'll fry up my undies with a little extra
>> virgin olive oil and eat them for dinner.</ASIDE>
>>
>>> - D isn't perfect, but it can be close to perfect if you people think
>>> out
>>> of the box for a minute.
>>
>> Again, you're being ridiculous, insulting and making fatuous blanket statements.
>>
>> At this point I've exhausted my reserve of interest. Apologies if you
>> have
>> some good points further down.
>>
>> Cheers
>>
>> Matthew
>>
>>
>>
>>> - The delegate/event model of C# should be included in D because, it
>>> makes
>>> it very easy to work with event based programming.
>>> - Methods/Properties should be PascalCase, it doesn't force you to use
>>> _var m_var and other types of decoration.
>>> - Indexers are cool since they allow you to use a class/struct like an
>>> array:
>>>
>>> public class Building
>>> {
>>>      Story[] stories;
>>>
>>>      public  Story this[int index] //doesn't have to be int eg:
>>> HashTable
>>>      {
>>>          get { return stories[index];
>>>          set
>>>          {
>>>              if (value != null)
>>>                  stories[index] = value;
>>>          }
>>>      }
>>> }
>>>
>>> public class Test
>>> {
>>>      public static void Main()
>>>      {
>>>          Building myHouse = new Building();
>>>          myHouse[10] = new Story("The last story");
>>>      }
>>> }
>>>
>>> - Operator overloading: It is easier to use the operators instead of
>>> functions (eg: opAdd()) when overloding.
>>>
>>>   public static bool operator != (Bar x, Bar y) {
>>> return x.value != y.value;
>>>   }
>>>
>>> - Attributes: Attributes are super cool and developers should be able to
>>> extend the language using attributes.
>>>    Attributes in D should have a better syntax to show that those things
>>> are different.  The reason why in C# they are [MyAttribute()] is
>>> MyAttribute is a class and you can have [MyAttribute(argument1,
>>> argument2,
>>> argument3)]
>>> class MyAttribute : FoobarAttribute
>>> {
>>>    // extend it
>>> }
>>>
>>> [MyAttribute()]
>>>   expression
>>>
>>> - C# has nailed a lot of good stuff, they looked at many languages when
>>> they made it. So D should have them too.
>>> - Namespaces and strong named assemblies (with metadata about the types)
>>> in dll format.  It is very anoying that you have to use the file system.
>>> - No header files (assemblies with meta data that support classes).
>>> - No more dozens of lines of ugly code to include a dll dynamically,
>>> take
>>> a look at the examples  Assembly.Load("mydll.dll"), use the classes in
>>> it
>>> with no problem.  A framework like that would be super cool in D.
>>> - Take a look at this article
>>> http://genamics.com/developer/csharp_comparative.htm and at the C#
>>> Language Reference.  All that cool stuff should be included.  If there
>>> is
>>> another cool thing that another language has that isn't in C#, included
>>> it
>>> too. But C# is perfect in a lot of ways.  Right now D is doing it the C
>>> way.
>>> - You can't build apps as fast in C++/C/D as you can do in .NET with any
>>> language (not as fast in Managed C++ since it has a lot of quircks).
>>> - Learn from .NET, and make D development as easy as it is in .NET.  It
>>> currently isn't. It is less complicated than C++ but with the library
>>> thing, it is just as worse (eg hard to load dlls, no classes, still,
>>> libs,
>>> headerfiles. ).
>>>
>>>
>>> I have attached those files that were posted, even though they look fine in Opera 7.5.  How come you can't see the tabs?
>>>
>>> This is the earlier post:
>>>
>>> Dude, in .NET you can do all that. For example at compile time i can
>>> have
>>> a dll with objects in it.  For example DigitalPlay.dll.
>>>
>>> namespace Test
>>> {
>>> using DigitalPlay.FoobarClient;
>>>
>>> class Testing
>>> {
>>>      public static void Main() {
>>>       DigitalPlay.FoobarClient.Client foo = new
>>> DigitalPlay.FoobarClient.Client();
>>>       // or shortcut it since i sayed using...
>>>       Client foo = new Client();
>>> }
>>> }
>>>
>>> csc.exe Test.cs /resources:DigitalPlay.dll
>>>
>>> The compiler looks for types in the resources provided and links them,
>>> No
>>> *.lib, header files no nothing. For late binding, it is a little more
>>> complicated:
>>>
>>> Interfaces.cs (dll)
>>> PluginServices.cs (dll)
>>> Plugin.cs (dll)
>>> Main.cs (exe)
>>> ***Attachment***
>>>
>>> Compilation
>>> 1) Interfaces.dll
>>> 2) PluginServices.dll (csc /target:library /resources:Interfaces.dll)
>>> 4) Plugin.dll (csc.exe /target:library
>>> /resources:Interface.dll;Pluginservices.dll)
>>> 3) Main.exe (csc.exe Main.cs
>>> /resources:Interfaces.dll;PluginServices.dll)
>>>
>>>
>>> The code is self explanatory.
>>>
>>> I could have showed you this in a few lines, but insted I showed you a
>>> full plugin system.  This also shows you the power of .NET types and how
>>> they describe themselves.  If you do this crap the same as it has been
>>> done before C-Like, that what is the point? Show some progress, damn
>>> it. D
>>> has potential, but you have to create a nice class library like .NET and
>>> stop doing the C-way of doing things. D, a 21st century language with
>>> the
>>> mentality of 1970s.
>>>
>>> For a system api call i'd use
>>> namespace Testing
>>> {
>>>    // using isn't import, it is a shortcut so you won't have to type the
>>> whole thing
>>>    using System.Runtime.InteropServices;
>>>
>>>    public class Tester
>>>    {
>>>      [DllImport("kernel32.dll")]
>>>      private static extern bool FreeConsole();
>>>      public static void Main()
>>>      {
>>>         FreeConsole();
>>>      }
>>>    }
>>> }
>>>
>>> So yes, you can use CLASSES in DLLS and no shitty header files or lib files.
>>>
>>> - This is for now, I'll post anything else that I forgot some other
>>> time.
>>> - I don't evangalize C# as something that should be used over D, I want
>>> C#
>>> features to be in D.
>>> - There is one feature in D, that i'd like in C#, so i'll use for
>>> instead:
>>>    foreach (int i, char c; a)
>>>    { ]
>>>    In C# you don't have access to the index.
>>>
>>>    C#
>>>    foreach (ElementType element in collection) { // statement}
>>>
>>>    translates into
>>>
>>>    IEnumerator enumerator =
>>> ((System.IEnumerable)(collection)).GetEnumerator();
>>>     try {
>>>     while (enumerator.MoveNext()) {
>>>        ElementType element = (ElementType)enumerator.Current;
>>>        statement;
>>>     }
>>>    }
>>> finally {
>>>     IDisposable disposable = enumerator as System.IDisposable;
>>>     if (disposable != null) disposable.Dispose();
>>> }
>>
>>
>
>
>
>-- 
>Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

> You just, stopped at reading the good part, features of C# that I want in
D.

Which illustrates the point that you've just lost your audience.

> Did you look at those attachments, that asked for?

Not yet.

> My target isn't you anyway, it is Mr. Walter Bright.

Oh really? And do you think Walter went to the trouble of creating a language and initiaiting, and participating in, this newsgroup only to pay it no heed.

I can tell you the NG has been most influential with Walter on a number of important issues: structs, deterministic destruction (which, btw, neither Java/.NET have, despite the specious pretense of the using keyword), etc. etc.

> I appologize for any spelling mistakes.

I have no problem with spelling mistakes. :)

>  As for why I haven't backed some
> of points like OO vs. procedural, those have already been backed up all
> over the net.

You've failed to address the point, *again*.

*You* state that D should go all OO, and yet *you* can offer no evidence to back up your assertion.

That's like me ringing up the folks at MS and telling them that they're OS is crap. They might, perhaps, enquire as to why I would think that. Were I then to say, "well everyone thinks so", I expect I'd hear a little click, and that would be that.

> You have a right to state your opinion, just as I do.

Indeed. But if you want anyone to listen to your opinion, you'd better offer more than just opinion and statements. Offer proof. Back up what you say. If you can't/won't, then get off the pot. You're just wasting everyone's time.


> On Sun, 22 Feb 2004 16:27:48 +1100, Matthew <matthew.hat@stlsoft.dot.org> wrote:
>
> >> You don't understand me.
> >
> > I think I(/we) do.
> >
> >>  I don't evangelize .NET; I evangelize some
> >> features of C#/.NET that should be in D.
> >
> > If that is true, you need to rethink your presentation style, since to
me
> > your posts smack of the former, despite being individually presented as
> > the
> > latter
> >
> >> -I want D to succeed, because I want a native C# (since I don't know
> >> what
> >> mono is going to be, and it always is 2 years behind Microsoft).
> >
> > Good. Here's some common ground.
> >
> >> -I want you people to think out of the box!
> >
> > Don't be ridiculous, not to say insulting. You have some of the smartest people in the industry on this NG.
> >
> >>  C# was done by people
> >> thinking out of the box.
> >
> > That's partly true. Another aspect was political (with both big and
small
> > P).
> >
> > Another aspect was, and I say this with some regret, to make programming
> > more accessible to less competent people. I have witnessed this myself,
> > whereby folks on C# and Java projects are happy to play with threads and
> > other non-trivial concepts more than they would be in C/C++ because
> > .NET/Java makes it easier for them to do so without making basic
> > mistakes.
> > However, the level of mistakes just moves to a higher level, evincing
> > itself
> > in bad design as opposed to broken code. To my mind, this barely
> > represents
> > a postive step.
> >
> > Writing software is the most complex activity man has undertaken. (It
was
> > quoted at the time that the Win2K os was the most complex machine ever created.) Do we really want less-talented people to be doing it?
> >
> >>  D has functions, so for those that want to use
> >> functions, let them. -I like OO (used functions once), but found OO
> > better.
> >
> > You used functions once. ROFL.
> >
> > Seriously, do you have any idea how that sounds? You just cut the legs
> > out
> > from any of your arguments.
> >
> > It's like someone who only speaks, say, Italian, saying that Italian is
> > the
> > only language worth knowing. "Oh sure, I learned a few phrases in French
> > once, but you can't say as much in French as you can in Italian".
> >
> >
> >> -I want D to have a library like delphi/.net has, full OO and component based (modern design of class libraries). For C++ you have vcf.sourceforge.net
> >
> > Can you explain why OO is better?
> >
> > I'm not saying a free-functions approach is better, or a fully generic approach, or whatever. But you are clearly making the point that an OO
is
> > superior, and I'm still waiting for you to offer some proof
> >
> >> -In .NET you can have classes in dlls, D can have them too, no one is forcing you to use the dll format dictated by MS before .NET was arround.
> >
> > I don't understand the point you're making here.
> >
> >> -Becaues C\C++ have been arround for a lot of time, it doesn't mean
that
> >> it is the best thing and stuff should still be done like that (that is
> >> why
> >> D has been invented).  Most people use Internet Explorer, is that the
> >> best
> >> browser? No.
> >
> > What has C/C++ got to do with anything? Are you saying that an OO
> > approach
> > cannot be supported by either of these languages, and/or that use of
> > these
> > languages forces one to adopt an entirely procedural approach? None of
> > those
> > are true. I have written object-oriented code in C, and modern C++ is an
> > even balance between OO (including ADTs and runtime-polymorphism) and
> > generics, with just a dash of procedural thrown in for good measure
> >
> > <ASIDE>C++ remains the best language at the moment because it ably
> > supports
> > *all* current programming paradigms (apart from functional, I guess,
> > although some of the more abstruse meta techniques are moving in that
> > direction). No other widely-used language can claim this, and the
watered
> > down attempts for generics in C# and Java are not going to come anywhere
> > near allowing them to join the club. D aims to be the second one, and
> > IMHO
> > it stands a very good chance at doing so. If you would care to point out
> > where this statement is wrong, I'll fry up my undies with a little extra
> > virgin olive oil and eat them for dinner.</ASIDE>
> >
> >> - D isn't perfect, but it can be close to perfect if you people think
> >> out
> >> of the box for a minute.
> >
> > Again, you're being ridiculous, insulting and making fatuous blanket statements.
> >
> > At this point I've exhausted my reserve of interest. Apologies if you
> > have
> > some good points further down.
> >
> > Cheers
> >
> > Matthew
> >
> >
> >
> >> - The delegate/event model of C# should be included in D because, it
> >> makes
> >> it very easy to work with event based programming.
> >> - Methods/Properties should be PascalCase, it doesn't force you to use
> >> _var m_var and other types of decoration.
> >> - Indexers are cool since they allow you to use a class/struct like an
> >> array:
> >>
> >> public class Building
> >> {
> >>      Story[] stories;
> >>
> >>      public  Story this[int index] //doesn't have to be int eg:
> >> HashTable
> >>      {
> >>          get { return stories[index];
> >>          set
> >>          {
> >>              if (value != null)
> >>                  stories[index] = value;
> >>          }
> >>      }
> >> }
> >>
> >> public class Test
> >> {
> >>      public static void Main()
> >>      {
> >>          Building myHouse = new Building();
> >>          myHouse[10] = new Story("The last story");
> >>      }
> >> }
> >>
> >> - Operator overloading: It is easier to use the operators instead of
> >> functions (eg: opAdd()) when overloding.
> >>
> >>   public static bool operator != (Bar x, Bar y) {
> >> return x.value != y.value;
> >>   }
> >>
> >> - Attributes: Attributes are super cool and developers should be able
to
> >> extend the language using attributes.
> >>    Attributes in D should have a better syntax to show that those
things
> >> are different.  The reason why in C# they are [MyAttribute()] is
> >> MyAttribute is a class and you can have [MyAttribute(argument1,
> >> argument2,
> >> argument3)]
> >> class MyAttribute : FoobarAttribute
> >> {
> >>    // extend it
> >> }
> >>
> >> [MyAttribute()]
> >>   expression
> >>
> >> - C# has nailed a lot of good stuff, they looked at many languages when
> >> they made it. So D should have them too.
> >> - Namespaces and strong named assemblies (with metadata about the
types)
> >> in dll format.  It is very anoying that you have to use the file
system.
> >> - No header files (assemblies with meta data that support classes).
> >> - No more dozens of lines of ugly code to include a dll dynamically,
> >> take
> >> a look at the examples  Assembly.Load("mydll.dll"), use the classes in
> >> it
> >> with no problem.  A framework like that would be super cool in D.
> >> - Take a look at this article
> >> http://genamics.com/developer/csharp_comparative.htm and at the C#
> >> Language Reference.  All that cool stuff should be included.  If there
> >> is
> >> another cool thing that another language has that isn't in C#, included
> >> it
> >> too. But C# is perfect in a lot of ways.  Right now D is doing it the C
> >> way.
> >> - You can't build apps as fast in C++/C/D as you can do in .NET with
any
> >> language (not as fast in Managed C++ since it has a lot of quircks).
> >> - Learn from .NET, and make D development as easy as it is in .NET.  It
> >> currently isn't. It is less complicated than C++ but with the library
> >> thing, it is just as worse (eg hard to load dlls, no classes, still,
> >> libs,
> >> headerfiles. ).
> >>
> >>
> >> I have attached those files that were posted, even though they look
fine
> >> in Opera 7.5.  How come you can't see the tabs?
> >>
> >> This is the earlier post:
> >>
> >> Dude, in .NET you can do all that. For example at compile time i can
> >> have
> >> a dll with objects in it.  For example DigitalPlay.dll.
> >>
> >> namespace Test
> >> {
> >> using DigitalPlay.FoobarClient;
> >>
> >> class Testing
> >> {
> >>      public static void Main() {
> >>       DigitalPlay.FoobarClient.Client foo = new
> >> DigitalPlay.FoobarClient.Client();
> >>       // or shortcut it since i sayed using...
> >>       Client foo = new Client();
> >> }
> >> }
> >>
> >> csc.exe Test.cs /resources:DigitalPlay.dll
> >>
> >> The compiler looks for types in the resources provided and links them,
> >> No
> >> *.lib, header files no nothing. For late binding, it is a little more
> >> complicated:
> >>
> >> Interfaces.cs (dll)
> >> PluginServices.cs (dll)
> >> Plugin.cs (dll)
> >> Main.cs (exe)
> >> ***Attachment***
> >>
> >> Compilation
> >> 1) Interfaces.dll
> >> 2) PluginServices.dll (csc /target:library /resources:Interfaces.dll)
> >> 4) Plugin.dll (csc.exe /target:library
> >> /resources:Interface.dll;Pluginservices.dll)
> >> 3) Main.exe (csc.exe Main.cs
> >> /resources:Interfaces.dll;PluginServices.dll)
> >>
> >>
> >> The code is self explanatory.
> >>
> >> I could have showed you this in a few lines, but insted I showed you a full plugin system.  This also shows you the power of .NET types and
how
> >> they describe themselves.  If you do this crap the same as it has been
> >> done before C-Like, that what is the point? Show some progress, damn
> >> it. D
> >> has potential, but you have to create a nice class library like .NET
and
> >> stop doing the C-way of doing things. D, a 21st century language with
> >> the
> >> mentality of 1970s.
> >>
> >> For a system api call i'd use
> >> namespace Testing
> >> {
> >>    // using isn't import, it is a shortcut so you won't have to type
the
> >> whole thing
> >>    using System.Runtime.InteropServices;
> >>
> >>    public class Tester
> >>    {
> >>      [DllImport("kernel32.dll")]
> >>      private static extern bool FreeConsole();
> >>      public static void Main()
> >>      {
> >>         FreeConsole();
> >>      }
> >>    }
> >> }
> >>
> >> So yes, you can use CLASSES in DLLS and no shitty header files or lib files.
> >>
> >> - This is for now, I'll post anything else that I forgot some other
> >> time.
> >> - I don't evangalize C# as something that should be used over D, I want
> >> C#
> >> features to be in D.
> >> - There is one feature in D, that i'd like in C#, so i'll use for
> >> instead:
> >>    foreach (int i, char c; a)
> >>    { ]
> >>    In C# you don't have access to the index.
> >>
> >>    C#
> >>    foreach (ElementType element in collection) { // statement}
> >>
> >>    translates into
> >>
> >>    IEnumerator enumerator =
> >> ((System.IEnumerable)(collection)).GetEnumerator();
> >>     try {
> >>     while (enumerator.MoveNext()) {
> >>        ElementType element = (ElementType)enumerator.Current;
> >>        statement;
> >>     }
> >>    }
> >> finally {
> >>     IDisposable disposable = enumerator as System.IDisposable;
> >>     if (disposable != null) disposable.Dispose();
> >> }
> >
> >
>
>
>
> -- 
> Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

inline

Sorry about the long post, I'm just getting pretty annoyed by this (I've tried to stay as calm as possible though.)

In article <opr3qywfq71s9n15@saturn>, SpookyET says...
>
>------------X6GdKj0MKFEpsdf1V7BNYF
>Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 Content-Transfer-Encoding: 8bit
>
>-I want D to succeed, because I want a native C# (since I don't know what mono is going to be, and it always is 2 years behind Microsoft).

D isn't C#; it never will be

>-I want you people to think out of the box!  C# was done by people thinking out of the box.  D has functions, so for those that want to use functions, let them. -I like OO (used functions once), but found OO better.

OO is a way of thinking, not a way of writing, you can write "OO" code without an OO-languge.  Also, generic and functional code is often more reusable than OO code.

>-I want D to have a library like delphi/.net has, full OO and component based (modern design of class libraries). For C++ you have vcf.sourceforge.net

It probably will in time.  C# was made by a company that gave its employees a clear goal.  Walter has no control over what the programmers working with/on D write, so D won't have such an extensive library immediately.  Also, it probably won't be as object based because of the reusability factor.

>-In .NET you can have classes in dlls, D can have them too, no one is forcing you to use the dll format dictated by MS before .NET was arround.

Net however doesn't use true dll's.  If D would make its own dll format, it probably wouldn't be usable by many other languages.  Also, the language isn't Windows specific, and library format is operating system dependant.

>-Becaues C\C++ have been arround for a lot of time, it doesn't mean that it is the best thing and stuff should still be done like that (that is why D has been invented).  Most people use Internet Explorer, is that the best browser? No.

I'd like to think that programs are more informed than the average computer user.  :p but I know this is often not true.

>- D isn't perfect, but it can be close to perfect if you people think out of the box for a minute.

Isn't that the point of making a new programming language: to think outside the box?  If I'm not mistaken, the D community is based on thinking outside the box. Copying another language's features without good reason however is not thinking outside the box.

>- The delegate/event model of C# should be included in D because, it makes it very easy to work with event based programming.

People are already working on modules that have similar functinality.  C++ has the functionality too btw.  And its really not as common a feature as C# would have you believe so why bloat the core language with something that should really be part of the library?

>- Methods/Properties should be PascalCase, it doesn't force you to use _var m_var and other types of decoration.

What's your point?  No one's forcing you to name your identifiers a certain way.

>- Indexers are cool since they allow you to use a class/struct like an array:

D has this already.  Only it's not called an indexer; it's just overloading the [] operator.  (Whoever came up with indexers anyway?  It's nothing different than overloading the [] operator.  The way you overload the [] operator and the way foreach is done (both syntax and adding functionality to a class) are two things inconsistant with the rest of the C# language.  They just seem horribly ugly and not well thought out to me.)

>- Operator overloading: It is easier to use the operators instead of functions (eg: opAdd()) when overloding.

opX() is easier to parse for the compiler.  It makes it a lot easier to write a
D compiler.

>- Attributes: Attributes are super cool and developers should be able to extend the language using attributes.

With my short use of C#, it seemed like attributes were nothing more than a workaround because C# doesn't have multiple inheritence and it didn't have templates.  While D doesn't have multiple inheritence, it has extensive templates, and they seem to remove any need for the C# attributes.

>- C# has nailed a lot of good stuff, they looked at many languages when they made it. So D should have them too.

In other words, you're saying that C# and D took many of the same things into consideration as both C# and D looked at other languages.  D however has another added advantage of being able to look at C# as well.  D also has a much different goal in mind than C# did, so the things the makers of C# looked for might be different than what the makers of D look for.

>- Namespaces and strong named assemblies (with metadata about the types) in dll format.  It is very anoying that you have to use the file system.

I actually agree with you about the file system thing, but I understand its reason for the most part.

>- Learn from .NET, and make D development as easy as it is in .NET.  It currently isn't. It is less complicated than C++ but with the library thing, it is just as worse (eg hard to load dlls, no classes, still, libs, headerfiles. ).

Have you tried it much?  It's really not complicated at all.  I hear the same thing about how much harder something is to do and how it makes it not worth it from many Mac users (who, because of Macs' ease of use, are completely lost when everything isn't presented directly to them)  And easy doesn't always mean good. Look at VB compared to C++.

In article <c19isc$1kqp$1@digitaldaemon.com>, Matthew says...
>
>*You* state that D should go all OO, and yet *you* can offer no evidence to back up your assertion.

of course we all know that D already went OO.
There is no need to go anywhere. it's already there.
(D also supports procedural BTW)

What's missing is a OO lib.

let's end this non discussion. nothing new is being said.

SpookyET made some suggestions, obviously before having
the sufficient contact with D and - seems to me - out of the
enthusiasm for D. He also seems to be quite focused on C#,
to me sounds like a limitation, maybe it's not...

Ant

In article <c19hc7$1h72$1@digitaldaemon.com>, resistor@mac.com says...
>
>
>Point in case: public static void main (String[] args)
>

Here we go again.
that not OO! That one language idea of starting an application.
who told you it was a good idea?

>There is no reason in the world why the main function should be part of a class.

"main function"?
Sorry to say but your mind is already crippled.
Why not call it entry point? or start something?
Why not have a application object?
Java System could be considered an application object.
I wouldn't mind to see a language starting an application
form a subclass of something like the java System class.

>It makes absolutely no sense

Might not be ideal but it works. You are a bit radical aren't you?

> and completely breaks the idea of OO being used to represent OBJECTS.

"completely"? you are completely ...

>
>The point is, then, that there is no need for any sensible language to be as rigidly OO as, say, Java.  Forcing some things in OO is just stupid, and some problems are better off solved procedurally.

I would say supid is to use java if you are not going to do OO.
Java is suppose to help you coding your OO solution for your problem.

>Another example:  I just today what a utility in procedural C to do some statistical analysis on datasets.  There was no need for OO: it just read values, did some math on them, and wrote them back out.  Now, in Java or another rigidly OO system, I would have had to define a class just to stick my procedural function in.  Where is the logic in that?

What's your problem of having an extra set of {}?
You don't have to create a hierarqui of objects to do a simple task.
I don't get your point.
Of course if you are using java for that you are completly...

>
>It is far more useful and flexible, especially for a language like D which claims to be a systems language as well, NOT to rigidly OO.
>

I'm using D rigidly OO, sorry for that...

Ant

SpookyET wrote:

> My target isn't you anyway, it is Mr. Walter Bright.

Matthew is like this groups bouncer (except he can't kick anyone out).  He knows what he's talking about.

-- 
-Anderson: http://badmama.com.au/~anderson/

Is that someone trying to pass themselves off
as "Ant" (antonio) ?
I think he speaks(and spells) a lot better than that.

Phill.

"And" <And_member@pathlink.com> wrote in message news:c19mas$1r6d$1@digitaldaemon.com...
> In article <c19hc7$1h72$1@digitaldaemon.com>, resistor@mac.com says...
> >
> >
> >Point in case: public static void main (String[] args)
> >
>
> Here we go again.
> that not OO! That one language idea of starting an application.
> who told you it was a good idea?
>
> >There is no reason in the world why the main function should be part of a
class.
>
> "main function"?
> Sorry to say but your mind is already crippled.
> Why not call it entry point? or start something?
> Why not have a application object?
> Java System could be considered an application object.
> I wouldn't mind to see a language starting an application
> form a subclass of something like the java System class.
>
> >It makes absolutely no sense
>
> Might not be ideal but it works. You are a bit radical aren't you?
>
> > and completely breaks the idea of OO being used to represent OBJECTS.
>
> "completely"? you are completely ...
>
> >
> >The point is, then, that there is no need for any sensible language to be
as
> >rigidly OO as, say, Java.  Forcing some things in OO is just stupid, and
some
> >problems are better off solved procedurally.
>
> I would say supid is to use java if you are not going to do OO.
> Java is suppose to help you coding your OO solution for your problem.
>
> >Another example:  I just today what a utility in procedural C to do some statistical analysis on datasets.  There was no need for OO: it just read values, did some math on them, and wrote them back out.  Now, in Java or
another
> >rigidly OO system, I would have had to define a class just to stick my procedural function in.  Where is the logic in that?
>
> What's your problem of having an extra set of {}?
> You don't have to create a hierarqui of objects to do a simple task.
> I don't get your point.
> Of course if you are using java for that you are completly...
>
> >
> >It is far more useful and flexible, especially for a language like D
which
> >claims to be a systems language as well, NOT to rigidly OO.
> >
>
> I'm using D rigidly OO, sorry for that...
>
> Ant
>
>