TeX (and more specifically LaTeX), are far more widely used in the mathematical community than MS Word. Most math departments expect or require you to use LaTeX to write your thesis, and possibly even your homework.
The math community is so deeply invested in TeX and it's associated tools that nobody would bother to switch to MS Word unless it somehow provided a capability that TeX or LaTeX can't, and that is very unlikely.
IBM acquires lots of new workers all the time as part of outsourcing deals. A company decides to use IBM for its IT and/or software development, and (if they're nice) transition their existing employees over to IBM. IBM accepts this as part of the deal, but they have to get rid of some people eventually and because attrition alone isn't enough they periodically lay people off.
It isn't necessarily pretty, but it's essentially part of their current business model.
Hiding local declarations in a nested scope is essentially encapsulation. Encapsulation is usually viewed as a GOOD THING among most programmers.
Encapsulation is a good thing, but remember that Pascal is a procedural language designed for structured programming, not object oriented programming. Pascal has certainly been updated to things like the Modula language family and stuff like Object Pascal (Delphi), but in standard run of the mill Pascal those features just weren't there. Pascal didn't even start out with modules; those came when Wirth designed Modula-2.
Now, I haven't worked much with Pascal, given that I'm probably much younger than you. But I have worked a lot with SML, and in SML nested functions are invaluable. In short, you can't get much work done without them, at least if you value somewhat clean and reusable code. Now, of course, you don't put big complicated things nesting inside each other there either, there's a module system to do that kind of encapsulation, but if you need one or two small helper functions inside a function body, local and let are your friends!
Aha! I think I see where our disconnect is. SML is a functional programming language, not an imperative language like Pascal, C, and Java. These are two different language families, and operate in qualitatively different ways. In a functional programming language, the ability to declare a function anywhere is essential, whereas in an imperative language the ability to do so is simply a feature.
I have a hard time understanding your assertion that using nested functions as intended leads to maintenance nightmare. My experience is exactly the opposite. Failing to use nested functions lead to uglier code, putting huge declarations inside a function is not what's intended (use the module system for that), and lifting stuff out, and adding a paramater is usually easy. But then again, our perspectives might differ.
Check out this response that I wrote to another post. I'd just give you the same example of how maintenance problems happen. Basically, it just gets messy, and nesting your functions and procedures just makes it a more complicated mess to sort out. In my experience, things turn to spaghetti code during the maintenance phase, so as a general rule I think that anything you can do that simplifies maintenance is probably worth it. To me, having all your procedures and functions at the same scope level makes maintenance much easier, and all other things being equal, it's the trade-off that I would make.
While I agree that nested functions were mostly of academic interest, and that that was probably an important reason why they were left out of C, I still disagree with the notion that nested functions are somehow more complicated.
I've never claimed that they are complicated. I've never claimed that they were hard. They do add complexity for essentially no benefit, so I do think they are an unnecessary complication. There is a clear difference between those that I hope you can see
As a programmer, I'm pretty used to recursion, so a function inside a function inside a function is pretty easy to handle, thank you!
Oh, you're a programmer...
Big deal, so am I. In fact I've been one long enough that I've used Pascal in a professional setting, so save your lame appeals to authority. Again, I've never said it was hard to understand.
You complain that nesting "made it difficult to share values between functions", which is completely ridiculous. Nesting made that sharing possible, and the removal of nesting from e.g. C instead forced you to use hacks, such as passing struct-pointers around.
Sure, when you wrote a program you never had to touch again (like your computer science homework), nested functions and procedures work just fine. However, they become a burden when you try to refactor things. As far as I'm concerned, making it easy to go in and change things is what good design is all about. If you never need to go back and change anything, it doesn't matter how you wrote it. You could write all your code in a giant chunk and it would make no difference.
To you're point about sharing values between functions and procedures, nesting your functions and procedures only makes bad practices simple. To share values, you either pass them as parameters (preferred), or you have them high enough in the scope hierarchy that all the functions/procedures that need it can see it (*not* preferred). If you're passing values as parameters all that matters is that the functions/procedures can see the each other, which is made simpler by having everything at the same scope level. If you are passing information around using variables inside nested scopes, all you are doing is using semi-global variables instead of actual global variables. You still have all the problems that come along with using variables that aren't local to a specific block of code, only now it's worse because you have more than one "global" scope that you have to concern yourself with. Once again, more complexity without benefit.
While I'm sure you're right about the possibility of abusing nesting (any programming feature can be abused), that doesn't make it a bad feature per se. And neither does the fact that C doesn't have it, make it a bad feature either. More to the point, most good programming language features ever invented, aren't in C!
You're correct, you can abuse any language feature. The difference here is, is wasn't abusing the feature, it was an unfortunate side effect of using the feature as intended
Oh, and I fail to see what makes lambdas so different from nested functions. The only difference I can see, is that languages with lambdas are usually garbage collected, so that passing pointers to nested functions around is safer. But other than that, failing to give nested functions a name (in the local scope) is merely a matter of syntax, not of semantics.
On this, I think you're probably technically right. They're intended to be used as little one line, convenience functions, but intent doesn't prevent it from being used in other ways. You could certainly abuse lambdas to write much longer functions and call them the same thing as Pascal's nested functions and procedures.
I'm having a little trouble following what you wrote. Could you give an example to clarify? I'm just curious if what you're talking about applies to Delphi (Object Pascal). I think I know what you mean, but I'm not really seeing the difference between having to pass values into nested functions versus passing them into non-nested ones. The only thing nesting gets you is the aforementioned "privacy" of the nested function to it's containing function.
The real problem occurs when you need to go back later and make changes. You end up with things that can't see each other that now suddenly need to call each other and pass data. Consider this example:
You get specs for several different types of reports from the business people. The specs are very clear, very straightforward. You implement all of these reports using one main procedure for each report with nested procedures and functions inside that main report procedure. Your code is as clear as it can be, you get the results you expect, they love reports, and you're a hero.
Later on, they want some modifications to a report. It's a reasonable request; they'd just like to have a section from report A show up as a subsection in report B. At this point you could could just copy and paste all the code that generates that section from report A into report B, but this kind of code duplication is almost always a bad idea. You're only other choice at this point is to move the function or procedure you need up high enough in the scope hierarchy so that both reports can see it. Depending on how much nesting you did in the original reports, this could be pretty painful, since suddenly variables and functions and procedures that you expected to be in scope before aren't any longer, and now you have to pass them all as parameters, and... You get the idea. It just gets messy.
If you had a code base that needed frequent modifications to allow new or different functionality, what little benefit there was to using nested functions are procedures is gone, and now it's just making your life miserable. You would've been better off if you just had all your functions and procedures at the same scope level from the start. This is essentially the scoping model modern languages use for functions and procedures.
The big problem I have with nested functions is that yet again they make the code difficult to understand with the eyeballs. Worse yet, you have to define the function between the declaration of the outer function and the body of it. So you get this:
This is a very good point. It gets difficult to tell just by looking at the code what level something was nested at, and where it could be called from.
The problem with nested functions (as in Pascal's scoping) is that in many situations it made it difficult to share values between functions or procedures
Uh? Say again? What was the problem? Nested functions solve this problem. If the variable isn't local, it's in the containing lexical scope. This simplifies sharing of values.
Try refactoring a large pascal code base that makes heavy use of nested functions and procedures. When you start needing to pass values to a function or procedure in a way that wasn't originally envisioned, you have 3 choices:
1) Start rewriting everything. (bad choice)
2) Start bubbling variables up in scope to the point they are visible to both functions/procedures. (bad choice)
3) Move all of the functions/procedures to the same scope so they can all see each other. (less bad than the other choices).
One way to solve that problem is to push variables up in scope, which leads to all the familiar problems with global variables.
I'm not sure what you are suggesting here, but it sounds like a bad idea. Just use lexical scoping, like Pascal does.
I'm suggesting that pushing variables up in scope is an option. A bad option, but it is, in fact, and option. It sounds like a bad idea because it is a bad idea. I wouldn't recommend it, and in fact I didn't recommend it. I was mostly using it to set up the second option, which I clearly marked as better.
The better option was to not nest your functions and procedures in the first place, so newer languages stopped supported that feature.
C had two goals: (1) to be almost as useful as assembly language for systems programming (2) writing a C compiler should be easy. Lexical scoping of nested functions is missing from C because it made the compiler more complicated, not for any esoteric philosophical reasons like you suggest.
Err... what "esoteric philosophical reasons" did I suggest? That the feature wasn't worth supporting so it was left out? Nested scopes, such as Pascal's, were the result of academic research into computer science, and from an academic, theoretical point of view they make a great deal of sense. However the benefits of nested scopes didn't translate that well outside of academia.
To your point though, if K & R had thought nested scopes were valuable enough to include, they would of. Supporting nested scopes does make managing your symbol table more difficult, but not so much more so that they would not have included it if they thought it had value. Clearly, they didn't think it had enough value.
Most notably, C didn't include it, and as a result it drastically simplified scoping rules to more or less what we're accustomed to now.
Well, if you are so retarded that you find nesting of variable-names within functions hard, I can understand why you prefer a system with only two levels of variable-names, local and global.
Right... I disagree with you, therefore I must be a retard. Nice critical thinking skills there...
I don't find the scoping rules for nested functions and procedures hard, I think they are unnecessary. The reason I prefer scoping rules such as C's and Java's is because they are what ended up getting used anyway. If I were to start writing programs in Pascal or Delphi again, I wouldn't use nested functions or procedures because they add too much complexity without providing enough benefit. I have no use for byzantine structures when simple ones suffice.
On the other hand, just about any other modern language includes some form of nesting of scopes, in a way that's harder to understand than Pascals nesting of functions.
To be able to create a function that could only be called from a certian other function.
Pascal had nested functions, which IIRC made them private to all accept their outer function. It would be nice if its successors (in popularity, not lineage) had that. If classes can be nested in C++ and Java, why not functions? It has utility even without closure support.
The problem with nested functions (as in Pascal's scoping) is that in many situations it made it difficult to share values between functions or procedures, (Pascal makes a distinction between those). One way to solve that problem is to push variables up in scope, which leads to all the familiar problems with global variables. The better option was to not nest your functions and procedures in the first place, so newer languages stopped supported that feature. Most notably, C didn't include it, and as a result it drastically simplified scoping rules to more or less what we're accustomed to now.
Apple has been doing this sort of thing with QuickTime for a while now. I only have QuickTime installed on Windows, and every time it has an update for QuickTime it wants me to download QuickTime+iTunes. It's annoying, but you can unclick the box, and I think there is an option to tell it to ignore that update in the future.
Nobody has mentioned it yet, but I wonder what the chances of Microsoft using some of the technology developed by Lionhead in other products, such as Windows or Office. Gesture technology has already been used in some other (non-MS) apps without a tremendous impact, but what if they took the trainable AI technology from Black & White and integrated it into their products so that you could have an assistant that actually learned how you use your computer, as opposed to something like the infamous Clippy that responds the essentially same way every time. I'm sure there's a market for that kind of thing out there.
It should also be noted that the distinction between meteors and meteorites is one of particle size, not composition, and since this is 3rd grade science it should be added that meteors are the smaller of the two.
That's not true. The distinction between a meteor and a meteorite is that meteors do not fall all the way to the ground, and meteorites do.
Since the comet takes 150 years to complete an orbit, it would also seem to follow that there must be less debris in successive years until the comet sweeps by again, so you've missed all the really good showers until 2126 anyway.
This also isn't true. Stuff continues to move out there, so we don't pass through the exact same spot in the debris trail every year. How big the meteor shower is varies from year to year.
I'll let somebody else point out that the orbit is 133 years, not 150.
I think you're missing the point. The backplane of the Cat6500 is pretty much what the PCI bus does for a PC. A 32bit/33mhz PCI bus gives you just about 1 Gbps while the Cat6500 backplane provides three buses of 256, 32 and 4 Gbps (not 720 GBps as the GP suggested - the "Sup720" refers to the 720 Mpps switching capacity). Switching to PCIE gives you 2.5 Gbps per lane, but how many motherboards provide the 100 PCIE lanes needed to compete?
I don't think I was entirely missing the point, but maybe I could have gone a little further in explaining myself. My poorly explained suggestion was that you can avoid the PCI bus entirely, thereby avoiding the bottleneck. When you have multiple cards installed in a single box you could just connect them together using some kind of high speed interconnect that goes directly between cards instead of using the system bus. That way you can have your high speed backplane to handle network switching/routing.
That said, I understand that this is a bit silly and completely misses the point of using a PC as a router instead of something designed to do the job, but it would hardly be the first time such a product came out of the tech industry. If somebody thinks there's a market for it, it will be built.
ASICs offload the hard work from the CPU of the Cisco systems. Basically any kind of compute-intensive bulk work, switching (yes, it switches layer 3 too), filtering (access-lists) and so on, is handled by dedicated ASICs and require little or no CPU intervention. This enables the catalyst to handle high amounts of data with a quite small CPU. Things that do end up on the CPU is management work, route computation (BGP changes, for example) and logging. To handle 720 million packets per second, you'd need quite a lot of CPU in your PC.
Is there any reason why you couldn't accomplish this using something besides an ASIC? Offloading the work to the card is what I suggested before, and if you want to switching or routing with any kind of low latency, you have to do that. If you used that strategy, the speed of the processor in the PC wouldn't matter any more than the speed of the processor in a Cisco. Again, it may defeat the point of using a PC for routing, but that doesn't mean nobody would build it if there was a market.
I think we're in total agreement that the high end of what Cisco does is not the target market. My biggest point that I was trying to make with my post was that there was no reason you couldn't stick a high speed backplane into a PC. It's just a matter of creativty and some engineering. Whether or not it makes sense is a whole different question.
You may commence flaming the Cisco fanboy now.
Can't see why I would do that. You managed to express a different point of view without a) going apopletic, b)insisting I'm an idiot for not sharing your view, and c) not insulting me and/or my lineage. If anything, your behavior should be applauded. I can see how you would expect different treatment on/. though.
...and you now have a 720 GBps back plane. No PC could ever hope to do that.
That's not quite true. There's no reason I can think of why you couldn't make a backplane for a PC that handles all the network traffic locally, without touching the PCI bus (or whatever bus). In fact, high speed interconnects used on clusters do that sort of thing already, and I suspect any high speed backplane for any platform would need to do the same. I'm not intimately familiar with ASICs, but if they add this type of functionality regardless of the clockspeed on the core chip, they probably handle all the traffic locally too.
A backplane like that may not exist for a PC currently, but if their PC router is successful enough to get companies using it, somebody will create one. Engineering a high speed backplane for arbitrary hardware is a problem that has already been solved, all that's needed now is a market with enough demand to make it worthwhile to build.
I love open source and all, but can a project like this really offer the same number of WIC modules?
I'm not sure they really need to provide all the modules that Cisco does. The majority of people only use a small subset of all the modules Cisco provides, and as long as that subset can be brought to the PC platform, (if they don't already exist in some form), then there will be a large market for Vyatta's product.
I'm sorry if you find that offensive, but it was abundantly clear that you misunderstood the original post. Not only did you misunderstand it, but you then proceeded to say more or less the exact same thing as the original post. I can only assume that anybody who didn't see that, didn't really read one, or both, posts.
Not to discount what you're saying, but did you really read what packeteer wrote?
packeteer wrote: Sexual assualt is not ok but mark this one up as being younge and stupid. If a 19 year old takes you to dinner and a movie and you agree to go back to his place certain things are expected of you. This does not mean that what the boy did was acceptable but anyone slightly mature would realize what they are giving the impression they are going to do by going to his house.
Just by reading the two sentences around the one you quoted makes it perfectly clear what was meant, and that it's not at all trying to justify what the 19 year-old did, nor saying in anyway that this is acceptable behavior.
I can only assume that whoever moderated your comment up didn't really read what you responded to either. If they had, they surely wouldn't have labelled this as insightful.
My suggestion is to encourage them to start writing something, anything about their topic. It doesn't have to be good, it doesn't have to be well formed, is doesn't even need to be coherent, they just need to get ideas out so they can start making something out of it. Too many people can't start writing in the first place because they expect fully formed perfection to come out.
If they're all engineering type students, you could easily link it to one of the most important concepts in many engineering fields: Get a solution first, then refine it. They probably understand and accept this idea without question as engineers, you just have to show them it applies to writing as well.
With a litte thought, I'm sure you could find many more parallels between writing and engineering that you could use for teaching.
I agree that the chances of it being in the ecliptic are pretty slim, but it's really the only place we would be likely to find it. The only way this was found was because of it's interaction with other objects. If it wasn't in the ecliptic, it would not have much to interact with.
Slashdot Mirror
All you need to do is arm that glider, and it is an autonomous long range torpedo.
TeX (and more specifically LaTeX), are far more widely used in the mathematical community than MS Word. Most math departments expect or require you to use LaTeX to write your thesis, and possibly even your homework.
The math community is so deeply invested in TeX and it's associated tools that nobody would bother to switch to MS Word unless it somehow provided a capability that TeX or LaTeX can't, and that is very unlikely.
IBM acquires lots of new workers all the time as part of outsourcing deals. A company decides to use IBM for its IT and/or software development, and (if they're nice) transition their existing employees over to IBM. IBM accepts this as part of the deal, but they have to get rid of some people eventually and because attrition alone isn't enough they periodically lay people off.
It isn't necessarily pretty, but it's essentially part of their current business model.
Hiding local declarations in a nested scope is essentially encapsulation. Encapsulation is usually viewed as a GOOD THING among most programmers.
Encapsulation is a good thing, but remember that Pascal is a procedural language designed for structured programming, not object oriented programming. Pascal has certainly been updated to things like the Modula language family and stuff like Object Pascal (Delphi), but in standard run of the mill Pascal those features just weren't there. Pascal didn't even start out with modules; those came when Wirth designed Modula-2.
Now, I haven't worked much with Pascal, given that I'm probably much younger than you. But I have worked a lot with SML, and in SML nested functions are invaluable. In short, you can't get much work done without them, at least if you value somewhat clean and reusable code. Now, of course, you don't put big complicated things nesting inside each other there either, there's a module system to do that kind of encapsulation, but if you need one or two small helper functions inside a function body, local and let are your friends!
Aha! I think I see where our disconnect is. SML is a functional programming language, not an imperative language like Pascal, C, and Java. These are two different language families, and operate in qualitatively different ways. In a functional programming language, the ability to declare a function anywhere is essential, whereas in an imperative language the ability to do so is simply a feature.
I have a hard time understanding your assertion that using nested functions as intended leads to maintenance nightmare. My experience is exactly the opposite. Failing to use nested functions lead to uglier code, putting huge declarations inside a function is not what's intended (use the module system for that), and lifting stuff out, and adding a paramater is usually easy. But then again, our perspectives might differ.
Check out this response that I wrote to another post. I'd just give you the same example of how maintenance problems happen. Basically, it just gets messy, and nesting your functions and procedures just makes it a more complicated mess to sort out. In my experience, things turn to spaghetti code during the maintenance phase, so as a general rule I think that anything you can do that simplifies maintenance is probably worth it. To me, having all your procedures and functions at the same scope level makes maintenance much easier, and all other things being equal, it's the trade-off that I would make.
As a programmer, I'm pretty used to recursion, so a function inside a function inside a function is pretty easy to handle, thank you!
A function inside a function inside a function isn't recursion, it's just a nested function inside a nested function. Perhaps you should review?
While I agree that nested functions were mostly of academic interest, and that that was probably an important reason why they were left out of C, I still disagree with the notion that nested functions are somehow more complicated.
I've never claimed that they are complicated. I've never claimed that they were hard. They do add complexity for essentially no benefit, so I do think they are an unnecessary complication. There is a clear difference between those that I hope you can see
As a programmer, I'm pretty used to recursion, so a function inside a function inside a function is pretty easy to handle, thank you!Oh, you're a programmer...
Big deal, so am I. In fact I've been one long enough that I've used Pascal in a professional setting, so save your lame appeals to authority. Again, I've never said it was hard to understand.
You complain that nesting "made it difficult to share values between functions", which is completely ridiculous. Nesting made that sharing possible, and the removal of nesting from e.g. C instead forced you to use hacks, such as passing struct-pointers around.
Sure, when you wrote a program you never had to touch again (like your computer science homework), nested functions and procedures work just fine. However, they become a burden when you try to refactor things. As far as I'm concerned, making it easy to go in and change things is what good design is all about. If you never need to go back and change anything, it doesn't matter how you wrote it. You could write all your code in a giant chunk and it would make no difference.
To you're point about sharing values between functions and procedures, nesting your functions and procedures only makes bad practices simple. To share values, you either pass them as parameters (preferred), or you have them high enough in the scope hierarchy that all the functions/procedures that need it can see it (*not* preferred). If you're passing values as parameters all that matters is that the functions/procedures can see the each other, which is made simpler by having everything at the same scope level. If you are passing information around using variables inside nested scopes, all you are doing is using semi-global variables instead of actual global variables. You still have all the problems that come along with using variables that aren't local to a specific block of code, only now it's worse because you have more than one "global" scope that you have to concern yourself with. Once again, more complexity without benefit.
While I'm sure you're right about the possibility of abusing nesting (any programming feature can be abused), that doesn't make it a bad feature per se. And neither does the fact that C doesn't have it, make it a bad feature either. More to the point, most good programming language features ever invented, aren't in C!
You're correct, you can abuse any language feature. The difference here is, is wasn't abusing the feature, it was an unfortunate side effect of using the feature as intended
Oh, and I fail to see what makes lambdas so different from nested functions. The only difference I can see, is that languages with lambdas are usually garbage collected, so that passing pointers to nested functions around is safer. But other than that, failing to give nested functions a name (in the local scope) is merely a matter of syntax, not of semantics.
On this, I think you're probably technically right. They're intended to be used as little one line, convenience functions, but intent doesn't prevent it from being used in other ways. You could certainly abuse lambdas to write much longer functions and call them the same thing as Pascal's nested functions and procedures.
The real problem occurs when you need to go back later and make changes. You end up with things that can't see each other that now suddenly need to call each other and pass data. Consider this example:
You get specs for several different types of reports from the business people. The specs are very clear, very straightforward. You implement all of these reports using one main procedure for each report with nested procedures and functions inside that main report procedure. Your code is as clear as it can be, you get the results you expect, they love reports, and you're a hero.
Later on, they want some modifications to a report. It's a reasonable request; they'd just like to have a section from report A show up as a subsection in report B. At this point you could could just copy and paste all the code that generates that section from report A into report B, but this kind of code duplication is almost always a bad idea. You're only other choice at this point is to move the function or procedure you need up high enough in the scope hierarchy so that both reports can see it. Depending on how much nesting you did in the original reports, this could be pretty painful, since suddenly variables and functions and procedures that you expected to be in scope before aren't any longer, and now you have to pass them all as parameters, and... You get the idea. It just gets messy.
The big problem I have with nested functions is that yet again they make the code difficult to understand with the eyeballs. Worse yet, you have to define the function between the declaration of the outer function and the body of it. So you get this:If you had a code base that needed frequent modifications to allow new or different functionality, what little benefit there was to using nested functions are procedures is gone, and now it's just making your life miserable. You would've been better off if you just had all your functions and procedures at the same scope level from the start. This is essentially the scoping model modern languages use for functions and procedures.
This is a very good point. It gets difficult to tell just by looking at the code what level something was nested at, and where it could be called from.
Uh? Say again? What was the problem? Nested functions solve this problem. If the variable isn't local, it's in the containing lexical scope. This simplifies sharing of values.
Try refactoring a large pascal code base that makes heavy use of nested functions and procedures. When you start needing to pass values to a function or procedure in a way that wasn't originally envisioned, you have 3 choices:
I'm not sure what you are suggesting here, but it sounds like a bad idea. Just use lexical scoping, like Pascal does.
I'm suggesting that pushing variables up in scope is an option. A bad option, but it is, in fact, and option. It sounds like a bad idea because it is a bad idea. I wouldn't recommend it, and in fact I didn't recommend it. I was mostly using it to set up the second option, which I clearly marked as better.
C had two goals: (1) to be almost as useful as assembly language for systems programming (2) writing a C compiler should be easy. Lexical scoping of nested functions is missing from C because it made the compiler more complicated, not for any esoteric philosophical reasons like you suggest.
Err... what "esoteric philosophical reasons" did I suggest? That the feature wasn't worth supporting so it was left out? Nested scopes, such as Pascal's, were the result of academic research into computer science, and from an academic, theoretical point of view they make a great deal of sense. However the benefits of nested scopes didn't translate that well outside of academia.
To your point though, if K & R had thought nested scopes were valuable enough to include, they would of. Supporting nested scopes does make managing your symbol table more difficult, but not so much more so that they would not have included it if they thought it had value. Clearly, they didn't think it had enough value.
Well, if you are so retarded that you find nesting of variable-names within functions hard, I can understand why you prefer a system with only two levels of variable-names, local and global.
Right... I disagree with you, therefore I must be a retard. Nice critical thinking skills there...
I don't find the scoping rules for nested functions and procedures hard, I think they are unnecessary. The reason I prefer scoping rules such as C's and Java's is because they are what ended up getting used anyway. If I were to start writing programs in Pascal or Delphi again, I wouldn't use nested functions or procedures because they add too much complexity without providing enough benefit. I have no use for byzantine structures when simple ones suffice.
On the other hand, just about any other modern language includes some form of nesting of scopes, in a way that's harder to understand than Pascals nesting of functions.
The problem with nested functions (as in Pascal's scoping) is that in many situations it made it difficult to share values between functions or procedures, (Pascal makes a distinction between those). One way to solve that problem is to push variables up in scope, which leads to all the familiar problems with global variables. The better option was to not nest your functions and procedures in the first place, so newer languages stopped supported that feature. Most notably, C didn't include it, and as a result it drastically simplified scoping rules to more or less what we're accustomed to now.
Apple has been doing this sort of thing with QuickTime for a while now. I only have QuickTime installed on Windows, and every time it has an update for QuickTime it wants me to download QuickTime+iTunes. It's annoying, but you can unclick the box, and I think there is an option to tell it to ignore that update in the future.
bdp
We can remember it for you wholesale!
I think Earthworm Jim would be a fun character to include.
Nobody has mentioned it yet, but I wonder what the chances of Microsoft using some of the technology developed by Lionhead in other products, such as Windows or Office. Gesture technology has already been used in some other (non-MS) apps without a tremendous impact, but what if they took the trainable AI technology from Black & White and integrated it into their products so that you could have an assistant that actually learned how you use your computer, as opposed to something like the infamous Clippy that responds the essentially same way every time. I'm sure there's a market for that kind of thing out there.
That's not true. The distinction between a meteor and a meteorite is that meteors do not fall all the way to the ground, and meteorites do.
This also isn't true. Stuff continues to move out there, so we don't pass through the exact same spot in the debris trail every year. How big the meteor shower is varies from year to year.
I'll let somebody else point out that the orbit is 133 years, not 150.
The comet has a period of 133 years, but the Earth passes through the debris left by the comet every year.
I don't think I was entirely missing the point, but maybe I could have gone a little further in explaining myself. My poorly explained suggestion was that you can avoid the PCI bus entirely, thereby avoiding the bottleneck. When you have multiple cards installed in a single box you could just connect them together using some kind of high speed interconnect that goes directly between cards instead of using the system bus. That way you can have your high speed backplane to handle network switching/routing.
That said, I understand that this is a bit silly and completely misses the point of using a PC as a router instead of something designed to do the job, but it would hardly be the first time such a product came out of the tech industry. If somebody thinks there's a market for it, it will be built.
Is there any reason why you couldn't accomplish this using something besides an ASIC? Offloading the work to the card is what I suggested before, and if you want to switching or routing with any kind of low latency, you have to do that. If you used that strategy, the speed of the processor in the PC wouldn't matter any more than the speed of the processor in a Cisco. Again, it may defeat the point of using a PC for routing, but that doesn't mean nobody would build it if there was a market.
I think we're in total agreement that the high end of what Cisco does is not the target market. My biggest point that I was trying to make with my post was that there was no reason you couldn't stick a high speed backplane into a PC. It's just a matter of creativty and some engineering. Whether or not it makes sense is a whole different question.
Can't see why I would do that. You managed to express a different point of view without a) going apopletic, b)insisting I'm an idiot for not sharing your view, and c) not insulting me and/or my lineage. If anything, your behavior should be applauded. I can see how you would expect different treatment on
That's not quite true. There's no reason I can think of why you couldn't make a backplane for a PC that handles all the network traffic locally, without touching the PCI bus (or whatever bus). In fact, high speed interconnects used on clusters do that sort of thing already, and I suspect any high speed backplane for any platform would need to do the same. I'm not intimately familiar with ASICs, but if they add this type of functionality regardless of the clockspeed on the core chip, they probably handle all the traffic locally too.
A backplane like that may not exist for a PC currently, but if their PC router is successful enough to get companies using it, somebody will create one. Engineering a high speed backplane for arbitrary hardware is a problem that has already been solved, all that's needed now is a market with enough demand to make it worthwhile to build.
I'm not sure they really need to provide all the modules that Cisco does. The majority of people only use a small subset of all the modules Cisco provides, and as long as that subset can be brought to the PC platform, (if they don't already exist in some form), then there will be a large market for Vyatta's product.
I'm sorry if you find that offensive, but it was abundantly clear that you misunderstood the original post. Not only did you misunderstand it, but you then proceeded to say more or less the exact same thing as the original post. I can only assume that anybody who didn't see that, didn't really read one, or both, posts.
Not to discount what you're saying, but did you really read what packeteer wrote?
packeteer wrote:
Sexual assualt is not ok but mark this one up as being younge and stupid. If a 19 year old takes you to dinner and a movie and you agree to go back to his place certain things are expected of you. This does not mean that what the boy did was acceptable but anyone slightly mature would realize what they are giving the impression they are going to do by going to his house.
Just by reading the two sentences around the one you quoted makes it perfectly clear what was meant, and that it's not at all trying to justify what the 19 year-old did, nor saying in anyway that this is acceptable behavior.
I can only assume that whoever moderated your comment up didn't really read what you responded to either. If they had, they surely wouldn't have labelled this as insightful.
My suggestion is to encourage them to start writing something, anything about their topic. It doesn't have to be good, it doesn't have to be well formed, is doesn't even need to be coherent, they just need to get ideas out so they can start making something out of it. Too many people can't start writing in the first place because they expect fully formed perfection to come out.
If they're all engineering type students, you could easily link it to one of the most important concepts in many engineering fields: Get a solution first, then refine it. They probably understand and accept this idea without question as engineers, you just have to show them it applies to writing as well.
With a litte thought, I'm sure you could find many more parallels between writing and engineering that you could use for teaching.
I agree that the chances of it being in the ecliptic are pretty slim, but it's really the only place we would be likely to find it. The only way this was found was because of it's interaction with other objects. If it wasn't in the ecliptic, it would not have much to interact with.