By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,141 Members | 1,225 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,141 IT Pros & Developers. It's quick & easy.

'with' statement

P: n/a
Hello,

In vb.net there is a with statement, Is there are similar constructor in c#?

May 1 '07 #1
Share this Question
Share on Google+
33 Replies


P: n/a
On May 1, 3:33 pm, DOTNETGUY <DOTNET...@discussions.microsoft.com>
wrote:
In vb.net there is a with statement, Is there are similar constructor in c#?
No, there is not.

May 1 '07 #2

P: n/a
"DOTNETGUY" <DO*******@discussions.microsoft.comwrote in message
news:50**********************************@microsof t.com...
In vb.net there is a with statement, Is there are similar constructor in
c#?
No, thankfully!
http://msdn2.microsoft.com/en-us/vcsharp/aa336816.aspx

May 1 '07 #3

P: n/a

"Andy" <an***@med-associates.comwrote in message
news:11*********************@c35g2000hsg.googlegro ups.com...
On May 1, 3:33 pm, DOTNETGUY <DOTNET...@discussions.microsoft.com>
wrote:
>In vb.net there is a with statement, Is there are similar constructor in
c#?

No, there is not.
But there ought to be.

As well as a genuine "case" statement (allowing operands of any type) to
replace the current "switch" statement, which is a deformed relic of the
influence of Fortran upon C in 1972 or so.

May 1 '07 #4

P: n/a
Michael A. Covington <lo**@ai.uga.edu.for.addresswrote:
On May 1, 3:33 pm, DOTNETGUY <DOTNET...@discussions.microsoft.com>
wrote:
In vb.net there is a with statement, Is there are similar constructor in
c#?
No, there is not.

But there ought to be.
I suspect we'll have to agree to disagree on that front.

I'd rather write a descriptive variable name and put that in front of
each statment than have the ambiguous (when there are multiple levels
of "with") dot on its own.
As well as a genuine "case" statement (allowing operands of any type) to
replace the current "switch" statement, which is a deformed relic of the
influence of Fortran upon C in 1972 or so.
Yes, a better switch statement would be very welcome. Groovy allows
some rather cool things on that front. Quite whether the fast
performance of the C-style switch can be matched (even for the simple
cases) by a more flexible switch is a matter for research etc. I'd
happily give up the performance in 99% of the cases in favour of the
flexibility.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
May 1 '07 #5

P: n/a
On Tue, 01 May 2007 15:30:40 -0700, Jon Skeet [C# MVP] <sk***@pobox.com>
wrote:
Michael A. Covington <lo**@ai.uga.edu.for.addresswrote:
>But there ought to be.

I suspect we'll have to agree to disagree on that front.
And I'll disagree with you both (but agreeably so, I hope). :)

I disagree that "there ought to be" in C#. As the article Mark referred
to points out, we lived just fine without a "with" statement in C and
C++. It's just not that important a construct to argue that it *ought* to
be in the language, even if having it would make life a little easier.

Intellisense in VS makes the usefulness of "with" even less, since it
usually only takes a handful of keystrokes to type in the longest of names
(exceptions including when you've got a lot of long names that are mostly
the same...a bad idea anyway, IMHO :) ).

I do see utility in the "with" statement. I just don't find it so
compelling as to demand its inclusion in the language.
I'd rather write a descriptive variable name and put that in front of
each statment than have the ambiguous (when there are multiple levels
of "with") dot on its own.
Ambiguity is, IMHO, a poor argument against a "with" statement. The
article Mark referred to brought up the question of ambiguity between a
field and a local variable. Well, as VB does, so too could C# just
require slightly different syntax for a field than a local (so you can
easily tell the difference between ".Text" and "Text"). As far as nested
"with" statements go, there are two easy solutions: either disallow nested
"with" statements altogether, or only allow access to the inner-most
"with" statement in any block of code.

I'd prefer the former, but if the language did the latter but the compiler
emitted a warning similar to that used when hiding a local variable, that
would be fine with me too.

I don't really see ambiguity as a significant or unresolvable problem,
with respect to having a "with" statement.

Pete
May 1 '07 #6

P: n/a
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP********************@msnews.microsoft.com.. .
I'd rather write a descriptive variable name and put that in front of
each statment than have the ambiguous (when there are multiple levels
of "with") dot on its own.
There's an easy solution to the problem of nested "with"es - "don't do
that". :)

