Personal computing discussed
Moderators: renee, SecretSquirrel, just brew it!
just brew it! wrote:I think the biggest problem with it was that the barrier to entry was low enough that a fairly substantial percentage of production VB code was written by people who were very new to software development and had a very tenuous grasp of proper software design principles.
derFunkenstein wrote:Lots of comments like "VB sucks, VB projects fail" but exactly zero specificity as to why. I only have cursory knowledge of VB, but it seemed fine, I guess.
Or is this just another way of saying "C++ all the way because higher-level languages and frameworks like .NET suck and everyone is an idiot but me"?.
Vhalidictes wrote:C++ = "Low-level languages are more efficient, and I know exactly how to get the project done."
Pros? Lowered chance of bugs, typically better performance optimization.
Cons? No chance whatsoever of the project coming in on time or on budget. No one alive (including the original programmer after about a year) will be able to maintain the source in the future.
Flying Fox wrote:VB.NET was given the same broad brush as VB classic. Not saying VB.net is a problem free language, but since it runs on top of the CLR it can be written as properly as C#, most of the time. VB classic was kind of a mess.
Flying Fox wrote:VB.NET was given the same broad brush as VB classic. Not saying VB.net is a problem free language, but since it runs on top of the CLR it can be written as properly as C#, most of the time. VB classic was kind of a mess.Vhalidictes wrote:C++ = "Low-level languages are more efficient, and I know exactly how to get the project done."
Pros? Lowered chance of bugs, typically better performance optimization.
Cons? No chance whatsoever of the project coming in on time or on budget. No one alive (including the original programmer after about a year) will be able to maintain the source in the future.
Really? Real C++ programmers would not assert C++ as "lower chance of bugs". Being an unmanaged language and the low level nature chance of bugs is actually much higher, even for an experienced person. Is it possible to write bug-free C++? Sure, but it is harder than higher level, garbage-collected languages. Performance optimization? Just because the code is written in C++ does not automatically mean performance is optimized. The optimizer has come a long way helping with the particular problem of template bloatedness, but written poorly C++ can be extremely inefficient too. Blanket statements like these for C++ are very dangerous.
derFunkenstein wrote:Maybe this is why I'm confused. I have only ever used VB.NET in Visual Studio 2015. It seemed fine.
Vhalidictes wrote:C++ ... No one alive (including the original programmer after about a year) will be able to maintain the source in the future.
just brew it! wrote:Isn't System.gc() helpful in some cases?Garbage collection in languages like Python and Java can occur at inconvenient times, and introduce a lot of variation in application performance.
meerkt wrote:Vhalidictes wrote:C++ ... No one alive (including the original programmer after about a year) will be able to maintain the source in the future.
That's a question of design and coding practices. C++ code, like most other serious languages, can be made perfectly readable and maintainable.just brew it! wrote:Isn't System.gc() helpful in some cases?Garbage collection in languages like Python and Java can occur at inconvenient times, and introduce a lot of variation in application performance.
derFunkenstein wrote:Lots of comments like "VB sucks, VB projects fail" but exactly zero specificity as to why. I only have cursory knowledge of VB, but it seemed fine, I guess.
Or is this just another way of saying "C++ all the way because higher-level languages and frameworks like .NET suck and everyone is an idiot but me"?
I mean, I work in an all-Microsoft shop. I didn't pick the platform and I started as a support monkey so really who cares (as long as I work here, this is what I'm stuck with), but this just sounds like sour grapes because Microsoft has the dominant desktop platform.
Pancake wrote:VB6/VBA I still occasionally have to deal with for using or integrating legacy cruft. Completely does my head in. It's success wasn't so much that it was an easy way to learn programming (Turbo Pascal or whatever that became was so much better as a high level language where you didn't have to deal with pointers and memory management) but because it was so deeply integrated into MS software eg Excel, Word and I'm sure anyone in my age group has some recollection of the horrors of Access database applications. HO LEE FOOK!!!
just brew it! wrote:How about this:
Picture a 3rd party application that needed to integrate with MS Word. Integration was initially attempted via OLE, but MS Word's OLE implementation was too unstable. To get around the OLE problems, the company producing this application eventually settled on a modified architecture that involved using a keyboard journal playback hook to stuff hotkey sequences into Word's keyboard queue. These hotkeys were configured in Word to invoke VBA macros that performed all the stuff that couldn't be done reliably with OLE. The VBA macros passed data back and forth to the 3rd party application via a DLL that had a shared data segment which was accessible to both Word and the external application.
I still have the mental scars from that project, over a decade later. Fortunately it wasn't my full-time job; it was a part-time gig that I was working on in the evenings to make a little extra cash.