Try doing that in LabVIEW. When the smallest property of those bundles change (i.e. more number of wires in the bundle, or a different data type for one wire), you have to change a number of things to make the things connecting to that bundle work again.
If you have been working with LV for a while, you should know about Type Definitions and possibly LVOOP/LV Class architecture. In short, you can EASILY do what you are talking about, as long as you have some idea how to use good practices in labview (and no, it doesn't take significantly more time, any more than avoiding GOTO statements).
In short, there are very simple "BKM"s in LV as there are in any language that will allow you to deal with exactly that (and other) situations.
Let me just put it this way: modifying a LabVIEW program is like trying to modify an electronic circuit---except that, very often, you won't have a circuit diagram in your hand, and you won't have any explanations as to why certain things were wired in a certain way.
And this is different from a poorly written text program how? I write my LV code in such a way that you can understand it by looking at it, amendable and commented.
Labview's biggest weakness is that it IS so easy to get a working program up that people who have never seen it before and get things done- sometimes rather horribly. But compare that to someone trying to write a deterministic piece of code in VB who has never seen a line of code before. They just can't (in a short period of time). But like any language, there are good and bad practices.
but for complex jobs interfacing with other programs or systems it becomes cumbersome.
Well, that's just wrong. LV excels at bringing together other systems. I'll admit right away that the old DLL interface nodes are a pain in the neck, but ActiveX/.NET nodes could not be easier.
I have worked on OOP labview systems with thousands of VIs (I suppose you could take that to mean 25,000 lines of code?). And we never hesitated to "interface" to another system or program. Most problems we had were due to lazy documentation by the people writing other libraries.
What kind of number crunching? I have never seen anything that couldn't be implemented in LV; albeit there are some cases where a DLL might have a faster interface.
I guess I am saying that while MATLAB certainly has advantages over labview, if you get to that point, you should be able to find either a labview library or DLL/.net assembly that can perform your calculations.
Why not recode the MATLAB routine in C, then create a DLL and avoid the MATLAB license fee?
Yes and no. LV started out like that- as a tool for engineers to implement their DAQ ideas without having to teach a programmer about physics.
But around 5 years ago NI came 'round and started to listen to the developer community- and continuously improved the "IDE" to bring it in line with other languages.
Since around 1998, I do not hesitate to tell people that if it can be done in java/VB, I can do it in LV. There are probably exceptions to that rule, but I haven't come across them.
By the way,
ou will find yourself spending most of your time moving lines on your screen because there is no free space left on the flow diagram for that extra feature that you need to implement.
is the equivalent of saying that C is a lousy language because eventually you have a 30,000 line program in on text file and you spend all your time hitting CTRL-F to jump around.
LabVIEW, in a sense, encourages all the "bad practices" of programming: it's not sufficiently easy to add comments: there should be more facilities for tagging, describing, and searching said info; almost everything ends up being global or having too large a scope; the wiring-diagram motif creates the equivalent of GOTOs, where you're trying to figure out where a value came from; overall code ends up tangled and difficult to maintain;...
Whoa. While some of that may be true (the facilities for tagging and searching are rather lax) the resulting code that is written is only as good as the programmer.
It's absolutely true that NEW labview programmers write spaghetti code more often than not. But just like GOTO statements, the mantra of the trained community is "No Globals!".
I will say this- when I step into a bad labview project, I can figure out what is going on fairly quickly. The debugging mode and visual nature excel in that respect. Opening a bad C# or even VB.net project can take days to figure out.
Bad code is bad code in any language.
I will agree that it takes a little more time to code very simple things, but it usually takes less time to code more complex things.
I think your ideas of LV are out of date.
I make my living writing labview code, and about 1/2 of what I write are off-line data analysis programs. This includes FFT, image analysis, complex math, matrix math, etc.
I don't love MS either. But when was the last time you got a BSOD on XP? I have crashes on XP about as often as I do on my debian server.
The only BSODs I have had on XP have been when I ran VERY BAD software. Interestingly, the last one was two weeks ago when I was using a driver to read an ext2 volume mounted over USB.
Yes, I have crashes on my debian box- the latest was somthing that rsync did that locked me out of both local and ssh connections. (Seriously. I have no idea what was happening and had to kill the machine) And no, I am not a linux guru. But if I have problems like these with my intermediate level of knowledge, then you'd better belive that joe blow will too.
OK. So it's a CMS. But it works great as a blog and is OSS. I have recently switched to it on my server, and it seems to handle everything better than Wordpress (I had a lot of spamming problems, and could never get the anti-spam additions to work). With drupal, I have had no problems with it or any of the modules I have installed.
drupal.org
I would like to see more features and I am upset that the new DirecTivo is unhackable, but when it all comes down to reliability. My TiVos have never failed me.
I would love to put together the same functionality with software. But the hardware cost alone would be > $500. I also consider myself to be capable of putting one together- but I didn;t want to deal with all that work. And what if the distro I chose was no good? There are people complaining about problems with MythTV, etc. How much time and effort do I need to spend on it?
It's true that inkjets today do a great job, especially compared to a few years ago.
However I found that it was extremely difficult to maintain consistancy with an inkjet. I had to recalibrate each time I swapped cartidges, paper, etc.
Now, if you compare this to an online site such as ofoto, you are comparing apples and oranges. They don't care about your prints, they don't maintain good equipment, etc. I have no idea what systems they are printing on.
I used to take my digital prints to a professional lab. I could download their weekly color calibration for Photoshop, I could trust them not to steal or abuse my art, and I ccunted on ecellent service, attention to detail and outstanding images. And I could also count on insanely high prices.
About 18 months ago I discovered Wolf and Ritz had standardized on a Fuji Frontier printing system. I have found it to be an excellent compromise. Their prints ar cheap (as low as $.19 4X6s, $5 8X10) and the prints are usually terriffic. Most stores have caring employees that will rerun/recrop your images if there was a problem. I have found a couple stores where they could care less though, and that makes it harder. But I would say I am very happy 9/10 times I go there. (I am sure there are other chains or small stores that are just as good. Photoworks here in SF, I think?).
BUT you really need to know what you are doing- FOR ANY PRINT LAB! Crop your pics to the final output ahead of time. Make sufre you account for differences in resolution and final aspect ratio. Make sure you account for white borders, if that is what you want. Know and understand any image manipulation/enhancement techniques they use.
So here's my suggestions:
InkJet: Use for discreet pics and for messing around. If you really want to put time and effort into it, do so. I have several images that I printed on an inkjet that I think are wonderful. But I would say that a *good* chemical processing beats ink jet in most situations for color range and contrast.
Online mail-back (ofoto, etc): You have got to be kidding.
Walgreens/Costco/Walmart: You might get decent stuff from one of these, but the people runnning the machines most likely have no idea what they are doing, and could care less about your prints. I have never been happy with prints from these places.
Wolf/Ritz/Other amatuer/semipro store: I find these to be a good compromise. If you find one near you that you trust, with employees that will work with you and care about your order, I think it's a good way to go. Some of these places have online submission sites, so you can pick up the prints. I DO NOT RECCOMEND having them mail them back. If there is a problem, it's usually harder to get it fixed.
Pro Color Lab: This is what you do if you want the best image possible. But can be expensive (although I know a lab here in SF that will do $.25 4X6s- but anything bigger is still pretty expensive).
Note about black and white digital: I have done quite a lot of BW chemical printing, some inkjet BW and a lot of RGB black and white on color systems. My opinion is that if you want the best looking black and white print, you have to enlarge it on silver-based chemistry.
I also feel that color digital cameras are not suited to general BW photography. This has to do with the nature of a three-color digital imaging chip (CCD or CMOS).
My choice for BW is to shoot on BW film, scan the negatives in a grayscale mode, manipulate and then have an image output back to negative film for enlarging on silver-based emulsion. I have done this on several occaisions, usually after having inkjet or RGB-BW prints made to test first. The other methods do not compare. I know this sounds insane, but there is no substitute at the moment. And those silver prints will last 1000 years if cared for.
FYI, Intel has not laid of employees for years and years (1983 I think?).
Intel is an extremely well-managed company. When they need to reduce workforce, they have done so by attrition (not replacing people when they leave).
Now, if you are talking about Applied Materials or most other semiconductor companies, that is true. They will spend like mad when things are good, and inflate their employee numbers with dead weight. Then when the cycle turns down, they dump these people on their asses.
Slashdot Mirror
Try doing that in LabVIEW. When the smallest property of those bundles change (i.e. more number of wires in the bundle, or a different data type for one wire), you have to change a number of things to make the things connecting to that bundle work again.
If you have been working with LV for a while, you should know about Type Definitions and possibly LVOOP/LV Class architecture. In short, you can EASILY do what you are talking about, as long as you have some idea how to use good practices in labview (and no, it doesn't take significantly more time, any more than avoiding GOTO statements).
In short, there are very simple "BKM"s in LV as there are in any language that will allow you to deal with exactly that (and other) situations.
Let me just put it this way: modifying a LabVIEW program is like trying to modify an electronic circuit---except that, very often, you won't have a circuit diagram in your hand, and you won't have any explanations as to why certain things were wired in a certain way.
And this is different from a poorly written text program how? I write my LV code in such a way that you can understand it by looking at it, amendable and commented.
Labview's biggest weakness is that it IS so easy to get a working program up that people who have never seen it before and get things done- sometimes rather horribly. But compare that to someone trying to write a deterministic piece of code in VB who has never seen a line of code before. They just can't (in a short period of time). But like any language, there are good and bad practices.
but for complex jobs interfacing with other programs or systems it becomes cumbersome.
Well, that's just wrong. LV excels at bringing together other systems. I'll admit right away that the old DLL interface nodes are a pain in the neck, but ActiveX/.NET nodes could not be easier.
I have worked on OOP labview systems with thousands of VIs (I suppose you could take that to mean 25,000 lines of code?). And we never hesitated to "interface" to another system or program. Most problems we had were due to lazy documentation by the people writing other libraries.
What kind of number crunching? I have never seen anything that couldn't be implemented in LV; albeit there are some cases where a DLL might have a faster interface.
I guess I am saying that while MATLAB certainly has advantages over labview, if you get to that point, you should be able to find either a labview library or DLL/.net assembly that can perform your calculations.
Why not recode the MATLAB routine in C, then create a DLL and avoid the MATLAB license fee?
But around 5 years ago NI came 'round and started to listen to the developer community- and continuously improved the "IDE" to bring it in line with other languages.
Since around 1998, I do not hesitate to tell people that if it can be done in java/VB, I can do it in LV. There are probably exceptions to that rule, but I haven't come across them.
By the way,
ou will find yourself spending most of your time moving lines on your screen because there is no free space left on the flow diagram for that extra feature that you need to implement.
is the equivalent of saying that C is a lousy language because eventually you have a 30,000 line program in on text file and you spend all your time hitting CTRL-F to jump around.
LabVIEW, in a sense, encourages all the "bad practices" of programming: it's not sufficiently easy to add comments: there should be more facilities for tagging, describing, and searching said info; almost everything ends up being global or having too large a scope; the wiring-diagram motif creates the equivalent of GOTOs, where you're trying to figure out where a value came from; overall code ends up tangled and difficult to maintain; ...
Whoa. While some of that may be true (the facilities for tagging and searching are rather lax) the resulting code that is written is only as good as the programmer. It's absolutely true that NEW labview programmers write spaghetti code more often than not. But just like GOTO statements, the mantra of the trained community is "No Globals!". I will say this- when I step into a bad labview project, I can figure out what is going on fairly quickly. The debugging mode and visual nature excel in that respect. Opening a bad C# or even VB.net project can take days to figure out. Bad code is bad code in any language. I will agree that it takes a little more time to code very simple things, but it usually takes less time to code more complex things.
I think your ideas of LV are out of date. I make my living writing labview code, and about 1/2 of what I write are off-line data analysis programs. This includes FFT, image analysis, complex math, matrix math, etc.
I don't love MS either. But when was the last time you got a BSOD on XP? I have crashes on XP about as often as I do on my debian server. The only BSODs I have had on XP have been when I ran VERY BAD software. Interestingly, the last one was two weeks ago when I was using a driver to read an ext2 volume mounted over USB. Yes, I have crashes on my debian box- the latest was somthing that rsync did that locked me out of both local and ssh connections. (Seriously. I have no idea what was happening and had to kill the machine) And no, I am not a linux guru. But if I have problems like these with my intermediate level of knowledge, then you'd better belive that joe blow will too.
OK. So it's a CMS. But it works great as a blog and is OSS. I have recently switched to it on my server, and it seems to handle everything better than Wordpress (I had a lot of spamming problems, and could never get the anti-spam additions to work). With drupal, I have had no problems with it or any of the modules I have installed. drupal.org
Sheep with too much money?
DirectTiVo: $99
Rebate: $100
---------------
Cost $-1.00
+ $8/month
And it works, 24/7 no problem.
I would like to see more features and I am upset that the new DirecTivo is unhackable, but when it all comes down to reliability. My TiVos have never failed me.
I would love to put together the same functionality with software. But the hardware cost alone would be > $500. I also consider myself to be capable of putting one together- but I didn;t want to deal with all that work. And what if the distro I chose was no good? There are people complaining about problems with MythTV, etc. How much time and effort do I need to spend on it?
It's true that inkjets today do a great job, especially compared to a few years ago.
However I found that it was extremely difficult to maintain consistancy with an inkjet. I had to recalibrate each time I swapped cartidges, paper, etc.
Now, if you compare this to an online site such as ofoto, you are comparing apples and oranges. They don't care about your prints, they don't maintain good equipment, etc. I have no idea what systems they are printing on.
I used to take my digital prints to a professional lab. I could download their weekly color calibration for Photoshop, I could trust them not to steal or abuse my art, and I ccunted on ecellent service, attention to detail and outstanding images. And I could also count on insanely high prices.
About 18 months ago I discovered Wolf and Ritz had standardized on a Fuji Frontier printing system. I have found it to be an excellent compromise. Their prints ar cheap (as low as $.19 4X6s, $5 8X10) and the prints are usually terriffic. Most stores have caring employees that will rerun/recrop your images if there was a problem. I have found a couple stores where they could care less though, and that makes it harder. But I would say I am very happy 9/10 times I go there. (I am sure there are other chains or small stores that are just as good. Photoworks here in SF, I think?).
BUT you really need to know what you are doing- FOR ANY PRINT LAB! Crop your pics to the final output ahead of time. Make sufre you account for differences in resolution and final aspect ratio. Make sure you account for white borders, if that is what you want. Know and understand any image manipulation/enhancement techniques they use.
So here's my suggestions:
InkJet: Use for discreet pics and for messing around. If you really want to put time and effort into it, do so. I have several images that I printed on an inkjet that I think are wonderful. But I would say that a *good* chemical processing beats ink jet in most situations for color range and contrast.
Online mail-back (ofoto, etc): You have got to be kidding.
Walgreens/Costco/Walmart: You might get decent stuff from one of these, but the people runnning the machines most likely have no idea what they are doing, and could care less about your prints. I have never been happy with prints from these places.
Wolf/Ritz/Other amatuer/semipro store: I find these to be a good compromise. If you find one near you that you trust, with employees that will work with you and care about your order, I think it's a good way to go. Some of these places have online submission sites, so you can pick up the prints. I DO NOT RECCOMEND having them mail them back. If there is a problem, it's usually harder to get it fixed.
Pro Color Lab: This is what you do if you want the best image possible. But can be expensive (although I know a lab here in SF that will do $.25 4X6s- but anything bigger is still pretty expensive).
Note about black and white digital:
I have done quite a lot of BW chemical printing, some inkjet BW and a lot of RGB black and white on color systems. My opinion is that if you want the best looking black and white print, you have to enlarge it on silver-based chemistry.
I also feel that color digital cameras are not suited to general BW photography. This has to do with the nature of a three-color digital imaging chip (CCD or CMOS).
My choice for BW is to shoot on BW film, scan the negatives in a grayscale mode, manipulate and then have an image output back to negative film for enlarging on silver-based emulsion. I have done this on several occaisions, usually after having inkjet or RGB-BW prints made to test first. The other methods do not compare. I know this sounds insane, but there is no substitute at the moment. And those silver prints will last 1000 years if cared for.
FYI, Intel has not laid of employees for years and years (1983 I think?). Intel is an extremely well-managed company. When they need to reduce workforce, they have done so by attrition (not replacing people when they leave). Now, if you are talking about Applied Materials or most other semiconductor companies, that is true. They will spend like mad when things are good, and inflate their employee numbers with dead weight. Then when the cycle turns down, they dump these people on their asses.
It is faster to develop an application in VB than any other Language
So wrong. Have you heard of labVIEW? Can do just about anything that VB does. and you really don't have to know jack about programming to get started.
http://www.ni.com