I think a stronger objection is that you shouldn't be making a lot of calls
one after another to a single object (in general).

///ark
May 2 '07 #7

P: n/a
I've seen this particular question come up at least 4 or 5 times in the last
year or so, and I have to agree. "With xyz ".... is simplyunnecessary in a
concise and elegant language like C#. Hard core classic VB programmers who
are resistant to change are usually the ones who harp on this (among other
silly issues).
Peter

--
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
Short urls & more: http://ittyurl.net


"Mark Rae" wrote:
"DOTNETGUY" <DO*******@discussions.microsoft.comwrote in message
news:50**********************************@microsof t.com...
In vb.net there is a with statement, Is there are similar constructor in
c#?

No, thankfully!
http://msdn2.microsoft.com/en-us/vcsharp/aa336816.aspx

May 2 '07 #8

P: n/a
"Peter Bromberg [C# MVP]" <pb*******@yahoo.yabbadabbadoo.comwrote in
message news:D2**********************************@microsof t.com...
I've seen this particular question come up at least 4 or 5 times in the
last
year or so, and I have to agree. "With xyz ".... is simplyunnecessary in a
concise and elegant language like C#. Hard core classic VB programmers who
are resistant to change are usually the ones who harp on this (among other
silly issues).
Peter
What I'd much rather have is a concise notation for mathematics.
Programming as we know it originated with Fortran (Formula Translation),
which allowed you to write such things as:

Y = SIN(X)**2 + COS(Z)**2

In C#, if I'm not mistaken, we're now stuck with

y = Math.Pow(Math.Sin(x),2) + Math.Pow(Math.Sin(z),2)

which is a great deal farther from normal mathematical notation. I know
it's nice and object-oriented, but something valuable has been lost.

It could have been worse. They could have given us:

Object.Assign(ref y,
Math.Add(Math.Pow(Math.Sin(x),2),Math.Pow(Math.Sin (z),2)));

If + has special status as a math operator, then why not ** and the Math
functions?


May 2 '07 #9

P: n/a
Michael A. Covington <lo**@ai.uga.edu.for.addresswrote:
What I'd much rather have is a concise notation for mathematics.
Programming as we know it originated with Fortran (Formula Translation),
which allowed you to write such things as:

Y = SIN(X)**2 + COS(Z)**2

In C#, if I'm not mistaken, we're now stuck with

y = Math.Pow(Math.Sin(x),2) + Math.Pow(Math.Sin(z),2)
Yes - this is a problem which Java solved using "static imports" - you
can specify either particular members or "all static members" from a
particular class, and then the class name doesn't need to be specified.
You'd just have:

y = Pow(Sin(x), 2) + Pow(Sin(z), 2);

Definitely something to be used with great care, but handy. In fact, I
wanted this just yesterday, for testing purposes...
which is a great deal farther from normal mathematical notation. I know
it's nice and object-oriented, but something valuable has been lost.

It could have been worse. They could have given us:

Object.Assign(ref y,
Math.Add(Math.Pow(Math.Sin(x),2),Math.Pow(Math.Sin (z),2)));

If + has special status as a math operator, then why not ** and the Math
functions?
I like a small language, personally. I don't think most people use the
power operator often enough to make it worth including in the language,
myself.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
May 2 '07 #10

P: n/a
On 2 May, 01:32, "Mark Wilden" <mwil...@communitymtm.comwrote:
"Jon Skeet [C# MVP]" <s...@pobox.comwrote in messagenews:MP********************@msnews.microsof t.com...
I'd rather write a descriptive variable name and put that in front of
each statment than have the ambiguous (when there are multiple levels
of "with") dot on its own.

There's an easy solution to the problem of nested "with"es - "don't do
that". :)

I think a stronger objection is that you shouldn't be making a lot of calls
one after another to a single object (in general).

///ark
I completely agree with this. One of my bug bears is coming across
code that looks like:

Kitten.MoveFrontPaw(Left);
Kitten.MoveBackPaw(Right);
Kitten.MoveFrontPaw(Right);
Kitten.MoveBackPaw(Left);

instead of:

Kitten.Walk();

and then the above travesty is needlessly repeated in about 30
locations normally with comic variations of Paw ordering.

May 2 '07 #11

P: n/a

