I could waste my time pretending you are a grown-up and talk to you like one. I could waste my time giving you the benefit of the doubt (given your career path) and assume you are a very bright person with complete lack of social skills (as I did until now). But I suspect it's not the case. It seems you are used to be the smartest person around you, and really aren't used to be challenged or called upon whatever you spew as a fact. I can only feel sorry for you.
As I said, we have different ideas of "reliability". And it seems I have somewhat less shorter memory.
All system calls on all processors on all operating systems are issued by a form of a call -- interrupt or direct. No two systems have (or should) have identical binary interface because then they would be the same system. All Unix-like systems share the same set of system calls/library functions that are mostly based on BSD and SysV interface, and included in POSIX standards. As long as software written for one system is portable to another through a trivial recompile, no one cares about trivial implementation details.
Bla bla. The fact is, that passing by register on i386 not only is stupid (there is a thing called "call gate" on the cpu that handles all the cruft), but deliberatly broke compatibility with other unix systems (that used by stack convention). Not everything is available from source and/or easy to recompile.
Headless systems are crippled by BIOS, not kernel.
But it's funny how linux had so much problems with it, but other systems didn't.
It is the most direct connection to bus as you can get.
It isn't. Google for external PCIe. And theoretically, you can use external PCIe to interconnect multiple nodes (think grid computing) at native PCIe lane speed. A 4 lane E-PCIe adapter can give you 20Gb/s of troughput.
There is already an alternative already. It's called external PCIe, and while quite similar to thunderbolt, is simpler (both in software and hardware) and more scalable.
I don't disagree, but the point is other technologies do all that and do it better, so again, why bother PHP?
Please do tell, what scripting/dynamic language can I use that is multiplatform, has a rich library of modules, runs well as CGI and has an apache module available, can be run from CLI easily, has at least equivalent PHP performance, can be used for OOP or procedural programming, and isn't Python or Perl? Because you sound like there's a ton of choices available.
One of the biggest problems with PHP is that it has literally hundreds of extremely subtle issues that can cause real bugs.
I do understand what you are saying, but if you were a C programmer, there would also be literally hundreds of extremely subtle issues that can cause real bugs, that wouldn't be catched at compile time. Shure, most of those issues aren't clearly defects of the language (and most PHP ones are), but the result is the same - silent failure.
Again, if you believe this, then I'm not convinced you're aware of PHP's many subtle issues. They are well documented, most recently, and probably most extensively here:
Yes, I'm well aware of them and the link you provided. As are many of the programmers involved in framework development. Most frameworks do provide complete test coverage, so either 1) TDD is mostly useless because the testcases cannot cover the entire range of values and options (execution paths) of the code being tested; or 2) most of the quirks of PHP can be worked around (as somewhat proved by the ton of functional applications available). I confess I'm not a big fan of TDD, but it can help catching some of the issues, and static analysis tools also go a long way in preventing unwanted behavior. It's not like the defects aren't well known.
Do you have any evidence to back this up? The only reason I can see it being true is that the web hasn't been around as long as the desktop, there's no evidence that I'm aware of that web applications get taken down and replaced quicker than desktop applications.
What kind of evidence do you want? Try to load a webpage made for Netscape 6.0 that uses Javascript on a modern browser. Show me a CMS available since 2002 that hasn't been rewritten at least once, and still works well. Go ahead, and try to run an ASP application from 2002 on a modern computer. Or Java web application. Or even a Python one.
The problem is that your argument seems to be weighted entirely on the rather weak get out clause that if PHP has failed then someone is doing it wrong.
My argument is that, despite all defects and quirks, PHP works, even if you think it doesn't. I never said that PHP is slower to develop with, and that is a very subjective metric. A proficient programmer in a specific language will always be more effective at it than a not-so talented one. Harder to maintain is also relative, it depends on the application and the code itself. And It's not like JAVA or Python is taking the web by storm.
As for redeeming features, I already said it - It's not Python, it runs almost everywhere, it doesn't shove a paradigm down my throat (like RoR), and you'd better know what you are doing, or it is going to blow on your face(like asm). That said, if I could use C# instead of PHP, I'd dump PHP in a heartbeat.
You are kidding, right? How many USB stacks Linux had until today, and how many drivers had to be rewritten? And how about audio?
Linux kernel is the only one that went through multiple changes in internals while keeping overall reliability, internal consistency and stability/compatibility of external interfaces
So, I guess you haven't seen much, and we do have different ideas of "reliability". Since 2.6 Linux is quite stable (on par with BSDs and Solaris), but that wasn't the case before. And compatibility? Are you talking about that unix clone that used DOS-style syscalls (by register) on i386?
ended up being married forever to inflexible, obsolete internal interfaces
Can I use the stock kernel on a headless system (no graphics card), or it still is a requirement?
overriding all intents of modularity.
What intents of modularity? Linux is a monolithic kernel. Just because it can load modules, it doesn't mean it's "modular". Modularity in Linux is on par with other monolithic kernels - you edit a makefile or an options file, and discard what you don't want to be built. Does that seem to you a genuine effort for modularity?
PHP is used for one thing and one thing only - to generate CGI-like applications that shit webpages. If you are using it for anything else, you are using it wrong. If you have strange/complex requirements, or need to scale horizontally, you are using it wrong. If you need a stateful environment (where threads usually make sense for some tasks), you are using it wrong. If you need a GUI, you are using it wrong. Etc etc.
Now for webpages, it does deliver - easy to use, easy to learn, acceptable performance, procedural support AND OOP. And it is very well supported well, everywhere. You can slap around some scripts for processing a form, or build a complex, "enterprise-grade" application. Because of that, it usually attracts less-talented programmers and beginners, but bad PHP code is usually easy to spot. Can't say the same for Python or Java. And the quirks. Yeah, they exist, and some of them are serious defects, but somehow applications get built that work most of the time, and don't fall apart.
The lack of threading support in PHP isn't a showstopper when you are building stateless applications. Because the application is basicly re-initialized from scratch each time it is run, you want it to exit as soon as possible, and not keeping it around executing threaded stuff. There were some projects in the past that tried to implement thread support and failed - mostly, due to the fact that most libraries that PHP uses weren't threaded, and general lack of interest.
Facebook is a textbook case of "you are doing it wrong". As soon as the requirements grew, they should have reimplemented the system in something nicer. We all know PHP isn't meant to be used as they are using it, and throwing money at the problem isn't going to solve anything.
I personally hate Python. I cannot use a language that treats me like a child. But yes, Python can be used in a plethora of cases where PHP is a bad idea - but, if I'm using Python, why not use anything else? The same argument can be applied to any language. PHP (with a decent framework) is quite usable, easy to learn/troubleshoot (despite of the quirks), and delivers. Web-based applications tipically have a (much) shorter lifespan than desktop applications, so even the long-run cost of "maintenance" isn't a real problem.
It has also been 7 years ago. If you don't know where.NET was 7 years ago, what makes you think that you're qualified to judge on its verits vs VB6 today?
Your original claim was that.NET is faster than VB6 ever was - it makes sense compare it in a time where.NET was touted as a VB6 replacement.
You do realize that database related stuff is bound by the efficiency of the DB framework and the backend database, not by codegen quality, right? In both VB and.NET, all codegen does is produce a bunch of method calls, for stuff like Recordset (in VB6) or DbDataReader (in VB.NET).
Assuming you actually believe what you write, then your assertion that "VB.NET apps are uniformly faster than VB apps" isn't true since - according to you - they produce essentialy the same code.
But I mentioned "your code" because I didn't assume you were doing database-related stuff. I just mentioned that for database-related stuff you do get from about the same speed to a lot slower. That is the experience I have with the codebases I worked with. As an example, I've assisted on a migration of a midsize app (>700 forms) in 2003 from VB6 to VB.NET, and it took more than 6 months to become usable because of memory spikes and database-related issues. More recently, I've been working with C# (.NET 4.0) with both PostgreSQL (npgsql) and SQLite, and often memory usage goes trough the roof. I work with several languages/environments, sometimes working on the same data, and I usually only have this kind of problems with.NET.Maybe it doesn't like me:)
By the way, which grid of the two (DataGrid and DataGridView) are you referring to?
I can't really remember which one I tested, we decided to replace it entirely with a DevExpress component, that we've been using since. At the time, even with virtual scrolling the grid was slow and had artifacts in maximized windows. I tested it with roughly 10k rows, 5-7 columns. A fast grid should take no more than 1-2 seconds to load and display the data on my desktop (quad-core 2.4Ghz).
If you have hands growing out of your ass, perhaps. I've wrote quite a few.NET apps, and typical memory consumption figures were 20-50 Mb.
I've just runned a simple app (less than 1Mb of source), opened a dialog with a list of 18 items pulled from a database, and it is eating 40Mb. The same application with just the main screen opened eats about 28Mb of memory, so I'd say 12Mb for a almost empty dataset, a grid and a form is a lot. I've seen datasets eating 200Mb of ram easily.
.NET GC works just fine. I suspect that has more to do with people leaving around references to objects they no longer need (which very often happens with event handlers they forget to unregister). Otherwise, if you make bullshit-y claims like that, how about providing references?
If you have to explicitly de-reference your vars, then you don't really need GC, do you? From what I've seen (and it is purely empirical), the GC seems to work with high and low watermarks for memory usage, and it only works "as expected" somewhere between a sweet spot, that varies according to the available RAM in the host. Given that true GC on a arbitrarily-sized heap allocator is computationally expensive, it does make sense it works that way, but for some applications - that require the load of a huge amount of data, some quick process on it, discard and repeat, usually leads to a fast depletion of the available RAM.
In VB6, on the other hand, you could easily have a memory leak simply by creating a circular reference between objects. And there were no weak references to work around that.
Yes, memory management in VB6 was a pain in the ass, but at a different order of magnitude. Today's computers have at least 8x the memory they had in 2000, the low-end cpus are at least 10x faster, and in many cases, the data size is about the same (a list of clients still is a list of clients, an article table still is an article table, etc). Modern db-driven applications usually aren't faster or leaner than they were 12 years ago, or - in many cases - better designed.
Most memory issues with VB6 could be easily fixed by using simple techniques, and using global datasets instead of arbitrarily opening and closing them inside forms and custom procedures and whatnot.
Edit and continue has been there for VB.NET since VS2005
Yeah, 7 years after the last release of VB6, and at the 3rd release of the VS suite with.NET support, so I guess it probably didn't affect many users _migrating_ from VB6. My mistake.
As I had already noted, VB.NET apps are uniformly faster than VB apps, because.NET JIT is better optimizing than VB6 compiler. If you really want it, I could do some benchmarking.
Maybe your code performs uniformly faster than VB apps, but it's not the general experience I have. Anything database-related range from about the same speed (with 2x or 3x the memory consumption) to noticeably slower. Probably some object-oriented code performs better when ported to.NET, but that's about it.
A call statement itself is relatively slow compared to, say, just adding two numbers together directly.
Usually is, but it is not an order of magnitude slower.
.NET JIT, on the other hand, compiles directly to native code, without an added layer of call indirection.
The.NET assembly is already the added layer of call indirection. And given the abstraction that datatypes suffer, I'd argue that whatever code is produced related to adding two integers will be much more extensive than the equivalent call generated by the VB compiler.
Yes, lets pretend that adding variables to structures, and adding conditional blocks to stuff like process management, network sockets or various stages of VFS has no effect on the user - specially when this funcionality is all added on a minor release.
. We shouldn't even use a physical item like that for purposes of verifying identity and permissions. At a border crossing, stating names and perhaps a number, or undergoing a brief biometric scan ought to be all that travelers need do. The officials at the border can then use their networked computers to check the information. It's just dopey to rely on the picture of a person carried by that person to check identity! That's as dopey as DRM. Yeah, yeah, like cash they have put security threads and watermarks and such on the passport pictures, to make forgery more difficult. And don't forget the embedded RFID chip! Currently, with passports the US now issues business sized cards for your wallet. The cards have useful phone numbers and a space upon which you are supposed to write your passport number, for just such an occurrence. Haven't progressed much!
Shure, go ahead and recruit people for the globally replicated, government controlled biometric scan database.
And a ton of countries already use a version of the electronic passport. While you see a security guard, many implementations rely on your biometric data stored inside the rfid chip to perform facial recognition. And you know what the best part is? The data is usually encrypted, but the private key is also stored on the chip, so you can actually tamper and re-sign the data so it's valid. How is that better than traditional passports?
In ALL conferences in EVERY country stuff is robbed cause people are idiots.
Well, a couple of years ago I've co-organized an international conference (2 years in a row), and nothing got stolen. It worries me that you think that is the norm.
Because more code gets hammered to provide funcionality the average user doesn't care/know about, often inside critical sections of the kernel. But I guess you already know that.
I'm not really a Linux user, but one thing I've noticed since the advent of the 2.6.x line, is that the seems to be for grabs for everyone who can hire a kernel developer. With each version, you get more and more hooks/half-assed funcionality that is only well supported or documented by a given vendor. As an example, take kernel namespaces. Full blown jail-like funcionality, but almost zero documentation - except if you buy a product that well, makes it usable. The kernel namespace feature implies modifications in the core of every major kernel subsystem and adds complexity, yet it seems no one uses it.
Yes, well, a lot of so-called "professional" programmers believe PHP is a well designed language, and a good number of them exist on Slashdot.
Well, I'm one of the guys that usually counter-arguments on the "PHP is evil" rants, and I create code professionally, so I guess I'm a "professional" programmer. I've never seen a PHP programmer saying it is a well designed language - on the contrary. Anyone that actually uses PHP knows it is an half-assed attempt at nothing, riddled with inconsistencies and unexpected behaviours. I probably could point out some serious problems with "acceptable" languages such as C, or inconsistencies in a language that is the "elefant in the room" (Javascript), but the list of defects of those languages combined probably isn't remotely close to the problems PHP has.
That said, there are areas where PHP shines - and, while there are alternatives - PHP still is a viable choice. As a programmer, I like how it does not force a paradigm down my throat, and gives me the liberty to freely implement how I choose to. I wouldn't use it for GUI programming (I know, someone else thought it was a good idea), or for complex database handling, and yes, the internet is full of piss-poor PHP code, but know what else? You have piss-poor JAVA code too. And C. And python. And every other language you can think of.
Perhaps the most glaring one in this day and age is the complete and utter lack of actual parallel programming support beyond a few awful curl hack libraries.
If you need parallel programming, PHP (and VB6:D) is not an acceptable choice. If what you meant was lack of thread support, well, I'd say threads - while valid in some contexts - are overused and often create more problems than they solve. As you said "anyone with even a basic understanding if computer science" can work around them in many (most?) cases. Even at the operating system level, threading poses scheduling problems in many operating systems, specially considering the multi-core world of today.
I do some C# development, and often prefer to use SharpDevelop, despite its limitations (no LINQ wizards, no database browsing and whatnot). The code editor seems more familiar to me, and it is an order of magnitude faster than VS2010/2011.
Cracking open a VB app, one is likely to find something that is not scalable or adaptable, requiring the entire thing to be junked.
The same could be said for any legacy language. I know cases of banks that tried to replace their multi-decade old COBOL systems and failed miserably. The solution? Wrap around some JAVA or.NET middleware so they can continue to use it.
Critical applications are never really junked. You can't replace decades of ironing out the kinks and expected (mis)behaviour. Most of those critical applications grew with the business itself, and in some cases, specific chunks of code can span an entire generation of programmers. If you expect to replace it with JAVA and.NET and some TDD, you are in for a surprise.
VB6 was also object-oriented - it had classes and stuff. It didn't have certain features, like inheritance, so you had to do with interfaces + aggregation + delegation (and people did). You certainly couldn't avoid OO when writing even the most basic VB6 programs, though. Every form would be an object to begin with.
Since VB5, some OO features were available. But a form wasn't an object. There is a common misconception in the OO world regarding event-driven or message based programming - none of them is directly related to OOP. At its core (at least upto XP), Windows API is a procedural, event-driven environment. VB6 produced code vaguely similar to the classic C approach of creating a window, and registering a event handler callback. Zero OOP.
See, again, you're judging something you haven't seen. In.NET with WinForms, you can literally hack together a GUI with inputs from DB without writing a single line of code - it's all wizards and drag and drop. Connect to database (wizard), then drag and drop that connection to a blank form and bam - there's your GUI, an editable grid of data with navigation, everything completely wired up.
Except that feature isn't from.NET/WinForms, but from the IDE, so it's not directly related to the language. And as I said before, the.NET dbgrid sucks balls. Big balls. And the responsivity of the resulting application isn't nowhere near a VB one. And the memory footprint is massive.
As a side note, I do have a basis for comparison because I used VB6 a fair bit back in the day - it was what I started my career on back in 2000 (as in, not the first language I learned, but the first that earned me money). It was a decent thing for what it was, but I don't feel it to be superior to.NET in any way.
I've worked extensively with VB since VB3, and I agree that it's not generically superior to . NET - but VB.NET is not a VB6 replacement for the casual user, and VB6 (and FoxPro) left a void in the Microsoft ecosystem they haven't been able to fill since then.
WinForms is very similar to VB6 UI toolkit on basic level, with mostly the same principles and the same controls.
Except that the grid component is actually unusable for serious applications. You know, the thinggy 90% of the database-driven forms use. And the memory footprint of a "simple" database application reaches hundreds of MB easily. And the garbage collector sometimes forget to, you know, do some garbage collection.
You do realize that.NET (yes, running on a VM with JIT) is actually still faster than VB6 ever was, right?
Go ahead and use a post-VB6 version of.NET (VS2003/2005). Dead slow IDE, no editing of the code while running (WTF? if you are doing step-by-step debugging you _need_ to stop the program to edit a line?), and the result would often be a slow as hell application, that used a memory footprint of 3-5x the VB equivalent.
"Fast native code" really means C/C++. Something like VB is slow because it's high-level, not because it's not native.
You'd be surprised. I generally consider compilers like VB6 (and Clipper and some Cobol compilers) as "fake compilers" - they rely on an extensive API usually made in C/C++, and their work is to generate the glue code between the API functions. So, while your application logic usually translated to a series of call statements, the functions called run at native speed, and in complex algorithms, they run laps around early.NET implementations.
Slashdot Mirror
In other words, shut up, moron.
I could waste my time pretending you are a grown-up and talk to you like one. I could waste my time giving you the benefit of the doubt (given your career path) and assume you are a very bright person with complete lack of social skills (as I did until now). But I suspect it's not the case. It seems you are used to be the smartest person around you, and really aren't used to be challenged or called upon whatever you spew as a fact. I can only feel sorry for you.
That's completely false.
As I said, we have different ideas of "reliability". And it seems I have somewhat less shorter memory.
All system calls on all processors on all operating systems are issued by a form of a call -- interrupt or direct. No two systems have (or should) have identical binary interface because then they would be the same system. All Unix-like systems share the same set of system calls/library functions that are mostly based on BSD and SysV interface, and included in POSIX standards. As long as software written for one system is portable to another through a trivial recompile, no one cares about trivial implementation details.
Bla bla. The fact is, that passing by register on i386 not only is stupid (there is a thing called "call gate" on the cpu that handles all the cruft), but deliberatly broke compatibility with other unix systems (that used by stack convention). Not everything is available from source and/or easy to recompile.
Headless systems are crippled by BIOS, not kernel.
But it's funny how linux had so much problems with it, but other systems didn't.
It is the most direct connection to bus as you can get.
It isn't. Google for external PCIe. And theoretically, you can use external PCIe to interconnect multiple nodes (think grid computing) at native PCIe lane speed. A 4 lane E-PCIe adapter can give you 20Gb/s of troughput.
There is already an alternative already. It's called external PCIe, and while quite similar to thunderbolt, is simpler (both in software and hardware) and more scalable.
I don't disagree, but the point is other technologies do all that and do it better, so again, why bother PHP?
Please do tell, what scripting/dynamic language can I use that is multiplatform, has a rich library of modules, runs well as CGI and has an apache module available, can be run from CLI easily, has at least equivalent PHP performance, can be used for OOP or procedural programming, and isn't Python or Perl? Because you sound like there's a ton of choices available.
One of the biggest problems with PHP is that it has literally hundreds of extremely subtle issues that can cause real bugs.
I do understand what you are saying, but if you were a C programmer, there would also be literally hundreds of extremely subtle issues that can cause real bugs, that wouldn't be catched at compile time. Shure, most of those issues aren't clearly defects of the language (and most PHP ones are), but the result is the same - silent failure.
Again, if you believe this, then I'm not convinced you're aware of PHP's many subtle issues. They are well documented, most recently, and probably most extensively here:
Yes, I'm well aware of them and the link you provided. As are many of the programmers involved in framework development. Most frameworks do provide complete test coverage, so either 1) TDD is mostly useless because the testcases cannot cover the entire range of values and options (execution paths) of the code being tested; or 2) most of the quirks of PHP can be worked around (as somewhat proved by the ton of functional applications available). I confess I'm not a big fan of TDD, but it can help catching some of the issues, and static analysis tools also go a long way in preventing unwanted behavior. It's not like the defects aren't well known.
Do you have any evidence to back this up? The only reason I can see it being true is that the web hasn't been around as long as the desktop, there's no evidence that I'm aware of that web applications get taken down and replaced quicker than desktop applications.
What kind of evidence do you want? Try to load a webpage made for Netscape 6.0 that uses Javascript on a modern browser. Show me a CMS available since 2002 that hasn't been rewritten at least once, and still works well. Go ahead, and try to run an ASP application from 2002 on a modern computer. Or Java web application. Or even a Python one.
The problem is that your argument seems to be weighted entirely on the rather weak get out clause that if PHP has failed then someone is doing it wrong.
My argument is that, despite all defects and quirks, PHP works, even if you think it doesn't. I never said that PHP is slower to develop with, and that is a very subjective metric. A proficient programmer in a specific language will always be more effective at it than a not-so talented one. Harder to maintain is also relative, it depends on the application and the code itself. And It's not like JAVA or Python is taking the web by storm.
As for redeeming features, I already said it - It's not Python, it runs almost everywhere, it doesn't shove a paradigm down my throat (like RoR), and you'd better know what you are doing, or it is going to blow on your face(like asm). That said, if I could use C# instead of PHP, I'd dump PHP in a heartbeat.
That's a false and baseless accusation
You are kidding, right? How many USB stacks Linux had until today, and how many drivers had to be rewritten? And how about audio?
Linux kernel is the only one that went through multiple changes in internals while keeping overall reliability, internal consistency and stability/compatibility of external interfaces
So, I guess you haven't seen much, and we do have different ideas of "reliability". Since 2.6 Linux is quite stable (on par with BSDs and Solaris), but that wasn't the case before. And compatibility? Are you talking about that unix clone that used DOS-style syscalls (by register) on i386?
ended up being married forever to inflexible, obsolete internal interfaces
Can I use the stock kernel on a headless system (no graphics card), or it still is a requirement?
overriding all intents of modularity.
What intents of modularity? Linux is a monolithic kernel. Just because it can load modules, it doesn't mean it's "modular". Modularity in Linux is on par with other monolithic kernels - you edit a makefile or an options file, and discard what you don't want to be built. Does that seem to you a genuine effort for modularity?
PHP is used for one thing and one thing only - to generate CGI-like applications that shit webpages. If you are using it for anything else, you are using it wrong. If you have strange/complex requirements, or need to scale horizontally, you are using it wrong. If you need a stateful environment (where threads usually make sense for some tasks), you are using it wrong. If you need a GUI, you are using it wrong. Etc etc.
Now for webpages, it does deliver - easy to use, easy to learn, acceptable performance, procedural support AND OOP. And it is very well supported well, everywhere. You can slap around some scripts for processing a form, or build a complex, "enterprise-grade" application. Because of that, it usually attracts less-talented programmers and beginners, but bad PHP code is usually easy to spot. Can't say the same for Python or Java. And the quirks. Yeah, they exist, and some of them are serious defects, but somehow applications get built that work most of the time, and don't fall apart.
The lack of threading support in PHP isn't a showstopper when you are building stateless applications. Because the application is basicly re-initialized from scratch each time it is run, you want it to exit as soon as possible, and not keeping it around executing threaded stuff. There were some projects in the past that tried to implement thread support and failed - mostly, due to the fact that most libraries that PHP uses weren't threaded, and general lack of interest.
Facebook is a textbook case of "you are doing it wrong". As soon as the requirements grew, they should have reimplemented the system in something nicer. We all know PHP isn't meant to be used as they are using it, and throwing money at the problem isn't going to solve anything.
I personally hate Python. I cannot use a language that treats me like a child. But yes, Python can be used in a plethora of cases where PHP is a bad idea - but, if I'm using Python, why not use anything else? The same argument can be applied to any language. PHP (with a decent framework) is quite usable, easy to learn/troubleshoot (despite of the quirks), and delivers. Web-based applications tipically have a (much) shorter lifespan than desktop applications, so even the long-run cost of "maintenance" isn't a real problem.
Good software is maintainable and flexible.
We're not talking about good and flexible software. We're talking about the linux kernel.
It has also been 7 years ago. If you don't know where .NET was 7 years ago, what makes you think that you're qualified to judge on its verits vs VB6 today?
Your original claim was that .NET is faster than VB6 ever was - it makes sense compare it in a time where .NET was touted as a VB6 replacement.
You do realize that database related stuff is bound by the efficiency of the DB framework and the backend database, not by codegen quality, right? In both VB and .NET, all codegen does is produce a bunch of method calls, for stuff like Recordset (in VB6) or DbDataReader (in VB.NET).
Assuming you actually believe what you write, then your assertion that "VB.NET apps are uniformly faster than VB apps" isn't true since - according to you - they produce essentialy the same code. .NET.Maybe it doesn't like me :)
But I mentioned "your code" because I didn't assume you were doing database-related stuff. I just mentioned that for database-related stuff you do get from about the same speed to a lot slower. That is the experience I have with the codebases I worked with. As an example, I've assisted on a migration of a midsize app (>700 forms) in 2003 from VB6 to VB.NET, and it took more than 6 months to become usable because of memory spikes and database-related issues. More recently, I've been working with C# (.NET 4.0) with both PostgreSQL (npgsql) and SQLite, and often memory usage goes trough the roof. I work with several languages/environments, sometimes working on the same data, and I usually only have this kind of problems with
By the way, which grid of the two (DataGrid and DataGridView) are you referring to?
I can't really remember which one I tested, we decided to replace it entirely with a DevExpress component, that we've been using since. At the time, even with virtual scrolling the grid was slow and had artifacts in maximized windows. I tested it with roughly 10k rows, 5-7 columns. A fast grid should take no more than 1-2 seconds to load and display the data on my desktop (quad-core 2.4Ghz).
If you have hands growing out of your ass, perhaps. I've wrote quite a few .NET apps, and typical memory consumption figures were 20-50 Mb.
I've just runned a simple app (less than 1Mb of source), opened a dialog with a list of 18 items pulled from a database, and it is eating 40Mb. The same application with just the main screen opened eats about 28Mb of memory, so I'd say 12Mb for a almost empty dataset, a grid and a form is a lot. I've seen datasets eating 200Mb of ram easily.
.NET GC works just fine. I suspect that has more to do with people leaving around references to objects they no longer need (which very often happens with event handlers they forget to unregister). Otherwise, if you make bullshit-y claims like that, how about providing references?
If you have to explicitly de-reference your vars, then you don't really need GC, do you? From what I've seen (and it is purely empirical), the GC seems to work with high and low watermarks for memory usage, and it only works "as expected" somewhere between a sweet spot, that varies according to the available RAM in the host. Given that true GC on a arbitrarily-sized heap allocator is computationally expensive, it does make sense it works that way, but for some applications - that require the load of a huge amount of data, some quick process on it, discard and repeat, usually leads to a fast depletion of the available RAM.
In VB6, on the other hand, you could easily have a memory leak simply by creating a circular reference between objects. And there were no weak references to work around that.
Yes, memory management in VB6 was a pain in the ass, but at a different order of magnitude. Today's computers have at least 8x the memory they had in 2000, the low-end cpus are at least 10x faster, and in many cases, the data size is about the same (a list of clients still is a list of clients, an article table still is an article table, etc). Modern db-driven applications usually aren't faster or leaner than they were 12 years ago, or - in many cases - better designed.
Most memory issues with VB6 could be easily fixed by using simple techniques, and using global datasets instead of arbitrarily opening and closing them inside forms and custom procedures and whatnot.
Edit and continue has been there for VB.NET since VS2005
Yeah, 7 years after the last release of VB6, and at the 3rd release of the VS suite with .NET support, so I guess it probably didn't affect many users _migrating_ from VB6. My mistake.
As I had already noted, VB.NET apps are uniformly faster than VB apps, because .NET JIT is better optimizing than VB6 compiler. If you really want it, I could do some benchmarking.
Maybe your code performs uniformly faster than VB apps, but it's not the general experience I have. Anything database-related range from about the same speed (with 2x or 3x the memory consumption) to noticeably slower. Probably some object-oriented code performs better when ported to .NET, but that's about it.
A call statement itself is relatively slow compared to, say, just adding two numbers together directly.
Usually is, but it is not an order of magnitude slower.
The .NET assembly is already the added layer of call indirection. And given the abstraction that datatypes suffer, I'd argue that whatever code is produced related to adding two integers will be much more extensive than the equivalent call generated by the VB compiler.
Yes, lets pretend that adding variables to structures, and adding conditional blocks to stuff like process management, network sockets or various stages of VFS has no effect on the user - specially when this funcionality is all added on a minor release.
. We shouldn't even use a physical item like that for purposes of verifying identity and permissions. At a border crossing, stating names and perhaps a number, or undergoing a brief biometric scan ought to be all that travelers need do. The officials at the border can then use their networked computers to check the information. It's just dopey to rely on the picture of a person carried by that person to check identity! That's as dopey as DRM. Yeah, yeah, like cash they have put security threads and watermarks and such on the passport pictures, to make forgery more difficult. And don't forget the embedded RFID chip! Currently, with passports the US now issues business sized cards for your wallet. The cards have useful phone numbers and a space upon which you are supposed to write your passport number, for just such an occurrence. Haven't progressed much!
Shure, go ahead and recruit people for the globally replicated, government controlled biometric scan database.
And a ton of countries already use a version of the electronic passport. While you see a security guard, many implementations rely on your biometric data stored inside the rfid chip to perform facial recognition. And you know what the best part is? The data is usually encrypted, but the private key is also stored on the chip, so you can actually tamper and re-sign the data so it's valid. How is that better than traditional passports?
In ALL conferences in EVERY country stuff is robbed cause people are idiots.
Well, a couple of years ago I've co-organized an international conference (2 years in a row), and nothing got stolen. It worries me that you think that is the norm.
Because more code gets hammered to provide funcionality the average user doesn't care/know about, often inside critical sections of the kernel. But I guess you already know that.
I'm not really a Linux user, but one thing I've noticed since the advent of the 2.6.x line, is that the seems to be for grabs for everyone who can hire a kernel developer. With each version, you get more and more hooks/half-assed funcionality that is only well supported or documented by a given vendor. As an example, take kernel namespaces. Full blown jail-like funcionality, but almost zero documentation - except if you buy a product that well, makes it usable. The kernel namespace feature implies modifications in the core of every major kernel subsystem and adds complexity, yet it seems no one uses it.
Yeah, I constantly forget the VM limitation in some processors (I ignored all non-VT core* cpus). It really is a WTF? moment for Intel customers.
Yes, well, a lot of so-called "professional" programmers believe PHP is a well designed language, and a good number of them exist on Slashdot.
Well, I'm one of the guys that usually counter-arguments on the "PHP is evil" rants, and I create code professionally, so I guess I'm a "professional" programmer. I've never seen a PHP programmer saying it is a well designed language - on the contrary. Anyone that actually uses PHP knows it is an half-assed attempt at nothing, riddled with inconsistencies and unexpected behaviours. I probably could point out some serious problems with "acceptable" languages such as C, or inconsistencies in a language that is the "elefant in the room" (Javascript), but the list of defects of those languages combined probably isn't remotely close to the problems PHP has.
That said, there are areas where PHP shines - and, while there are alternatives - PHP still is a viable choice. As a programmer, I like how it does not force a paradigm down my throat, and gives me the liberty to freely implement how I choose to. I wouldn't use it for GUI programming (I know, someone else thought it was a good idea), or for complex database handling, and yes, the internet is full of piss-poor PHP code, but know what else? You have piss-poor JAVA code too. And C. And python. And every other language you can think of.
Perhaps the most glaring one in this day and age is the complete and utter lack of actual parallel programming support beyond a few awful curl hack libraries.
If you need parallel programming, PHP (and VB6 :D) is not an acceptable choice. If what you meant was lack of thread support, well, I'd say threads - while valid in some contexts - are overused and often create more problems than they solve. As you said "anyone with even a basic understanding if computer science" can work around them in many (most?) cases. Even at the operating system level, threading poses scheduling problems in many operating systems, specially considering the multi-core world of today.
You mean, like Javascript?
I do some C# development, and often prefer to use SharpDevelop, despite its limitations (no LINQ wizards, no database browsing and whatnot). The code editor seems more familiar to me, and it is an order of magnitude faster than VS2010/2011.
Cracking open a VB app, one is likely to find something that is not scalable or adaptable, requiring the entire thing to be junked.
The same could be said for any legacy language. I know cases of banks that tried to replace their multi-decade old COBOL systems and failed miserably. The solution? Wrap around some JAVA or .NET middleware so they can continue to use it. .NET and some TDD, you are in for a surprise.
Critical applications are never really junked. You can't replace decades of ironing out the kinks and expected (mis)behaviour. Most of those critical applications grew with the business itself, and in some cases, specific chunks of code can span an entire generation of programmers. If you expect to replace it with JAVA and
VB6 was also object-oriented - it had classes and stuff. It didn't have certain features, like inheritance, so you had to do with interfaces + aggregation + delegation (and people did). You certainly couldn't avoid OO when writing even the most basic VB6 programs, though. Every form would be an object to begin with.
Since VB5, some OO features were available. But a form wasn't an object. There is a common misconception in the OO world regarding event-driven or message based programming - none of them is directly related to OOP. At its core (at least upto XP), Windows API is a procedural, event-driven environment. VB6 produced code vaguely similar to the classic C approach of creating a window, and registering a event handler callback. Zero OOP.
See, again, you're judging something you haven't seen. In .NET with WinForms, you can literally hack together a GUI with inputs from DB without writing a single line of code - it's all wizards and drag and drop. Connect to database (wizard), then drag and drop that connection to a blank form and bam - there's your GUI, an editable grid of data with navigation, everything completely wired up.
Except that feature isn't from .NET/WinForms, but from the IDE, so it's not directly related to the language. And as I said before, the .NET dbgrid sucks balls. Big balls. And the responsivity of the resulting application isn't nowhere near a VB one. And the memory footprint is massive.
As a side note, I do have a basis for comparison because I used VB6 a fair bit back in the day - it was what I started my career on back in 2000 (as in, not the first language I learned, but the first that earned me money). It was a decent thing for what it was, but I don't feel it to be superior to .NET in any way.
I've worked extensively with VB since VB3, and I agree that it's not generically superior to . NET - but VB.NET is not a VB6 replacement for the casual user, and VB6 (and FoxPro) left a void in the Microsoft ecosystem they haven't been able to fill since then.
WinForms is very similar to VB6 UI toolkit on basic level, with mostly the same principles and the same controls.
Except that the grid component is actually unusable for serious applications. You know, the thinggy 90% of the database-driven forms use. And the memory footprint of a "simple" database application reaches hundreds of MB easily. And the garbage collector sometimes forget to, you know, do some garbage collection.
I can't make it work sufficiently to use. The compiled app works, but I have to maintain an XP system to do VB6 development.
Professional W7 versions have available a ready-to-use Windows XP, so it's not like MS doesn't provide a (half assed) solution.
You do realize that .NET (yes, running on a VM with JIT) is actually still faster than VB6 ever was, right?
Go ahead and use a post-VB6 version of .NET (VS2003/2005). Dead slow IDE, no editing of the code while running (WTF? if you are doing step-by-step debugging you _need_ to stop the program to edit a line?), and the result would often be a slow as hell application, that used a memory footprint of 3-5x the VB equivalent.
"Fast native code" really means C/C++. Something like VB is slow because it's high-level, not because it's not native.
You'd be surprised. I generally consider compilers like VB6 (and Clipper and some Cobol compilers) as "fake compilers" - they rely on an extensive API usually made in C/C++, and their work is to generate the glue code between the API functions. So, while your application logic usually translated to a series of call statements, the functions called run at native speed, and in complex algorithms, they run laps around early .NET implementations.