you can't get in trouble with your boss for picking C#

[John Wilger]

=20
Just a note, dude. I clicked on your URL there, and was greeted with...
=20
"our full featured editor that is inspired by the famous emacs and vi
editors"
=20
Your marketeers need to learn there's no faster way to turn some of us of= f
to an editor than praise its comparison to those pieces of crap. I worked= vi
classic for 2 years, and vim for 2 years, and I will do anything to avoid
them.

Odd. I pine for vim when I'm (for whatever reason) forced to use some
bloated-ass IDE. To each, his own, I suppose... ;-)

--=20
Regards,
John Wilger

-----------
Alice came to a fork in the road. "Which road do I take?" she asked.
"Where do you want to go?" responded the Cheshire cat.
"I don't know," Alice answered.
"Then," said the cat, "it doesn't matter."
- Lewis Carrol, Alice in Wonderland

 

[Andrew Stuart]

I'm the boss at my company and you'd get in trouble if you chose C#.

;-)

Andrew

 

[Paolo Capriotti]

Hello ToRA,
=20
=20
T> For example, in Java/C# etc. you have to declare the type of any and
T> every variable you create. In languages like ML / Haskell, the
T> compiler is able to infer the types of your variables (you may
T> optionally expicitly declare the type of them yourself if you want).
=20
You forget that this does absolutely not fit into the ruby model. You
can't do type inference with overloaded operators. I don't know
Haskell but i know a little bit of OCAML and there you have to use the
ugly floating point operators "+." etc.

In Haskell you have both overloaded operators/functions and type inference.=
=20

Paolo

 

[Lyndon Samson]

------=_Part_30490_15357988.1127007451690
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

=20
=20
Just a note, dude. I clicked on your URL there, and was greeted with...
=20
"our full featured editor that is inspired by the famous emacs and vi
editors"
=20
Your marketeers need to learn there's no faster way to turn some of us of= f
to an editor than praise its comparison to those pieces of crap. I worked= =20
vi
classic for 2 years, and vim for 2 years, and I will do anything to avoid
them.

Opinionated, or just ignorant? You seem quite happy to label the two most=
=20
popular text editors by usage ( excluding notepad ) as crap.
And yes, their popularity isn't just because of lack of other options.


If you all do indeed mean vim-like power without the f~~~ed up keystrokes,


I think you meant to type modal editing.=20

find another way to say it. CUA keystrokes provide the flattest possible

learning curve for modern programmers...

Huh, what good is a short learning curve if you end up learning all the=20
features of a very basic editor?




--

Phlip
http://www.greencheese.org/ZeekLand <-- NOT a blog!!!
=20
=20
=20
=20

--=20
Into RFID? www.rfidnewsupdate.com <http://www.rfidnewsupdate.com> Simple,=
=20
fast, news.

------=_Part_30490_15357988.1127007451690--

 

[Florian Groß]

For example, in Java/C# etc. you have to declare the type of any and
every variable you create.

This is changed in C# 3. You will be able to do var and AFAIK there is
even experiments with automatically specifying generic collections to a
specific type if you only ever put in objects of that type.

I guess I'm increasingly more sounding like a C# fan boy, but I think it
is going into an interesting direction...

 

[ToRA]

Hey again,

Further to that, I probably should explicitly point out that in Ruby
the type model is subtly different than most(?) of the rest of the
other languages being mentioned, since a valid type for something in
ruby is one that can respond to the appropriate messages/method calls.
This is 'Duck' or structural typing, as opposed to the explicit type
tree that java et al have.

So really, you don't have operator overloading in the classical sense,
an operator is just a message the lhs can respond to when passed a rhs
argument.

Types then become sets of methods, and super/subclass relations become
sub/superset relations on those method sets.

Static type inference then becomes a hefty job of filling in those sets
and checking constraints, which if you google on it, will turn up has
already been done (to varying degrees) for javascript and python.

Tris.

 

[gabriele renzi]

Lothar Scholz ha scritto:

You
can't do type inference with overloaded operators. I don't know
Haskell but i know a little bit of OCAML and there you have to use the
ugly floating point operators "+." etc.

Otherwise there is nothing the compiler can find out.

well, haskell is able to handle overloaded operators, see here:
http://www.haskell.org/tutorial/classes.html

But I think that the Haskell model would be quite hard to retrofit into
ruby, anyway

 

[gabriele renzi]

