OSNews:

Great tips

donotreply@osnews.com (Anonymous) — Wed, 21 Apr 2004 20:30:00 GMT

Thanks for the great tips! Sure they will come in handy, especially that misc-binary thing.

bin_fmt

donotreply@osnews.com (Anonymous) — Wed, 21 Apr 2004 20:48:00 GMT

Bin_fmt is a nice little deal, but I think it can cause problems if you use wine(I don't) because the exe headers are the same. Just a caveat.

re: bin_fmt

donotreply@osnews.com (Anonymous) — Wed, 21 Apr 2004 21:09:00 GMT

Yes, that was explained in the article.

uh

donotreply@osnews.com (Anonymous) — Wed, 21 Apr 2004 21:13:00 GMT

"One thing you cannot do in C is to derive a window class to create your window."

Yes you can. Apps do it all the time. This is the whole point of the GObject system.

re: uh

donotreply@osnews.com (Anonymous) — Wed, 21 Apr 2004 21:20:00 GMT

No, you cannot derive a CLASS. C doesn't has classes. The GObject system is about structures as pseudo-classes.

Some corrections...

donotreply@osnews.com (Anonymous) — Wed, 21 Apr 2004 21:20:00 GMT

Some article corrections...

3rd tip: System.Diagnostics.Process is in the System assembly, not the System.Diagnostics assembly (which doesn't exist).

6th tip: You certainly can create your own Window from C. It's not as easy as in C#, but it is possible. (If it wasn't, then how was GtkWindow declared -- in C -- to be a derived class of GObject?) Object derivation requires that you provide two structures, the instance structure and the class structure. It becomes class derivation when the first instance of these structures is of the appropriate base class type:

struct MyForm {GtkWindow parent; /* other members... */};
struct MyFormClass {GtkWindowClass parent; /* other class members... */};

Other steps will also need to be taken. See: http://www.le-hacker.org/papers/gobject/ch05.html#howto-gobject.

whatever happened to the executable bit?

donotreply@osnews.com (Anonymous) — Wed, 21 Apr 2004 21:22:00 GMT

I always found it anoying having to type mono programname.exe everytime I want to run a .Net program

Me too. But the article didn't explain what to do about it. It still ends in .exe .

RE: Some corrections...

donotreply@osnews.com (Anonymous) — Wed, 21 Apr 2004 21:25:00 GMT

It's not as easy as in C#, but it is possible.

Its not easy to do surgery on yourself in a bath-tub filled with ice while looking up at an overhead ceiling, but its possible.

For some people, though, its just as good as "You can't."

Thank god for C#/Gtk#, or I would never have written GUI-based programs for Linux, ever.

No, that wasn't an attack on you, that was just me being EXTRA witty.

Re: Some corrections

donotreply@osnews.com (Anonymous) — Wed, 21 Apr 2004 21:26:00 GMT

3rd tip: System.Diagnostics.Process is in the System assembly, not the System.Diagnostics assembly (which doesn't exist).

According to Monodoc, and according to my own tests, System.Diagnostics exists, and Process is there.

6th tip: You certainly can create your own Window from C. It's not as easy as in C#, but it is possible. (If it wasn't, then how was GtkWindow declared -- in C -- to be a derived class of GObject?) Object derivation requires that you provide two structures, the instance structure and the class structure. It becomes class derivation when the first instance of these structures is of the appropriate base class type:

I took a look at GObject documentation, and as far as I could see, GObject are not classes, but pseudo-classes based on structures, as Jay Developer said.

RE: whatever happened to the executable bit?

donotreply@osnews.com (Anonymous) — Wed, 21 Apr 2004 21:26:00 GMT

You usually either create a shell script that wraps the binary and mono and you put it on /usr/bin or you tell Gnome to run all .exe files with mono. However, the second solution is not very good if you also have WINE installed.

Web services with Mono

donotreply@osnews.com (Anonymous) — Wed, 21 Apr 2004 21:33:00 GMT

Perhaps a bit off topic, but last week i experimented with some elementary asp.net files on Mono-Linux (i tried both xsp.exe and mod_mono). Especially web services seemed to run very slow in comparison to Asp.net-Windows. Is Mono still missing some important performance code with regard to web services or do i need to tweak it somehow?

gobject

donotreply@osnews.com (Anonymous) — Wed, 21 Apr 2004 21:34:00 GMT

Gobject is an object system with classes, instances, properties, methods, inheritance, signals and slots. It supports everything that is expected from an object system. Can anyone explain what'e "pseudo" about it?
Sure, it's ugly, and proper OO support in the language is much nicer, but the fact remains, you can subclass GtkWindow and it will semantically be exactly the same thing as subclassing in C++/Java/C#/whatever.

I'm not defending GObject, i think it sucks, but's that's no reason to spread lies about it, no?

re: gobject

donotreply@osnews.com (Anonymous) — Wed, 21 Apr 2004 21:38:00 GMT

I meant "pseudo", not as an insult, but as a way of saying that those "classes" are not based on the language direct support, but on using some kind of workaround. I'm not trying to say they don't work, or that they do not provide all the features classes are supposed to.

re:re: gobject

donotreply@osnews.com (Anonymous) — Wed, 21 Apr 2004 21:52:00 GMT

Hi

You should be aware that pseudo actually means false. Gobject is very much a existing useful system and thats the only way c could have object oriented mechanisms for gtk+

What?

donotreply@osnews.com (Anonymous) — Wed, 21 Apr 2004 21:56:00 GMT

Jesus Christ! you can derive classes in Fortran if it has a proper object library. Has it occured to the author that GTK+ is an object oriented library written in C?

I mean to say, before C#/GTK# were ever conceived, GTK+/C/gobject had support for classes, methods, slots, signals, inheritance etc.

And what on earth is psuedo classes? If there is anything psuedo about languages, it is the level of abstractions present in object oriented languages. Classes in object oriented languages are a combination psuedo structures, psuedo function pointers and psuedo pointers to structures.

In fact, fundamentally, a class is refined data structure. Any C programmer worthy of typinp on keyboard should be able to implement classes in raw C, using data structures and pointer functions. Which, essentially, if how the gobject library was designed if memory serves me right.

Oh boy, I feel bad for the next generation of programers. I mean, do I really need to tell a programer that object orientation is just an abstraction model and that you can write a project in an OO pattern in any language?

Sure C# makes it easier and cleaner to write GUIs, but I think it is important that programmer really understand what OO is, and frankly it is more of an ideology than a characteristic of a language.

Yes, you can derive window classes in C.And GTK+ makes it easy to do so.

re: gobject, @Anonymous (IP: 61.95.184.---)

donotreply@osnews.com (Anonymous) — Wed, 21 Apr 2004 21:56:00 GMT

That's the problem: language. In Portuguese, pseudo actually may mean something else, like "almost". In fact, it can mean from "false" to "disguised", not forgetting the "apparent" and "look-alike".

@Jay

donotreply@osnews.com (Anonymous) — Wed, 21 Apr 2004 21:58:00 GMT

Ok, fair enough. "Pseudo" is a vauge word.

Regarding the speed of Mono. How fast does it run today? Do they expect to reach performance parity with commercial VMs anytime soon? Reading the white papers from sun on their HotSpot VM makes it clear that creating a high performance optimizing VM is no small feat. It took them several years and lots of skilled developers to reach where they are today. And it still suffers from poor startup performance and excessive memory use, although perfomance is pretty impressive.
The CLR is different from java in a number of ways, but the fact remains: dynamic optimization is tricky, to say the least.
AOT compilation helps with the memory consumption and startup performance, but languages as high-level and relatively dynamic as Java/C# needs dynamic optimization to be competitvie with C/C++, performance-wise.

Re: Web services with Mono

donotreply@osnews.com (Anonymous) — Wed, 21 Apr 2004 22:04:00 GMT

Especially web services seemed to run very slow in comparison to Asp.net-Windows. Is Mono still missing some important performance code with regard to web services or do i need to tweak it somehow?

Yes. Natively compiled code . Microsoft has hyped runtime code, but they cheat by making pseudo-x86/COM/CLR binaries - and they tend to do this whether they are managed or not. Microsoft cheats, and the Mono people have fallen for the .NET/CLR hype. It is not fast enough for a lot of applications.

The web services bits in Mono are probably very experimental at this stage. They are concentrating on other things.

@root

donotreply@osnews.com (Anonymous) — Wed, 21 Apr 2004 22:20:00 GMT

This irrational fear of high-level programming constructs is ridiculous. C programmers limit themselves completely unnecessarily. Would you want to:

- Implement multimethod dispatch in C? Do you think your one-off algorithm would run anywhere near as fast as an optimized dispatch? Don't think you need multimethods? Ever use visitor pattern?

- Implement dynamic typing in C? Do you think your performance will be anywhere near as fast as what you can get when you have a good type-inferring compiler? Don't think you need dynamic typing? Ever used a union of different pointer types?

- Implement lambdas in C? You're into "generate machine code in C-strs" here. Do you think it'll perform anywhere near as fast as it does when you have a closure-optimizing compiler? Don't think you need lambdas? How many one-off callbacks do you have? How many nested loops?

- Hand-expand macros? Back to generating machine code here. Don't think you need macros? Do you *like* manually writing code to (say) parse an XML DOM tree?

- Implement predicate dispatch? Pattern matching? Do you realize how much your performance will suck without a compiler that optimizes those predicates? Don't think you need predicate dispatch? How many huge 'if...else' trees do you have in y our code?

- Manually perform storage-use optimizations? Manually generate copy-down methods? C generic data structures are much slower as a result of having to deal with everything via void*, and having to use function pointers for predicates.

- Implement inheritence? Limited types (constrained types)? Union types? Product types? Type constrained variables? Do you know how much your performance will suck compared to a language that has a proper class-hierarchy optimizing compiler? You've already admitted you need inheritance. Oh, how much does your performance suck when you don't have an optimizing compiler to optimize-out all those indirect function calls?

These days, its only moderately useful to understand what's going on at the machine level. The C abstract machine looks nothing like a modern processor anyway. Its completely silly, however, to *program* at the machine level. Especially when the end-result is likely to be slower than letting a near-omnipotent optimizer beat the code into shape.

Programs must be written for people to read, and only incidentally for
machines to execute.
--Abelson and Sussman

re: OO in C

donotreply@osnews.com (Anonymous) — Wed, 21 Apr 2004 22:24:00 GMT

If you want to implement OO in C you don't use function pointers, unless you want per-instance methods, and neither C++/Java/C# supports that (highly dynamic languages as Python and Ruby does). I think this misconception is based on the fact that in C++, methods look exactly like function pointer struct memebers, but they aren't.
You use a per-class table where you look up the right method, and invoke it. Imagine you have a class with one instance variable (an integer, 4 bytes), and 20 methods.
With per-object function pointers, each instance of that object would occupy 84 bytes!! In C++, the pointers would be stored in a per-class table (the vtable), and the object would occupy 4 bytes for the integer, plus a couple of bytes overhead (depending on the situation, at least 4 bytes for the pointer to the vtable).
That's a 10x difference, now wonder that most languages don't have per-instance methods.

Re: Re: Some corrections (System.Diagnostics assembly)

donotreply@osnews.com (Anonymous) — Wed, 21 Apr 2004 22:29:00 GMT

Don't confuse the assembly and the namespace.

The System.Diagnostics.Process class lives in the System.Diagnostics namespace, and in the System.dll assembly.

From Monodoc:

Namespace: System.Diagnostics
Assembly: System 1.0.3300.0 (in System.dll)
Culture: neutral

Remember: assemblies are the units of packaging (.dll, .exe, etc.), and namespaces are to save us from typing long names all the time. :-)

