11 programming trends to watch

From JavaScript everywhere to everything on the JVM, new tools, techniques, and troubles are changing how developers work

1 2 3 4 5 6 Page 2
Page 2 of 6

One of the newer arrivals is CoffeeScript, a shorthand language that's compiled down to JavaScript by inserting all the punctuation that scripting-language users hate to type. The idea is so popular that there are already CoffeeScript spin-offs like Coco, Parsec-Coffee-Script, and Contracts-Coffee-Script, each of which adds its own sophisticated metaprogramming structures to make it easier to spin out elaborate code.

Some extensions are so successful they've almost become languages unto themselves. Think of all the Web developers banging out workable code with jQuery, without remembering or knowing anything about JavaScript scoping.

If that's not enough, there are experiments linking pretty much any language to JavaScript, including Ruby, Python, Lisp, Scheme, Haskell, and OCaml.

Programming trend No. 3: No code is an island

A friend once told me he was heading to the woods in Northern Michigan where his father and uncles built a cabin by themselves. It was theirs and theirs alone. They hauled the wood and the rock, and they could sit afterward and gaze at the sunset with deep pride in their accomplishment.

Writing a program used to be like this. Push the compile button, and after it churned, the code would take over your machine. Sure, it was interacting with the OS layer, but it was easier to point to a tangible thing that you built, just like that cabin. See that file with the EXE suffix? I built that one, mom.

That distinction is disappearing. Our code is living increasingly in ecosystems. Many PHP programmers, for instance, create plug-ins for WordPress, Drupal, Joomla, or some other framework. Their code is a module that works with other modules.

Sometimes the fragments are even smaller, just bits of code dropped into fields. Many Drupal modules can be customized with PHP, for example. The programmer is just filling out forms with snippets of code, not building something new that stands alone.

When these mechanisms work, the results can be uplifting. More often than not, the results are mixed. While your snippets can work well with what's under the hood, they often need plenty of debugging. In many cases, the errors come from deep inside the system where you're not supposed to be looking. And there is little documentation because no one expected you to interact with the system this way.

In the worst examples, the errors come from someone else's snippets, and there's no way to debug the two simultaneously because they own their code and you own yours. Often the best solution is to get the other programmer on the phone, of all things.

These tools often work for small extensions and simple tools that have been anticipated by the authors of the original framework. Anything else is an invitation to hit-or-miss debugging cycles. There's no substitute for having all the source code available to be read and traced with your own stack, but that's becoming less common.

1 2 3 4 5 6 Page 2
Page 2 of 6
How to choose a low-code development platform