I Don’t Much Get Go

by Jon Davis 24. August 2010 01:53

When Google announced their new Go programming language, I was quite excited and happy. Yay, another language to fix all the world’s problems! No more suckage! Suckage sucks! Give me a good language that doesn’t suffer suckage, so that my daily routine can suck less!

And Google certainly presented Go as “a C++ fixxer-upper”. I just watched this video of Rob Pike describing the objectives of Go, and I can definitely say that Google’s mantra still lines up. The video demonstrates a lot of evils of C++. Despite some attempts at self-edumacation, I personally cannot read nor write real-world C++ because I get lost in the gobbligook that he demonstrated.

But here’s my comment on YouTube:

100% of the examples of "why C++ and Java suck" are C++. Java's not anywhere near that bad. Furthermore, The ECMA open standard language known as C#--brought about by a big, pushy company no different in this space than Google--already had the exact same objectives as Java and now Go had, and it has actually been fundamentally evolving at the core, such as to replace patterns with language features (as seen in lambdas and extension methods). Google just wanted to be INDEPENDENT, typical anti-MS.

While trying to take Go in with great excitement, I’ve been forced to conclude that Google’s own message delivery sucks, mainly by completely ignoring some of the successful languages in the industry—namely C# (as well as some of the lesser-used excellent languages out there)—much like Microsoft’s message delivery of C#’s core objectives somewhat sucked by refraining from mentioning Java even once when C# was announced (I spent an hour looking for the C# announcement white paper from 2000/2001 to back up this memory but I can’t find it). The video linked above doesn’t even show a single example of Java suckage; it just made these painful accusations of Java being right in there with C++ as being a crappy language to work with. I haven’t coded in Java in about a decade, honestly, but back then Java was the shiznat and code was beautiful, elegant, and more or less easy to work with.

Meanwhile, Java has been evolving in some strange ways and ultimately I find it far less appetizing than C#. But where is Google’s nod to C#? Oh that’s right, C# doesn’t exist, it’s a fragment of someone’s imagination because Google considers Microsoft (C#’s maintainer) a competitor, duh. This is an attitude that should make anyone automatically skeptical of the language creator’s true intentions, and therefore of the language itself. C# actually came about in much the same way as Go did as far as trying to “fix” C++. In fact, most of the problems Go describes of C++ were the focus of C#’s objectives, along with a few thousand other objectives. Amazingly, C# has met most of its objectives so far.

If we break down Google’s objectives themselves, we don’t see a lot of meat. What we find, rather, are Google employees trying to optimize their coding workflow for previously C++ development efforts using perhaps emacs or vi (Rob even listed IDEs as a failure in modern languages). Their requirements in Go actually appear to be rather trivial. It seems that they want to write quick-and-easy C-syntax-like code that doesn’t get in the way of their business objectives, that performs very fast, and fast compilation that lets them escape out of vi to invoke gcc or whatever compiler very quickly and go back to coding. These are certainly great nice-to-haves, but I’m pretty sure that’s about it.

Consider, in contrast, .NET’s objectives a decade ago, .NET being at the core of applied C# as C# runs on the CLR (the .NET runtime):

  • To provide a very high degree of language interoperability
    • Visual Basic and C++ and Java, oh my! How do we get them to talk to each other with high performance?
    • COM was difficult to swallow. It didn’t suck because its intentions were gorgeous—to have a language-netural marshalling paradigm between runtimes—but then the same objectives were found in CORBA, and that sucked.
    • Go doesn’t even have language interoperability. It has C (and only C) function invocators. Bleh! Google is not in the real world!
  • To provide a runtime environment that completely manages code execution
    • This in itself was not a feature, it was a liability. But it enabled a great deal, namely consolidating QA resources for low-level functionality, which in turn brought about instantaneous quality and productivity on Microsoft’s part across the many languages and the tools because fewer resources had to focus on duplicate details.
    • The Mono runtime can run a lot of languages now. It is slower than C++, but not by a significant level. A C# application, fully ngen’d (precompiled to machine-level code), will execute at roughly 90-95% of C++’s and thus theoretically Go’s performance, which frankly is pretty darn good.
  • To provide a very simple software deployment and versioning model
    • A real-world requirement which Google in its corporate and web sandboxes is oblivious to, I’m not sure that Go even has a versioning model
  • To provide high-level code security through code access security and strong type checking
    • Again, a real-world requirement which Google in its corporate and web sandboxes is oblivious to, since most of their code is only exposed to the public via HTML/REST/JSON/SOAP.
  • To provide a consistent object-oriented programming model
    • It appears that Go is not an OOP language. There is no class support in Go. No objects at all, really. Just primitives, arrays, and structs. Surpriiiiise!! :D
  • To facilitate application communication by using industry standards such as SOAP and XML.
  • To simplify Web application development
    • I really don’t see Google innovating here, instead they push Python and Java on their app cloud? I most definitely don’t see this applying to Go at all.
  • To support hardware independence and portability
    • Although the implementation of this (JIT) is a liability, the objective is sound. Old-skool Linux folks didn’t get this; it’s stupid to have to recompile an application’s distribution, software should be precompiled.
    • Java and .NET are on near-equal ground here. When Java originally came about, it was the silver bullet for “Write Once, Run Anywhere”. With the successful creation and widespread adoption of the Mono runtime, .NET has the same portability. Go, however, requires recompilation. Once again, Google is not out in the real world, they live in a box (their headquarters and their exposed web).

