The problem is that while tabs can be size-adjusted, the rest of the letters can't be. Thus, although all your tabs expand and contract, the letters that you're indenting against don't, and the formatting looks gradually crazier.
I'm sure you're worked with small tabs (for example 4-space), and then seen your code in a "normal" editor or printout (8-space) -- the result looks just crazy.
And at least I can see a { or } in printed code. Seeing white space is altogether more difficult!
Not completely true. Seeing _whitespace_ is impossible; seeing _indentation_, however, is extremely easy. In fact, it's enormously easier than seeing { and }; consider the fact that many C bugs are of the form
if (something)
do_this();
do_that();
...where "do_that" appears to most people to be conditional, but is actually unconditionally executed.
The difference is that every procedural programmer -- including the ones I was working with -- knows that globals are bad. The problem is that they don't know object-oriented design, and they thought that they'd acheive it by adding classes to their existing C methods. They also knew that classes have instance variables so that objects can have state, so they added those as well.
Yes, there are stupid programmers everywhere. No, that doesn't make "C with classes" bad -- but I don't know what the original author meant by "C with classes". If he meant "procedural programs wrapped in classes", then my warning holds.
If you'll clarify what you mean by "C with classes" I can tell you whether my sad story applies to it.
I'd like to point out that there is absolutely nothing wrong with writing "C with Classes."
Depends what you mean -- the type I'm most familiar with jams all the functions into one class which is then instantiated once, and since the programmer knows that "it's an object" he knows that it must need member data, so he feels free to have all the functions use lots of member data. (Effectively indistinguishable from global variables.)
I worked with one class that had over 100 methods and 50 member variables. There were hidden in there about 5 completely different interfaces, none of which were simultaneously usable (because they shared member variables); in addition, the 5 interfaces consisted each of about 10 functions (some shared with other interfaces), most of which had to be called in a specific order.
To add insult to injury, most of the actual data-passing in these functions were not via the member variables; it was via massively long function parameter lists. Many of the functions took pointers to the same data that _had_ to be in a member variable.
That's what I think of when I hear "C with Classes".
You can see why I wince.
Now, I've written a good amount of "strongly typed C" (that's C code compiled with a C++ compiler); it's my preferred way of writing C. I think _that's_ a good thing. But if you're going to use classes, I think you HAVE to know how to write object-oriented code to an object-oriented design; you can't just use the old C procedural skills.
I agree with your conclusion, but your rationale is lacking. Yes, I've tried searching for 'i' in a modern IDE; it works perfectly well. Matter of fact, I search for it in vi, and it works perfectly well too, because 'i' and other short variables are only for local scopes -- I can find where they're defined by shifting my eyes upwards, and maybe pressing page up once.
Yes, not all code is good. But if you have a choice between a short index variable and a long one, you're writing the code. Write it well, and the length of the variable won't matter.
If you'd read the article, you'd know. This system, unlike the well-known whitelist system, doesn't classify unknown email at all.
How did this get in to Nature? There are far better anti-spam tools like spamassassin & popfile that are far more effective against spam than this technique.
This technique, like all the other anti-spam techniques we have, is a tool, not a system. You don't STOP using all the other things when you start using it. This one, unlike all the others that I know of, can work well with the others because when it has a classification, it knows for SURE. If it says an email is spam, the ISP can throw the email away, and not waste time and resources storing it (and therefore not waste the user's resources doing a Bayesian scan, which is actually relatively computationally expensive). If it says an email is NOT spam, further analysis for generic spam isn't needed (although, of course, other types of categorization are often called for, as with the person who wants to block massively forwarded jokes).
You'd certainly still be running POPFile -- this method only creates a determination for 50% of email anyhow, and the remaining 50% still has to be classified. The nice part is that it works at the receiving ISP level, so you never have to see the "spam" part of the 50%, and your ISP doesn't have to store it.
This would pass the "joke network" emails right on through, and POPFile would be able to work on them -- but how nice, POPFile wouldn't ALSO have to wade through all those other nonsense emails.
This isn't marketted as a cure-all, only as an augmentation of what we do now. It's also apparently unique, since it requires relatively low overhead and can be done in a distributed way -- that is, it's practical for even large ISPs, but it doesn't require a centralized list like the blacklists do.
The Framework Classes are the Framework Classes. If Mono creates their own API to do XYZ, then its _NOT_ an extension of the.NET Framework anymore than my HelloWorld.cs class is an extension to the Framework.
Yes, Mono can't change "the Framework classes", which are part of a language standard. But they CAN change.NET, or more accurately people's perception of and expectations for.NET, in the same way that Microsoft or Netscape can change people's expectations of HTML.
Surely you can't ignore the fact that Windows.Forms is _part_ of.NET right now; Mono may someday be able to change that.
Mono is a project that comprises many subprojects. One of those subprojects is.NET compatibility. But if that subproject were dropped from Mono, you'd still be left with a vibrant, useful project. It is therefore wrong to talk of Mono as "extending.NET" as if.NET was the foundation of everything Mono does.
Visit Mono's home page and see the first paragraph in the center of the page. Allow me to quote:
"The Mono project is an open source effort sponsored by Novell to create a free implementation of the.NET Development Framework."
I don't know why I even have to say this; it's obvious from everything about the project. Why on earth you'd want to deny it is only eclipsed by the fact that somehow you've become ABLE to deny it. No,.NET isn't the "foundation of everything Mono does"; but Mono is primarily an implementation of.NET.
I understand where you're coming from, but none of these points pertain to the.NET Framework as a Framework, but rather what you can build with it.
No. You can't build GTK# using only the Framework, any more than you could build Windows.Forms using only the Framework. You need GTK for GTK#, and you need Win32 for Windows.Forms.
Windows.Forms is part of Microsoft's.NET Framework, and GTK# is Mono's extension to the.NET Framework to allow more portable.NET graphics.
The Framework is the CLR and standardized API.
Right. And Mono implements the CLR decently (minus a few features), then implements the API decently (minus a lot of features, but slowly catching up); then it adds to that API more features.
Constructing their own GTK# language
API, not language.
and database access is not an extension to "The Framework" but rather an implementation of the "The Framework".
Wow. No. Not even. Ever. Under any definition.
Both of those things (GTK# and the database API whose name I've forgotten) are APIs that Mono developers have, that the.NET standard doesn't, but which could be added to.NET. They're extensions.
They are NOT a implementation of the Framework. Mono is an implementation of the Framework.
Unless they are making modifications to the CLR and/or adding new instructions to the CIL, they're not extending anything,
Great! Then we agree -- because Mono makes modifications to the CLR (by providing more APIs), it's extending.NET.
[they're not extending anything,] anymore than I do when I write my own application.
But Mono isn't just a.NET application. If you wrote a reimplementation of.NET that had more capabilities in its APIs than Microsoft's, then you'd be extending.NET just the same as Mono is.
Geos 1.x printed beautiful, crisp black-and-white text and graphics (the text was rendered from outline fonts, by the way). Geos 2.0 did the same, but added a "high quality" setting, in which the printer would make 4 passes over each line.
You had to be careful with stuff printed at high quality -- not only was the paper wet from all the ink, it would also be sliced in places.
So that proves that dot matrix printers print more ink on the page than they cut grooves into the paper:-).
In other words, Mono is.NET, embraced and extended.
Sounds like he's saying it extends the framework to me...
No, he's not -- but I understand how you'd reach that misunderstanding. He's trying to compare Mono to Microsoft's well-known tactic of "embrace and extend", wherein they "embrace" a popular/useful technology publicly, but then "extend" it via an implementation offerring a few advantages, but in a way that won't work with the original (often partially because of new capabilities).
Quite seriously, this is precisely what Mono is doing with.NET.
But again, if you're not familiar with that expression, I can understand why you'd misread it to be saying that Mono was extending.NET....and can you explain to me how the.NET Framework is improved upon in Mono?
Not as well as many others have, but I'll summarize a couple of points.
- they offer a FAR superior alternative to ADO.NET (caveat: I've no right to judge, as database access isn't my specialty)
- they offer very elegant access to graphics operations in a way which is both powerful and platform-independant (Windows.Forms only handles one of these things at a time). I've been told that GTK# is one of the nicest ways to do GTK work.
Now mind you, I'm NOT saying that Mono is better than.NET. I'm just saying that it has value of its own, and some things in it are improvements on things in.NET. (Others are definitely steps backward -- but that's explicitly because Mono isn't complete.)
Calling Mono an extension to.NET because it uses Gnome is like calling a Ford car chassis with a Yugo engine an enhanced vehicle.
That's right, but that's not what he said. He said that Mono extends.NET by adding things like GTK# et al. Mono itself is clearly NOT an extension to.NET, since it fails to implement a large number of things in.NET.
Mono feeds off of the various Linux GUI libararies in order to implement the windowing requirements for.NET.
Nope. It FAILS to implement the windowing requirements of.NET. (Although that's being worked on.)
The real reason Mono feeds off (various things, including GUI Libraries) is in order to add functionality to.NET..NET doesn't have D-BUS.
Mono offers no improvements to.NET as a Framework.
Incorrect.
They are also nowhere near completion of implementing the entire Framework.
Correct.
Right now Mono is a "neat tool" which might let you run your C# app under Linux (no offense to your work and efforts intended, Miguel).
Berkley Softworks developed C64-Geos, which was also ported to the Apple and such, and then all through the 80s worked on their next accomplishment: Geos for the PC.
When released, it was the first commercial object oriented OS for the PC (NeXTStep was earlier, but Geos beat it to the PC).
And honestly, it kicked BUTT, because not only was it fast and elegant, it had a KILLER application suite and awesome dot matrix printer driver. Near laser quality from a mere 24-pin and my old '286... And it ran as a DOS application, too, with special drivers to make it cooperate with DR-DOS' task switcher.
We don't/know/ that it's the same person, but the fact is that whoever it is included a copy of the source for MyDoom with it. This does narrow things down a bit -- admittedly no proof, but definitely a smoking gun.
BTW, this is a very odd thing for a spammer to do, since it reveals everything any of their competitors would need to know to use their network.
Your post was almost entirely correct, and was very powerful in rebutting the nonsense you were responding to.
In old languages like Lisps the use of generics is usually strongly discouraged [...]
You know why it's discouraged? because it doesn't exist!
Not true -- Common Lisp has generics.
Lisp is dynamically typed, so templates don't make much sens.
Lisp includes facilities for specifying static types, so its templates. However, generics are useful for more than just static typing; they provide polymorphism that inheritance alone can't provide.
I guess you're confusing with macros, that are, indeed, Turing complete and can arbitrarily mess up the grammer in unskilled hand.
He probably is confusing SOMETHING, but macros aren't discouraged in the Lisp community:-). They're considered to be one of the great strengths of Lisp. Some people even mistakenly believe that they're unique to Lisp's s-expressions (incorrect because Forth's "concatenative" syntax is even more applicable to automatic code generation).
I've really seldom seen such an accumulation of BS in a single post.
I agree with this sentiment, although I've seen worse:-).
They did NOT sue/squash us. We sue/squashed them; and in return, they embrace/extend/extinguished us -- but what they didn't realise and we did was that the market for disk compression was OVER. They took it from us by buying and releasing one of our competitor's products which didn't infringe on our patents, but they got NOTHING in return, not even the satisfaction of causing our demise.
I left the company with the Hifn spinoff, so I missed all the fun as Stac stopped producing real product and went into an orgy of spending Microsoft's money on research products; having lost their original direction (compression) and all motivation (having to earn a living), their days were numbered (but that wasn't Microsoft's fault!).
Why would you use the pluralization virii, though? It's not an English pluralization, and it's not a Latin one either. In Latin the word virus is defectively plural; it's a mass noun, always used in an uncountable manner.
The elevator isn't everywhere on the Earth's equator -- it's only at one point.
No, it's everywhere - the Earth rotates. Therefore the (corrected for the 90 degree phase difference, since the elevator shoots perpendicular to its radial axis) projection of the equator on the Moon is the target that the Moon [sic] can hit.
It's possible that each point on the equator will sweep over every point covered by the equator, but it's not by any means certain. The moon's orbit is NOT static; even given all the time in the world it won't repeat itself.
This means that, even given unlimited time, our elevator may NOT sweep over every part of the moon's surface that the equator sweeps over.
Of course, it just might. So what? Time is of the essence. If someone's going to perform this attack, they have to prepare for it and execute it in a TINY window. If they realise that execution won't work this time, they have to abort and wait for next time to come around. Care to calculate how many seconds until that next time? The answer will have a lot of zeroes, any way you read it!
Actually, this *does* work. Go look it up in any basic high-energy physics book: any force with a 1/r^2 dependence has an effective cross section at low velocities (energies) of twice the hard-sphere model. This is obvious. If you try to hit the moon, gravity pulls you towards the moon, so you'll hit it. Yes, you're trying to hit a specific spot, but thankfully, vectors add, not replace each other, so you can compute the trajectory such that the impact point is your target. Then you just have to wait for the elevator to line up.
This paragraph is true but irrelevant -- you're NOT trying to hit the moon. You're trying to hit a target on the moon. The last two sentances are the kickers -- you have to compute THE trajectory, and then all you can do is wait.
You actually said this - "gravity doesn't magically pull bullets toward their target", but it "accelerates objects towards each other." Well, pull means force, and acceleration is force, so you just said that gravity doesn't do something it does.:)
You missed the most crucial part of my statement, one which I spent a long time expanding on. Here's another statement of it: every object attracts every other object, but not every object is your target. In this case, only one object is your target, and it's of negligable mass compared to its background. The moon may be easy to hit; but your target isn't any easier to hit than it would have been in open space.
The problem in shooting something, like a bullet, is that the gravitational attraction is virtually zero and the kinetic energy greatly exceeds the potential energy.
Yes; and the gravitational attraction from other objects swamps that from your target. Heck, a nearby hill swamps the attraction from your target.
Moon's velocity would be perpendicular to the projectile velocity.
The moon wouldn't be parallel, but neither would it be perpendicular to launch.
They wouldn't add or subtract. Relative velocity would be 3 km/s (for a counterweight at virtually infinite distance, less for one closer to geosync, obviously).
You're merely making the opposite approximation to the one I made. The velocity relative to the moon would be between 2 and 3 km/s.
The travel to the moon would be longer than the distance from geosynch to moon's orbit, too, but I made that approximation because I didn't want to figure the orbit (nor did I want to work any trig to find the straight-line path). The two assumptions cancel each other out -- slower velocity, shorter trajectory.
Of course, the answer is wrong, but I'm hoping it's ballpark, and at any rate it gives some idea of the magnitudes involved.
I just realised, by the way, that one of my numbers was badly wrong anyhow. I assumed 3km/s launch velocity -- that was stupid. That's geosynch veloci
Once every few years, that is. The moon-Earth cycle repeats on a few-year basis. Heck, if you're trying for surprise mass destruction, what's a few years to wait?
See below -- the repeat isn't close enough to allow you to hit the same target. You'd have to be shooting at a city, not a building -- and I can't see any reason to build a city anywhere in line with the elevator.
Besides, I don't understand why you don't see what I mean: the area of land that the elevator can impact is (kindof) the projection of the Earth's axis on the Moon.
You mean equator, of course.
Since the relative orientation of those two things change over the year and over the month, the elevator can hit the entire area that it sweeps over, which is pretty large.
The elevator isn't everywhere on the Earth's equator -- it's only at one point.
Plus the lunar "wiggles" will help you here too, since the Moon doesn't present "exactly" the same face to us all the time (lunar librations are the term, I think).
Exactly -- in other words, the next time we swing by the aim will be different. There's no such thing as an exact repeat; wait a few years for the moon to swing by again, and even if you're not arrested for making the first failed attempt, you're definitely not going to be aiming for the same place.
Remember, it's a LONG shot.
I don't get it: suppose the Moon and the Earth are lined up, and everything's aligned. Then basic ballistics says you can only fire when the straightline projection of the path impacts the moon.
You're forgetting gravity -- it's not a straight line, but rather a conic section. But that doesn't matter; you can pretend it's straight, since like a straight line, at a given velocity there's only one shortest-time ballistic path between two points. The point is that there's only ONE trajectory you can follow to hit your desired target; if you launch off by even a tiny bit (anyone care to compute how long your launch window would be in order to hit any realistic target?), you miss. Doesn't matter if you hit the moon; you missed your target.
However, gravity increases the effective cross-section of any object by a factor of two - something fired with a straightline projection "near" an object will hit the object.
I wish this actually worked -- my target shooting would be a lot better if it did! But it doesn't. Gravity doesn't magically pull bullets toward their targets; it merely accelerates masses toward each other. The problem is that the mass of the moon FAR outweighs the mass of your actual target; your sabot isn't going to be drawn toward the target, but rather the moon as a whole.
Therefore, if the straightline projection misses the moon by a bit, the gravitationally affected path will not.
But you're not trying to shoot the moon. That's already been done -- see those craters? You're actually trying to hit a tiny spot on the moon.
I'd like to run the calculations -- you can make some assumptions to make it simpler. But I don't have the time. Think about it, though -- the counterweight will be moving about 2km/s relative to the moon (geosync is 3km/s, moon is 1km/s), so it'll take more than 2 days to reach it (that's assuming the launch was normal to the geosync orbit rather than tangent, so it'll actually be much longer). That's more than 2 days of time for any tiny directional error to accumulate. How are you going to have microsecond accuracy on cutting the cable, especially when everyone knows the only time (down to the microsecond) you can possibly do it?
I can't see that being easy, though. It depends on an impressive list of things, foremost amongst them is there being a lunar base in any sort of position to be hit by the counterweight. It's not like you can aim; all you can do is time the break.
The axis of the Moon's orbit and the Earth's rotation aren't aligned. You'd actually have a large portion of the surface of the Moon that you could aim at. Perhaps all of it. You'd just have to wait until the proper alignment of the elevator and the Moon.
I admit I was being brief (I know the alignments aren't perfect); but this complication doesn't change things at all. There are still huge tracts of land on the moon which don't line up with any trajectory of an elevator break (in fact, that's an understatement made strictly because I wanted to use the phrase "huge tracts of land on the moon"), and because the lineup isn't exact, it's much worse for any potential attacker -- any given target will present itself once, and essentially never again.
Plus gravity is very helpful with these sort of things. Makes the cross-section of the moon twice as big, after all (if memory serves).:)
What do you mean? This is basic ballistics; there's only one minimum-time trajectory, and all the other possible trajectories will involve at least one circuit of the moon, plenty of time for defenders to get something to intercept the counterweight before it can collide. There's therefore only one conceivable target-time.
The effective "cross-section" of the moon may be large from geosync orbit, but that doesn't affect the cross-section of any actual targets on it.
-Billy
Re:New idea for causing massive damage! :)
on
Clean Nuclear Launches?
·
· Score: 2, Insightful
Try breaking the cable high enough above the planet that the counterweight exits Earth orbit.
Okay, I can see that being easy.
Now, imagine TIMING such an event so that the counterweight ends up headed right for a lunar base.
I can't see that being easy, though. It depends on an impressive list of things, foremost amongst them is there being a lunar base in any sort of position to be hit by the counterweight. It's not like you can aim; all you can do is time the break.
The people building the elevator and lunar base, on the other hand, CAN aim -- they can choose to move the location of one or the other over by a few feet or miles, and make an impact opportunity vanishingly rare or even impossible.
Of course, they can't do that if they never think of it, so it's good that you and others like you are looking for the loopholes.
I'm only a beginner in C# and Java, but I know both have reflection, and the proposed Java 1.5 has enums. Kudos to C# for having them first:-), but Java 1.5 has them better, as first-class objects.
Also.net/IIS is a better platform for webdevelopment.
Better for whom? Why? Doesn't it have the severe shortcoming of platform lockdown?
I can write a c#.net app in 1/4th the code of a java one. Go take a look at Microsoft's petshop program if you do not believe me.
I can write an assembly app in 1/4 the code of a Python one. Assuming, of course, that the Python app wasn't written for small code size... The simile is very accurate; Sun didn't write their petshop for small size.
The Java Petshop reimplementation here spanks both Sun's and Microsoft's petshop in terms of size, and pretty clearly demonstrates that both languages could do better.
BTW, I absolutely love C# -- from what I've done with it so far. My only complaint is that its support is at best halfhearted for other platforms, and I will not allow my work to be tied down to one platform. This is the only thing that kept me from learning K (well, K is portable, the only problem is that it's only available from one vendor, Kx systems). Anyhow, I think C#'s bytecode is far beyond anything Sun's ever going to do with Java.
ALso WIndows2k3 is as stable as Linux now. NT4 is old. The situation has improved dramatically. I have never even seen a blue screen on windows2k yet!
I agree with all of that, but it's not enough. I have seen blue screens and system crashes on 2000 and XP (XP far, FAR FAR more often than 2000). But then I've seen system crashes on Linux, so I'm not just complaining about MS;-).
Slashdot Mirror
The problem is that while tabs can be size-adjusted, the rest of the letters can't be. Thus, although all your tabs expand and contract, the letters that you're indenting against don't, and the formatting looks gradually crazier.
I'm sure you're worked with small tabs (for example 4-space), and then seen your code in a "normal" editor or printout (8-space) -- the result looks just crazy.
-Billy
Not completely true. Seeing _whitespace_ is impossible; seeing _indentation_, however, is extremely easy. In fact, it's enormously easier than seeing { and }; consider the fact that many C bugs are of the form...where "do_that" appears to most people to be conditional, but is actually unconditionally executed.
-Billy
The difference is that every procedural programmer -- including the ones I was working with -- knows that globals are bad. The problem is that they don't know object-oriented design, and they thought that they'd acheive it by adding classes to their existing C methods. They also knew that classes have instance variables so that objects can have state, so they added those as well.
Yes, there are stupid programmers everywhere. No, that doesn't make "C with classes" bad -- but I don't know what the original author meant by "C with classes". If he meant "procedural programs wrapped in classes", then my warning holds.
If you'll clarify what you mean by "C with classes" I can tell you whether my sad story applies to it.
-Billy
I'd like to point out that there is absolutely nothing wrong with writing "C with Classes."
Depends what you mean -- the type I'm most familiar with jams all the functions into one class which is then instantiated once, and since the programmer knows that "it's an object" he knows that it must need member data, so he feels free to have all the functions use lots of member data. (Effectively indistinguishable from global variables.)
I worked with one class that had over 100 methods and 50 member variables. There were hidden in there about 5 completely different interfaces, none of which were simultaneously usable (because they shared member variables); in addition, the 5 interfaces consisted each of about 10 functions (some shared with other interfaces), most of which had to be called in a specific order.
To add insult to injury, most of the actual data-passing in these functions were not via the member variables; it was via massively long function parameter lists. Many of the functions took pointers to the same data that _had_ to be in a member variable.
That's what I think of when I hear "C with Classes".
You can see why I wince.
Now, I've written a good amount of "strongly typed C" (that's C code compiled with a C++ compiler); it's my preferred way of writing C. I think _that's_ a good thing. But if you're going to use classes, I think you HAVE to know how to write object-oriented code to an object-oriented design; you can't just use the old C procedural skills.
-Billy
Just thought I'd post a link to an example of an imperative language implementing JPEG decoding in only a few pages of code. :-).
-Billy
Ever try searching for "i" in a modern IDE?
Long names are good.
I agree with your conclusion, but your rationale is lacking. Yes, I've tried searching for 'i' in a modern IDE; it works perfectly well. Matter of fact, I search for it in vi, and it works perfectly well too, because 'i' and other short variables are only for local scopes -- I can find where they're defined by shifting my eyes upwards, and maybe pressing page up once.
Yes, not all code is good. But if you have a choice between a short index variable and a long one, you're writing the code. Write it well, and the length of the variable won't matter.
-Billy
If you'd read the article, you'd know. This system, unlike the well-known whitelist system, doesn't classify unknown email at all.
How did this get in to Nature? There are far better anti-spam tools like spamassassin & popfile that are far more effective against spam than this technique.
This technique, like all the other anti-spam techniques we have, is a tool, not a system. You don't STOP using all the other things when you start using it. This one, unlike all the others that I know of, can work well with the others because when it has a classification, it knows for SURE. If it says an email is spam, the ISP can throw the email away, and not waste time and resources storing it (and therefore not waste the user's resources doing a Bayesian scan, which is actually relatively computationally expensive). If it says an email is NOT spam, further analysis for generic spam isn't needed (although, of course, other types of categorization are often called for, as with the person who wants to block massively forwarded jokes).
-Billy
You'd certainly still be running POPFile -- this method only creates a determination for 50% of email anyhow, and the remaining 50% still has to be classified. The nice part is that it works at the receiving ISP level, so you never have to see the "spam" part of the 50%, and your ISP doesn't have to store it.
This would pass the "joke network" emails right on through, and POPFile would be able to work on them -- but how nice, POPFile wouldn't ALSO have to wade through all those other nonsense emails.
This isn't marketted as a cure-all, only as an augmentation of what we do now. It's also apparently unique, since it requires relatively low overhead and can be done in a distributed way -- that is, it's practical for even large ISPs, but it doesn't require a centralized list like the blacklists do.
-Billy
The Framework Classes are the Framework Classes. If Mono creates their own API to do XYZ, then its _NOT_ an extension of the .NET Framework anymore than my HelloWorld.cs class is an extension to the Framework.
.NET, or more accurately people's perception of and expectations for .NET, in the same way that Microsoft or Netscape can change people's expectations of HTML.
.NET right now; Mono may someday be able to change that.
Yes, Mono can't change "the Framework classes", which are part of a language standard. But they CAN change
Surely you can't ignore the fact that Windows.Forms is _part_ of
-Billy
Mono is a project that comprises many subprojects. One of those subprojects is .NET compatibility. But if that subproject were dropped from Mono, you'd still be left with a vibrant, useful project. It is therefore wrong to talk of Mono as "extending .NET" as if .NET was the foundation of everything Mono does.
.NET Development Framework."
.NET isn't the "foundation of everything Mono does"; but Mono is primarily an implementation of .NET.
Visit Mono's home page and see the first paragraph in the center of the page. Allow me to quote:
"The Mono project is an open source effort sponsored by Novell to create a free implementation of the
I don't know why I even have to say this; it's obvious from everything about the project. Why on earth you'd want to deny it is only eclipsed by the fact that somehow you've become ABLE to deny it. No,
-Billy
I understand where you're coming from, but none of these points pertain to the .NET Framework as a Framework, but rather what you can build with it.
.NET Framework, and GTK# is Mono's extension to the .NET Framework to allow more portable .NET graphics.
.NET standard doesn't, but which could be added to .NET. They're extensions.
.NET.
.NET application. If you wrote a reimplementation of .NET that had more capabilities in its APIs than Microsoft's, then you'd be extending .NET just the same as Mono is.
No. You can't build GTK# using only the Framework, any more than you could build Windows.Forms using only the Framework. You need GTK for GTK#, and you need Win32 for Windows.Forms.
Windows.Forms is part of Microsoft's
The Framework is the CLR and standardized API.
Right. And Mono implements the CLR decently (minus a few features), then implements the API decently (minus a lot of features, but slowly catching up); then it adds to that API more features.
Constructing their own GTK# language
API, not language.
and database access is not an extension to "The Framework" but rather an implementation of the "The Framework".
Wow. No. Not even. Ever. Under any definition.
Both of those things (GTK# and the database API whose name I've forgotten) are APIs that Mono developers have, that the
They are NOT a implementation of the Framework. Mono is an implementation of the Framework.
Unless they are making modifications to the CLR and/or adding new instructions to the CIL, they're not extending anything,
Great! Then we agree -- because Mono makes modifications to the CLR (by providing more APIs), it's extending
[they're not extending anything,] anymore than I do when I write my own application.
But Mono isn't just a
-Billy
:-)
:-).
Geos disproves that!
Geos 1.x printed beautiful, crisp black-and-white text and graphics (the text was rendered from outline fonts, by the way). Geos 2.0 did the same, but added a "high quality" setting, in which the printer would make 4 passes over each line.
You had to be careful with stuff printed at high quality -- not only was the paper wet from all the ink, it would also be sliced in places.
So that proves that dot matrix printers print more ink on the page than they cut grooves into the paper
-Billy
I wasn't aware there was a Smalltalk for DOS at the time. My mistake.
Perhaps I could call PC-Geos the first consumer OO OS?
-Billy
Sounds like he's saying it extends the framework to me...
No, he's not -- but I understand how you'd reach that misunderstanding. He's trying to compare Mono to Microsoft's well-known tactic of "embrace and extend", wherein they "embrace" a popular/useful technology publicly, but then "extend" it via an implementation offerring a few advantages, but in a way that won't work with the original (often partially because of new capabilities).
Quite seriously, this is precisely what Mono is doing with
But again, if you're not familiar with that expression, I can understand why you'd misread it to be saying that Mono was extending
Not as well as many others have, but I'll summarize a couple of points.
- they offer a FAR superior alternative to ADO.NET (caveat: I've no right to judge, as database access isn't my specialty)
- they offer very elegant access to graphics operations in a way which is both powerful and platform-independant (Windows.Forms only handles one of these things at a time). I've been told that GTK# is one of the nicest ways to do GTK work.
Now mind you, I'm NOT saying that Mono is better than
-Billy
Calling Mono an extension to .NET because it uses Gnome is like calling a Ford car chassis with a Yugo engine an enhanced vehicle.
.NET by adding things like GTK# et al. Mono itself is clearly NOT an extension to .NET, since it fails to implement a large number of things in .NET.
.NET.
.NET. (Although that's being worked on.)
.NET. .NET doesn't have D-BUS.
.NET as a Framework.
:-)
That's right, but that's not what he said. He said that Mono extends
Mono feeds off of the various Linux GUI libararies in order to implement the windowing requirements for
Nope. It FAILS to implement the windowing requirements of
The real reason Mono feeds off (various things, including GUI Libraries) is in order to add functionality to
Mono offers no improvements to
Incorrect.
They are also nowhere near completion of implementing the entire Framework.
Correct.
Right now Mono is a "neat tool" which might let you run your C# app under Linux (no offense to your work and efforts intended, Miguel).
Correct.
-Billy
Berkley Softworks developed C64-Geos, which was also ported to the Apple and such, and then all through the 80s worked on their next accomplishment: Geos for the PC.
When released, it was the first commercial object oriented OS for the PC (NeXTStep was earlier, but Geos beat it to the PC).
And honestly, it kicked BUTT, because not only was it fast and elegant, it had a KILLER application suite and awesome dot matrix printer driver. Near laser quality from a mere 24-pin and my old '286... And it ran as a DOS application, too, with special drivers to make it cooperate with DR-DOS' task switcher.
I miss it now.
-Billy
Relax.
/know/ that it's the same person, but the fact is that whoever it is included a copy of the source for MyDoom with it. This does narrow things down a bit -- admittedly no proof, but definitely a smoking gun.
We don't
BTW, this is a very odd thing for a spammer to do, since it reveals everything any of their competitors would need to know to use their network.
-Billy
You know why it's discouraged? because it doesn't exist!
Not true -- Common Lisp has generics.
Lisp is dynamically typed, so templates don't make much sens.
Lisp includes facilities for specifying static types, so its templates. However, generics are useful for more than just static typing; they provide polymorphism that inheritance alone can't provide.
I guess you're confusing with macros, that are, indeed, Turing complete and can arbitrarily mess up the grammer in unskilled hand.
He probably is confusing SOMETHING, but macros aren't discouraged in the Lisp community
I've really seldom seen such an accumulation of BS in a single post.
I agree with this sentiment, although I've seen worse
-Billy
I worked for Stac back when that lawsuit started.
They did NOT sue/squash us. We sue/squashed them; and in return, they embrace/extend/extinguished us -- but what they didn't realise and we did was that the market for disk compression was OVER. They took it from us by buying and releasing one of our competitor's products which didn't infringe on our patents, but they got NOTHING in return, not even the satisfaction of causing our demise.
I left the company with the Hifn spinoff, so I missed all the fun as Stac stopped producing real product and went into an orgy of spending Microsoft's money on research products; having lost their original direction (compression) and all motivation (having to earn a living), their days were numbered (but that wasn't Microsoft's fault!).
-Billy
Why would you use the pluralization virii, though? It's not an English pluralization, and it's not a Latin one either. In Latin the word virus is defectively plural; it's a mass noun, always used in an uncountable manner.
-Billy
No, it's everywhere - the Earth rotates. Therefore the (corrected for the 90 degree phase difference, since the elevator shoots perpendicular to its radial axis) projection of the equator on the Moon is the target that the Moon [sic] can hit.
:)
It's possible that each point on the equator will sweep over every point covered by the equator, but it's not by any means certain. The moon's orbit is NOT static; even given all the time in the world it won't repeat itself.
This means that, even given unlimited time, our elevator may NOT sweep over every part of the moon's surface that the equator sweeps over.
Of course, it just might. So what? Time is of the essence. If someone's going to perform this attack, they have to prepare for it and execute it in a TINY window. If they realise that execution won't work this time, they have to abort and wait for next time to come around. Care to calculate how many seconds until that next time? The answer will have a lot of zeroes, any way you read it!
Actually, this *does* work. Go look it up in any basic high-energy physics book: any force with a 1/r^2 dependence has an effective cross section at low velocities (energies) of twice the hard-sphere model. This is obvious. If you try to hit the moon, gravity pulls you towards the moon, so you'll hit it. Yes, you're trying to hit a specific spot, but thankfully, vectors add, not replace each other, so you can compute the trajectory such that the impact point is your target. Then you just have to wait for the elevator to line up.
This paragraph is true but irrelevant -- you're NOT trying to hit the moon. You're trying to hit a target on the moon. The last two sentances are the kickers -- you have to compute THE trajectory, and then all you can do is wait.
You actually said this - "gravity doesn't magically pull bullets toward their target", but it "accelerates objects towards each other." Well, pull means force, and acceleration is force, so you just said that gravity doesn't do something it does.
You missed the most crucial part of my statement, one which I spent a long time expanding on. Here's another statement of it: every object attracts every other object, but not every object is your target. In this case, only one object is your target, and it's of negligable mass compared to its background. The moon may be easy to hit; but your target isn't any easier to hit than it would have been in open space.
The problem in shooting something, like a bullet, is that the gravitational attraction is virtually zero and the kinetic energy greatly exceeds the potential energy.
Yes; and the gravitational attraction from other objects swamps that from your target. Heck, a nearby hill swamps the attraction from your target.
Moon's velocity would be perpendicular to the projectile velocity.
The moon wouldn't be parallel, but neither would it be perpendicular to launch.
They wouldn't add or subtract. Relative velocity would be 3 km/s (for a counterweight at virtually infinite distance, less for one closer to geosync, obviously).
You're merely making the opposite approximation to the one I made. The velocity relative to the moon would be between 2 and 3 km/s.
The travel to the moon would be longer than the distance from geosynch to moon's orbit, too, but I made that approximation because I didn't want to figure the orbit (nor did I want to work any trig to find the straight-line path). The two assumptions cancel each other out -- slower velocity, shorter trajectory.
Of course, the answer is wrong, but I'm hoping it's ballpark, and at any rate it gives some idea of the magnitudes involved.
I just realised, by the way, that one of my numbers was badly wrong anyhow. I assumed 3km/s launch velocity -- that was stupid. That's geosynch veloci
Once every few years, that is. The moon-Earth cycle repeats on a few-year basis. Heck, if you're trying for surprise mass destruction, what's a few years to wait?
See below -- the repeat isn't close enough to allow you to hit the same target. You'd have to be shooting at a city, not a building -- and I can't see any reason to build a city anywhere in line with the elevator.
Besides, I don't understand why you don't see what I mean: the area of land that the elevator can impact is (kindof) the projection of the Earth's axis on the Moon.
You mean equator, of course.
Since the relative orientation of those two things change over the year and over the month, the elevator can hit the entire area that it sweeps over, which is pretty large.
The elevator isn't everywhere on the Earth's equator -- it's only at one point.
Plus the lunar "wiggles" will help you here too, since the Moon doesn't present "exactly" the same face to us all the time (lunar librations are the term, I think).
Exactly -- in other words, the next time we swing by the aim will be different. There's no such thing as an exact repeat; wait a few years for the moon to swing by again, and even if you're not arrested for making the first failed attempt, you're definitely not going to be aiming for the same place.
Remember, it's a LONG shot.
I don't get it: suppose the Moon and the Earth are lined up, and everything's aligned. Then basic ballistics says you can only fire when the straightline projection of the path impacts the moon.
You're forgetting gravity -- it's not a straight line, but rather a conic section. But that doesn't matter; you can pretend it's straight, since like a straight line, at a given velocity there's only one shortest-time ballistic path between two points. The point is that there's only ONE trajectory you can follow to hit your desired target; if you launch off by even a tiny bit (anyone care to compute how long your launch window would be in order to hit any realistic target?), you miss. Doesn't matter if you hit the moon; you missed your target.
However, gravity increases the effective cross-section of any object by a factor of two - something fired with a straightline projection "near" an object will hit the object.
I wish this actually worked -- my target shooting would be a lot better if it did! But it doesn't. Gravity doesn't magically pull bullets toward their targets; it merely accelerates masses toward each other. The problem is that the mass of the moon FAR outweighs the mass of your actual target; your sabot isn't going to be drawn toward the target, but rather the moon as a whole.
Therefore, if the straightline projection misses the moon by a bit, the gravitationally affected path will not.
But you're not trying to shoot the moon. That's already been done -- see those craters? You're actually trying to hit a tiny spot on the moon.
I'd like to run the calculations -- you can make some assumptions to make it simpler. But I don't have the time. Think about it, though -- the counterweight will be moving about 2km/s relative to the moon (geosync is 3km/s, moon is 1km/s), so it'll take more than 2 days to reach it (that's assuming the launch was normal to the geosync orbit rather than tangent, so it'll actually be much longer). That's more than 2 days of time for any tiny directional error to accumulate. How are you going to have microsecond accuracy on cutting the cable, especially when everyone knows the only time (down to the microsecond) you can possibly do it?
-Billy
The axis of the Moon's orbit and the Earth's rotation aren't aligned. You'd actually have a large portion of the surface of the Moon that you could aim at. Perhaps all of it. You'd just have to wait until the proper alignment of the elevator and the Moon.
I admit I was being brief (I know the alignments aren't perfect); but this complication doesn't change things at all. There are still huge tracts of land on the moon which don't line up with any trajectory of an elevator break (in fact, that's an understatement made strictly because I wanted to use the phrase "huge tracts of land on the moon"), and because the lineup isn't exact, it's much worse for any potential attacker -- any given target will present itself once, and essentially never again.
Plus gravity is very helpful with these sort of things. Makes the cross-section of the moon twice as big, after all (if memory serves).
What do you mean? This is basic ballistics; there's only one minimum-time trajectory, and all the other possible trajectories will involve at least one circuit of the moon, plenty of time for defenders to get something to intercept the counterweight before it can collide. There's therefore only one conceivable target-time.
The effective "cross-section" of the moon may be large from geosync orbit, but that doesn't affect the cross-section of any actual targets on it.
-Billy
Try breaking the cable high enough above the planet that the counterweight exits Earth orbit.
Okay, I can see that being easy.
Now, imagine TIMING such an event so that the counterweight ends up headed right for a lunar base.
I can't see that being easy, though. It depends on an impressive list of things, foremost amongst them is there being a lunar base in any sort of position to be hit by the counterweight. It's not like you can aim; all you can do is time the break.
The people building the elevator and lunar base, on the other hand, CAN aim -- they can choose to move the location of one or the other over by a few feet or miles, and make an impact opportunity vanishingly rare or even impossible.
Of course, they can't do that if they never think of it, so it's good that you and others like you are looking for the loopholes.
-Billy
Enumorators? Reflection?
:-), but Java 1.5 has them better, as first-class objects.
.net/IIS is a better platform for webdevelopment.
;-).
I'm only a beginner in C# and Java, but I know both have reflection, and the proposed Java 1.5 has enums. Kudos to C# for having them first
Also
Better for whom? Why? Doesn't it have the severe shortcoming of platform lockdown?
I can write a c#.net app in 1/4th the code of a java one. Go take a look at Microsoft's petshop program if you do not believe me.
I can write an assembly app in 1/4 the code of a Python one. Assuming, of course, that the Python app wasn't written for small code size... The simile is very accurate; Sun didn't write their petshop for small size.
The Java Petshop reimplementation here spanks both Sun's and Microsoft's petshop in terms of size, and pretty clearly demonstrates that both languages could do better.
BTW, I absolutely love C# -- from what I've done with it so far. My only complaint is that its support is at best halfhearted for other platforms, and I will not allow my work to be tied down to one platform. This is the only thing that kept me from learning K (well, K is portable, the only problem is that it's only available from one vendor, Kx systems). Anyhow, I think C#'s bytecode is far beyond anything Sun's ever going to do with Java.
ALso WIndows2k3 is as stable as Linux now. NT4 is old. The situation has improved dramatically. I have never even seen a blue screen on windows2k yet!
I agree with all of that, but it's not enough. I have seen blue screens and system crashes on 2000 and XP (XP far, FAR FAR more often than 2000). But then I've seen system crashes on Linux, so I'm not just complaining about MS
-Billy