So here is the deal. Most computers come with 1 or maybe two UARTS and some come with no serial interface at all
Consider the serial interface, its a 1 to 1 connection with the a UART, need another interface, you need another UART. You can play interrupt games all day long and make them pretend to be com10 ubtil the cows come home, but you can only connect as many devices as you have UARTS.
The Universal Serial Bus solves this problem, but it does it badly. You can build a good size chain of USB devices together by either having a USB hub built onto the MB or by having a USB hub externally. Now I can plug in my thumb drive, my camera, my mouse, joy stick, printer, scanner etc.
Without USB to do the above I need a game port, several serial ports, a parallel port etc.
Th deal is that people want plug-n-play. They don't want to have to deal with 8 port serial cards and the problems with setting up same ( various pretend interrupts, base ports etc.
So I am asking you what you would propose. What type of hardware device would provide the type of functionality that USB provides without the problems?
The USB interface is a primitive network, it lacks a lot of the facilities of a network connection ( I am comparing it to Ethernet) but it basically does the job, many devices can sit on the same 4 wires and all talk to the computer using the ID byte to allow the software interface to differentiate what device is talking and send the data feed to the program that has claimed that device. Additionally it provides power, perhaps not the best idea but it eliminates a lot of bricks plugged into your outlets and keeps the cost of the peripheral down. Those power systems are not as good as they could be, but hey show me a consumer level device that is not running right up to the edge of the on board PS's limits.
I am all for junking USB but we need something better that provides the same type of utility, so please give the world your ideas, if they work I am sure that they will be given serious consideration.>/p>
I'm still not sure I fully get the malicious code issue, as the iPhone is essentially a dumbed down Macbook with a harder-to-use keyboard. How is the iPhone any more dangerous?
I have mod points right now, but sadly. there is no mod indicator for clueless!
If you really think this is just a dumbed down MacBook, then the mod indicator wold be totally appropriate. The iPhone is one complicated bit of tech. There are so many timing issues, security issues, cpu hog issues, so many things to be taken into account. Further, I really doubt that there is any sort of firewall in effect at the phone & radio interface level to the towers or to the AT&T network that keeps this thing running. The SDK will have to be bullet proof to keep hackers from fragging the phone network. As to just giving away digital signauters, I would not hold my breath since I am pretty sure they want to know exactly who and where you are since that digital signature will let an app do many many things.
I can just see some script-kiddie thinking just how fun it would be to take down 1 or more entire cells for nothing more then bragging rights and a laugh. As to actual malicious hackers, the possibilities are endless for their type evilness, imagine a million zombied iPhone's getting a command that just sends the entire AT&T cell network into the dumber, or that start sending spam, or that start...
And you wonder why apple is keeping all this stuff close to the vest and making double damn sure that the things that need to be cut-off from 3rd party developers, are really cut-off. Imagine what the fear level at AT&T does when they start contemplating the consequences of a bit of zombie code hitting a million iPhoens.
And none of the possible pithy replies like, "Well they should have done X" are gonna get any traction when the cell network is crashing around their ears, it would cost them billions if this happened. The iPhone is NOT a MacBook, it is a communications device that has some great apps built in. If I were Steve jobs I would have software that literally "bricks" ANY iPhone, permanently and forever by actually burning out key circuits that had a non-signed bit of software on it. The liability for Apple & AT&T is beyond huge, it could very well be a company killer if the shit got deep.
I would agree (tacitly) that using XML as an import/export format might be good. The problem becomes XML in and of itself. XML was designed to be able to add/remove/modify elements at will and because its an English-like format it is relatively easy to do so.
The bigger issue is e-mail itself with the never ending parade of tags that are being popped in there, which would make for a moving target for even XML to deal with, not to mention the mail client.
Before I went with what you suggest, and it is a good suggestion, I would go back and clean the entire e-mail specification up. It was designed in the days before spam, mail bombing, etc. etc. etc. and it has far to many very vague points in it that will resist being able to be categorized.
There is one part that is gonna kick your ass, and that is the ocean.
Waves are going to be the tricky part, since unlike tree's and other obstructions they are constantly in motion and vary in both size and intensity on an almost random basis. These will be the problem since knowing when you can tack, safely, and not end up stuck in the trough and rolled or worse yet, pitch polled by your computer trying to sail up the face of a wave will be your greatest challenge.
As others have said, your basic hull design is going to make a lot of difference. A mono-hull will be the rule, I think, and one with enough keel to right itself. I would avoid cats or tri's and outriggers of any type, since they tend to cartwheel and once upside down its pretty much game over.
I would also go with sails modified with some drainage to help your righting arm coming back from a knock down, since you really wont be able to let go of the jib or main to facilitate same.
Your rigging is going to have to snarl free as well. I suggest a roller main to allow you to reef based on conditions and a roller jib in case you get into a blow and need to just roll it up and sail with only a reefed main.
There is a LOT of stuff that needs to be taken into account, best of luck.
Now admittedly I am not a Java Programmer, I am however a programmer, and as I understood Java's ENTIRE purpose in life it was to be a "Build it once, run it everywhere a JVM existed" environment where no platform dependencies existed.
There was no porting of your applications, there was simply copy it over there and it just ran. Things like SWING, AWT or whatever they call the framework this week, made sure that a java call for say an "About Box" was translated the the native UI engine for whatever platform it was running on. The programmer didn't have to even think about it, just call it.
So WHY does anything written in Java have to be "Ported"? It is because, at least in my opinion, Java has failed miserably at the most promising goal it aspired to.
Most Java apps are reasonably well behaved, the performance of most, well the best that can be said is that it is adequate but they just gulp resources like no tomorrow.
One day I will re-visit Java and see if it is any closer to its vaunted goal, but for today, it is at best "OK" for doing non GUI server side stuff, but for real GUI applications where the user experience really sells the application, I will stick with other tools that truly understand the notion for X-Platform.
You just incremented the pointer by sizeof(Integer), which was in those days a signed 16 bit number and the pointers were 16 bit as well unless they were FAR pointers, then decremented the same pointer back to pointing to its original memory location.
I know the great unwashed just loves to cap on pascal, but you are simply incorrect. I learned C at the same time I was learning pascal. I though C was a bit more elegant in some ways, but not any more powerful. Not only that, it was very easy to tell that in C you could do some pretty stupid things, inadvertently and very easily and trash the whole shooting match if you were not extremely careful.
I understand what you are saying; however, by changing a pointer to an object, especially one that is created by a constructor, is just BAD programming and is a mistake I would expect from someone who has never programmed in a language with pointers, or just someone tinkering around and doing silly things.
NO language is fool proof when people do stupid things.
Languages have rules and failure to follow said rules is neither the fault of the language, the language designer, the compiler or anything else, its the fault of the programmer.
Now then, having said that, their have been instances when I have PURPOSEFULLY changed a pointer to an object, but not before making sure that I either moved the contents of memory around, or saved off the original value of the pointer so I could restore it. Now even doing it that way is fraught with peril because you can never be quite sure if you caught everything.
Pascal can save you from yourself in most instances, but there are instances where it just can't, like when you don't obey the rules. But the nice part is that you can break the rules, but do so at your own peril and make double damn sure you know what you are doing.
It reminds me a lot of the DOS days when we were writing code that addressed video memory directly, doing things like diving deep into the video card and turning off refresh to avoid the snow that came from that or Delving into the PSP to extend the size of the file table when DOS was limiting you to 20 open files max. We also did things like go around the file system and read and WRITE sectors on the hard drive. ALL these things broke the rules, but we were careful to understand ALL the rules before we started breaking them.
Pointers, inline coding and inline assembler are features you expect from a "robust language"? Well, as long as you don't need robust applications I suppose.
Well I will take this as potential flame bait, but what the heck. There are MANY robust applications written in Pascal. One of the very robust applications that comes to mind was Quatro Pro, Written completely in Object Pascal. It was eating Lotus 123's & Excel's lunch in the spreadsheet race before the infamous "Look and Feel" lawsuit of that pecker head Jim Manzi, which Borland eventually won, but only after being bled for cash that it almost put the company under.
You might want to lookup OpenTable.com. ALL of their backend software, written in Pascal ( Delphi ), you might also want to look around in a few other places. LOTS of very robust applications out there.
The point is that robust applications can be written in pretty much any language, not just the one you, or I happen to be fanboy's of since its all about the programmers writing the software, not the language. Some language implementations might be faster or slower depending on who wrote the compiler, but thats not really the point, now is it.
Laughing my ass off. Ya know that is one thing I do like about Delphi, the compiler is SO damn fast, it can be used as a syntax checker!
Interestingly enough, even in Delphi you can leave off the VERY last semi-colon just before the end of the procedure declaration.
I have to confess that I MUCH prefer pascals case/switch behavior to that of C. I am always forgetting to BREAK and the damn thing falls through. I guess that is the price I pay for using both languages for different and various projects. C'Est le Vie eh?
//the following two declarations are analogous Procedure FooProc(var X : ineger); Procedure BarProc(X : pIntger); // Where pInteger is defined as Type pInteger : ^Integer;
In both cases the variable passed in must be dereference. In the case of FooProc() the compiler does it for you, in the case of BarProc() you must do so explicitly as:
// defined with a VAR parameter Procedure FooProc(var X : integer); begin X:= X + 1; end // Defined with a pointer to integer parameter Procedure BarProc(X : pInteger ); begin X^:= X^ + 1 ' end; // calling is thus FooProc(i); BarProc(@i); // The @ operator sends the address of the variable being passed. // because i is defined as an integer, the compiler knows the bit size // and arrangement and therefor the dereferencing of i is a known // quantity and it runs just fine.
As you can plainly see they are exactly the same except that in one the compiler does the work for you, and in the other YOU do the details. Bye the bye, this was all tested and compiled under Delphi V5 Enterprise.
Well to each their own. I have programmed in C, C++, ADA, PHP, Java, JavaScript, PSQL, TSQL, JCL, Assembler for x86, 68K, Z80 and still find pascal's verboseness a benefit.
And I really have no idea what version of Delphi you are using, since by the very definition of the Pascal Language itself, VAR parameters are passed as a pointer to the area of the heap or the stack that the VAR(iable) exists in, they can be local of global in scope, but a var parameter MUST be passed. The compiler de-references the pointer in the background so you don't have to deal with pointers, if you don't want to.
Quite possibly you might be thinking of the fact that you can call a function without assigning its result to a variable. This is a convenient feature but in my opinion it makes for sloppy programming, because if you don't need the result, then you should have defined a procedure rather then a function.
As to the lack of a keyword to SET a function result AND exit at the same time, I think that rather has its advantages. Now I am not saying a return keyword like the one defined in "C" does not have its own advantages, but the keyword result has its definite advantages. As they professor in my C classes once said, "Beware of early returns"
Pascal is arguably one of the easiest languages to learn there ever was. It's very verboseness leads to readable code, but don't confuse that with weakness. Modern Pascal implementations like Delphi and Free Pascal are powerful languages.
The basics of pascal are simple:
// A simple function Function FooFunc(X : integer) : integer; begin result:= X + 1; end;
// A simple Procedure Procedure FooProc(var X : integer ); begin X:= X + 1; end;
Note the difference in the way the function and the procedure are declared above. Pascal passes parameters either by reference or by value. Using the var directive in the procedure declaration of x as integer I told the compiler to pass the value in by reference and therefor that value can be changed by the procedure. Note that when declaring the parameter this way I can ONLY pass a variable to it of the same type, or typecast a variable of a similar type. If I do NOT use the var invocation in declaring the parameter I can pass either a variable or a literal as below:
// pass in a literal Y:= FooFunc(1);
// pass in a variable Y:= FooFunc(i);
// Y will contain the value of the operation of the function.
FooProc(i);
// The variable i is now modified by the procedure.
FooProc(1);
// Illegal syntax, a variable MUST be passed to the procedure.
This should give you a basic start, the rest is really easy. Pascal does pointers, Structures, file I/O with either typed or untyped files, Inline Coding, Inline Assembler, pretty much everything you would expect from a robust language.
Now there was another reply concerning the PIC system. I worked with Ultimates ( such hubris! ) version of PIC and DBasic in the late 80's. It was BLAZINGLY fast at reading data, but as others have mentioned writing data was another story.
There is an issue of preallocating your files. In PIC's implementation there was the concept of overflow frames as well. These were to handle the growth of Multivalued fields, which were in fact row based data. Now you have to understand that this was a time when hard disk storage was VERY expensive and nothing was counted in Gigabytes.
But even these days when you are talking about truly HUGE databases running into the Tera bytes of data both the preallocation overflow to be contended with. Now PIC had a pretty fine solution for this, but it waisted disk space. Tera Byte sized hard drives are on their way but I still do not think that the aforementioned problems are going to go away, in fact I think they will be amplified and here is why:
Databases of yesterday, and this new proposal is in fact not new, but its rather an old idea were there before CLOBS and BLOBS. Imagine a situation when you attempt to store a CLOB or BLOB with a row oriented approach. You will either have to have a massive overflow capability or you will have to preallocate your file to such a large extent as to make the technique cost prohibitive as your enormous, yet empty file occupies almost all of the available disk space. Additionally if you anticipated CLOB or BLOB storage estimates are wrong the file(s) will need resizing and reallocation on a fairly regular basis and this is not optimal as doing so requires you to have at least the size of the current data file in empty storage available.
I like the idea, but row oriented storage is not a prevalent design feature in any of the current databases out there, and I think for good reason.
You know, normally I would just let this go by, but in your case I am going to make an exception, so here it goes.
I do not speak authoritatively on matters of which I do not have knowledge.
My parents never had a basement.
I was in the Navy when Star Wars hit the screen for the first time.
As to Submarines, Submarine Warfare, Underwater Acoustics, Theory of Sound Propagation in Water... As the saying goes, "Been there, done that got the t-shirt", and I have more t-shirts then I care to remember.
I do occasionally site references, but in many cases I do not because it tends to lead a conversation into areas in which I am forced to demure, as I am now forced to do so in this case.
As to my star wars reference, it was aimed specifically at someone I think is of an age where they would take it as an encouragement, not an admonishment. Apparently, I was mistaken.
All of what you say is true, but most of the cruise missile launching is for the sub captain to be able to pin another one on his chest. The ones they launch from subs are just a tad bit more expensive then the dry launch flavor.
As to the rest, well you can do your own research.
I am going to make this really easy for you to understand.
My next door neighbor, could GIVE A FUCK LESS about the guts of Linux, Windows, Plan9, Unix, Zenix or ANY OTHER operating system you want to mention.
What they do, in point of fact, GIVE A FUCK ABOUT, is can they right a letter and print it. Can they write a spreadsheet and print it, or e-mail it. Can they use it to estimate a job, with a given bit of software.
Does that help you understand my point?
And oh by the way, I am done replying to you. Ta Ta
You obviously know nothing about submarine warfare. A modern United States Nuclear Attack Submarine is for all intents and purposes un-detectable by a surface combatant, of any type. As someone who knows, be advised there are only really two types of combatant vessels, Submarines and targets.
An aircraft carriers ONLY purpose is to launch, and hopefully recover, its air wing to attack the enemy. Post launch they are considered expendable.
A deployed SSN requires no support system. Its sole purpose is to attack enemy submarines and surface vessels. Submarines run with surface combatant groups to protect the Bird Farm first and any other vessels second.
If you are a surface ship and a modern Nuclear Powered SSN decides you are its target, unless something very drastic goes wrong on the sub you are simply dead.
Slashdot Mirror
So here is the deal. Most computers come with 1 or maybe two UARTS and some come with no serial interface at all
Consider the serial interface, its a 1 to 1 connection with the a UART, need another interface, you need another UART. You can play interrupt games all day long and make them pretend to be com10 ubtil the cows come home, but you can only connect as many devices as you have UARTS.
The Universal Serial Bus solves this problem, but it does it badly. You can build a good size chain of USB devices together by either having a USB hub built onto the MB or by having a USB hub externally. Now I can plug in my thumb drive, my camera, my mouse, joy stick, printer, scanner etc.
Without USB to do the above I need a game port, several serial ports, a parallel port etc.
Th deal is that people want plug-n-play. They don't want to have to deal with 8 port serial cards and the problems with setting up same ( various pretend interrupts, base ports etc.
So I am asking you what you would propose. What type of hardware device would provide the type of functionality that USB provides without the problems?
The USB interface is a primitive network, it lacks a lot of the facilities of a network connection ( I am comparing it to Ethernet) but it basically does the job, many devices can sit on the same 4 wires and all talk to the computer using the ID byte to allow the software interface to differentiate what device is talking and send the data feed to the program that has claimed that device. Additionally it provides power, perhaps not the best idea but it eliminates a lot of bricks plugged into your outlets and keeps the cost of the peripheral down. Those power systems are not as good as they could be, but hey show me a consumer level device that is not running right up to the edge of the on board PS's limits.
I am all for junking USB but we need something better that provides the same type of utility, so please give the world your ideas, if they work I am sure that they will be given serious consideration.>/p>
I have mod points right now, but sadly. there is no mod indicator for clueless!
If you really think this is just a dumbed down MacBook, then the mod indicator wold be totally appropriate. The iPhone is one complicated bit of tech. There are so many timing issues, security issues, cpu hog issues, so many things to be taken into account. Further, I really doubt that there is any sort of firewall in effect at the phone & radio interface level to the towers or to the AT&T network that keeps this thing running. The SDK will have to be bullet proof to keep hackers from fragging the phone network. As to just giving away digital signauters, I would not hold my breath since I am pretty sure they want to know exactly who and where you are since that digital signature will let an app do many many things.
I can just see some script-kiddie thinking just how fun it would be to take down 1 or more entire cells for nothing more then bragging rights and a laugh. As to actual malicious hackers, the possibilities are endless for their type evilness, imagine a million zombied iPhone's getting a command that just sends the entire AT&T cell network into the dumber, or that start sending spam, or that start...
And you wonder why apple is keeping all this stuff close to the vest and making double damn sure that the things that need to be cut-off from 3rd party developers, are really cut-off. Imagine what the fear level at AT&T does when they start contemplating the consequences of a bit of zombie code hitting a million iPhoens.
And none of the possible pithy replies like, "Well they should have done X" are gonna get any traction when the cell network is crashing around their ears, it would cost them billions if this happened. The iPhone is NOT a MacBook, it is a communications device that has some great apps built in. If I were Steve jobs I would have software that literally "bricks" ANY iPhone, permanently and forever by actually burning out key circuits that had a non-signed bit of software on it. The liability for Apple & AT&T is beyond huge, it could very well be a company killer if the shit got deep.
Was that in a cluster?
I would agree (tacitly) that using XML as an import/export format might be good. The problem becomes XML in and of itself. XML was designed to be able to add/remove/modify elements at will and because its an English-like format it is relatively easy to do so.
The bigger issue is e-mail itself with the never ending parade of tags that are being popped in there, which would make for a moving target for even XML to deal with, not to mention the mail client.
Before I went with what you suggest, and it is a good suggestion, I would go back and clean the entire e-mail specification up. It was designed in the days before spam, mail bombing, etc. etc. etc. and it has far to many very vague points in it that will resist being able to be categorized.
Be prepared to have you e-mail file(s) jump in size by an order of magnitude.
XML'ng is becoming a verb for creating massive bloat.
There is one part that is gonna kick your ass, and that is the ocean.
Waves are going to be the tricky part, since unlike tree's and other obstructions they are constantly in motion and vary in both size and intensity on an almost random basis. These will be the problem since knowing when you can tack, safely, and not end up stuck in the trough and rolled or worse yet, pitch polled by your computer trying to sail up the face of a wave will be your greatest challenge.
As others have said, your basic hull design is going to make a lot of difference. A mono-hull will be the rule, I think, and one with enough keel to right itself. I would avoid cats or tri's and outriggers of any type, since they tend to cartwheel and once upside down its pretty much game over.
I would also go with sails modified with some drainage to help your righting arm coming back from a knock down, since you really wont be able to let go of the jib or main to facilitate same.
Your rigging is going to have to snarl free as well. I suggest a roller main to allow you to reef based on conditions and a roller jib in case you get into a blow and need to just roll it up and sail with only a reefed main.
There is a LOT of stuff that needs to be taken into account, best of luck.
My Fender Hot Rod DeVille' goes to 12!
You know that was really really awful, come on admit it. It was however kinda funny, but it was still REALLY awful. Uhg!
Now admittedly I am not a Java Programmer, I am however a programmer, and as I understood Java's ENTIRE purpose in life it was to be a "Build it once, run it everywhere a JVM existed" environment where no platform dependencies existed.
There was no porting of your applications, there was simply copy it over there and it just ran. Things like SWING, AWT or whatever they call the framework this week, made sure that a java call for say an "About Box" was translated the the native UI engine for whatever platform it was running on. The programmer didn't have to even think about it, just call it.
So WHY does anything written in Java have to be "Ported"? It is because, at least in my opinion, Java has failed miserably at the most promising goal it aspired to.
Most Java apps are reasonably well behaved, the performance of most, well the best that can be said is that it is adequate but they just gulp resources like no tomorrow.
One day I will re-visit Java and see if it is any closer to its vaunted goal, but for today, it is at best "OK" for doing non GUI server side stuff, but for real GUI applications where the user experience really sells the application, I will stick with other tools that truly understand the notion for X-Platform.
Nope, not so. Even in Turbo Pascal back in the dos days you could do the following:
You just incremented the pointer by sizeof(Integer), which was in those days a signed 16 bit number and the pointers were 16 bit as well unless they were FAR pointers, then decremented the same pointer back to pointing to its original memory location.
I know the great unwashed just loves to cap on pascal, but you are simply incorrect. I learned C at the same time I was learning pascal. I though C was a bit more elegant in some ways, but not any more powerful. Not only that, it was very easy to tell that in C you could do some pretty stupid things, inadvertently and very easily and trash the whole shooting match if you were not extremely careful.
I understand what you are saying; however, by changing a pointer to an object, especially one that is created by a constructor, is just BAD programming and is a mistake I would expect from someone who has never programmed in a language with pointers, or just someone tinkering around and doing silly things.
NO language is fool proof when people do stupid things.
Languages have rules and failure to follow said rules is neither the fault of the language, the language designer, the compiler or anything else, its the fault of the programmer.
Now then, having said that, their have been instances when I have PURPOSEFULLY changed a pointer to an object, but not before making sure that I either moved the contents of memory around, or saved off the original value of the pointer so I could restore it. Now even doing it that way is fraught with peril because you can never be quite sure if you caught everything.
Pascal can save you from yourself in most instances, but there are instances where it just can't, like when you don't obey the rules. But the nice part is that you can break the rules, but do so at your own peril and make double damn sure you know what you are doing.
It reminds me a lot of the DOS days when we were writing code that addressed video memory directly, doing things like diving deep into the video card and turning off refresh to avoid the snow that came from that or Delving into the PSP to extend the size of the file table when DOS was limiting you to 20 open files max. We also did things like go around the file system and read and WRITE sectors on the hard drive. ALL these things broke the rules, but we were careful to understand ALL the rules before we started breaking them.
Well I will take this as potential flame bait, but what the heck. There are MANY robust applications written in Pascal. One of the very robust applications that comes to mind was Quatro Pro, Written completely in Object Pascal. It was eating Lotus 123's & Excel's lunch in the spreadsheet race before the infamous "Look and Feel" lawsuit of that pecker head Jim Manzi, which Borland eventually won, but only after being bled for cash that it almost put the company under.
You might want to lookup OpenTable.com. ALL of their backend software, written in Pascal ( Delphi ), you might also want to look around in a few other places. LOTS of very robust applications out there.
The point is that robust applications can be written in pretty much any language, not just the one you, or I happen to be fanboy's of since its all about the programmers writing the software, not the language. Some language implementations might be faster or slower depending on who wrote the compiler, but thats not really the point, now is it.
I hear ya! I STILL use WP 5.1, god it rocks and the macro facility is second to none. Now THAT is a word processor!
Where!? Ohh the horror, the HORROR!!!!!
Laughing my ass off. Ya know that is one thing I do like about Delphi, the compiler is SO damn fast, it can be used as a syntax checker!
Interestingly enough, even in Delphi you can leave off the VERY last semi-colon just before the end of the procedure declaration.
I have to confess that I MUCH prefer pascals case/switch behavior to that of C. I am always forgetting to BREAK and the damn thing falls through. I guess that is the price I pay for using both languages for different and various projects. C'Est le Vie eh?
Sorry I want to give you an example:
In both cases the variable passed in must be dereference. In the case of FooProc() the compiler does it for you, in the case of BarProc() you must do so explicitly as
As you can plainly see they are exactly the same except that in one the compiler does the work for you, and in the other YOU do the details. Bye the bye, this was all tested and compiled under Delphi V5 Enterprise.
Well to each their own. I have programmed in C, C++, ADA, PHP, Java, JavaScript, PSQL, TSQL, JCL, Assembler for x86, 68K, Z80 and still find pascal's verboseness a benefit.
And I really have no idea what version of Delphi you are using, since by the very definition of the Pascal Language itself, VAR parameters are passed as a pointer to the area of the heap or the stack that the VAR(iable) exists in, they can be local of global in scope, but a var parameter MUST be passed. The compiler de-references the pointer in the background so you don't have to deal with pointers, if you don't want to.
Quite possibly you might be thinking of the fact that you can call a function without assigning its result to a variable. This is a convenient feature but in my opinion it makes for sloppy programming, because if you don't need the result, then you should have defined a procedure rather then a function.
As to the lack of a keyword to SET a function result AND exit at the same time, I think that rather has its advantages. Now I am not saying a return keyword like the one defined in "C" does not have its own advantages, but the keyword result has its definite advantages. As they professor in my C classes once said, "Beware of early returns"
Pascal is arguably one of the easiest languages to learn there ever was. It's very verboseness leads to readable code, but don't confuse that with weakness. Modern Pascal implementations like Delphi and Free Pascal are powerful languages.
The basics of pascal are simple:
Note the difference in the way the function and the procedure are declared above. Pascal passes parameters either by reference or by value. Using the var directive in the procedure declaration of x as integer I told the compiler to pass the value in by reference and therefor that value can be changed by the procedure. Note that when declaring the parameter this way I can ONLY pass a variable to it of the same type, or typecast a variable of a similar type. If I do NOT use the var invocation in declaring the parameter I can pass either a variable or a literal as below:
This should give you a basic start, the rest is really easy. Pascal does pointers, Structures, file I/O with either typed or untyped files, Inline Coding, Inline Assembler, pretty much everything you would expect from a robust language.
You actually allow ANY IM technology that you cannot lock down to ONLY the intranet? What are you just asking to me hosed?
Now there was another reply concerning the PIC system. I worked with Ultimates ( such hubris! ) version of PIC and DBasic in the late 80's. It was BLAZINGLY fast at reading data, but as others have mentioned writing data was another story.
There is an issue of preallocating your files. In PIC's implementation there was the concept of overflow frames as well. These were to handle the growth of Multivalued fields, which were in fact row based data. Now you have to understand that this was a time when hard disk storage was VERY expensive and nothing was counted in Gigabytes.
But even these days when you are talking about truly HUGE databases running into the Tera bytes of data both the preallocation overflow to be contended with. Now PIC had a pretty fine solution for this, but it waisted disk space. Tera Byte sized hard drives are on their way but I still do not think that the aforementioned problems are going to go away, in fact I think they will be amplified and here is why:
Databases of yesterday, and this new proposal is in fact not new, but its rather an old idea were there before CLOBS and BLOBS. Imagine a situation when you attempt to store a CLOB or BLOB with a row oriented approach. You will either have to have a massive overflow capability or you will have to preallocate your file to such a large extent as to make the technique cost prohibitive as your enormous, yet empty file occupies almost all of the available disk space. Additionally if you anticipated CLOB or BLOB storage estimates are wrong the file(s) will need resizing and reallocation on a fairly regular basis and this is not optimal as doing so requires you to have at least the size of the current data file in empty storage available.
I like the idea, but row oriented storage is not a prevalent design feature in any of the current databases out there, and I think for good reason.
As an amateur musician of some experience, I can only ass the following:
She is a brilliant musician and is one hell of a hottie!
Lara St. John penned a minor little bit that will help explain this.
You know, normally I would just let this go by, but in your case I am going to make an exception, so here it goes.
I do occasionally site references, but in many cases I do not because it tends to lead a conversation into areas in which I am forced to demure, as I am now forced to do so in this case.
As to my star wars reference, it was aimed specifically at someone I think is of an age where they would take it as an encouragement, not an admonishment. Apparently, I was mistaken.
All of what you say is true, but most of the cruise missile launching is for the sub captain to be able to pin another one on his chest. The ones they launch from subs are just a tad bit more expensive then the dry launch flavor.
As to the rest, well you can do your own research.
Allow me to introduce you to a bit of oceanography. Read and understand.
Go forth my young Padawan Learner and let the force educate you.
Ok...
I am going to make this really easy for you to understand.
My next door neighbor, could GIVE A FUCK LESS about the guts of Linux, Windows, Plan9, Unix, Zenix or ANY OTHER operating system you want to mention.
What they do, in point of fact, GIVE A FUCK ABOUT, is can they right a letter and print it. Can they write a spreadsheet and print it, or e-mail it. Can they use it to estimate a job, with a given bit of software.
Does that help you understand my point?
And oh by the way, I am done replying to you. Ta Ta
You obviously know nothing about submarine warfare. A modern United States Nuclear Attack Submarine is for all intents and purposes un-detectable by a surface combatant, of any type. As someone who knows, be advised there are only really two types of combatant vessels, Submarines and targets.
An aircraft carriers ONLY purpose is to launch, and hopefully recover, its air wing to attack the enemy. Post launch they are considered expendable.
A deployed SSN requires no support system. Its sole purpose is to attack enemy submarines and surface vessels. Submarines run with surface combatant groups to protect the Bird Farm first and any other vessels second.
If you are a surface ship and a modern Nuclear Powered SSN decides you are its target, unless something very drastic goes wrong on the sub you are simply dead.