News: Design your own language today: Ted Neward at TSSJS

  1. By Jack Vaughan At the second day of the TheServerSide Java Symposium in Las Vegas, developer and consultant Ted Neward told an audience of architects and developers that they should study the newly arising programming languages to find ways to improve their productivity. He even suggested they take a day or a weekend to try to create their own language. The list of new languages worth checking out is long. Neward mentioned Groovy, Ruby, Scala, F#, and Erlang among many others. Neward also discussed improvements to Java. “Look to enhancements to the language you use,” he told TSSJS attendees. He pointed to Closures as a new Java technology that bears consideration. He also warned developers to prepare to learn new methods of programming in order to create truly thread-safe code in a new era requiring concurrent processing. Neward said that it is clear that some languages become ‘eternal,’ and most pass away. But things do not stand still. “We are not done,” he said, of programming language creation. The new languages bring new ideas, and can be worthwhile learning tools. This is especially true, he said, now that the creation of new languages is spreading more broadly beyond academia, and is being pursued by a large group of pragmatic, working programmers. “If you haven’t spent any time looking at Ruby .. JRuby .. Scala or any other languages running on the JVM, now is a good time to do so,” he said. What if developers get resistance from management when they try to implement the new languages? Well, Neward chides, what they don’t know can’t hurt them. Since many of the new languages can run as Java class files on top of the JVM, use of the new languages may not be obvious to some managers. Tell the boss, it’s no problem, he suggested with a wink, “Say ‘It’s okay it’s …er, Java 7,’” Although he said that Domain-Specific Languages (DSLs) are over-hyped he said the bear consideration. “Examine the idea of writing your own language. Writing a DSL is much easier than you might think,” he said, pointing to readily available parser/grammar tools. “It is worth spending some time trying it out, playing with it, because, if nothing else, you will find new ways to do everyday business kind of things.”
  2. Creating a programming language, even if it's 'just' a DSL, is much harder than Neward might think.
  3. Sorry to repeat almost all the post I did in the other thread, but those are just about the same topic. One thing I guess is important about DSL is the language part. Languages are to describe things, using a grammar and a vocabulary. For my purposes, a language may not actually need to be compiled or executed. It should be fine just to describe something. So, Human-interpreted languages are perfectly fine. In this post ( Talk about DSL ) I discuss about them, and my actual conclusion is that we do DSL every time the coding lang does not fulfill our needs. They will work for small problem solving up to architecture description. It is not to reinvent the wheel or write new Java cousin, but to allow a better way to solve a problem. For instance, this "Now, let’s go a little further: people use DSL all the time! I’ve known programmers everywhere that use encodings in strings. Have you done that? A string that contains a list of values separated by a “separator” (colon?) and the first value is the code of the operations, the other values means something and such? Have you hear of the interpreter pattern? Those are DLS in a String! Micro DSLs, something executable and some other time just to display." And you can find some other interesting points in the post. No, DSL are not to construct a full language, and you may not need your new IDE either.
    William Martinez Pomares.
    Architect's Thoughts
  4. what they don’t know can’t hurt them.[ Go to top ]

    what they don’t know can’t hurt them.
    what about other developers in your team? or developers that will review and change your code in future? will you lie to them too?
  5. Maybe it was better to have a beer this time. Guido