3 ms·

Good question. You asked it, so now I don't have to! The comments are good. So, yes, for my startup, I'm using the Microsoft 'stack'. But for C#, I'm not us

Good question. You asked it, so now I don't have to! The comments are good. So, yes, for my startup, I'm using the Microsoft 'stack'. But for C#, I'm not using it! Haven't touched it! Instead I'm using Visual Basic .NET and .NET, ADO.NET, ASP.NET, Windows Server, etc. For 'training' people, my guess is that 'basic' Visual Basic .NET will prove to be super easy for nearly any reasonably talented, interested hire to learn. Why? For nearly everything I'm doing, nearly all of the the syntax and semantics of Visual Basic (the current .NET version) couldn't be easier to read and type. I also like the Visual Basic compiler, just as shipped with the .NET Framework (version 4.0). The Visual Basic compiler is right there as file VBC.EXE, and to run it just use a command line or some scripting language (I am using ObjectRexx) to type the command line. The command line syntax is short and easy to understand. The compiler is fast and generates remarkably small EXE files. The error messages are from good to quite nice. So far I've found no bugs at all. I'm thrilled. My view is that the syntax of C# is more difficult, and so far I see no reason to struggle with it. So, for my startup, so far it's just Visual Basic and .NET. For typing in software, I just use my favorite text editor KEdit with a lot of macros. And I make heavy use of just the ordinary desktop 'windowing': So, when typing, typically I have about 15 windows open, 'tiled' with the upper left corners running from upper right to lower left (can always see at least the top or left side of each window and can rearrange the Z-order without moving any windows). So, I have windows with pieces of my design, software, testing, documentation, etc. all readily available. It's nice. I'm also thrilled with how ASP.NET works when I just type in Web page software with KEdit. So, when a browser displays a page under development, if there are Visual Basic errors then get a nice page in the browser making clear what the errors are. NICE. When the compiler errors are gone, then at the bottom of the Web page is a NICE description of all the work ASP.NET did with a 'control tree', various ID values, some sizes in bytes, some timings in milliseconds, etc. NICE. When finally understand from 5000 feet up basically what ASP.NET is doing, then it's fairly simple and clear and okay. Why I am staying with Microsoft: (1) What I Knew. I got started on that path to Microsoft and stayed on it. So I did a lot with OS/2, and when I changed to Windows it was, of course, similar. (2) Documentation. I am finding that my code is heavily just some 'glue' to call code from Microsoft, especially their .NET. So, I do more reading documentation than writing code. So, I care a lot about the quality of the documentation. The Microsoft .NET documentation is enormous. I have about 2400 Web pages of Microsoft documentation on my computer, abstracted, and indexed, and I put as comments in my code the file system tree names of relevant documentation and with one keystroke KEdit will display the Web page. Nice. But that's a LOT of documentation. Writing such documentation is EXPENSIVE. In simple terms, the quality from Microsoft is high. More deeply, often the writing quality of the real 'content' needs to be improved. I'm afraid that, without the big bucks of Microsoft, alternative documentation would be worse. (3) Support. If my startup is successful, then I will want a lot of technical support. I'll be willing and able to pay for the support. I am hoping that going with Microsoft I will be able to get some good support. So far I've gotten some surprisingly good support for free from various experts at Microsoft via various Microsoft fora. Of course, to get a good response, tend to need to have done some good homework and actually ask a good question! The free support is so good that I am looking forward to some nice help when I'm able to pay. For Unix flavors, I'd be afraid on each of these three points. Afraid? Yes. Well informed on Unix? No!

