What I wrote is literally true, but maybe
there is some humor in there somewhere.

For WCF, LINQ, and WPF, we looked at the
documentation, and it was clear that just
working through the tough parts of the documentation
alone would be much more work than just writing
our code directly. Moreover, any bugs,
security problems, need for updates, etc. of
WCF, LINQ, and WPF we just neatly avoided.

And we saved maybe a lot of address space.

That is, it looked to us like, for us, YMMV,
WCF, LINQ, and WPF are a candle not worth
the match. I can believe that in some
situations those three could have some value;
for us, I don't see the value.

I mean, WCF boils down to TCP/IP raw sockets,
right? Well, the API to raw sockets is
about the easiest I/O one could hope for,
nearly as easy as the ancient Basic statement
PRINT or the same in C, etc. I tried for
several days to make sense out of WCF,
came up with zip, zilch, zero, nichts,
nil, nada, and gave up,
but I learned raw sockets in about three
hours one afternoon decades ago. To heck
with WCF.

For LINQ, that boils down to just SQL, right?
Well, SQL was supposed to be really easy to
use, is profusely documented, and has been,
for decades, has long been an ANSI
standard, has been tested in various ways,
and with astounding severity, around the world,
for decades, right? So, writing some SQL
is not so tough. Getting a connection
string to SQL Server? Yup, that took two
weeks of mud wrestling, but the SQL statements
were easy enough to write. SQL's fine.
Very glad to have it. SQL Server connection
string mud wrestling? Did I mention some
bad documentation? The full power of the
Microsoft Corporation still is unable
to document how to write SQL Server
connection strings. The only way I
learned was via Google searches wherever,
and then I did some organized trials
of essentially all possible combinations
of everything involved until it appeared
to work. I still don't know just why
what worked did and what didn't work
didn't. Cave men with burnt sticks
wrote better documentation on cave
walls.

For our SQL Server database schema,
that is, the specifications of
the tables, the columns, etc.,
we have a little file, just awash in
comments, nicely clear and easy to read,
that we run through
the wonderful SQLCMD.EXE -- "Look,
Ma, no GUIs!". And no clicking!
Instead, just type the name of a little
script, and presto, boom, have
a new database created just as
want, nearly no chance of anything
going wrong. It's better than most sex!

For the SQL Server Management Studio, can use
it read only a little and otherwise just
can't make sense out of most of the screens,
windows, sub-windows, check boxes, terminology,
concepts, etc.

So, for SQL Server administration,
just back to the simplest
little SQL statements, mostly industry standard.

The SQL Server documentation of users, logins,
etc. wins the prize for the worst technical
writing I ever saw. But, do some Google
searches, go to some Web sites, and see
that just some fairly simple SQL statements
are enough for such administration work.
So, get a collection of little SQL files,
run them through the wonderful, fantastic,
we're lovin' it, SQLCMD.EXE, document
the little files and their usage, and, fine --
f'get about Management Studio.

Basically, right, really prefer
command lines to GUIs! GUIs? Far
too difficult to understand,
get to work, script,
document, etc. We'll let the
cognitive psychologists at Xerox
PARC, Steve Jobs, etc. play with
direct manipulation GUIs, and we'll
stay with command lines, scripts
driving command lines, and a text
editor writing the scripts. Sorry
'bout that. To each their own.
If you like GUIs, then go for it.
YMMV.

WPF? Maybe that boils down to Windows
Forms for a native Windows application,
but our only GUI is HTML and CSS
with the little JavaScript ASP.NET writes
for us. If WPF boils down to HTML elements,
then, sure, we'll just use, directly, HTML elements
and/or the ASP.NET class wrappers for
those elements to make the HTML
programmable, that is, be able to
generate HTML elements via software
that executes for each user
uniquely after they connect.

So, we just saved having to read some
hundreds of Web pages at MSDN, buy
a cubic foot or so of books, do 500
Google searches about details, submit
100 questions to Stack Overflow and
the MSFT fora, etc.

Our code so far is about 30 KLOC
(that is, actual VB statements)
with maybe 60 KLOC of blank lines
and 100 KLOC of comments.