Home / Programming / Hot Programming Trends—and going cold

Hot Programming Trends—and going cold

Hot or not? From the web to the motherboard to the training ground, get the scoop on what’s in and what’s out in app dev. Hot Programming Trends—and going cold, programmer should know, Hot Programming Trends, programmer trends, recent languages, recent programming languages

Programmers love to sneer at the world of fashion where trends blow through like breezes. The world of technology, rigor, science, math, and precision rule over fad. That’s not to say programming is a profession devoid of trends. The difference is that programming trends are driven by greater efficiency, increased customization, and ease of use. The new technologies that deliver one or more of this eclipse the previous generation. It’s a meritocracy, not a whimsy-ocracy.

Hot: Preprocessors
Not: Full language stacks

It wasn’t long ago that people who created a new programming language had to build everything that turned code into the bits fed to the silicon. Then someone figured out they could piggyback on the work that came before. Now people with a clever idea to simply write a preprocessor that translates the new code into something old with a rich set of libraries and APIs.

The scripting languages like Python or JavaScript were once limited to little projects, but now they’re the foundation for serious work. And those who didn’t like JavaScript created CoffeeScript, a preprocessor that lets them code, again, without the onerous punctuation. There are dozens of variations preslicing and predicing the syntax in a different way.

The folks who loved dynamic typing created Groovy, a simpler version of Java without the overly insistent punctuation. There seem to be dozens of languages—Groovy, Scala, Clojure, Kotlin, etc.—that run on the JVM, but there’s only one JVM. You can run many languages on.Net’s VM as well. Why reinvent the wheel?

Hot: Serverless
Not: Docker

This isn’t exactly true. Docker containers are everywhere. Servers are spinning up and shutting down containers all of the time. However, Docker containers are soooo much bigger than they need to be.

If you think about it, you may only write a few dozen lines of real decision-making code for that microservice you’re deploying, but you’ll need to toss in a bazillion lines of configuration to make Node.js and whatever else start up correctly with Docker. Yes, it’s all boilerplate, but that’s missing the point.

The new serverless architectures let us deploy just those few if-then-else statements that make the real decisions. Everything else is left up to the folks who are renting us the serverless platform.

Yes, we’ll be complaining about lock-in and lack of customization in a few years, but for now the serverless options seem like sweet relief from all of the devops and configuration.

Hot: JavaScript MV* frameworks
Not: JavaScript files

Long ago, everyone learned to write JavaScript to pop up an alert box or check to see that the email address in the form contained an @ sign. Now HTML AJAX apps are so sophisticated that few people start from scratch. It’s simpler to adopt an elaborate framework and write a bit of glue code to implement your business logic.

There are now dozens of frameworks like Kendo, Sencha, jQuery Mobile, AngularJS, Ember, Backbone, Meteor JS, and many more, all ready to handle the events and content for your web apps and pages.

Those are merely the web apps. There are also a number tuned to offering cross-platform development for the smartphone/tablet world. Technologies like NativeScript, PhoneGapApache Cordova, and React Native are a few of the options for creating apps out of HTML5 technology.

Hot: CSS frameworks
Not: Generic CSS

Once upon a time, adding a bit of pizzazz to a webpage meant opening the CSS file and including a new command like font-style:italic. Then you saved the file and went to lunch after a hard morning’s work. Now webpages are so sophisticated that it’s impossible to fill a file with such simple commands. One tweak to a color and everything goes out of whack. It’s like what they say about conspiracies and ecologies: Everything is interconnected.

That’s where CSS frameworks like SASS and its cousins like Compass have found solid footing. They encourage literate, stable coding by offering programming constructs such as real variables, nesting blocks, and mix-ins. It may not sound like much newness in the programming layer, but it’s a big leap forward for the design layer.

Hot: SVG on Canvas
Not: Flash

Flash has been driving people crazy for years, but the artists have always loved the results. The anti-aliased rendering looks great, and many talented artists have built a deep stack of Flash code to offer sophisticated transitions and animations. The casual games continue to be very popular. So Flash clings to life on the web.

Now that the JavaScript layer has the ability to do much of the same, browser makers and developers are cheering for the end of Flash. They see better integration with the DOM layer coming from new formats like SVG (Scalable Vector Graphics). The SVG and HTML comprise one big pile of tags that’s often easier for web developers to use. Then there are large APIs that offer elaborate drawing on the Canvas object, often with the help of video cards. Put them together and you’re left with few reasons to use Flash anymore.

Hot: Almost big data (analysis without Hadoop)
Not: Big data (with Hadoop)

Everyone likes to feel like the Big Man on Campus, and if they aren’t, they’re looking for a campus of the appropriate size where they can stand out. It’s no surprise then that when the words “big data” started flowing through the executive suite, the suits started asking for the biggest, most powerful big data systems as if they were purchasing a yacht or a skyscraper.

The funny thing is many problems aren’t big enough to use the fanciest big data solutions. Sure, companies like Google or Yahoo track all of our web browsing; they have data files measured in petabytes or yottabytes. But most companies have data sets that can easily fit in the RAM of a basic PC. I’m writing this on a PC with 16GB of RAM—enough for a billion events with a handful of bytes. In most algorithms, the data doesn’t need to be read into memory because streaming it from an SSD is fine.

There will be instances that demand the fast response times of dozens of machines in a Hadoop cloud running in parallel, but many will do fine plugging along on a single machine without the hassles of coordination or communication.

Hot: Spark
Not: Hadoop

It’s not so much that Hadoop is cooling off. It’s more that Apache Spark is red hot, making the Hadoop model look a bit old. Spark borrows some of the best ideas of Hadoop’s approach to extracting meaning from large volumes of data and updates them with a few solid improvements that make the code run much, much faster. The biggest may be the way that Spark keeps data in fast memory instead of requiring everything be written to and read from the distributed file system.

Of course many people are merging the two by using Spark’s processing speed on data stored in Hadoop’s distributed file system. Hadoop and Spark are more often partners than competitors.

Hot: Database configuration
Not: Software programming

Long ago, programmers used to joke that they didn’t know what programming would look like in the next century, but they knew it would be called Fortran. This joke was so funny they would fall off their dinosaurs and break their wooden underwear. Then they would go back to configuring a database.

And we’re still building databases today but what we think of as a “database” is now many times more sophisticated and powerful. The off-the-shelf databases will synchronize themselves across continents while offering a flexible tradeoff between consistency and speed. Some cloud services like Firebase will push new data all of the way out to web apps running on mobile clients.

Much of the serverless revolution is based on the realization that many of the cloud data stores are now so powerful that we only need to write a few if-then-else clauses to build a pretty cool web app.

Hot: Game frameworks
Not: Native game development

Once upon a time, game development meant hiring plenty of developers who wrote everything in C from scratch. Sure, it cost a bazillion dollars, but it looked great and it ran like the wind. Now, no one can afford the luxury of custom code. Most game developers gave up their pride years ago and use libraries like Unity, Corona, or LibGDX to build their systems. They don’t write C code so much as instructions for the libraries.

Is it a shame that our games aren’t handcrafted with pride but stamped out using the same engine? Nope. Most of the developers are relieved. Because they don’t have to deal with the details, they can concentrate on the game play, narrative arc, characters, and art.

Hot: Static website generators
Not: Single-page web apps

Remember when URLs pointed to webpages filled with static text and images? Then the dynamic, single-page web apps came along and replaced them all with one clever web app that would fetch the data in question. Guess what? The pendulum is swinging back and all of the kids are building static site generators. There are dozens of them. It’s like a hybrid. You put all of the data in one pile and then you write some code that sticks the data into some templates so that there’s one HTML file for each static URL and this came from each row in the table of data.

The kids think these static sites are superfast and they are. Just don’t tell them that the old dynamic systems like WordPress and Drupal worked much the same way, by keeping caches that were pretty much filled with static pages generated with the latest data.

Hot: GraphQL

It’s not as if REST is dead. It’s just that we want to do more with the API, and GraphQL is a way to do it. GraphQL returns the data in JSON, just like REST. GraphQL starts off with an HTTP POST, just like many REST calls. It’s just that the GraphQL syntax allows you to specify very complex queries with only a few keystrokes. This makes it simpler for programmers to ask for just what they want, and it reduces the amount of server-side work that must be done when someone wants a slightly different API.

Hot: Cloud IDEs
Not: Local IDEs

A long time ago, people used a command-line compiler. Then someone integrated that with an editor and other tools to create the IDE. Now it’s time for the IDE to be eclipsed (ha) by browser-based tools that let you edit the code, even the code of a working system. If you don’t like how WordPress functions, it comes with a built-in editor that lets you change the code right then and there. Microsoft’s Azure lets you write JavaScript glue code right in its portal. These systems don’t offer the best debugging environments, and there’s something dangerous about editing production code, but the idea has legs.



This post credit goes to infoworld.com

About inspirit

Leave a Reply

Notify of
Social Media Auto Publish Powered By : XYZScripts.com