What is the current preferred way to save user preferences in dotnet?

[Kerry Sanders]

Yea... it kind of didn't make sense to me. The IDE is the same. Showing how to
use it would be graphical representations of the IDE itself. Conused.
<scratching head>

 

[Edward G. Nilges]

Just out of curiousity, why do you say that Visual Basic is best for this?

Until recently it had the best features for GUI design. And today, C#
code for GUIs is somewhat more complex either actually or potentially
in the sense that it can be changed in more flexible ways.

However, I'm using C# for another project and it is now as good for
GUIs as VB.

But you can forget about my finding the time, any time soon, to recode
10000 lines of great VB into great C#.

The first thing I'll probably do in a project like that is roar off
into The Great American VB to C# Conversion Tool.

That's because as a gentleman I should otherwise see myself, from on
high, as engaged in mere manual labor: putting parentheses around If
conditions, erasing Thens, and wrapping blocks in curly littly braces.

The result would be no better and no worse than the base code, because
the runtime is the same. Furthermore, I would reflect on my scandalous
overuse of "has-a" delegation and the resultant use of objects inside
objects, and the power of Inherits as I evolve from relatively flat
inheritance into deeper inheritance.

For using Inherits is like renting a car: using instantiated objects
is like owning a used car. When you Inherit a good object, you don't
have to worry about the engine falling out. When you delegate an
instantiated good object, the hooks might be wrong.

I should then say, are we not men: and, is it not unseemly therefore
for me to do this women's work. I would then either write the Great
American Conversion Tool or rewrite the compiler.

 

[Edward G. Nilges]

Yea... it kind of didn't make sense to me. The IDE is the same. Showing how to
use it would be graphical representations of the IDE itself. Conused.
<scratching head>

The initial concept and initial prototype were presented to Apress and
Dan Appleman in Oct 2001 when I did not foresee the popularity of C#.

The important issues to me remain the front end computer science.
Since I know about twenty languages I am unimpressed by language
chauvinism.

You guys are great programmers (if I may be permitted to butter y'all
up) NOT because you use C#. You guys are great programmers because
there is a science and an art of programming, of good ideas about
algorithm and data design, over and above the ways we code.

For example, the algorithms in Knuth's old books are today more
reliable than corresponding algorithms in numerical recipes because
(1) Knuth was a real computer scientist and (2) Knuth did not delegate
the dogwork of code to graduate student slaves as did, I think, the
Numerical Recipes gang.

The code in his old books is written in Mix assembly language, but his
explanations are so clear that one has only to structure the code in
one's language of choice to make a working product.

For example, I've implemented Knuth's linear probing technique for
hash tables in assembler, Cobol, PL/I, Visual Basic and C. The
important issue was remembering to tag deletes specially in order not
to short-circuit the search, not the details of the language. Knuth
explains this.

I do not show the IDE as screen shots in the book. Instead I show my
own forms, which coulda been developed in C#, in order to illustrate,
for example, my data model for representing a Quick Basic variable
type and variable.

The form shows clearly that a QB variable can be a Boolean, Byte,
Integer, (32-bit) Long, Single, Double, String, Variant or Array, and
that a Variant or Array are containers for types...which in the case
of the Variant can be "anything but Variant" or Array "anything but
array".

It shows that you need an "abstract" variant as the contained type in
Array because while a standalone variant must be "concrete" (with a
nonvariant type) a variant in an array can't be hardened with a type.

Oh and by the way. The current preferred way to save user preferences
to me is a data base, except for the connection string of course. This
is because changing App.Config is a massive hack and sucks totally.
You have to write to a copy in the bin file and the user must reboot
your application to see the change. If you recompile and forget about
the bin copy, all of your user's changes are lost. You are in hot
water.

Or, you can use the Registry. I do hope the Registry is not destined
for the glue factory at some future date. Also, in a network
situation, a data base allows you to force users to share settings
properly. If you wish to allow the user to change some settings you
can add a column to the table.

Eric Gunnerson's suggestion may however represent a preferred
Microsoft pattern and practice.

Back to C#. I thought, after attending the Author's conferences in
2001 and 2002 that language would be truly a lifestyle choice. It's
not. Offices that use VB .Net want newbies to use VB .Net so that the
grognards, the old guys, are not discombobulated, and vice-versa.

As a parlor game, I tried to think which language which character in
the Austin Powers series would use. Here are my suggestions.

Dr. Evil: VB.Net
Scott Evil: C#
Frau Farbissiner: HTML
Number Two: Cobol
Austin Powers: VB 3
Mrs. Kensington: Dreamweaver
Fat Bastard: Algol

 

[Mountain Bikn' Guy]

Edward,

I'm going to buy your book. I'm looking forward to it, but the fact of the
matter is that I do not read VB. I've never programmed in VB. (In the past I
have used C++, Java, plus a little prolog, etc., but the only language I use
now is C#). I know that isolated lines of code can sometimes look almost the
same, but complex code is far different between the two languages.
Therefore, the VB is a barrier for me.

Prior to your last message (to which I am responding), you were emphasizing
that VB would expand your audience. I disagreed (and presented Troelsen's
success as a case example). Now you seem to be reversing course and saying
that the reason for using VB is not that it will expand your audience, but
that you are stuck with a legacy decision:

The initial concept and initial prototype were presented to Apress and
Dan Appleman in Oct 2001 when I did not foresee the popularity of C#.

After my initial comment, I was reading an article on The Code Project
(www.codeproject.com) and ran across this message. The author of a VB
article was conversing with the author of a similar C# article:

"As an aside ... your article was posted only 3 days before mine, but has
waaaay more views . Maybe I should start posting in C# instead of VB..... "
(I think this link will work:
http://www.codeproject.com/vb/net/usersettings.asp?msg=557870&target=preferences#xx557870xx).

You can defend you decision as much as you wish (and I think the bulk of
your post is just a rationalization for the decision you are stuck with),
but for me the bottom line is that I would find your book more useable if it
were in C# and I believe your audience would be larger as well. But I guess
it doesn't matter at this point. I'm going to have to force myself to learn
VB to read your book, I guess. (It's not like I don't have other things to
do, and it's not like I will actually ever write code in VB either...)

Regards,
Mountain

The important issues to me remain the front end computer science.
Since I know about twenty languages I am unimpressed by language
chauvinism.

You guys are great programmers (if I may be permitted to butter y'all
up) NOT because you use C#. You guys are great programmers because
there is a science and an art of programming, of good ideas about
algorithm and data design, over and above the ways we code.

For example, the algorithms in Knuth's old books are today more
reliable than corresponding algorithms in numerical recipes because
(1) Knuth was a real computer scientist and (2) Knuth did not delegate
the dogwork of code to graduate student slaves as did, I think, the
Numerical Recipes gang.

The code in his old books is written in Mix assembly language, but his
explanations are so clear that one has only to structure the code in
one's language of choice to make a working product.

For example, I've implemented Knuth's linear probing technique for
hash tables in assembler, Cobol, PL/I, Visual Basic and C. The
important issue was remembering to tag deletes specially in order not
to short-circuit the search, not the details of the language. Knuth
explains this.

I do not show the IDE as screen shots in the book. Instead I show my
own forms, which coulda been developed in C#, in order to illustrate,
for example, my data model for representing a Quick Basic variable
type and variable.

The form shows clearly that a QB variable can be a Boolean, Byte,
Integer, (32-bit) Long, Single, Double, String, Variant or Array, and
that a Variant or Array are containers for types...which in the case
of the Variant can be "anything but Variant" or Array "anything but
array".

It shows that you need an "abstract" variant as the contained type in
Array because while a standalone variant must be "concrete" (with a
nonvariant type) a variant in an array can't be hardened with a type.

Oh and by the way. The current preferred way to save user preferences
to me is a data base, except for the connection string of course. This
is because changing App.Config is a massive hack and sucks totally.
You have to write to a copy in the bin file and the user must reboot
your application to see the change. If you recompile and forget about
the bin copy, all of your user's changes are lost. You are in hot
water.

Or, you can use the Registry. I do hope the Registry is not destined
for the glue factory at some future date. Also, in a network
situation, a data base allows you to force users to share settings
properly. If you wish to allow the user to change some settings you
can add a column to the table.

Eric Gunnerson's suggestion may however represent a preferred
Microsoft pattern and practice.

Back to C#. I thought, after attending the Author's conferences in
2001 and 2002 that language would be truly a lifestyle choice. It's
not. Offices that use VB .Net want newbies to use VB .Net so that the
grognards, the old guys, are not discombobulated, and vice-versa.

As a parlor game, I tried to think which language which character in
the Austin Powers series would use. Here are my suggestions.

Dr. Evil: VB.Net
Scott Evil: C#
Frau Farbissiner: HTML
Number Two: Cobol
Austin Powers: VB 3
Mrs. Kensington: Dreamweaver
Fat Bastard: Algol

 

[Mountain Bikn' Guy]

But you can forget about my finding the time, any time soon, to recode
10000 lines of great VB into great C#.

But you expect me (and your other readers who know C# but not VB) to find
the time to learn a new language? Which is more efficient: one code
translation by an experienced guy who knows 20 languages, or thousands of
people learning VB for the first time in order to read your book? (Actually,
most of those thousands would probably just not buy the book, but that's a
different issue.)

I can't be the only guy who used to love C++ and hate VB who has now
converted to C# and dotnet without ever writing a single line of VB!

The first thing I'll probably do in a project like that is roar off
into The Great American VB to C# Conversion Tool.

http://authors.aspalliance.com/aldotnet/examples/translate.aspx

http://www.ellkay.com/ConvertVB2CSharp.htm (also see
http://www.ellkay.com/Downloads/ConvertVB2CSharp.doc)


It looks like a very challenging job. Here are some excerpts from the docs:

What is not supported in the latest release?
a.. Conditionally compilation blocks with pre-processor directives not
supported. These include
a.. #Const,
b.. #ExternalSource,
c.. #If...Then...#Else, and
d.. #Region
b.. AddressOf
c.. AddHandler and RemoveHandler
d.. AddEvent. This command allows to add custom events. Even though all
design time generated events are converted custom AddEvents is not supported
e.. When. When command is used in exception handling along with Catch
command e.g. "Catch ex As Exception When y = 0".
f.. Declare statement is not supported.
E.g. of use:

Declare Function GetUserName Lib "advapi32.dll" Alias _

"GetUserNameA" (ByVal lpBuffer As String, ByRef nSize As
Integer) As Integer





Items that get converted but are not supported in C#
a.. Option Explicit: In C# all declarations are mandatory which means that
Option Explicit On is mandatory. Even though the converter copies this over,
it to be removed manually.
b.. Range in Select-Case-End Select: The Select-Case-End Select command in
VB .NET has some cool features. It allows us to specify a range or a list of
comma separated for checking in each Case statement. Unfortunately, this is
not supported in C#. If you are using any of these features, you will have
to manually fix the converted case statements.
c.. Stop: In VB .NET, another way to add a break point in code is via the
Stop command. A matching command does not exist in C#. The Stop gets copied
over and has to be removed manually.
d.. IsDbNull: This functions checks datatype for null value and it does
not exist in C#. Again, the code gets copied and you have to manually remove
it.
e.. On Error: This is a big one. Unfortunately, On Error and Resume are
not supported in C#. You've probably heard this before but I will re-iterate
it again; recommended path for exception handling is through
try-catch-finally commands. The good news from the conversion end is that
all labeled statement blocks and GoTo commands get converted to C#.
f.. CreateObject(): Does not exist in C# but gets copied over.
g.. VB .NET Static command: There is a static command in both VB .NET and
C#. Their meaning however is entirely different. The static in C# maps to
Shared in VB .NET and the conversion for Shared methods works. The Static
command in VB .NET is used in procedures (Sub) and it retains values of all
variables even after the termination of the procedure. C# does not have a
matching functionality.
h.. ReDim: This is not supported in C#.
i.. Type in For Each: In VB .NET, the For Each command does not support
declaring a type in the same line as the For Each. In C# it is exactly the
opposite; the type is required to be on the same line as the foreach. In
this case, the VB .NET code gets converted without a type and you have you
specify the type manually.







Work in Progress
Here are some of the items that we are still working on:

a.. SyncLock: SyncLock ensures that multiple threads do not execute the
same statements at the same time.
b.. Const: We have no idea how we missed declaring constants. <g> Example:
Protected Const x As Integer = 1
c.. Rem: Additional way to specify remarks in VB .NET
Support for Multiple Event Handlers: If an event is specified using the
Handles command, VB .NET allows to specify more than one event handler for
the method. Example you can have the one click method for your button1 and
button2 by specifying Sub MyClickMethod() Handles Button1.Clock,
Button2.Click. The current version only supports one event handler per
method. Basically, if you have not specified event handlers manually your
code will convert fine.

 

[Edward G. Nilges]

But you expect me (and your other readers who know C# but not VB) to find
the time to learn a new language? Which is more efficient: one code
translation by an experienced guy who knows 20 languages, or thousands of
people learning VB for the first time in order to read your book? (Actually,
most of those thousands would probably just not buy the book, but that's a
different issue.)

I can't be the only guy who used to love C++ and hate VB who has now
converted to C# and dotnet without ever writing a single line of VB!

But since you're great programmers, you can READ the strange language.
For example, I don't code in Java. However, at a conference I was able
to follow Java code because its semantics and its "issues" roughly
replicate .Net.

Furthermore, because you have a background in C++, this means that you
can get up to speed quickly in VB which is semantically simpler than
C++. I came to old Basics from assembler, Fortran, PL/I and Cobol.
Thus I was fortunate never to be part of the demotic Basic subculture
(which generated some really horrible code).

Dijkstra with his customary precision said that while Cobol is a
criminal offense, Basic is "merely" bad as one's first language.
Cobol, at least when I used it, was less programming and more a form
of muttering. But even old Basic provided enough features to use a
clear style derived from assembly language, in which you "virtually"
replicated structured patterns.

Thanks for the information below, BTW.

I am using C# on the job and I work for an excellent C# programmer. In
general and from where I sit it is a culture of true inheritance and
not delegation and this is an improvement.

For example, my compiler uses traditional collections as hash tables.
As such it has to enforce its "own" structure when, in the frequent
case, the collection contains subcollections. This necessitates
"inspect" methods which look through the collections for expected
structure.

Whereas using Inherits I could have implemented a deep level from the
abstract to the concrete. The problem would be the absence of multiple
inheritance in VB when a collection has to implement two different
interfaces.

Generics weren't ready when I started the project.

You've given me food for thought and I thank you. My next compiler
will be in C#.

 

[Mountain Bikn' Guy]

You've given me food for thought and I thank you. My next compiler
will be in C#.

And I thank you for the book you're working on! Since I can't hassle you any
further about C#, I guess now I can start asking, "How much longer before we
can buy the book?"

 

[Jon Skeet [C# MVP]]

But since you're great programmers, you can READ the strange language.
For example, I don't code in Java. However, at a conference I was able
to follow Java code because its semantics and its "issues" roughly
replicate .Net.

Sure, it's possible to read VB.NET if you're really a C# programmer and
vice versa - but that doesn't make it easy to learn other things. If I
wanted a book to teach me German, I wouldn't buy one which is written
in French. Sure, I could probably get by, with a bit of work and the
help of a dictionary, but there'd be too many obstacles in my way.
Similarly, if I were to buy any more .NET books, I would choose ones
where the examples were in C# rather than VB.NET.

There are enough good .NET books on the market now that there's no
reason to go for one which puts a barrier in the way of learning, in
terms of the language the examples are written in.

 

[Mountain Bikn' Guy]

Jon,
Well stated! Just yesterday I tried to follow a VB.NET example related to a
topic I had no experience with. The combination of an unfamiliar language
and a new topic made it not worth the trouble to use that example. The same
thing surely applies to a whole book. As I said before, show me a few lines
of VB and I'm sure I can figure it out without knowing VB (after all some
single lines of code are almost identical). But show me a complex example
with multiple methods, properties, classes, etc. and it looks very foreign
and very different from C#.

I also just noticed that Chris Sells's fantastic WinForms book (WinForms
Programming in C#) has a separate VB edition (Windows Forms Programming in
VB.NET.) Edward, it might pay to ask Chris how he managed to get both
versions out. In his case, the C# version came out in August and the VB
version in October (and he had a co-author, Justin Gehtland, for the VB
version).

Regards,
Mountain

 

[Mountain Bikn' Guy]

Thanks for the information below, BTW.

Edward, here's another interesting item:

http://groups.google.com/groups?hl=...ff&[email protected]


From: Roger Jack ([email protected])
Subject: Product to automatically convert VB.Net projects to C# - Beta
Testers wanted
View: Complete Thread (2 articles)
Original Format
Newsgroups: microsoft.public.dotnet.languages.csharp
Date: 2003-12-04 10:08:41 PST


Are you stuck maintaining VB.Net code when you prefer to work in C#? Our
C-Sharpener For VB tool is a Visual Studio Add-in that converts VB.Net
projects to C# projects. It translates the code and other project related
files.

We are looking for a limited number of Beta Testers to help test our new
tool. If you are interested, please go to

http://www.elegancetech.com/CSVB_Download.aspx?src=9

Thanks!

Roger Jack
Elegance Technologies, Inc.
www.elegancetech.com

 

[Ayende Rahien]

Knowing VB and wanting to read an entire book that uses nothing but VB will
limit its appeal, at least to me. I generally do not buy a book if it is
targeted to VB.

This book I hope will be an exception.

I could have written the compiler in C Sharp. I love bloody C Sharp.
But I agreed with Apress to write it in Visual Basic. Also, I would
like on behalf of the countless programmers who must use VB 24/7 to
show that advanced applications are possible in VB.[/QUOTE]

What about two editions?
I can read VB, I just don't like it.
Either it will make your book larger (a good selling point)
Or you can print it in two editions, one in C# and the other in VB.

Too many headhunters diss good programmers merely because the
programmers use an unfashionable language.

It's programming's form of the rejection of a person from the South
based on his accent.

There is nothing natural about opening a block with a left curly
brace, and to older programmers, who may have trouble disambiguating a
left curly brace from a left parenthesis, the keywords of VB may be
clearer.

That is a good point.

If mathematicians wasted half the time programmers waste on such
details: if mathematicians rejected the work of other mathematicians
*tout court* because the other mathematicians didn't use the
Politically Correct symbols, mathematical progress would slow to a
crawl.

You don't know about the equal wars?
= was the winner but there were many competitors.

 

[Edward G. Nilges]

Sure, it's possible to read VB.NET if you're really a C# programmer and
vice versa - but that doesn't make it easy to learn other things. If I
wanted a book to teach me German, I wouldn't buy one which is written
in French. Sure, I could probably get by, with a bit of work and the
help of a dictionary, but there'd be too many obstacles in my way.
Similarly, if I were to buy any more .NET books, I would choose ones
where the examples were in C# rather than VB.NET.

I'd question this analogy, Jon.

Natural languages, even of neighbors who can't stand each other like
the British and the French, carve the world up in different ways. They
have different semantics.

Therefore you cannot be certain that referents are the same. When the
Englishman refers to "the nation" he means something different from
the Frenchman's du pays. Why even the shimmering moon refers to
something different, with different connotations inherited from
literature, than la lune.

But in .Net you can bet, your sweet patootie, that the things
underneath the words are the SAME, and have the same connotations for
good or ill to the .Net developer.

Was this not, big fella, the whole motivation behind .Net? Wasn't its
purpose to unite the warring tribes and bring upon us a world of
peace, love and understanding between users of different languages?

I concede my praxis derives from the relatively flatter object models
of VB object development. A current C# project in my day job is giving
me all sorts of kewl ideas for using more Inheritance, ideas which
scare Dan Appleman (no, Dan, I am NOT going to rewrite the compiler
and yes Dan Chapter 8 of 11 will be done this weekend). But, of
course, compilers have been written (whether generated using tools or
by hand) for years using delegation and before that modules and before
that One Big Main Routine that three people in the world understood.

[The IBM 1401 compiler for Fortran was 99 phases on punched cards and
executing it was like singing "99 bottles of beer on the wall" in
summer camp. Two living people in the world understand it and one is
J. A. N Lee of the University of Virginia, the author in 1969 of The
Anatomy of a Compiler and the other might be me...still crazy after
all these years. But I digress.]

The issue you fellows raise is genuine but it is in part one of
perception. "Oh, that book uses VB for its examples I had better put
it back on the shelf and go read Maxim." But I claim that my
deliberate choice of VB will be a more pervasive and all-embracing
message. It will say to the world, including VB programmers, that
compilers do not, necessarily, have to be written in any one language.

It will foreground the theory as applied and not this or that
language.

I am reminded in this connection of a Cambridge University Press book,
"Non-numerical Programming in Fortran."

The title has for a geek a certain je ne sais quoi, a certain frisson,
and a surprise factor. This is because it is of high
information-theoretic content, as an unexpected message. You see on
the shelf book after book with expected titles and this one sticks
out.

"Hmm, let's see. GREAT HORNED TOAD it's a compiler book with examples
in Visual Basic. I must read further."

I used Non-Numerical Programming in Fortran to learn how to construct
a program that displayed numerical information with graphics
consisting of bar charts on the printer, and many other amusing
lessons. I'd say that the surprise factor, the je ne sais quoi, and
the great horned toad factor played a role in my use of the book.

Computing science is no more about computers than astronomy is about
telescopes, to quote the late hero computer scientist Dijkstra (who
passed away in August 2002). On the face of it this statement sounds
just wrong and like one of those marvelous but false European ideas,
like zoos, Zeppelins, Gauloises or the Schlieffen Plan. It sounds like
Kant's claim, at the beginning of Groundwork of a Metaphysic of
Morals, that the only thing we can know to be good is a good will as
if the road to hell, and all that rot.

But Dijkstra was right (as was Kant, whose thought influenced
Dijsktra, but das ist ein anders...ein Kann, der Wurmen.). It's a bad
mistake, not to be "abstract" and "academic", but basically to confuse
the two levels of concrete and abstract.

For the same reason T. S. Eliot wrote "I gotta use words when I talk
to you", we have to use SOME "programming language" when we
communicate information about programming, even if it is pseudo-code
or Algol's old idea of a "publication language."

A common language would be the end of language (this may be why
Esperanto never got off the ground), and the reason, I am now
convinced by reading Derrida, is that manufacture of language is the
manufacture of difference. In computing the symptom is the constant
way in which programs, even programs written in a shop common
language, become different worlds. Different personalities don't
explain the phenomenon.

Derrida shows us how language always consists of a physical "trace",
whether the "trace" is ink on paper or bits on silicon, and our basic
delusion, which he shows confuses the hell out of us, is that there is
any exit from this situation. In computing science we dream of a
common language but the ultimate end of this goal is one software
program written by the government, and we resist this wakeup call for
the OBVIOUS reasons.

If VB still had its own runtime, it would be a poor choice, I think,
to use VB to write a compiler. But with respect to the "lifestyle
choice" of language, .Net consists of the "stars" and I think we
should "hang loose" about language choices.

Postscript: my draft of the book exercises iron self-control and
except for occasional marginalia it is free of any philosophical
skylarking as seen above.

There are enough good .NET books on the market now that there's no
reason to go for one which puts a barrier in the way of learning, in
terms of the language the examples are written in.

Perhaps I should include an exercise in each chapter. "Rewrite the
examples in this chapter in C#".

 

[Jon Skeet [C# MVP]]

I'd question this analogy, Jon.

Natural languages, even of neighbors who can't stand each other like
the British and the French, carve the world up in different ways. They
have different semantics.

Therefore you cannot be certain that referents are the same. When the
Englishman refers to "the nation" he means something different from
the Frenchman's du pays. Why even the shimmering moon refers to
something different, with different connotations inherited from
literature, than la lune.

But in .Net you can bet, your sweet patootie, that the things
underneath the words are the SAME, and have the same connotations for
good or ill to the .Net developer.

But words are how things will be described, and they *do* differ for
the same thing. For instance, an indexer in C# is just called a
property with parameters in VB.NET, etc. This kind of thing can cause
confusion if you're not already comfortable with what's being
discussed.

However, the thrust of my analogy is that when reading VB.NET code
which is explaining something new to me, I have to make more mental
leaps than I do with C#. There's either an extra translation layer or
at least a much "thicker" translation layer - I'd end up needing to do
more work in order to learn the same things. Are you confident that
your book is *that* much better than the competition that it wouldn't
just be better for me (and people like me) to find a book which
explains things in a way which is simpler for me to take in?

The issue you fellows raise is genuine but it is in part one of
perception. "Oh, that book uses VB for its examples I had better put
it back on the shelf and go read Maxim." But I claim that my
deliberate choice of VB will be a more pervasive and all-embracing
message. It will say to the world, including VB programmers, that
compilers do not, necessarily, have to be written in any one language.

It's my perception that:

a) There are plenty of good .NET books around, and the chances are I
can find one that explains pretty much whatever I need explaining to me
using C# examples. If I want straight compiler theory, which doesn't
need to be .NET specific, I can go for one of the many classic compiler
texts which may well be in other languages I'm familiar with.

b) I find C# examples easier to read than VB.NET examples.

Are you actually disputing either of these?

I'm quite happy to acknowledge that VB.NET can be used for serious
purposes such as compilers, but I didn't need your book to be around to
tell me that.

It will foreground the theory as applied and not this or that
language.

<snip>

And that's fine - but while there *are* examples, I'd prefer to see
them in a language I'm already comfortable with.

"Hmm, let's see. GREAT HORNED TOAD it's a compiler book with examples
in Visual Basic. I must read further."

If you think that's the message it really gives out, that's fine - but
I can say for sure that it's *not* the message it would give out to me.

I used Non-Numerical Programming in Fortran to learn how to construct
a program that displayed numerical information with graphics
consisting of bar charts on the printer, and many other amusing
lessons. I'd say that the surprise factor, the je ne sais quoi, and
the great horned toad factor played a role in my use of the book.

We no doubt think in different ways then. I'd suggest that given the
other responses in this thread, there are plenty of other people who
think the way I do.

Perhaps I should include an exercise in each chapter. "Rewrite the
examples in this chapter in C#".

Perhaps. Then do it yourself, and publish a C# version of the book.
However much you justify your current position to yourself as striking
a blow for VB.NET, it will be losing you sales.

 

[Mountain Bikn' Guy]

But words are how things will be described, and they *do* differ for
the same thing. For instance, an indexer in C# is just called a
property with parameters in VB.NET, etc. This kind of thing can cause
confusion if you're not already comfortable with what's being
discussed.

I'm in agreement with Jon on this point, and actually, almost every point of
his response.

It's my perception that:

a) There are plenty of good .NET books around, and the chances are I
can find one that explains pretty much whatever I need explaining to me
using C# examples. If I want straight compiler theory, which doesn't
need to be .NET specific, I can go for one of the many classic compiler
texts which may well be in other languages I'm familiar with.

I guess this is the only point where I have a slight difference with Jon --
I don't have any classic compiler books sitting around. I'd have to go out
and find a good one. My only choices would probably be a compiler book in C
or C++, or Edward's new book. At this point I have the impression that
Edward's book, despite the VB hurdle, might be more useful because I am
doing all my real work in dotnet (C# of course). Maybe I should find a good
C compiler book and read it first. Jon is absolutely right about the use of
VB erecting an additional hurdle.

<snip>

And that's fine - but while there *are* examples, I'd prefer to see
them in a language I'm already comfortable with.
Absolutely!



Perhaps. Then do it yourself, and publish a C# version of the book.
Yes!

However much you justify your current position to yourself as striking
a blow for VB.NET, it will be losing you sales.

That is my opinion as well!

Mountain

 

[Edward G. Nilges]

But words are how things will be described, and they *do* differ for
the same thing. For instance, an indexer in C# is just called a
property with parameters in VB.NET, etc. This kind of thing can cause
confusion if you're not already comfortable with what's being
discussed.

However, the thrust of my analogy is that when reading VB.NET code
which is explaining something new to me, I have to make more mental
leaps than I do with C#. There's either an extra translation layer or
at least a much "thicker" translation layer - I'd end up needing to do
more work in order to learn the same things. Are you confident that
your book is *that* much better than the competition that it wouldn't
just be better for me (and people like me) to find a book which
explains things in a way which is simpler for me to take in?



It's my perception that:

a) There are plenty of good .NET books around, and the chances are I
can find one that explains pretty much whatever I need explaining to me
using C# examples. If I want straight compiler theory, which doesn't
need to be .NET specific, I can go for one of the many classic compiler
texts which may well be in other languages I'm familiar with.

b) I find C# examples easier to read than VB.NET examples.

Are you actually disputing either of these?

I'm quite happy to acknowledge that VB.NET can be used for serious
purposes such as compilers, but I didn't need your book to be around to
tell me that.


<snip>

And that's fine - but while there *are* examples, I'd prefer to see
them in a language I'm already comfortable with.


If you think that's the message it really gives out, that's fine - but
I can say for sure that it's *not* the message it would give out to me.


We no doubt think in different ways then. I'd suggest that given the
other responses in this thread, there are plenty of other people who
think the way I do.



Perhaps. Then do it yourself, and publish a C# version of the book.
However much you justify your current position to yourself as striking
a blow for VB.NET, it will be losing you sales.

I have no special brief for Visual Basic. I have no special affection
for the language.

But I am very concerned about language chauvinism, in part because it
gives headhunters and managers the unfortunate perception that if a
developer knows VB he would take months to get "up to speed" in C#, or
conversely.

There is a learning curve but for a good developer it is measured in
hours. The stuff that takes longer to learn consists in abstractions
including OO design theory which can be instantiated in either
language.

 

[Jon Skeet [C# MVP]]

I have no special brief for Visual Basic. I have no special affection
for the language.

But I am very concerned about language chauvinism, in part because it
gives headhunters and managers the unfortunate perception that if a
developer knows VB he would take months to get "up to speed" in C#, or
conversely.

There is a learning curve but for a good developer it is measured in
hours. The stuff that takes longer to learn consists in abstractions
including OO design theory which can be instantiated in either
language.

Absolutely, and I have no beef with that. However, if I want to learn
about a particular subject, I don't want to have to learn VB first, and
there's no reason why I *should* learn VB first.

 

[Edward G. Nilges]

Absolutely, and I have no beef with that. However, if I want to learn
about a particular subject, I don't want to have to learn VB first, and
there's no reason why I *should* learn VB first.

There are some good things in VB which aren't in C# to my knowledge
(corrections welcome):

(1) The With clause makes code better organized and more maintainable.
The With clause is an announcement to the program reader that the code
after the With and before the End With is "focused" upon a goal that
has to do with the variable named in the With clause.

(2) It's easier to get to Opacity and Opacity is just cool

(3) When you get to be my age, curly brackets are slightly harder to
see

(4) If you know VB you can get a job faster

(5) The relative paucity of threading choices means that as a project
manager you can enforce a simple discipline for enforcing thread
usage, and thread usage documentation.

The default class is "can't thread". An intermediate class Interlocks
anything in shared variables. A truly threadable class Synclocks the
object state in each Public procedure.

Keeps life simple.

(6) There are better facilities immediately available for string
handling

 

[ozbear]

On 7 Dec 2003 22:13:09 -0800, (e-mail address removed) (Edward G. Nilges)
wrote:

(1) The With clause makes code better organized and more maintainable.
The With clause is an announcement to the program reader that the code
after the With and before the End With is "focused" upon a goal that
has to do with the variable named in the With clause.

<snip>
Bzzzt...thanks for playing...

"with", in any language, is an abomination that obscures what is
being referenced.

Professional programmers don't use /with/.

Oz

 

[Jon Skeet [C# MVP]]

There are some good things in VB which aren't in C# to my knowledge
(corrections welcome):

<snip>

Even if I agreed with your points (and to be honest, I don't actually
agree with any of them apart from that knowing VB could help you to get
a job faster - because knowing something is pretty much always better
than not knowing something, and the point about the braces may or may
not be correct, but is irrelevant to me as *I* can see them perfectly
well) - even if I agreed with them, that doesn't mean I should have to
learn VB in order to learn about compiler theory. And of course, I
don't - so I wouldn't, as I'd buy a different book.

There are many things which aren't in VB or C# but are in Ruby or
Python, but that doesn't mean I'd buy a book which gave all its
examples in either of those languages either, unless the book were just
teaching me the language itself.

 

[Mountain Bikn' Guy]

There are some good things in VB which aren't in C# to my knowledge

(corrections welcome):

(1) The With clause makes code better organized and more maintainable.
The With clause is an announcement to the program reader that the code
after the With and before the End With is "focused" upon a goal that
has to do with the variable named in the With clause.

(2) It's easier to get to Opacity and Opacity is just cool

(3) When you get to be my age, curly brackets are slightly harder to
see

(4) If you know VB you can get a job faster

(5) The relative paucity of threading choices means that as a project
manager you can enforce a simple discipline for enforcing thread
usage, and thread usage documentation.

The default class is "can't thread". An intermediate class Interlocks
anything in shared variables. A truly threadable class Synclocks the
object state in each Public procedure.

Keeps life simple.

(6) There are better facilities immediately available for string
handling

Edward, I think it was a mistake on your part to imply that VB is superior
to C#, for several reasons:
1. This hints at the "language chauvinism" you have been saying you detest.
2. It won't be hard for most of the people on this newsgroup to make a
*longer* list of reasons why C# is better. Once that happens, are you going
to then change your position and base your book on C#? If not, you'll have
to explain why not, given that C# has been shown to be superior to VB by a
lot of intelligent people on this newsgroup (after all, you are the one that
initiated that topic).
3. C# is apparently Microsoft's language of choice for (much of) their next
generation operating system and framework. I'd be willing to bet that MS
favors C# over VB for compiler development. I assume it would be easy for
people more experience than me to argue that C# would be a better choice for
a book such as yours. Now that you have opened the discussion to the "best
choice", I don't see how VB can come out on top.