|
Been using C# for over a decade (amongst other languages) and still loving it. The language is constantly evolving and bringing out new features.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
Yep! I really love C#. Trouble is my boss insists on using VB.net. 
We're philosophical about power outages here. A.C. come, A.C. go.
|
|
|
|
|
C# being in the "C group" of languages, there are a few things that we have to bear over with. Such as why the ... do you have write all condions in parentheses? The "Algol group", such as Pascal, managed without the parentheses, and you never use them in plain writing. ("If (you're cold), then put on a sweater").
And: Why isn't a single statement a block? In some contexts, I can use either a single statement or a block, but not in other contexts (such as exception handlers).
And the extremely ugly 'try - catch' syntax! Compare to, say, CHILL: Any block follwed by an exception handler (indicated by an ON <exception> keyword) before the semicolon is sufiicient - no need for the try "pre-warning", it is implied by the presence of a handler. No need for (yet) another level of {} ...
But after 30+ years with C-class programming, we have learned to live with it.
C# is the best of the crowd, but still I miss a couple of elements from Pascal: First and foremost array dimensioning and indexing. You cannot make an array indexed from 1950 to 2020, as simple and straightforward as we did in Pascal. You cannot index an array by a non-integer value - enums in particular. Enums are not a fully recognized, distinct type as it was in Pascal; it is really not much more than the old #define spring 0; #define summer 1; ... They still have a lot of "integer properties". But they are not integers, either: You cannot declare an array of four elements indexed by the 'season' enumeration type. It is a pity that when enums where included, that they didn't fully copy the Pascal enum concept.
We can manage with the integer/enum bastard concept, and we have learned to live with numbering elements from zero, but they must be mentioned in a "would have been nice to have" list.
I have a couple more "nice to have": In CHILL, a label doesn't name a point, but a block. A function name is a label on the block implementing the function, but you may label any block in the same way. This allows a clean way of, say, exiting through several nested levels of looping: An OuterLoop: ... which contains a MiddleLoop: ... which in turn contains an InnerLoop:... : The inner loop code can EXIT MiddleLoop; directly without setting flags to be tested etc.
Another flow control mechanism in the "nice to have" list: If you prematurely exit a loop, it ususally represents a different situation from running the loop to the end, and neds a different treatment. So a loop may have two exit paths, distinguishing between these two. One proprietary language providing this ("PLANC") had FOR-loops with such a mechanism:
FOR <iteration specification=""> DO
. ... <loop body="" statements="">
. .... WHILE <condition>; // can we skip out now, is the job done?
. ... <more loop="" body="" statements="">
EXITFOR
. ... <handling of="" loop="" exhaustion="">
EXITWHILE
. ... <handling of="" premature="" exit="">
ENDFOR
No need to set flags, no need to test flags, and the two different exits is semantically witin the loop, with access to e.g. loop local variables.
The only way to understand the great value of these nice-to-have things is to work with them and see how useful they are in large, complex code. Any three-line example is always met with replies "But why couldn't you simply do so-and-so?" - yes, for the super-simple illustration, but not for the complex situations where you really benefit from them.
I guess there is no hope of getting any such mechamisms into neither C# nor any other languages in the C group. I have considered, for my private programming, making a preprocessor that would allow me to use both Pascal type indexing, proper enum handling, labeled blocks and handling of premature loop exits, translating it to dirty gotos to generated labels. For my private use, I could do that, but my employer would never tolerate that kind of "private extensions", even with a preprocessor translating it to plain C#.
|
|
|
|
|
Maybe you should try get a job on the C# compiler team 
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
I try to do as much C# as I can, but SSIS keeps pulling me back in. (It's not a language.)
|
|
|
|
|
PIEBALDconsult wrote: It's not a language
Yes, it is a sentence. 
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[ ^]
|
|
|
|
|
But doesn't SSIS let you do C# now instead of forcing you to do VB?
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Yes, in Script Tasks you can choose to use C# or VB, but a Script Task should be a last resort; they're nasty. (I write a lot of them anyway.)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