Florian Groß ha scritto:

This is changed in C# 3. You will be able to do var and AFAIK there is
even experiments with automatically specifying generic collections to a
specific type if you only ever put in objects of that type.

in C# 2.0 there is type inference for delegates IIRC

I guess I'm increasingly more sounding like a C# fan boy, but I think it
is going into an interesting direction...

I somewhat agree, but I think the C# team made a great design error:
growing the language by stacking feature over feature over feature..

 

[Alexandru Popescu]

#: Robert Klemme changed the world a bit at a time by saying on 9/16/2005 10:16 AM :#

Btw, is J2EE enterprise ready? Is there a significant number of
applications out there that make full use of J2EE's feature set (including
scalability features) and serve large numbers of concurrent users? I'm
not prejudicing, just curious.

Regards

robert

Should I ask as Trans did on another mail: where've you been these last years? .

/alex

 

[Alexandru Popescu]

#: gabriele renzi changed the world a bit at a time by saying on 9/18/20=
05 12:36 PM :#

Florian Gro=DF ha scritto:
=20
in C# 2.0 there is type inference for delegates IIRC
=20
=20
I somewhat agree, but I think the C# team made a great design error:=20
growing the language by stacking feature over feature over feature..
=20
=20

From their point of view this is not a problem. They have the monopol so=
nobody will be able to=20
complain. On the other hand, on the Java world sometimes the things are m=
oving way too slow, because=20
there are many peons (for example generics where praised by users for cou=
ple of years). I don't have=20
the power to comment which approach is better, but I am getting the feeli=
ng that it is always in the=20
middle .

=2E/alex

 

[Robert Klemme]

#: Robert Klemme changed the world a bit at a time by saying on 9/16/2005
10:16 AM :#

Should I ask as Trans did on another mail: where've you been these
last years? .

Been busy with a non J2EE-Java application that is DB intesive. Also, I
prefer to participate in c.l.r over J2EE related forums. When I last
peeeked at J2EE it seemed bloated, complicated and more hype than reality.
Big players jumped on the train because they seemed to want to make big
bucks with big development environments for J2EE. But since I know that
some time has passed since they I asked.

Cheers

robert

 

[Martin DeMello]

If you all do indeed mean vim-like power without the f~~~ed up keystrokes,
find another way to say it. CUA keystrokes provide the flattest possible
learning curve for modern programmers...

The "learning curve" is a red herring here. You're making the classic
mistake of confusing "easy to learn" with "easy to use once learnt".

martin

 

[Devin Mullins]

When I last peeeked at J2EE it seemed bloated, complicated and more
hype than reality. Big players jumped on the train because they seemed
to want to make big bucks with big development environments for J2EE.
But since I know that some time has passed since they I asked.

Yeah, nothing's changed.

Oh, except there's a growing Spring subculture .

Devin
(Spring is an IoC container for Java, in case you live in a pineapple
under the sea.)

 

[Robert Klemme]

Yeah, nothing's changed.

Oh, except there's a growing Spring subculture .

Devin
(Spring is an IoC container for Java, in case you live in a pineapple
under the sea.)

In fact it's an octopus's garden - but don't tell anyone: I would not want
to get it crowded down here.

robert

 

[Thomas Sondergaard]

I think C# is becoming a sensible language. It's still statically typed,
of course, but it is improving heavily.

I couldn't agree more. I think what pushed many of us toward ruby was
the fact that the static type systems of Java, C# and C++ are getting in
the way all the time, but Microsoft is doing real work with C#/.net to
alleviate that problem. If they push it far enough, I think they just
might pull most of us back again (to mono)

Thomas

 

[Lyndon Samson]

------=_Part_32063_15150137.1127085770582
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

=20

=20
I couldn't agree more. I think what pushed many of us toward ruby was
the fact that the static type systems of Java, C# and C++ are getting in
the way all the time, but Microsoft is doing real work with C#/.net to
alleviate that problem. If they push it far enough, I think they just
might pull most of us back again (to mono)

No 1 immediate irritant when coding in java after ruby

No=20
return a,b,c

Very basic, but in the java world its getA, getB, getC, or pack into a=20
passed array.








Thomas

=20
=20

--=20
Into RFID? www.rfidnewsupdate.com <http://www.rfidnewsupdate.com> Simple,=
=20
fast, news.

------=_Part_32063_15150137.1127085770582--

 

