Slashdot Mirror

First, it's probably worth noting that there is a big gap between the majority of what academia considers "PLs research" and what you sound like you're interested in, which is more inventing languages on a semi-ad-hoc basis. Things like Python, Perl, Ruby, etc., didn't come out of academia, and are not greatly studied in the field of PLs. I'm not saying this is because they aren't worthy of study, it's just how it is--- if anything I think both those languages and academic PLs could actually benefit from more mixing, as those languages take a very programmer-centric view (language as a user interface), which I think is correct, but academic PLs knows a lot more about implementing them in ways other than "naive interpreter" and avoiding weird semantics edge cases that have to be patched over.

As for what academic PLs does do, probably a bit under half of it is currently working on functional languages and type systems; I'd say Haskell in particular is basis of the plurality of current PLs research. In that context, you wouldn't really be inventing a new language, but you would more likely be finding new language features and working out both the theory and practice of how to add them into Haskell. Besides Haskell, there are also pockets here and there working on the various ML languages, Clean, and a few others.

The other big concentration is a bit more real-world, engineering-oriented, mostly involving bolting features onto existing, widely-used programming languages to bring some of the advantages of "modern" languages without changing the original language too radically. These take the form of either extended static checkers, or conservative language additions, leading to things like Cyclone, ESC/Java, and so on. The classic lint goes in this category to some extent.

A third, sort of cross-cutting concern, is anything to do with language support for multithreading and concurrency. There is obviously a lot of interest in such things lately, almost regardless of where it gets bolted in.

If you want to do any of the above three concentrations, there are dozens of schools to choose from. Do make sure you look at the specific school to see if it does a specific one, though: many schools' PLs groups are small, and if you go somewhere with two people working on Haskell, and want to work on program verification in a subset of Java, you're in the wrong place.

If you want to do something else, then you need a much more narrow search to find a specific faculty member doing what you want. One suggestion for how to find them would be to scan through the proceedings of recent PLs conferences to find papers that sound like something in the area of what you'd like to do, then find where the people who wrote those papers work. Some of the major conferences are POPL, ICFP, and OOPSLA.

One of the selling points of Unix has always been the ability to have multiple user accounts with security policies that prevent them from interacting badly. The problem, of course, is that security holes are relatively frequent. In particular, local security holes, i.e. exploits in any code that ever runs setuid, are quite frequent. That they're so frequent that people don't trust OS security at all, to the point of running separate apps in separate virtual machines, seems like a pretty conclusive determination that OS security policies have failed.

I can't help but think that one alternate route that would've ended up more efficient would be to give in and write more core software using some variety of language not vulnerable to quite as many buffer overflows and stack-smashing attacks. Doesn't have to be some big paradigm switch like using Ocaml; a C-with-some-safety dialect like Cyclone would be fine. Besides inertia, one of the main arguments against was that it adds overhead compared to straight C. But the fact that people are willing to accept a much larger amount of overhead via virtual machines to get more solid guarantees of security that the OS is frankly failing to provide is some indication that the overhead-for-security tradeoff is something people really do want.

There are some advantages to using virtual machines regardless, such as ability to migrate apps separately. But we're using them here in some cases where multiple users on the same OS really would have been the best setup, except for the fact that we don't trust Linux to be free of local-root exploits.

At the very least, using a C-like language with safety, like Cyclone, would be a reasonable performance/safety tradeoff for a lot of users compared to the current tradeoffs (which leave quite a bit to be desired). I'm guessing the main stumbling block would be reimplementation overhead (Linux already exists in C, has a lot of code, and is a fairly quickly moving target) and lack of interest on the part of kernel hackers (who have little interest in using non-C languages), rather than performance of the resulting system.

There are many misunderstandings about parallelism, as it is evident from this discussion. Some posters said that "my O/S already runs in multicore/multicpu systems, thank you very much"...some others said that some tasks are like word processing is non-parallelizable etc.

The misunderstandings lie not in what parallelism is, but what Intel and other companies are trying to achieve. The quest for parallelism is not about running lots of programs in parallel, but extracting the parallelism out of sequentially written programs, including kernels. In order to improve performance, any parallelism that lies in our applications but is not exploited right now must be utilized, if we want to see real improvements in the future.

Modern CPUs do many tricks in order to increase parallelism, like pipelining and out-of-order execution. Current research at Intel has produced an 80-core CPU. It is highly unlikely that any of us will run 80 programs simultaneously tomorrow, so either this research is for servers only (highly unlikely because Intel will need to sell a lot of these chips to cover research expenses), or Intel knows that programs can be parallelized even more.

Compilers can not identify all possible parallel paths of execution, because it is an intractable problem. Writing complicated multithreaded programs using threads, semaphores and mutexes is quite difficult. So what is needed is another software architecture that allows programs to be easily parallelized.

Ericsson has dealt with these problems a lot time ago, and the result was Erlang. Based on the Actor model, Erlang programs can contain thousands of objects working in parallel, and the programmer need not worry about how to lock/unlock resources.

Microsoft's only option is to ditch C and use another language for their O/S. C can not work with the Actor model, unless modified. The best option for them is to make a C-like low-level language that includes the Actor model as part of the language specification. They can combine Cyclone, a version of C which is safe, with the best parts of ADA and Erlang, and come up with a language which allows the easiest possible path to writing parallelizable programs. And there is a big opportunity for them to put bounds checking and garbage collection to all their code, so as that two basic problems (buffer overflows and wild pointers) are solved at last.

Cyclone is a dialect of C that uses a type system to guarantee zero buffer overflows. Of course, this means a few operations will be slower than C, but the slowdown shouldn't be too bad considering that Cyclone was designed for efficient systems programming, like writing drivers.

I believe it's open source and contains safe C library wrappers as you describe.

Since most of Microsoft's bugs come from using C, it is time to switch to an altenative. Cyclone is the perfect candidate: compatible with C, yet safe.

The Cyclone programming language can be found here:

http://cyclone.thelanguage.org/

When are we going to stop writing large programs in C? For small things where potability is critical and lines of code are low, C can be a good choice for a certain class of application where low-level access and/or high efficiency is needed. However, with something massive like Firefox, it isn't possible to keep tabs on things. The result is a number of security holes surfacing constantly -- Not an ideal situation. Why not move to a more secure language like Cyclone? Programmer portability in such a situation is high and entire classes of bugs would disappear. The performance penalty would be minimal.

Why aren't more people using such language? Why not use Cycling, or even higher level languages where they can reduce lines of code and keep things more maintainable in less performance critical sections? I can only attribute it to laziness and blubism:

"As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub." - Paul Graham