Re: Jonathan Pryor

donotreply@osnews.com (Anonymous) — Wed, 21 Apr 2004 22:35:00 GMT

Sorry. My confusion.

Re: whatever happened to the executable bit?

donotreply@osnews.com (Anonymous) — Wed, 21 Apr 2004 22:40:00 GMT

It sounds like your complaint isn't about the lack of the executable bit, but of the presence of the .exe extension.

You're in luck: the file extension isn't necessary. mono my-program doesn't require the file extension, and neither does ./my-program (with binfmt_misc set up properly). Such is the joy of Unix file sniffing for file type detection. Yay.

However, removing the extension limits portability. One of the nice properties of CLI assemblies is that they can (in theory) run unchanged between Linux and Windows (and other operating systems Mono supports). If you remove the extension, then other operating systems (Windows) might not recognize the file type, rendering the program useless until it's renamed. So that we can easily copy programs between platforms, we continue to use the .exe extension.

As Eugenia pointed out, shell scripts can also be used, so Unix users get the extension-less program names, and Windows users can continue with their blissful existence. :-)

@Rayiner Hashem

donotreply@osnews.com (Anonymous) — Wed, 21 Apr 2004 22:46:00 GMT

What on earth are you babbling about?
If you really knew what you where talking about you would know that:
* Type inferring has nothing to do with dynamic typing.
* Parse a DOM tree? Do you even know what the DOM is? If you can point me to a parseable DOM tree i will gladly make a parser in assembly for you . If you mean an XML document you should say so. No one refers to an XML document as a DOM tree, especially when one means it as an input to a parser.

What language are you talking about anyway? What language has multimethods, dynamic typing, type inference, lambda expressions, a macro system, pattern matching, inheritance, constrained types, product types etc...Haskell? Wouldn't classify that as faster than C, not even close. Maybe faster than python.

Avoir binfmt_misc use zsh

donotreply@osnews.com (Anonymous) — Wed, 21 Apr 2004 22:55:00 GMT

In latest zsh on a shell level you can associate executable simply like :

alias -s .exe "mono"

exe

donotreply@osnews.com (Anonymous) — Wed, 21 Apr 2004 22:57:00 GMT