runjake 15y ago
Your comments are interesting, as VB and VB.NET are distinct languages with differing (though similar) syntax and quite different paradigms. VB.NET shares its paradigm more with C# than the classic VB. VB.NET code can be ported cleanly to C#.
- NY_Entrepreneur 15y ago
  Yes. On the 'porting', I can believe that! However, I couldn't do the porting because I don't know C# syntax! For "classic VB", I don't know that either! I never used it. For Windows programming, I just started with what you call 'VB.NET'. I didn't mention 'classic VB' (or VB 6.0 or whatever it was) but tried to indicate that I am using the newer, most recent version of VB and am also heavily using .NET, ASP.NET, and ADO.NET. On the 'porting', sure: It appears that in effect Microsoft went 'language syntax agnostic', concentrated on the lower levels down toward the processors and Microsoft's 'common language runtime' (CLR), their 'intermediate language' or whatever they call it, etc. and in effect said that anyone was welcome to develop any 'syntactic sugar' on top they wanted. Sounds like a good move to me. I understand that C# offers a little that VB.NET does not, e.g., for 'reflection' or whatever, useful for writing polymorphic or more efficient late binding code. Okay. I'm trying to avoid using late binding. For polymorphic code, mostly for object oriented programming, I'm just using .NET where I mostly don't have to think about polymorphism. I have written a few classes and, then, a few polymorphic functions, but there I used interfaces which I regard as much the same I've done for decades with 'entry variables'. The problem has always been, and still is, inside the polymorphic code, for each time touch the relevant data, have to call a function that is passed to the polymorphic code, and even just a little such usage can double or triple execution time of the polymorphic code. Of course another way out is to use 'generics', but those go way back, also: Basically just have the compiler write different versions of the code depending on the data types to be used. Since VB.NET can be translated to C#, if I have to look at some C#, then I will imagine that I'm just looking at VB.NET with some 1-1 syntactic translations. But the thread was concerned about training employees, and it seems to me that the syntax, semantics, etc. of VB.NET are so nice that, just for the language, the training should be fairly easy. Moreover, in my work, nearly all the effort is just understanding the documentation for .NET, ASP.NET, and ADO.NET. Then that understanding should be quite similar no matter what language is used to get to .NET, etc. For understanding the basic VB.NET syntax and semantics themselves, that's from easy down to nearly trivial. So, for my company, I'm trying to stay with VB.NET instead of C#: Get what my company needs, have the code easier to read, and have training easier. Yes, one of the nicer parts of VB.NET, and likely all the languages based on the CLR, and maybe not so easy for a beginner trying to understand and use, is the CLR 'garbage collection' (GC). I was afraid that maybe each few seconds GC would wake up, put all the application logic on hold, do its GC, and then restart the application logic, but so far I've been pleased: From some timings I've done, etc., I've seen no significant such intervals of 'application logic on hold'. What will happen with VB.NET and GC on processors with many cores will be interesting to watch. I don't know that the CLR, VB.NET, C#, the other Microsoft languages based on the CLR, and .NET are in all ways the best possible, but so far I'm pleased and thrilled. E.g., they look solid enough for me to concentrate on my work for my company. I've seen a lot in computing, including IBM's old efforts at some 'commonality' in the programming languages, etc., saw a lot of messes, and see what Microsoft has done as much better. That they got GC working well is IMPRESSIVE -- they could have messed that up. Microsoft could have made a huge mess out of the CLR, etc., but it appears so far that, instead, they did some good work. What's comparable or good/bad in the Unix/Linux world I don't know.

runjake 15y ago

Your comments are interesting, as VB and VB.NET are distinct languages with differing (though similar) syntax and quite different paradigms. VB.NET shares its paradigm more with C# than the classic VB. VB.NET code can be ported cleanly to C#.

NY_Entrepreneur 15y ago
Yes. On the 'porting', I can believe that! However, I couldn't do the porting because I don't know C# syntax! For "classic VB", I don't know that either! I never used it. For Windows programming, I just started with what you call 'VB.NET'. I didn't mention 'classic VB' (or VB 6.0 or whatever it was) but tried to indicate that I am using the newer, most recent version of VB and am also heavily using .NET, ASP.NET, and ADO.NET. On the 'porting', sure: It appears that in effect Microsoft went 'language syntax agnostic', concentrated on the lower levels down toward the processors and Microsoft's 'common language runtime' (CLR), their 'intermediate language' or whatever they call it, etc. and in effect said that anyone was welcome to develop any 'syntactic sugar' on top they wanted. Sounds like a good move to me. I understand that C# offers a little that VB.NET does not, e.g., for 'reflection' or whatever, useful for writing polymorphic or more efficient late binding code. Okay. I'm trying to avoid using late binding. For polymorphic code, mostly for object oriented programming, I'm just using .NET where I mostly don't have to think about polymorphism. I have written a few classes and, then, a few polymorphic functions, but there I used interfaces which I regard as much the same I've done for decades with 'entry variables'. The problem has always been, and still is, inside the polymorphic code, for each time touch the relevant data, have to call a function that is passed to the polymorphic code, and even just a little such usage can double or triple execution time of the polymorphic code. Of course another way out is to use 'generics', but those go way back, also: Basically just have the compiler write different versions of the code depending on the data types to be used. Since VB.NET can be translated to C#, if I have to look at some C#, then I will imagine that I'm just looking at VB.NET with some 1-1 syntactic translations. But the thread was concerned about training employees, and it seems to me that the syntax, semantics, etc. of VB.NET are so nice that, just for the language, the training should be fairly easy. Moreover, in my work, nearly all the effort is just understanding the documentation for .NET, ASP.NET, and ADO.NET. Then that understanding should be quite similar no matter what language is used to get to .NET, etc. For understanding the basic VB.NET syntax and semantics themselves, that's from easy down to nearly trivial. So, for my company, I'm trying to stay with VB.NET instead of C#: Get what my company needs, have the code easier to read, and have training easier. Yes, one of the nicer parts of VB.NET, and likely all the languages based on the CLR, and maybe not so easy for a beginner trying to understand and use, is the CLR 'garbage collection' (GC). I was afraid that maybe each few seconds GC would wake up, put all the application logic on hold, do its GC, and then restart the application logic, but so far I've been pleased: From some timings I've done, etc., I've seen no significant such intervals of 'application logic on hold'. What will happen with VB.NET and GC on processors with many cores will be interesting to watch. I don't know that the CLR, VB.NET, C#, the other Microsoft languages based on the CLR, and .NET are in all ways the best possible, but so far I'm pleased and thrilled. E.g., they look solid enough for me to concentrate on my work for my company. I've seen a lot in computing, including IBM's old efforts at some 'commonality' in the programming languages, etc., saw a lot of messes, and see what Microsoft has done as much better. That they got GC working well is IMPRESSIVE -- they could have messed that up. Microsoft could have made a huge mess out of the CLR, etc., but it appears so far that, instead, they did some good work. What's comparable or good/bad in the Unix/Linux world I don't know.