Create a web resource that provides a quick reference for different programming languages, based on how common programming idioms are expressed in them. The idea is to compare by saying: "If you write this in C, you'd use this in Perl". Using this resource should make it easy to learn a new programming language by referring to a language one already knows. A key criteria should be conciseness, but pointers to further information should be provided as well.
Often it is much easier to learn a programming language by comparing it to one one already knows that from scratch. (See this example.) This resource would developers to quickly pick up a new language by looking up and comparing key features.
The project should cover features that range from simple syntactic constructs (“Where do I put the semicolon?”, “How do I do comments that extend to the end of the line in C#?”, “What is switch() statement’s name in Perl?”) to types (“Which C# type corresponds to Java bytes?”) to API functionality (“How do I do associative arrays in Python?”). A typical comparison might be:
|
|
C |
C++ |
Perl |
|
for loop, integer index |
int i ; for (i = 0; i < 10; i++) { body; } |
body; } (*) |
body; } (**) |
In addition, the resource might provide useful footnotes and alerts that could be color-coded/hyperlinked, for instance:
(*) i’s lexical scope is the body of the function. Some older C++ compilers will erroneously place i in the scope of the surrounding function.
(**) my creates lexically scoped variables in Perl. Compare to local.
Conceptually, the resource could be thought of as a table: rows corresponds to a specific features, and columns correspond to languages. Groups of rows correspond to specific groups of features, such as syntactic constructs, types, certain API functions, etc. Groups of columns could correspond to families of languages.
|
|
L1 |
L2 |
L3 |
L4 |
L5 |
L6 |
|
F1 |
|
|
E13 |
E14 |
E15 |
E16 |
|
F2 |
|
|
E23 |
E24 |
|
|
|
F3 |
E31 |
E32 |
E33 |
|
E35 |
E36 |
|
F4 |
|
E42 |
E43 |
|
|
|
For example, language L3 might provide feature F1 through F4, which is shown in examples E13 through E43. Feature F1 is supported in languages L3 through L6. Some groups of features will be supported by some groups of languages: for instance, all object-oriented languages will provide support for features related to inheritance.
Examples should show the relevant fragments, but they should be linked to actual source code files developers could download and run.
If the project is successful (that is, it is being widely used as a resource) advocates of a given language may wish to contribute entries (“columns”) for their language of choice. Support for adding columns should be added in a fashion similar to collaborative editing systems such as Wiki. Allowing for extensibility and collaboration in this way requires a balance between allowing contributors to creatively shape the entries they add on one hand and maintaining a concise and uniform presentation on the other hand. (A markup language could enforce the latter.) Similarly, contributors should be able to add rows that may highlight how a certain language supports a certain feature.
Users of this resource should be able to create their specific view that includes the languages and features they are interested in.
The implementation will be web-based. Different technologies are possible (databases, XML, etc.). However, ease of hosting is important.
[My personal opinion is that: ] It seems likely that this application could benefit from extensive use of Javascript/Dynamic HTML. The main advantage of using Javascript is to reduce the number of interactions with the server (and the often user-perceptible delay this incurs!).
A second advantage is that changes to the view can be done locally (for instance, displaying/hiding/collapsing/expanding columns/row) It may also be possible to put the control over the interaction with the server fully in the hands of a client-side library, as is done in the Gmail email client. (See this article for background on how to do that: XML Http Request Object.) In this model, the Javascript-client would retrieve blocks of information from the database as needed/required by the user. This would have the side-effect of lightening the load on the server since on those blocks would be retrieved that a user wishes to see.
A third reason for using Javascript is to allow for better presentation, for instance by using such libraries as Overlib that provide support for tooltips. (See the references in this paper as an example.)
There should be a glossary that defines terms used in the resource. Terms should be hyperlinked to entries in the glossary.
A nice extension to the project would be a translator that would allow a user to enter a fragment written in language X and obtain the equivalent fragment in language Y. Such translator could be provided as pluggable add-ins.