I insist on bringing non-existence into it because that's the state of evidence for the proposition that there is a god. None. I don't extend belief to propositions that are outside the realm of known physics, have no supporting evidence, and for which the existence of the proposition itself can be explained by mundane, even if relatively unsavory, activities.
In the case of your example, it's entirely possible (re physics), but as it isn't in any way relevant to my life - it's trivial to me - and cannot equally trivially be verified, I won't extend the effort to bring my position on your postulate up to the level of belief. Which leaves me without belief, but not actively disbelieving -- that requires extending almost as much effort as believing. Which would be answer number (4) "have you seen my cat?"
Now, if your story had an out-of-physics qualifier in it: "We had 3-way sex on an inertia-less drive UFO", then I can trivially go straight for lacking belief without hearing any more. I would, I assure you, ask for a ride in the UFO. If you provided it, I'd buy your sex story, as your standard of telling me wild stuff and backing it up would now be world-class.
Likewise, if some religious person tells me there's a god, and he heals people instantly through them, I'd say, ok, here's this person I know who needs healing of the following kind. Heal them. Instantly. If they did so, I would credit the story that it was god, because if there's one thing I'm pretty sure of, it is that humans can't magically heal anything by themselves. Otherwise, I remain without belief in the god-concepts, and still convinced they're just another mundane jackass.
Yes, that would be where your error is, right there.
You're having a conversation right now with a hardline atheist — a fellow completely without belief in a god or gods — who asserts that certain claims of known non-existence of a god or gods are inherently flawed. That's just me; but there are others like me (Just ask here, there are plenty on slashdot) and there are many of other stripes, as well.
I'm hardly neutral; the only social constructs I hold less regard for than individual belief in such stories are the organizations that spread them around, asserting they represent truths.
Let me put it to you this way. Imagine something you consider to be utterly mythological, superstitious, not based in any way upon objective fact. You pick. Easter bunny, Santa, Elves, Astrology, Homeopathy, etc. I'll pick — for me — Astrology. Now, you and I both know, and surely can agree, that there are people out there who believe — and I mean really believe — in astrology. Now, since astrology (or whatever you picked) is definitely a load of ridiculous hokum someone made up and made a system out of, we can also agree that since there is no knowledge to be had about the operation of the mythological effects of the system, that belief can exist without any knowledge of empirical facts at all.
To elaborate, UFO cultists believe in UFOs without ever seeing them. The Heaven's Gate people believed enough to kill themselves. Kids believe in Santa. Some people believe in elves and fairies. Angels. Pick your poison. You should be able to easily identify a case where belief exists without knowledge. You know, facts. Those things that won't go away no matter how much you wish, pray, chant or hide them under crystal pyramids.
Conversely, there are people (let's call them morons, just to keep things honest) who don't hold any belief in evolution as a process. The facts - the knowledge - are that evolution is a repeatable, testable, dependable process that exists and operates irregardless of such beliefs, but nonetheless, these people cling firmly to the lack of belief. To put a fine point on it, they will not believe. This is their position. Again, we see that knowledge is not a prerequisite for belief.
So what we've established here is that belief can exist entirely separate from knowledge, and entirely without it. Belief is a position on a proposition. No more, no less.
Now. Given that this is so — and you know for a fact that of course it is — how is it that you would construct a position that says that a lack of knowledge in and of itself could possibly define a middle ground between belief and lack of belief? Belief is like pregnancy. Either you are, or you aren't. There's no middle ground. If you believe, then you don't lack belief — by definition.
That's why knowledge can't be used to define a presumptive "middle position" between those who hold beliefs and those who don't (on any subject you care to pick.) It is an illusion, at best a social play to avoid the stigma the religious like to attach to the atheists they can identify.
Definitions aside, if you come to me and say "I am agnostic", I will simply look you in the eye and say, "so, do you believe in a god or gods, or do you not?" You can legitimately answer:
Yes (you're a theist)
No (you're an atheist)
I don't know [if I have such a belief] (cowardice or capacity problem - jackass or clueless inability for introspection)
[_____] (failure to respond, but you know it's one of the 3 above)
...but what you can't legitimately answer is "I don't know if there's a god or gods"... because I didn't ask you that question. I asked you if you believed there was a god or gods. The question of knowledge, as unequivocally established above, is entirely disjoint from belief.
Not if there is no evidence of the woman's existence, you can't. You can't have any knowledge at all. All you can have (or not have) is belief; and that's the fulcrum upon which the weights of theism and atheism turn.
Athiests believe god does not exist. (negative)
Agnostics do not believe god exists and not not believe god does not exist. (neutral)
Thiests believe god exists. (positive)
That - to be blunt - is poppycock.
Theism is the belief in a god or gods. A-theism is the state of being without belief in a god or gods. Those are the two possible states. Agnosticism addresses why one does, or does not, hold such a belief, that is, whether one has knowledge with regard to the subject sufficient to establish belief — but it does not address whether one holds such a belief.
Knowledge and reasons aside, you're either theist, or atheist. There is no middle state. You can't believe and lack belief at the same time. Either you believe, or you don't. The terms theist and atheist don't delve into why. They simply address your state of belief.
When it comes to why people decide as they do, there are many types of atheist thinking as there are many types of religious thinking. One atheist will tell you the idea is simply ridiculous; another will tell you they see no evidence; another will tell you religion is clearly a control system; another will tell you they "know" there is no god. Theists will tell you god(s) are real within the Christian, Muslim, Hindu, etc. systems and further, within a range of variations within those systems of thought.
Bottom line, you can't be agnostic instead of theist, or atheist. If you say you are, what we take away from your statement is that you're bewildered and don't understand the subject matter.
Reading it, you'd think this would stop the theists from repeatedly dragging the man unwillingly into their camp; but since this well-known remark...
"It was, of course, a lie what you read about my religious convictions, a lie which is being systematically repeated. I do not believe in a personal God and I have never denied this but have expressed it clearly. If something is in me which can be called religious then it is the unbounded admiration for the structure of the world so far as our science can reveal it
...didn't do it... somehow, I doubt this new letter will, either, clear as it may be.
I didn't miss it at all. We build objects of that size here on earth (bridges, for one); there's nothing about this that screams "can't be done." Hard? Sure. Put a few technologies in place - like a space-based materials plant - and it could be *tens* of kilometers times multiple instances and it wouldn't make much difference, other than time.
The problem with using a solid sphere of rock is that the mass is to great to rotate it to point at desired targets without a huge energy budget and very heavy duty thrust delivery. A radius is a better idea than a sphere in terms of material; a sphere is better in terms of rigidity but the material costs would be many times that of a radius.
Quickly isn't really a problem from several points of view. First, make more than one. That increases the number of pointings. Second, just wait.:-)
With regard to flexing, that's an engineering challenge, but not one that requires unobtanium. They've already said the idea is to put it where the gravity is lowest; to that, add something that *does* flex and it'll straighten itself out. This is ultra low-g space, remember -- there's no weather, air resistance, etc.
With a system like this, "trivial" is relative. A radius is trivial in terms of material compared to a sphere. A sphere is trivial in terms of rotation, if it's a lightweight manufactured sphere. If the material is manufactured in space, either one would seem to be fairly practical. There are *many* reasons we'd want to be able to manufacture materials in space.
Make a sphere with a central axis. Place the fresnel lens on the surface of the sphere. Rotate the sphere about the center (where the focal point is.) No more formation flying, etc. Since you don't need any part of the sphere but the place where the fresnel lens is, just create a radius - lens at one end, focal point at the other end. Use a track to adjust the focal point distance from the foil. Rotate the entire assembly to re-point. No formation flying. Precision alignment all the time. Slow adjustment means good fuel economy.
It seems to me that this is a great excuse for a foil-making plant in space. Imagine a veewwwwy large foil sheet. Then think of the available resolution. This is better than a dispersed array.
Politicians are free to make any law they want, to screw with us any way they want, and they are completely free from repercussions. They get their money for free by taking it from us, they are free from repercussions if they spend it, and if they seem to be running out, they just take more from us or borrow it (and obligate US to pay it back. They have free parking, too.
I understand perfectly well that it is in Michael Powell's best interests to make such a response, but in the idiotic (and often overwhelming) tide of mommy-government "we know what's best for you" sophism, it is nothing less than delightful to see a vendor actually put up a fight instead of rolling over.
Note to everyone else: If you're a technical person, and you're not familiar with Powell's technical bookstore, you owe it to yourself to at least look around.
My only connection with Powells is that I've bought books from them.
"You have the right to remain silent. If you do, we'll waterboard you until you tell us what we want to hear. Anything you say can be used against you in a court of law, if we decide to let you see a judge. You have the right to speak to an attorney, however, we may or may not let you exercise that right. You have the right to have an attorney present during questioning, but generally speaking, that's unlikely, so forget it. If you cannot afford a lawyer, don't worry about it, because we're unlikely to let you speak to one."
Would a recording outside of the US be viable in a US court?
Do US courts seriously consider these issues any longer? The majority of the constitution is at best nod and wink territory these days. They tap whoever they want; they jail whoever they want; and as for admissible in court, who says it'll even get to court? Who says you'll even get a phone call? This isn't your father's USA.
I'll agree that it's meaningless in the sense you describe, but I'll also add that it's a relatively easily answered question as long as one keeps superstition at bay.
Mathematics is a language, one intentionally of the most precision we can manage. This language is very well able to, and intended to, describe many of the methods and mechanisms of the universe we live in, and is additionally capable of describing things that are abstract and/or impossible.
As a language, it evolves with use, and it maintains consistency with use. It also can lose ideas and dialects.
To get all happy-assed because one has a technically specialized language available is akin to a programmer thinking he is discovering a hitherto unknown facet of the universe because he just learned Python. Fun, interesting, mind-expanding, all that... but not a "connection to a non-physical state." Just a new language.
The universe works in certain ways. Most languages exist to describe those ways, and how we interact with them. Math is one of a very few languages that attempt to do that precisely, and this is both notable and useful, but it isn't magical. Because the goal is to discover how the universe works, and how abstracts perhaps not in the universe might be expressed, we are driven to extend the language. We don't "discover" it, we invent it.
To the extent that we meet our goals -- that is in particular, successfully describe how the universe works -- we can expect that someone or something working elsewhere would come to the same or equivalent conclusions. Because knowing how things work seems to be is so fundamental to our industry and technology, we presume that it would be similarly fundamental to the industry and technology of those "others." If that presumption is correct, then thinking of math as a "universal language" is an idea that has legs; but again, there's nothing magical about it. We can be pretty certain that while another race might know what the idea of "pi" represents, they're not going to call it "pi", it's not that kind of universal.
Math can be expected to be a common ground just as other types of communications and specifications based upon communications are likely to be common ground. Also like metallurgy; chemistry; physics; etc. Not because it's magic, but because the universe offers only certain things to its inhabitants, and as we work with them and extend our knowledge about them, we're going to need very specific ways to describe and represent and work with them. So would anyone else, if they're even remotely similar to us.
So it's invented. But it is invented to describe something that already exists, in many cases, as well as imaginary things conceived by minds conditioned by experience with other things as they exist. That's why some people think math can be described as "discovered"; but they're simply confusing the universe being described with the description. We might discover how orbits work and very precisely describe that orbit with math; but the math for the orbit is not the orbit itself. It's a description; it's language.
I suspect that's mostly because you've not done it. Even in MSVC's ancient development system, building (and modifying) a GUI with menus, widgets, etc is a matter of just a few minutes work, most of which simply generates trivially handled resources. Petzold's books lay it all out for you, among others.
Custom widgetry is more work, but again, you only have to write it once if you write it well, so I've never felt like it was a big deal. For instance, we did our own toolbars long before Windows had toolbar support. That's another reason to do it -- to get functionality that isn't otherwise available.
The vast majority of UI nastiness (that is, the complexity that is the same for everything, as opposed to the stuff you want it to do that's unique to your application) was long ago abstracted into Windows and OS X. Linux... well, Linux not so much. You have to go up a level from Linux into someone's custom widgetry or you *will* be dealing with some low level nastiness.
If I was writing some image manipulation software......the Load/Save/View/whatever parts, I'll do in VB!
Speaking as one of the primary authors (and the system architect) of one of the most powerful of the image manipulation systems presently out there, I think you may have underestimated the need for high speed when drawing, loading and saving image data, particularly compressed image data and layered image data. But best of luck with that, anyway.:-)
...but you will spend a lot more time creating, debugging and maintaining it.
Hmm. Creating, probably so. You're writing smaller steps on a per-keystroke basis, so it's pretty much a given.
Debugging and maintaining, however, are issues more predicated upon design skills than the language used. From things entirely outside the code's executing domain (like comments and other documentation) to things inside (structures and algorithms), correctness (from which depends debugging), reliability (from which depends maintainance) and completeness / applicability (from which also depend maintainance), all these things are independent of the language, except in very minor and essentially irrelevant ways.
I would argue that coding in an HLL does not improve these latter things. However, coding in C brings you extremely close to both the problem(s), and the solution(s) you decide to implement without taking you that last troublesome step down into assembler, where you lose platform independence. I think that is a uniformly positive set of consequences to enjoy as a result of spending that extra time.
It doesn't make sense for the majority of classes of software, from a cost vs. gain perspective, to use C for the job.
Well, we'll have to agree to disagree here. Wasting resources can have unpredictably large effects, such as pushing a system over the edge between running in memory and beginning to swap. The more you waste, the more likely you are to cause such problems.
The fact is, running the user out of resources for no reason other than saving small amounts of my time up front is outside the bounds I am willing to go. The gains at the user's end, especially when multiplied by many users across many invocations, are likely to be substantial. Consequently, the investment on my end is almost certain to be small by comparison, even if it is actually many of my hours.
As a user, I run into this all the time. If I start a certain application, it typically takes quite some time to start. It's the "industry standard", but frankly, it runs like a pig in hip deep dung on every startup. And it eats memory like crazy, even the executable is 4x larger than other apps that do the same thing, but which -- notably -- aren't the "industry standard." So I make the choice, as a user, to use the other apps for all tasks that are achievable either way (and as it turns out, I *very* rarely have to start the industry standard program.) I want my memory to be used for data, not for a bloated application; and I want my time used in working on that data, not waiting to count and register every plugin or aux feature in the system every time the application starts.
The problem is that from the programmer's perspective, "time and effort" are not even slightly the same as they are from the user's perspective. For my part, I consider it an ethical "must-do" to consider the user's perspective as the primary one driving the design. Both from the viewpoint that their resources are not "mine to waste" just because they have extended me the courtesy of allowing my software to run in their machine, but also from the viewpoint that any supposedly "extra" time I spend, I spend once; any time I cost the users unnecessarily, I extract that cost from every user, and every time the software is run.
some one did that for us, so we can all use the same type of thing.
No. They didn't. They implemented something else entirely, something that works outside the paradigm of what you're doing, attempting to track memory use by indirect means (such as counting references.) And this is precisely the problem with such memory management; by taking the programmer out of the management loop and abstracting it into irrelevance, the programmer no longer has either the means or the incentive to keep tight control of resources. The mindset leads to thinking nothing of bringing the entire Python interpreter into memory in order to evaluate a line or two of trivial logic, because its trivially easy to do. Consequently, huge system loads are incurred for relatively small tasks. Write that same logic in C, and you have a dedicated executable that (a) is tiny by comparison, (b) runs orders of magnitude faster, (c) you actually understand on every level. Presuming you don't drag in some huge library you didn't really need or do a really bad job.:-)
Don't get me wrong - I am *not* a Python hater, in fact, it is one of my favorite languages. But I don't use it for everything just because it is easy. I always think about resources used, whose resources they are, whether I have the implicit right to consume them if I don't have to, and if I do have such a right, do I *want* to consume them? After all, they may be mine, and if I'm trying to do something else, some interpreter clumping around in the background consuming large chunks of resources may not be in my best interests. If it is true for me, it's probably true for my customers, so in the end, I have to do the same evaluation for them as well.
Seriously, most people want to sit down and write the logic for their application, not invent (or even copy-paste) memory management schemes.
Yes, I understand that perfectly. I'm a huge fan of Python for that very reason.
However, in C, writing memory management only needs to be done once; while writing the "logic for the[ir] application" is done many times. Consequently, the apparent load of writing memory management is much lighter than one might initially recognize. Or to put it another way, once it's done, it's done and represents no load at all.
Further, there are huge advantages to having 100% control over the memory management of your application; speed advantages, fewer wasted/tied-up resources, and all the downhill consequences of those things -- if you don't waste resources, they're available for the user, or for other aspects of your programs. Likewise, if you get things done faster, more CPU is available elsewhere.
Another thing: Depending on an external agency to manage your resources is a two-edged sword. If there are bugs in *your* code, you can fix them as fast as you are competent to do so. Considering you wrote it in the first place, the presumption that you are competent to fix it is usually on target.
If there are bugs in an external agency, you typically get to report them... and wait, bugs happily chewing on the users of your applications, until said external agency gets around to fixing whatever it was. If indeed they ever do.
Same thing goes for list management, etc. Write it once, learn all about it (which is interesting AND increases your Leet Skillz) and now you have a generally useful tool that is as fast as you can make it, totally amenable to fixes and updates, and invulnerable to the ass-draggery of outside influences. I have used my list management module in AI apps, ray tracers, image processing, file management, and even in dialogs to control layer types in various (what I think are) clever ways. I have huge confidence in it, but, should it turn out to be broken... I could fix it in minutes. At which point every app I've written gains ground, all my customers win, etc.
There's something else that has always remained in the back of my mind. As languages get more sophisticated, there is a trend for them to generate much larger and much slower resulting applications. It isn't uniform, and it depends on what you're doing, compilers as compared to interpreters, etc., but the trend itself is pretty clear. For instance, a Python app seems small, until you realize that the Python interpreter is loaded for your one-liner. C++ apps tend to be huge compared to C apps. And so on.
This trend - basically - tracks the increasing availability of memory and CPU power. Seems reasonable enough. But the funny thing is, if you take an app that was designed to run at adequate speed on hardware from, say, 1992, keep the technology behind the app the same if you update it - that is, keep writing efficient C and so on - then the increase in memory and CPU resources serve to turn the app into some kind of blistering miracle implementation instead of the run of the mill performance you get from depending on the latest and greatest HLL with garbage collection, the implicit inclusion of module after module of object-oriented processing and modeling, data hiding, etc., etc.
Directly related to this is the fact that if you attempt a modern task - such as an image manipulation system - in a modern language, you, as the programmer, can be significantly enabled by the language; that is, you can be done sooner, and you can have a lot of things done, too, many coming along for the ride, for "free." Garbage collection / memory management being one such thing. But if you approach the task using C, which is basically capable of creating as fast an application as you are capable of writing, it is so close to assembly, while we can certainly agree up front it'll take you longer, the end result coul
C is perfectly capable of extremely high-quality memory management with significant ease-of-use. However, you get to create that facility, or of course you can utilize someone else's design if you can locate one that fits your API needs, budget and time frame.
For instance, years ago I faced this issue and wrote a module that ensures there are no leaks in any part of an application I write; I also get over-run and under-run detection, named segments, dual-free attempt capture, memory usage reporting, and more. I have debug and end-user levels for the code so that during development, I get enormous detail, while the end user doesn't see that unless I specifically turn it on for them.
I have both pool and chunk level management; I have both pool and individual "free" levels; all of this in very few K indeed.
C is the perfect language to implement memory management in, in fact, because it has perfect fine-grained control over memory.
That goes for other things as well; C is highly capable if you need to build in certain types of OO; objects with built-in methods and variables can be crafted in seconds, with no waste at all; uniform list handling can be crafted (and is an interesting and useful programming exercise.)
C *could* go away as a result of a generation of programmers who really don't know how to deal with such things, but I think it would be a real loss if it happened. The up side is that it'll take a while. There's a whole generation of us who know C quite well, and we're nowhere near dead yet.;-)
Slashdot Mirror
I insist on bringing non-existence into it because that's the state of evidence for the proposition that there is a god. None. I don't extend belief to propositions that are outside the realm of known physics, have no supporting evidence, and for which the existence of the proposition itself can be explained by mundane, even if relatively unsavory, activities.
In the case of your example, it's entirely possible (re physics), but as it isn't in any way relevant to my life - it's trivial to me - and cannot equally trivially be verified, I won't extend the effort to bring my position on your postulate up to the level of belief. Which leaves me without belief, but not actively disbelieving -- that requires extending almost as much effort as believing. Which would be answer number (4) "have you seen my cat?"
Now, if your story had an out-of-physics qualifier in it: "We had 3-way sex on an inertia-less drive UFO", then I can trivially go straight for lacking belief without hearing any more. I would, I assure you, ask for a ride in the UFO. If you provided it, I'd buy your sex story, as your standard of telling me wild stuff and backing it up would now be world-class.
Likewise, if some religious person tells me there's a god, and he heals people instantly through them, I'd say, ok, here's this person I know who needs healing of the following kind. Heal them. Instantly. If they did so, I would credit the story that it was god, because if there's one thing I'm pretty sure of, it is that humans can't magically heal anything by themselves. Otherwise, I remain without belief in the god-concepts, and still convinced they're just another mundane jackass.
Yes, that would be where your error is, right there.
You're having a conversation right now with a hardline atheist — a fellow completely without belief in a god or gods — who asserts that certain claims of known non-existence of a god or gods are inherently flawed. That's just me; but there are others like me (Just ask here, there are plenty on slashdot) and there are many of other stripes, as well.
I'm hardly neutral; the only social constructs I hold less regard for than individual belief in such stories are the organizations that spread them around, asserting they represent truths.
Let me put it to you this way. Imagine something you consider to be utterly mythological, superstitious, not based in any way upon objective fact. You pick. Easter bunny, Santa, Elves, Astrology, Homeopathy, etc. I'll pick — for me — Astrology. Now, you and I both know, and surely can agree, that there are people out there who believe — and I mean really believe — in astrology. Now, since astrology (or whatever you picked) is definitely a load of ridiculous hokum someone made up and made a system out of, we can also agree that since there is no knowledge to be had about the operation of the mythological effects of the system, that belief can exist without any knowledge of empirical facts at all.
To elaborate, UFO cultists believe in UFOs without ever seeing them. The Heaven's Gate people believed enough to kill themselves. Kids believe in Santa. Some people believe in elves and fairies. Angels. Pick your poison. You should be able to easily identify a case where belief exists without knowledge. You know, facts. Those things that won't go away no matter how much you wish, pray, chant or hide them under crystal pyramids.
Conversely, there are people (let's call them morons, just to keep things honest) who don't hold any belief in evolution as a process. The facts - the knowledge - are that evolution is a repeatable, testable, dependable process that exists and operates irregardless of such beliefs, but nonetheless, these people cling firmly to the lack of belief. To put a fine point on it, they will not believe. This is their position. Again, we see that knowledge is not a prerequisite for belief.
So what we've established here is that belief can exist entirely separate from knowledge, and entirely without it. Belief is a position on a proposition. No more, no less.
Now. Given that this is so — and you know for a fact that of course it is — how is it that you would construct a position that says that a lack of knowledge in and of itself could possibly define a middle ground between belief and lack of belief? Belief is like pregnancy. Either you are, or you aren't. There's no middle ground. If you believe, then you don't lack belief — by definition.
That's why knowledge can't be used to define a presumptive "middle position" between those who hold beliefs and those who don't (on any subject you care to pick.) It is an illusion, at best a social play to avoid the stigma the religious like to attach to the atheists they can identify.
Definitions aside, if you come to me and say "I am agnostic", I will simply look you in the eye and say, "so, do you believe in a god or gods, or do you not?" You can legitimately answer:
Not if there is no evidence of the woman's existence, you can't. You can't have any knowledge at all. All you can have (or not have) is belief; and that's the fulcrum upon which the weights of theism and atheism turn.
That - to be blunt - is poppycock.
Theism is the belief in a god or gods. A-theism is the state of being without belief in a god or gods. Those are the two possible states. Agnosticism addresses why one does, or does not, hold such a belief, that is, whether one has knowledge with regard to the subject sufficient to establish belief — but it does not address whether one holds such a belief.
Knowledge and reasons aside, you're either theist, or atheist. There is no middle state. You can't believe and lack belief at the same time. Either you believe, or you don't. The terms theist and atheist don't delve into why. They simply address your state of belief.
When it comes to why people decide as they do, there are many types of atheist thinking as there are many types of religious thinking. One atheist will tell you the idea is simply ridiculous; another will tell you they see no evidence; another will tell you religion is clearly a control system; another will tell you they "know" there is no god. Theists will tell you god(s) are real within the Christian, Muslim, Hindu, etc. systems and further, within a range of variations within those systems of thought.
Bottom line, you can't be agnostic instead of theist, or atheist. If you say you are, what we take away from your statement is that you're bewildered and don't understand the subject matter.
Sigh. And so it goes.
Reading it, you'd think this would stop the theists from repeatedly dragging the man unwillingly into their camp; but since this well-known remark...
I didn't miss it at all. We build objects of that size here on earth (bridges, for one); there's nothing about this that screams "can't be done." Hard? Sure. Put a few technologies in place - like a space-based materials plant - and it could be *tens* of kilometers times multiple instances and it wouldn't make much difference, other than time.
The problem with using a solid sphere of rock is that the mass is to great to rotate it to point at desired targets without a huge energy budget and very heavy duty thrust delivery. A radius is a better idea than a sphere in terms of material; a sphere is better in terms of rigidity but the material costs would be many times that of a radius.
That's exactly what I meant by radius. A radius is a line equal to the length from the center to the edge of a sphere.
Quickly isn't really a problem from several points of view. First, make more than one. That increases the number of pointings. Second, just wait. :-)
With regard to flexing, that's an engineering challenge, but not one that requires unobtanium. They've already said the idea is to put it where the gravity is lowest; to that, add something that *does* flex and it'll straighten itself out. This is ultra low-g space, remember -- there's no weather, air resistance, etc.
With a system like this, "trivial" is relative. A radius is trivial in terms of material compared to a sphere. A sphere is trivial in terms of rotation, if it's a lightweight manufactured sphere. If the material is manufactured in space, either one would seem to be fairly practical. There are *many* reasons we'd want to be able to manufacture materials in space.
Make a sphere with a central axis. Place the fresnel lens on the surface of the sphere. Rotate the sphere about the center (where the focal point is.) No more formation flying, etc. Since you don't need any part of the sphere but the place where the fresnel lens is, just create a radius - lens at one end, focal point at the other end. Use a track to adjust the focal point distance from the foil. Rotate the entire assembly to re-point. No formation flying. Precision alignment all the time. Slow adjustment means good fuel economy.
It seems to me that this is a great excuse for a foil-making plant in space. Imagine a veewwwwy large foil sheet. Then think of the available resolution. This is better than a dispersed array.
Well, one can hope. :-)
Politicians are free to make any law they want, to screw with us any way they want, and they are completely free from repercussions. They get their money for free by taking it from us, they are free from repercussions if they spend it, and if they seem to be running out, they just take more from us or borrow it (and obligate US to pay it back. They have free parking, too.
Note to self: Buy some more books from Powells.
I understand perfectly well that it is in Michael Powell's best interests to make such a response, but in the idiotic (and often overwhelming) tide of mommy-government "we know what's best for you" sophism, it is nothing less than delightful to see a vendor actually put up a fight instead of rolling over.
Note to everyone else: If you're a technical person, and you're not familiar with Powell's technical bookstore, you owe it to yourself to at least look around.
My only connection with Powells is that I've bought books from them.
You're not keeping up. It used to be "innocent until proven guilty"; Now it is "innocent until arrested, waterboarded until admits guilt."
"You have the right to remain silent. If you do, we'll waterboard you until you tell us what we want to hear. Anything you say can be used against you in a court of law, if we decide to let you see a judge. You have the right to speak to an attorney, however, we may or may not let you exercise that right. You have the right to have an attorney present during questioning, but generally speaking, that's unlikely, so forget it. If you cannot afford a lawyer, don't worry about it, because we're unlikely to let you speak to one."
Do US courts seriously consider these issues any longer? The majority of the constitution is at best nod and wink territory these days. They tap whoever they want; they jail whoever they want; and as for admissible in court, who says it'll even get to court? Who says you'll even get a phone call? This isn't your father's USA.
I'll agree that it's meaningless in the sense you describe, but I'll also add that it's a relatively easily answered question as long as one keeps superstition at bay.
Mathematics is a language, one intentionally of the most precision we can manage. This language is very well able to, and intended to, describe many of the methods and mechanisms of the universe we live in, and is additionally capable of describing things that are abstract and/or impossible.
As a language, it evolves with use, and it maintains consistency with use. It also can lose ideas and dialects.
To get all happy-assed because one has a technically specialized language available is akin to a programmer thinking he is discovering a hitherto unknown facet of the universe because he just learned Python. Fun, interesting, mind-expanding, all that... but not a "connection to a non-physical state." Just a new language.
The universe works in certain ways. Most languages exist to describe those ways, and how we interact with them. Math is one of a very few languages that attempt to do that precisely, and this is both notable and useful, but it isn't magical. Because the goal is to discover how the universe works, and how abstracts perhaps not in the universe might be expressed, we are driven to extend the language. We don't "discover" it, we invent it.
To the extent that we meet our goals -- that is in particular, successfully describe how the universe works -- we can expect that someone or something working elsewhere would come to the same or equivalent conclusions. Because knowing how things work seems to be is so fundamental to our industry and technology, we presume that it would be similarly fundamental to the industry and technology of those "others." If that presumption is correct, then thinking of math as a "universal language" is an idea that has legs; but again, there's nothing magical about it. We can be pretty certain that while another race might know what the idea of "pi" represents, they're not going to call it "pi", it's not that kind of universal.
Math can be expected to be a common ground just as other types of communications and specifications based upon communications are likely to be common ground. Also like metallurgy; chemistry; physics; etc. Not because it's magic, but because the universe offers only certain things to its inhabitants, and as we work with them and extend our knowledge about them, we're going to need very specific ways to describe and represent and work with them. So would anyone else, if they're even remotely similar to us.
So it's invented. But it is invented to describe something that already exists, in many cases, as well as imaginary things conceived by minds conditioned by experience with other things as they exist. That's why some people think math can be described as "discovered"; but they're simply confusing the universe being described with the description. We might discover how orbits work and very precisely describe that orbit with math; but the math for the orbit is not the orbit itself. It's a description; it's language.
That's my take, anyway.
I suspect that's mostly because you've not done it. Even in MSVC's ancient development system, building (and modifying) a GUI with menus, widgets, etc is a matter of just a few minutes work, most of which simply generates trivially handled resources. Petzold's books lay it all out for you, among others.
Custom widgetry is more work, but again, you only have to write it once if you write it well, so I've never felt like it was a big deal. For instance, we did our own toolbars long before Windows had toolbar support. That's another reason to do it -- to get functionality that isn't otherwise available.
The vast majority of UI nastiness (that is, the complexity that is the same for everything, as opposed to the stuff you want it to do that's unique to your application) was long ago abstracted into Windows and OS X. Linux... well, Linux not so much. You have to go up a level from Linux into someone's custom widgetry or you *will* be dealing with some low level nastiness.
Speaking as one of the primary authors (and the system architect) of one of the most powerful of the image manipulation systems presently out there, I think you may have underestimated the need for high speed when drawing, loading and saving image data, particularly compressed image data and layered image data. But best of luck with that, anyway. :-)
O. S M R wolf. C M P N?
Hmm. Creating, probably so. You're writing smaller steps on a per-keystroke basis, so it's pretty much a given.
Debugging and maintaining, however, are issues more predicated upon design skills than the language used. From things entirely outside the code's executing domain (like comments and other documentation) to things inside (structures and algorithms), correctness (from which depends debugging), reliability (from which depends maintainance) and completeness / applicability (from which also depend maintainance), all these things are independent of the language, except in very minor and essentially irrelevant ways.
I would argue that coding in an HLL does not improve these latter things. However, coding in C brings you extremely close to both the problem(s), and the solution(s) you decide to implement without taking you that last troublesome step down into assembler, where you lose platform independence. I think that is a uniformly positive set of consequences to enjoy as a result of spending that extra time.
Well, we'll have to agree to disagree here. Wasting resources can have unpredictably large effects, such as pushing a system over the edge between running in memory and beginning to swap. The more you waste, the more likely you are to cause such problems.
The fact is, running the user out of resources for no reason other than saving small amounts of my time up front is outside the bounds I am willing to go. The gains at the user's end, especially when multiplied by many users across many invocations, are likely to be substantial. Consequently, the investment on my end is almost certain to be small by comparison, even if it is actually many of my hours.
As a user, I run into this all the time. If I start a certain application, it typically takes quite some time to start. It's the "industry standard", but frankly, it runs like a pig in hip deep dung on every startup. And it eats memory like crazy, even the executable is 4x larger than other apps that do the same thing, but which -- notably -- aren't the "industry standard." So I make the choice, as a user, to use the other apps for all tasks that are achievable either way (and as it turns out, I *very* rarely have to start the industry standard program.) I want my memory to be used for data, not for a bloated application; and I want my time used in working on that data, not waiting to count and register every plugin or aux feature in the system every time the application starts.
The problem is that from the programmer's perspective, "time and effort" are not even slightly the same as they are from the user's perspective. For my part, I consider it an ethical "must-do" to consider the user's perspective as the primary one driving the design. Both from the viewpoint that their resources are not "mine to waste" just because they have extended me the courtesy of allowing my software to run in their machine, but also from the viewpoint that any supposedly "extra" time I spend, I spend once; any time I cost the users unnecessarily, I extract that cost from every user, and every time the software is run.
What? Where's a wolf?
No. They didn't. They implemented something else entirely, something that works outside the paradigm of what you're doing, attempting to track memory use by indirect means (such as counting references.) And this is precisely the problem with such memory management; by taking the programmer out of the management loop and abstracting it into irrelevance, the programmer no longer has either the means or the incentive to keep tight control of resources. The mindset leads to thinking nothing of bringing the entire Python interpreter into memory in order to evaluate a line or two of trivial logic, because its trivially easy to do. Consequently, huge system loads are incurred for relatively small tasks. Write that same logic in C, and you have a dedicated executable that (a) is tiny by comparison, (b) runs orders of magnitude faster, (c) you actually understand on every level. Presuming you don't drag in some huge library you didn't really need or do a really bad job. :-)
Don't get me wrong - I am *not* a Python hater, in fact, it is one of my favorite languages. But I don't use it for everything just because it is easy. I always think about resources used, whose resources they are, whether I have the implicit right to consume them if I don't have to, and if I do have such a right, do I *want* to consume them? After all, they may be mine, and if I'm trying to do something else, some interpreter clumping around in the background consuming large chunks of resources may not be in my best interests. If it is true for me, it's probably true for my customers, so in the end, I have to do the same evaluation for them as well.
Yes, I understand that perfectly. I'm a huge fan of Python for that very reason.
However, in C, writing memory management only needs to be done once; while writing the "logic for the[ir] application" is done many times. Consequently, the apparent load of writing memory management is much lighter than one might initially recognize. Or to put it another way, once it's done, it's done and represents no load at all.
Further, there are huge advantages to having 100% control over the memory management of your application; speed advantages, fewer wasted/tied-up resources, and all the downhill consequences of those things -- if you don't waste resources, they're available for the user, or for other aspects of your programs. Likewise, if you get things done faster, more CPU is available elsewhere.
Another thing: Depending on an external agency to manage your resources is a two-edged sword. If there are bugs in *your* code, you can fix them as fast as you are competent to do so. Considering you wrote it in the first place, the presumption that you are competent to fix it is usually on target.
If there are bugs in an external agency, you typically get to report them... and wait, bugs happily chewing on the users of your applications, until said external agency gets around to fixing whatever it was. If indeed they ever do.
Same thing goes for list management, etc. Write it once, learn all about it (which is interesting AND increases your Leet Skillz) and now you have a generally useful tool that is as fast as you can make it, totally amenable to fixes and updates, and invulnerable to the ass-draggery of outside influences. I have used my list management module in AI apps, ray tracers, image processing, file management, and even in dialogs to control layer types in various (what I think are) clever ways. I have huge confidence in it, but, should it turn out to be broken... I could fix it in minutes. At which point every app I've written gains ground, all my customers win, etc.
There's something else that has always remained in the back of my mind. As languages get more sophisticated, there is a trend for them to generate much larger and much slower resulting applications. It isn't uniform, and it depends on what you're doing, compilers as compared to interpreters, etc., but the trend itself is pretty clear. For instance, a Python app seems small, until you realize that the Python interpreter is loaded for your one-liner. C++ apps tend to be huge compared to C apps. And so on.
This trend - basically - tracks the increasing availability of memory and CPU power. Seems reasonable enough. But the funny thing is, if you take an app that was designed to run at adequate speed on hardware from, say, 1992, keep the technology behind the app the same if you update it - that is, keep writing efficient C and so on - then the increase in memory and CPU resources serve to turn the app into some kind of blistering miracle implementation instead of the run of the mill performance you get from depending on the latest and greatest HLL with garbage collection, the implicit inclusion of module after module of object-oriented processing and modeling, data hiding, etc., etc.
Directly related to this is the fact that if you attempt a modern task - such as an image manipulation system - in a modern language, you, as the programmer, can be significantly enabled by the language; that is, you can be done sooner, and you can have a lot of things done, too, many coming along for the ride, for "free." Garbage collection / memory management being one such thing. But if you approach the task using C, which is basically capable of creating as fast an application as you are capable of writing, it is so close to assembly, while we can certainly agree up front it'll take you longer, the end result coul
Hunter you may be; reader, you are not. "single", not "silver."
C is perfectly capable of extremely high-quality memory management with significant ease-of-use. However, you get to create that facility, or of course you can utilize someone else's design if you can locate one that fits your API needs, budget and time frame.
For instance, years ago I faced this issue and wrote a module that ensures there are no leaks in any part of an application I write; I also get over-run and under-run detection, named segments, dual-free attempt capture, memory usage reporting, and more. I have debug and end-user levels for the code so that during development, I get enormous detail, while the end user doesn't see that unless I specifically turn it on for them.
I have both pool and chunk level management; I have both pool and individual "free" levels; all of this in very few K indeed.
C is the perfect language to implement memory management in, in fact, because it has perfect fine-grained control over memory.
That goes for other things as well; C is highly capable if you need to build in certain types of OO; objects with built-in methods and variables can be crafted in seconds, with no waste at all; uniform list handling can be crafted (and is an interesting and useful programming exercise.)
C *could* go away as a result of a generation of programmers who really don't know how to deal with such things, but I think it would be a real loss if it happened. The up side is that it'll take a while. There's a whole generation of us who know C quite well, and we're nowhere near dead yet. ;-)