What is the current preferred way to save user preferences in dotnet? Is the
registry the right place to do this? Can anyone recommend a good article (or
book) for this topic? Thanks.
41  3359 
"Mountain Bikn' Guy" <vc@attbi.com> wrote in message
news:K2rvb.199258$mZ5.1480585@attbi_s54... What is the current preferred way to save user preferences in dotnet? Is
the registry the right place to do this? Can anyone recommend a good article
(or book) for this topic? Thanks.
For a desktop app, save information in per-user registry keys, or in XML
files kept in per-user folders. I have some discussion about this in my
book, but frankly the documentation for the methods is fairly
straightforward. See the help on Application.UserAppDataPath and
Application.UserAppDataRegistry. Keep in mind that new folders and registry
keys will be generated for each version of your app that writes to these
locations, so you'll want to start managing your version numbers before you
start using these properties.
--
Mickey Williams
Author, "Microsoft Visual C# .NET Core Reference", MS Press www.servergeek.com
My preference is to define a class that holds them all and then serialize it
out to a file in the per-user directory
(Environment.GetFolderPath(SpecialFolder.Applicati on) is the location).
That seems to work nicely.
--
Eric Gunnerson
Visit the C# product team at http://www.csharp.net
Eric's blog is at http://blogs.gotdotnet.com/ericgu/
This posting is provided "AS IS" with no warranties, and confers no rights.
"Mountain Bikn' Guy" <vc@attbi.com> wrote in message
news:K2rvb.199258$mZ5.1480585@attbi_s54... What is the current preferred way to save user preferences in dotnet? Is
the registry the right place to do this? Can anyone recommend a good article
(or book) for this topic? Thanks.
Momento
"Eric Gunnerson [MS]" <er****@online.microsoft.com> wrote in message
news:u6**************@TK2MSFTNGP12.phx.gbl... My preference is to define a class that holds them all and then serialize
it out to a file in the per-user directory
(Environment.GetFolderPath(SpecialFolder.Applicati on) is the location).
That seems to work nicely.
--
Eric Gunnerson
Visit the C# product team at http://www.csharp.net
Eric's blog is at http://blogs.gotdotnet.com/ericgu/
This posting is provided "AS IS" with no warranties, and confers no
rights. "Mountain Bikn' Guy" <vc@attbi.com> wrote in message
news:K2rvb.199258$mZ5.1480585@attbi_s54... What is the current preferred way to save user preferences in dotnet? Is
the registry the right place to do this? Can anyone recommend a good article
(or book) for this topic? Thanks.
Thanks. I'll get a copy of your book. It's one of the few C# books I don't
already have. I guess I just needed an excuse to get it and you just gave me
a good one. ;)
(Notice to authors: in exhange for really good and quick replies to my
posts, I'll purchase a copy of your book. How's that for a deal? ;)
However, in this case I think I'll use Eric's suggestion for saving user
preferences. (...I already have Eric's book. It's one of my favorites.)
Regards,
Mountain
P.S. The book I'm most excited about reading next is "Build Your Own .Net
Language and Compiler" by Edward G. Nilges, Josef Finsel
"Mickey Williams" <my first name at servergeek.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl... "Mountain Bikn' Guy" <vc@attbi.com> wrote in message
news:K2rvb.199258$mZ5.1480585@attbi_s54... What is the current preferred way to save user preferences in dotnet? Is the registry the right place to do this? Can anyone recommend a good article
(or book) for this topic? Thanks.
For a desktop app, save information in per-user registry keys, or in XML
files kept in per-user folders. I have some discussion about this in my
book, but frankly the documentation for the methods is fairly
straightforward. See the help on Application.UserAppDataPath and
Application.UserAppDataRegistry. Keep in mind that new folders and
registry keys will be generated for each version of your app that writes to these
locations, so you'll want to start managing your version numbers before
you start using these properties.
--
Mickey Williams
Author, "Microsoft Visual C# .NET Core Reference", MS Press
www.servergeek.com
"Mountain Bikn' Guy" <vc@attbi.com> wrote in message news:<cYLvb.209194$ao4.744288@attbi_s51>... Thanks. I'll get a copy of your book. It's one of the few C# books I don't
already have. I guess I just needed an excuse to get it and you just gave me
a good one. ;)
(Notice to authors: in exhange for really good and quick replies to my
posts, I'll purchase a copy of your book. How's that for a deal? ;)
However, in this case I think I'll use Eric's suggestion for saving user
preferences. (...I already have Eric's book. It's one of my favorites.)
Regards,
Mountain
P.S. The book I'm most excited about reading next is "Build Your Own .Net
Language and Compiler" by Edward G. Nilges, Josef Finsel
Josef had the idea and I am in his debt. He is a real nice guy who
already has some great books to his credit, and I urge you to look up
his work on Amazon, including The Reluctant Data Base Administrator's
Handbook. It is a book for a programmer who's been told by his manager
that he is now a DBA.
But Josef had to bail out of the actual writing of the book and I am
finishing it up for release early next year. I have written a compiler
for most of Quick Basic and spend the meat of the book in explaining
how that's done, using object oriented techniques, recursive descent,
and BNF.
I use Visual Basic and not C# to appeal to a wide audience.
"Mickey Williams" <my first name at servergeek.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl... "Mountain Bikn' Guy" <vc@attbi.com> wrote in message
news:K2rvb.199258$mZ5.1480585@attbi_s54... What is the current preferred way to save user preferences in dotnet? Is the registry the right place to do this? Can anyone recommend a good article (or book) for this topic? Thanks.
For a desktop app, save information in per-user registry keys, or in XML
files kept in per-user folders. I have some discussion about this in my
book, but frankly the documentation for the methods is fairly
straightforward. See the help on Application.UserAppDataPath and
Application.UserAppDataRegistry. Keep in mind that new folders and
registry keys will be generated for each version of your app that writes to these
locations, so you'll want to start managing your version numbers before
you start using these properties.
--
Mickey Williams
Author, "Microsoft Visual C# .NET Core Reference", MS Press
www.servergeek.com
> I use Visual Basic and not C# to appeal to a wide audience.
rats
Yes by using VB you are sure to attract C# coders!! GENIUS!
"Edward G. Nilges" <sp*********@yahoo.com> wrote in message
news:f5**************************@posting.google.c om... "Mountain Bikn' Guy" <vc@attbi.com> wrote in message
news:<cYLvb.209194$ao4.744288@attbi_s51>... Thanks. I'll get a copy of your book. It's one of the few C# books I
don't already have. I guess I just needed an excuse to get it and you just
gave me a good one. ;)
(Notice to authors: in exhange for really good and quick replies to my
posts, I'll purchase a copy of your book. How's that for a deal? ;)
However, in this case I think I'll use Eric's suggestion for saving user
preferences. (...I already have Eric's book. It's one of my favorites.)
Regards,
Mountain
P.S. The book I'm most excited about reading next is "Build Your Own
..Net Language and Compiler" by Edward G. Nilges, Josef Finsel
Josef had the idea and I am in his debt. He is a real nice guy who
already has some great books to his credit, and I urge you to look up
his work on Amazon, including The Reluctant Data Base Administrator's
Handbook. It is a book for a programmer who's been told by his manager
that he is now a DBA.
But Josef had to bail out of the actual writing of the book and I am
finishing it up for release early next year. I have written a compiler
for most of Quick Basic and spend the meat of the book in explaining
how that's done, using object oriented techniques, recursive descent,
and BNF.
I use Visual Basic and not C# to appeal to a wide audience.
"Mickey Williams" <my first name at servergeek.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl... "Mountain Bikn' Guy" <vc@attbi.com> wrote in message
news:K2rvb.199258$mZ5.1480585@attbi_s54...
> What is the current preferred way to save user preferences in
dotnet? Is the > registry the right place to do this? Can anyone recommend a good
article (or > book) for this topic? Thanks.
For a desktop app, save information in per-user registry keys, or in
XML files kept in per-user folders. I have some discussion about this in
my book, but frankly the documentation for the methods is fairly
straightforward. See the help on Application.UserAppDataPath and
Application.UserAppDataRegistry. Keep in mind that new folders and
registry keys will be generated for each version of your app that writes to
these locations, so you'll want to start managing your version numbers
before you start using these properties.
--
Mickey Williams
Author, "Microsoft Visual C# .NET Core Reference", MS Press
www.servergeek.com
Luckly I will download you're book from peer2peer networks and not buy it.
Phew, dont want to waste my money on some VB book.
"Alvin Bruney" <al**********@telia.com> wrote in message
news:Oz**************@TK2MSFTNGP11.phx.gbl... Yes by using VB you are sure to attract C# coders!! GENIUS!
"Edward G. Nilges" <sp*********@yahoo.com> wrote in message
news:f5**************************@posting.google.c om... "Mountain Bikn' Guy" <vc@attbi.com> wrote in message
news:<cYLvb.209194$ao4.744288@attbi_s51>... Thanks. I'll get a copy of your book. It's one of the few C# books I don't already have. I guess I just needed an excuse to get it and you just gave me a good one. ;)
(Notice to authors: in exhange for really good and quick replies to my
posts, I'll purchase a copy of your book. How's that for a deal? ;)
However, in this case I think I'll use Eric's suggestion for saving
user preferences. (...I already have Eric's book. It's one of my
favorites.)
Regards,
Mountain
P.S. The book I'm most excited about reading next is "Build Your Own .Net Language and Compiler" by Edward G. Nilges, Josef Finsel
Josef had the idea and I am in his debt. He is a real nice guy who
already has some great books to his credit, and I urge you to look up
his work on Amazon, including The Reluctant Data Base Administrator's
Handbook. It is a book for a programmer who's been told by his manager
that he is now a DBA.
But Josef had to bail out of the actual writing of the book and I am
finishing it up for release early next year. I have written a compiler
for most of Quick Basic and spend the meat of the book in explaining
how that's done, using object oriented techniques, recursive descent,
and BNF.
I use Visual Basic and not C# to appeal to a wide audience.
"Mickey Williams" <my first name at servergeek.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
> "Mountain Bikn' Guy" <vc@attbi.com> wrote in message
> news:K2rvb.199258$mZ5.1480585@attbi_s54...
> > What is the current preferred way to save user preferences in dotnet? Is the
> > registry the right place to do this? Can anyone recommend a good article (or
> > book) for this topic? Thanks.
>
> For a desktop app, save information in per-user registry keys, or in XML > files kept in per-user folders. I have some discussion about this in my > book, but frankly the documentation for the methods is fairly
> straightforward. See the help on Application.UserAppDataPath and
> Application.UserAppDataRegistry. Keep in mind that new folders and
registry
> keys will be generated for each version of your app that writes to these > locations, so you'll want to start managing your version numbers before you
> start using these properties.
>
> --
> Mickey Williams
> Author, "Microsoft Visual C# .NET Core Reference", MS Press
> www.servergeek.com
>
>
>
>
"Mountain Bikn' Guy" <vc@attbi.com> wrote in message news:<mHSvb.209956$275.783419@attbi_s53>...
I use Visual Basic and not C# to appeal to a wide audience.
rats
Sorry you feel that way. Here's my reasoning.
All or most C# programmers know Visual Basic, but not all Visual Basic
programmers know C#. Ergo I have a wider audience by using Visual
Basic.
C# allows more access to unmanaged facilities and features in general.
But, to show the basics of a compiler's front end, I need to Keep It
Simple and again accessible to programmers who use VB for the most
part.
You know, Brian Kernighan himself uses Visual Basic to teach Computer
Science 101 to non-majors, at Princeton University. He says he's
concerned to show America's best and brightest that programming is not
for dullards. Dave Hansen, also at Princeton, also opined to me that
doing a good job is more difficult using a language such as Cobol, the
VB of its day.
VB doesn't allow you to use pure pointers to point at void material,
invalid material, or the shimmering Moon: but this is a good thing.
There's no reason I can think of why a compiler would need untyped or
void data.
I will certainly concede that with Josef Finsel and with Dan Appleman
I decided in 2002 to use VB for the above reasons, and this was before
the move to C# at many shops in preference to VB.Net. I did not
foresee the popularity of C#, and, I can see its power at my current
"day job" where I use it.
I am in no mood to mount a typical, and profoundly narcissistic,
defense of Visual Basic, because over a career spanning thirty years,
I have heard too many rhodomontades, in defense of a programmer's
favorite language. I remain silent during these rhodomontades because
I abandoned the languages I started out with (1401 SPS and machine
language) as fast as I could...by debugging a nonworking Fortran
compiler in object code form. Since that time, I have programmed in
machine, several assemblers, Fortran,Cobol, Rexx, PL/I, True Basic,
Quick Basic, Visual Basic (3.. .Net), C#, C, C++, several special
purpose languages for the writing of scripts, and Spinoza, my own
language.
I have not found the language of the gods. This would be one in which
you did not need to write comments and in which clean compilation
would almost completely imply correct execution. Eiffel may be what I
am thinking about or object Spinoza.
My favorite language happens to be computer science and algorithms,
the common language of all programming languages.
Had Algol succeeded it might have become my favorite language, because
the designers of Algol were not in thrall to immediate corporate
needs, and because they foresaw (in their ideas about publication
languages) the need to couple the language to its presentation.
But, odds are you know VB, even if you dislike it. I can assure you
that the book will be free of excess respect for third party tools
which is characteristic of the VB community and shall instead stress
good algorithms which are uncharacteristic of the VB community. It
shall also be written in a witty and amusing fashion, also
uncharacteristic of the VB community. But, odds are you know VB, even if you dislike it.
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.
Hi Edward,
I still plan to buy your book, and I look forward to reading it. I am a bit
bummed that it uses VB and it sounds like a lot of other people here feel
the same way. I share Dave's habit of generally avoiding VB-targeted books.
You wrote a nice defense of your VB decision, but I can't help but thinking
that a C# focus didn't prevent Andrew Troelsen from becoming " #1 selling
author in the world on .NET" ( http://www.otug.org/meeting/200205.html) and
winning numerous other #1 awards for C# and the .NET Platform.
My own guess (worth about 2 cents) is that a VB focus will hurt your book
sales more than help, in today's climate.
Anyway, I'm still going to purchase your book!
Regards,
Mountain
"Dave" <no****************@wi.rr.com> wrote in message
news:OT**************@tk2msftngp13.phx.gbl... But, odds are you know VB, even if you dislike it.
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.
"Dave" <no****************@wi.rr.com> wrote in message news:<OT**************@tk2msftngp13.phx.gbl>... But, odds are you know VB, even if you dislike it.
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.
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.
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.
"Dave" <no****************@wi.rr.com> wrote in message news:<OT**************@tk2msftngp13.phx.gbl>... But, odds are you know VB, even if you dislike it.
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.
In the 1970s, several books such as Fortran With Style came out and
sold, to the best of my knowledge, very well to Fortran programmers
ashamed of having to use languages that were already unfashionable.
Fortran With Style showed how programming with some dignity was
possible even if you had to use Fortran.
What I call programming with dignity is what PJ Plauger has called
Programming on Purpose, and my experience is that it is possible to
write undignified, offensive and foul code to no purpose in any
language: my kid found a C++ program that was written in this
fashionable and "advanced" language as a single main() procedure.
The authors of Fortran With Style made a discovery which I made
simultaneously, in 1974. This was that you did not have to use one of
the "structured" languages to write structured code. But the
widespread bad practice in languages like Fortran, Basic and Cobol
created the perception that the bad practice was caused by the
language.
But we know who to blame for bad practice and I am certain that this
includes programmers who haven't learned their trade but use a
fashionable language in which to wreak havoc. I am equally certain
that youse guys have learned your trade, in part because your favorite
languages teach good practice. I would agree that a programmer who
knows Basic only in all probability doesn't know his job (although one
of my students was a Basic-only programmer and knew his job).
I will review your comments with my publisher.
Power to the People,
Ed
> I will review your comments with my publisher.
That's awesome!!! Maybe there is some (C#) hope after all!
If you minimize the VB and make the book a C# focused book, I"ll personally
buy 4 copies instead of 1.
"Mountain Bikn' Guy" <vc@attbi.com> wrote in message news:<rqewb.214740$mZ5.1619829@attbi_s54>...
I will review your comments with my publisher.
That's awesome!!! Maybe there is some (C#) hope after all!
If you minimize the VB and make the book a C# focused book, I"ll personally
buy 4 copies instead of 1.
Don't have any expectations in this area. The book was delayed by my
other committments, and until now I haven't had this type of feedback.
I am sure you can read Visual Basic.
Also, note that a large part of the book consists of a rich GUI that
shows in detail what a compiler does, and, VB is best for this.
I still have to crank a compiler for miniature Algol for the book.
Based on your comments, I will consider using C sharp.
Edward,
Thanks for your feedback. I'm looking forward to the book. I'll be happy to
proof read drafts and give you other feedback in any way that can be
helpful.
Regards,
Mountain
"Edward G. Nilges" <sp*********@yahoo.com> wrote in message
news:f5**************************@posting.google.c om... "Mountain Bikn' Guy" <vc@attbi.com> wrote in message
news:<rqewb.214740$mZ5.1619829@attbi_s54>...
I will review your comments with my publisher.
That's awesome!!! Maybe there is some (C#) hope after all!
If you minimize the VB and make the book a C# focused book, I"ll
personally buy 4 copies instead of 1.
Don't have any expectations in this area. The book was delayed by my
other committments, and until now I haven't had this type of feedback.
I am sure you can read Visual Basic.
Also, note that a large part of the book consists of a rich GUI that
shows in detail what a compiler does, and, VB is best for this.
I still have to crank a compiler for miniature Algol for the book.
Based on your comments, I will consider using C sharp.
"Edward G. Nilges" <sp*********@yahoo.com> wrote in message
news:f5**************************@posting.google.c om... "Mountain Bikn' Guy" <vc@attbi.com> wrote in message
news:<rqewb.214740$mZ5.1619829@attbi_s54>...
I will review your comments with my publisher.
That's awesome!!! Maybe there is some (C#) hope after all!
If you minimize the VB and make the book a C# focused book, I"ll
personally buy 4 copies instead of 1.
Don't have any expectations in this area.
Please use C#. I was very excited when I first heard
about the book, but now I find out that it's not C#
focused! Sorry, I can't buy it :(
Maybe Alvin Bruney has the right idea...
>Also, note that a large part of the book consists of a rich GUI that shows in detail what a compiler does, and, VB is best for this.
Just out of curiousity, why do you say that Visual Basic is best for this?
I was wondering the same thing.
"Kerry Sanders" <di****@NOSPAMyahoo.com> wrote in message
news:54********************************@4ax.com... Also, note that a large part of the book consists of a rich GUI that
shows in detail what a compiler does, and, VB is best for this.
Just out of curiousity, why do you say that Visual Basic is best for this?
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>
On Tue, 25 Nov 2003 17:18:42 GMT, "Mountain Bikn' Guy" <vc@attbi.com> wrote: I was wondering the same thing.
"Kerry Sanders" <di****@NOSPAMyahoo.com> wrote in message
news:54********************************@4ax.com.. . >Also, note that a large part of the book consists of a rich GUI that
>shows in detail what a compiler does, and, VB is best for this.
Just out of curiousity, why do you say that Visual Basic is best for this?
Kerry Sanders <di****@NOSPAMyahoo.com> wrote in message news:<54********************************@4ax.com>. .. Also, note that a large part of the book consists of a rich GUI that
shows in detail what a compiler does, and, VB is best for this.
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.
Kerry Sanders <di****@NOSPAMyahoo.com> wrote in message news:<uj********************************@4ax.com>. .. 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
On Tue, 25 Nov 2003 17:18:42 GMT, "Mountain Bikn' Guy" <vc@attbi.com> wrote:
I was wondering the same thing.
"Kerry Sanders" <di****@NOSPAMyahoo.com> wrote in message
news:54********************************@4ax.com.. . >Also, note that a large part of the book consists of a rich GUI that
>shows in detail what a compiler does, and, VB is best for this.
Just out of curiousity, why do you say that Visual Basic is best for this?
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/us...es#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
On Tue, 25 Nov 2003 17:18:42 GMT, "Mountain Bikn' Guy" <vc@attbi.com>
wrote:I was wondering the same thing.
"Kerry Sanders" <di****@NOSPAMyahoo.com> wrote in message
news:54********************************@4ax.com.. .
> >Also, note that a large part of the book consists of a rich GUI that
> >shows in detail what a compiler does, and, VB is best for this.
>
>
> Just out of curiousity, why do you say that Visual Basic is best for
this?
> 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/aldot...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.
"Mountain Bikn' Guy" <vc@attbi.com> wrote in message news:<oIKyb.384079$Fm2.396519@attbi_s04>...
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!
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#.
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/aldot...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.
> 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?" ;)
Edward G. Nilges <sp*********@yahoo.com> wrote: 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.
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.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
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
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP***********************@msnews.microsoft.co m... Edward G. Nilges <sp*********@yahoo.com> wrote: 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.
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.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
"Edward G. Nilges" <sp*********@yahoo.com> wrote in message
news:f5**************************@posting.google.c om...
Thanks for the information below, BTW.
Edward, here's another interesting item: http://groups.google.com/groups?hl=e...tngp13.phx.gbl
From: Roger Jack (rj***@worldnet.att.net)
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
"Edward G. Nilges" <sp*********@yahoo.com> wrote in message
news:f5*************************@posting.google.co m... "Dave" <no****************@wi.rr.com> wrote in message
news:<OT**************@tk2msftngp13.phx.gbl>... But, odds are you know VB, even if you dislike it.
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.
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.
Jon Skeet [C# MVP] <sk***@pobox.com> wrote in message news:<MP***********************@msnews.microsoft.c om>... Edward G. Nilges <sp*********@yahoo.com> wrote: 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.
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#".
Edward G. Nilges <sp*********@yahoo.com> wrote: 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?
<snip>
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.
<snip> 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#".
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.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Edward G. Nilges <sp*********@yahoo.com> wrote: I'd question this analogy, Jon.
<snip>
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.
I'm in agreement with Jon on this point, and actually, almost every point of
his response.
<snip> 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.
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!
<snip> 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#".
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
Jon Skeet [C# MVP] <sk***@pobox.com> wrote in message news:<MP************************@msnews.microsoft. com>... Edward G. Nilges <sp*********@yahoo.com> wrote: 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?
<snip>
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.
<snip>
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#".
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.
Edward G. Nilges <sp*********@yahoo.com> wrote: 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.
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.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jon Skeet [C# MVP] <sk***@pobox.com> wrote in message news:<MP************************@msnews.microsoft. com>... Edward G. Nilges <sp*********@yahoo.com> wrote: 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.
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
On 7 Dec 2003 22:13:09 -0800, sp*********@yahoo.com (Edward G. Nilges)
wrote:
<snip> (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
Edward G. Nilges <sp*********@yahoo.com> wrote: 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.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
> 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.
"Mountain Bikn' Guy" <vc@attbi.com> wrote in message news:<qV4Bb.271928$Dw6.929566@attbi_s02>... 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:
I didn't claim that "VB is superior to C#", because I started with
machine language and have used about 20 languages, all of which with
the exception of HTML are Turing equivalent. I made some points in
VB's favor.
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).
The way in which a programming language is "superior" is never as
important as the science-behind. Consider the strange statement of
hero computer scientist Edsger Dijkstra: "computing science is no
more about computers than astronomy is about telescopes".
Dijkstra was trying to draw our attention to a shared reality which
isn't "reified" (in the sense of being-a-thing) which to him was the
true subject of discourse.
Paradoxically, Dijkstra was at one and the same time obsessed with the
need for an elegant and persipicuous notation, and contemptuous of
claims for notation magic.
That is, I think, because Dijsktra, unlike an American computer
scientist, was educated in a European intellectual tradition with its
own limitations, its own flaws, but one based on Kant.
If I "cudgel my brains" like Second Gravedigger in Hamlet, I almost
apprehend that Kant foregrounded the unbreakability of the link
between language and reality to such extent that Kantianism is the
refusal to consider a language as a thing-in-isolation.
Therefore Dijkstra didn't reify and reduce the solution to using the
right notation while at the same time realizing that notation is
important.
I conclude that what's important is elegant code in a Turing complete
language and not this or that language artifact. There are limitations
to this view. You can write elegant code in Fortran but the audience
would be vanishingly small (this isn't the case with VB as a Coast
Pidgin and lingua franca of commerce).
I am thinking of my Indian coworkers in Fiji who to get a book must
pay Amazon for shipping and who use VB and not C# and I would like to
send the message that it's possible to compile business rules in their
language.
I want developers to be empowered as an Army of One to write a quick
simple parser in the many cases where the user has a need for an
unbounded set of solutions. Military science has discovered since the
"stosstruppen" of WWI that you advance by empowering the unit and the
individual.
My inspiration remains the fact that FBI agent Colleen Rowley
testified before Congress in Dec 2001 that her team, investigating
Moussaui and the other bad guys prior to Sep 11, COULD NOT enter
simple queries of the form "terroristAssociation And
attendsFlightSchool", and 3000 people died...possibly as a result (we,
as ordinary citizens, still don't know the full story although we, as
ordinary citizens of the USA, have a right to know).
Sequestration of compiler algorithms in a language favored by
highly-paid specialists in compilers has the organizational effect of
forcing MIS teams to use little-understood "solutions", and,
apparently in the case of the FBI, to have to wait for solutions that
never arrive.
I am not privy to the FBI data base and its design. But let us suppose
that it was running (as it might well be) on a mainframe in Langley
running IBM's Conversational Monitor System.
This aging system is programmed at the user interface level by a
language called Rexx.
My guess is that this language prompted Colleen for queries and sent
them to a server. My guess is that it could have preprocessed the
queries using a lexical analyzer and recursive descent parser, and
sent a stream of simple queries.
This "compiler" could have been written, in this possible scenario,
quickly, and was not because organizational pressures meant it was a
nonstarter.
In my own MIS experience, it seems that every time developers approach
a sort of "sound barrier" at which the user's system chaotically
changes from a single solution to a
language-for-talking-about-solutions, the system's design has a
nervous breakdown.
Vague references to overly abstract entities appear such as "tags"
which "tag" a query and modify the query in ways we know not. The
modification is carried out in secret and in code, in ways that may or
may not correspond to user needs.
This is why I'd like to democratize compiler arcana.
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
My personal experience is based on getting rejected from the Microsoft
compiler team last year. I was rejected because I haven't used C++
heavily. I think the plan is to use C++ going forward.
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.
My compiler foregrounds a glass box GUI so you can see what makes it
tick and VB remains, marginally, the best choice.
Edward, Thanks for your balanced comments. I was afraid I was going to get
blasted for my last post. ;) I just hope all this discussion isn't impeding
your progress on the book!
Mountain
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: godyuyu |
last post by:
i need change the system preferred audio device in my vc++ project ,but i can't find the resolution.I just want to know the method.
|
by: Ale K. |
last post by:
I got a Structure that handles all the Data for my DB Connections like, type
of database, usernames, servers,etc and i was wondering what was the best
approach to save that data.
What is the...
|
by: Luis |
last post by:
Hello All!
I know this may be beginner stuff but...
I was wondering if there is a way to save text from a text box to an
Application Configuration file and maybe hash it so that the text in the...
|
by: pealy2 |
last post by:
Sorry if this is in the wrong group, I've searched long & hard without
finding anything even slightly useful. (recommendations for a more
relevant group gratefuly received)
I need to change the...
|
by: Laserson |
last post by:
Hi! I have one question about SaveSetting() function. I have one checkbox
and i want to save it's state on form closing and then restore it on form
loading. How can i make it?
|
by: shapper |
last post by:
Hello,
In my Page's VB.NET code I am changing the value of the Profile
property NAME.
Profile.Name = tbName.Text
However, I need to change this property value from a class in my
App_Code...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
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: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |
