There are state mandated curricula. Teachers are employees, just like say software engineers. They have bosses, and the bosses tell them what to teach and how to teach it.
Back in the day teachers often had a good bit of leeway, they put together a course and taught it. Maybe they had to use whatever textbook was available but beyond that they did usually largely do their own thing, but even then it was far from beyond supervision or intervention.
Nowadays with state mandated textbooks, lesson plans, standardized tests, etc as well as being even more in the public eye than ever before it is actually pretty difficult for teachers to wander much from what they've been told to teach.
Sure, teachers can obviously present things in a way that tends to present certain views in a better or worse light, but they aren't free to ignore or disparage material. School administrators have plenty of problems already, and they are not usually too happy about teachers who's techniques land angry parents on their backs either, so the general attitude is 'stop making trouble and just teach what your told to.'
Plus there is the fact that some really large percentage of teachers are themselves either anti-evolution or can't tell the difference between ID and science (and are none too well grounded in the science itself for that matter).
I will agree with you that a few teachers will go to the wall, and be fired. A somewhat larger percentage of the good ones will roll their eyes and try to do the best they can. But they're only human and being fired is no fun.
Creationists don't live in the actual real world of cause and effect and rational thought, by definition. Me, I don't want irrational fundies in charge of MY nuclear weapons stockpile...
Contrary to your belief that 'these kinds of problems are subtle and might be missed during a decent period of testing' it can be EXTREMELY difficult to find these kinds of problems. Beyond your wildest imaginings difficult.
Having worked on high performance hardware/software systems as an engineer I can tell you from first hand experience that the situation is more like there are 999,999,998 ways for things to go wrong and about 2 ways you can get it right, and those 2 ways are not AT ALL obvious. Usually the types of problems you encounter HAVE no obvious cause and no obvious solution and mostly can't be reliably replicated. They can stem from the very most subtle differences between two boards or systems. A cap that happens to be a bit out of spec and a slightly less than perfect solder joint can combine to create an error that happens 1 out of every 100 billion times an operation is performed.
Now, combine that with the fact that you have a dozen vendors slightly varying implementations of a given board design, PCs of all different types and quality levels running at different speeds with different CPUs in them, running a plethora of different versions and subversions of OS and drivers and applications, and the real miracle is you can make a board that works reliably at all.
Any attempt to make a really seriously bullet proof product that would virtually never have problems is simply infeasible. There is a law of diminishing returns involved. At a certain point you have to say "Well, we've tested it in 10 dozen different systems under 6 different OS versions with 128 different apps, and we get N number of crashes/malfunctions per hour of runtime." and then you call it a day. You could spend 10x more time and money on QA and reduce the failures to N/2, but you also won't sell much product when multiply your NRE by a factor of 10...
Plus such perfection will be for naught because MS will release BrokenOS patch "friday the 13th" 2 days later and you'll STILL be encountering the higher error rates. Same goes for new motherboards, games, etc. It is just a loosing proposition.
All you can realistically do is what they do now, test the heck out of it as best you can afford to, ship it out the door, and try to address any issues that come up later as quickly and painlessly as you can.
This is the kind of reason why military and aerospace grade hardware costs 2000x more than electronics with similar functionality with civilian retail/commercial specs. They REALLY do have to be certain things work exactly right or people die, and it is WAY expensive.
The whole thing may well be pretty much balderdash. Then again, we shall see... What really is the point of speculating? Some guy's blog someplace doesn't particularly seem like the height of reliability, then again corps often try to hide dirty laundry. Who knows?
Perl is right out. Other than the fact that it's a horrid language, It's not designed for embedding,
Sorry to burst that bubble but perl 5 has been completely embeddable from the very start.
and you wouldn't have been looking at Perl5, you'd have been looking at Perl4...
Again, not accurate. Perl 5 predates javascript by a number of years, 5+ in fact.
And you wouldn't get any benefit from CPAN... you'd need to build a new library from scratch, one designed for the limited environment of a sandbox, and that's nothing you couldn't do with Javascript.
Again, I disagree entirely. The vast majority of available CPAN modules are perfectly useful in a client side environment, even within the confines of a sandbox. At the 'chrome' level there is no compelling argument against the possibility of using absolutely ANY CPAN module if you really wanted to.
Furthermore perl has a perfectly good sandbox model, you can execute any code you want within restricted environments, specify exactly what classes of operations are permissible within that environment, and restrict the sandboxed code to any particular desired subset of data within the containing interpreter environment. See the 'Safe' module if you doubt me, it works. Furthermore it was available from the outset of perl 5. Beyond that no other dynamic environment had anything like complete taint checking a dozen years ago. All that infrastructure had to be built for javascript, it was already on the table with perl.
Languages for this purpose need to be designed with embedding and security in mind, which rules out a lot of options. Forth is highly embeddable, but you'd need a high level derivitive of it (like, say, Postscript) to satisfy the security requirements. I love Forth, and Postscript was a much-requested extension back then, but I suspect that it would have ended up with more complaints by now.
Well, I did EXTENSIVE work with FORTH back in the '80s. My experience with it says that the basic model is exceedingly flexible. It is one of the simplest and most elegant software designs in the history of software engineeering, if not THE most elegant. I am utterly confident an implementation could have met the desired requirements in regard to security and performance. There are certainly plenty of arguments against it on other grounds, but it was a very feasible alternative from a purely technical standpoint.
I used REXX, as AREXX on the Amiga, and it's barely better than Basic, and it's got some really amazing design flaws... such as uninitialised variables defaulting to their name as their value which was probably OK on OS/360... but sheesh.
Oh, I used AREXX plenty myself. I don't think it was a great language, but it was a workable alternative, and certainly a lot of the drawbacks of this or that particular implementation need not have been carried forward. Still, you mentioned REXX. Wouldn't likely have been one of my serious candidates, but still possible.
The only existing languages that I'm familiar with that they could have realistically used were Lisp derivatives. And of those Tcl or a similarly licensed Scheme would have been the best choices.
TCL is a sort of horrible little language. It operates on some good principles, but it was never capable at any level of being in the same class with FORTH, perl, javascript, etc. Certainly not in anything like the form it has taken.
Javascript is actually quite a nice language. The object model is an excellent one for a scripting environment, much better than a formal class based structure. The syntax is straightforward. I would love a command line Javascript with a good built-in string library for the things I use awk/sh/perl/tclsh for now.
It is partially a matter of taste of course. I find that javascript managed to incorporate
Sure, REXX would have been a pretty reasonable choice at the time. I don't think it is particularly astoundingly great, but if you look at it from the perspective of the time it was certainly a mature scripting language, well supported, and designed for exactly that sort of task.
I happen to have spent 4 years writing a few million lines of FORTH, so yeah, that would have suited ME fine. Probably wouldn't have gone over so well with the 'I understand it because it has curley braces' crowd though;)
Perl was a perfectly viable choice. It has always been quite embeddable. Dirt simple even at a basic level. Of course you would need bindings, but that is true with any interpreter. It was certainly the premiere choice 10 years ago and I'd have voted for it in 3 milliseconds flat.
Instead we got YASL. There are certainly far worse scripting languages out there, and every one will have its fans, but javascript is mediocre. I say this from the platform of a really large amount of development experience in several scripting languages. Just to use perl as an example it is just as convenient to use for small tasks as javascript, yet manages to hang together well on much larger ones quite a lot better. Plus it has a real set of library modules. How it irks me not to have access to a good library on the client side! Honestly, good libraries are worth more by far than this or that language feature. Good library implementations are non-trivial in a lot of cases and will save vastly more time, energy, and quality than one or two debatable language features.
Opinions differ on that last topic. There are perfectly good scripting languages Netscape could have chosen to embedd which are both standard and considerably more suitable for non-trivial use.
It is water under the bridge now at any rate, we have js and we'll just have to live with it.
You CAN call java from javascript, and the other way around too. The hitch is you still have to have a BIT of javascript in there, but it could be as trivial as an event handler that proxies to java.
There are plenty of other issues with applets though, trust me, I've written some fairly decent complexity ones. The only GUI library you have is AWT, which is best not described, the expletives would be unpleasant...
In any case, you can do what you describe now. Frankly though if JS was a better language this would not be an issue, but it isn't...
Who happen to think javascript is a particularly cheezy dynamic scripting language and would jettison it in 14 milliseconds if there WAS any way to have a viable alternative.
The only reason javascript still exists is because any author of client side code that tried to use anything else would have to get all their clients to download another plugin. Worse, you would have to implement said plugin for at least 4 browsers on 3 major desktop platforms and who knows what all on mobile.
So really, javascript need not be anything beyond marginally functional to be de-facto the one and only client side scripting language.
I won't even go into its deficiencies. Suffice it to say we are all paying for Brendan Eich's hubris in thinking he was the next Larry Wall. Sorry, not hardly.
Hmmm. Well, it seemed perfectly straightforward to me when I picked it up. I mean making a singleton in perl is the same as any other OO language, in the package your constructor just returns a reference to a static instance, or creates one if it doesn't exist yet. I don't know how it works in say Python, but I am guessing it is pretty much the same. It certainly isn't different from say Java, save for the lack of threading issues...
Speaking for myself I'm not convinced that bless() is all that cryptic. Certainly doesn't seem moreso to me than various features of other languages. Personally I find PHP's OO capabilities to be pretty limited compared to perl's. Maybe it takes a small investment of time to fully understand them at first, but it hardly seems excessive to me, and given that other things become much easier later on because of it one could counter argue that in the long run it is simpler and can improve code maintainability.
In fact it is quite an elegant implementation which can provide practically any imaginable OO feature anyone could ever want.
bless($self,$package);
The ENTIRETY of perl OO syntax and it manages to encompass all the hoohaa that requires a bizillion tons of features in other languages.
The beauty of perl OO is you are NOT put into a straightjacket by it, and things like reflection, introspection, AOP, etc are just plain dirt simple. Just check out Conway's book if you doubt.
Beyond that there are simply things you can do with OO perl you would be hard pressed at best to do in other scripting languages. I'll take perl's implementation of OO any time. It rocks.
If you blame your lousy code on the language, then you don't understand software engineering.
There are just as many crappy programs written in PHP, Python, etc as there are in perl, and you can make just as big a mess in any of them, trust me, I've seen it all in 25 years in this business.
Perl is actually a very elegantly designed language. Any decent team of programmers should have no more trouble designing and building a solution using perl than they would in any other scripting language.
The funniest thing about the perl bashing is that practically every concept now in vogue existed in perl LONG before it was adopted elsewhere.
CPAN, built in unit test and install harnesses, standardized embedded documentation. Show me a repository of libraries that is overall as consistently and well documented as CPAN, or anything near as comprehensive. Every other language out there has imitated perl and its related facilities.
Personally I have nothing against other scripting languages, but IMHO it is just redundancy. They aren't any better than their grandpappy The Camel!
And if you put bad coders on a project, or even if you give reasonably good coders insufficient support and have a poor process, you will likely get bad code as a result. It matters not if the code is written in Perl, Python, PHP, Ruby, or whatever your language de jour happens to be.
Perl is a perfectly good programming language. Personally I've written/been lead developer for several multi-hundred-thousand line perl web apps. Our code was perfectly clean and intelligible and quite maintainable.
CPAN is also a great resource, and frankly I haven't seen where any of the other dynamic scripting languages has anything similar that provides the breadth and depth of library functionality.
Some may say perl is 'dead', but it is sure alive and well in this neck of the woods and doing just fine, and nobody around here sees any pressing need to replace it with anything else. I can't think of a single language feature perl lacks or any other issue that would make me want to switch in particular. My feeling is it is a crying shame the scripting language community has balkanized itself so much, and a real crying shame we got that turkey javascript foisted on us. Far better would it have been if Netscape had just embedded perl instead of believing they could (and failing to) do better.
As so many have no doubt said above, you CANNOT determine which apps are secure, and there really is no existing 'test suite' for application security in general. It is far too broad a ground to cover.
What you need to do is identify 'known good' versions of applications. Essentially that is going to involve finding a version of each app, or maybe several versions, which have no known unmitigatable security issues. You can do that by looking for CVE's etc.
Those become your good baseline. From there you'll just have to monitor the various security mailing lists and subscribe to the vendor for each application for security alerts. That way you will know when a vulnerability is discovered in your application.
At that point you'll have to patch. The exact strategy you use is going to depend on the vendor, the OS, and your internal needs. In some shops it may be sufficient to enable windows autoupdates, or app specific updates. More likely you're going to need to manage and distribute patches locally yourself.
That brings up the next issue. You need to know what apps and versions each system is running. One way to do that would be to implement NAC (Network Access Control) on your corporate network. If you choose an appropriate NAC implementation it should be able to determine the patch status of a system, jail it if it isn't up to date, etc. At the very worst at least you can find out which machines haven't been patched.
Maybe your organization already has some of this infrastructure in place, so it might not be all that hard to do.
Now, all that being said, if you want to deal with strictly SERVER side applications, especially webapps, there ARE scanners for many of those. They are worth using, though you really should have something like an ITIL infrastructure in place for managing and provisioning those...
The OP wanted to know if anyone knew of a tool for doing a REVIEW of a user interface.
This has not to do with user interface design or testing.
Look at it this way. You design your UI, you build it, now you need to compare the design with the implementation. Is there a tool for that?
This would be particularly important in cases where you are updating an existing UI. Suppose the tasks are X,Y, and Z. Now you need to determine if those tasks have been properly accomplished. Do the new UI elements propery integrate with the look and feel of the rest of the UI? Do they properly implement the workflow. Was the design of these changes/features what you really wanted?
You need to review the thing, just like you would review a piece of source code. Is the job done right, that is the question to answer.
So IMHO such a tool would allow people to view and interact with the UI and to annotate it in some fashion. Then they can show everyone what they like or don't like, and any errors or inconsistencies, which can then be fixed and reviewed again.
Some of this might fall under the heading of UI test automation, but that only really checks the functionality, not the consistency and feel of the thing.
Personally I don't know of a purpose built tool for this. It could be a nice thing to have, especially in larger shops.
Well, if Earth lets themselves be boxed in, they're pwned. Hence, they're going to fight any attempt of a colony setting up their own communications infrastructure around Earth tooth and claw.
Which I think is exactly my point. And once you loose that fight, it is over.
Its not that I think setting up a self-sufficient community in space is going to be easy. I suspect it will be a LONG time before it becomes feasible. But once its there, Earth becomes the tail, not the dog simply by virtue of the nature of things.
I'm not even convinced it IS possible to create such a thing for whatever reasons either. Not due to engineering details, those can be solved fairly easily. More due to the simple fact that we may find that the physiological limitations of the human body's ability to adapt to low gravity can't be overcome.
In which case we might find that it is our robotic overlords that end up pwning us...;)
Still not the same thing. There are orders of magnitude difference between the complexity of x86 instruction set and javascript.
In any case Prototype works great. Abstracted away all those nasty browser issues. My stuff seems to work fine in any modern browser too. Time will tell which approach is best, but so far I'm not convinced of the value proposition. hehe
It isn't that I reject the concept wholesale, but I look at it this way, if I primarily develop client side code then the least complex path is to do it in the native language for that environment, javascript.
Code generators ARE evil! lol. And quite frequently in my experience EXACTLY what you want to do is tweak the generated code. And that inevitably involves paying the cost of getting into the guts of the code generator, which means now I'm not supporting MY code, I'm supporting the GWT code on top of it. Given the amazing profusion of technologies one already has to master in order to get these kinds of project done, one less is a mightly appealing concept to many of us!
I doubt that. And for most forms of large-scale energy generation, you're lacking one thing: An easily available way to sink heat (on Earth, you've got rivers, oceans, and the atmosphere).
Eh, I seriously doubt that is going to be much of a problem. Thermal pollution IS a significant issue on Earth, ask anyone thats run a power plant...
Pollution is a _huge_ concern, because it will put extra strain on the life support facilities before it can be removed from the "inside" and dumped somewhere on the "outside", and the moon base will have a lot less "environment" to dilute the pollution than Earth. And if the people on the moon somehow come up with minimum-pollution ways of manufacturing and generating energy, Earth will have them, too.
Yeah, I disagree. Nobody is going to do dirty stuff INSIDE their controlled environment! And outside is nothing. Any waste you do want to keep in one place is likely to just stay there on its own.
Possibly, but they will still have to expend way more energy, material, labor and research just to keep themselves alive.
Again, I disagree. I think good solutions exist. Our current engineering experience is mostly with conditions on Earth. Once you have engineering experience in space environments I suspect those issues are not going to be any bigger than they are anyplace. Besides, it is much easier to get the energy you need in a place like the Moon.
Consider, once you build something on Earth, it doesn't get hit by micrometeorites, the solar wind, solar flares or other cosmic radation.
The equipment we put in space now deals with all the same considerations, and they don't appear to be all that difficult to deal with. Virtually any structure built on the Moon would persist with practically no maintenance in human timescales essentially forever.
And any launch from Earth must be energetic and thus can't really be 'stealthy'.
That might be a point, but unless you've got a spy satellite network around Earth, they can just launch/thrust when you can't see it.
And why exactly would our hypothetical Lunar Civilization NOT have that capability? Just ordinary considerations of traffic control, navigation, and communications would practically mandate a significant baseline capability in that area. The best Earth will be able to do is try to hold its sustainable space based civilization to itself by main force. Inevitably that course will fail in time.
No, it is a code generator. It is generating javascript. Ergo it is a code generator, and that javascript may well not meet my needs. Furthermore I've lost the ability to simply use whichever javascript components I might feel like using, or I have to design components specifically using GWT, and then I am going to be propelled into the bowels of the details of exactly HOW it does that, on and on.
As for the 2nd part, I may not WANT to do things the way GWT does them. Maybe JSON isn't where I need to be at. What if I want to consume a SOAP service? No, you gotta do JSON because that is the way it is...
Even if we simply accept your 'compiler' argument and chalk it up to semantics there is a HUGE difference between gcc or javac and what GWT is doing. At that maybe you recall the endless debates, arguments, and etc surrounding c and c++ binary ABI standards of years past? Given the shifting sands of browser compatibility that one was pretty much a cakewalk.
UI and backend should be decoupled. Developers of one should not need to be impacted or deal with the details of the other. If the application is properly architected and well documented then there should be few issues. The front end guys can do their front end thing with the tools they favor and the same for the backend, and the twain shall meet over HTTP...
It isn't so much that I have any particular opinion about GWT, but I do believe I am articulating the fundamental reasons for developer's reluctance to jump into it. Certainly we here are in no hurry to jump on the bandwagon. That was the question in the OP's mind, I just answered it. The market will sort things out, and when it does, we'll be in a fine position. We can come in, or we can do whatever makes sense in the long run.
In a word the strength of the web is the LACK of coupling between client and server tier. Tools like GWT cut against that. I don't WANT to have to particulars of the server side implementation all over the place on my client side.
I probably have different teams working on each portion of my web application. Why should I wish to have such tight coupling between them?
Furthermore in my 25 years of software development I've developed a real healthy contempt for automatic code generators. Nothing is more of a PITA than having to try to arm twist some code generator when it generates buggy code that doesn't do exactly what I want. It very quickly becomes more of a liability to the project than an advantage.
No, I would rather be able to develop client side logic built to the specification of the interface with the server side. Now, I'd be a lot more enthusiastic about having a GOOD GUI development tool for javascript/css/html/xml and a client side stub generator that simply wraps the SPECIFICATION of the interface between the client and the server.
Furthermore a GWT like system has all sorts of other architectural assumptions built into it that are likely to restrict the design of my system in various ways. Good tools ALLOW appropriate design, they don't railroad you into doing things a certain way. So, no, I am not particularly a fan of this approach and I doubt I will become one in the near future.
Its an interesting debate. I consider a few factors and my opinion is that it would eventually favor a space based power.
The people in space are going to be infinitely more familiar with and motivated to understand space based operations. Inevitably their technical capabilities will surpass any possessed by Earth in that regard because the whole thrust of their civilization is going to be in that direction.
Also in the longer term I wonder just how much more expensive it will be to live on the Moon say, where energy is far more available, pollution is not a concern, there is always plenty of available room to grow, etc. 'Life Support' on Earth may not be as cheap as we might think.
Consider, once you build something on the Moon or in space, it is THERE, no wind erodes it, no floods or hurricanes damage it. There may well be many subtle advantages there. It is far too early to say what the costs and benefits really are and if they cancel out.
But one thing IS certain. It will always take 81 times more energy to launch from Earth than from the Moon, and infinitely more than from some say Amor class asteroid. And any launch from Earth must be energetic and thus can't really be 'stealthy'. I can so no potential military advantage for Earth whatsoever, only population size.
No, inevitably sooner or later the ECONOMIC equation will be that Earth has nothing to offer to your space based civilization. Its goods cannot be competitive. It would simply make no sense for someone living on the Moon to ship things to Earth, there's nothing they can get in trade save maybe a novel or a good bottle of wine. That won't be enough to hold such a civilization to the mother planet, not for long.
But to the original point. Why would such a civilization ever want to go back and live on a planet again? It would be like you or I deciding to build a house on top of Mt Everest. The view might be nice, but the daily commute would be a real bitch.
Its all about economics. Sooner or later you're going to reach the point where Earth can't continue to compete. Everything Earth does in space is going to be 10-100x more expensive than what your Lunar Civilization can do. With that kind of cost advantage going from bare self-sufficiency to supremacy would be no more than a matter of a few decades.
ROFL! The military position of any decent infrastructure on the Moon would TOTALLY dominate near-earth space.
You have limitless power and throwaway mass you can easily hoist to Earth. While Earth has to send its weapons UP the gravity well. Good luck Earth.
And pretty much ANY kind of infrastructure where you could loft more than a trivial amount of stuff off the moon would by virtue of its position at the top of the gravity well etc be very easy to weaponize.
The reverse however is not true at all. Beyond that any self-sufficient 'space colony' will virtually HAVE to have vastly greater expertise in space operations than its opponents on Earth.
There could be a historically brief phase where Earth still has dominance of cis-lunar space, but given the vast disparity in cost factors between space operations from Earth and from the Moon it would be very unlikely to persist for any significant period of time.
Within a few decades of being self-sufficient any lunar or free space facility would achieve breakout military capability, dominate cis-lunar space, and essentially dictate all terms of access by Earth. In any case once you have such a capability you just go further out into space, and if Earths messes with you, you just pound them silly with rocks which could just as easily be launched from the main belt or even much further out. It could never be a winning proposition
Slashdot Mirror
There are state mandated curricula. Teachers are employees, just like say software engineers. They have bosses, and the bosses tell them what to teach and how to teach it.
Back in the day teachers often had a good bit of leeway, they put together a course and taught it. Maybe they had to use whatever textbook was available but beyond that they did usually largely do their own thing, but even then it was far from beyond supervision or intervention.
Nowadays with state mandated textbooks, lesson plans, standardized tests, etc as well as being even more in the public eye than ever before it is actually pretty difficult for teachers to wander much from what they've been told to teach.
Sure, teachers can obviously present things in a way that tends to present certain views in a better or worse light, but they aren't free to ignore or disparage material. School administrators have plenty of problems already, and they are not usually too happy about teachers who's techniques land angry parents on their backs either, so the general attitude is 'stop making trouble and just teach what your told to.'
Plus there is the fact that some really large percentage of teachers are themselves either anti-evolution or can't tell the difference between ID and science (and are none too well grounded in the science itself for that matter).
I will agree with you that a few teachers will go to the wall, and be fired. A somewhat larger percentage of the good ones will roll their eyes and try to do the best they can. But they're only human and being fired is no fun.
And there are no 'facts' to point out.
Creationists don't live in the actual real world of cause and effect and rational thought, by definition. Me, I don't want irrational fundies in charge of MY nuclear weapons stockpile...
Contrary to your belief that 'these kinds of problems are subtle and might be missed during a decent period of testing' it can be EXTREMELY difficult to find these kinds of problems. Beyond your wildest imaginings difficult.
Having worked on high performance hardware/software systems as an engineer I can tell you from first hand experience that the situation is more like there are 999,999,998 ways for things to go wrong and about 2 ways you can get it right, and those 2 ways are not AT ALL obvious. Usually the types of problems you encounter HAVE no obvious cause and no obvious solution and mostly can't be reliably replicated. They can stem from the very most subtle differences between two boards or systems. A cap that happens to be a bit out of spec and a slightly less than perfect solder joint can combine to create an error that happens 1 out of every 100 billion times an operation is performed.
Now, combine that with the fact that you have a dozen vendors slightly varying implementations of a given board design, PCs of all different types and quality levels running at different speeds with different CPUs in them, running a plethora of different versions and subversions of OS and drivers and applications, and the real miracle is you can make a board that works reliably at all.
Any attempt to make a really seriously bullet proof product that would virtually never have problems is simply infeasible. There is a law of diminishing returns involved. At a certain point you have to say "Well, we've tested it in 10 dozen different systems under 6 different OS versions with 128 different apps, and we get N number of crashes/malfunctions per hour of runtime." and then you call it a day. You could spend 10x more time and money on QA and reduce the failures to N/2, but you also won't sell much product when multiply your NRE by a factor of 10...
Plus such perfection will be for naught because MS will release BrokenOS patch "friday the 13th" 2 days later and you'll STILL be encountering the higher error rates. Same goes for new motherboards, games, etc. It is just a loosing proposition.
All you can realistically do is what they do now, test the heck out of it as best you can afford to, ship it out the door, and try to address any issues that come up later as quickly and painlessly as you can.
This is the kind of reason why military and aerospace grade hardware costs 2000x more than electronics with similar functionality with civilian retail/commercial specs. They REALLY do have to be certain things work exactly right or people die, and it is WAY expensive.
The whole thing may well be pretty much balderdash. Then again, we shall see... What really is the point of speculating? Some guy's blog someplace doesn't particularly seem like the height of reliability, then again corps often try to hide dirty laundry. Who knows?
Perl is right out. Other than the fact that it's a horrid language, It's not designed for embedding,
Sorry to burst that bubble but perl 5 has been completely embeddable from the very start.
and you wouldn't have been looking at Perl5, you'd have been looking at Perl4...
Again, not accurate. Perl 5 predates javascript by a number of years, 5+ in fact.
And you wouldn't get any benefit from CPAN... you'd need to build a new library from scratch, one designed for the limited environment of a sandbox, and that's nothing you couldn't do with Javascript.
Again, I disagree entirely. The vast majority of available CPAN modules are perfectly useful in a client side environment, even within the confines of a sandbox. At the 'chrome' level there is no compelling argument against the possibility of using absolutely ANY CPAN module if you really wanted to.
Furthermore perl has a perfectly good sandbox model, you can execute any code you want within restricted environments, specify exactly what classes of operations are permissible within that environment, and restrict the sandboxed code to any particular desired subset of data within the containing interpreter environment. See the 'Safe' module if you doubt me, it works. Furthermore it was available from the outset of perl 5. Beyond that no other dynamic environment had anything like complete taint checking a dozen years ago. All that infrastructure had to be built for javascript, it was already on the table with perl.
Languages for this purpose need to be designed with embedding and security in mind, which rules out a lot of options. Forth is highly embeddable, but you'd need a high level derivitive of it (like, say, Postscript) to satisfy the security requirements. I love Forth, and Postscript was a much-requested extension back then, but I suspect that it would have ended up with more complaints by now.
Well, I did EXTENSIVE work with FORTH back in the '80s. My experience with it says that the basic model is exceedingly flexible. It is one of the simplest and most elegant software designs in the history of software engineeering, if not THE most elegant. I am utterly confident an implementation could have met the desired requirements in regard to security and performance. There are certainly plenty of arguments against it on other grounds, but it was a very feasible alternative from a purely technical standpoint.
I used REXX, as AREXX on the Amiga, and it's barely better than Basic, and it's got some really amazing design flaws... such as uninitialised variables defaulting to their name as their value which was probably OK on OS/360 ... but sheesh.
Oh, I used AREXX plenty myself. I don't think it was a great language, but it was a workable alternative, and certainly a lot of the drawbacks of this or that particular implementation need not have been carried forward. Still, you mentioned REXX. Wouldn't likely have been one of my serious candidates, but still possible.
The only existing languages that I'm familiar with that they could have realistically used were Lisp derivatives. And of those Tcl or a similarly licensed Scheme would have been the best choices.
TCL is a sort of horrible little language. It operates on some good principles, but it was never capable at any level of being in the same class with FORTH, perl, javascript, etc. Certainly not in anything like the form it has taken.
Javascript is actually quite a nice language. The object model is an excellent one for a scripting environment, much better than a formal class based structure. The syntax is straightforward. I would love a command line Javascript with a good built-in string library for the things I use awk/sh/perl/tclsh for now.
It is partially a matter of taste of course. I find that javascript managed to incorporate
TACO!
Dangit! Your nonsense filter doesn't like my ASCII art!!!!
And yeah, I agree, Obama Bin-Laden has won! :(
Sure, REXX would have been a pretty reasonable choice at the time. I don't think it is particularly astoundingly great, but if you look at it from the perspective of the time it was certainly a mature scripting language, well supported, and designed for exactly that sort of task.
I happen to have spent 4 years writing a few million lines of FORTH, so yeah, that would have suited ME fine. Probably wouldn't have gone over so well with the 'I understand it because it has curley braces' crowd though ;)
Perl was a perfectly viable choice. It has always been quite embeddable. Dirt simple even at a basic level. Of course you would need bindings, but that is true with any interpreter. It was certainly the premiere choice 10 years ago and I'd have voted for it in 3 milliseconds flat.
Instead we got YASL. There are certainly far worse scripting languages out there, and every one will have its fans, but javascript is mediocre. I say this from the platform of a really large amount of development experience in several scripting languages. Just to use perl as an example it is just as convenient to use for small tasks as javascript, yet manages to hang together well on much larger ones quite a lot better. Plus it has a real set of library modules. How it irks me not to have access to a good library on the client side! Honestly, good libraries are worth more by far than this or that language feature. Good library implementations are non-trivial in a lot of cases and will save vastly more time, energy, and quality than one or two debatable language features.
Opinions differ on that last topic. There are perfectly good scripting languages Netscape could have chosen to embedd which are both standard and considerably more suitable for non-trivial use.
It is water under the bridge now at any rate, we have js and we'll just have to live with it.
You CAN call java from javascript, and the other way around too. The hitch is you still have to have a BIT of javascript in there, but it could be as trivial as an event handler that proxies to java.
There are plenty of other issues with applets though, trust me, I've written some fairly decent complexity ones. The only GUI library you have is AWT, which is best not described, the expletives would be unpleasant...
In any case, you can do what you describe now. Frankly though if JS was a better language this would not be an issue, but it isn't...
Who happen to think javascript is a particularly cheezy dynamic scripting language and would jettison it in 14 milliseconds if there WAS any way to have a viable alternative.
The only reason javascript still exists is because any author of client side code that tried to use anything else would have to get all their clients to download another plugin. Worse, you would have to implement said plugin for at least 4 browsers on 3 major desktop platforms and who knows what all on mobile.
So really, javascript need not be anything beyond marginally functional to be de-facto the one and only client side scripting language.
I won't even go into its deficiencies. Suffice it to say we are all paying for Brendan Eich's hubris in thinking he was the next Larry Wall. Sorry, not hardly.
Hmmm. Well, it seemed perfectly straightforward to me when I picked it up. I mean making a singleton in perl is the same as any other OO language, in the package your constructor just returns a reference to a static instance, or creates one if it doesn't exist yet. I don't know how it works in say Python, but I am guessing it is pretty much the same. It certainly isn't different from say Java, save for the lack of threading issues...
Speaking for myself I'm not convinced that bless() is all that cryptic. Certainly doesn't seem moreso to me than various features of other languages. Personally I find PHP's OO capabilities to be pretty limited compared to perl's. Maybe it takes a small investment of time to fully understand them at first, but it hardly seems excessive to me, and given that other things become much easier later on because of it one could counter argue that in the long run it is simpler and can improve code maintainability.
In fact it is quite an elegant implementation which can provide practically any imaginable OO feature anyone could ever want.
bless($self,$package);
The ENTIRETY of perl OO syntax and it manages to encompass all the hoohaa that requires a bizillion tons of features in other languages.
The beauty of perl OO is you are NOT put into a straightjacket by it, and things like reflection, introspection, AOP, etc are just plain dirt simple. Just check out Conway's book if you doubt.
Beyond that there are simply things you can do with OO perl you would be hard pressed at best to do in other scripting languages. I'll take perl's implementation of OO any time. It rocks.
If you blame your lousy code on the language, then you don't understand software engineering.
There are just as many crappy programs written in PHP, Python, etc as there are in perl, and you can make just as big a mess in any of them, trust me, I've seen it all in 25 years in this business.
Perl is actually a very elegantly designed language. Any decent team of programmers should have no more trouble designing and building a solution using perl than they would in any other scripting language.
The funniest thing about the perl bashing is that practically every concept now in vogue existed in perl LONG before it was adopted elsewhere.
CPAN, built in unit test and install harnesses, standardized embedded documentation. Show me a repository of libraries that is overall as consistently and well documented as CPAN, or anything near as comprehensive. Every other language out there has imitated perl and its related facilities.
Personally I have nothing against other scripting languages, but IMHO it is just redundancy. They aren't any better than their grandpappy The Camel!
And if you put bad coders on a project, or even if you give reasonably good coders insufficient support and have a poor process, you will likely get bad code as a result. It matters not if the code is written in Perl, Python, PHP, Ruby, or whatever your language de jour happens to be.
Perl is a perfectly good programming language. Personally I've written/been lead developer for several multi-hundred-thousand line perl web apps. Our code was perfectly clean and intelligible and quite maintainable.
CPAN is also a great resource, and frankly I haven't seen where any of the other dynamic scripting languages has anything similar that provides the breadth and depth of library functionality.
Some may say perl is 'dead', but it is sure alive and well in this neck of the woods and doing just fine, and nobody around here sees any pressing need to replace it with anything else. I can't think of a single language feature perl lacks or any other issue that would make me want to switch in particular. My feeling is it is a crying shame the scripting language community has balkanized itself so much, and a real crying shame we got that turkey javascript foisted on us. Far better would it have been if Netscape had just embedded perl instead of believing they could (and failing to) do better.
As so many have no doubt said above, you CANNOT determine which apps are secure, and there really is no existing 'test suite' for application security in general. It is far too broad a ground to cover.
What you need to do is identify 'known good' versions of applications. Essentially that is going to involve finding a version of each app, or maybe several versions, which have no known unmitigatable security issues. You can do that by looking for CVE's etc.
Those become your good baseline. From there you'll just have to monitor the various security mailing lists and subscribe to the vendor for each application for security alerts. That way you will know when a vulnerability is discovered in your application.
At that point you'll have to patch. The exact strategy you use is going to depend on the vendor, the OS, and your internal needs. In some shops it may be sufficient to enable windows autoupdates, or app specific updates. More likely you're going to need to manage and distribute patches locally yourself.
That brings up the next issue. You need to know what apps and versions each system is running. One way to do that would be to implement NAC (Network Access Control) on your corporate network. If you choose an appropriate NAC implementation it should be able to determine the patch status of a system, jail it if it isn't up to date, etc. At the very worst at least you can find out which machines haven't been patched.
Maybe your organization already has some of this infrastructure in place, so it might not be all that hard to do.
Now, all that being said, if you want to deal with strictly SERVER side applications, especially webapps, there ARE scanners for many of those. They are worth using, though you really should have something like an ITIL infrastructure in place for managing and provisioning those...
The OP wanted to know if anyone knew of a tool for doing a REVIEW of a user interface.
This has not to do with user interface design or testing.
Look at it this way. You design your UI, you build it, now you need to compare the design with the implementation. Is there a tool for that?
This would be particularly important in cases where you are updating an existing UI. Suppose the tasks are X,Y, and Z. Now you need to determine if those tasks have been properly accomplished. Do the new UI elements propery integrate with the look and feel of the rest of the UI? Do they properly implement the workflow. Was the design of these changes/features what you really wanted?
You need to review the thing, just like you would review a piece of source code. Is the job done right, that is the question to answer.
So IMHO such a tool would allow people to view and interact with the UI and to annotate it in some fashion. Then they can show everyone what they like or don't like, and any errors or inconsistencies, which can then be fixed and reviewed again.
Some of this might fall under the heading of UI test automation, but that only really checks the functionality, not the consistency and feel of the thing.
Personally I don't know of a purpose built tool for this. It could be a nice thing to have, especially in larger shops.
Well, if Earth lets themselves be boxed in, they're pwned. Hence, they're going to fight any attempt of a colony setting up their own communications infrastructure around Earth tooth and claw.
Which I think is exactly my point. And once you loose that fight, it is over.
Its not that I think setting up a self-sufficient community in space is going to be easy. I suspect it will be a LONG time before it becomes feasible. But once its there, Earth becomes the tail, not the dog simply by virtue of the nature of things.
I'm not even convinced it IS possible to create such a thing for whatever reasons either. Not due to engineering details, those can be solved fairly easily. More due to the simple fact that we may find that the physiological limitations of the human body's ability to adapt to low gravity can't be overcome.
In which case we might find that it is our robotic overlords that end up pwning us... ;)
Still not the same thing. There are orders of magnitude difference between the complexity of x86 instruction set and javascript.
In any case Prototype works great. Abstracted away all those nasty browser issues. My stuff seems to work fine in any modern browser too. Time will tell which approach is best, but so far I'm not convinced of the value proposition. hehe
Time will tell. ;)
It isn't that I reject the concept wholesale, but I look at it this way, if I primarily develop client side code then the least complex path is to do it in the native language for that environment, javascript.
Code generators ARE evil! lol. And quite frequently in my experience EXACTLY what you want to do is tweak the generated code. And that inevitably involves paying the cost of getting into the guts of the code generator, which means now I'm not supporting MY code, I'm supporting the GWT code on top of it. Given the amazing profusion of technologies one already has to master in order to get these kinds of project done, one less is a mightly appealing concept to many of us!
I doubt that. And for most forms of large-scale energy generation, you're lacking one thing: An easily available way to sink heat (on Earth, you've got rivers, oceans, and the atmosphere).
Eh, I seriously doubt that is going to be much of a problem. Thermal pollution IS a significant issue on Earth, ask anyone thats run a power plant...
Pollution is a _huge_ concern, because it will put extra strain on the life support facilities before it can be removed from the "inside" and dumped somewhere on the "outside", and the moon base will have a lot less "environment" to dilute the pollution than Earth. And if the people on the moon somehow come up with minimum-pollution ways of manufacturing and generating energy, Earth will have them, too.
Yeah, I disagree. Nobody is going to do dirty stuff INSIDE their controlled environment! And outside is nothing. Any waste you do want to keep in one place is likely to just stay there on its own.
Possibly, but they will still have to expend way more energy, material, labor and research just to keep themselves alive.
Again, I disagree. I think good solutions exist. Our current engineering experience is mostly with conditions on Earth. Once you have engineering experience in space environments I suspect those issues are not going to be any bigger than they are anyplace. Besides, it is much easier to get the energy you need in a place like the Moon.
Consider, once you build something on Earth, it doesn't get hit by micrometeorites, the solar wind, solar flares or other cosmic radation.
The equipment we put in space now deals with all the same considerations, and they don't appear to be all that difficult to deal with. Virtually any structure built on the Moon would persist with practically no maintenance in human timescales essentially forever.
And any launch from Earth must be energetic and thus can't really be 'stealthy'.
That might be a point, but unless you've got a spy satellite network around Earth, they can just launch/thrust when you can't see it.
And why exactly would our hypothetical Lunar Civilization NOT have that capability? Just ordinary considerations of traffic control, navigation, and communications would practically mandate a significant baseline capability in that area. The best Earth will be able to do is try to hold its sustainable space based civilization to itself by main force. Inevitably that course will fail in time.
No, it is a code generator. It is generating javascript. Ergo it is a code generator, and that javascript may well not meet my needs. Furthermore I've lost the ability to simply use whichever javascript components I might feel like using, or I have to design components specifically using GWT, and then I am going to be propelled into the bowels of the details of exactly HOW it does that, on and on.
As for the 2nd part, I may not WANT to do things the way GWT does them. Maybe JSON isn't where I need to be at. What if I want to consume a SOAP service? No, you gotta do JSON because that is the way it is...
Even if we simply accept your 'compiler' argument and chalk it up to semantics there is a HUGE difference between gcc or javac and what GWT is doing. At that maybe you recall the endless debates, arguments, and etc surrounding c and c++ binary ABI standards of years past? Given the shifting sands of browser compatibility that one was pretty much a cakewalk.
UI and backend should be decoupled. Developers of one should not need to be impacted or deal with the details of the other. If the application is properly architected and well documented then there should be few issues. The front end guys can do their front end thing with the tools they favor and the same for the backend, and the twain shall meet over HTTP...
It isn't so much that I have any particular opinion about GWT, but I do believe I am articulating the fundamental reasons for developer's reluctance to jump into it. Certainly we here are in no hurry to jump on the bandwagon. That was the question in the OP's mind, I just answered it. The market will sort things out, and when it does, we'll be in a fine position. We can come in, or we can do whatever makes sense in the long run.
In a word the strength of the web is the LACK of coupling between client and server tier. Tools like GWT cut against that. I don't WANT to have to particulars of the server side implementation all over the place on my client side.
I probably have different teams working on each portion of my web application. Why should I wish to have such tight coupling between them?
Furthermore in my 25 years of software development I've developed a real healthy contempt for automatic code generators. Nothing is more of a PITA than having to try to arm twist some code generator when it generates buggy code that doesn't do exactly what I want. It very quickly becomes more of a liability to the project than an advantage.
No, I would rather be able to develop client side logic built to the specification of the interface with the server side. Now, I'd be a lot more enthusiastic about having a GOOD GUI development tool for javascript/css/html/xml and a client side stub generator that simply wraps the SPECIFICATION of the interface between the client and the server.
Furthermore a GWT like system has all sorts of other architectural assumptions built into it that are likely to restrict the design of my system in various ways. Good tools ALLOW appropriate design, they don't railroad you into doing things a certain way. So, no, I am not particularly a fan of this approach and I doubt I will become one in the near future.
Its an interesting debate. I consider a few factors and my opinion is that it would eventually favor a space based power.
The people in space are going to be infinitely more familiar with and motivated to understand space based operations. Inevitably their technical capabilities will surpass any possessed by Earth in that regard because the whole thrust of their civilization is going to be in that direction.
Also in the longer term I wonder just how much more expensive it will be to live on the Moon say, where energy is far more available, pollution is not a concern, there is always plenty of available room to grow, etc. 'Life Support' on Earth may not be as cheap as we might think.
Consider, once you build something on the Moon or in space, it is THERE, no wind erodes it, no floods or hurricanes damage it. There may well be many subtle advantages there. It is far too early to say what the costs and benefits really are and if they cancel out.
But one thing IS certain. It will always take 81 times more energy to launch from Earth than from the Moon, and infinitely more than from some say Amor class asteroid. And any launch from Earth must be energetic and thus can't really be 'stealthy'. I can so no potential military advantage for Earth whatsoever, only population size.
No, inevitably sooner or later the ECONOMIC equation will be that Earth has nothing to offer to your space based civilization. Its goods cannot be competitive. It would simply make no sense for someone living on the Moon to ship things to Earth, there's nothing they can get in trade save maybe a novel or a good bottle of wine. That won't be enough to hold such a civilization to the mother planet, not for long.
But to the original point. Why would such a civilization ever want to go back and live on a planet again? It would be like you or I deciding to build a house on top of Mt Everest. The view might be nice, but the daily commute would be a real bitch.
Its all about economics. Sooner or later you're going to reach the point where Earth can't continue to compete. Everything Earth does in space is going to be 10-100x more expensive than what your Lunar Civilization can do. With that kind of cost advantage going from bare self-sufficiency to supremacy would be no more than a matter of a few decades.
ROFL! The military position of any decent infrastructure on the Moon would TOTALLY dominate near-earth space.
You have limitless power and throwaway mass you can easily hoist to Earth. While Earth has to send its weapons UP the gravity well. Good luck Earth.
And pretty much ANY kind of infrastructure where you could loft more than a trivial amount of stuff off the moon would by virtue of its position at the top of the gravity well etc be very easy to weaponize.
The reverse however is not true at all. Beyond that any self-sufficient 'space colony' will virtually HAVE to have vastly greater expertise in space operations than its opponents on Earth.
There could be a historically brief phase where Earth still has dominance of cis-lunar space, but given the vast disparity in cost factors between space operations from Earth and from the Moon it would be very unlikely to persist for any significant period of time.
Within a few decades of being self-sufficient any lunar or free space facility would achieve breakout military capability, dominate cis-lunar space, and essentially dictate all terms of access by Earth. In any case once you have such a capability you just go further out into space, and if Earths messes with you, you just pound them silly with rocks which could just as easily be launched from the main belt or even much further out. It could never be a winning proposition