I think you will struggle to hire good programmers willing to work in VB.NET. (For myself, I wouldn't take a job in anything short of scala or haskell. These aren't "easy" languages; in fact stereotypically they're "hard", but they allow me to write in a few lines something that would be dozens of repetitions of a pattern in a less powerful language. Programming in something else is boring and repetitive by comparison). You said before you were confident in the microsoft platform because of the large, busy websites using it; are any of those built on VB.NET?
>The challenges in writing significant Web site software are outside the language and in the APIs, e.g., the .NET Framework, ASP.NET, ADO.NET, also in the middle ware, e.g., IIS, SQL Server, and in some issues of system and network management, system security, etc.
Sounds like you think you don't really need much actual programming. Maybe the problem you're solving isn't really a technical one, and that's fine - in which case maybe you'll be fine with mediocre programmers and it would be a waste of money to hire top ones.
> For myself, I wouldn't take a job in anything short of scala or haskell.
Amazing.
> You said before you were confident in the microsoft platform because of the large, busy websites using it; are any of those built on VB.NET?
That about has to be the case: What is usually mentioned
is C#, but as far as I know what is doable in C# is always
or nearly so also doable in VB.NET. C# supports Lambda expressions, and I'm not yet sure that VB.NET does. It
may be easier to write efficient, polymorphic code in
C# than VB.NET. And there may be some other differences.
But assuming C# or VB.NET for the language, the rest about has to
be ASP.NET (with or without model-view-controller, MVC),
ADO.NET, SQL Server, IIS, the .NET Framework, JavaScript,
maybe some server side GDI or GDI+ for manipulating images,
etc.
Apparently the big deal for a big Web server farm
built on the Microsoft platform is ASP.NET and IIS and
the more advanced features of those two. E.g., I'm sure
there are ways to cache Web pages, but I haven't gotten
to them yet and likely won't before revenue if only
because the more important pages have to be built
one at a time and couldn't be cached; the Web pages that
could be cached are so small that it's not worth the
bother to set up page caching.
> Maybe the problem you're solving isn't really a technical one, and that's fine
The core of my site is quite technical as applied math,
but the users will never see that. And the programming
for the applied math I've already done and likely won't
need to redo for a long time if ever.
The rest of the programming will be routine for a Web
site or a business and, thus, for a language, well within
the capabilities of VB.NET.
> Sounds like you think you don't really need much actual programming.
For the routine business programming, I don't know how
much will be needed. But I did select SQL Server
instead of some simpler no-SQL due to anticipating
needing in time
much of the power of a real relational
database.
> maybe you'll be fine with mediocre programmers
I want bright people, but I'm not too impressed
with "top" "programmers". If I had some really
challenging software to write, say, for reliability,
then I might prefer a bright pure math major to a
bright computer science major. If the math major
needs something tricky in computer science, then he
could chat an afternoon with a computer science
prof and find, say, what pages in, maybe, something
by Sedgewick to read. Otherwise I'd hire bright,
well motivated, people with an interest in computing
from some majors other than math or computer science.
I might be missing something about Scala or Haskell,
but so far what I see in nearly all production programming
on Windows
is a little 'glue' in a language like VB.NET connecting
a lot of 'bricks' from the .NET Framework, ASP.NET,
..., T-SQL, etc. So the VB.NET is define a function,
pass some arguments, define and allocate some
storage inside the function, operate on the data
via if-then-else, do-while, expressions, call-return,
try-catch, use the APIs, and then return. I see no
way to get around using the 'bricks', and
the 'glue' code is so small that I see no
great savings in having a better way to do it.
>The challenges in writing significant Web site software are outside the language and in the APIs, e.g., the .NET Framework, ASP.NET, ADO.NET, also in the middle ware, e.g., IIS, SQL Server, and in some issues of system and network management, system security, etc.
Sounds like you think you don't really need much actual programming. Maybe the problem you're solving isn't really a technical one, and that's fine - in which case maybe you'll be fine with mediocre programmers and it would be a waste of money to hire top ones.
Well, best of luck either way.