bah. i've built myself a microsoft-free existance, but the walls are starting to crack.
now i'm going to build a development platform and design myself a next-generation language with C-based syntax. see you all in 15 years.

@Rayiner Hashem

donotreply@osnews.com (Anonymous) — Thu, 22 Apr 2004 00:25:00 GMT

This irrational fear of high-level programming constructs is ridiculous. C programmers limit themselves completely unnecessarily. Would you want to:

What irrational fear? I don't fear using high-level programming constructs, it's just that 90% of them have no practical uses.

- Implement multimethod dispatch in C? Do you think your one-off algorithm would run anywhere near as fast as an optimized dispatch? Don't think you need multimethods? Ever use visitor pattern?

I've never used a visitor pattern. In what application is it normally used and how?

- Implement dynamic typing in C? Do you think your performance will be anywhere near as fast as what you can get when you have a good type-inferring compiler? Don't think you need dynamic typing? Ever used a union of different pointer types?

For the love of God, why would I want dynamic typing in C? And no I have never had to use a Union of different pointer types. How and when is this applicable?

- Implement lambdas in C? You're into "generate machine code in C-strs" here. Do you think it'll perform anywhere near as fast as it does when you have a closure-optimizing compiler? Don't think you need lambdas? How many one-off callbacks do you have? How many nested loops?

I really don't know. I haven't carried out any benchmarks so I can't speculate. Also compiler optimization isn't my forth. But on average, C code is usually faster than many higher level languaged generated code, irrespective of the implementation facilities of lambdas in C. And C compilers are a lot more mature and generate faster code than any other language I know that implements lambdas.

- Hand-expand macros? Back to generating machine code here. Don't think you need macros? Do you *like* manually writing code to (say) parse an XML DOM tree?

Is that even possible?

- Implement predicate dispatch? Pattern matching? Do you realize how much your performance will suck without a compiler that optimizes those predicates? Don't think you need predicate dispatch? How many huge 'if...else' trees do you have in y our code?

So, say, I write a pattern matching algorithm in Perl, and one in C, are you insinuating that the Perl code will undoubtedly be faster than the C code? You need to specific with your accounts and provide practical instances where C code clearly sucks in pattern matching or predicate dispatch.

- Manually perform storage-use optimizations? Manually generate copy-down methods? C generic data structures are much slower as a result of having to deal with everything via void*, and having to use function pointers for predicates.

Your sources and benchmarks are welcome. Until then, I hold your statements as unproven theories.

- Implement inheritence? Limited types (constrained types)? Union types? Product types? Type constrained variables? Do you know how much your performance will suck compared to a language that has a proper class-hierarchy optimizing compiler? You've already admitted you need inheritance. Oh, how much does your performance suck when you don't have an optimizing compiler to optimize-out all those indirect function calls?

I don't really see the performance hits you are clamoring about. In my experience languages that have all these properties built in are much slower than C which doesn't. Which performance hit are we talking about? What applications suffer from all these performance hits? Where are your benchmarks?

These days, its only moderately useful to understand what's going on at the machine level. The C abstract machine looks nothing like a modern processor anyway. Its completely silly, however, to *program* at the machine level. Especially when the end-result is likely to be slower than letting a near-omnipotent optimizer beat the code into shape.

I disagree with you. It is very useful to understand what is going on at the machine level. You learn to write optimized and efficient code, and you actually have a thorough knowledge of what your code is doing at every stage. This skill is excellent for optimizing, debugging, maintanance and trouble shooting your code. Which is 90% of what you'll be doing in your coding career anyway. Ultimately, the errors your debuggers, optimizers, profilers, memory tools spit out are more often than not machine code jargon.

I also disagree that coding at the machine level is slower and less optimized than coding at a ridiculously abstract level. In fact, I don't know where you get that notion from. If that was so, we all be writing out drivers, kernel, compilers, higher level languages and libraries in Python.

Finally, I don't consider C to be a machine level language. In my opinion, it is a high level language, that people can read. I have no fear in using higher level languages, many of the features present in higher level languages are useless to me. Just like Microsoft Office, 95% of the feature available in it are absolutely useless to me.

Data structures, variables and methods/functions, that's all what programming is about, every other feature academic verbosity and needless complexity.

WTF?

donotreply@osnews.com (Anonymous) — Thu, 22 Apr 2004 01:35:00 GMT

What the hell is everybody's problem with Mono programs ending in .exe? Guess what, it's part of the .NET spec. In reality this is no different than putting a .py, .pl, .ru, .c, .cpp, or .sh at the end of a file. I like the idea of Mono programs ending .exe with the only issue being that it is difficult to distinguish between apps that Wine should execute vs. apps that Mono should execute.

Mono performance.

donotreply@osnews.com (Anonymous) — Thu, 22 Apr 2004 01:44:00 GMT

Hello,

Mono performance is fairly good. In general, you get much better performance from CLI-based systems because they fixed
a few design issues in the VM that have a big impact on performance (for example having valuetypes, default virtualization mode for methods, etc).

So, yes, HotSpot is a terrific JITer, but the good news is that Mono can give a reasonable JIT speed (70-80% of it) with 30% of the work. With more full time JIT hackers coming on board that gap should close pretty quickly.

At to Web Services: our support is fairly good, it has gone through extensive testing, no need to spread fear and doubts. Am sure there are still some unresolved issues (like with any other piece of software), but am confident that we can solve those.

Miguel.

@Fredrick

donotreply@osnews.com (Anonymous) — Thu, 22 Apr 2004 03:39:00 GMT

* Type inferring has nothing to do with dynamic typing.

Type inferencing is a method, in dynamically typed languages, of increasing the performance of dynamically typed code. The compiler uses a type-inference algorithm to determine what method calls can be bound statically. Unlike type-inferencing in static languages, it is not fully complete --- ie. when type inferencing fails, it falls back to dynamic typing, rather than failing altogether. Now, when you fake dynamic typing in C (via void* and tagged unions), you don't get the advantage of the compiler doing this for you.

* Parse a DOM tree? Do you even know what the DOM is? If you can point me to a parseable DOM tree i will gladly make a parser in assembly for you .
Don't be childish. Of course I know what a DOM tree is. An XML-DOM parser will spit out a DOM tree after parsing an XML file. Usually, the DOM tree itself is rather unweildy to use. Thus, it is usually parsed into some internal program representation. This is precisely the step Xen tries to automate. Well, you can do the same thing with macros, too.

What language are you talking about anyway? What language has multimethods, dynamic typing, type inference, lambda expressions, a macro system, pattern matching, inheritance, constrained types, product types
Not a specific one. I wasn't actually trying to push a specific language, just to juxtepose high-level languages against C. Dylan and Common Lisp have everything on that list except product types and pattern matching (though you can fake pattern matching with macros to a great degree). Haskell has everything except the macro system, dynamic typing, and multimethods. The new Nemerle language for .NET has most of these features too.

@root

donotreply@osnews.com (Anonymous) — Thu, 22 Apr 2004 04:46:00 GMT

