I know that the established programmer hierarchy would have me burned at the stake for even hinting at it, but I miss my old GOTO statement. Call it sloppy if you like, but a simple one line statement beats the shit out of the acrobatics I often have to do in Java to SIMPLY JUMP OUT OF THIS METHOD/LOOP TO A SINGLE SPECIFIC POINT IN THE PROGRAM.
break;}
break;}
break;} return;}//shit, still doesn't go where I need it to
Now, cue the voices of 1,000 programmers looking for a non-existent "disagree" mod and screaming at the top of their girlie lungs on why GOTO is EVIL, EVIL, EVIL--as they parrot the professors who taught them that.
While I'm not averse to using goto as necessary where available, I do try to avoid it as it is distinctly easy to make unclear code with it. With Java you do have the ability to label (and break/continue) loops, and of course you have exceptions and finally clauses to make various cleanup patterns simple. You also have private methods that are really cheap. All that sort of horrible mess that would lead to the precise thing that you're complaining about should be refactored so that it conveys its exact intention clearly instead of spreading complexity all round the place. If all those good things I just mentioned are not sufficient to handle your specific case, I want to know what's going on. (Or maybe I don't; it sounds really scary-bad!)
Of course, if your real problem is that you're working somewhere with a strict "no break in loops, no return from functions except at end" policy, there's no hope for you. You're doomed by someone in charge who hasn't understood a single thing written about how to analyze programs for the past 30 years.
Really? You're doing it wrong then. Either you should be using a stronger base to the road or you should lay it with a different technology altogether. For example, if you're in an area with significant frost-heave, leaving a good thick layer at the top of the road as untarred gravel makes it much easier to get the surface back to drivable in the spring: just run a grader over it. Cheap and effective. (OK, you have to reduce your speed a bit when driving on that stuff but so what? It's costing you less in taxes to maintain.)
Wow hiding behind anonymous, but spoken like somebody who like me has gone through it. I learned by the market. I thought, "hey I am a geek and can write algos thus I should be able to make money regardless..." HA right... The tech is secondary!
With movies, you're making entertainment. You don't need flash-bang effects to provide entertainment. You do want a good story, told well. (Now, if someone could just persuade the blockbuster-pushers in Hollywood that this was deeply true, we'd be better off overall.)
We've been living with the numbers for the last three years. In other industries I'm sure the cost of cloud computing quickly eclipses the cost of owned computing capacity, but in visual effects and animation production you have to remember one important factor; your computers are idle most of the time.
It's the same in small engineering firms. Most of the time they're physically building their current product, not doing simulations to design the next one. Idle computers are a total waste in such a situation. Yes, they could sell on the spare cycles but that would also require them to have a full time sysadmin, someone spending time on sales of compute time, and so on; the tail would wag the dog. Far better to buy it in when needed. (What's more, I know that at least one of the software vendors in the area knows about this.)
Would a big enterprise have the same requirements? Surely not, but that's no surprise at all. One size won't fit all, and never did. Actually, really big enterprises are more interested in cloud than you might initially guess; they're often organized internally as a collection of smaller sub-enterprises that share some common services. Clouds — quite possibly internal ones, or ones centrally purchased in from outside and then delegated — make lots of sense there too. It's an interesting mix and the same patterns get replicated at many levels.
Is there an security involved in the Amazon cloud?
As much as you want to put in the VM image. If you're not diligent with protecting your nuclear simulation code, it's your fault, not mine or Amazon's.
Granted a big project (a movie) might have gigabytes of texture data but still nothing that can't be uploaded in half a day or so.
I measured this a couple of years ago. At the time, you could ship data to S3 or EC2 at about 10GB/hour provided you're not saturating your own network or doing it at a very busy time. For a truly large amount of data (1TB up) I suppose you'd just FedEx a hard disk...
Does the CEO realizes that he's trading CPU's limitation against bandwidth's limitation ?
Does it matter? Disks are cheaper in many ways than computation, and digitally rendering a movie will use a lot of that. Not having to find a building to hold a large datacenter which you're not using all of the time anyway... that will surely save masses even with all the additional networking.
Large downloads could also be handled by shipping physical disks. Major cloud vendors will do that.
Is it that hard to find a decent textbook that's either in the public domain or sold cheap?
Thanks to the entertainment industry, any textbook that is PD will be close on a century old. Across a huge proportion of human knowledge there's been a lot discovered and worked out in that time; the PD textbooks are of historical interest, but you can't teach from them. (There are very few that are current and PD; it takes a lot of work to write a textbook and authors mostly like to be reasonably compensated.)
Sold off cheap is much more of a sane option, except that it is hard to ensure that a whole class gets the same edition of the same book at that point, which is what you need to keep the teacher from going crazy. (Can you imagine how awful it would be if everyone in a class of 30 was trying to learn from a different book, many of which will have silly errors in or which you'll have never read yourself?) The only way it can work is if the same book is used for a number of years in a row, allowing students from one year to sell it on to the next. Which is what happens now.
You only need one good textbook for each subject, no?
<sarcasm> You only need one company for each kind of product, no? </sarcasm>
It's important to have multiple textbooks because it's important to present multiple points of view on a subject. That in turn is important because there is no guarantee that any single point of view is correct, no matter how authoritative or how many people collaborated on the production of that PoV. People can make mistakes, both on their own and in groups. The other non-financial benefit to having multiple textbooks is that many subjects are so large that putting everything in there just makes it overwhelming. Narrowing to subfields helps.
Of course, the real problem is that textbook publishers have viewed the area as a colossal cash-cow where they could get lots of money out for relatively little outlay on their part. It's a damn shame that it's taken a huge technological shake-up to get even a chance to put a stop to this racket, but that's quite often true of tech changes.
Also, I think that under the default setup you have to be admin to create links.
That'll be to create hard links to directories, which is a Bad Idea everywhere. Symbolic links to directories are fine though, and can be created by ordinary users (with the right tool; Windows doesn't come with anything like 'ln' by default).
So in order to stop the allocator wasting memory by using up more memory than requested, we're supposed to ask for more memory than we need? That seems to be a facepalm moment. Let's move wastage to where we can't measure it, so that we can't see any wastage any more. The bind moggles.
No, but there's a lot of times when you over-allocate deliberately so you can expand into that space. This is the key to making things like string concatenation fast (an exponential growth strategy — multiplying the space requested by a constant factor each time — gives amortized constant time for memory allocation per byte when building up by appending, which is a hugely common operation). This is fine, but since in this situation you have precise control over how much to request as you don't need it all instantly, you can ask for amounts that are likely to be efficiently handled, minimizing the amount of space that has been allocated at the low level but not actually made available to the consumers of that space (i.e., that's the slop). It's a really easy tweak to make once you are aware of the problem, and it will nearly halve the amount of memory that some data structures use. Big Win.
I have 8gb of memory on my main computer. I want firefox to use up as much of it as it can to improve my browsing experience.
No, it shouldn't use any more memory than it needs. Using extra RAM just for giggles is stupid and totally wasteful, especially as the rest of that space could be used for something else. What would that other thing be? I dunno. Maybe an email client, an office suite, an IDE, a photo or video editing suite, or something else. Or even many of them at once. But having to only browse the web because doing anything else is painful... that's just wrong, and it's been wrong for as long as there's been web browsers.
your hands look pretty opaque under normal sunlight, but if you put a torch up against them you can see the glow coming through quite clearly
Is that British English (i.e. "flashlight"), or are you Just That Crazy?
GP might be mad as a loon for all I know, but it is British English (with that interpretation) all the same. Guess the light would also shine through for a bit with the other kind of torch too, but only for the moment or so before the screaming from the burns started.
If there is one crime that we should punish with very long vacations from polite society, it should be theft.
If theft is going to result in "long vacations", so should receiving stolen goods (since it is really "theft by proxy"). After all, it's the fences that enable thieves to dispose of the goods.
What's missing are APIs to get to your content without the clumsy requirement to sync locally first.
You mean like you get from the dropbox website? Like you can do already (with some files publicly available by default and others requiring you to approve their being shared)? Or were you thinking about something more sophisticated like being able to relocate computation to be in close proximity to the data at rest out there on the Cloud? (That sounds easier than it really is; in reality you have to have exactly the right kind of computation to be able to do that.)
What will definitely remain true is that to compute with the data, you'll have to bring the two together somewhere, to transfer to a different device (physical or virtual) you'll have to move the data around, and to see/visualize the data, you'll have to bring it (or samples of it) to where you are. Those are fundamental.
However, iCloud and iOS in general are moving towards a solution that will make a service like DropBox irrelevant. When your applications abstract their files as data objects, and the user does not need to interact with a file system at all, there is need for a file system synchronization service.
I've been hearing this for over 20 years, and it remains largely BS. Oh, at some levels of abstraction it's somewhat true (though it's more that people move to "dataset" rather than "object") but by far the most common level involves files and directories and has done for years. It seems to be an abstraction that people like.
The big problem for iCloud is that the world is heterogenous. Not everyone uses Apple's products, and that's not about to change. Platform-agnostic clients don't have nearly as many problems with the baggage of other systems from the same vendor.
How would we communicate without IP then? Piggy-backing on ICMP?
ICMP is defined to sit on top of IP. Eliminating IP itself would require replacing it with something like the old Coloured Book protocols or IPX/SPX. Indeed, I remember using both of those years ago, and I praise the Great Lord Richie and His Prophets, Cerf and Berners-Lee, that IP has won that particular war. It's almost as great as the fact that ASCII beat EBCDIC...
What they actually recommended is running the GUI on the client.
That makes a whole bunch of sense, and is what you'd do on any (sane) Unix system too. What's more, this will make Windows work much better in a virtualized server environment (e.g., Azure) and that's of interest to a great many people. (Me, not so much. YMMV.) Having a GUI on a server is like having running shoes on a herring.
I thought about that, and you're probably right. But even if it did, the linker might freak out about the lack of type, and/or the absence of argc/argv. And even if the linker was cool enough about it, since he never returns from main(), the program would dump core/crash.
If it's C (not C++) it will probably work though the exit code will be thoroughly arbitrary (with the most likely exit code still being success due to probable propagation from the result of the printf call). It depends on the exact details of the ABI.
Anyone writing such code for real deserves to be forcefully reeducated.
I prefer the theory that well developed code is it's own documentation. (believe this comes from reading a lot from Uncle Bob)
For learning about what the code does? Sure. For learning why? No. That's when you need comments and external documentation. (With code, all other questions tend to be subservient to those two: what is happening and why.)
The best comment I ever saw in code though was simply a reference to an academic paper that described the algorithm used in depth, including all the magic numbers and bits that made you thing "WTF?!". Documentation doesn't usually need to be long, but it does need to be informative.
Crud loads of javadoc/msdn like documents aren't as effective as readable code and a few real world examples.
Neither is a substitute for the other, and good API documentation will include some stripped-down examples. (Not all API docs are good.) Bear in mind that a full real world example is usually bloated up with stuff to deal with other necessary things; great if you're solving that real world problem, but crap for understanding an API's use.
And of course, not everything you need to document is an API. It can be necessary to add docs to the trickier parts of the implementation too.
Slashdot Mirror
[The center of the galaxy is] actually a massive rotating bar
Really? What do they serve at this massive rotating bar? What music do they play? Are there lights? Do they have any sports on TV?
Comparable to the diameter of the black hole I guess which is the event horizon.
It's exactly the event horizon; you definitely can't see anything inside of that limit by any means from outside by its very definition.
I know that the established programmer hierarchy would have me burned at the stake for even hinting at it, but I miss my old GOTO statement. Call it sloppy if you like, but a simple one line statement beats the shit out of the acrobatics I often have to do in Java to SIMPLY JUMP OUT OF THIS METHOD/LOOP TO A SINGLE SPECIFIC POINT IN THE PROGRAM.
break;}
break;}
break;} //shit, still doesn't go where I need it to
return;}
Now, cue the voices of 1,000 programmers looking for a non-existent "disagree" mod and screaming at the top of their girlie lungs on why GOTO is EVIL, EVIL, EVIL--as they parrot the professors who taught them that.
While I'm not averse to using goto as necessary where available, I do try to avoid it as it is distinctly easy to make unclear code with it. With Java you do have the ability to label (and break/continue) loops, and of course you have exceptions and finally clauses to make various cleanup patterns simple. You also have private methods that are really cheap. All that sort of horrible mess that would lead to the precise thing that you're complaining about should be refactored so that it conveys its exact intention clearly instead of spreading complexity all round the place. If all those good things I just mentioned are not sufficient to handle your specific case, I want to know what's going on. (Or maybe I don't; it sounds really scary-bad!)
Of course, if your real problem is that you're working somewhere with a strict "no break in loops, no return from functions except at end" policy, there's no hope for you. You're doomed by someone in charge who hasn't understood a single thing written about how to analyze programs for the past 30 years.
Our Roads get replaced every ~5 years.
Really? You're doing it wrong then. Either you should be using a stronger base to the road or you should lay it with a different technology altogether. For example, if you're in an area with significant frost-heave, leaving a good thick layer at the top of the road as untarred gravel makes it much easier to get the surface back to drivable in the spring: just run a grader over it. Cheap and effective. (OK, you have to reduce your speed a bit when driving on that stuff but so what? It's costing you less in taxes to maintain.)
Wow hiding behind anonymous, but spoken like somebody who like me has gone through it. I learned by the market. I thought, "hey I am a geek and can write algos thus I should be able to make money regardless..." HA right... The tech is secondary!
With movies, you're making entertainment. You don't need flash-bang effects to provide entertainment. You do want a good story, told well. (Now, if someone could just persuade the blockbuster-pushers in Hollywood that this was deeply true, we'd be better off overall.)
We've been living with the numbers for the last three years. In other industries I'm sure the cost of cloud computing quickly eclipses the cost of owned computing capacity, but in visual effects and animation production you have to remember one important factor; your computers are idle most of the time.
It's the same in small engineering firms. Most of the time they're physically building their current product, not doing simulations to design the next one. Idle computers are a total waste in such a situation. Yes, they could sell on the spare cycles but that would also require them to have a full time sysadmin, someone spending time on sales of compute time, and so on; the tail would wag the dog. Far better to buy it in when needed. (What's more, I know that at least one of the software vendors in the area knows about this.)
Would a big enterprise have the same requirements? Surely not, but that's no surprise at all. One size won't fit all, and never did. Actually, really big enterprises are more interested in cloud than you might initially guess; they're often organized internally as a collection of smaller sub-enterprises that share some common services. Clouds — quite possibly internal ones, or ones centrally purchased in from outside and then delegated — make lots of sense there too. It's an interesting mix and the same patterns get replicated at many levels.
Is there an security involved in the Amazon cloud?
As much as you want to put in the VM image. If you're not diligent with protecting your nuclear simulation code, it's your fault, not mine or Amazon's.
Granted a big project (a movie) might have gigabytes of texture data but still nothing that can't be uploaded in half a day or so.
I measured this a couple of years ago. At the time, you could ship data to S3 or EC2 at about 10GB/hour provided you're not saturating your own network or doing it at a very busy time. For a truly large amount of data (1TB up) I suppose you'd just FedEx a hard disk...
Does the CEO realizes that he's trading CPU's limitation against bandwidth's limitation ?
Does it matter? Disks are cheaper in many ways than computation, and digitally rendering a movie will use a lot of that. Not having to find a building to hold a large datacenter which you're not using all of the time anyway... that will surely save masses even with all the additional networking.
Large downloads could also be handled by shipping physical disks. Major cloud vendors will do that.
Is it that hard to find a decent textbook that's either in the public domain or sold cheap?
Thanks to the entertainment industry, any textbook that is PD will be close on a century old. Across a huge proportion of human knowledge there's been a lot discovered and worked out in that time; the PD textbooks are of historical interest, but you can't teach from them. (There are very few that are current and PD; it takes a lot of work to write a textbook and authors mostly like to be reasonably compensated.)
Sold off cheap is much more of a sane option, except that it is hard to ensure that a whole class gets the same edition of the same book at that point, which is what you need to keep the teacher from going crazy. (Can you imagine how awful it would be if everyone in a class of 30 was trying to learn from a different book, many of which will have silly errors in or which you'll have never read yourself?) The only way it can work is if the same book is used for a number of years in a row, allowing students from one year to sell it on to the next. Which is what happens now.
You only need one good textbook for each subject, no?
<sarcasm> You only need one company for each kind of product, no? </sarcasm>
It's important to have multiple textbooks because it's important to present multiple points of view on a subject. That in turn is important because there is no guarantee that any single point of view is correct, no matter how authoritative or how many people collaborated on the production of that PoV. People can make mistakes, both on their own and in groups. The other non-financial benefit to having multiple textbooks is that many subjects are so large that putting everything in there just makes it overwhelming. Narrowing to subfields helps.
Of course, the real problem is that textbook publishers have viewed the area as a colossal cash-cow where they could get lots of money out for relatively little outlay on their part. It's a damn shame that it's taken a huge technological shake-up to get even a chance to put a stop to this racket, but that's quite often true of tech changes.
Size and weight are minor annoyances.
You wait until you've got to haul all that stuff around before you say that again...
Also, I think that under the default setup you have to be admin to create links.
That'll be to create hard links to directories, which is a Bad Idea everywhere. Symbolic links to directories are fine though, and can be created by ordinary users (with the right tool; Windows doesn't come with anything like 'ln' by default).
So in order to stop the allocator wasting memory by using up more memory than requested, we're supposed to ask for more memory than we need? That seems to be a facepalm moment. Let's move wastage to where we can't measure it, so that we can't see any wastage any more. The bind moggles.
No, but there's a lot of times when you over-allocate deliberately so you can expand into that space. This is the key to making things like string concatenation fast (an exponential growth strategy — multiplying the space requested by a constant factor each time — gives amortized constant time for memory allocation per byte when building up by appending, which is a hugely common operation). This is fine, but since in this situation you have precise control over how much to request as you don't need it all instantly, you can ask for amounts that are likely to be efficiently handled, minimizing the amount of space that has been allocated at the low level but not actually made available to the consumers of that space (i.e., that's the slop). It's a really easy tweak to make once you are aware of the problem, and it will nearly halve the amount of memory that some data structures use. Big Win.
I have 8gb of memory on my main computer. I want firefox to use up as much of it as it can to improve my browsing experience.
No, it shouldn't use any more memory than it needs. Using extra RAM just for giggles is stupid and totally wasteful, especially as the rest of that space could be used for something else. What would that other thing be? I dunno. Maybe an email client, an office suite, an IDE, a photo or video editing suite, or something else. Or even many of them at once. But having to only browse the web because doing anything else is painful... that's just wrong, and it's been wrong for as long as there's been web browsers.
your hands look pretty opaque under normal sunlight, but if you put a torch up against them you can see the glow coming through quite clearly
Is that British English (i.e. "flashlight"), or are you Just That Crazy?
GP might be mad as a loon for all I know, but it is British English (with that interpretation) all the same. Guess the light would also shine through for a bit with the other kind of torch too, but only for the moment or so before the screaming from the burns started.
If there is one crime that we should punish with very long vacations from polite society, it should be theft.
If theft is going to result in "long vacations", so should receiving stolen goods (since it is really "theft by proxy"). After all, it's the fences that enable thieves to dispose of the goods.
What's missing are APIs to get to your content without the clumsy requirement to sync locally first.
You mean like you get from the dropbox website? Like you can do already (with some files publicly available by default and others requiring you to approve their being shared)? Or were you thinking about something more sophisticated like being able to relocate computation to be in close proximity to the data at rest out there on the Cloud? (That sounds easier than it really is; in reality you have to have exactly the right kind of computation to be able to do that.)
What will definitely remain true is that to compute with the data, you'll have to bring the two together somewhere, to transfer to a different device (physical or virtual) you'll have to move the data around, and to see/visualize the data, you'll have to bring it (or samples of it) to where you are. Those are fundamental.
However, iCloud and iOS in general are moving towards a solution that will make a service like DropBox irrelevant. When your applications abstract their files as data objects, and the user does not need to interact with a file system at all, there is need for a file system synchronization service.
I've been hearing this for over 20 years, and it remains largely BS. Oh, at some levels of abstraction it's somewhat true (though it's more that people move to "dataset" rather than "object") but by far the most common level involves files and directories and has done for years. It seems to be an abstraction that people like.
The big problem for iCloud is that the world is heterogenous. Not everyone uses Apple's products, and that's not about to change. Platform-agnostic clients don't have nearly as many problems with the baggage of other systems from the same vendor.
How would we communicate without IP then? Piggy-backing on ICMP?
ICMP is defined to sit on top of IP. Eliminating IP itself would require replacing it with something like the old Coloured Book protocols or IPX/SPX. Indeed, I remember using both of those years ago, and I praise the Great Lord Richie and His Prophets, Cerf and Berners-Lee, that IP has won that particular war. It's almost as great as the fact that ASCII beat EBCDIC...
What they actually recommended is running the GUI on the client.
That makes a whole bunch of sense, and is what you'd do on any (sane) Unix system too. What's more, this will make Windows work much better in a virtualized server environment (e.g., Azure) and that's of interest to a great many people. (Me, not so much. YMMV.) Having a GUI on a server is like having running shoes on a herring.
I thought about that, and you're probably right. But even if it did, the linker might freak out about the lack of type, and/or the absence of argc/argv. And even if the linker was cool enough about it, since he never returns from main(), the program would dump core/crash.
If it's C (not C++) it will probably work though the exit code will be thoroughly arbitrary (with the most likely exit code still being success due to probable propagation from the result of the printf call). It depends on the exact details of the ABI.
Anyone writing such code for real deserves to be forcefully reeducated.
I've worked with plenty of people who had 5+ years of "experience" who perform at the competency level of a 1st year coder.
Ah, people who have had 6 months of experience over and over again.
I prefer the theory that well developed code is it's own documentation. (believe this comes from reading a lot from Uncle Bob)
For learning about what the code does? Sure. For learning why? No. That's when you need comments and external documentation. (With code, all other questions tend to be subservient to those two: what is happening and why.)
The best comment I ever saw in code though was simply a reference to an academic paper that described the algorithm used in depth, including all the magic numbers and bits that made you thing "WTF?!". Documentation doesn't usually need to be long, but it does need to be informative.
Crud loads of javadoc/msdn like documents aren't as effective as readable code and a few real world examples.
Neither is a substitute for the other, and good API documentation will include some stripped-down examples. (Not all API docs are good.) Bear in mind that a full real world example is usually bloated up with stuff to deal with other necessary things; great if you're solving that real world problem, but crap for understanding an API's use.
And of course, not everything you need to document is an API. It can be necessary to add docs to the trickier parts of the implementation too.
Get back to us when you kill an IBM Model M keyboard. It's like the Tonka Truck of keyboards. You hit someone with a Model M, they're going down.
It's a great melee weapon for use against zombies. I believe you can type on it too.