"DeveloperX" <nn*****@operamail.comwrote in message
news:11**********************@y5g2000hsa.googlegro ups.com...
On 2 May, 01:32, "Mark Wilden" <mwil...@communitymtm.comwrote:
>"Jon Skeet [C# MVP]" <s...@pobox.comwrote in
messagenews:MP********************@msnews.microso ft.com...
I'd rather write a descriptive variable name and put that in front of
each statment than have the ambiguous (when there are multiple levels
of "with") dot on its own.

There's an easy solution to the problem of nested "with"es - "don't do
that". :)

I think a stronger objection is that you shouldn't be making a lot of
calls
one after another to a single object (in general).

///ark

I completely agree with this. One of my bug bears is coming across
code that looks like:

Kitten.MoveFrontPaw(Left);
Kitten.MoveBackPaw(Right);
Kitten.MoveFrontPaw(Right);
Kitten.MoveBackPaw(Left);

instead of:

Kitten.Walk();

and then the above travesty is needlessly repeated in about 30
locations normally with comic variations of Paw ordering.
Your example is multiple methods being called. I agree with you for
methods. However, try this:

Kitten.Color = "Black"
Kitten.Eyes = "Green"
Kitten.Fur = "Long"

These are properties of a Kitten. In general, they cannot be incorporated
into a single property.

Mike.
May 2 '07 #12

P: n/a

"Peter Duniho" <Np*********@nnowslpianmk.comwrote in message
news:op***************@petes-computer.local...
On Tue, 01 May 2007 15:30:40 -0700, Jon Skeet [C# MVP] <sk***@pobox.com>
wrote:
>Michael A. Covington <lo**@ai.uga.edu.for.addresswrote:
>>But there ought to be.

I suspect we'll have to agree to disagree on that front.

And I'll disagree with you both (but agreeably so, I hope). :)

I disagree that "there ought to be" in C#. As the article Mark referred
to points out, we lived just fine without a "with" statement in C and
C++. It's just not that important a construct to argue that it *ought* to
be in the language, even if having it would make life a little easier.

Intellisense in VS makes the usefulness of "with" even less, since it
usually only takes a handful of keystrokes to type in the longest of names
(exceptions including when you've got a lot of long names that are mostly
the same...a bad idea anyway, IMHO :) ).

I do see utility in the "with" statement. I just don't find it so
compelling as to demand its inclusion in the language.
>I'd rather write a descriptive variable name and put that in front of
each statment than have the ambiguous (when there are multiple levels
of "with") dot on its own.

Ambiguity is, IMHO, a poor argument against a "with" statement. The
article Mark referred to brought up the question of ambiguity between a
field and a local variable. Well, as VB does, so too could C# just
require slightly different syntax for a field than a local (so you can
easily tell the difference between ".Text" and "Text"). As far as nested
"with" statements go, there are two easy solutions: either disallow nested
"with" statements altogether, or only allow access to the inner-most
"with" statement in any block of code.
In VB, the with statement is really nothing more than telling the compiler
"Make a temporary, unnamed, local variable for me." As for ambiguity in
nested with statements, only the inner most with statement allows access to
its properties without specifiying the variable name. Is a with statement
useful - definitely. Is it a must have, no.
I'd prefer the former, but if the language did the latter but the compiler
emitted a warning similar to that used when hiding a local variable, that
would be fine with me too.

I don't really see ambiguity as a significant or unresolvable problem,
with respect to having a "with" statement.

Pete
There is no ambiguity with the VB with statement. It can, however, be less
useful than expected, especially when nested.

Mike.
May 2 '07 #13

P: n/a
I like a small language, personally. I don't think most people use the
power operator often enough to make it worth including in the language,
myself.
But when we use it, it really helps correctness if our formulas can *look*
like formulas!

Be careful when asking for a language that doesn't cater to
mathematicians... you might get COBOL. :)
May 2 '07 #14

P: n/a
On May 1, 6:18 pm, "Michael A. Covington"
<l...@ai.uga.edu.for.addresswrote:
In vb.net there is a with statement, Is there are similar constructor in
c#?
No, there is not.

But there ought to be.
No, there should not be. It doesn't add anything that you can't
already get with a simple statement. It doesn't make code more
performant, and it doesn't make code any more readable. In other
words, it adds no value whatsoever.
As well as a genuine "case" statement (allowing operands of any type) to
replace the current "switch" statement, which is a deformed relic of the
influence of Fortran upon C in 1972 or so.
What if said objects don't have comparison operators? Most classes
don't define == or even .Equals, which means that switch would operate
on the default implementation, which compares references. Not very
useful. Also, if switch isn't powerful enough for you, you can also
use if - else if statements. Honestly, switch is a rarely used
construct I've found.

May 2 '07 #15

P: n/a
On May 1, 7:06 pm, "Peter Duniho" <NpOeStPe...@nnowslpianmk.com>
wrote:
Ambiguity is, IMHO, a poor argument against a "with" statement. The
article Mark referred to brought up the question of ambiguity between a
field and a local variable. Well, as VB does, so too could C# just
require slightly different syntax for a field than a local (so you can
easily tell the difference between ".Text" and "Text"). As far as nested
"with" statements go, there are two easy solutions: either disallow nested
"with" statements altogether, or only allow access to the inner-most
"with" statement in any block of code.
Actually I find it a good argument. It makes the language (and hence
the compiler) more complex. Adding a bunch of complexity for no real
gain isn't a great idea in my opinion.

May 2 '07 #16

P: n/a
On May 2, 2:26 pm, "Michael D. Ober" <obermd.@.alum.mit.edu.nospam>
wrote:

<snip>
Your example is multiple methods being called. I agree with you for
methods. However, try this:

Kitten.Color = "Black"
Kitten.Eyes = "Green"
Kitten.Fur = "Long"

These are properties of a Kitten. In general, they cannot be incorporated
into a single property.
This is normally done once, when constructing the object - which is
why C# 3.0 has syntax specifically for this case.

Jon

May 2 '07 #17

P: n/a
On May 2, 3:00 pm, "Michael A. Covington"
<l...@ai.uga.edu.for.addresswrote:
I like a small language, personally. I don't think most people use the
power operator often enough to make it worth including in the language,
myself.

But when we use it, it really helps correctness if our formulas can *look*
like formulas!
I think that's an argument for allowing user-defined operators (not
just overloading of existing ones), which is attractive in some senses
but makes things more complicated.

I don't think C# is trying to target *every* developer on the planet.
It doesn't need to be all things to all people. It's much better (IMO)
to cater very well for the more common cases, making the rarer
situations a bit harder (but still perfectly doable).

Jon
May 2 '07 #18

P: n/a
On Wed, 02 May 2007 06:27:22 -0700, Michael D. Ober
<obermd.@.alum.mit.edu.nospamwrote:
[...] As
for ambiguity in nested with statements, only the inner most with
statement allows access to its properties without specifiying the
variable name.
I know. And as I stated, that is the solution to the ambiguity that I
prefer.
Is a with statement
useful - definitely. Is it a must have, no.
I said that too.
>I don't really see ambiguity as a significant or unresolvable problem,
with respect to having a "with" statement.

There is no ambiguity with the VB with statement.
I know there's no ambiguity. That's why I said it's not a problem.

Pete
May 2 '07 #19

P: n/a
On Wed, 02 May 2007 07:10:47 -0700, Andy <an***@med-associates.comwrote:
On May 1, 7:06 pm, "Peter Duniho" <NpOeStPe...@nnowslpianmk.com>
wrote:
>Ambiguity is, IMHO, a poor argument against a "with" statement. [...]

Actually I find it a good argument. It makes the language (and hence
the compiler) more complex. Adding a bunch of complexity for no real
gain isn't a great idea in my opinion.
My point is that "ambiguity" as a debating point is a non-starter. A
"with" statement is only ambiguous if the language designer allows it to
be, and there's no reason for them to.

Yes, introducing a "with" statement increases complexity, but that's true
of anything you include in a language. If "complexity" in and of itself
were an argument against inclusion, then no computer language would do
anything.

And keep in mind, there are plenty of people who would debate whether a
"with" statement offers "no real gain".

Pete
May 2 '07 #20

P: n/a
Michael D. Ober <obermd.@.alum.mit.edu.nospamwrote:

<snip>
I don't really see ambiguity as a significant or unresolvable problem,
with respect to having a "with" statement.

There is no ambiguity with the VB with statement. It can, however, be less
useful than expected, especially when nested.
I didn't mean in terms of compiler ambiguity. You can make the language
specify that it'll be whatever you like. But for the *reader*, it looks
ambiguous - it's basically a minor disaster on the readability front.

I personally don't see why it's any more useful than using a local
variable yourself, without complicating the language.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
May 2 '07 #21

P: n/a
Peter Duniho <Np*********@nnowslpianmk.comwrote:
Actually I find it a good argument. It makes the language (and hence
the compiler) more complex. Adding a bunch of complexity for no real
gain isn't a great idea in my opinion.