[Phlip]

The "learning curve" is a red herring here. You're making the classic
mistake of confusing "easy to learn" with "easy to use once learnt".

The root principle of Usability (as a discipline for designing human-machine
interactions) is this: A GUI shall be easy for newbies to learn, and shall
not interfere with proficient user repeatedly accessing advanced features.

Vi fails both sides of the bargain, not because its keystrokes differ from
the magic CUA, but because they are inconsistent within themselves. Only
muscle memory permits proficient users to accomodate the many ways Vi cannot
even make up its own mind about the nature of text editing. The editor is
inconsistent even about simple concepts like whether a text cursor operates
on the left or right side of its character. When you type A for Append, you
move the right side, and I for Insert gives you the left side. It only does
that because it doesn't always treat \n as a character, so A fails at the
end of a line, and they added I to compensate. This would be almost
harmless, except that after typing new text, Vi remembers its confusion for
you, and Escape will move the text cursor to the left if Vi remembers you
typed an A.

Typing quickly without constantly readjusting your mental model of the
editor's state requires you to subconsciously remember and accomodate many
minor inconsistencies like these. 2 of my 4 years using Vi were with Vi
classic, the kind that did not even support a modern keyboard's cursor keys.
I have seen people type, faster than I ever could, in classic mode on modern
Vim. It's a scary sight, and a reminder that complete Vi proficiency is
inaccessible to many people, even if only in terms of their aptitude for
menial keyboarding prowess.

 

[Florian Groß]

I somewhat agree, but I think the C# team made a great design error:
growing the language by stacking feature over feature over feature..

I think they have been picking quite a minimalist set considering where
they came from. (After all they couldn't really have called it C# if it
was dynamically typed and not an imperative language...)

 

[Isaac Gouy]

This is changed in C# 3. You will be able to do var and AFAIK there is
even experiments with automatically specifying generic collections to a
specific type if you only ever put in objects of that type.

I guess I'm increasingly more sounding like a C# fan boy, but I think it
is going into an interesting direction...

Yes, C# 3.0 and VB9 are going in a very interesting direction.

There's something hilarious about the idea that VB could be a cool
language - but WOW these are mainstream languages with a sizable
userbase.

 

[Brock Weaver]

------=_Part_7755_5246533.1127233283721
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Remember when Java was the new guy in town (ca. 1995)? "It's too slow, too=
=20
unstable, too ..." etc. That is the stage Ruby is at now.

Java has turned out to be a very successful language. Some may argue it is=
=20
not a "good" language as it makes certain compromises ("joe" =3D=3D "joe"=
=20
returns false -- now that seems weird, albeit correct since there is no=20
operator overloading). However, it is successful nonetheless. If you'll=20
notice the initial "downfalls" of Java early on are no longer issues --=20
JVM's have come a long way in the past few years both speed wise and=20
stability wise.

Ruby is nearing this tipping point now. The language is certainly powerful=
=20
enough -- I believe it mixes all the "good" portions of today's mainstream=
=20
languages with very little of the "bad". But performance is still a concern=
,=20
stability is still a concern, etc.

For any of you who have hosted busy ASP.NET <http://ASP.NET> webservices,=
=20
you could say the same of .NET 1.1 -- stability is still an issue (who's=20
surprised by that? Anyone? ), yet it is viewed as "enterprise ready".

Ruby will get to the point of stability which Java enjoys now. It may be=20
awhile until some of the kinks are worked out, but with the multitude of=20
developers beginning to at least try it out, there is nowhere to go but up.

You can argue the benefits of different languages until you're blue in the=
=20
face, but at the end of the day what matters is this: whatever it takes for=
=20
one to generate robust, concise, maintainable, straightforward code that=20
performs within an acceptable timeframe is what should be used. This means=
=20
different things to different people, and we usually get lost in the=20
details. But I believe whatever language someone views as fulfilling these=
=20
requirements is what s/he will use. I also believe Ruby can fill that niche=
=20
for several developers if they give it a fair run.

[steps off soapbox]

=20

=20
Yes, C# 3.0 and VB9 are going in a very interesting direction.
=20
There's something hilarious about the idea that VB could be a cool
language - but WOW these are mainstream languages with a sizable
userbase.
=20
=20
=20

--=20
Brock Weaver
(e-mail address removed)

/* you are not expected to understand this */

------=_Part_7755_5246533.1127233283721--