Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Jon is right in saying that “[d]ifferent tasks suit different languages and paradigms.” However, there are a few considerations that are largely independent of the domain. These mostly concern syntax but since code is read more often than written, I actually think that syntax matters.</p> <p>For one thing, and something that many languages do wrong, it's completely arbitrary to base the syntax off C. C actually has an exceptionally bad syntax. I'll just pick two examples.</p> <p>The first is quite uncontroversial: semicolons are unnecessary. Take the following code; the grammar is completely unambiguous and easy to parse for a compiler. Neither semicolons nor explicit line continuations are necessary.</p> <pre><code>answer = 42 fraction = answer * 2 / (answer + 1) Console.WriteLine( "Some funny number: {0}", fraction ) </code></pre> <p>This is actually quite similar to Python but even more permissive: the definition of <code>fraction</code> spans multiple lines. This is logical since the first line isn't yet complete.</p> <p>Another bone I've got to pick with C-like syntaxes are their largely implicit variable declarations. Instead of announcing clearly “I'm declaring a <code>variable</code> of type <code>Foo</code>,” all they whisper shyly is “<sub><code>Foo var</code></sub>”. Since <code>Foo</code> isn't even a reserved word in most cases, the programmer isn't offered a single visual hint here. I prefer VB's explicit <code>Dim var As Foo</code>, even thought he keyword used here is, well, quite dim.</p> <p>(C++ actually makes matters much, much worse by introducing a lot of nearly identical and often ambiguous syntaxes that mean completely different things, from variable initializations to function declarations).</p> <p>Another thing <em>my</em> language would have to have is static typing. It's true that dynamic typing <em>has</em> its uses but they are surprisingly rare. Even most “scripting languages” wouldn't really need them. I think that this is often confused with <em>implicit</em> typing which has rather more uses. Take (again) the example of Python. Why doesn't it offer static typing? It's already strongly typed, statical type checking would only be consequent, and would cut down on debugging quite a bit. The same goes for explicit variable declaration. I fail to see what advantages implied variable declaration offers.</p> <p>So there we've already got an outline for a language:</p> <ul> <li>Clean syntax, avoid historical clutter. In particular: <ul> <li>No semicolons</li> <li>No explicit line continuations à la VB</li> </ul></li> <li>Explicit variable declarations</li> <li>Static typing</li> </ul> <p>Furthermore, I'm a huge fan of certain C++ concepts, such as general-purpose templates, RAII (i.e. avoiding garbage rather than collecting it), immutability and the concept of value ranges defined via iterators. I've stated elsewhere that I believe iterators to be one of the most fundamental innovations ever. Give'em a little lipstick and you won't even recognize the ugly beast that is C++:</p> <pre><code>for i in MyVector: print(i) </code></pre> <p>rather than</p> <pre><code>for (typename vector&lt;T&gt;::const_iterator i = MyVector.begin(); i != MyVector.end(); ++i) cout &lt;&lt; *i &lt;&lt; endl; </code></pre> <p>Of course I'm aware that the above syntax is offered by many languages. But they all only offer watered-down versions of C++' powerful iterator concept (to use C++ terminology, the only kind of iterators that most languages know are input iterators, which are basically the least powerful iterators).</p> <p>At this point I should probably say that the sole copyright for all these ideas is mine, patents pending (in particular for the <a href="http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&amp;Sect2=HITOFF&amp;d=PG01&amp;p=1&amp;u=%2Fnetahtml%2FPTO%2Fsrchnum.html&amp;r=1&amp;f=G&amp;l=50&amp;s1=%2220040230959%22.PGNR.&amp;OS=DN/20040230959&amp;RS=DN/20040230959" rel="nofollow noreferrer"><code>MayOrMayNotBe</code> operator</a> that doesn't really compare object references).</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload