Compilers and smart IDEs correct your syntax
Am I supposed to put a semicolon after the last statement in a block? Is the semicolon a "separator" or a "terminator"? Language designers have spent a long time crafting parsers that enforce these rules and -- guess what -- I don't care. There was a time a decade or so when I did care, but now the IDEs do the work for me. They're constantly watching my back and telling me when I screw up. I let them do the thinking for me and spend my time pondering the big questions about my code. The IDE is the peon, the programming assistant that handles those petty details.
Automation has saved us from the tedium of programming syntax. Oh sure, they don't do everything for us. We still need to have a vague idea of which punctuation to deploy. But most of the time, the details about the languages don't matter.
The IDEs also help with frameworks, but only the little details. They'll remind us the parameters for the function call, and they'll even check to see whether the data is the right type. After that, we're supposed to know which functions to use and how to plug them together. This is where our mind focuses when the syntax doesn't matter so much -- toward the higher-level methods and functions that will help surface solutions more expediently.
Syntax is disappearing with visual languages
While this has been predicted for many years, it's slowly happening with some -- though not all -- code. Some programming continues to be very textual, but some is becoming more visual, which means the underlying computer language doesn't matter as much.
GUI builders are the easiest places to see this. You can drag and drop user interface widgets all day and night without worrying about whether it's C or Java or anything else. The details are coded in visual boxes.
Tools like AndroidBuilder make it possible to drag and drop much of the layout, and AndroidBuilder will dutifully write the XML and Java stubs needed to make the code work. It's hard to argue that visual languages are going to be the future, especially after they failed repeatedly to realize the prophecy, but the tools are growing more visual when they can be. This means languages are a bit less powerful or important.
Code is law
Computer languages are largely agnostic. They're designed to be open, accepting, and almost infinitely malleable. They're meant to do whatever you want. Sure, sometimes you need to use a few extra characters because of the syntax, but those are merely keystrokes. After that, it's mainly if-then-elses, plus occasional clever bits. All of the language will still help you get the results you want the way you want to get them. If there are strictures, they're designed to keep your code as bug-free as possible, not limit what you can do.
Frameworks are where the power lies. This is where architects can decide what is allowed and what is inherently forbidden. If the architect doesn't want something to happen, the magic function call is missing from the API. If the architect likes the idea, there are usually multiple function calls and plenty of supporting tools. This is why Larry Lessig, the Harvard law professor, likes to say, "Code is Law."
The frameworks establish the rules for their corner of the Internet and you must live within them once you choose them. Some blogging platforms encourage linking with others through AJAX calls and some don't support them. That's why you must investigate carefully and choose wisely. It's ultimately why frameworks dominate every part of our lives, even those few moments when we're not programming.
Related articles
- Attack of the one-letter programming languages
- 9 cutting-edge languages worth learning now
- 10 battles raging for the hearts and minds of developers
- Download: The professional programmer's business survival guide
- Download: 2015 Technology of the Year Awards
- Download: 29 tips for succeeding as an independent developer
- Review: The big four Java IDEs compared
- Download: Hands-on with 10 JavaScript editors and IDEs
- PHP vs Node.js: An epic battle for developer mind share
- 15 technologies changing how developers work
- 12 predictions for the future of programming
- 15 hot programming trends -- and 15 going cold
- 10 capabilities we want to see in HTML6