Hello,
In vb.net there is a with statement, Is there are similar constructor in c#?
33  2408 
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.
"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
"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.
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
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
"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
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
"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?
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
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.
"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.
"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.
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. :)
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.
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.
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
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
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
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
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
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
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.
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
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
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.
>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.
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
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.
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
"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.
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
>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?
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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Marco Bubke |
last post by:
Hi
I have read some mail on the dev mailing list about PEP 318 and find the new
Syntax really ugly.
def foo(x, y): pass
I call this foo(1, 2), this isn't really intuitive to me!
Also I...
|
by: Jason Callas |
last post by:
I have a stored procedure that runs as a step in a scheduled job. For
some reason the job does not seem to finish when ran from the job but
does fine when run from a window in SQL Query.
I know...
|
by: nobody |
last post by:
hello everybody,
is there a way of creating an array with help of a function that would
accept the name of this array as a parameter and then create global
Array type variable of that name?
so...
|
by: Toby Austin |
last post by:
I'm trying to replace <table>s with <div>s as much as possible.
However, I can't figure out how to do the following…
<table>
<tr>
<td valign="top" width="100%">some data that will...
|
by: C Gillespie |
last post by:
Dear All,
Hopefully I have a simple problem. Basically, I just want to alter some text
with JS.
Here is some of my test code:
<snip>
<script type="text/javascript">
var tmp='a';
|
by: eman1000 |
last post by:
I was recently looking at the prototype library
(http://prototype.conio.net/) and I noticed the author used the
following syntax:
Object.extend(MyObj.prototype, {
my_meth1: function(){},...
|
by: NM |
last post by:
Hello,
I've got a problem inserting binary objects into the postgres database.
I have binary objects (e.g. images or smth else) of any size which I
want to insert into the database. Funny is it...
|
by: Rasmus Kromann-Larsen |
last post by:
The With Conundrum
I'm currently writing a master thesis on (preparations for) static
analysis of JavaScript, and after investigating the with statement, it
only even more evident to me that the...
|
by: oll3i |
last post by:
my librarybean
package library.ejb;
import java.sql.*;
import javax.ejb.*;
import library.common.*;
@Stateless @Remote
|
by: jwwicks |
last post by:
C/C++ Programs and Debugging in Linux
This tutorial will give you a basic idea how to debug a program in Linux using GDB. As you are aware Visual Studio doesn’t run on Linux so you have to use...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
| |
