A programming language is similar to any other kind of software, in the sense that it have users, uses cases, pro/cons. From the language POW, we are the end-users. But not necesarily, the *targetted* end-users.
INSTEAD of regular software, it have very
strong lock-in. Not only are constrained by platforms (ie: You can't use java in iOS, not
cleanly), but also, by their syntax (how write & read it, and this is a very
problematic issue: The syntax is a huge deal because it constrain how you can use the language) by style (functional, procedural, object-oriented, declarative, concatenative, etc: All of them different, and some are the opposite of the other), by their performance, and a lot of little & big details.
The lock-in show up in that is
expensive to write, document, understand, debug, maintain source code, run the actual software (ie: Some languages create software that demand more memory, so in a web server, you could need a more costly hosting) and other stuff.
A lot of software is build on top of languages with very bad "end-user interfaces" (like C, C++, JavaScript) that cause HUGE amount of problems, and waste of millons $$ and time. Unfortunally, "fix" a language is
serious bussines, because, as I explain, the lock-in is
damm hard: Nobody wanna to re-write the code to solve anything. Is like write a novel, then 2 years later better "words" and "prose" is discovered then go back and rewrite it...
A lot of the stories about software security problems, software hacked, software crashing, etc is directly tied to the issues that C, C++, JS and others have. They demand not only *skills* but a lot of discipline.
Programming is
VERY frustrating.
Unfortunally, the mayority of the developers are resistant to change (and the worse? Hardly aknowledge that change is necesary in first place. Denial in everything you can think of, is the norm baby!), and worse, the jobs
available are largelly about continue to use what is in use
rigth now, than to move to something better. Is like a company that use Win 3.11, and deny as much as possible to move to something better. But worse: Probably can't move even if want to!
Not help at all, that learn new languages is hard (some naive people think that you can do it in a week. Very naive...) and because the past software is done in X is easier to use what the past software use than try to convert to Y.
Like trying to use Pages when before you use Word. Not only you need to learn a new software, but also the data (the document) not traslate well (sometimes, not at all, or WORSE: corrupted) and what have
pages is not exactly what have
word. Or you depend in that task X was fast before, but now is slow -except if ALL THE OTHERS things are fast, you don't care because your use case is doomed!-
So even if some language is better than another, it will not necesarily allow to translate the same concepts (ie: Not even can you do the same thing) cleanly, neither the same data (the source code or even the actual binary interface), neither have the availability of resource, libraries, documentation or man-power.
So, all of this to finally answer:
I'd love to grasp the impact in a more concrete way.
To make a example. A language is like a serie of magic spells. So you say:
And your probably expect that it mean: "Something called myAge is a number exactly 20."
So, you wanna to check if you can buy beer:
PHP:
canBuyBeer?(age (is a number)):
if age > 20
return NO PROBLEM
else
return HA! HA!
ShowOnScreen: "Can I buy beer with the age I put in myAge ?" canBuyBeer?(myAge)
And your probably could think: canBuyBeer decide that if the age is more than 20 then yes, instead no. This also mean that for this to work, age must be a number. And you probably imagine that the language is not stupid and it validate that age MUST be a valid number, like when registering to a website and checking your age, you can't say you born in 20 B.C
Unfortunally, a lot of languages have the
Billon dolar mistake, that say that
age, even if I instruc to the language that it must be a number, can be also a NULL, just because. And a NULL could crash the software, and cause death, loss of property, and other real issues. And really, I'm not exagerating (much).
Is like a web form where it say "Give me your email" and you can put a photo there, or upload all the game of trones season.
Here swift solve it because it guarantte: 1) All objects are initialized before it first use 2)If something could be NULL, then is because the programmer, not the stupid compiler, say so. And it need to be handle the case where if something expected to be something instead is NULL.
This sound a lot stupid? And this design mistake was introduced in
1965 That is how hard is to solve things in programming. And the worst? This problem WAS solved long time ago (similar to how swift do things now) but unfortunally, C, C++, JS and similar are more popular than better, saner, more productive alternatives invented decades ago.
So the signficance of swift is:
1- It solve a lot of stupid litte things that are stupid, mind you, and already solved years ago by the way
2- It have a lower barried to interface with the "old" objective-c/coccoa software, not only in meaning (can do almost the same) but also in binary interface (can use the same old software, cleanly)
almost perfectly
3- It reduce the necesity to write a lot of boilerplate code that add noise
4- It introduce several real neat things that are unknow to a lot of developers that have never used all that better, sanner, still fast, languages, without being to alien and hard to understand. Things like more mutable/inmutable control, functional coding, pattern matching and other stuff that probably will be unapreciated at first for some people, but, that are just better.
5- At whole, would produce better code, without sacriface too much.
A lot of people think that this kind of language is only to attract the stupid or total noob developer. But really, it let good developers to not waste time and not-so-good developers to not do too bad
Eventually, this must lead to better quality of the apps. Unfortunally, this will take a long time (remember, people are dealing with bad stuff introduced decades ago, unfixable in old languages) and brave (or naive!) developers that embrace better tools and ideas.
And is very important that:
6- Is possible to still use the "old" obj-c, because honestly: Swift is too young, too beta rigth now, so is a very hard sell to do a full move in one step.