UML tools are CASE tools. For that matter, Word and Visio can be considered CASE tools. THe most advanced ones may generate class headers and stub implementation files.
Compilers and interpreters are not usually placed under this umbrella.
VPLs are compilers and interpreters, not CASE tools. The VPL is the programming language itself.
On top of that I never used the term "silver bullet." At best VPLs will make design and maintenance easier, but not by orders of magnitude required to call it a silver bullet. It's just another way to design and write code, one that I believe has real promise over the long term.
Well I think that says something, but I don't think that is somehow a proof that research along this line is a dead-end. All it means is that none of the variants you've tried are a big success.
There's no reason that VPL should be hard to use, slow or inflexible. There are certainly implementations that are.
It's a young field of study that hasn't got much attention, and I don't think there's any fundamental flaw in the concept, just some fledgling attempts.
I agree they have been around for a while, and most do suck.
I think they could be better, and they have gotten better over time. LabView I think is a better example, with the ability to make components and state machines visually.
The human brain is geared more towards processing of visual information than it is textual information. I think to reach our full potential as programmers that's where we need to go.
Also I think having a visual representation of the design which is always up to date because it is also the implementation, makes emphasizing research in this branch of programming languages worth it.
Visual Programming Language
on
How Do You Use UML?
·
· Score: 2, Interesting
It sounds like what you are really interested in is not UML but VPLs, Visual Programming Language (not to be confused with things like Visual Basic which is a fairly normal programming paradigm with some RAD gui development tools built in).
Programming with boxes and wires is the way you code in such languages. Anyway google for visual programming language and you will find lots of stuff. The VPLs also allow you to draw your state machine for a component visually. This permits writing your entire application visually, as opposed to just connecting up components.
I think one of these days we'll create all applications in this way. What could be better for an architect than having your entire application as a very clear, always up-to-date diagram, which can be zoomed in or out to get whatever level of implementation detail you like?
The solution to such problems is redundancy. One efficient form is padding with extra bits to add error correcting codes.
Science fiction may have an answer too. I believe the Slavers [Niven, Known Space series] engineered giant food animals (with intelligence just because the Slavers were really mean) that had specially engineered DNA so that they would not be impacted by radiation. As you say, mutation is necessary in evolving systems, but if one were engineering a system, you'd want to take that out of the equation.
Perhaps not science, but that can be the beginning of a valid technique of proof. In mathematics, it is the first step in a "Proof By Contradiction."
Assume some statement as true which you believe to be false, and demonstrate how it contradicts another statement already proven true or which is a postulate or axiom. If you can do this, you have proven the original statement false.
Not that this is what OP intended of course, but a contradiction to "You don't assume things and then try to disprove them." Sometimes you do.
As a code geek in school, I would have liked to see some simple interfacing projects. Say, make a logic analyzer out of a parallel port, or drive a LED 7-segment display.
I always thought yet another crystal radio, or running a motor or light bulb was kind of boring. Didn't hold my attention.
Also you might consider demonstrating how to hack off-the-shelf hardware... take things apart, how to tell what different components are and what they do, how to determine how a chip is mapped into memory, connect to a memory bus (think Mailstation, etc) to add new components...
Connect tools, scopes, analyzers, etc. to show what is happening in the circuit. Measure voltages and show how they match up with the specification for the part...
Well, you could just pop the browser up with the full text of the GPL, and have a dancing RMS elf walk them through gearhead freedom issues that no one but us really care about...
How about... if it were the Christmas card, and you gave instructions on how to boot it, and that it's *safe* and doesn't install anything to their hard drive. Some people might try it out.
Have it boot up, pop open a browser and show some online christmas card that you know is safe.
After that closes, have a stocking or something that says "click me" which is really a folder with a bunch of games in it.
A. You should not do patent research (treble damages). Don't feel bad... big companies don't do this research either, for the same reason. B. As a small operation, you're not the target of infringement lawsuits. C. If you're doing closed-source software, they probably won't be able to tell you're infringing unless it's some patented video or audio codec implementation.
Keep in mind that you don't go straight from infringement to a lawsuit. The patent holder may well just want you to take a license, which can be negotiated as a royalty paid to them on copies of the software you sell.
If you can't afford a license, or they won't sell you one, you will have to rework your code not to use the patented idea.
The sky isn't falling. There are all manner of different liabilities that can pop up for any business at any time. There is no way to predict it. That's what insurance and indemnification are for.
I've started using external hard drives for backup. There is just no other low cost solution for backup. The USB/Firewire enclosures are pretty cheap, so it is easy to connect and disconnect the drive.
Doesn't it make more sense to rip to FLAC, and use a script to reencode to the format your portable player accepts? For the near future that format is going to be MP3, but eventually that could change.
I often put summary comments that say what the code is doing, not just why it is doing it.
Yeah each line in and of itself should be understandable to a programmer who understands the language. I wouldn't recommend a comment on every line (unless it's assembly code).
I tend to have blocks of 4-7 lines of code, and each gets a comment stating what that block of code does. It's a summary. By looking at 4 or 5 lines of comments on blocks you can tell what the whole routine is doing.
When doing maintenance programming, I usually care more about what the coder is trying to do than why. The why tends to be obvious from the name of the function, or what it does. If the why is totally non-obvious, it's usually because it is so complex that you really need to be reading a separate standard document, or a high level (usually high powered matH) design document.
Come on... TQFP isn't that bad. The fact is you just can't get decent pricing on flash, ram as DIP.
Anyway the real scary thing for hobbyists is BGA.
Circuit cellar had an article recently on converting a reflow oven out of a toaster oven. Or you could just use a hot plate to reflow the solder. So surface mount parts are definitely doable, and PCB prototyping houses charge fairly reasonable rates. So you should consider not fussing with breadboarding/wirewrap.
Alternatively with a laser printer and label backing you can make artwork to etch your own PCBs.
Ah, you actually make a valid point that I missed, about contractors. Here's the section of the "GPL FAQ" (which btw, is not the GPL, so it's a little suspect)
That is interesting. Keep in mind that my point still stands; I said that Connelly's case hinges on whether the programmer infringed on his copyright, and whether he distributed the code or not. If by default employing an off-site contractor you automatically are considered under the GPL to be distributing the work, then yes, he distributed it, end of story, as long as the GPL does say that, and a court would enforce it.
Here is the section of the GPL FAQ for folks to look at on their own:
Is making and using multiple copies within one organization or company "distribution"? No, in that case the organization is just making the copies for itself. As a consequence, a company or other organization can develop a modified version and install that version through its own facilities, without giving the staff permission to release that modified version to outsiders.
However, when the organization transfers copies to other organizations or individuals, that is distribution. In particular, providing copies to contractors for use off-site is distribution.
>RTFA. I did, I even read the whole thing:-) That's how I know you're wrong. Grow up a little and admit your mistakes.
> The code between the two derivative works that create lead story blocks is not the same code.
I'm not arguing this point at all. My issue is with your interpretation of the GPL.
You may be wrong there too... you don't have to make a verbatim copy to be infringing. It's actually fairly complex in that regard.
>RTFA. I did, stop saying that!
> Owning the copyright to GPL code means little other than the fact that you get credit for it.
Sweet Jesus! It means a heckuvalot more than that. Let me count the ways:
It means you own the work, which in turn means that you can license it under any and as many licenses as you like. It means you can sue someone for infringment if they make a copy without a license that allows it (and if they violate the GPL and you license under the GPL, that person may not have any license to distribute). It means you can sell your work, make copies without worrying about licensing etc.
No, owning copyright on a GPLed work is *very* important.
Now in this case, owning copyright on a small patch to a GPLed work is certainly of less value than if you had written the whole thing from scratch since other parties have ownership claims on parts of the collective work which you have to respect.
> RTFA. Come on, I did read it, quit it already!
> The code was not copied. The code in Mambo does not belong to Connolly in any way shape or form.
I didn't say the code was copied, I made no assertion as to that in any way. Please reread my comment.
The author doesn't seem to understand how the GPL works.
If I make changes to a GPL'ed work, they are my changes. I own the copyright. I don't own the copyright to the entire work, but I own my changes. Imagine my changes as a diff file with a copyright on it.
If I distribute it, the GPL requires that I license my copyrighted code under the GPL.
The author completely misses this point, and in fact makes the assertion that if you derive a work from GPLed code that your work is automatically GPLed. This is a common fallacy. I can't believe it made Newsforge as such.
The only issue here is whether a) the code was copied such that it is close enough to be considered infringement and b) whether Connelly distributed the code outside of his organization.
If that would be useful, there's nothing to stop someone from developing a.sxw file converter for MS Word.
I like the tricky logic of it. Spread openoffice file format by allowing users to open files without forcing them to switch to openoffice. If the strategy works and the format catches on, that could reduce the lock-in factor.
Ah, you've never read Hero With a Thousand Faces by Joseph Campbell.
Star Wars is a prototypical Hero's Journey story. It is not original in Star Wars, or The Lord of The Rings, or The Neverending Story, or The Last Starfighter, or Beowulf, or The Odyssey,...
I really think TLS was a pretty creative movie, and "rip-off" is neither fair nor even helpful in understanding what it was about...
Well, putting the OS into flash disk won't achieve what you want either... first the flash disk really does have a lot of overhead, which you shouldn't discount.
However, if you look at a typical Linux system booting up it actually spends most of its time serially running init scripts, many of which are I/O bound in some way.
The biggest bang for the buck I've heard of is running init through "make" and creating a makefile with correct dependencies for the init scripts so that they can be run in parallel. That plus Linuxbios could get you an instant-on box.
Another way to do it, would be to tune a good "suspend to disk" type image to get the hardware brought up right. If you really thought it could work, you could even suspend to a flash disk, then always boot from the flash.
Once upon a time computers did boot their normal operating environment instantaneously. They had ROM mapped into the address space of the CPU. You turn on any TRS-80 Model 100, Color Computer, Commodore 64, etc. and your computer is ready to work because it's code is mapped into RAM much like a PC BIOS chip.
Keep in mind though that when folks hook up a flash drive to their computer that they are not mapping it directly into RAM, rather they are layering on top a file system, so it's not going to be instantaneous.
If you want instantaneous on a modern PC, you need to go for something like LinuxBIOS project, and replace the PC BIOS with a kernel.
Slashdot Mirror
How to answer that... how about No?
UML tools are CASE tools. For that matter, Word and Visio can be considered CASE tools. THe most advanced ones may generate class headers and stub implementation files.
Compilers and interpreters are not usually placed under this umbrella.
VPLs are compilers and interpreters, not CASE tools. The VPL is the programming language itself.
On top of that I never used the term "silver bullet." At best VPLs will make design and maintenance easier, but not by orders of magnitude required to call it a silver bullet. It's just another way to design and write code, one that I believe has real promise over the long term.
Well I think that says something, but I don't think that is somehow a proof that research along this line is a dead-end. All it means is that none of the variants you've tried are a big success.
There's no reason that VPL should be hard to use, slow or inflexible. There are certainly implementations that are.
It's a young field of study that hasn't got much attention, and I don't think there's any fundamental flaw in the concept, just some fledgling attempts.
I agree they have been around for a while, and most do suck.
I think they could be better, and they have gotten better over time. LabView I think is a better example, with the ability to make components and state machines visually.
The human brain is geared more towards processing of visual information than it is textual information. I think to reach our full potential as programmers that's where we need to go.
Also I think having a visual representation of the design which is always up to date because it is also the implementation, makes emphasizing research in this branch of programming languages worth it.
It sounds like what you are really interested in is not UML but VPLs, Visual Programming Language (not to be confused with things like Visual Basic which is a fairly normal programming paradigm with some RAD gui development tools built in).
Programming with boxes and wires is the way you code in such languages. Anyway google for visual programming language and you will find lots of stuff. The VPLs also allow you to draw your state machine for a component visually. This permits writing your entire application visually, as opposed to just connecting up components.
I think one of these days we'll create all applications in this way. What could be better for an architect than having your entire application as a very clear, always up-to-date diagram, which can be zoomed in or out to get whatever level of implementation detail you like?
It's much easier to ignore noise you create yourself than to ignore noise created by others.
I always use a "clicky" buckling spring UNICOMP keyboard. Once I start typing the rest of the world just disappears.
Tough nuggies for everyone else.
I guess the downside is everyone can tell when I'm on my 45 minute space-out.
The solution to such problems is redundancy. One efficient form is padding with extra bits to add error correcting codes.
Science fiction may have an answer too. I believe the Slavers [Niven, Known Space series] engineered giant food animals (with intelligence just because the Slavers were really mean) that had specially engineered DNA so that they would not be impacted by radiation. As you say, mutation is necessary in evolving systems, but if one were engineering a system, you'd want to take that out of the equation.
Perhaps not science, but that can be the beginning of a valid technique of proof. In mathematics, it is the first step in a "Proof By Contradiction."
Assume some statement as true which you believe to be false, and demonstrate how it contradicts another statement already proven true or which is a postulate or axiom. If you can do this, you have proven the original statement false.
Not that this is what OP intended of course, but a contradiction to "You don't assume things and then try to disprove them." Sometimes you do.
-- John.
That was my first thought given given this article is from the "Beanstalk dept."
-- John.
My understanding is that some languages do not have a plural form as English does.
Hence "fish and chip, $5"
As a code geek in school, I would have liked to see some simple interfacing projects. Say, make a logic analyzer out of a parallel port, or drive a LED 7-segment display.
I always thought yet another crystal radio, or running a motor or light bulb was kind of boring. Didn't hold my attention.
Also you might consider demonstrating how to hack off-the-shelf hardware... take things apart, how to tell what different components are and what they do, how to determine how a chip is mapped into memory, connect to a memory bus (think Mailstation, etc) to add new components...
Connect tools, scopes, analyzers, etc. to show what is happening in the circuit. Measure voltages and show how they match up with the specification for the part...
Well, you could just pop the browser up with the full text of the GPL, and have a dancing RMS elf walk them through gearhead freedom issues that no one but us really care about...
How about... if it were the Christmas card, and you gave instructions on how to boot it, and that it's *safe* and doesn't install anything to their hard drive. Some people might try it out.
Have it boot up, pop open a browser and show some online christmas card that you know is safe.
After that closes, have a stocking or something that says "click me" which is really a folder with a bunch of games in it.
That's more like something someone would want...
A. You should not do patent research (treble damages). Don't feel bad... big companies don't do this research either, for the same reason.
B. As a small operation, you're not the target of infringement lawsuits.
C. If you're doing closed-source software, they probably won't be able to tell you're infringing unless it's some patented video or audio codec implementation.
Keep in mind that you don't go straight from infringement to a lawsuit. The patent holder may well just want you to take a license, which can be negotiated as a royalty paid to them on copies of the software you sell.
If you can't afford a license, or they won't sell you one, you will have to rework your code not to use the patented idea.
The sky isn't falling. There are all manner of different liabilities that can pop up for any business at any time. There is no way to predict it. That's what insurance and indemnification are for.
It's a good point.
I've started using external hard drives for backup. There is just no other low cost solution for backup. The USB/Firewire enclosures are pretty cheap, so it is easy to connect and disconnect the drive.
Doesn't it make more sense to rip to FLAC, and use a script to reencode to the format your portable player accepts? For the near future that format is going to be MP3, but eventually that could change.
I believe MythTV will rip cd's, has a user friendly menuing system, etc.
I often put summary comments that say what the code is doing, not just why it is doing it.
:-)
Yeah each line in and of itself should be understandable to a programmer who understands the language. I wouldn't recommend a comment on every line (unless it's assembly code).
I tend to have blocks of 4-7 lines of code, and each gets a comment stating what that block of code does. It's a summary. By looking at 4 or 5 lines of comments on blocks you can tell what the whole routine is doing.
When doing maintenance programming, I usually care more about what the coder is trying to do than why. The why tends to be obvious from the name of the function, or what it does. If the why is totally non-obvious, it's usually because it is so complex that you really need to be reading a separate standard document, or a high level (usually high powered matH) design document.
So I guess I don't agree with you
Come on... TQFP isn't that bad. The fact is you just can't get decent pricing on flash, ram as DIP.
Anyway the real scary thing for hobbyists is BGA.
Circuit cellar had an article recently on converting a reflow oven out of a toaster oven. Or you could just use a hot plate to reflow the solder. So surface mount parts are definitely doable, and PCB prototyping houses charge fairly reasonable rates. So you should consider not fussing with breadboarding/wirewrap.
Alternatively with a laser printer and label backing you can make artwork to etch your own PCBs.
Ah, you actually make a valid point that I missed, about contractors. Here's the section of the "GPL FAQ" (which btw, is not the GPL, so it's a little suspect)
That is interesting. Keep in mind that my point still stands; I said that Connelly's case hinges on whether the programmer infringed on his copyright, and whether he distributed the code or not. If by default employing an off-site contractor you automatically are considered under the GPL to be distributing the work, then yes, he distributed it, end of story, as long as the GPL does say that, and a court would enforce it.
Here is the section of the GPL FAQ for folks to look at on their own:
Is making and using multiple copies within one organization or company "distribution"?
No, in that case the organization is just making the copies for itself. As a consequence, a company or other organization can develop a modified version and install that version through its own facilities, without giving the staff permission to release that modified version to outsiders.
However, when the organization transfers copies to other organizations or individuals, that is distribution. In particular, providing copies to contractors for use off-site is distribution.
>RTFA. :-) That's how I know you're wrong. Grow up a little and admit your mistakes.
I did, I even read the whole thing
> The code between the two derivative works that create lead story blocks is not the same code.
I'm not arguing this point at all. My issue is with your interpretation of the GPL.
You may be wrong there too... you don't have to make a verbatim copy to be infringing. It's actually fairly complex in that regard.
>RTFA.
I did, stop saying that!
> Owning the copyright to GPL code means little other than the fact that you get credit for it.
Sweet Jesus! It means a heckuvalot more than that. Let me count the ways:
It means you own the work, which in turn means that you can license it under any and as many licenses as you like. It means you can sue someone for infringment if they make a copy without a license that allows it (and if they violate the GPL and you license under the GPL, that person may not have any license to distribute). It means you can sell your work, make copies without worrying about licensing etc.
No, owning copyright on a GPLed work is *very* important.
Now in this case, owning copyright on a small patch to a GPLed work is certainly of less value than if you had written the whole thing from scratch since other parties have ownership claims on parts of the collective work which you have to respect.
> RTFA.
Come on, I did read it, quit it already!
> The code was not copied. The code in Mambo does not belong to Connolly in any way shape or form.
I didn't say the code was copied, I made no assertion as to that in any way. Please reread my comment.
Fixing my twisted broken logic at the end there is left as an excercise for the reader
The author doesn't seem to understand how the GPL works.
If I make changes to a GPL'ed work, they are my changes. I own the copyright. I don't own the copyright to the entire work, but I own my changes. Imagine my changes as a diff file with a copyright on it.
If I distribute it, the GPL requires that I license my copyrighted code under the GPL.
The author completely misses this point, and in fact makes the assertion that if you derive a work from GPLed code that your work is automatically GPLed. This is a common fallacy. I can't believe it made Newsforge as such.
The only issue here is whether a) the code was copied such that it is close enough to be considered infringement and b) whether Connelly distributed the code outside of his organization.
If either are untrue, Connelly has no case.
If that would be useful, there's nothing to stop someone from developing a .sxw file converter for MS Word.
I like the tricky logic of it. Spread openoffice file format by allowing users to open files without forcing them to switch to openoffice. If the strategy works and the format catches on, that could reduce the lock-in factor.
Ah, you've never read Hero With a Thousand Faces by Joseph Campbell.
...
Star Wars is a prototypical Hero's Journey story. It is not original in Star Wars, or The Lord of The Rings, or The Neverending Story, or The Last Starfighter, or Beowulf, or The Odyssey,
I really think TLS was a pretty creative movie, and "rip-off" is neither fair nor even helpful in understanding what it was about...
Well, putting the OS into flash disk won't achieve what you want either... first the flash disk really does have a lot of overhead, which you shouldn't discount.
However, if you look at a typical Linux system booting up it actually spends most of its time serially running init scripts, many of which are I/O bound in some way.
The biggest bang for the buck I've heard of is running init through "make" and creating a makefile with correct dependencies for the init scripts so that they can be run in parallel. That plus Linuxbios could get you an instant-on box.
Another way to do it, would be to tune a good "suspend to disk" type image to get the hardware brought up right. If you really thought it could work, you could even suspend to a flash disk, then always boot from the flash.
Once upon a time computers did boot their normal operating environment instantaneously. They had ROM mapped into the address space of the CPU. You turn on any TRS-80 Model 100, Color Computer, Commodore 64, etc. and your computer is ready to work because it's code is mapped into RAM much like a PC BIOS chip.
Keep in mind though that when folks hook up a flash drive to their computer that they are not mapping it directly into RAM, rather they are layering on top a file system, so it's not going to be instantaneous.
If you want instantaneous on a modern PC, you need to go for something like LinuxBIOS project, and replace the PC BIOS with a kernel.