October 30, 2012 § Leave a Comment
Are you a student?
Do you want to fight the good fight, for the Future of the Web, and earn credits along the way?
Mozilla Education maintains a tracker of student project topics. Each project is followed by one (or more) mentor from the Mozilla Community.
Are you an educator?
We offer/accept both Development-oriented, Research-oriented projects and not-CS-oriented-at-all projects.
Are you an open-source developer/community?
If things work out smoothly, we intend to progressively open this tracker to other (non-Mozilla) projects related to the future of the web. Stay tuned – or contact us!
October 20, 2011 § 7 Comments
(source: speaker in a recent open-source conference)
And dynamic languages are fun. They make writing code simple and fast. They are vastly more suited to prototyping than static languages. Dynamism also makes it possible to write extremely powerful tools that can perform JIT translation from other syntaxes, add missing features to existing classes and functions and more generally fully customize the experience of the developer.
Or let’s do something a little smarter.
The main benefit of strong, static typing, is that it helps find errors.
- Even the simplest analyses can find all syntax errors, all unbound variables, all variables bound several times and consequently almost all scoping errors, which can already save considerable time for developers. Such an analysis requires no human intervention from the developer besides, of course, fixing any error that has been thus detected. As a bonus, in most cases, the analysis can suggest fixes.
- Similarly trivial forms of analysis can also detect suspicious calls to break or continue, weird uses of
switch(), suspicious calls to private fields of objects, as well as suspicious occurrences of
eval– in my book, eval is always suspicious.
- Slightly more sophisticated analyses can find most occurrences of functions or methods invoked with the wrong number of arguments. Again, this is without human intervention. With type annotations/documentation, we can move from most occurrences to all occurrences.
- This same analysis, when applied to public APIs, can provide developers with more informations regarding how their code can be (mis)used.
- At the same level of complexity, analysis can find most erroneous access to fields/methods, suspicious array traversals, suspicious calls to iterators/generators, etc. Again, with type annotations/documentation, we can move from most to all.
- Going a little further in complexity, analysis can find fragile uses of
this, uncaught exceptions, etc.
Types as documentation
Types as QA metric
While disciples of type-checking tend to consider typing as something boolean, the truth is more subtle: it quite possible that one piece of code does not pass type-checking while the rest of the code does. Indeed, with advanced type systems that do not support decidable type inference, this is only to be expected.
The direct consequence is that type-checking can be seen as a spectrum of quality. A code can be seen as failing if the static checking phrase can detect evident errors, typically unbound values or out-of-scope break, continue, etc. Otherwise, every attempt to type a value that results in a type error is a hint of poor QA practice that can be reported to the developer. This yields a percentage of values that can be typed – obtain 100% and get a QA stamp of approval for this specific metric.
May 23, 2011 § 18 Comments
The Opa platform was created to address the problem of developing secure, scalable web applications. Opa is a commercially supported open-source programming language designed for web, concurrency, distribution, scalability and security. We have entered closed beta and the code will be released soon on http://opalang.org, as an Owasp project .
- Edit The video spawned a conversation on Reddit.
- Edit Interesting followup on Hacker News.
- Edit Reworked source code & comments for clarity. Thanks for the feedback.
- EditCome and chat with us on Freenode, channel #opalang .
If you are a true coder, sometimes, you meet a problem so irritating, or a solution so clumsy, that challenging it is a matter of engineering pride. I assume that many of the greatest technologies we have today were born from such challenges, from OpenGL to the web itself. The pain of pure LAMP-based web development begat Ruby on Rails, Django or Node.js, as well as the current NoSQL generation. Similarly, the pains of scalable large system development with raw tools begat Erlang, Map/Reduce or Project Voldemort.
Opa was born from the pains of developing scalable, secure web applications. Because, for all the merits of existing solutions, we just knew that we could do much, much better.
Unsurprisingly, getting there was quite a challenge. Between the initial idea and an actual platform lay blood, sweat and code, many experiments and failed prototypes, but finally, we got there. After years of development and real-scale testing, we are now getting ready to release the result.
August 28, 2008 § Leave a Comment
Start-up MLState and team SDS (Security of Distributed Systems, part of Laboratoire d’Informatique Fondamentale d’Orléans) offer a post-doctorate position in the domain of Programming Language Design, under the supervision of David Teller (SDS) and Henri Binsztok (MLState).