addressalign-toparrow-leftarrow-rightbackbellblockcalendarcameraccwcheckchevron-downchevron-leftchevron-rightchevron-small-downchevron-small-leftchevron-small-rightchevron-small-upchevron-upcircle-with-checkcircle-with-crosscircle-with-pluscrossdots-three-verticaleditemptyheartexporteye-with-lineeyefacebookfolderfullheartglobegmailgooglegroupshelp-with-circleimageimagesinstagramlinklocation-pinm-swarmSearchmailmessagesminusmoremuplabelShape 3 + Rectangle 1ShapeoutlookpersonJoin Group on CardStartprice-ribbonShapeShapeShapeShapeImported LayersImported LayersImported Layersshieldstartickettrashtriangle-downtriangle-uptwitteruserwarningyahoo

Language Attributes Discussion

What characteristics do we use to describe languages? What's "dynamic" and what's "static", and to what languages can we apply this label? How does this help us compare-and-contrast different languages?

 

From Jay (our presenter):

 

On Software Language Design: Hits, Misses, and Trade-Offs (formerly Language Attributes Discussion)

There are many websites that compare different programming languages in different ways. 
* Sites that offer program snippets for different languages (e.g., rosettacode.org). 
* Sites that compare language syntax or semantics. 
* In tabular form (e.g., http://hyperpolyglot.org/). 
* Diagrammatically (e.g., http://dafoster.net/articles/20...
* Sites that disclose “hidden features” (e.g., http://beerpla.net/2009/06/21/h...)

But a rote comparison of language attributes is only a first step. Software engineers should strive to be able to compare features across languages, know what alternatives exist, and what trade-offs they represent. And most of all, how features can best work together to suit the use cases of targeted portions of the developer community. There have been many articles explaining differences between the most popular languages, C++ and Java, partially due to Stroustrup's The Design and Evolution of C++, and to Java's JCP & JCRs. So I'll try to focus elsewhere.

Some language design hits: 
* Most language innovations over the years: IOC, QuickCheck, Templates, VMs, xUnit, etc. 
* Language design evolution support: JCP/PEP, Boost (C++ features).

Some language design misses, or ideas that have jumped the shark: 
* NULL in most OO languages (not including NULL in SQL) 
* C++'s export keyword (Turned out to be less useful than hoped.) 
* Deprecated features

Some other things that should be kept in mind when comparing languages and language features: 
* Punctuation and syntax are limited resources. 
* Most common mistakes made by experienced users? (= vs. ==, forgetting semi-colon, etc.) 
* Undefined behavior. (C has lots of this, but it's less prevalent in newer languages.) 
* Support for OO, FP, GC, DSLs, higher types & kinds, (co-)monads, etc.

Some strategies: 
* Turn implicit code into explicit, then back to implicit differently. For example, type-checking. 
* Turn typographical conventions into syntactic rules (e.g., Capitalize type names). 
* Turn syntactic conventions into semantic rules (e.g., have syntax constraints allow the meaningful addition of non-ASCII characters to identifier names).

Lastly, I'll present some “crazy ideas” for new languages or modifications to existing ones, in the hopes of fostering some lively discussion.

As I said above, feedback and/or discussion welcome.

 

 

Join or login to comment.

  • Michael S.

    One thing I wanted to tack on:

    It's likely this was found somewhere later in Jay's slides than we got to, but I wanted to mention that I too often find to be overlooked when evaluating language design is code evolution.

    This means that you're thinking about stuff like:
    a. The habits that the language encourages in your code and its dependencies, and what they mean practically for the quality of your software and the efficiency of development.
    b. How the language saves you from changes causing bugs.
    c. Tool support - how easy is it to make big changes?

    I think that dynamic languages tend to fall short when considering this. While you can somewhat address point (b) by writing tons of tests, this does not account for differences in runtime environment, or any corner cases you forgot. Also, types nicely provide the domain for tests (quickcheck).

    Dynamic languages are flexible, something that you can only get with good static typing, sacrificing some simplicity. Well worth it!

    September 5, 2013

  • Michael S.

    Hey! It was very interesting to talk to y'all about languages yesterday!

    Here's an email thread about Alan Kay's VPRI / STEPS project report: http://www.mail-archive.com/fonc@vpri.org/msg04303.html - that's why I said that the report was being eagerly awaited - I'd seen discussion of it so recently! This email list can be quite interesting, in general. A related list is augmented-programming: https://groups.google.com/forum/#!forum/augmented-programming.

    September 5, 2013

  • Chris B.

    I don't remember if I mentioned this last time or not, but earlier this year, I read a really good book I think a lot of sealangers might be interested in: Understanding Computation[1], by Tom Stuart. In it, he walks through building a language from nothing and a bunch of other cool computer science. If anyone else has read this or wants to borrow my copy, let me know. I would love to talk about the topics discussed in the book.

    [1]: http://shop.oreilly.com/product/0636920025481.do

    September 4, 2013

    • Ted N.

      I got a copy from ORA; I'll bring it next month and give it away. (Forgot to bring books this time. Sorry.)

      September 4, 2013

11 went

People in this
Meetup are also in:

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy