No problems, I'm just genuinely interested in the arguments.
SQL obviously isn't a general purpose language, and it needs the procedural extensions to behave like a third generation language.
But what is the arguments for it not to count as a programming language?
Seriously, languages are all pretty much the same, with some syntax and operator differences. Even SQL is pretty much the same between the different database systems, again with some syntax differences and availability of built-in functions.
The REAL difficulty and learning curve is using the myriad of frameworks and libraries. WinForms, WPF, MVC, regular ASP.Net, Entity Framework, nHibernate, Lightspeed, Telerik, SyncFusion, CodePlex, etc, etc.
There are almost two dozen ORM frameworks available, and almost as many UI libraries for every imaginable platform. It's freakin crazy.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
And one level removed... It's the analysis that is key.
I got a job doing Clipper Programming with ZERO Clipper experience, by explaining that the CORRECT thing is to first TRULY Understand the What and the Why of the changes to the software. To spend an extra amount of time solving the right problem properly. I pointed out that in the past, he probably had the SAME BUG show up in multiple places, or requiring multiple changes to get removed. Very common, and the cause is having not solved the problem properly.
I proposed that code should generally be error free, and that should be the first goal before you write a line of code in any language.
I got the job. And after a year of part-time college work-study work on the project, my hours dropped to near zero. He actually felt bad, because I had programmed myself out of a job. Something he did not think even possible, until he realized that had the code be written this way from the start, he would have NEVER NEEDED a programmer to maintain it!
I answered 4-6: C/C++, C#, HTML/CSS, Pascal, and [shudder] .BATch. Those are the languages I use often enough today to maintain proficiency and to apply in production code without hesitation.
I've used a lot more languages than that in my time: several dialects of FORTRAN (back when it was an acronym for FORmula TRANslation), Ada, PL/I, too many assembly languages to count, BASIC, numerous scripting languages from IBM JCL through VAX/VMS DCL and more, LISP, and so on. Most of these I can still read. I probably couldn't write them without a moderate amount of time to refresh.
The O.F.V. is that programming languages are simply different tools in your toolbox. Some are more appropriate for a given task than others, and we all don't have the same set available. Many programmers pride themselves on having working knowledge of a lot of languages and using the most elegant approach to solving a problem. For others, we have a hammer and everything had better look like a nail. Both views are valid if you apply your tools correctly and solve the problem to the user's satisfaction.
The first is the algorithmic one, with dialects running from Algol60 through Pascal (and Concurrent Pascal and Object Pascal), Simula, Fortran, Chill, C, C++, C#, Java, ... Count Basic in as well (in umpteen variants). And a few proprietary ones (Planc, NPL).
Then comes the workspace/array based APL. Others in that group I am not familiar with.
And the list/inference languages - I put Lisp and Prolog and SNOBOL in the same group. Lots of people will protest, but they really are much the same way of thinking.
Maybe XSLT goes in the Prolog/Snobol group (it is actually closer than Lisp), or maybe it is on its own. I never became comfortable with it, though.
If you finally throw in assembly language, ranging from Univac 1100 series through 16-bit minis and superminis (ND-100/ND-500) and the x86 family, we are up to five. But I do not consider assembly programming modern multi-core, heavily pipelined CPUs fit for human brains - that is done so much better by compilers.
First, good poll question... it made me actually think about it.
1. BASIC or its progeny; I started in BASIC on a Commodore PET, then a C-64, VAX/VMS, VB 4 and then up through VB.NET to current.
2. Fortran; spent quite a bit of my career working in Fortran on VAX/VMS to OpenVMS
3. SQL - specifically SQLServer; I may not be current with it, but I can still produce production quality solutions
My career has largely been driven by service type applications; behind-the-scene type stuff. I rarely do visualization, and, if I do, it is with vendor provided applications.