I've never used a visitor pattern. In what application is it normally used and how?
What kind of code do you write? Visitor pattern is pervasive in many classes of programs. Any time you need to dispatch on the type of more than one variable (eg: a game engine where you need to compute intersections between triangles and circles, circles and squares, etc, etc), you end up using visitor pattern, or some logicallly degenerate case of it. Multimethods make the visitor pattern completely unnecessary.

http://exciton.cs.oberlin.edu/javaresources/DesignPatterns/VisitorP...

For the love of God, why would I want dynamic typing in C? And no I have never had to use a Union of different pointer types. How and when is this applicable?
Again, what kind of programs do you write? This is *very* common in C programs. Look at the definition of XEvent in Xlib.

http://tronche.com/gui/x/xlib/events/structures.html

Its a type tag plus a union of all the possible sub-structures. This is a shoddy, error-prone way of faking dynamic typing.

Is that even possible?
Remember the articles about Xen? Instead of writing a whole bunch of functions to turn your DOM representation into your own internal tree of objects, you can use syntax extensions to C# and have the compiler automatically generate the parser. Well, you can do the same with macros, and you don't have to hack support for a specific language into the compiler.

So, say, I write a pattern matching algorithm in Perl, and one in C, are you insinuating that the Perl code will undoubtedly be faster than the C code?
Obviously, you don't know what pattern matching means in the context of programming languages. Look it up.

I don't really see the performance hits you are clamoring about. In my experience languages that have all these properties built in are much slower than C which doesn't. Which performance hit are we talking about?
What languages are you experienced with? Perl and Python are not in the same target market as C. Lisp, ML, Scheme, and Dylan are. These languages will get you very close to C in performance:

http://www.bagley.org/~doug/shootout/index2.shtml (see the Ocaml results, in particular).

Doug's benchmarks don't take into account advanced usage, so the result is skewed towards C, but high-level languages make a very good showing. In practice, good developers in these languages get over 80% the performance of C.

I disagree with you. It is very useful to understand what is going on at the machine level.
Then read up on processor architecture. C tells you nothing about what the machine is doing under the hood. Modern architectures are nearly as alien to the C machine model as they are to the Lisp machine model. And most experienced Lisp, et-al developers have a good understanding of what their code is doing at the C-level, because they are familiar with their compilers. They don't need to actually *program* at that level the whole time to get that understanding.

I also disagree that coding at the machine level is slower and less optimized than coding at a ridiculously abstract level. In fact, I don't know where you get that notion from. If that was so, we all be writing out drivers, kernel, compilers, higher level languages and libraries in Python.
Python is a terrible example. Its not even natively compiled! Languages with native compilers (Lisp, Scheme, Dylan, ML, among others) are much faster, and much closer to C.

I'm not saying that you cannot get C code to run faster than the equivilent Lisp, et-al code. You can go really low-level with C. However, the time-investment required for that level of optimization is ridiculous.

Consider: when you've got a dynamic type (eg: the XEvent structure), do you generate hand-optimized functions for each possible case? Do you use generic list functions (based on void*), or do you have hand-written list-functions optimized for each type? I highly doubt it. Hell, even the Linux kernel doesn't do that!

The point is, a high-level language compiler has a lot more freedom to optimize, because it has more information (by definition, 'high level'), and because it doesn't have to deal with the weaknesses of the C memory model (basically, the memory representation of objects must be determinate, which rules out huge classes of optimizations). The type of tricks GTK+ uses to fake object-orientation (weakly typed pointers, lots of casting, indirect calls via function pointers) are precisely the cases where a C compiler will *always* pay the cost of dynamism, wheras a more advanced compiler will be able to optimize most of it away.

The end result is that while in the optimal case, C code will be faster, in the general case, the code from a high-level language compiler will usually be faster. See:

http://www.algo.be/cl/TEE-lisp/31837187622993390/index.htm

The basic result was that the median C++ program was much slower than the median Lisp program, even though the fastest C++ program was faster than the fastest Lisp program. This is because developers are not all superhuman, and when you have a mix of programmers of different capabilities, you can't do the sorts of manual optimization C programmers have to do.

Data structures, variables and methods/functions, that's all what programming is about, every other feature academic verbosity and needless complexity.
If you think that, no amount of argumentation will persuade you. We cannot see eye-to-eye. I know both C/C++ and Lisp, while you apparently have no real experience with the latter. I suggest you go learn Lisp. Until then, consider this: coding in Lisp (or Dylan or Scheme, or ML if you like static typing) is a lot like coding in Python. Its really fast and really productive. At the same time, advanced compiler technology means that its also results in very fast code. You can see, then, why I consider these languages to be much better than C for application development.

RE:Miguel de Icaza

donotreply@osnews.com (Anonymous) — Thu, 22 Apr 2004 05:07:00 GMT

Congratulation to all of you who are involve in MONO development. What a nice piece of development. Hope MONO will sucess in archieving its goal.

GTK# is cool, but

donotreply@osnews.com (Anonymous) — Thu, 22 Apr 2004 13:47:00 GMT

it needs to be taken one step further into a true RAD environment similar to Delphi.
Kylix was a good try, but the deployment issues where insane.
If monodevelop adds a nice GUI forms builder similar to CSharpBuilder on windows we could see a explosion of apps for Linux.

@snorkel

donotreply@osnews.com (Anonymous) — Thu, 22 Apr 2004 14:06:00 GMT

The supposed skinny on a gui builder for MonoDevelop is that glade isn't the best solution because of issues with custom controls or something. Supposedly, a new gui builder is going to be done, but hasn't been started and obviously will be a while before it's done. It won't be specific to gtk#.

question...

donotreply@osnews.com (Anonymous) — Thu, 22 Apr 2004 18:45:00 GMT

Not being an expert concerning the legal issues surrounding Mono, could someone help me understand why they think Microsoft will allow Mono to coexist alongside their proprietry implementation. I understand the main argument is that the CLI and the C# language is standardised through the ECMA, but given that one of Microsoft's executives recently stated that:

'We'd have been dead a long time ago without Windows APIs' [ref: zdnet.co.uk]

Why is anyone in doubt that Microsoft would permit their lock-in to be diluted with a free, open equivalent? Microsoft can't be daft enough to hand as much power to the open source community without having something else up it's sleave.

Just a question from someone not very knowledgeable about Mono.

Steve

@Rayiner Hashem

donotreply@osnews.com (Anonymous) — Thu, 22 Apr 2004 21:16:00 GMT

What kind of code do you write?

I write all sorts of embedded software.

You confuse me by unrestrictedly interchanging object oriented jargon in higher level languages with those of procedural languages. For example, when you say, "Union of different pointers," it would have made a lot more sense if you just said type definitions or typdefs.

So also is your definition of high level languages. Some languages have been relegated to the realm of the academic sphere. Who uses Scheme, Dylan, ML, Lisp, etc for general purpose stuff? Only hobbyist and academic scholars care for those languages. In practice and reality, C, C++, Java, Python, Perl, C# are the languages used by majority of the professional software vendors. Not Lisp, Dylan, Ocalm, ML or your niche programming languages.

