boost crowd.

[Max Samukha]

On 11/28/2011 03:52 PM, so wrote:
> On Mon, 28 Nov 2011 15:34:19 +0200, Max Samukha <maxter at spambox.com> wrote:
>
>> No, it has nothing to do with the IDE. The article describes a visual
>> tool for viewing meta-data stored in a .NET binary. You don't have to
>> use it.
>>
>> Specially for you, die-hard IDE haters, this is how to use the
>> terminal to create a mono app and library:
>
> I started to use vim/cmake "after" years of using IDEs, and one of the
> best if not the best VisualStudio.
>
>> 1. Library:
>>
>> nano lib.cs
>> ----
>> using System;
>>
>> public class Lib
>> {
>> public static void hello() { Console.WriteLine("We don't need no
>> header crap"); }
>> }
>> ----
>>
>> Compile that into a library, lib.dll:
>>
>> dmcs lib.cs -target:library
>>
>> 2. Host:
>>
>> nano app.cs
>> ----
>> class App
>> {
>> public static void Main()
>> {
>> Lib.hello();
>> }
>> }
>>
>> Compile and run the app:
>>
>> dmcs app.cs -reference:lib.dll
>> ./app.exe
>> We don't need no header crap
>
> Now how do you know you have a "Lib", and it implements "hello", what
> rule enforces that?
> If this is all it does, you are overlooking the most important point of
> header files.

Could you clarify what is the most important part? If you want to use a 
library, you would need to read its docs anyway. The interface files 
won't be of much help (D's ones will, since dmd liberally pours 
implementations into them). If the docs are unavailable or outdated, you 
can always extract the declarations from the library:

monop -a -r:lib.dll

lib
Version=0.0.0.0
Culture=neutral
PublicKeyToken=null

public class Lib {
	
	public Lib ();
	
	public static void hello ();
}

Creating separate interface files, taking trouble to push them around 
along with the library and then feeding them to the compiler are 
needlessly redundant steps. Or what am I missing?

>
>> Your information about "serious" programming is a bit outdated.
>
> What i mean by "serious" is that, if you "need" a specific language for
> some task what you are doing is serious.
> Because you are falling back to a less known and probably more complex
> tools/languages, it is much harder to replace you.
> I am still waiting for the next-gen game engine, next-gen video
> decoder/encoder, next-gen ... from those serious languages you mention.
> I am not ridiculing anything, aren't these the facts?

The fact is that apps with tight real-time requirements cannot be 
developed in C# for obvious reasons, and compilation models are 
irrelevant to the fact.

Ok, I am not a C# advocate. I hate it no less than C++ or D. It just 
happens that its compilation model is superior.