Science is only science when someone can perform an experiment and observe results that coincide with their hypothesis.
Er... no. Or rather, yes, but with the caveat that "experiment" doesn't necessarily mean "something done in a lab". One proposes a hypothesis that can explain existing observations. That hypothesis is then tested, by using it to make predictions about future observations (which may or may not be produced by an experiment in the lab). If the predictions are found to be correct, then the hypothesis gains credence (but isn't considered "proved"). If at any point new observations are found which contradict the hypothesis, then it is discarded or revised.
As an example of science that does not involve lab experiments, consider Kepler's laws of orbital motion. Kepler hypothesized his "laws" based on the excruciatingly detailed observations of Tycho Brahe. Obviously, performing a lab experiment to confirm the laws is rather difficult (hard to fit even Mercury in the lab, let alone the Sun). Instead, Kepler used his "laws" to make predictions about the future motion of the planets. Later observations bore out his hypothesis, and the "laws" gained credence. Note that Kepler's laws are now widely accepted (Google for "Keplerian orbit"), but have never been tested via laboratory experiment. The closest we've come to "experimental" verification is the launch of artificial satellites, starting in the 1950s. But Kepler's laws were commonly accepted long before then, on the basis of observations of planetary motion (and later, as the result of Newton's demonstration that an inverse square gravitational force would result in Keplerian orbits).
Evolution is much the same. A large number of observations (both fossil records, and studies of existing flora and fauna) pointed to some kind of evolution occurring. Darwin's big contribution was to develop an explanation for the mechanism by which evolution occurs (i.e. natural selection) - a contribution more akin to Newton's development of gravitational theory than to Kepler's purely descriptive laws of orbital motion. Darwin's theories were lent credence as a result of both later field and fossil observations, which were found to follow the pattern predicted by Darwin's theory. Of course, like Newton, it was eventually found that the original version of Darwin's theory wasn't perfect, and evolutionary theory has...well...evolved, in much the same way that Newtonian mechanics has given way to relativistic mechanics. But evolutionary theory is on as firm a scientific footing as any other branch of science (and firmer than some).
...but for the most part I think we operate by assumptions...
Right. And that's a huge source of bugs. Bad assumptions, or assumptions that get violated during some calls are precisely the kind of things that produce produce behavioral errors. What DbC lets you do is state your assumptions, and do so in a format that is automatically checkable (either statically or at runtime). Note that you don't have to write contracts. But if, as you're coding, you realize that you're making a particular assumption about a precondition to the call, or that you intend to guarantee some kind of postcondition, you might as well encode those assumptions and intentions as a contract.
I am just doing it!! I am NOT thinking about pre/post conditions such as "loan amount > zero"
<sarcasm>Yes, god forbid anyone should actually think about what they're coding before they start cutting code. That would be a recipe for disaster...</sarcasm> That said, again, you don't have to write contracts. Just as you don't have to write unit tests. But both things are good practices that are going to help you find bugs.
Secondly, in real systems that much of the code just doesn't lend it self to being described by pre/post conditions.... Subscriptions.get_expired()... Seems pretty straightforward, get me a collection of expired Subscriptions...What kind of Contract would I use....
I could just as well say: "...in real systems much of the code just doesn't lend it self to being checked by unit tests.... Subscriptions.get_expired()... Seems pretty straightforward, get me a collection of expired Subscriptions...What kind of unit test would I use...." Seriously, stop and think about what kind of unit tests you would define for Subscriptions.get_expired(), and you're likely to be well on your way to figuring out what the preconditions (if any) and postconditions of the operation are.
What's easier than typing '#' followed by a comment?
Heh. Took me a moment to realize that you weren't talking about preprocessor #defines there:-) Why that's relevant will become obvious shortly. Anyway, I'd posit that typing '//', '--', or '%', followed by a comment is about as easy.
As for whether comments are "easier" than contracts, it depends on (as I said before) your application domain, and also what your timescale and environment is like. Example: I recently wrote some code in which I encoded some constraints on values as preprocessor #if statements (kind of an ad hoc static type system, since I couldn't say what I needed to within the standard C type system, and other languages are not an option at this point). Now, I could have just written some comments describing the constraints. In fact, that's initially what I did. But then I realized that encoding them as "contracts" of a sort ensures that neither I (working at some distant time in the future), nor another coder working on the same code-base, can inadvertently break the constraints without generating a compiler error. The comments are still there, to explain what's going on. But in the long term, it's "easier" to provide assurance that the program will work as intended by having a compile-time check which ensures that I or someone else can't alter the code in a way that violates the assumptions which underly the operation of the program than it is to provide some kind of external social guarantee that every coder working on the code in question will be careful enough to avoid violating constraints.
Type safety just isn't worth all this effort. Duck typing is fine by me.
Whether or not the effort of type-safety is worth it largely depends on your application domain. Duck typing may be fine by you, but for embedded code in a mission-critical application static type-checking buys you a lot of peace of mind.
That said, DbC is not the same as type safety. It provides both less (runtime checks only), and more (much more expressive constraints). Of course, some DbC systems do provide static checking of contracts as well. But the result is (with the possible exception of Eiffel) layered on top of the type system of the language, rather than being integrated with it.
And most competent developers do it anyway, in the way I've described.
So why not give them tools to make the job easier? You can do OO in C, but it's much easier in a language designed to support objects. Similarly, while it's possible to do ad hoc DbC in most languages, it becomes much easier if you have tools and facilities in place to support it.
Actually, you can perform quicksort on linked lists. But without random access, many of the optimizations you can use to make quicksort really "quick" can't be done, so there isn't much reason to prefer quicksort over a good mergesort implementation for linked lists.
Even with code libraries it isn't as if one can order a window in a standard size, an 8 foot 2 by 4, or pvc pipe.
But I can order (just from the C standard library) a generic quicksort implementation, and IEEE floating-point math. Better than having to implement all that stuff from scratch every time. Not to mention the fact that the C language itself embodies prebuilt constructs like for- and while-loops, switch-case statements, and other "standard components" of structured programming. Or that you can readily buy or download C libraries to do all sorts of other useful tasks. The "standard library" for Java includes implementations of various classic dynamic data structures, implementations of fairly standard compression algorithms (zip), and a variety of other goodies.
It is like saying: "Well, we need some pipe here, so lets find some polyvinyl chloride (or worse, how do we make polyvinal chloride, lets get a chem e and the chemicals and make it) and the tools needed to heat it and shape it into pipe. And we need some wood, so lets go grow a tree, cut it down and mill it." The tree and the polyvinyl chloride are about the best level of APIs, libraries etc. And the code between is at the atom/molecule level.
Hardly. Few projects are built entirely from raw assembler (atoms and molecules) these days. Most leverage, at minimum, a high-level language of some description, and probably an associated standard library. The combination of which provides the equivalent of raw materials like beams and pipes. Depending on the frameworks, libraries, and applications you're building upon, modern application development can be more like assembling prefab walls and roofs than assembling molecules - building a webapp with Ruby on Rails leverages the Rails framework, Ruby itself, existing database software, and existing web server software. All highly complex "building materials" that provide huge amounts of functionality, none of which you have to build from scratch.
And then there is the issue of the foundation of the "house" varying by the OS, compiler etc all in very slight ways.
Right. Because every house is built on perfectly flat ground, with an identical mineral composition, water content, and climate to the location of every other house. No problems with changing environments there at all. If only the software industry had it that easy...
CS/Comp Engineering is making progress, but it is highly complex and as if we were creating the construction industry, but starting it from the basic building blocks of chemsitry(sic) and physics level.
Again, hardly. Software development is certainly less mature than the construction industry, but it's nowhere near as primitive as you are trying to make out. I think you are overstating the complexity of software development, and underestimating just how complex design tasks in other disciplines are (have you ever actually looked at how complex the design of, say, a modern aircraft actually is?).
Re:Becuase People don't know what they want!
on
Why Software is Hard
·
· Score: 1
Your step one in "building a house" can go through all 6 of the steps that you have listed for software development. We get hired by clients, sometimes they have a good idea what they want, sometimes they don't. Sometimes what they want is feasible, sometimes it isn't. It's not unusual for even smaller projects to drag on for years, because the client keeps changing his/her mind. Many projects that cross our desks will never be built.
The same is true of engineering. I've worked in the space industry, both on projects that have never got beyond paper studies, and projects that have successfully landed on Mars. In every case, we went through "all 6 steps" long before we got to "bending metal" (for those projects that got that far). For some reason, some software people seem to have an oddly idealized conception of how design is carried out in other, non-software industries. We all have to deal with the same kind of problems - I'm now working as a software engineer, and my experiences with the design process there seem little different than what I saw when I was working as a spacecraft engineer.
CSP is a big help, but it's no silver bullet. With discipline and a well-designed division of responsibilities into processes, concurrency can be manageable and even very pleasant (I really enjoy it), but that's not at all the same as saying that it's easy.
Amen to that. I really enjoy programming using CSP or Actor-style concurrency. Using those kinds of concurrency models is certainly far easier than programming using a shared-state thread model. But that isn't the same as being "easy" - you still need to think about the design of the system, and take care with the way processes interact. One of the more complex highly-concurrent systems that I've developed was an occam program with around 1,000+ interacting concurrent processes organized with a dynamically changing communications topology. It worked extremely well. Partly because the interactions were carefully designed, and in some cases modelled and verified (and fixed!) using CSP before I wrote a single line of occam.
Purely Functional Programming...is the only way we are going to take advantage of multi-core cpu's and continue to improve our software.
Er... not really. The occam was very successfully doing the multicore thing 20 years ago, when multi-processor systems were last seen as "the next big thing". And occam is quite definitely imperative. There're also several modern languages that are being successfully used in the concurrent space which are not really purely functional too: Oz and E spring to mind. Purely functional programming is certainly a good answer, but it's hardly the only answer. While it may be a good idea to "let the machine sort it out" for some applications, in others it makes much more sense to write the code itself in an explicitly concurrent fashion because the resulting program is easier to understand that way.
Which is to say, its aimed at the niche that Fortran, despite how old and creaky it is, still rules. The world of programming has come a long way since Fortran, but nothing matches it for scientific computing and number crunching. To be honest that's about the only aspect of Fortran worth keeping...
That's true to a certain extent. But the other reason that Fortran stays around is the sheer quantity of legacy Fortran code. In the aerospace industry (with which I have some experience) there's a boatload of old Fortran code lying around that gets used for all sorts of important stuff (computational aerodynamics, spacecraft trajectory computations, etc.). No one wants to port the code to a new language because (a) the existing code is known to work, while any port might introduce bugs, and (b) the guys that actually understand what the code does and how it works are likely retired or dead, which increases the chances of introducing a bug during a port. So while Fortress may be a worthy replacement for Fortran (no argument there), there's no greater chance of a move to Fortress than to any other language for a lot of the legacy code out there.
I guess, in some ways, you could almost claim that Firefly was almost that...
Almost. And Firefly was certainly influenced by B7 (Joss Whedon has said as much). But I agree it'd be nice to see B7 get reworked. I think that things like Avon's somewhat ambiguous morality would ultimately make for a very different series than Firefly. Who knows, perhaps in the reboot they'll perpetrate a BSG-like gender-change, and make Servalan a man...;-)
You can go to school to learn to be a bridge builder and come out of it knowing all the exact specifications to build a bridge and probably design a fairly good bridge, or with a bit of creativity and some extra architectural skills a really cool bridge.
Christ, I'm sick of the bridge analogy. How many Slashdotters have ever actually designed and constructed a bridge, or really have any idea how hard it actually is? Are there any former bridge builders who are now software engineers reading this? Could you perhaps step in here, and tell us just how well bridge design actually compares to software design? For that matter, how many people have gone to school to learn bridge-building, and subsequently gone on to design and build bridges straight out of school? I'm guessing none. My own experience in engineering (electrical and aerospace rather than civil, but I'm guessing that civil is similar) is that kids straight out of school don't know anywhere near enough to tackle a major design project by themselves.
That's because in engineering you have an environment to work in. If you're building a bridge you already know the endpoints and that it'll basically be a line. If you're designing a building you know the laws of gravity aren't going to change. Often times in CS the task will be something like to build a single 'bridge' that can be installed over a river, between continents, or in a Lego landscape. Or the 'laws of gravity' like which direction the stack grows will change on you.
Er... you may know the endpoints. In some cases the customer may not have specific endpoints in mind, just know that (for example) a particular river needs to be spanned at some point. The customer might also change their mind about the endpoints partway through the design. There's also the question of what kind of load the bridge should be built to carry. How much traffic will there be? What kind? Does it vary widely in different seasons? Is it likely to increase over the life of the bridge? By how much? How stable does the bridge need to be: Can it swing a little? How much? Under what wind conditions? The "environment" of a bridge is nowhere near as easily characterized as you so casually assume. The same goes for buildings. There may be some constants in a given problem domain, but there are also a pretty wide range of variables.
You also seem to be assuming that civil engineering is the only kind of engineering. What about the microcontroller design engineers whose products need to function in everything from kitchen appliances to cars, and potentially in a wide range of climates? The aeronautical engineer whose product must function safely over a wide range of temperatures, pressures, airspeeds, while carrying a variety of passengers and cargo? The communications engineer whose product may be used for voice or data, in urban canyons and open prairies? There are plenty of engineered products where key elements of the "environment", ones that impact the function of the product, are not fixed, or even particularly well-characterized.
That's because the details often don't matter as much in engineering.
Wow. Just... wow. I can't believe you actually said that with a straight face (I'm assuming it was with a straight face). How much the details matter is dependent on the kind of product being engineered. Ditto which details matter. Just like in software development, where the exact details of the execution time of some particular algorithm may not matter that much for a web-app (so long as the time is "good enough" in most cases), but are absolutely critical for a real-time system.
If you use a bolt that is 1% too short chances are your structure will still stand. If you use a buffer that is 1 character too short chances are your program will explode and (take out the nuclear reactor with it).
It depends on the structure. Part of good engineering is determining what the tolerances of your design are, so that you know where you can get away with a 1% error, and where 0.0001% accuracy is critical. The odds are good that a nuclear reactor will require tolerances far in tighter than 1% in many places. By the same token, there are many situations where having a buffer 1 character too short probably isn't disastrous (maybe some non-critical data gets discarded in a few edge cases, but you don't lose anything the user really cares about).
In CS you *do* have an unlimited pool of 'parts' to choose from, whether created from scratch or copied.
I think that what the other poster was talking about was the limited availability of pre-designed building blocks, not the material shortages that might be faced in fabricating a particular design. In many cases it's simply not cost-effective to embark on (for example) a new ASIC design. So either the product won't get developed, or you need to find a creative way to make use of those components that you can rea
To the question "Why?", religion (at least the Islamo-Judeo-Christian variety) offers the excellent and illuminating answer "Because that's what God decided!". Which is clearly superior to the current answer provided by science (i.e. "Because!"), since it contains more words. Of course, it's not necessarily a more intellectually satisfying answer, since it leaves open important questions like "Why did God decide that?", "Why God?", and "Which God?". But if the metrics by which you choose an answer to "Why?" include "more words", and "creates more questions than it answers", then it seems to me that religion is the way to go.
Some people (notably Matthias Felleisen) have made a pretty good argument that functional programming has more in common with OO (or perhaps more to teach OO) than might be apparent at first glance. This presentation (warning: PPT) makes the case.
The Vikings had farms there for nearly a century (more? less?) before it got too cold for the crops to survive. It was never "hospitable", but it was endurable. For farmers, who supplemented their farming with fishing. Later this colony got frozen out.
The Viking colony on Greenland survived for around 500 years. The causes of the failure of the Viking colony are diverse: a mixture of economic problems (the rise of the Hanseatic League for example), over-farming, and, yes, climate change. But the reason that climate change had an impact was as much to do with the conservative Viking culture as it was the difficulty of the conditions. The Inuit were able to live there long after the Viking colony died out, but the Vikings refused to adopt Inuit technologies that might have helped them to survive.
I suppose it depends on what you mean by "formal methods". I know that some people think using UML is using "formal methods". I also know that some people think that using "formal methods" means using some kind of heavyweight "formal" process with rigidly defined steps, lots of documentation, and many "formal" reviews. But in my book (and in Wikipedia) "formal methods" are
...mathematically based techniques for the specification, development and verification of software and hardware systems.
So yes, algorithmic study and Big O estimates are one part of using "formal methods" for software design.
The point is that there is a lot more to the use of mathematical reasoning in software than just Big O estimates. You can utilize strong type systems to statically guarantee useful properties of your code (up to and including freedom from deadlock in the case of TyPiCal's type system). You can make use of Hoare logic to reason about state changes - this is the basis for developing useful assert statements. You can use design-by-contract and logical assertions to define and statically check the specifications on your code (see for example SPARK/Ada or JML). You can use process algebra, or temporal logic, or Petri nets, or some other mathematical technique, to model and understand multi-threaded and distributed systems, and analyze them for deadlock, livelock, and various other properties. I could go on. The point is, there're lots of useful mathematical tools for reasoning about software. Some of them have been integrated into current programming practice (type systems, assertions, pre- and post-conditions), others are still a long way from gaining acceptance (formal proofs with Z or VDM, concurrency design using process algebra). The most important thing is to know what tools are available, and be willing to apply them when and where they might be helpful.
Structural engineering - static load analysis of simple structures, finite-element modeling of complex structures
Digital hardware design - boolean logic, circuit simulation, more recently formal verification via model-checking and higher-order logic
Control engineering - frequency methods for stability analysis (PID controllers), linear algebra for the derivation of optimal control laws
Spacecraft trajectory design - pretty much all orbit analysis is mathematical in nature, and even the heavily numerical work is rooted in things like dynamical systems theory
Communications system engineering - statistical analysis of signals and noise, coding theory to improve SNR
Note that most engineering doesn't rely on formal mathematics to ensure correctness - they still do testing as well - but formal mathematical work can significantly increase your confidence in correctness, and it can help to detect design errors much earlier in the design process. Some things simply can't be tested though - spacecraft trajectory design is one of those things where the math must be right, becuse you only get one shot.
Now, let's flip the question around. Can you give me an example of a field of "real engineering" that doesn't make use of some kind of mathematics to help understand and analyze proposed designs?
Back to the topic, Firefly is unusual, politically. It's hard to think of an SF show that's that libertarian.
There's always Blake's 7. Of course, Firefly was influenced by B7 (Joss Whedon apparently watched B7 while he was at university in the UK), so I guess it's not surprising that there're some parallels in themes.
I think you're underestimating exactly how powerful state governments still are - grocery stores in Pennsylvania look considerably different than grocery stores in Ohio due to the complete lack of alcohol in Pennsylvania grocery stores. The gay marriage issue? States again (and contrary to what our President might think, states won't give up that right through an amendment, either). Speed limits? States. Sales tax? States. Education system? States. Police? States. Driver's licensing? States.
I think you're underestimating the power of the federal government. Drinking age in all states? 21, because that's the way the feds wanted it. No doubt if they wnated to ban booze in grocery stores through all of the states they could do that, using the same tactics they used to normalize the drinking age - they just don't care to do so. Gay marriage? States for now - although we keep hearing rumblings about consitutional amendments. Education system? Uh... No Child Left Behind anyone? Police? I'll give you that one, at least partially - the US law enforcement structure is one of the most baroque I've ever seen: city cops, county sheriffs, state troopers, the FBI, the DEA, the BATF, the Secret Service, the Federal Marshals, etc. Driver's license? States for now. But again, I wouldn't count on it being that way for long (there's a war on terror on you know, and those damn illegal immigrants are harming our national security). Now let's talk about federal circumventing of medical marijuana laws in states like California...
Something along similar lines is Frank van Ham's work on visualizing large state spaces. He's generated some neat visualizations of complex transition systems associated with various protocols.
If you're dual-citizen, it can take two years plus for them to process the paperwork, they're that paranoid.
If you're a dual-citizen then you can pretty much forget about getting a secret clearance. DoD policy (as of about 2 years ago) states that dual-citizens (regardless of what other country they are a citizen of) will be denied clearances unless they give up their non-US citizenship.
Right. Because Heinlein certainly never portrayed the downsides of capitalism. Nor did he ever show a centrally controlled or socialist economy in a positive light. Oh, wait...
Slashdot Mirror
Er... no. Or rather, yes, but with the caveat that "experiment" doesn't necessarily mean "something done in a lab". One proposes a hypothesis that can explain existing observations. That hypothesis is then tested, by using it to make predictions about future observations (which may or may not be produced by an experiment in the lab). If the predictions are found to be correct, then the hypothesis gains credence (but isn't considered "proved"). If at any point new observations are found which contradict the hypothesis, then it is discarded or revised.
As an example of science that does not involve lab experiments, consider Kepler's laws of orbital motion. Kepler hypothesized his "laws" based on the excruciatingly detailed observations of Tycho Brahe. Obviously, performing a lab experiment to confirm the laws is rather difficult (hard to fit even Mercury in the lab, let alone the Sun). Instead, Kepler used his "laws" to make predictions about the future motion of the planets. Later observations bore out his hypothesis, and the "laws" gained credence. Note that Kepler's laws are now widely accepted (Google for "Keplerian orbit"), but have never been tested via laboratory experiment. The closest we've come to "experimental" verification is the launch of artificial satellites, starting in the 1950s. But Kepler's laws were commonly accepted long before then, on the basis of observations of planetary motion (and later, as the result of Newton's demonstration that an inverse square gravitational force would result in Keplerian orbits).
Evolution is much the same. A large number of observations (both fossil records, and studies of existing flora and fauna) pointed to some kind of evolution occurring. Darwin's big contribution was to develop an explanation for the mechanism by which evolution occurs (i.e. natural selection) - a contribution more akin to Newton's development of gravitational theory than to Kepler's purely descriptive laws of orbital motion. Darwin's theories were lent credence as a result of both later field and fossil observations, which were found to follow the pattern predicted by Darwin's theory. Of course, like Newton, it was eventually found that the original version of Darwin's theory wasn't perfect, and evolutionary theory has...well...evolved, in much the same way that Newtonian mechanics has given way to relativistic mechanics. But evolutionary theory is on as firm a scientific footing as any other branch of science (and firmer than some).
Right. And that's a huge source of bugs. Bad assumptions, or assumptions that get violated during some calls are precisely the kind of things that produce produce behavioral errors. What DbC lets you do is state your assumptions, and do so in a format that is automatically checkable (either statically or at runtime). Note that you don't have to write contracts. But if, as you're coding, you realize that you're making a particular assumption about a precondition to the call, or that you intend to guarantee some kind of postcondition, you might as well encode those assumptions and intentions as a contract.
<sarcasm>Yes, god forbid anyone should actually think about what they're coding before they start cutting code. That would be a recipe for disaster...</sarcasm> That said, again, you don't have to write contracts. Just as you don't have to write unit tests. But both things are good practices that are going to help you find bugs.
I could just as well say: "...in real systems much of the code just doesn't lend it self to being checked by unit tests.... Subscriptions.get_expired() ... Seems pretty straightforward, get me a collection of expired Subscriptions...What kind of unit test would I use...." Seriously, stop and think about what kind of unit tests you would define for Subscriptions.get_expired(), and you're likely to be well on your way to figuring out what the preconditions (if any) and postconditions of the operation are.
Heh. Took me a moment to realize that you weren't talking about preprocessor #defines there :-) Why that's relevant will become obvious shortly. Anyway, I'd posit that typing '//', '--', or '%', followed by a comment is about as easy.
As for whether comments are "easier" than contracts, it depends on (as I said before) your application domain, and also what your timescale and environment is like. Example: I recently wrote some code in which I encoded some constraints on values as preprocessor #if statements (kind of an ad hoc static type system, since I couldn't say what I needed to within the standard C type system, and other languages are not an option at this point). Now, I could have just written some comments describing the constraints. In fact, that's initially what I did. But then I realized that encoding them as "contracts" of a sort ensures that neither I (working at some distant time in the future), nor another coder working on the same code-base, can inadvertently break the constraints without generating a compiler error. The comments are still there, to explain what's going on. But in the long term, it's "easier" to provide assurance that the program will work as intended by having a compile-time check which ensures that I or someone else can't alter the code in a way that violates the assumptions which underly the operation of the program than it is to provide some kind of external social guarantee that every coder working on the code in question will be careful enough to avoid violating constraints.
Whether or not the effort of type-safety is worth it largely depends on your application domain. Duck typing may be fine by you, but for embedded code in a mission-critical application static type-checking buys you a lot of peace of mind.
That said, DbC is not the same as type safety. It provides both less (runtime checks only), and more (much more expressive constraints). Of course, some DbC systems do provide static checking of contracts as well. But the result is (with the possible exception of Eiffel) layered on top of the type system of the language, rather than being integrated with it.
So why not give them tools to make the job easier? You can do OO in C, but it's much easier in a language designed to support objects. Similarly, while it's possible to do ad hoc DbC in most languages, it becomes much easier if you have tools and facilities in place to support it.
Actually, you can perform quicksort on linked lists. But without random access, many of the optimizations you can use to make quicksort really "quick" can't be done, so there isn't much reason to prefer quicksort over a good mergesort implementation for linked lists.
Amen to that. I really enjoy programming using CSP or Actor-style concurrency. Using those kinds of concurrency models is certainly far easier than programming using a shared-state thread model. But that isn't the same as being "easy" - you still need to think about the design of the system, and take care with the way processes interact. One of the more complex highly-concurrent systems that I've developed was an occam program with around 1,000+ interacting concurrent processes organized with a dynamically changing communications topology. It worked extremely well. Partly because the interactions were carefully designed, and in some cases modelled and verified (and fixed!) using CSP before I wrote a single line of occam.
Er... not really. The occam was very successfully doing the multicore thing 20 years ago, when multi-processor systems were last seen as "the next big thing". And occam is quite definitely imperative. There're also several modern languages that are being successfully used in the concurrent space which are not really purely functional too: Oz and E spring to mind. Purely functional programming is certainly a good answer, but it's hardly the only answer. While it may be a good idea to "let the machine sort it out" for some applications, in others it makes much more sense to write the code itself in an explicitly concurrent fashion because the resulting program is easier to understand that way.
Er... you may know the endpoints. In some cases the customer may not have specific endpoints in mind, just know that (for example) a particular river needs to be spanned at some point. The customer might also change their mind about the endpoints partway through the design. There's also the question of what kind of load the bridge should be built to carry. How much traffic will there be? What kind? Does it vary widely in different seasons? Is it likely to increase over the life of the bridge? By how much? How stable does the bridge need to be: Can it swing a little? How much? Under what wind conditions? The "environment" of a bridge is nowhere near as easily characterized as you so casually assume. The same goes for buildings. There may be some constants in a given problem domain, but there are also a pretty wide range of variables.
You also seem to be assuming that civil engineering is the only kind of engineering. What about the microcontroller design engineers whose products need to function in everything from kitchen appliances to cars, and potentially in a wide range of climates? The aeronautical engineer whose product must function safely over a wide range of temperatures, pressures, airspeeds, while carrying a variety of passengers and cargo? The communications engineer whose product may be used for voice or data, in urban canyons and open prairies? There are plenty of engineered products where key elements of the "environment", ones that impact the function of the product, are not fixed, or even particularly well-characterized.
Wow. Just... wow. I can't believe you actually said that with a straight face (I'm assuming it was with a straight face). How much the details matter is dependent on the kind of product being engineered. Ditto which details matter. Just like in software development, where the exact details of the execution time of some particular algorithm may not matter that much for a web-app (so long as the time is "good enough" in most cases), but are absolutely critical for a real-time system.
It depends on the structure. Part of good engineering is determining what the tolerances of your design are, so that you know where you can get away with a 1% error, and where 0.0001% accuracy is critical. The odds are good that a nuclear reactor will require tolerances far in tighter than 1% in many places. By the same token, there are many situations where having a buffer 1 character too short probably isn't disastrous (maybe some non-critical data gets discarded in a few edge cases, but you don't lose anything the user really cares about).
I think that what the other poster was talking about was the limited availability of pre-designed building blocks, not the material shortages that might be faced in fabricating a particular design. In many cases it's simply not cost-effective to embark on (for example) a new ASIC design. So either the product won't get developed, or you need to find a creative way to make use of those components that you can rea
Fortunately, we have all sorts of additional commentary from the framers which helps to elucidate their intent in writing the 2nd amendment.
To the question "Why?", religion (at least the Islamo-Judeo-Christian variety) offers the excellent and illuminating answer "Because that's what God decided!". Which is clearly superior to the current answer provided by science (i.e. "Because!"), since it contains more words. Of course, it's not necessarily a more intellectually satisfying answer, since it leaves open important questions like "Why did God decide that?", "Why God?", and "Which God?". But if the metrics by which you choose an answer to "Why?" include "more words", and "creates more questions than it answers", then it seems to me that religion is the way to go.
Some people (notably Matthias Felleisen) have made a pretty good argument that functional programming has more in common with OO (or perhaps more to teach OO) than might be apparent at first glance. This presentation (warning: PPT) makes the case.
The Viking colony on Greenland survived for around 500 years. The causes of the failure of the Viking colony are diverse: a mixture of economic problems (the rise of the Hanseatic League for example), over-farming, and, yes, climate change. But the reason that climate change had an impact was as much to do with the conservative Viking culture as it was the difficulty of the conditions. The Inuit were able to live there long after the Viking colony died out, but the Vikings refused to adopt Inuit technologies that might have helped them to survive.
I suppose it depends on what you mean by "formal methods". I know that some people think using UML is using "formal methods". I also know that some people think that using "formal methods" means using some kind of heavyweight "formal" process with rigidly defined steps, lots of documentation, and many "formal" reviews. But in my book (and in Wikipedia) "formal methods" are
So yes, algorithmic study and Big O estimates are one part of using "formal methods" for software design.The point is that there is a lot more to the use of mathematical reasoning in software than just Big O estimates. You can utilize strong type systems to statically guarantee useful properties of your code (up to and including freedom from deadlock in the case of TyPiCal's type system). You can make use of Hoare logic to reason about state changes - this is the basis for developing useful assert statements. You can use design-by-contract and logical assertions to define and statically check the specifications on your code (see for example SPARK/Ada or JML). You can use process algebra, or temporal logic, or Petri nets, or some other mathematical technique, to model and understand multi-threaded and distributed systems, and analyze them for deadlock, livelock, and various other properties. I could go on. The point is, there're lots of useful mathematical tools for reasoning about software. Some of them have been integrated into current programming practice (type systems, assertions, pre- and post-conditions), others are still a long way from gaining acceptance (formal proofs with Z or VDM, concurrency design using process algebra). The most important thing is to know what tools are available, and be willing to apply them when and where they might be helpful.
Note that most engineering doesn't rely on formal mathematics to ensure correctness - they still do testing as well - but formal mathematical work can significantly increase your confidence in correctness, and it can help to detect design errors much earlier in the design process. Some things simply can't be tested though - spacecraft trajectory design is one of those things where the math must be right, becuse you only get one shot.
Now, let's flip the question around. Can you give me an example of a field of "real engineering" that doesn't make use of some kind of mathematics to help understand and analyze proposed designs?
Something along similar lines is Frank van Ham's work on visualizing large state spaces. He's generated some neat visualizations of complex transition systems associated with various protocols.
If you're a dual-citizen then you can pretty much forget about getting a secret clearance. DoD policy (as of about 2 years ago) states that dual-citizens (regardless of what other country they are a citizen of) will be denied clearances unless they give up their non-US citizenship.
Right. Because Heinlein certainly never portrayed the downsides of capitalism. Nor did he ever show a centrally controlled or socialist economy in a positive light. Oh, wait...
Now there is a good idea! After all, if the legislators in question aren't doing anything corrupt they should have nothing to worry about...