And with the goals of C#,

  • C# language is intended to be a simple, modern, general-purpose, object-oriented programming language.
    • Go: “OOP is cruft.”
  • The language, and implementations thereof, should provide support for software engineering principles such as strong type checking, array bounds checking, detection of attempts to use uninitialized variables, and automatic garbage collection. Software robustness, durability, and programmer productivity are important.
    • Go: “Um, check, maybe. Especially productivity. Productivity means clean code.”
    • (As I always say, the more you know, the more you realize how little you know. Clearly you think you’ve got it all down, little Go.)
  • The language is intended for use in developing software components suitable for deployment in distributed environments.
    • Go: “Yeah we definitely want that. We’re Google.”
  • Source code portability is very important, as is programmer portability, especially for those programmers already familiar with C and C++.
    • Go: “Just forget C++. It’s bad. But the core syntax (curly braces) is much the same, so ... check!”
  • Support for internationalization is very important.
  • C# is intended to be suitable for writing applications for both hosted and embedded systems, ranging from the very large that use sophisticated operating systems, down to the very small having dedicated functions.
    • Go: “Check!”
    • (Yeah, except that Go isn’t an applications platform. At all. So, no. Uncheck that.)
  • Although C# applications are intended to be economical with regard to memory and processing power requirements, the language was not intended to compete directly on performance and size with C or assembly language.

