Lambda the Ultimate

inactiveTopic Whitepaper on new C# Features
started 11/13/2002; 7:11:29 AM - last post 11/16/2002; 2:20:55 PM
Ehud Lamm - Whitepaper on new C# Features  blueArrow
11/13/2002; 7:11:29 AM (reads: 1465, responses: 6)
Whitepaper on new C# Features
This is the most detailed specification I was able to find of the proposed additions to C#. Warning: It a Word document.

The FAQ available is also useful, and the new features though yet unspecified, have a home page.

It is amusing to see how hard Java and C# developers are trying to copy features available in Ada (and even in C++) for so long.

I wonder, how much of the difference between the programming experience (i.e., style, taste) in Java/C# and Ada/C++ can simply be attributed to garbage collection?

And oh, iterators were already present in CLU...


Posted to general by Ehud Lamm on 11/13/02; 7:13:00 AM

Patrick Logan - Re: Whitepaper on new C# Features  blueArrow
11/13/2002; 6:54:57 PM (reads: 1184, responses: 0)
Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary.

http://www.math.grin.edu/courses/Scheme/r5rs-html/r5rs_3.html

-R5RS authors

After a couple decades plus of programming in all kinds of languages, what continues to strike me is how many features just do not significantly affect productivity.

A language that mostly stays out of the way and lets a team simply express their intent is all that's needed.

What's truly missing, and I thought I'd see it by now, is a way to put significantly more power into non-programmers' hands.

Frank Atanassow - Re: Whitepaper on new C# Features  blueArrow
11/14/2002; 2:05:18 AM (reads: 1134, responses: 0)
I wonder, how much of the difference between the programming experience (i.e., style, taste) in Java/C# and Ada/C++ can simply be attributed to garbage collection?

This is a perceptive remark; I think the difference is quite significant. With C and C++, I always feel like I'm standing on a precipice, because I'm always only one statement away from a segmentation fault.

Dejan Jelovic - Re: Whitepaper on new C# Features  blueArrow
11/14/2002; 3:46:12 AM (reads: 1127, responses: 0)
I wonder, how much of the difference between the programming experience (i.e., style, taste) in Java/C# and Ada/C++ can simply be attributed to garbage collection?

A lot.

Specifically, Java and C# default to higher-level constructs and make you work extra in order to write low-level code, while C++ defaults to low-level constructs and makes you work extra to build higher-level abstractions.

The only revolutionary thing about C# is, IMO, the fact that it makes interop with C much simpler and much faster than other languages. Green Card and JNI don't come even close.

Dejan www.jelovic.com

Chris Rathman - Re: Whitepaper on new C# Features  blueArrow
11/14/2002; 9:01:33 AM (reads: 1074, responses: 0)
The only revolutionary thing about C# is, IMO, the fact that it makes interop with C much simpler and much faster than other languages. Green Card and JNI don't come even close.
Inspired by this article, I wrote an application in C# that automates our process of turning paper documents into PDF files for our Benefits Dept (thousands and thousands of pages of Beneficiary forms). The biggest hassle was TWAIN, in that it was written with C and the raw Windows event APIs in mind. Not only do you have to worry about the byte/word alignment mismatch but also you have the driver allocating raw memory that you have to take care to dispose of manually.

The C# interop directives are easier to work with than trying to build the higher level abstractions in C/C++. The interop directives, though, really don't read like code, so much as they do as compiler macros to trick the compiler.

Jo Totland - Re: Whitepaper on new C# Features  blueArrow
11/16/2002; 7:28:35 AM (reads: 1006, responses: 0)
Not only do you have to worry about the byte/word alignment mismatch but also you have the driver allocating raw memory that you have to take care to dispose of manually.

Why do you worry about that on x86? Any x86 processor will happily let you read/write unaligned memory, it will simply be slower. Allocating raw memory and disposing of it shouldn't be too much hassle either. It is localized to the twain driver, and shouldn't need to destroy the design of the rest of your program. Of course, I'm just curious, there could be reasons I haven't thought about, I've never used C#.

Chris Rathman - Re: Whitepaper on new C# Features  blueArrow
11/16/2002; 2:20:55 PM (reads: 1014, responses: 0)
Why do you worry about that on x86? Any x86 processor will happily let you read/write unaligned memory, it will simply be slower.
The problem is that you have to read and write data structures to communicate with the TWAIN driver. The managed types in C# do use alignment, so you have to override this default and use the interop instructions to marshal the data in and out. Something like the Identity Structure has to be written as:

   [StructLayout(LayoutKind.Sequential, Pack=2, CharSet=CharSet.Ansi)]
   public class TW_IDENTITY {
      public IntPtr        Id;               // Unique number.  In Windows, application hWnd
      public TW_VERSION    Version;          // Identifies the piece of code
      public ushort        ProtocolMajor;    // Application and DS must set to TWON_PROTOCOLMAJOR
      public ushort        ProtocolMinor;    // Application and DS must set to TWON_PROTOCOLMINOR
      public uint          SupportedGroups;  // Bit field OR combination of DG_ constants
                                             [MarshalAs(UnmanagedType.ByValTStr, SizeConst=34)]
      public string        Manufacturer;     // Manufacturer name, e.g. "Hewlett-Packard"
                                             [MarshalAs(UnmanagedType.ByValTStr, SizeConst=34)]
      public string        ProductFamily;    // Product family name, e.g. "ScanJet"
                                             [MarshalAs(UnmanagedType.ByValTStr, SizeConst=34)]
      public string        ProductName;      // Product name, e.g. "ScanJet Plus"
   }

It certainly works, but you have to insert the StructLayout and MarshalAs directives. These directives are fairly picky - put in the wrong constant and they go haywire. My original comment is that they are little more than compiler macros and that they take on a life of their own - requiring the mastering of fairly arcane trivia.