My point is that "ambiguity" as a debating point is a non-starter. A
"with" statement is only ambiguous if the language designer allows it to
be, and there's no reason for them to.
I should have been a lot more clear, and using the word ambiguous was a
mistake. What I meant was that it's not obvious to the reader of the
code which object is being referred to, unless they know the details of
the language specification. You could specify it any way you like, of
course, to avoid the compiler thinking it was ambiguous - but it would
still provoke a "Huh?" in the reader.

Apologies for causing confusion.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
May 2 '07 #22

P: n/a
On May 2, 12:49 pm, "Peter Duniho" <NpOeStPe...@nnowslpianmk.com>
wrote:
Yes, introducing a "with" statement increases complexity, but that's true
of anything you include in a language. If "complexity" in and of itself
were an argument against inclusion, then no computer language would do
anything.
I wasn't arguing that complexity should rule out a feature though, I
was arguing that complexity which adds no value should be ruled out.
And keep in mind, there are plenty of people who would debate whether a
"with" statement offers "no real gain".
I could hardly take them seriously either. Eliminating the need to
type the variable name repeatedly in a block doesn't make things
anymore readable. You'd have to show that repeating the same variable
name in a few lines reduces readablity, and I don't anyone could
honestly do that.

May 2 '07 #23

P: n/a
Jon,

Agreed - nested "with" statements can be very difficult to read.

Mike.

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP********************@msnews.microsoft.com.. .
Peter Duniho <Np*********@nnowslpianmk.comwrote:
Actually I find it a good argument. It makes the language (and hence
the compiler) more complex. Adding a bunch of complexity for no real
gain isn't a great idea in my opinion.

My point is that "ambiguity" as a debating point is a non-starter. A
"with" statement is only ambiguous if the language designer allows it to
be, and there's no reason for them to.

I should have been a lot more clear, and using the word ambiguous was a
mistake. What I meant was that it's not obvious to the reader of the
code which object is being referred to, unless they know the details of
the language specification. You could specify it any way you like, of
course, to avoid the compiler thinking it was ambiguous - but it would
still provoke a "Huh?" in the reader.

Apologies for causing confusion.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

May 2 '07 #24

