VB5 and VB6 compilers could either produce p-code or *native code* (as the developer wanted). The native code executables still needed the VB runtime; but the runtime was not interpreting, but rather just providing standard routines. This is similar to say... Scheme native compilers. Even VC++ needs msvcrt. The only difference with the later was that it was more pervasive.
Your concept of *real* programming languages is rather amateur. I probably had some of those notions 15 years ago. After a couple of dozen languages or so, words like "real" loose their meaning because there are no convenient and passionate categories any more.
Dynamic linking is being used because static linking has been denied as a choice in most of the current dev tools that matter on Windows. In Delphi, I had a choice of static and dynamic linking. I always chose static linking. Most Delphi users did the same. I didn't have that choice with VB6, Java, and.NET.
Static linking is not bad. When smart linking, only the used routines from the library are bundled along, not everything in the library. When I used dynamic linking, to simplify installation for the user, I had to also distribute the full DLLs along (they would not be installed if they already exist on the target machine), even when I used only a small portion of their functionality. Consequently, my installers were always SMALLER when using static linking.
If you are developing in-house applications, this is less of a concern though since you can reasonably assume their presence on the target machines; and because you will be using the same dev tools consistently. Dynamic linking is only efficient when the involved DLLs are relatively unchanging and necessary by many apps. This also works well in Linux where a package manager with dependency tracking is an assumed part of the system. Dynamic linking has its advantages and disadvantages. But it is not a solution that uncritically deserves its current dominance.
You are not really being objective. You are comparing your older generation notebook with your current generation Mac Book. That accounts for the price better than whether Mac is value for it's price (maybe it is, but that is a different argument). It would have helped if you detailed how you defined build quality and stability. Should be easy given that you claim remarkable difference, not subtle. And it would have been fair to compare the your current MacBook to a current Windows laptop (not that I expect everyone to own more than 1 laptop at a time).
I should have mentioned that I did try Clojure. While it is certainly the epitome of dynamic typing and syntactic flexibility for the JVM, I rejected it for the same reasons (no code completion and other validations). Most of the software I choose to write in Java is so because of the specific libraries. Most of code ends up manipulating these libraries, not as my custom logic. If I had a lot of custom logic, I could see value in Clojure (or in Scala as I mentioned in my previous post) where I could use it for domain specific code and keep the low level, object oriented API interaction to a minimum through a few wrappers written in Java. Unfortunately, those are not the kind of applications I write these days.
My point is the same... that these may be great languages but will remain incomplete in their offerings as long as their designers/community don't take the IDE as seriously as the language design. It is fortunately not as hard as it once used to be to bridge that gap, given that Eclipse and other IDE platforms already provide much tooling. Perhaps in a few years when IDE ecosystem further matures, languages can be considered on their own merit and not based on the baggage they now carry.
I could use an alternative programming language for the JVM that is more expressive than Java. Both Scala and Groovy integrate well with Java at the language level, albeit with different type systems. While I do use Groovy from time to time, what kept me from Scala was that it is not well supported by IDEs (Eclipse/Netbeans - I hear things are somewhat better with IntelliJ). The problem is the nature of Java libraries. They tend to be deeply nested and often expressed in lower level abstractions and are difficult to use without strong IDE support. I don't need an IDE for Python (flat module systems, high level libraries), but certainly do for Java. With solid IDE support however, I am nearly as productive in Eclipse + Java as with dynamic languages, even for medium apps. Scala and Groovy come with their own standard libraries and I don't need IDE support as long as I stay within them. But sooner or later, I will need to step into plain Java land and I no longer feel productive. I would rather use straight Java for them.
The development experience is language + tools, not just the language. While Scala can piggy back on JVM and undercut the rest of the process that languages need to go through to mature and be accepted, Scala plugin (or someone else) has to provide a JDT equivalent first to have popular appeal.
I just wish there was a well supported superset of Java with productivity considerations that maintains 1:1 byte-code compatibility on compilation. Java purists can keep their language clean. But the rest of us can be happy too. Scala has that potential.... almost. So far, Groovy has been filling that role for me. Groovy will never have the kind of edit-time IDE intelligence simply due to it's dynamic nature. But for now, it stands ahead (after all, it has been around longer).
And consequently, the user base of LaTeX to that of MS Word is just about proportional to the ownership of super sonic jet pilots to that of bicycle users:-).
> Interestingly, it looks like India's health care system, a mix of private and public initiatives, is doing very poorly compared to the universal system in Singapore. India's healthcare system is not providing good service for their population, so I don't know why you consider it evidence of the "free" market working it's magic.
India's healthcare system is doing fine... IF you factor in what resources go into it. Most patients (non-metro) pay few cents to a couple of dollars per consultation in private clinics. This is not co-pay or care subsidized by government. It is the full amount. Given that Indian per-capita is 20 times lower than US/Singapore, Indians are getting EFFICIENT (while not an abundance of) care. My jaw dropped when I saw that a very minor emergency room visit was billed at $250 (pre-insurance) in US.
> Technically no, practically yes. C# is.net specific and.net is windows specific. Mono is not 100% compatible.
1. If (depending on version) Mono is not a perfect port of.NET, that makes.NET code using those bits, not cross-platform. That is not the same as windows specific. For instance, not every program written in Python will run on all platforms. Some of its' standard libraries are platform specific (Eg: msvcrt). But Python is considered cross-platform.
2. C# IS cross-platform. AFAIK the compiler implementations behave identically. It's small portions of the standard library that are at fault.
But nothing stops you from writing fully cross-platform code, if you must. Just a bit more effort.
Personally, I gave up on C#. While C# is indeed better designed than Java, Groovy integrates with Java well and fills up any of the major feature and productivity gaps that I cared for anyway.
Platform independence (FYI, it is not *otherwise* known as web-based front end) and making it web available have nothing to do with its applicability. It is designed for VA clinical workflows. If you think it worked beautifully for you in a distinctly different setting, report that through a journal. I cannot take an anonymous assertion on this kind of an issue. Don't get me wrong. I would like to see it (or any other open software) get wide spread applicability. But clinical informatics has a long tradition of naive assumptions and this issue is far more complicated than a minor portability issue.
Because while CPRS is a wonderful organizational success story, Britain's EMR is a national success story. And national scale is what we are looking at right now.
In US, EMRs came early and were great in academic centers and federally funded facilities. They did not work out so well for smaller practices.
For one, CPRS does not have billing and made adoption difficult in the past. Not to mention the fact that they kept rewriting it several times. The clinicians love it because it close fit they way they worked in VA. Not surprising since a ton of money was spent perfecting it in that way. But the problem is with moving it to a non-VA setting.
BTW, there are already efforts to make CPRS more generally applicable (http://worldvista.org/). They are not a major player yet however.
Because no one knows what the standard should be about. There is no standard electronic medical record system. At the moment, everyone interprets it differently. Some scan paper and say that's enough for them. Others just type full text in. Few have them more structured. What the format will contain will depend on the intended features of the medical record and there is no clear agreement on that.
Believe it or not, health care is far more complex than what software nerds think it is and making a data format standardized without understanding its implications is just asking for trouble. There is enough health informatics literature to suggest that we don't fully understand technology insinuations in a clinical setting. Doctors will happily adopt technology that helps them and their patients. So far many remain unconvinced at the choices they have.
It is also more realistic to focus on standardizing communication between systems rather than the data formats within the systems, at least for now. There are already methods and standards that have had partial success (see HL7, IHE).
Regardless, we eventually need a standard. 5 years is simply too short a time frame for that to happen, largely because US healthcare is too diverse and judging by the pace of research in the field so far. This might be easier to do within more homogenous health systems such as those in Europe (or at least, so I hear). It is good that the funding is beginning but the goals must be realistic. Can we force something in 5 years? Sure. Just not certain that it would give the bang for the buck.
I liked Vala as a language and briefly took it for a spin, a while ago. However, without mature IDEs that Java and C# have, I found the experience closer to programming in D than C#, even though the language is closer to C#.
I would gladly take CD checks over limited installs any day. Red Alert series is known for its replayability and people play it for years on end, unlike most games. Limited install don't cut it.
EA, let us pick our poison. Enable limited installs only if the I choose the disk check to not bother them. However, the problem seems to be that disk checking is now seen as an unreliable method by the companies.
Also, do these companies plan to ultimately release patches that remove DRM after a set period of time?, say 3-5 years when they won't be running authentication servers or just simply decide that you don't own the game anymore?
But its trickier than that. It is 5 to 9 "items", not simply numbers. What constitutes an item can change. If you perceive the area code of your phone number as an item, it just counts as 1. So it all depends on how you "chunk" information. That is how experts are said to work better. They chunk at a different level than novices.
As for your phone predicament, you are not alone. At least, I am no different from you in that.
On Windows, each applications typically ships its own libs; while it reduces dependencies, it introduces duplication and severely bloats install size. *Severely* bloats install size? At 5.7 MB? For perhaps the most important app on my computer?
Wow! You are right. He is VERY liberal. I guess, I fell for a few non-representative speeches. I am a foreigner and did not know about him before the primaries.
Slashdot Mirror
VB5 and VB6 compilers could either produce p-code or *native code* (as the developer wanted). The native code executables still needed the VB runtime; but the runtime was not interpreting, but rather just providing standard routines. This is similar to say... Scheme native compilers. Even VC++ needs msvcrt. The only difference with the later was that it was more pervasive.
Your concept of *real* programming languages is rather amateur. I probably had some of those notions 15 years ago. After a couple of dozen languages or so, words like "real" loose their meaning because there are no convenient and passionate categories any more.
Dynamic linking is being used because static linking has been denied as a choice in most of the current dev tools that matter on Windows. In Delphi, I had a choice of static and dynamic linking. I always chose static linking. Most Delphi users did the same. I didn't have that choice with VB6, Java, and .NET.
Static linking is not bad. When smart linking, only the used routines from the library are bundled along, not everything in the library. When I used dynamic linking, to simplify installation for the user, I had to also distribute the full DLLs along (they would not be installed if they already exist on the target machine), even when I used only a small portion of their functionality. Consequently, my installers were always SMALLER when using static linking.
If you are developing in-house applications, this is less of a concern though since you can reasonably assume their presence on the target machines; and because you will be using the same dev tools consistently. Dynamic linking is only efficient when the involved DLLs are relatively unchanging and necessary by many apps. This also works well in Linux where a package manager with dependency tracking is an assumed part of the system. Dynamic linking has its advantages and disadvantages. But it is not a solution that uncritically deserves its current dominance.
You are not really being objective. You are comparing your older generation notebook with your current generation Mac Book. That accounts for the price better than whether Mac is value for it's price (maybe it is, but that is a different argument). It would have helped if you detailed how you defined build quality and stability. Should be easy given that you claim remarkable difference, not subtle. And it would have been fair to compare the your current MacBook to a current Windows laptop (not that I expect everyone to own more than 1 laptop at a time).
I am sued. Therefore, I am?
I should have mentioned that I did try Clojure. While it is certainly the epitome of dynamic typing and syntactic flexibility for the JVM, I rejected it for the same reasons (no code completion and other validations). Most of the software I choose to write in Java is so because of the specific libraries. Most of code ends up manipulating these libraries, not as my custom logic. If I had a lot of custom logic, I could see value in Clojure (or in Scala as I mentioned in my previous post) where I could use it for domain specific code and keep the low level, object oriented API interaction to a minimum through a few wrappers written in Java. Unfortunately, those are not the kind of applications I write these days.
My point is the same... that these may be great languages but will remain incomplete in their offerings as long as their designers/community don't take the IDE as seriously as the language design. It is fortunately not as hard as it once used to be to bridge that gap, given that Eclipse and other IDE platforms already provide much tooling. Perhaps in a few years when IDE ecosystem further matures, languages can be considered on their own merit and not based on the baggage they now carry.
I could use an alternative programming language for the JVM that is more expressive than Java. Both Scala and Groovy integrate well with Java at the language level, albeit with different type systems. While I do use Groovy from time to time, what kept me from Scala was that it is not well supported by IDEs (Eclipse/Netbeans - I hear things are somewhat better with IntelliJ). The problem is the nature of Java libraries. They tend to be deeply nested and often expressed in lower level abstractions and are difficult to use without strong IDE support. I don't need an IDE for Python (flat module systems, high level libraries), but certainly do for Java. With solid IDE support however, I am nearly as productive in Eclipse + Java as with dynamic languages, even for medium apps. Scala and Groovy come with their own standard libraries and I don't need IDE support as long as I stay within them. But sooner or later, I will need to step into plain Java land and I no longer feel productive. I would rather use straight Java for them.
The development experience is language + tools, not just the language. While Scala can piggy back on JVM and undercut the rest of the process that languages need to go through to mature and be accepted, Scala plugin (or someone else) has to provide a JDT equivalent first to have popular appeal.
I just wish there was a well supported superset of Java with productivity considerations that maintains 1:1 byte-code compatibility on compilation. Java purists can keep their language clean. But the rest of us can be happy too. Scala has that potential.... almost. So far, Groovy has been filling that role for me. Groovy will never have the kind of edit-time IDE intelligence simply due to it's dynamic nature. But for now, it stands ahead (after all, it has been around longer).
And consequently, the user base of LaTeX to that of MS Word is just about proportional to the ownership of super sonic jet pilots to that of bicycle users :-).
In Halo 1, the pistol was the BFG.
> Interestingly, it looks like India's health care system, a mix of private and public initiatives, is doing very poorly compared to the universal system in Singapore. India's healthcare system is not providing good service for their population, so I don't know why you consider it evidence of the "free" market working it's magic.
India's healthcare system is doing fine... IF you factor in what resources go into it. Most patients (non-metro) pay few cents to a couple of dollars per consultation in private clinics. This is not co-pay or care subsidized by government. It is the full amount. Given that Indian per-capita is 20 times lower than US/Singapore, Indians are getting EFFICIENT (while not an abundance of) care. My jaw dropped when I saw that a very minor emergency room visit was billed at $250 (pre-insurance) in US.
Replying my own - I would prefer to put it this way
Is it cross-platform?
Technically - Yes
Practically - Yes
Out-of-the-box - Not always.
> Technically no, practically yes. C# is .net specific and .net is windows specific. Mono is not 100% compatible.
1. If (depending on version) Mono is not a perfect port of .NET, that makes .NET code using those bits, not cross-platform. That is not the same as windows specific. For instance, not every program written in Python will run on all platforms. Some of its' standard libraries are platform specific (Eg: msvcrt). But Python is considered cross-platform.
2. C# IS cross-platform. AFAIK the compiler implementations behave identically. It's small portions of the standard library that are at fault.
But nothing stops you from writing fully cross-platform code, if you must. Just a bit more effort.
Personally, I gave up on C#. While C# is indeed better designed than Java, Groovy integrates with Java well and fills up any of the major feature and productivity gaps that I cared for anyway.
Platform independence (FYI, it is not *otherwise* known as web-based front end) and making it web available have nothing to do with its applicability. It is designed for VA clinical workflows. If you think it worked beautifully for you in a distinctly different setting, report that through a journal. I cannot take an anonymous assertion on this kind of an issue. Don't get me wrong. I would like to see it (or any other open software) get wide spread applicability. But clinical informatics has a long tradition of naive assumptions and this issue is far more complicated than a minor portability issue.
It's not just open source, it is PUBLIC DOMAIN. Federal laws that apply to medical devices do not apply to EMRs.
It already is
http://worldvista.org/
Because while CPRS is a wonderful organizational success story, Britain's EMR is a national success story. And national scale is what we are looking at right now.
In US, EMRs came early and were great in academic centers and federally funded facilities. They did not work out so well for smaller practices.
For one, CPRS does not have billing and made adoption difficult in the past. Not to mention the fact that they kept rewriting it several times. The clinicians love it because it close fit they way they worked in VA. Not surprising since a ton of money was spent perfecting it in that way. But the problem is with moving it to a non-VA setting.
BTW, there are already efforts to make CPRS more generally applicable (http://worldvista.org/). They are not a major player yet however.
Because no one knows what the standard should be about. There is no standard electronic medical record system. At the moment, everyone interprets it differently. Some scan paper and say that's enough for them. Others just type full text in. Few have them more structured. What the format will contain will depend on the intended features of the medical record and there is no clear agreement on that.
Believe it or not, health care is far more complex than what software nerds think it is and making a data format standardized without understanding its implications is just asking for trouble. There is enough health informatics literature to suggest that we don't fully understand technology insinuations in a clinical setting. Doctors will happily adopt technology that helps them and their patients. So far many remain unconvinced at the choices they have.
It is also more realistic to focus on standardizing communication between systems rather than the data formats within the systems, at least for now. There are already methods and standards that have had partial success (see HL7, IHE).
Regardless, we eventually need a standard. 5 years is simply too short a time frame for that to happen, largely because US healthcare is too diverse and judging by the pace of research in the field so far. This might be easier to do within more homogenous health systems such as those in Europe (or at least, so I hear). It is good that the funding is beginning but the goals must be realistic. Can we force something in 5 years? Sure. Just not certain that it would give the bang for the buck.
I liked Vala as a language and briefly took it for a spin, a while ago. However, without mature IDEs that Java and C# have, I found the experience closer to programming in D than C#, even though the language is closer to C#.
C# definition is openly "specified" (ECMA), not openly sourced. Mono provides the open implementation for this specification.
http://www.ecma-international.org/publications/standards/Ecma-334.htm
> given Obama's track record of generally being a bad guy
[citation needed]
I would gladly take CD checks over limited installs any day. Red Alert series is known for its replayability and people play it for years on end, unlike most games. Limited install don't cut it.
EA, let us pick our poison. Enable limited installs only if the I choose the disk check to not bother them. However, the problem seems to be that disk checking is now seen as an unreliable method by the companies.
Also, do these companies plan to ultimately release patches that remove DRM after a set period of time?, say 3-5 years when they won't be running authentication servers or just simply decide that you don't own the game anymore?
7 is not the hard number the way the summary makes it sound. The range was claimed as 5-9.
http://www.musanim.com/miller1956/
A classic 50 yr old paper. Has been a subject of great debate since.
But its trickier than that. It is 5 to 9 "items", not simply numbers. What constitutes an item can change. If you perceive the area code of your phone number as an item, it just counts as 1. So it all depends on how you "chunk" information. That is how experts are said to work better. They chunk at a different level than novices.
As for your phone predicament, you are not alone. At least, I am no different from you in that.
You might have been lucky to pay $82, but that is not the going price for a used 770. I am yet to see one on sale for double that.
At 5.7 MB? For perhaps the most important app on my computer?
Writing to NTFS works fine. I did work with a Wubi install this way. I wish Wubi added a mount point to its disk image in Windows though.
Wow! You are right. He is VERY liberal. I guess, I fell for a few non-representative speeches. I am a foreigner and did not know about him before the primaries.