Re: Wild speculations about the "other" factors


"Bob Dawson" <RBDawson@xxxxxxxxxxx> wrote in message
news:454026b7$1@xxxxxxxxxxxxxxxxxxxxxxxxx
"Lurkio" wrote

offering what is effectively (to me) a me-too Pascal.NET
compiler with little (or no) inherent advantages over the
free C# one (other than to religious Pascal-ers),

Well, by that logic there's no reason for any language--other than C#--to
target the .NET environment,

Now your gettting with the program.

and I just don't think that's true. The truth
is that IL--much like a CPU instruction set--makes many many things
possible, and no single language exposes all of them or ever will. Rather,
each language tends to become a somewhat idiosyncratic view of the
underlying (perhaps virtual) machine: a perspective that focuses some
things
and obscures others.

A brilliant trojan horse, luring all comers in theoretically equality while
making C# the "golden boy" of the .NET marketplace.


And since any language does represent a set of trade-offs in design
choices
and resulting strengths and weakness, the decision to use C#, COBOL,
Eiffel,
VB, J#, Chrome, or yes, even Delphi is not entirely inconsequential.

Not entirely inconsqential, but inconsequential where it counts the most...
The marketplace. The strategy to prove technical equality for any "syntax"
and "compiler" that care to play in the sand-box while making damned sure no
business in its right mind would choose anything but C#, is brilliant.
Because MS has bet that no matter *how* you got to .NET, you will eventually
become a C# adherent, or remain forever outside the "inner circle".

For
that reason alone, while I'm perfectly happy to believe you if you say
that
you're personally language agnostic, I still think your claim that only a
'religious Pascal-er' would care about language choice is simply wrong.

As a programmer (a very important one, to be sure!), you'll have to
continually explain to your CEO/COO/CFO why you've chosen to dodge East
while 99 % of the software dev community has gone West. At the end of the
day, businesses will just hire the programmers they need on the
Syntax/Platform/OS they choose for their own business reasons.

Bob, I'm not saying you should start polishing your resume right this
second. I'm just saying, you might want to peak at it. (Joking!).

Meanwhile the angst of over .NET syntax will only to apply to a tiny subset
of the .NET community; while the .NET development community is only a subset
of the Windows I.T. applications programming community, which is only a
subset of the overall Software Development community. (Or do I have to give
you all a DICE demo, again?)


There are good reasons--based on the programmer, the requirements, or the
different natures of the languages themselves--to prefer one language over
another. Preference is not necessarily mere prejudice.


At the end of the day businesses will analyze the market place and go with
the safest choice in terms of ROI. Since MS has annointed C# to be its
chosen successor to VB as the Microsoft applications programming syntax,
then most Microsoft shops will follow that lead, even those coming from VB
for the most part. The forces involved are too strong.

Delphi for .NET, as a language choice, is only going to appeal to a very
small subset of the Delphi customer base that is so fixated on Pascal as a
syntax, that they'll ignore all the advantages migrating to C# offers is
..NET is indeed their intended migration path in the first place.

And the above argument is, of course, entirely independent of the fact
that
most Delphi programmers already have a mountain of code that they're going
to be maintaining and updating for years to come.

I have a mountain of code in Win32. It works fine in Win32, and I have no
reason to port it to a different platform on a windows OS, since it will
continue to run on Win32 and Win64. If my Win32 compiler doesn't get a
Win64 update, then I'll treat my Win32 as legacy code and cease further
growth of that codebase and begin transition to a more viable toolset with a
better future. I've rejected that idea that I won't have to rewrite my
server-side (socket servers) code for .NET because its just not true. And
since I value performance of my server side code, I'll opt for a lean, mean
and clean server solution and it won't be .NET.

-d


.

Relevant Pages

  • Re: FORTH levels
    ... Most working on a collaborative project do not choose the programming language they are using: it is thrust upon them by the needs of the collaboration. ... When Iverson and Hui came up with J-- in part to remove APL's special character set and make it more "user friendly" not much of a community formed around it. ... And people who are by not by any reasonable stretch of the term "programmers" seem to take to Perl. ... But RPN does not require a visible stack, any more than any language requires a visible stack to rebuild its semantic trees from its flat expression. ...
    (comp.lang.forth)
  • IDEs, syntactic vs. semantic highlighting, etc. (was Re: What is your favourite IDE? Eclipse DLTK!)
    ... ability to move from basic syntax highlighting of code to something more like ... While syntax highlighting is nice, ... I think we're starting to get into language design and language processor implementation issues here, and I'm all in favor of debating that. ... And how many programmers *really* program on a "team of one?" ...
    (comp.lang.ruby)
  • Re: [Lit.] Buffer overruns
    ... >>The C community is too far gone to even see that its obsession with the ... OS, language, compiler, et al. ... > availability and cost of programmers as well. ...
    (sci.crypt)
  • Re: Language to replace C
    ... I notice that you have abandoned a lot of C's syntax. ... I've been pondering language design issues for some ... new programmers that have never seen the language before. ... instead of char* argv, ...
    (comp.lang.c)
  • Re: About VS C++
    ... finding resumes with the ease of finding good programmers. ... played with the latest language for about a year or two gets the nod. ... represents about 5% of the software development process. ... syntax is the key to the long term success of software development, ...
    (borland.public.delphi.non-technical)