how many other university satellites are going to be put up?
Uh, I hate to break it to you, but there are already a bunch up there. And more on the way. In the US alone, Stanford has launched a couple of satellites (Sapphire being the only one I can remember off the top of my head), Utah State & Weber State have launched one (NUsat), the Air Force Academy has put up several (FalconSat), and the University of Colorado has launched at least one (SNOE) - I've probably missed a bunch because I'm doing this oof the top of my head. The Air Force and Naval Academies have several student-built satellites manifested already. There a bunch of schools building CubeSats. And around a dozen schools competing in the NASA/AFRL University Nanosat competition.
Outside the US, a number of European universities have worked on CubeSats, the University of Stellanbosch in South Africa has done one or two satellites, and, of course, the University of Surrey (and their spinoff Surrey Satellite Technologies Ltd) have launched around 25 satellites in the last 20 years. Again, I've probably missed a bunch that I can't remember right now - these are just the ones that immediately leap to mind.
When I open a Word document with my course assignment instructions, OOO displays it without all the numbering, ie:
Numbered lists are read fine in both OO.o Writer and abiword.
Are you saying that the parent post is lying? Because otherwise your assertion is contradicted by the very statement you are replying to. Personally, I don't think the parent post is a lie, since I've experienced the same problem myself on occasion. So I guess numbered lists are not "read fine" after all...
n my experience static vs. dynamic typing is really a matter of how well I've managed to nail down exactly what sorts of data structures I'm going to use. If I'm still doing exploratory/prototype/research code then dynamic types win out every time because they provide incredible flexibility. If I have nailed down what data structures I want to use then static types aren't any extra work and provide and extra buffer of safety.
Actually, I'd argue that static type checks are just as valuable during prototyping. They force the compiler to check the sanity of the data structures and functions you've put together. If you've written a new function that's trying to do something incompatible with the data structure you've already defined the compiler will flag that immediately. Then you can evaluate whether you need to modify the data structure definition or the function in question. Without a static type check you may end up with something that passes your unit tests, but doesn't truly represent your intentions once it hits corner cases (not that you can't end up in that boat even using static checks, but it's less likely).
I should probably point out here that I'm thinking in terms of development using a type-inferred language (Haskell, ML, etc) in which static typying is not so cumbersome.
Eh? I've seen all sorts of "static language people" complain about C's weak typing. Of course, these folks tend to be Haskell or SML users rather than C users, so they actually have some idea of what constitutes "strong" typing (as well as static typing).
Now, you will see some theoretical CS types argue that dynamic typing doesn't constitute typing at all, i.e. that tagged values are not the same as types in a type-theoretical sense. However, I've never heard any of them claim that C is strongly typed either.
Well, Stackless itself implements "tasklets" (lightweight threads) using a round-robin scheduler (which does not schedule tasks that are blocked on channel communications) - see here for more. This approach was apparently heavily influenced by things like CSP and occam.
I have to admit that I'm not clear on what the original article means when they talk about using non-preemptive multithreading (do they mean somehow overriding the Stackless tasklet scheduler?). They seem to be worried about the need for locks on shared-state variables. However, the correct approach to building a Stackless-based system would probably be to follow the CSP paradigm of avoiding shared-state completely - such systems are lock-free and can be completely deterministic. But perhaps I am completely misinterpreting what they are trying to get at.
There is some similarity, but perhaps not as much as you think. Dataflow programs are essentially composed of stateless filters which accept inputs and transform them into outputs. CSP-like languages, such as Stackless, implement concurrent processes that can retain state, and exhibit reactive behavior (i.e. an "actors" model of computation rather than a "filters" model).
Note that it is possible to implement a state-free, dataflow-style program using a CSP-like language. But the stateful style is much more common (and has obvious relevance to game scripting).
Multithreading in Lua is easy. Lua provides the coroutine facility.
Coroutines are not the same as threads. Coroutines provide what is essentially sequentially executed (i.e. single-threaded) functions with preserved state between function calls. This is not at all the same as the interleaved execution of mutliple threads of control that a truly concurrent system provides. Please do not conflate the two.
It's not creating a totally new system: we already have nation-wide systems for national ID, criminal records, taxes etc anyway.
I hate argments like this. It's the same kind of argument that's used to push the USA-PATRIOT act: these aren't new capabilities - we already use them against drug dealers, now we're just expanding to use them against "terrorists" too. No one stops to ask whether the precedent-setting actions against drug dealers (or the precedent-setting government collection of data in your case) was actually right to begin with (in the case of anti-drug laws in the US, most people had no idea that such laws had been passed). Nor is it a valid argument to say "we already do a, b, and c, so there's no harm in doing d". Action d may very well be the proverbial straw that breaks the camel's back.
I'm not sure about the others, but it wouldn't surprise me if Suharto in Indonesia was focused on the East Timorese "terrorists" (one man's terrorist is another man's freedom fighter).
I'd love to see a language (or language extension) cleanly define a way to let me define a code block attributes which could affect how and where it gets executed.
The venerable occam programming language requires that each block of code be specifically identified as being executable either in parallel or sequentially. Since PAR and SEQ constructs can be nested it is easy to build up quite complex concurrent structures that can easily be distributed. Since the semantics of occam processes are derived from Hoare's CSP process algebra the compositional nature of occam's parallelism is theoretically sound, and avoids many of the problems associated with thread-based concurrency model that most people are familiar with.
Please do not confuse the policies of libertarians (small 'l') in general with those of the Libertarian Party (big 'L'). There is a far wider range of libertarian thought than that represented by the LP.
Just as one example, there are some libertarians who argue that corporations themselves represent an unwanted government interference in "the market" (since they are purely a legal fiction anyway). Those libertarians are hardly likely to "reduce or eliminate the last remaining restraints on multi-national corporations" - they're more likely to elimnate the laws that allow corporations to exist in the first place.
That's in interestingly warped view of libertarianism you have there. Actually, it's Objectivists who object to "altruism" (although it's not clear to me that what they mean by "altruism" would necessarily include fee-free lifts off of roofs during an emergency situation). Now, while there is some overlap between Objectivists and libertarians, it is by no means true that all libertarians are Objectivists (or that all Objectivists are libertarians, or even that all Objectivists object to "altruism").
Actually, the best commercially available space-ready solar cells operate at around 28% efficiency these days. Rumor has it that there are 30-35% efficient cells in the lab right now. Of course, none of that invalidates your basic point...
This is occurring in North America, which somehow makes it news(?)
Of course, there have been plenty of micro- and nano-sat's in the US too... the CubeSat community has been doing stuff like this for years, and NASA/AFRL have sponsored the University Nanosat competition for the last several years. Not to mention NASA projects like the ST-5 nanosat constellation pathfinder, or Air Force projects like PICOsat.
Not that what the CanX team are doing isn't cool. But they're just one member of a much larger community of smallsat developers that get hardly any PR. One of the best resources for seeing what the small/micro/nano-sat community is up to is the annual SmallSat conference.
You might start here. Lots of other books will tell you how to use semaphores and mutexes. This book will help you to understand why to use semaphores and mutexes (and perhaps open your eyes to better concurrency constructs), and teach you how to reason about your multithreaded design so that you won't get any nasty surprises when it comes time to run it.
Apple is neither a hardware company nor a software company. What Apple sells is user experiences. Apple users don't buy a computer, or a piece of software, they buy an integrated product that lets them get the things done that they want to get done ("It Just Works"(TM)). Both the hardware and the software are integral pieces of that product, and neither is complete without the other.
As I said before, I don't believe that graphics should be excluded completely from specification. Simply that care needs to be taken in their use, so that secondary cues do not lead to a specification that is more confusing rather than less so.
With regard to debugging, I agree that graphics can provide useful contextual information. But that doesn't necessarily mean that they should be the primary reference - they can simply be a visual aid.
I'll also add that (a) Oleg makes some good points in response to Frank's comment, and (b) in many of Frank's more recent comments on LtU I've got the impression that he now favors textual languages over graphical ones.
Math has nothing to do with it. COSA solves the nastiest problem of complex software programs: blind code or unresolved data dependencies. That is, something is modified in one part of the program unbeknownst to another. This makes it almost impossible to modify complex code without introducing dangerous and unforeseen side effects.
Math has everything to do with it. The COSA approach appears to be rest on the notion of reducing everything to the simplest possible (correct-by-inspection) components, and then building a system from them and assuming that it will be correct. This is a fundamentally flawed approach, for the simple reason that a system is more than the sum of its parts: it also consists of the interfaces between those parts. While individual COSA components may be understandable and reliable, the emergent behavior of the complete system will be difficult or impossible to comprehend in any non-trivial system. The COSA website makes several references to the successes of the integrated circuit industry. However, the IC industry is facing the same difficulties with emergent behavior, which is why they are gravitating towards math: specifically, formal verification techniques using higher-order logic, temporal logic, and model-checking. Math is the key to building complex systems.
The second greatest cause of unreliability is non-deterministic timing. COSA solves this problem through synchronicity.
COSA can provide deterministic timing wrt when a state transition occurs. But I didn't see anything on the website that demonstrated how it would achieve the deterministic occurence of a specific state. Again, that would (IMHO) require you to have a good understanding of the emergent behavior of your COSA program. If I'm missing something there, please point it out.
COSA is revolutionary because it guarantees 100% reliability.
That's nice. How exactly does it "guarantee" such reliability? I fail to see anything in the COSA model that (a) prevents programmer error, or (b) provides a way to verify that a program actually does what it's supposed to (aside from inspection, which I'm afraid simply isn't acceptable for the kind of highly concurrent designs that COSA encourages).
Academia has turned software construction into a complete babelized mess over the last fifty years.
Ah. So instead of learning from those who have gone before (and who are, incidentally, working hard to unify their theoretical work even as I write this) you prefer to reinvent the wheel, and to do so badly. Good plan.
COSA is trying to be as simple as possible. The COSA motto is: If it is not simple, it's wrong.
Nothing wrong with that. The question is whether that approach can successfully scale to systems that are a complex aggregation of simple parts (which appears to be what COSA programs are intended to be). Those kind of systems are where the math (such as CSP or CCS) becomes invaluable.
Why not have the specification be primarily graphical, as in interface builders, flowcharts and object relationship diagrams, then go directly to a low-level representation such as object code, machine language or bytecode with no traditional semi-readable character-based language at all?
Possibly because empirical studies (such as those summarized in Marian Petre's "Why looking isn't always seeing: readership skills and graphical programming" [Communications of the ACM, Volume 38, Issue 6 (June 1995), Pages: 33 - 44]) have demonstrated that graphical languages are actually worse for user comprehension than textual languages (the results are true for both novice and expert users). A large part of this has to do with the secondary cues (i.e. layout-based cues) embedded in the graphical representations. You can always read text serially. Reading a diagram on the other hand requires an inspection strategy. Some key quotes from Petre's paper:
"It is worth noting that expertise cannot compensate for everything. Graphics was uniformly slower than text; it is apparent that even the expert reader of graphical notations is doing a hard job.... One of the distinctions between expert and novice behavior was that the experts made better use of their fingers, occasionally using all ten to mark points along a circuit."
"When comparable graphical and textual representations were presented side-by-side, experienced readers nearly always used the text to guide their reading of the graphics."
Note that I'm not trying to claim that there's no place for graphical elements within a specification. Simply that those elements need to be carefully used and probably quite limited in their application (a good example might be the schema boxes that are typically used in Z specs - they make things much more clear, without introducing secondary cues that can be confusing).
Slashdot Mirror
Uh, I hate to break it to you, but there are already a bunch up there. And more on the way. In the US alone, Stanford has launched a couple of satellites (Sapphire being the only one I can remember off the top of my head), Utah State & Weber State have launched one (NUsat), the Air Force Academy has put up several (FalconSat), and the University of Colorado has launched at least one (SNOE) - I've probably missed a bunch because I'm doing this oof the top of my head. The Air Force and Naval Academies have several student-built satellites manifested already. There a bunch of schools building CubeSats. And around a dozen schools competing in the NASA/AFRL University Nanosat competition.
Outside the US, a number of European universities have worked on CubeSats, the University of Stellanbosch in South Africa has done one or two satellites, and, of course, the University of Surrey (and their spinoff Surrey Satellite Technologies Ltd) have launched around 25 satellites in the last 20 years. Again, I've probably missed a bunch that I can't remember right now - these are just the ones that immediately leap to mind.
That horse has left the barn already.
Actually, I'd argue that static type checks are just as valuable during prototyping. They force the compiler to check the sanity of the data structures and functions you've put together. If you've written a new function that's trying to do something incompatible with the data structure you've already defined the compiler will flag that immediately. Then you can evaluate whether you need to modify the data structure definition or the function in question. Without a static type check you may end up with something that passes your unit tests, but doesn't truly represent your intentions once it hits corner cases (not that you can't end up in that boat even using static checks, but it's less likely).
I should probably point out here that I'm thinking in terms of development using a type-inferred language (Haskell, ML, etc) in which static typying is not so cumbersome.
Now, you will see some theoretical CS types argue that dynamic typing doesn't constitute typing at all, i.e. that tagged values are not the same as types in a type-theoretical sense. However, I've never heard any of them claim that C is strongly typed either.
I have to admit that I'm not clear on what the original article means when they talk about using non-preemptive multithreading (do they mean somehow overriding the Stackless tasklet scheduler?). They seem to be worried about the need for locks on shared-state variables. However, the correct approach to building a Stackless-based system would probably be to follow the CSP paradigm of avoiding shared-state completely - such systems are lock-free and can be completely deterministic. But perhaps I am completely misinterpreting what they are trying to get at.
Note that it is possible to implement a state-free, dataflow-style program using a CSP-like language. But the stateful style is much more common (and has obvious relevance to game scripting).
Coroutines are not the same as threads. Coroutines provide what is essentially sequentially executed (i.e. single-threaded) functions with preserved state between function calls. This is not at all the same as the interleaved execution of mutliple threads of control that a truly concurrent system provides. Please do not conflate the two.
I hate argments like this. It's the same kind of argument that's used to push the USA-PATRIOT act: these aren't new capabilities - we already use them against drug dealers, now we're just expanding to use them against "terrorists" too. No one stops to ask whether the precedent-setting actions against drug dealers (or the precedent-setting government collection of data in your case) was actually right to begin with (in the case of anti-drug laws in the US, most people had no idea that such laws had been passed). Nor is it a valid argument to say "we already do a, b, and c, so there's no harm in doing d". Action d may very well be the proverbial straw that breaks the camel's back.
I'm not sure about the others, but it wouldn't surprise me if Suharto in Indonesia was focused on the East Timorese "terrorists" (one man's terrorist is another man's freedom fighter).
The venerable occam programming language requires that each block of code be specifically identified as being executable either in parallel or sequentially. Since PAR and SEQ constructs can be nested it is easy to build up quite complex concurrent structures that can easily be distributed. Since the semantics of occam processes are derived from Hoare's CSP process algebra the compositional nature of occam's parallelism is theoretically sound, and avoids many of the problems associated with thread-based concurrency model that most people are familiar with.
Well, OCaml and Haskell for starters.
Just as one example, there are some libertarians who argue that corporations themselves represent an unwanted government interference in "the market" (since they are purely a legal fiction anyway). Those libertarians are hardly likely to "reduce or eliminate the last remaining restraints on multi-national corporations" - they're more likely to elimnate the laws that allow corporations to exist in the first place.
That's in interestingly warped view of libertarianism you have there. Actually, it's Objectivists who object to "altruism" (although it's not clear to me that what they mean by "altruism" would necessarily include fee-free lifts off of roofs during an emergency situation). Now, while there is some overlap between Objectivists and libertarians, it is by no means true that all libertarians are Objectivists (or that all Objectivists are libertarians, or even that all Objectivists object to "altruism").
Actually, the best commercially available space-ready solar cells operate at around 28% efficiency these days. Rumor has it that there are 30-35% efficient cells in the lab right now. Of course, none of that invalidates your basic point...
This is occurring in North America, which somehow makes it news(?)
Of course, there have been plenty of micro- and nano-sat's in the US too... the CubeSat community has been doing stuff like this for years, and NASA/AFRL have sponsored the University Nanosat competition for the last several years. Not to mention NASA projects like the ST-5 nanosat constellation pathfinder, or Air Force projects like PICOsat.
Not that what the CanX team are doing isn't cool. But they're just one member of a much larger community of smallsat developers that get hardly any PR. One of the best resources for seeing what the small/micro/nano-sat community is up to is the annual SmallSat conference.
See also OS X, and the nifty Preview.app
But apparently not because of superior ability to spell, or even mundane ability to use a spell-checker.
You might start here. Lots of other books will tell you how to use semaphores and mutexes. This book will help you to understand why to use semaphores and mutexes (and perhaps open your eyes to better concurrency constructs), and teach you how to reason about your multithreaded design so that you won't get any nasty surprises when it comes time to run it.
Do you mean "glaciers"? Or is a "gletcher" some kind of large arctic animal I've never heard of?
Apple is neither a hardware company nor a software company. What Apple sells is user experiences. Apple users don't buy a computer, or a piece of software, they buy an integrated product that lets them get the things done that they want to get done ("It Just Works"(TM)). Both the hardware and the software are integral pieces of that product, and neither is complete without the other.
With regard to debugging, I agree that graphics can provide useful contextual information. But that doesn't necessarily mean that they should be the primary reference - they can simply be a visual aid.
I'll also add that (a) Oleg makes some good points in response to Frank's comment, and (b) in many of Frank's more recent comments on LtU I've got the impression that he now favors textual languages over graphical ones.
Math has everything to do with it. The COSA approach appears to be rest on the notion of reducing everything to the simplest possible (correct-by-inspection) components, and then building a system from them and assuming that it will be correct. This is a fundamentally flawed approach, for the simple reason that a system is more than the sum of its parts: it also consists of the interfaces between those parts. While individual COSA components may be understandable and reliable, the emergent behavior of the complete system will be difficult or impossible to comprehend in any non-trivial system. The COSA website makes several references to the successes of the integrated circuit industry. However, the IC industry is facing the same difficulties with emergent behavior, which is why they are gravitating towards math: specifically, formal verification techniques using higher-order logic, temporal logic, and model-checking. Math is the key to building complex systems.
The second greatest cause of unreliability is non-deterministic timing. COSA solves this problem through synchronicity.
COSA can provide deterministic timing wrt when a state transition occurs. But I didn't see anything on the website that demonstrated how it would achieve the deterministic occurence of a specific state. Again, that would (IMHO) require you to have a good understanding of the emergent behavior of your COSA program. If I'm missing something there, please point it out.
That's nice. How exactly does it "guarantee" such reliability? I fail to see anything in the COSA model that (a) prevents programmer error, or (b) provides a way to verify that a program actually does what it's supposed to (aside from inspection, which I'm afraid simply isn't acceptable for the kind of highly concurrent designs that COSA encourages).
Academia has turned software construction into a complete babelized mess over the last fifty years.
Ah. So instead of learning from those who have gone before (and who are, incidentally, working hard to unify their theoretical work even as I write this) you prefer to reinvent the wheel, and to do so badly. Good plan.
COSA is trying to be as simple as possible. The COSA motto is: If it is not simple, it's wrong.
Nothing wrong with that. The question is whether that approach can successfully scale to systems that are a complex aggregation of simple parts (which appears to be what COSA programs are intended to be). Those kind of systems are where the math (such as CSP or CCS) becomes invaluable.
Possibly because empirical studies (such as those summarized in Marian Petre's "Why looking isn't always seeing: readership skills and graphical programming" [Communications of the ACM, Volume 38, Issue 6 (June 1995), Pages: 33 - 44]) have demonstrated that graphical languages are actually worse for user comprehension than textual languages (the results are true for both novice and expert users). A large part of this has to do with the secondary cues (i.e. layout-based cues) embedded in the graphical representations. You can always read text serially. Reading a diagram on the other hand requires an inspection strategy. Some key quotes from Petre's paper:
Note that I'm not trying to claim that there's no place for graphical elements within a specification. Simply that those elements need to be carefully used and probably quite limited in their application (a good example might be the schema boxes that are typically used in Z specs - they make things much more clear, without introducing secondary cues that can be confusing).