Slashdot Mirror
Employers Want JavaScript, But Developers Want Python, Survey Finds (infoworld.com)
An anonymous reader quotes InfoWorld:
When it comes to which programming languages are in demand by employers, JavaScript, Java, Python, C++, and C -- in that order -- came out on top in a recent developer survey. Developers, however, want to learn languages like Python, Go, and Kotlin. A survey of developers by technical recruiter HackerRank, conducted in October, found no gap between languages employers want and what developers actually know, with JavaScript barely edging out Java...
HackerRank also found gaps in JavaScript frameworks between what employers want and what developers know. The React JavaScript UI library had the biggest delta between employers and developers, with about 37 percent of employers wanting React skills but only about 19 percent of developers having them... [But] problem-solving skills are the most-sought by employers, more than language proficiency, debugging, and system design.
The survey involved 39,441 developers, and concluded that "Python ruled among all age groups," according to Application Development Trends, "except for those 55 years or older, who narrowly prefer C."
HackerRank also found gaps in JavaScript frameworks between what employers want and what developers know. The React JavaScript UI library had the biggest delta between employers and developers, with about 37 percent of employers wanting React skills but only about 19 percent of developers having them... [But] problem-solving skills are the most-sought by employers, more than language proficiency, debugging, and system design.
The survey involved 39,441 developers, and concluded that "Python ruled among all age groups," according to Application Development Trends, "except for those 55 years or older, who narrowly prefer C."
Companies want flashy pretty webpages. Developers prefer to produce something else.
I only look for jobs that use Simulink, Matlab, and embedded C/C++. But that's because I have no desire to ever be near the web front end. I know nothing professionally about TCP/IP but have CAN memorized.
Yep, my employer is starting a new project in nodejs because they want to attract "top talent" so there is a big pool of nodejs developers, over my objection that the "top talent" isn't actually in that pool in the first place (and suggested Go, as there is also a performance requirement).
But I like Basic, not C.
Guess I'm an outlier.
I would have answered the survey with the majority.
Personally I learned and started using both Python and Javascript late in my career that goes all the way back to writing assembly language on the CDC 6000 and I can't remember how many languages I used. (DIBOL anyone? APL?). As with most software engineers I read Javascript seems to be one of the most unprofessionally crafted languages ever put into wide use.
The updates to Javascript (ES5/ES6) go a long way to fixing things. However I have often wondered how much the world would be different had Python been used as the in-browser programming language rather than JS (ECMAscript) from the start.
The only problem I think Python would introduce is its dependence on white space as a syntactically significant element. That seems like a small compromise. Anyone else think this?
I don't mind javascript as language. The problem is the DOM, CSS, cross browser incompatibilities, and all the rube goldberg machines like jquery and select2.
The russian doll that is modern web programming is a nightmare. Things like jquery remind me of script kiddies who think they are cool when they use a source filter and/or operator overloading to completely redefine a language.
The hacking that has gone into things like jquery is impressive but it should never have become the standard for production code. It should have stayed in the "that's a cool hack" category.
37 percent of employers wanting React skills but only about 19 percent of developers having them
37% of employers may need developers with React skills, but they don't need 100% of their developers to have React skills. Statistics like this are nonsense. I really doubt that 37% of all unfilled developer positions need React skills. I doubt 19% of all unfilled developer positions need React skills. The whole article is full of garbage like this.
-- All that is necessary for the triumph of evil is that good men do nothing. -- Edmund Burke
Javascript runs (usually) on the browser, while Python is server side. Not really the same purpose.
Slashdot, fix the reply notifications... You won't get away with it...
Most important finding in the survey. ... Gets popcorn ... Where is everyone? ...
Guess I'm getting old.
I'd probably hack something together using Python if it was a quick and dirty job. Maybe a combination of bash, sed, PHP, awk & sed if I had the luxury of doing it properly.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Why is that relevant? Dynamic typing is retarded and every single popular statically typed language has implementations that are far faster than V8.
Why?
A web application done today makes total sense, a desktop app only makes a certain sense.
Pros of a web app: dynamic multi user interaction is baked in, most apps require real time updates when another user performs an action or something server side changes. Web applications are free from operating system requirements, operating system environment requirements, and hardware requirements (if it runs a browser it will work). You can run it on a cellphone, raspberry pi, best desktop, linux, mac, windows etc. Web pages do not require the user to download and run mysterious patch executable programs, instead you just update the website and everyone who logs in next is on the new updated version. Web pages will also exist forever more or less, they don't break because the operating system goes to a newer version, or you installed new anti virus, or you even dropped your computer down an incinerator chute (just hop on the next computer available and all your work is still there on the site).
Cons: it isn't as powerful, though its generally speaking powerful enough.
All that said, employers who prefer javascript and are moving towards this type of architecture are certainly not deserving of a bullet in the head but rather a hearty handshake for being so logical about a core business system.
Or does the "top talent" in this area prefer static typing?
Yes
Javascript has the problem that you can type obj.typo = 5 and it will run just fine, and you won't ever be notified of your typo unless there are some behavioral issues. Whereas many languages will catch that typo before you even run the code. Python, of course, has the same problem.
"First they came for the slanderers and i said nothing."
Sometimes, it's strictly about the tech. One language is superior to another for the job being done
Other times, it's about the team. If the entire team is expert at a language, there needs to be a really, really good reason to change
Other times, it's about the tools, or the libraries
Unfortunately, some times it's driven by clueless management, who have no idea how to program but still have strong opinions
Individual programmer preference is only important for personal education or hobby projects
That's why companies want JavaScript. They have huge piles of the stuff, mountains of spaghetti code, a mishmash of frameworks and Stack Overflow copypasta.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
Because Javascript is a language that was designed for adding isolated behaviors with simple scripts to web pages. It was not designed to be a language used to build application logic with.
To make it roughly capable of implementing application logic it's been mangled into a giant, hacked together house of cards mess and it shows in all the things you mention and more.
And now idiots are trying to use it to build not just front end, but back end as well. Because they only know to to use a hammer, so everything looks like a nail to them.
Node.js is the abomination that is the result of this.
Coming from the Objective-C and Swift world I get you. Coming into the language with no prior experience with it leaves a sour taste in your mouth. It didnt take me too long to figure out I would hate it with a passion. The languages is deceptive. DOM is deceptive and unforgiving for those that have never worked with. It sucks. Why do I have to install Typescript just so I can use Javascript?
Javascript has no classes (while at the same time, trying to pretend that it does). To your point about array, Javascript arrays aren't really arrays - that is, it's not a list of items. JS defines these as 'associate arrays', meaning that they can be whatever they dev wants it to be. You can also divide arrays by each other and there will be no compiler error or it might not even crash. You will still get an answer to what is in the 'array' but it won't be right. The program might crash 1,000 lines later but there is no way to trace the problem. How do you even debug a large application? I couldn't even find a method to see if an array contained a specific item, or to get the number of items in it or to test if it was empty. The " == " operator isn't what you think it is.
Where's the basic data structures? Classes? Not on your life. Inheritance? (of a different kind). Reading from and writing to files is awful. Especially when reading files other that contain other things such as data streams(i.e. pdfs, general binary data, etc).
They need to completely start over, get all the browsers to agree on a standard and force people to stop supporting older versions and upgrade to the new standard. Establish a consortium. Until then, I'm not trying again. I'll go back to Swift.
That is why the dynamic language ccrowd 'invented' (rediscovered, cough cough) unit tests and test driven development.
To bad they throw it on the staticc typed language crowed now as if we never had heared about compilers.
(For those who wonder: I only write integration tests and 'system tests' on the level of use cases, scenarios or stories. For real software, that means deployed applications, not 'libraries', ordinary 'unit tests' are in 90% of all cases complete pointless and a waste of time - in a compiled, strong typed language, that is)
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Ah, on what planet does "ESC d d" make sense to delete a line?
No one will ever convince me that any variant of vi is a good idea.
People moved from assembly mainly to dynamic typed languages like LISP and Smalltalk.
Calling dynamic typed retarded only shows how new you are to programming and how less you have grasped so far.
E.g. write a DSL in a dynamic typed language and then the same in a statical typed one. Have fun :)
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
problem-solving skills are the most-sought by employers, more than language proficiency, debugging, and system design.
Yeah. Try getting your resume past HR if you've had 15 years of problem-solving experience in a dozen different languages but not the one their shop uses.
And: TCP/IP has no 'security' build in either, that would be on much higher levels.
Actually, IPsec (initially developed as part of the requirements for IPv6, but back ported as an option of IPv4) *is* at the "Internet Layer".
(It sits at the "IP" part of "TCP/IP", right under the "TCP" / "UDP" transport layer).
But yeah, most other the other encryption is usually happening in the application layer (HTTPS, SSH, etc.)
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
No competent developer would defile their mind with Python or Go.
That's what I was thinking too. To make things more confusing, people moved from assembly to FORTRAN and COBOL, not LISP.
Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws-Plato
First of all you said dynamically typed like that is a strength, it's easier but more bug prone. Secondly, Perl. I see lots of benchmarks showing Perl near the end of the row but that is because you if you don't speak Perl you'll end up using it's flexibility to code up a bunch of array based garbage written like it's C code and include 400 spam modules to "avoid reinventing the wheel." When you load a module just to get the PID of your script when there is a built in that contains the pid... you are definitely reinventing the wheel.
I've written Python (2.7) and Jython in the past for scripting out IBM WebSphere administration stuff for WebSphere Admins who were to lazy to learn how to script their stuff. Been writing my JBoss/Wildfly stuff in Python 3.4 now - I would NEVER use JavaScript on the server side - much less on the Client side. It's all a giant steaming pile of shit! Consider the whole language was written in what 10 days? Even Netscape who wanted that language couldn't implement it right in their browser. I've used Perl to write scripts for backing up Subversion (SVN) repositories. I've done DOS Batch and PowerShell - but Python kicks both of those scripting languages ASS! I've done a TON of Java and all it's associated stuff. But right now I'm really enjoying coding in Python - it's versatile, fast and clean. Jython is nice because you can have the best of two worlds - Python and Java. But JavaScript - employers that want that real bad don't know SHIT about real languages - JavaScript is NOT a real language - it's a FUCKING JOKE!
The Truth is a Virus!!!
Web apps are fine, but the logic should be driven by the server side. The client javascript should be a minimal thing that handles updating dynamic content and does input prevalidation. If it's big enough to need a framework, you've probably already gone too far by half.
Don't worry, the results haven't rendered in the Emacs browser yet, they'll get here.
Millions long for immortality who do not know what to do with themselves on a rainy Sunday afternoon. -- Susan Ertz
I wanted to learn Python a while back. So I bought a book on the language. All the pages were blank.
Have gnu, will travel.
Yup, and for dynamic typing (if it doesn't grow hair on your palms), I've found perl faster than most anything else, but then I'm careful and know how scoping issues affect the invoking of its garbage collector. Most don't, but most thing perl is like selfgol from Damian Conway - which is explicitly an example of how to be bad and to "don't do it this way". Mine looks pretty clean.
Why guess when you can know? Measure!
Mod parent up. It's the programmer, stupid. You can be a shite-head in any language....or write good code in *some* of them.
Why guess when you can know? Measure!
What widely used, dynamically typed, memory-safe language has a runtime faster than the V8 engine used in Node.js?
SBCL is pretty fast... So is LuaJIT.
Ezekiel 23:20
Is there top talent anywhere that prefers dynamic typing?
Your ad here. Ask me how!
LISP and Smalltalk were early exemplars of functional programming and object oriented programming respectively. Dynamic typing had little to nothing to do with it.
Your ad here. Ask me how!
For real software, that means deployed applications, not 'libraries', ordinary 'unit tests' are in 90% of all cases complete pointless and a waste of time - in a compiled, strong typed language, that is
Chances are that this is an observation of status quo, not of potential. Tests catch problems with logic and types, with the latter in a sense being a subset of the former. Type systems only catch problems with types. Type systems extended to handle problems with logic become non-decidable and therefore aren't used in general practice. By the way, I assume you meant strong static typing rather than merely strong typing. And I'd also remark that decent compilers of dynamically typed languages still catch many potential errors at compile time so there really isn't a reason not to have both.
Ezekiel 23:20
That's what I give about what developers want.
I do not believe in karma. "Funny"=-6. Do good and forbid evil. Yours, Oft-Offtopic Flamebaiting Troll.
Or does the "top talent" in this area prefer static typing?
Yes.
My experience is that dynamically typed languages make you feel more productive but lower your productivity overall. It takes longer for a programmer to persuade a Haskell or C++ or Java compiler to accept their program. Python programmers interpret this as "satisfying the arbitrary whims of the compiler", where C++ programmers interpret this as "finding and squashing bugs before deploying".
If you don't mind deploying bugs because time-to-market is more important than software quality, that may not be a concern for you. But you won't attract "top talent" with that attitude.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
bash + sed + awk == Perl
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
That is why the dynamic language ccrowd 'invented' (rediscovered, cough cough) unit tests and test driven development.
Oh, no. You can thank the Extreme Programming Gurus (now known as "Agile") for this.
The system that I work on now is an API, so unit testing it is necessary. For external APIs, you absolutely need to know if any user-visible behaviour has changed.
For internal APIs, the main job of unit testing is to make refactoring sufficiently expensive that it will never happen.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
Of all the stupidity that Python requires and encourages, significant whitespace is by far the least objectionable.
FORTRAN had significant whitespace. Occam had significant whitespace. Haskell has significant whitespace. Makefiles have significant tabs for Knuth's sake. We're grownups and we can cope.
The main problem with Python is literally everything else.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
Did anybody else fall for your "client-side" and "[enforce] the rules" in the same sentence bit?
I have no idea what you're getting at. I said the authoritative validation runs on the server. I was referring to ensuring that the behavior of the pre-submission validation, which runs on the client, matches that of the authoritative validation, which runs on the server. Any mismatch causes a poor user experience, as users who want to enter data that is server-valid but not client-valid have to "hack" it in using Inspect Element.
I agree that top talent can use pretty much any environment. And that static vs. dynamic typing has never been (even close to) the most important decision point (or event a point that comes up unless you're writing a language).
I do also think that static typing is superior, and like to argue about it on the internet.
Your ad here. Ask me how!
OK, I know C# isn't the most popular language on slashdot. But it is really popular with businesses. The fact that it's not even on the list makes me question the survey's methodology. Other surveys certainly include C#, such as http://www.codingdojo.com/blog....
Dr Pangloss, what a pleasant surprise to see you here!
You can thank the Extreme Programming Gurus (now known as "Agile") for this.
And in what programming language did those guys work at that time? Hm?
The system that I work on now is an API, so unit testing it is necessary.
Agreed.
For internal APIs, the main job of unit testing is to make refactoring sufficiently expensive that it will never happen.
You could "black box testing" only the APl and only have further unit tests for essential stuff.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Oops, of course I meant strong _static_ typing.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Both are dynamic typed, so what is your point?
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
I'm not sure they did, except in niche applications & academia. But in any case it's a huge leap to say they did that because they're dynamically typed, and it's another one to say that just because a lot of people do something that means it's not retarded.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
My point is that LISP and Smalltalk weren't interesting because of (or hell, I would stay were interesting in spite of) dynamic typing. They have other other important reasons people used them. It's like claiming the reason that people like to go n cruises is the unlimited soda for their children. Sure that's a thing that some people want (and other people oppose), but it's never been close to why its interesting.
Your ad here. Ask me how!
If you want a terribly slow web app that's limited to the speed of your internet connection, sure, do that. Bonus: you get to screw over the people on metered connections and kill the battery life of mobile users as well while doing this
And in what programming language did those guys work at that time?
Mostly pre-ANSI C++. Smalltalk also gets quite a bit of coverage in GoF.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
He actually wrote "the same rules", implying it's being done [at least] twice. Which is the case. I don't even play a web developer on TV and I know that.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
I don't see why the app will be slow if you've done it right. OP already specified multi-user and client-server, so you aren't going to eliminate the network traffic by stuffing a bunch of stuff into the client.
No real surprise. Employers want to pay programmers to do the same things they have done before. Programmers want to do things they haven't done yet.
You may credit me as "some random person on Slashdot".
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
If you lose your internet connection, you can't do shit. Some people consider that a bit of a drawback too.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
I consider myself 90th percentile (in that I think I'm better than at least the bottom 10%). :) I might or might be what you consider "top talent," but for whatever it's worth, I prefer dynamic typing when it's appropriate, and static typing when it's appropriate. A lot of times, that's dictated by a choice of tools or technologies made by others. Much of my work is done in C# which is statically typed by default but supports dynamic types as well, which I use only rarely, but like to have available when needed. But I also love Python, and can tolerate JavaScript when and if necessary. :) Proper automated testing can often mitigate the lack of compile-time checks inherent in dynamically typed languages, and the use (abuse?) of things like Object and generics can often mitigate the lack of full support for dynamic types in many otherwise strongly-typed languages. Normally, what can be done in one can be done in the other, but it always makes sense to have multiple tools at one's disposal and to try to choose whatever seems like the right one for any given job.
Nonaggression works!
No, they worked with SmallTalk. ...
The GoF guys are not the unit testing guys
The GoF actually did work mostly with C++, however they analyzed code in other languages, too, to find patterns.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
The other important things, like dynamic dispatch (calling methods that don't exist and provide runtime glue to 'interpret the call') is only possible because the languages are dynamic typed.
The typesystem (and meta type system, and meta object protocol) is the most important part of SmallTalk and OO LISP variations.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Well, :) and C evolved into a more mature language and had then its offsprings like C++. ... but also in most of them they fixed it a good deal over time.
most assembler programmers 'in the old time' invented their own 'business high level assembler' languages that they interpreted with a relatively small interpreter.
Besides that we basically we only had two crowds, language wise: the FORTRAN / COBOL crowed that from different points of views wanted to write compilers; and the LISP / Smalltalk crowd that were in the early steps of working with OO concepts, IDEs and other unique things, like the Smalltalk images.
Then again suddenly the C crowed popped up, but I would put them into the operation systems crowd. They basically only invented C and its predecessor to easy port their toy operation systems to new processors, untill they suddenly where no longer toy operation systems
I guess in all crowds they made retarded stuff
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Haskell has significant whitespace.
Not to detract from your main point, but at least in the case of Haskell the significant whitespace is optional. This is just a consequence of the "layout rule": if you omit the braces and semicolons after certain keywords, the parser will insert them for you based on indentation. If you prefer C-style code with explicit braces and arbitrary whitespace, you can write it that way. (This is a great feature when writing code samples in forums where you can't count on whitespace being preserved.)
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
The graph in the original article shows (for 55+ year olds):
Python: 68.2%
C: 70.8%
(a bunch of other languages, then)
Swift: 75% (emphasis mine)
Whoever wrote that didn't look at the graph for more than a second or two.
Ronnie O'Sullivan could massacre me at snooker using a broom handle.
He'd still be better using an actual cue.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
If I was under thirty with tribal tattoos and piercings you could hang a towel on I'd invent my own language that translates on the fly into whatever you want.
As long as you want swift or go.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."