P: n/a
On Wed, 02 May 2007 12:38:01 -0700, Jon Skeet [C# MVP] <sk***@pobox.com>
wrote:
[...] What I meant was that it's not obvious to the reader of the
code which object is being referred to, unless they know the details of
the language specification. You could specify it any way you like, of
course, to avoid the compiler thinking it was ambiguous - but it would
still provoke a "Huh?" in the reader.
Ah. Yes, I agree that even though the language can be made unambiguous,
it's still readability issue.

I think that if you disallow nested "with" statements, that helps a lot.
Not that I really miss having a "with" statement, just that if you didn't
allow them to be nested it wouldn't be all that bad. :)

Pete
May 3 '07 #25

P: n/a
I don't think C# is trying to target *every* developer on the planet.
It doesn't need to be all things to all people. It's much better (IMO)
to cater very well for the more common cases, making the rarer
situations a bit harder (but still perfectly doable).
If you think trigonometry is rare, you must not do much graphics.
May 3 '07 #26

P: n/a
>As well as a genuine "case" statement (allowing operands of any type) to
>replace the current "switch" statement, which is a deformed relic of the
influence of Fortran upon C in 1972 or so.

What if said objects don't have comparison operators? Most classes
don't define == or even .Equals, ...
That is true of the "switch" statement already. What concerns me is that
"switch" is so awkward, with "break" at the end of every section, mimicking
the Fortran-like flow-of-control semantics that underlies the original C
switch statement. I prefer the syntax of Pascal, especially since the C#
switch statement does *not* really work like the C switch statement that
it's modeled on; there is no fallthrough.

May 3 '07 #27

P: n/a
Michael A. Covington <lo**@ai.uga.edu.for.addresswrote:
I don't think C# is trying to target *every* developer on the planet.
It doesn't need to be all things to all people. It's much better (IMO)
to cater very well for the more common cases, making the rarer
situations a bit harder (but still perfectly doable).

If you think trigonometry is rare, you must not do much graphics.
Not a lot, no. I don't think a particularly large proportion of
professional developers do - particularly managed developers.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
May 3 '07 #28

P: n/a
On 2 May, 14:26, "Michael D. Ober" <obermd.@.alum.mit.edu.nospam>
wrote:
"DeveloperX" <nntp...@operamail.comwrote in message

news:11**********************@y5g2000hsa.googlegro ups.com...


On 2 May, 01:32, "Mark Wilden" <mwil...@communitymtm.comwrote:
"Jon Skeet [C# MVP]" <s...@pobox.comwrote in
messagenews:MP********************@msnews.microsof t.com...
I'd rather write a descriptive variable name and put that in front of
each statment than have the ambiguous (when there are multiple levels
of "with") dot on its own.
There's an easy solution to the problem of nested "with"es - "don't do
that". :)
I think a stronger objection is that you shouldn't be making a lot of
calls
one after another to a single object (in general).
///ark
I completely agree with this. One of my bug bears is coming across
code that looks like:
Kitten.MoveFrontPaw(Left);
Kitten.MoveBackPaw(Right);
Kitten.MoveFrontPaw(Right);
Kitten.MoveBackPaw(Left);
instead of:
Kitten.Walk();
and then the above travesty is needlessly repeated in about 30
locations normally with comic variations of Paw ordering.

Your example is multiple methods being called. I agree with you for
methods. However, try this:

Kitten.Color = "Black"
Kitten.Eyes = "Green"
Kitten.Fur = "Long"

These are properties of a Kitten. In general, they cannot be incorporated
into a single property.

Mike.- Hide quoted text -

- Show quoted text -
Oh agree completely, it was a rant at some API's I've been forced to
use/fix in the past.

I'm "With" agnostic. I use it in VB6 and don't really miss it in C#
but I've no issue with its inclusion.
May 3 '07 #29

P: n/a
I think a with statement can make code easier to read. It explicitly says
"I'm these setting properties on the same object."

But my earlier caveat still applies.

///ark
May 3 '07 #30

P: n/a

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP********************@msnews.microsoft.com.. .
Michael A. Covington <lo**@ai.uga.edu.for.addresswrote:
I don't think C# is trying to target *every* developer on the planet.
It doesn't need to be all things to all people. It's much better (IMO)
to cater very well for the more common cases, making the rarer
situations a bit harder (but still perfectly doable).

If you think trigonometry is rare, you must not do much graphics.

Not a lot, no. I don't think a particularly large proportion of
professional developers do - particularly managed developers.
The thing is, when you need a concise notation for mathematics, you *really*
need it, or the code becomes massively unreadable. And this happens to be
the first aspect of programming languages that was ever invented. It's a
pity to lose it.
May 4 '07 #31

P: n/a
Michael A. Covington <lo**@ai.uga.edu.for.addresswrote:
Not a lot, no. I don't think a particularly large proportion of
professional developers do - particularly managed developers.

The thing is, when you need a concise notation for mathematics, you *really*
need it, or the code becomes massively unreadable. And this happens to be
the first aspect of programming languages that was ever invented. It's a
pity to lose it.
Well, I quite agree that it would be nice to have the equivalent of
Java's "import static" in C# at some point, but I don't think that
making the maths easier is going to impact *that* many developers
compared with, say, LINQ which is likely to be useful to virtually
everyone.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
May 4 '07 #32

P: n/a
>The thing is, when you need a concise notation for mathematics, you
>*really*
need it, or the code becomes massively unreadable. And this happens to
be
the first aspect of programming languages that was ever invented. It's a
pity to lose it.

Well, I quite agree that it would be nice to have the equivalent of
Java's "import static" in C# at some point, but I don't think that
making the maths easier is going to impact *that* many developers
compared with, say, LINQ which is likely to be useful to virtually
everyone.
What programming language do you recommend for mathematical programming in
..NET, then?
May 4 '07 #33

P: n/a
Michael A. Covington <lo**@ai.uga.edu.for.addresswrote:
Well, I quite agree that it would be nice to have the equivalent of
Java's "import static" in C# at some point, but I don't think that
making the maths easier is going to impact *that* many developers
compared with, say, LINQ which is likely to be useful to virtually
everyone.

What programming language do you recommend for mathematical programming in
.NET, then?
Well, I haven't tried the Fortran for .NET compilers, but they'd be an
obvious starting point. Here's one:

http://www.silverfrost.com/11/ftn95/overview.asp

It really depends on how maths-heavy the code is going to be - I'd
probably *try* it in C# and see how painful it is to start with.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
May 4 '07 #34

This discussion thread is closed

Replies have been disabled for this discussion.