You joke, but this stuff happens. I'm not a startup, but I'm working on a native...

graycat · on Nov 2, 2014

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.

FourthProtocol · on Nov 2, 2014

It seems we share a similar philosophy. My SQL code is actually generated by the client. The server also generates its own SQL code, and does its own DB admin (create and drop tables, insert seed data and so on).

I think I need to look into TCP/IP sockets though. I have a very simple WCF service that accepts a byte array, and returns a byte array. No more, no less. The back-end deserializes the bytes and does what it needs to. WCF configuration is a Night! Mare! I think someone got completely spannered on the dependency injection koolaid. My service is a single method, and I spend more time babysitting XML in Web.Config than I do writing the service...

And yeah, with white space and comments my code base is around 120 LKOC. Just under 140 if I include the Windows Phone client.

graycat · on Nov 2, 2014

Long ago I concluded that in tools, ease of use was tools that were reliable, did fairly simple things, and were easy to understand how to use and not tools that tried to do a lot, do favors, anticipate what I wanted, and do more for (to!) me!

So, in a kitchen, I don't want a hot dog cooker and, instead, can, depending on what I want, just use a pot and with water and boil the hotdogs, use a skillet with some oil and fry the hot dogs, or go on the back porch, build a charcoal fire, and broil the hotdogs. Besides, for a hotdog cooker, how to clean the darned thing! And have to get it out of storage, set it up, etc. No thanks.

For cutting onions, use my best three tools in a kitchen, a good French chef's knife, a cutting board, and my hands. Works great also for potatoes, carrots, cabbage, garlic, and much more.

In a shop, have saws, hammers, files, wrenches, screwdrivers, a drill plate, drill bits, a nice, variables speed, reversible 3/8" electric (not battery powered -- don't want to mud wrestle with batteries that run down, need charging, go dead, wear out, get weak, need to be replaced, etc.) drill. Also socket wrenches, etc. But lots of automatic tools, e.g., a screwdriver that has a spiral shaft that push on to turn a screw, don't want.

To sharpen a kitchen knife? Sure, just use whatever grit size sand paper, usually silicon carbide, want, put the paper flat on the cutting board, and sharpen away.

Simple tools, that do simple things, and are reliable and easy to understand. Then, build more on those.

So, just use TCP/IP raw sockets and build more on those.

For a session state server, use TCP/IP raw sockets, de/serialization, and two collection classes. Piece of cake, no use of CONFIG whatever, no use of XML, only a few pages of documentation, lots of good, old code samples, rock solidly reliable ("TCP/IP sockets are the workhorse of all of the Web and Internet") etc. By far the easy way.

FourthProtocol · on Nov 3, 2014

My server is stateless. Definitely checking it out.