Hacker Newsnew | comments | show | ask | jobs | submit | sgt101's comments login

Amazing! I had no idea at all!

Is it real? Why are there no movies?

Talk about heroic....


here's a reference

http://en.wikipedia.org/wiki/Mycin#Practical_use

-----


Yes, and it was a real research collaboration - a brilliant insight - to see that the Jeopardy language was constrained and tractable to analysis that would allow a mapping to a solver.

I have not been involved in these efforts or the community closely enough to say, but I think that things like controlled english

http://en.wikipedia.org/wiki/Attempto_Controlled_English

and

http://web.eecs.umich.edu/~soar/sitemaker/docs/pubs/Interact...

may have been inspired by the success of Watson in Jeopardy.

On the other hand I was running a question answering question when Watson started, and the PI said to me "oh yeah, but that's cheating..."

And on the third hand we stopped and closed that project pretty well six months later.

So - there's a lot to think about!

-----


Also the world of genomics has done fantastic work on compression and if you can compress it further you will probably win a decent award with a ceremony and free booze.

-----


I worked as a C and then C++ dev for a few years and then I started a Ph.D writing a C++ code base.

I remember the day that I got java 0.7 running on my spark 20. I would never touch the STL again, never have to worry about malloc and #def overwrites. No more gdb.

There's not much nice for c/c++ devs, pity them.

-----


How many java programs are running your desktop now?

How many C/C++ programs?

-----


It might be the opposite, for corporates, this might be hardware that no one can afford not to have.

People spend a lot on hardware, and a lot on electricity. If HP can do what others can do, but at 1/4 of the cost, and they charge 1/3 of the price, then money will flow to them like water.

-----


Errrm, you are right so long as nothing changes. As soon as anything changes the merrily chugging COBOL becomes a weird frizzie step aunt from an obscure island near Antarctica and, well, stops the chugging and starts jitterbugging.

Then everyone does a "what the hell is going on" dance and wheels barrows full of cash into a carpark where "consultants" pour lighter fluid onto them and burn bonuses in a horrifying money sacrifice to the dark gods of bug fixing.

After awhile everything returns to normal.

Where did you hear the thing about fault tolerance from? Is there a seat at that bar for me?

-----


In physical engineering two principle tools are used to control projects : specifications and tolerances.

I software we have a kind of specification (generally dimensioned and rather fuzzy) but no concept of tolerance.

But also software quality seems to me to be more fundamentally about perception than anything else.

-----


The problem with software is that the software is the specification. Any sufficiently detailed software spec will need to be written in a formal language that might as well be code.

-----


I know that's received wisdom in some parts, but is it actually true? Is it true for other engineering disciplines? Is it true for hardware design? If not, what makes software special?

I think it only seems true because of the amount of money people are willing to invest in software development, relative to other ventures.

-----


It's just a property of the artifact you're building. You're designing a process instead of a product. The artifact you produce is a description of that process--code.

The closet thing I can think of is anyone who works on processes instead of products. If you look at disciplines that design processes, the larger the scope of the process, the less exact the methods to design them (mainly because the number of variables grows too large).

At one end, industrial engineers who design assembly lines have very rigorous design methodologies backed by math and empirical data. At the other extreme you have politicians designing the process of running a country, and their methodologies are almost never based on math or empirical evidence.

One way I've heard it described is kind of midway between an industrial engineer and a politician--When designing a large scale software system, you should be like an urban planner. You decide what kind of zoning you need--residential over here, commercial over there. Then you build the roads and other infrastructure that connects the various districts.

-----


I agree with your analogies, but I think that there are at least a few intermediate levels between high-level process description and code that benefit from some sort of spec. Good specs fill the gaps between the zoning and the pavement.

-----


> If not, what makes software special?

There is no ASCII representation of a bridge which is actually a bridge. Other engineering disciplines are in the business of producing matter with certain properties; the description of the properties is fundamentally distinct from the matter itself.

There is an ASCII representation of every piece of software which is actually that software: its source code.

This would also explain why "code as spec" goes hand in hand with modern, expressive languages: a sufficiently large C program is not human-readable as a description of its own behavior. If you want to create the program you intend to create, it is necessary to write a specification at a higher level of abstraction, then hand-translate that into C, and attempt to keep the two in sync.

Whereas one can read/write business logic in Ruby, Python, or whatever about as well as they can read/write a description of the same logic in English.

-----


A sufficiently large program in [any language] is not readable as a description of its own behavior. I think it's easy to fall into the trap of thinking this is not true for expressive languages like Ruby or Python, because there are precious few projects of sufficient complexity written in those languages.

If you think I'm wrong, please show me the Ruby equivalent of an os kernel or Photoshop, and I'll reevaluate my thinking.

More importantly, every program can be seen as, at some level, a description of its own behavior. But none contain a description of the system's intent.

That's what specs are for.

-----


Tolerances do come into play in safety and security engineering, and also when designing for reliability.

* What are the likely failure modes for this subsystem?

* What are the consequences if it fails?

* How much should we invest in analysis and testing of this subsystem or aspect of the software?

* When we find out about a severe issue internally (not known to the public), do we issue an "out of cycle" patch immediately, or do we wait for the next release? Do we tell customers about it?

I know there's some moral hazard in our industry, because it is rare to see software companies advising users of security problems that weren't reported by a third party.

The usual case (in closed-source) is that security issues discovered internally are quietly fixed without notifying the customer.

-----


I played wow from beta. I quit in Cata, came back in Panda and have quit again in WoD. In vanilla I saw that there was much money in the game and lo, I did say, arriveth the $$ arriveth the MBAs.

And so it was, much sadly for all when Tigole went off.

But here are the sums.

They've lasted for (on average) 5 years. 30 * $10 * 200 = $60000pcm * 60 = $3,600,000.

That is a NPV of 3.

Can i haz MBA?

-----


Yeah, but it's cheap.

-----

More

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: