gdp

Which API are you talking about?

I don't mean to sound condescending, but following the general tone of your post, are you sure you know what an API is?

The take-home point for me was that the execution model for Javascript is inherently poor security-wise. Changing this would require changing the semantics of the language (i.e. you would break most Javascript code in existence), at which point it essentially ceases to be Javascript (unless you want to start to argue about replacing axe handles and such, but the original point stands - you could take a new language which fixes the execution model and call it "Javascript", but it would still not be the Javascript we use right now).

Right, but that's just a social distinction. It does nothing to protect users from careless web developers, and it does nothing to help web developers be less careless.

Please, somebody think of the users!

There are obvious technical solutions to this, but people seem unwilling to acknowledge that they might even be necessary.

What is 'trusted' javascript though?

There is no differentiation between 'trusted' and 'untrusted', which I think was the point that the presentation was making.

I said as much in the blog comments, but I'll repeat it here too. The issues noted in the presentation, plus the fact that the language is a bit of a dog, is why I suggested proof-carrying code as a replacement for Javascript:

http://www.plsadventures.com/2009/08/worrying-trends-in-prog...

(and got pretty well flamed for it, too)

TV will always have a place as something people can twitter about in real time.

Well, sure, I wasn't hoping that somebody would say "this already exists and here it is" (though that might be nice) - I was saying "here's something that would improve my life". Maybe I'll even take the time to implement it one of these days!

I didn't enumerate the reasons that I don't use dynamic languages, because that would have been flame-bait territory.

I see this suggestion as a way in which static languages could be better at prototyping in the same way that dynamic languages sometimes are, so I think you noticed my (implied) assumption that there was something desirable about this idiom that is not as readily achievable using existing methods in languages like ML or Haskell.

That said, I can't see that there is any reason why what I suggest wouldn't be useful in a dynamic language, too. The implementation details just change a bit.

Even bringing dynamic languages into the conversation was an just to counter to people saying "Use ___" where ___ is one of Python, Ruby etc, which is basically a non-solution for my purposes.

> Next time I'll run into someone I'll first ask what school he attends and who is his advisor instead of arguing about what he semantically meant describing his field.

If you actually meant the reverse of that, then I agree that would be a far superior topic of conversation than school of origin or advisor.

> Amichail said SPJ is not member of that community and that's perfectly true.

My argument was that it is impossible to exclude SPJ from any sensible definition of "theoretical computer science", unless you are taking those words and re-defining them to mean something other than what they actually mean as a collection of words.

I accept that there may be a group of people who call what they do "theoretical computer science", and who believe that nothing else is "theoretical computer science", but in that case, the onus is on those people to remember to translate "theoretical computer science" as a term into "complexity theory" when they talk to people outside the complexity theory community, because the rest of us have a much stronger claim to the general meaning of the term, which encompasses both this idiosyncratic use of "TCS" as well as all of the other things that it can correctly be taken to mean.

Allow me to make my argument entirely concrete:

Let's say that I do "organic chemistry" and I go to organic chemistry conferences with other organic chemists. Obviously there are other sub-branches of chemistry. If I decided to stop calling what I do "organic chemistry" and start calling it just "chemistry" instead, to the exclusion of any other kind of chemistry, you can understand why people would be very confused (and probably a little annoyed) when I start telling them that Alfred Nobel wasn't a chemist.

I will go even further to say that the test for a sensible definition of "theoretical computer science" is probably which people it includes, and SPJ would probably be on that list, IMHO (along with Hoare and Milner and countless others who are excluded by this supposedly widely-held definition).

And I really don't think it's widely-held outside of the community that calls itself the TCS community, which by definition, doesn't make it a "widely held view", does it?

I think the distinction is useful as it stands. Given that a lot of computer "science" is an applied "science" (I use scare quotes deliberately because I think some of the "science" content is dubious), the "theoretical" distinction makes it obvious that you're talking about a theory of computer science, not the application of those theoretical concepts to create things.

> It is my experience that people in casual conversations automatically assume topic to be complexity theory, despite I'm in Europe.

What one community decides to define itself as isn't really a concern of mine. I'm also in Europe and I've found that "theoretical computer science" is pretty widely understood to mean the kinds of things I'm arguing that it means.

> It would be a bit like calling category theory a "theoretical mathematics"

So why would it make any more sense to apply it to complexity theory? It's not like work on languages, semantics or logic are any more "applied" than complexity.

I did read the thread, thanks.

The "contrast" is being highlighted, but I can't see anyone in there seriously advancing the idea that all of the things I've described aren't "theoretical CS" - they just suggest that there aren't many people in the US doing them. One commenter rightly notes that there are plenty of people doing the kind of "theoretical CS" I'm talking about at CMU, for example (and I can think of a handful of other places doing similar work in the US).

So I stand by my original assertion: the definition of TCS as being exactly complexity and algorithmic analysis is a particularly narrow definition that is inconsistent with the way in which most people use and understand "theoretical computer science".

I kinda switched off before the flame-bait portion even started.

The first few paragraphs of text appear to be confusing Lisp/Scheme with 'functional programming' as a paradigm, and making an argument about one using the other. There would be nothing easier about "modifying the way the compiler generates code" in OCaml than in C or anything else (assuming a well-written compiler in each case).

> You're wrong in the "not shared by many" part.

At least the first dozen comments on that link support my position that programming, logic and semantics are all "theoretical computer science". You appear to have produced an example of one person questioning whether his definition of TCS is too narrow, and then pages of comments from people telling him that it is.

What was your point, again?

Purely anecdotal, but does anyone else notice while browsing around even the (largely static) unauthenticated pages that the generation times are a bit lousy?

So your assertion is that theoretical computer science is complexity theory and algorithmic analysis?

How about any of these?

Semantics

Concurrency theory

Theories of refinement

Type theory

The Curry-Howard Correspondence (and results derived from it)

(Finite) automata

...

Shall I go on?

Those are all "theoretical CS". Programming language theorists qualify as "theoretical CS" practitioners in most cases. Simon Peyton Jones certainly qualifies.

I think you have a strange, narrow definition of theoretical CS that isn't shared by many people.

Because there is no objective measure for "quality" within an individual implementation within a language. The best we can hope for is some guarantee that people know what the tools and techniques available to them are, and that they know the factors that influence software quality.

That would be more valuable than being language certified.

I'm with you on this one.

Oh, duly noted. That wasn't obvious to me from my initial reading of the article.

That said, that's certainly contrary to my experiences. Most smart people are suckers for interesting research, and if you're doing something interesting, people will feel like discussing it.

Of course, most people often like talking about their own work more. If that's really a concern, just school up on the work of a few people and ask them about their research in a semi-intelligent way. It's just human that we're often much more interesting to ourselves than other people are.

You're talking about programming and creating programs. That would be a really, really useless certification.

You appear to have inferred incorrectly that I am talking about safety critical work.

I am not. I'm talking about anything that people are expected to spend money on. The certification passes to the software, and then users are capable of making slightly more informed decisions.

I'm a formal methods geek, so I generally advocate theorem provers for stuff which is actually safety critical. To me, certification of developers would just be a way of lifting the general quality of the non-safety-critical stuff that still has the opportunity to cost people lots of time and money.

Think about viruses, for example. People complain about viruses causing millions of dollars of damage.

The virus didn't actually do any damage. The shonky programming that allowed the virus to propagate in the first place did.

And that's why certification is important. Hopefully it would at least ensure that people writing software are familiar with the issues that can affect software quality.

No, hiring on the basis of a certification would be silly. Declining to hire on the basis of a lack of certification might not be.

Here's a basic idea. It might be one of many:

Software x has been developed in the following way (explained here). Which of the following are not valid statements about x?

1) x is free of defects 2) We can have confidence that x will work under these circumstances <...> 3) ...

I mean, sure, you would need to contrive a proper example, but that is the kind of thing I am advocating. It should be a test that a competent developer who actually thinks about quality at all should be able to pass without much in the way of study or "extra work". People who do not think about the quality of the software they produce would need to learn about these issues.

OK, you've fundamentally mis-represented what I've said.

You're talking about programming - I'm talking about certification of software engineering. They are two separate-but-related concepts.

A certification should not be "Joe knows the syntax of language X according to some test" - it should be "Joe is familiar with this range of techniques that can be applied to produce higher-quality software". These are reasonably easy things to test, and their presence or absence is not related to intelligence or programming skill.

Whether (as employees) these programmers actually are expected to apply these concepts is irrelevant. The fact that everyone knows what everyone else knows leads to a basic assumption that you either are applying some good software engineering techniques, or you have examined the reasons why you are choosing not to apply them.

The problem is that we have developers who are perfectly capable of writing good quality software according to some development practice, and developers who don't even know these things exist. If everyone knows what everyone else knows (and users know what developers are expected to know), then we start getting some pretty good assurances that people have at least considered these issues.

And that's worthwhile.

> And there will always be talented, passionate developers who don't test well or don't see the need to memorize something that Google could reveal in a single search or who just think that the certification process is bollocks.

Any certification process that simply involved rote learning or which could be googled wouldn't be worth the paper it is written on. I'm certainly not advocating that.

> Just because Joe has a piece of paper saying that he knows X, Y, and Z doesn't mean that Joe isn't going to take shortcuts that end up costing the company thousands or millions of dollars (or human lives!).

Sure, certification doesn't do away with the need for QA and internal processes. It just ensures that anyone producing software that targets certain markets will have a basic understanding of which corners they are cutting. The government, for example, could mandate that they will prefer suppliers who have a certain percentage of certified developers. Playing an averages game, that at least means that somebody in the company is going to know when corners are being cut, rather than just having a group of people hacking along.

> Because Joe has this piece of paper, companies may be lulled into thinking that they don't need to test him as hard or give him as long a trial period before entrusting him with critical systems.

As I said before, the assurances provided by certification are not for the benefit of employers, they are for the benefit of users. If your hypothetical company actually did this, then they would be a very dumb company.

That's just an example of a bad certification process. Being able to provide an example of bad certification does not invalidate the entire concept.

Degree programs that contain certain requirements could be accredited as being equivalent to a certain certification.

Not all degrees programmes include even the first thing about software engineering - they have plenty of programming, but nothing that would actually ensure that people have a systematic approach to software development.

No, tests ensure certain functional behaviour under one input.

Certification would ensure that Joe is capable of writing tests that actually test anything, for example.

> You're making one huge assumption here: that the certification actually certifies anything at all. As a matter of fact, it does not. Certifications are useless. Having or not having a certification is no indication of presence or lack of programming skill.

Bet you're not a fan of driver licensing either, right? 'cause a driver license is no indication of the presence or absence of driving skill, either.

Oh, wait, yes it is.

> What about certifying the software that Joe the developer creates, rather than Joe the developer?

There's a simple reason why - it costs x to certify 1 developer, and y to certify a piece of software.

For most software, "y" is still too expensive to offset the potential damage caused by software failure (compared to a jetliner, where the potential cost is huge).

A programmer may create hundreds or even thousands of pieces of software during a career. Average x over that number of projects, and it's negligible. Multiply that number by y, and you have an enormous figure.

Also, the cost of certifying a piece of software to provide any kind of assurances of quality is time consuming and expensive. Compare this to a certification that shows that anyone who wants to claim to be a "software engineer" actually knows the first thing about software engineering, and is at least capable of producing software in a systematic way.

It's just like we license drivers once and assume that that basic level of competency will ensure "quality driving" on a variety of road types. We don't certify each driver for each road individually.

I agree that the existing certification programs may be lacking, but I don't think that negates the need for them. It just means we need to come up with better certifications.

That's actually true of computer science in general. Ever turned up to a web conference? Or an OO conference? or a Java conference? I guarantee you that I feel as out of place and excluded in any of those forums as I'm sure you do in a theory conference.

The thing about any "community" that is well-defined enough to justify having its own conferences is that it has its own set of foundational assumptions and jargon, and conventions. If you don't know these things, you're going to have trouble participating at a high level.

I don't think it's so much that people will not "pay attention" to you - it's probably just that what you are saying isn't very interesting. The thing about non-theory CS people interacting with theoretical CS people is that they usually present exactly the same arguments/problems/ideas that everyone else does. Believe me, you get _really_ bored by the seventeenth time you have to address the question "but what if the theorem prover has bugs in it?!", pronounced with the swagger of someone who believes they have just hit upon a novel idea.

I imagine that if I turned up to a gathering of high-energy particle physicists, I don't think they would pay much attention to my thoughts on the subject either.

It's not dismissive behaviour, either. It's actually just a common mistake within CS to believe that you can turn your hand to any part of CS - you're essentially participating in a very high-level discussion.

To answer the original question, I've found people in the top echelons of theoretical CS to be extremely patient and friendly.

I asked some really silly questions of top researchers (in one-on-one or small group situations) as an undergraduate that probably deserved to be answered with disdain - I still cringe in retrospect. The most biting retort I ever got was "Oh, that's covered in <such-and-such-a-paper>, which is worth reading if you're interested in this". Hardly a telling-off. For the most part, people have always taken the time to explain things from first principles, or re-state them in ways that I could understand.

The idea of the ivory tower is a bit of a misconception. You're talking about very, very smart people who are usually more than accommodating when it comes to answering genuine questions or just engaging in discussions. I would jump at the chance to talk to them about anything and everything - it'll be interesting to say the least, and they are some of the nicest people you'll meet in CS.