Right now, Go just looks like a syntax with a few basic support classes for I/O and such. I must confess I was somewhat unimpressed by what I saw at Go’s web site (http://golang.org/) because the language does not look like much of a readability / maintainability improvement to what Java and C# offered up.

  • Go supposedly offers up memory management, but still heavily uses pointers. (C# supports pointers, too, by the way, but since pointers are not safe you must declare your code as “containing unsafe code”. Most C# code strictly uses type-checked references.)
  • Go eliminates semicolons as statement terminators. “…they are inserted automatically at the end of every line that looks like the end of a statement…” Sorry, but semicolons did not make C++ unreadable or unmaintainable
    Personally I think code without punctuation (semicolons) looks like English grammar without punctuations (no period)
    You end up with what look like run-on sentences
    Of course they’re not run-on sentences, they’re just lazily written ones with poor grammar
    wat next, lolcode?
  • “{Sample tutorial code} There is no implicit this and the receiver variable must be used to access members of the structure.” Wait, what, what? Hey, I have an idea, let’s make all functions everywhere static!
  • Actually, as far as I can tell, Go doesn’t have class support at all. It just has primitives, arrays, and structs.
  • Go uses the := operator syntax rather than the = operator for assignment. I suppose this would help eliminate the issue where people would type = where they meant to type == and destroy their variables.
  • Go has a nice “defer” statement that is akin to C#’s using() {} and try...finally blocks. It allows you to be lazy and disorganized such that late-executed code that should called after immediate code doesn’t require putting it below immediate code, we can just sprinkle late-executed code in as we go. We really needed that. (Except, not.) I think defer’s practical applicability is for some really lightweight AOP (Aspect Oriented Programming) scenarios, except that defer is a horrible approach to it.
  • Go has both new() and make(). I feel like I’m learning C++ again. It’s about those pesky pointers ...
    • Seriously, how the heck is
       
        var p *[]int = new([]int) // allocates slice structure; *p == nil; rarely useful
        var v  []int = make([]int, 100) // the slice v now refers to a new array of 100 ints

       
      .. a better solution to “improving upon” C++ with a new language than, oh I don’t know ..
       
        int[] p = null; // declares an array variable; p is null; rarely useful
        var v = new int[100]; // the variable v now refers to a new array of 100 ints

       
      ..? I’m sure I’m missing something here, particularly since I don’t understand what a “slice” is, but I suspect I shouldn’t care. Oh, nevermind, I see now that it “is a three-item descriptor containing a pointer to the data (inside an array), the length, and the capacity; until those items are initialized, the slice is nil.” Great. More pointer gobbligook. C# offers richly defined System.Array and all this stuff is transparent to the coder who really doesn’t need to know that there are pointers, somewhere, associated with the reference to your array, isn’t that the way it all should be? Is it really necessary to have a completely different semantic (new() vs. make())? Ohh yeah. The frickin pointer vs. the reference.
  • I see Go has a fmt.Printf(), plus a fmt.Fprintf(), plus a fmt.Sprintf(), plus Print() plus Println(). I’m beginning to wonder if function overloading is missing in Go. I think it is; http://golang.org/search?q=overloading
  • Go has “goroutines”. It’s basically, “go func() { /* do stuff */ }” and it will execute the code as a function on the fly, in parallel. In C# we call these anonymous delegates, and delegates can be passed along to worker thread pool threads on the fly with only one line of code, so yes, it’s supported. F# (a young .NET sibling of C#) has this, too, by the way, and its support for inline anonymous delegate declarations and spawning them off in parallel is as good as Go’s.
  • Go has channels for communication purposes. C# has WCF for this which is frankly a mess. The closest you can get to Go on the CLR as far as channels go is Axum, which is variation of C# with rich channel support.
  • Go does not throw exceptions. It panics, from which it might recover.

While I greatly respect the contributions Google has made to computing science, and their experience in building web-scalable applications (that, frankly, typically suck at a design level when they aren’t tied to the genius search algorithms), and I have no doubt that Google is an experienced web application software developer with a lot of history, honestly I think they are clueless when it comes to real-world applications programming solutions. Microsoft has been demonized the world over since its beginnings, but one thing they and few others have is some serious, serious real-world experience with applications. Between all of the web sites and databases and desktop applications combined everywhere on planet Earth through the history of man, Microsoft has probably been responsible for the core applications plumbing for the majority of it all, followed perhaps by Oracle. (Perhaps *nix and applications and services that run on it has been the majority; if nothing else, Microsoft has most certainly still had the lead in software as a company, to which my point is targeted.)

It wasn’t my intention to make this a Google vs. Microsoft debate, but frankly the fact that Go presentations neglect C# severely causes question to Go’s trustworthiness.

In my opinion, a better approach to what Google was trying to do with Go would be to take a popular language, such as C#, F#, or Axum, and break it away from the language’s implementation libraries, i.e. the .NET platform’s BCL, replacing them with the simpler constructs, support code, and lightweight command-line tooling found in Go, and then wrap the compiler to force it to natively compile to machine code (ngen). Honestly, I think that would be both a) a much better language and runtime than Go because it would offer most of the benefits of Go but in a manner that retains most or all of the advantages of the selected runtime (i.e. the CLR’s and C#’s multitude of advantages over C/C++), but also b) a flop, and a waste of time, because C# is not really broken. Coupled with F#, et al, our needs are quite well met. So thanks anyway, Google, but, really, you should go now.

Currently rated 3.2 by 6 people

  • Currently 3.166667/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: , , , ,

C# | F# | General Technology | Mono | Opinion | Software Development

Cascading .NET Versioning In The Path

by Jon Davis 16. December 2007 15:21

The .NET Framework v3.0 and v3.5 both broke some versioning rules, and I suppose there was good reason. Version 3.0 was just version 2.0 plus a few new DLLs for WPF, WCF, WF, and CardSpace. But those new technologies were huge, huge enough to give the .NET Framework a new version number. Meanwhile, though, the C# language and .NET Framework 3.5 forked off cosistency again, in a way that was unnecessary, and with double the damage. C# 3.0 runs on .NET 3.5 -- that is way too confusing. C# 3.0 compiles to the .NET 2.0 CLR. That is way too confusing, too. .NET Framework 3.5 builds on top of .NET Framework 3.0 and 2.0. That would make sense, except that v3.0 and v2.0 are sort of seperate entities.

If you open up C:\Windows\Microsoft.NET\Framework, you'll find each of these .NET Framework versions deployed in their own directory..

08/29/2007  12:30 AM    <DIR>          v1.0.3705
08/29/2007  01:01 AM    <DIR>          v1.1.4322
12/15/2007  03:13 PM    <DIR>          v2.0.50727
11/02/2006  08:15 AM    <DIR>          v3.0
11/19/2007  09:49 PM    <DIR>          v3.5
08/28/2007  05:22 PM    <DIR>          VJSharp

Incidentally, notice that v3.0 and v3.5 don't have build numbers, while the others do. Refer back to my rant about inconsistency. (Personally, I never liked the build numbers being there anyway.) Meanwhile, VJSharp is completely unversioned.

Then there are tons of utility files that do not belong in this directory at all, and Microsoft allowed a mess to be made in here:

08/29/2007  05:39 AM    <DIR>          1028
08/29/2007  06:58 AM    <DIR>          1030
08/29/2007  02:57 AM    <DIR>          1031
08/29/2007  03:10 AM    <DIR>          1035
08/29/2007  04:13 AM    <DIR>          1036
08/29/2007  06:05 AM    <DIR>          1040
08/29/2007  03:55 AM    <DIR>          1042
08/29/2007  07:27 AM    <DIR>          1043
08/29/2007  06:31 AM    <DIR>          1044
08/29/2007  05:16 AM    <DIR>          1046
08/29/2007  03:39 AM    <DIR>          1049
08/29/2007  03:23 AM    <DIR>          1053
08/29/2007  04:33 AM    <DIR>          2052
08/29/2007  04:53 AM    <DIR>          3082
11/01/2006  11:33 PM            72,704 NETFXSBS10.exe
02/20/2003  06:44 PM            36,354 NETFXSBS10.hkf
09/18/2006  02:32 PM            41,392 netfxsbs12.hkf
11/19/2007  09:09 PM            16,896 sbscmp10.dll
11/19/2007  09:09 PM            16,896 sbscmp20_mscorwks.dll
11/19/2007  09:09 PM            16,896 sbscmp20_perfcounter.dll
11/01/2006  11:33 PM             5,120 sbs_diasymreader.dll
11/01/2006  11:33 PM             5,120 sbs_iehost.dll
11/01/2006  11:33 PM             5,120 sbs_microsoft.jscript.dll
11/01/2006  11:33 PM             5,632 sbs_microsoft.vsa.vb.codedomprocessor.dll
11/01/2006  11:33 PM             5,120 sbs_mscordbi.dll
11/01/2006  11:33 PM             5,120 sbs_mscorrc.dll
11/01/2006  11:33 PM             5,120 sbs_mscorsec.dll
11/01/2006  11:33 PM             5,120 sbs_system.configuration.install.dll
11/01/2006  11:33 PM             5,120 sbs_system.data.dll
11/01/2006  11:33 PM             5,120 sbs_system.enterpriseservices.dll
11/01/2006  11:33 PM             5,120 sbs_VsaVb7rt.dll
11/01/2006  11:33 PM             5,120 sbs_wminet_utils.dll
11/19/2007  09:09 PM            16,896 SharedReg12.dll

Now we're one step closer to looking like the infamous Windows Registry. Each Microsoft employee or department gets to put his own file or entry wherever he wants, see? I wonder how many Microsoft employees have decided to move their office desks to the middle of the front lobby, besides the nice front desk lady(ies).

Anyway, the reason why I posted here is because, ironically, the .NET Framework does not appear in the PATH for some strange reason. I've always had to manually add "DOTNET", pointing to C:\Windows\Microsoft.NET\Framework\v1.1.4322 or ...\v2.0.50727 to my environment variables, then add %DOTNET% to my PATH. I used this regularly for tools like my own AssemblyLister so I could easily pre-JIT my assemblies for faster boot time (even if the trade-off is slower runtime performance). But this broke with v3.0 and it is still broken in v3.5, because there is no CLR and Framework directory that runs .NET Framework v3.5. .NET Framework v3.5, like v3.0, is just some add-on assemblies to v2.0. But if I were to reference only the v2.0 directory, I would only have the v2.0 framework (plus the GAC, which, fortunately, contains the v3.0 and v3.5 DLL assemblies, but not their utilities).

Fortunately, you can cascade the .NET versions in the PATH. I don't know why I didn't do this a long time ago, but the PATH environment variable, which is a semi-colon delimited list of directories in which to search for files in the file system shell without referencing their complete paths, is already a cascading list. In other words, when searching for a file using the PATH, the first directory listed is scanned first, then the second, and so on.

One thing I like about the .NET Framework versioning that Microsoft claimed that they are committed to when they were working on v2 was that the .NET Framework will try to be forwards-compatible and will always be backwards-compatible to assemblies targeting different versions of the CLR. This means that a v1.1 assembly can be run in a v2.0 CLR, and a v2.0 assembly might be able to run in a v1.1 CLR. In the end, it's just MSIL that the CLR breaks down into machine code at runtime (unless it's pre-JITted).

So as long as you're using an environment (such as cmd.exe or PowerShell) that splits the PATH string into multiple directores, recursively finding more %variables%, and scans them one by one in cascading order, you can effectively use a single environment variable to reference all of your .NET Framework directories at the same time, with the newer .NET Framework files taking priority over the older files. To do this, just add each .NET Framework version, starting with v3.5, then v3.0, then v2, then v1.1 (if v1.1 is installed), into a DOTNET environment variable, and then add %DOTNET% to your path.

  • DOTNET = C:\Windows\Microsoft.NET\Framework\v3.5; C:\Windows\Microsoft.NET\Framework\v3.0; C:\Windows\Microsoft.NET\Framework\v2.0.50727; C:\Windows\Microsoft.NET\Framework\v1.1.4322; C:\Windows\Microsoft.NET\Framework\v1.0.3705
  • PATH (virtually on %PATH%, not literally) = %PATH%;%DOTNET% 

By "virtually on %PATH%, above, all I mean is that you would replace %PATH% with what it already is, then append ";%DOTNET%".

If I wanted to use the 64-bit versions of the .NET Framework, I could do the same, using C:\Windows\Microsft.NET\Framework64\, but meanwhile also adding the x86 paths for compatibility.

  • DOTNETX64 =
     
    C:\Windows\Microsoft.NET\Framework64\v3.5; C:\Windows\Microsoft.NET\Framework64\v3.0; C:\Windows\Microsoft.NET\Framework64\v2.0.50727; C:\Windows\Microsoft.NET\Framework\v3.5; C:\Windows\Microsoft.NET\Framework\v3.0; C:\Windows\Microsoft.NET\Framework\v2.0.50727; C:\Windows\Microsoft.NET\Framework\v1.1.4322; C:\Windows\Microsoft.NET\Framework\v1.0.3705
     
    - or -

    C:\Windows\Microsoft.NET\Framework64\v3.5; C:\Windows\Microsoft.NET\Framework64\v3.0; C:\Windows\Microsoft.NET\Framework64\v2.0.50727; %DOTNET%
  • PATH = %PATH%;%DOTNETX64%

Unfortunately, though, this brings another issue into the mix. Which one do you want in your PATH, %DOTNET% or %DOTNETX64%? This is an important question. I do ASP.NET development in 32-bit and I debug my apps in explicit x86 CPU build mode (because Visual Studio doesn't let me perform edit-and-continue tasks in 64-bit, which is already the default environment for the "Any CPU" build mode). But without compiling to 64-bit, CLR assemblies can hit the RAM registry space ceiling, quickly running out of RAM (OutOfMemoryException or something similar), and this has happened to me already while building a search engine server based on Lucene.NET.

To be honest, I'm still not sure. I'm going to try using the 64-bit path variable (%DOTNETX64%) for now and see if it brings me any problems. I think Windows is defaulting to that one already. Meanwhile, though, I can still continue to target x86 CPUs in my builds.

So to test this out, I try where in Vista to see the cascading effect. (Note that any time you change the PATH environment variable, or any environment variable(s), you must close the command shell window and restart it before the variables will propogate. They will not propogate into the GUI shell until you log out and log back in.)

C:\Users\Jon>where ngen
C:\Windows\Microsoft.NET\Framework64\v2.0.50727\ngen.exe
C:\Windows\Microsoft.NET\Framework\v2.0.50727\ngen.exe
C:\Windows\Microsoft.NET\Framework\v1.1.4322\ngen.exe

So it seems to work, which is nice.

Meanwhile, I still need an environment variable to single directory for my primary CLR, which contains ngen.exe and csc.exe and other CLR essentials.

  • CLRDIR = C:\Windows\Microsoft.NET\Framework64\v2.0.50727

There's one last change I need to make, though. It might make more sense to change the environment variable %DOTNET% to %NETFXX86%, and then change %DOTNETX64% to %NETFX%. This way, apps that target a %NETFX% environment variable can properly target the environment's complete and CPU-targeted environment rather than just focus solely on x86 compatibility.

So, here's what I have in the end:

  • NETFXX86 =
     
    C:\Windows\Microsoft.NET\Framework\v3.5;
    C:\Windows\Microsoft.NET\Framework\v3.0;
    C:\Windows\Microsoft.NET\Framework\v2.0.50727;
    C:\Windows\Microsoft.NET\Framework\v1.1.4322;
    C:\Windows\Microsoft.NET\Framework\v1.0.3705
      
  • NETFXX64 =
     
    C:\Windows\Microsoft.NET\Framework64\v3.5;
    C:\Windows\Microsoft.NET\Framework64\v3.0;
    C:\Windows\Microsoft.NET\Framework64\v2.0.50727
     
  • NETFX = %NETFXX64%; %NETFXX86%
     
  • DOTNET = %NETFX%
     
  • CLRDIR = C:\Windows\Microsoft.NET\Framework64\v2.0.50727
      
  • PATH =
     
    C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin; %SystemRoot%\system32; %SystemRoot%; %SystemRoot%\System32\Wbem; %SYSTEMROOT%\System32\WindowsPowerShell\v1.0\; C:\Program Files (x86)\Microsoft SQL Server\90\Tools\binn\; C:\Program Files (x86)\Microsoft SQL Server\80\Tools\Binn\; C:\Program Files\Microsoft SQL Server\90\DTS\Binn\; C:\Program Files\Microsoft SQL Server\90\Tools\binn\; C:\Program Files (x86)\Microsoft SQL Server\90\DTS\Binn\; C:\Program Files (x86)\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE\; C:\Program Files (x86)\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies\; C:\Program Files (x86)\QuickTime\QTSystem\; C:\Program Files (x86)\Common Files\Adobe\AGL; C:\Windows\SUA\common\; C:\Windows\SUA\usr\lib\; C:\Program Files\Microsoft Network Monitor 3\; E:\filez\dev\IronPython-1.1; C:\Program Files (x86)\GnuWin32\bin; C:\ruby\bin; C:\MinGW\bin; C:\cygwin\bin;
    %NETFX%

Now I can use "native" .NET apps like csc.exe or ngen.exe, and have all tools and assemblies on hand, without manually loading the SDK command shell.

I created an EXE to auto-configure this: SetNetFxEnvVars.exe [source] Note that it will require an immediate reboot. Note also that if you're using Internet Explorer, in order to run the EXE you must download it and then unblock it (right-click it, choose Properties, then click Unblock).

kick it on DotNetKicks.com

Currently rated 3.0 by 2 people

  • Currently 3/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: , , , , , , , ,

Software Development | Microsoft Windows


 

Powered by BlogEngine.NET 1.4.5.0
Theme by Mads Kristensen

About the author

Jon Davis (aka "stimpy77") has been a programmer, developer, and consultant for web and Windows software solutions professionally since 1997, with experience ranging from OS and hardware support to DHTML programming to IIS/ASP web apps to Java network programming to Visual Basic applications to C# desktop apps.
 
Software in all forms is also his sole hobby, whether playing PC games or tinkering with programming them. "I was playing Defender on the Commodore 64," he reminisces, "when I decided at the age of 12 or so that I want to be a computer programmer when I grow up."

Jon was previously employed as a senior .NET developer at a very well-known Internet services company whom you're more likely than not to have directly done business with. However, this blog and all of jondavis.net have no affiliation with, and are not representative of, his former employer in any way.

Contact Me 


Tag cloud

Calendar

<<  September 2018  >>
MoTuWeThFrSaSu
272829303112
3456789
10111213141516
17181920212223
24252627282930
1234567

View posts in large calendar