I've had no practical experience with Lisp. I learnt lisp on my own as an academic pursuit. It's a great language, but I have never been compelled to write one single application in it. This is not a feature fest contest, or best language contest. It is about what is practical and relevant.

You might consider Lisp great for application development, I don't. Compared to other languages like Java, C#, Python, C or C++, how many specialized APIs does Lisp have? Can I write GTK+ applications in Lisp? How about low level code? Do software vendors provide API bindings in Lisp? How many programmers actually know Lisp as compared to C/C++/Java/C#? Are there opengl bindings for lisp? How many hardware platforms can Lisp run on?

Lisp is a great language, but great languages don't necessarily make good applications or practical usage. Nothing has convinced me to write a single application in Lisp and I know the same is true for many other programmers who know Lisp. That's because I don't care for the language or compiler advancement itself, I care for the development platform and practical usage. Lisp is not practical for me to use.

Your software vendor would have to be drunk to tell you to code their next big project in Lisp. Who will maintain it 5years from then when you've left? What is the demand for Lisp programmers? I'm sorry, as much as I like Lisp, it doesn't qualify as a practical general purpose language and the same goes for Ocaml, Scheme and Dylan.

As for the languages I know. I know C, Fortran, Forth, C++, Perl, Pyhton, Bash, Java, C# and Lisp. For most of the work I do I use C and occasionally C++. If I ever get interested in application development, I wouldn't be using Lisp, Scheme, Dylan, or Ocaml either. With outstanding development frameworks like .NET/Mono, why should I? And since I'm quite versed in C and C++ I'd be better of using GTK+ to write my higher level applications anyway, if I have the need to.

And once again, I see no performance hits with many GTK+ applications despite the fact that it is object oriented C. According to your postulations, GCC isn't smart enough to optimize GTK+ applications because of inherent weaknesses in C's memory model and also because of it's fake object system. My experience has been the opposite. I see no performance penalties in GTK+ object system. In fact, up until recently, GTK+ applications were small, fast and efficient. I remember clearly that GTK1 apps in particular where faster and smaller than apps written in object oriented languages.

The same holds true today too. GTK+2 albeit slower than GTK+1 apps still are still smaller and faster than comparable applications written in object oriented languages and I'm yet to see visible performance hits as result of GTK+ doing object orientation in C. I don't buy theories anymore, give me practical instances where object oriented C applications suck terribly as compared to the ones written in Lisp, Dylan, Ocaml and Scheme, then I would shut up.

@Stephen Henry

donotreply@osnews.com (Anonymous) — Thu, 22 Apr 2004 22:06:00 GMT

There's a couple issues involved in the legalties of Mono.

Most likely ECMA 335 and 336 are clear if someone can confirm that it's Royalty Free.

The other issue concerns the APIs that are not covered by the ECMA specs. These APIs mostly cover ASP.NET, ADO.NET, windows forms, and some microsoft-specific apis. These aren't a necessity for open source systems. Most of these will be implemented, but can be backed out if necessary.

Another thing you can look at is why hasn't Microsoft gone after Wine, Crossover, etc... yet? I guess one answer is that they don't pose a threat to microsoft...yet. The other answer could be that there still seems to be a question regarding the patentability of APIS. Remember, Mono is a clean-room implementation of the APIS. They're not ripping off Rotor code.

If Gnome were to choose Mono as a standard runtime and didn't use any of the non-ecma apis then they would probably be in the clear. In reality though, people like Havoc Pennington don't care if ecmca 335 and 336 are royalty-free. People like him hate Mono because the tech was invented by Microsoft. So Gnome will probably continue along the path of cobbled together, home-grown crap that will take years to implement, will be buggy as hell, and most developers just won't touch it.

Don't get me wrong, I like Gnome - I'm using it as my primary desktop, but Miguel de Icaza choosing c over c++ for the Gnome language was just a bone-headed move plain and simple. It's no secret that he does not like C++, but because of his personal preferences and not technical merit he chose to use a language that isn't suited for desktop development.

@root

donotreply@osnews.com (Anonymous) — Thu, 22 Apr 2004 22:10:00 GMT

Like most Lisp people, Raynier just can't help himself from not doing a little Lisp advocacy when the subject of computer languages come up. Lisp people just can't get it through their head that Lisp is fine as a research language, but it had 40 years to prove itself as a mainstream language and never did. If you read some of the Lisp mailinglists you would think that all programming problems would have been solved years ago if everybody has been using Lisp. It's just a way for certain people to see themselves as elite.

Parasit project..

donotreply@osnews.com (Anonymous) — Thu, 22 Apr 2004 22:17:00 GMT

Why "/opt/gnome/bin/mono"??

One more time, Mono is NOT GNOME!!!!
I know the Mono developers want it, but please.. Mono is NOT GNOME!!

Some times I think that Mono is a parasit project

Re: Parasit project..

donotreply@osnews.com (Anonymous) — Thu, 22 Apr 2004 22:29:00 GMT

That's where I DECIDED I would install it... It's where I install all Gnome and Ximian stuff.

Not in any way the default install path.

@root

donotreply@osnews.com (Anonymous) — Thu, 22 Apr 2004 22:32:00 GMT

I write all sorts of embedded software.
I suppose it depends on the precise sort of embedded software you're talking about. There are places where I would agree that C isn't a huge hinderence (writing an FFT, for example). However, I also write embedded code (probably completely different --- we've got radios with hundreds of megs of RAM where I would have loved to have more than the spartan feature-set of C++ available to me.

So also is your definition of high level languages. Some languages have been relegated to the realm of the academic sphere. Who uses Scheme, Dylan, ML, Lisp, etc for general purpose stuff?
This discussion was not about what is a practical language for a particular project. This discussion was in response to:

"Oh boy, I feel bad for the next generation of programers. I mean, do I really need to tell a programer that object orientation is just an abstraction model and that you can write a project in an OO pattern in any language?"
You essentially said: "language doesn't matter, concepts do." My point was that language *does* matter, because it can make it orders of magnitude easier to implement certain concepts. This discussion is about an entirely abstract subject --- we're not talking about practical implementation here.

Can I write GTK+ applications in Lisp? How about low level code?
Yes.

Do software vendors provide API bindings in Lisp?
Some do, some don't.

How many programmers actually know Lisp as compared to C/C++/Java/C#?
Not enough. But that's not as huge a hurdle as one might think. There are a lot of situations where having a small team of highly-skilled developers is better than having a large team of commodity programmers. In these situations, it is easy to add the constraint that the programmers know some suitable high-level language. Several corporations understand that using a better language can be great for productivity, even if it limits your available developer pool. Ericsson, for example, uses Erlang throughout its enterprise. How many Erlang programmers are there compared to C++ programmers?

Are there opengl bindings for lisp?
Yes.

How many hardware platforms can Lisp run on?
The best free Lisp (SBCL), runs on Alpha, PowerPC, x86, and SPARC, and MIPS. It supports FreeBSD, Solaris, NetBSD, OpenBSD, and MacOS X. A Windows port is in the works. Commercial Lisps run on a wide range of architectures (including Windows). A good Windows commercial Lisp can be had for $250 (Corman).

And once again, I see no performance hits with many GTK+ applications despite the fact that it is object oriented C. According to your postulations, GCC isn't smart enough to optimize GTK+ applications because of inherent weaknesses in C's memory model and also because of it's fake object system.
You wouldn't. Language speed has almost no impact on GUI performance. That's why Python makes a perfectly good GUI language for most tasks. If you wanted, however, to use high-level OO constructs in speed-critical, you'd see these performance hits. Lisp has been used on popular PS2 games (Jak and Daxter), to make development easier without affecting performance.

See, C programmers have this attitude about C: they have very fast code most of the time, and if they want to use high level (read: productivity-enhancing) features, they can always roll their own. Except for certain problem domains (your's would probably qualify, though), this is precisely backwards. You want those high-level features to improve productivity, and want to be able to code in a low-level way for that 1% of each program that needs it. Thus, its better for overall performance when you can let the optimizer deal with that other 99%, and give your full attention to that 1% that needs it.

@Lumbergh

donotreply@osnews.com (Anonymous) — Thu, 22 Apr 2004 23:33:00 GMT

Like most Lisp people, Raynier just can't help himself from not doing a little Lisp advocacy when the subject of computer languages come up.
I'd love to see how you came to that conclusion, given that I didn't even mention Lisp in my original post! When it did come out, it was in the context of talking about compiler optimizations. Lisp is where a lot of the research on high-level optimizations focused on.

I also find it interesting that I mentioned ML and Dylan a great deal too, because they were relevent in talking about compiler optimizations. The fact that you latched onto the "Lisp" in that list of languages says more about you than it does about me.

Look: I make it a point to not insert random Lisp plugs into discussions. When I do mention it, it is because it is relevent to the topic at hand. For example, in this discussion, I mentioned it because I wanted to show root the downsides of having to roll your own high-level features in C. I mentioned it before in reference to Xen, because Lisp macros serve as a much cleaner way to implement domain-specific-languages. And I feel obliged to mention it whenever somebody claims Java and C# are innovative, because that is just simple misinformation.

Lisp people just can't get it through their head that Lisp is fine as a research language, but it had 40 years to prove itself as a mainstream language and never did.
Why do you think that is? I have yet to see a convincing technical argument on this point. Nearly always, the argument descends into "Lisp is a great language, but..."

@Lumbergh

donotreply@osnews.com (Anonymous) — Thu, 22 Apr 2004 23:39:00 GMT

This is clearly flamebait, but if Lumbergh gets to read it before it gots modded down, I'm happy:

Lumbergh: I find it highly interesting that in the Novell Mono thread, the *only* person to mention Lisp was *you*.

@Raynier

donotreply@osnews.com (Anonymous) — Fri, 23 Apr 2004 01:21:00 GMT

Lumbergh: I find it highly interesting that in the Novell Mono thread, the *only* person to mention Lisp was *you*.

There are at least 3 mentions of Lisp in your second @Root post, and at least one mention of Lisp in your @Fredrick post before I even showed up on this thread. Try again. It seems that your Lisp advocacy is so engrained that you don't even remember when you mention it.

@Lumbergh

donotreply@osnews.com (Anonymous) — Fri, 23 Apr 2004 01:33:00 GMT

Try reading my post again. Does this *look* like the Novell Mono thread to you? It seems that your anti-Lisp reactionism is so engrained that you forget how to read when you see "Lisp" in a sentence.

Also, note that Lisp in pretty much every instance in this thread, Lisp is mentioned only as one of several languages that have advanced compilers. Why aren't you calling me an ML fanboy?

@Raynier

donotreply@osnews.com (Anonymous) — Fri, 23 Apr 2004 01:39:00 GMT

Don't you find it interesting that Root's reply to you concentrated mainly on the comparison of Lisp to other mainstream languages when you supposedly never mentioned Lisp. Remember, I was responding to Root. It just happens that I noticed your mention of Lisp several times in previous posts and I'm well aware of your Lisp advocacy in other threads.

@Lumbergh

donotreply@osnews.com (Anonymous) — Fri, 23 Apr 2004 01:45:00 GMT

Obviously, you still don't get it. I never said I didn't mention Lisp in this thread. I said I never mentioned it in the thread about Novell and Mono a few days back. *You're* the one you brought up Lisp. And I wasn't comparing Lisp to meanstream languages. I was saying that high-level languages give the optimizer much more room to work, and using Lisp, ML, and Dylan for real-world examples. I would have used C#, but no C# compilers have those sorts of optimizations!

@Raynier

donotreply@osnews.com (Anonymous) — Fri, 23 Apr 2004 02:37:00 GMT

Ok, when you referred to the Novell/Mono thread I didn't realize you were talking about a previous thread because that thread wasn't really about Mono and I was replying to the idiot that claimed "why doesn't open source come up with something better", as if it's just a matter of a couple weekends and a sourceforge page to come up with some kind of managed environment that will compete in the mainstream of .NET and Java.

I referred to your comment about open-source already coming up with something better over 10 years ago and then cited examples that I wanted you to reply to since you didn't give any of your own. I threw Lisp into that mix because you invariably bring up Lisp in language discussion.

I stand by comments in the previous thread that if open source had come up with something so much better 10 years ago then it would be in wide-spread use today. There's more to development then just the language itself. There's the API's, developer tools, Docs, the ability to integrate with the native os easily, gui bindings.... The bandwagon effect is even important, because as a developer you want to be assured that the supporting cast for the runtime/language will continue to be developed, debugged, improved upon. And usually that takes some sort of organization with a lot of resources to guarantee that....probably one of the reasons why Qt (developed by a commercial company with full-time developers) is so much better than gtk+, even when you factor out that c++ is just a better language for gui development.

Listen, I have nothing against the language Lisp. I'm sure it has interesting features that more mainstream languages can use if they choose. Most of my experience with a lisp-derived language is in scheme while studying "Structure and Interpretation of Computer Programs". But as my previous reasons stated there's a lot more to using a language effectively then just the language proper. And you have to admit that _historically_ Lisp has had speed issues.

Anyway, I might go emerge some variant of Lisp to play around with tonight and check out some tutorials to see what the elitists are always clamoring about. What version of lisp would you recommend that has decent libraries and is an easy introduction to some of the more interesting features of Lisp?

@Lumbergh

donotreply@osnews.com (Anonymous) — Fri, 23 Apr 2004 03:32:00 GMT

I stand by comments in the previous thread that if open source had come up with something so much better 10 years ago then it would be in wide-spread use today.
"Better" does not necessarily lead to popularity. There are lots of "better" technologies that died because of market reasons.

There's more to development then just the language itself. There's the API's, developer tools, Docs, the ability to integrate with the native os easily, gui bindings....
I'd say that's more a matter of "more practical" then "better." "Better" to me means technically better, better in the abstract. I would never call C# better than Lisp, but I'd be the first to admit that there are many cases where it is more suitable, because of its market support and huge library.

In any case, neither of these conversations has been about "better." The last one was about innovation (Lisp had the features first), and this one was about availability and optimization of high-level features.

And you have to admit that _historically_ Lisp has had speed issues.
Maybe. Good native Lisp compilers came out with MacLisp in the 80's. Their primary user was the Macsyma project, who used it for numerical code. They managed to get Lisp code to run nearly as fast as FORTRAN.

What version of lisp would you recommend that has decent libraries and is an easy introduction to some of the more interesting features of Lisp?
Clisp for playing around, SBCL for industrial-strength stuff. DrScheme is a good intro environment, but its Scheme rather than Common Lisp. As for libraries, check dev-lisp, there are lots of cool things in there.

http://www.cliki.net/Library

Encodings

donotreply@osnews.com (Anonymous) — Fri, 23 Apr 2004 21:18:00 GMT

The tip about encodings could do with a lot of work. (It also has little to do with Mono specifically - it's just a normal .NET thing.)

A few things (which apply to .NET in general - I would certainly imagine they'd all work in Mono):

o Rather than use new ASCIIEncoding etc, just use Encoding.ASCII - it's a singleton, so it won't end up creating objects for you needlessly.

o Your article implies that the interface for ASCIIEncoding is different to the one for UTF8Encoding. It's not. They both inherit the same methods from Encoding, and you can use the same code for both.

o Your NullEncoding is lossy, as you're using one byte per character rather than two. Why not just use UnicodeEncoding instead, which is basically the "right" way of doing what you were doing in the first place?

See http://www.pobox.com/~skeet/csharp/unicode.html for more information.

Re: Encodings

donotreply@osnews.com (Anonymous) — Fri, 23 Apr 2004 21:27:00 GMT

A few things (which apply to .NET in general - I would certainly imagine they'd all work in Mono):

Yes, that's true, in general.

Your article implies that the interface for ASCIIEncoding is different to the one for UTF8Encoding. It's not. They both inherit the same methods from Encoding, and you can use the same code for both.

According to Monodoc, it is different. I was basing myself in Monodoc, because the article is about Mono.

Your NullEncoding is lossy, as you're using one byte per character rather than two. Why not just use UnicodeEncoding instead, which is basically the "right" way of doing what you were doing in the first place?

Lossy? Are you sure? Because I tryed it, and it works. If you payed a little more attention to the text, you would see what I explained about UTF encoders. Sometimes you just CAN'T use Unicode. And would you explain why is UnicodeEncoding the "right" way? Is it the right way if I send, through a socket for example, data to a server that does not support Unicode and it receives Unicode data? Is it still the "right" way? And is it the "right" way if you whish to use the exact codepage you are using, like many other people around the world?

Re: Encodings

donotreply@osnews.com (Anonymous) — Sat, 24 Apr 2004 15:35:00 GMT

According to Monodoc, it is different

Did you check for the inherited members of ASCIIEncoding? I suspect not, as if you had, you'd see that it inherits byte[] GetBytes(string).

Lossy? Are you sure?

Yes, your NullEncoding is lossy. Or rather, it would be if it didn't fall over. It would have to be - it's encoding length*2 bytes of information in length bytes. Did you try it with all characters, including those > 0x7f? I suspect not.

I've just tried it, and (as hinted above), it falls over with an OverflowException with characters > 0x7f. Here's the test program:

class Test
{
static void Main()
{
string test = "u008x0";
byte[] bytes = NullEncoding.GetBytes(test);
string test2 = NullEncoding.GetString(bytes);
Console.WriteLine (test==test2);
}
}

Your NullEncoding wouldn't solve anything though - you still don't know what the other side is going to use. If you can guarantee that the two sides use the same thing, I'd recommend using Encoding.Unicode or Encoding.UTF8. If you can't guarantee what each side will use, and you can't specify it, you're stuffed. How exactly do you believe NullEncoding helps?

One more comment on your NullEncoding implementation: creating a string using concatenation like that becomes painfully slow as the size of the string increases. In this case, you could actually just allocate a char array to start with, fill it, and then create the string directly. In general, it's worth using a StringBuilder (and initialising it with an appropriate size if you know one).

See http://www.pobox.com/~skeet/java/stringbuffer.html for a fuller example of why you shouldn't create the string in that way - it's Java-based, but the principles are the same.

Re: Jon Skeet

donotreply@osnews.com (Anonymous) — Sun, 25 Apr 2004 01:21:00 GMT

You're wrong. Yes, I've tryed it with characters > 0x7F, and for a simple reason. I'm Portuguese. about 1/50th of the characters we use are > 0x7F. I've tryed it with my own name which is written João, with an a with tilde. And it worked fine. And when I tryed it with the ASCII encoding and Unicode encodings, it just came a "?".

Your NullEncoding wouldn't solve anything though - you still don't know what the other side is going to use. If you can guarantee that the two sides use the same thing, I'd recommend using Encoding.Unicode or Encoding.UTF8. If you can't guarantee what each side will use, and you can't specify it, you're stuffed. How exactly do you believe NullEncoding helps?

Well, but that is if YOU CAN guarantee. But I was NOT talking about when YOU can guarantee. I was talking about when you CANNOT guarantee.

One more comment on your NullEncoding implementation: creating a string using concatenation like that becomes painfully slow as the size of the string increases. In this case, you could actually just allocate a char array to start with, fill it, and then create the string directly. In general, it's worth using a StringBuilder (and initialising it with an appropriate size if you know one).

Yes, I'm aware of that. But have you ever heard of KISS (Keep It Simple Stupid)? If I'm trying to make the reader understand what he has to do, why should I complicate further?

As far as I'm concerned, you're just trolling.

Re: Encoding

donotreply@osnews.com (Anonymous) — Sun, 25 Apr 2004 07:22:00 GMT

So did you actually try my test program?

If your tests with UnicodeEncoding didn't give the original stringyou clearly weren't testing properly, as UnicodeEncoding *isn't* lossy.

You still haven't explained how you expect NullEncoding to preserve all the data with a compression ratio of 2:1. Are you aware that chars in .NET are 16 bit? If you are, please explain how you expect to compress 16 bits into 8 bits without any loss. If you're not, please read some books or documentation before writing any more "tips" on the subject.

You still haven't explained how you expect NullEncoding to help if you *cannot* guarantee what encoding is used on each side - if you don't know what the other side expects, you just can't get the data to it accurately. NullEncoding just *doesn't help*. You don't seem to have even read the text you quoted.

As for not using StringBuilder - you could actually have made the code simpler *and* more efficient by just using a char array. I really don't like presenting horribly inefficient code (which you're recommending others use!) without at least giving warnings about its inefficiency.

As for whether or not I'm trolling - I'm trying to correct some of the horribly misguided impressions you've given. The fact that you think NullEncoding isn't lossy shows you don't know *nearly* enough to be writing about the subject. To my mind, if you're going to write garbage, you should expect to be called on it.

Re: Encoding

donotreply@osnews.com (Anonymous) — Sun, 25 Apr 2004 07:24:00 GMT

Oh, and does your lack of comment about the ASCIIEncoding interface mean you've got a clue on that topic now, and accept that you can just use GetBytes(string)?

Re: Encoding

donotreply@osnews.com (Anonymous) — Sun, 25 Apr 2004 11:33:00 GMT

I see my test program hasn't quite posted properly - I should have previewed it, apologies for that. The string should be "u0080", not "u008x0". (Not entirely sure how it cut and pasted to that, to be honest.) Hopefully you saw what I was getting at anyway and changed it when testing it yourself.

I still don't understand why you didn't see an OverflowException when testing with your own name though, as the docs for Convert.ToByte(char) specifically say it will throw an OverflowException if "value is greater than Byte.MaxValue". Byte.MaxValue is 127, and the character for an a with a tilde is (according to www.unicode.org) 0xe3.

Re: Encoding

donotreply@osnews.com (Anonymous) — Sun, 25 Apr 2004 12:45:00 GMT

There's no compression 2:1. Since I use the ISO-8859-15 codepage, and since in that codepage all characters have a value

Re: Encoding

donotreply@osnews.com (Anonymous) — Sun, 25 Apr 2004 14:47:00 GMT

The characters you happen to be using may all be Unicode < 256, but that's not true of Unicode strings in general. So yes, your encoder is lossy for general strings. It may not be lossy in your particular case, but that's not the same thing. (Also, I don't believe all characters in ISO-8859-15 *are* less than 256 in Unicode. In particular, I believe it includes the Euro sign, which is 0x20ac in Unicode.)

Apologies for the braino on Byte.MaxValue - don't know what I was thinking there, or what happened when I got an OverflowException (typo, no doubt). Try it with string test = "u0100" and you'll get the exception for certain though. So yes, your encoding will fall over with perfectly valid strings. That's hardly encouraging, is it?

Char.MaxValue *isn't* 127, btw- it's 65535. SByte.MaxValue is 127.

As for why you got a compilation error with ASCIIEncoding: I don't know, I'd have to see your code. The reason you can explicitly see the overridden methods in UnicodeEncoding is that they are overridden there rather than using the base implementation. That doesn't mean the base implementation isn't there though. Here's an example program which compiles fine for me. Please try it and see if it compiles for you too:

using System;
using System.Text;

class Test
{
static void Main()
{
byte[] b = Encoding.ASCII.GetBytes("hello");
Console.WriteLine(b.Length);
}
}

The above compiles for me even with a relatively old version of Mono. It should compile for you too. This goes against what you claim in the article. Care to explain?

It seems to me that you don't know anything about converting data of different size, how unicode works and about how things are converted to and from unicode.

LOL. I'm not the one claiming that an encoding which takes a string of UTF-16 characters and maps it to the same number of bytes will work without being lossy...

It's fine to show that there are various different methods you can call on Encodings - but when you start claiming that you can only use a certain method on one kind of encoding when it's actually a member of the base class, you're just being inaccurate.

You also still haven't explained how you expect your NullEncoding to help when you don't know what encoding the other side is going to use. (Basically your encoding is an ISO-8859-1 encoding, which can be got using Encoding.GetEncoding(28591). Of course, you'd know that if you read the link I posted earlier, which also pretty much disproves your claim that I don't know anything about how Unicode works.)

Re: Jon Skeet

donotreply@osnews.com (Anonymous) — Sun, 25 Apr 2004 15:32:00 GMT

(Also, I don't believe all characters in ISO-8859-15 *are* less than 256 in Unicode. In particular, I believe it includes the Euro sign, which is 0x20ac in Unicode.)

I didn't said that all characters in ISO-89859-15 are less than 256 in Unicode. I said exactly the opposite: that all characters in ISO-8859-15 are below 256 in ISO-8859-15, because ISO-8859-15 is a 256 char encoding.

Char.MaxValue *isn't* 127, btw- it's 65535. SByte.MaxValue is 127.

Yes, I've mixed up.

You also still haven't explained how you expect your NullEncoding to help when you don't know what encoding the other side is going to use. (Basically your encoding is an ISO-8859-1 encoding, which can be got using Encoding.GetEncoding(28591)

Because since you don't know what the other side is using, you just use it as it comes and let the classes do the rest for you.
And the point in the article is not to teach all about encodings, but to let people understand a bit of the theory behind it. You too, that have also written articles, should be know that is difficult to explain theory and practice at the same time. It is easy to be misinterpreted. In this case sometimes there may have been confusion because of my poor english, but there are always some people that simply do not pay attention.
And some other times, you just have to twist the reality a bit, so that people can understand the first bit. Later, when they have already learned a bit more, they can "undo" that small deviation of reality and understand every piece missing. Didn't your math, phisics and chemestry teachers do it, when you were in school? Didn't they ever made you assume things that weren't real, so that you might understand others that were and for which they couldn't explain it any simpler because you still didn't have the knowlege for it?
For example didn't they start telling you that gravity acceleration was allways 9.8m/s² to later tell you that in fact it varies according to the distance to the Earth center? Didn't it work to let you understand the rest?

RE: Encoding

donotreply@osnews.com (Anonymous) — Sun, 25 Apr 2004 15:57:00 GMT

There's a difference between the approximations made in physics and what you did here. You basically said, "Here's a good class to use" when the class you gave was horrendously inefficient, and breaks on any string with a character in which has a Unicode value > 255. Also, when I write an "approximation to the truth" I try to always make sure that I state that it's an approximation, so that people don't hold it to be the truth. Where I can, I direct them to more detailed resources if they wish to learn more.

Your previous post about values in ISO-8859-15 not being > 255 was confusing. I see what you meant now, but that's irrelevant. What's important is whether or not any characters in the string have a Unicode value > 255. If they have, your class breaks with an exception. If it didn't throw an exception (if you used a cast instead of Convert.ToByte, for instance), it would have to lose data instead, because even if *you* don't happen to use Unicode characters > 255, other people do. Pretending they don't is dangerous.

Because since you don't know what the other side is using, you just use it as it comes and let the classes do the rest for you.

What you get is bytes. You have to convert those into characters. If you don't know the encoding on the server, you simply cannot do that accurately. Your class doesn't help with this like you claim it does. It does nothing useful.

And the point in the article is not to teach all about encodings, but to let people understand a bit of the theory behind it.

Except you didn't. If anything, you confused things more, as far as I can see. You provided code which attempted to solve a problem to which there is no solution, and the code you gave is inefficient and breaks on any character data not in the first 256 Unicode values - something you either weren't aware of, or just failed to mention.

You claimed that people couldn't use code that they could use (Encoding.GetBytes(string) where the encoding in question is an ASCIIEncoding) you implied there are no existing encodings other than the UTF ones and ASCII (there are plenty) and generally painted a pretty sorry picture. Why not just point people to an article which explains Unicode in a reasonable way? http://www.joelonsoftware.com/articles/Unicode.html is a good article to point newbies at, for instance.