The Technologies Changing What It Means To Be a Programmer 294
snydeq writes Modern programming bears little resemblance to the days of assembly code and toggles. Worse, or perhaps better, it markedly differs from what it meant to be a programmer just five years ago. While the technologies and tools underlying this transformation can make development work more powerful and efficient, they also make developers increasingly responsible for facets of computing beyond their traditional domain, thereby concentrating a wider range of roles and responsibilities into leaner, more overworked staff.
Some of us do still assemble, even now (Score:3)
Modern programming bears little resemblance to the days of assembly code
What's not modern about using assembler where it's appropriate to do so?
Sometimes I do it just because I like it...
Re: (Score:2)
Re:Some of us do still assemble, even now (Score:5, Interesting)
Just because you can doesn't mean you should. 30 years ago, applications were built with long life-spans in mind, so dropping into very low-level code could make financial sense. Today, programs are generally designed for adaptability and compatibility. The target is constantly moving for the vast majority of applications out there. Dropping into assembly rarely makes sense anymore, because the mantra is "good enough" rather than "best" because even the "best" won't stay that way for long.
Of course, different industries will have different mileage. If you do most of your work for embedded devices or industry-niche things like robotics or satellites, then by all means dive into the 1's and 0's.
Re:Some of us do still assemble, even now (Score:4, Interesting)
Just because you can doesn't mean you should. 30 years ago, applications were built with long life-spans in mind, so dropping into very low-level code could make financial sense.
No, it was utter necessity. For 30 years ago I hadn't even gotten my C64 with all of 65536 bytes of RAM yet, 38911 of which would be left available once BASIC was loaded. Store one uncompressed screenshot of the 320x240x4 bit (16 color) screen and 38400 of those was gone. If you tried storing the Lord of the Rings trilogy in memory - compressed to ~12 bits/word, you'd get about halfway into the Fellowship of the Ring. True, today we waste space but back then we lacked essential space. Every corner was cut, every optimization taken to avoid using any of our precious bytes. See the Y2K problem.
For a more modern but similar issue, I used to have the same attitude to my bandwidth. It used to be slow, costly (pay per minute) and it was important to use it as a precious resource. Today I might end up downloading a whole season of a show after watching the first episode, go bored after three and delete the other twenty. It's there to be used, not to sit idle. I've got 16GB of RAM, there's no point to waste but there's nothing to be gained by hiding in a 1GB corner. If it makes life easier for developers to pull in a 10MB library than write a 100kB function, do it. If you can get it working, working well and working fast then maybe we'll get around to the resource usage.. someday. It's not a big deal.
Re: (Score:3)
, go bored after three and delete the other twenty.
Don't worry. Soon permanent storage space will be so big that nobody deletes anymore. After a while, rm will be removed from Linux distros. You'll just revision the data on your drive, never actually deleting anything. Ha-ha, only serious.
Re: (Score:2)
Don't worry. Soon permanent storage space will be so big that nobody deletes anymore. After a while, rm will be removed from Linux distros.
LOL. I'm laughing with the vague worry that you're accurately predicting the future.
Re: (Score:2)
Just because you can doesn't mean you should.
Just because you shouldn't always doesn't mean you shouldn't ever.
Re:Some of us do still assemble, even now (Score:5, Insightful)
Because it is InfoWorld. Seriously.
Here's item # 3.
Do you remember the first time you used a library? But they're new because programmers 5 years ago did not have libraries.
It gets better:
Yeah. That's a radical new concept there.
Fuck it.
Tonight we're gonna party like it's 1995.
And, finally:
No it is not. Not they would not. Windows XP was released in 2001 and there are still people using it. That's 13 years ago.
InfoWorld sucks.
Re:Some of us do still assemble, even now (Score:4, Funny)
There is a very tiny overlap between software developers and journalists. And yet the number of software development journalists greatly exceeds the size of that overlap. The only explanation is that there are people who don't know what they're talking about who write these articles.
Re: (Score:2)
Re: (Score:2)
Yeah, I skimmed the list and there were only a few things that were newer than 5 years old. Docker definitely, node.js is maybe 5yrs old already (but that looks like it peaked - the cool kids have already moved on). Chef is already about 5 years old and Puppet is already much older (and that's ignoring much older config management tools).
Re:Some of us do still assemble, even now (Score:5, Insightful)
It's pretty obvious this is written through the lens of a javascript-focused web programmer. Seriously, libraries are a hot new trend? That's hilarious stuff. Read each item in this list as "From the viewpoint of a Javascript/web developer...", and it seems to make a bit more sense.
It's pretty clear he only has a vague notion of game development either (my profession), and gets some basic facts wrong. He calls Unity a library (it's a game engine, better categorized as a framework). In a different article, he claims that game frameworks are in, while native development is out. The first part is true, but the second part certainly is not. C++ is still used almost exclusively for large-scale AAA game development. Unless by "native development" he meant "roll your own game engine", in which case he's using the wrong terminology.
Re: (Score:2)
Unless by "native development" he meant "roll your own game engine", in which case he's using the wrong terminology.
Maybe he means that because of outsourcing, more and more applications are being developed in India by the "natives" rather than in the US by H1Bs
Re: (Score:3)
The problem is that not that many people are able to use assembler these days, because they do not get it. It is still needed in numerous places and if you cannot even do small stuff with it, then you are not a professional programmer.
Re: (Score:2)
Sorry,
... and if you cannot even do small stuff with it, then you are not a professional programmer. ;D and regarding your post you are an idiot anyway, so who cares.
that is a misconception. "They do not get it" is certainly wrong.
Assembler is the most simple programming "language" in existing, everyone gets it.
Like you I guess, post your last assembly code otherwise I would say: you are a liar
Re: (Score:2)
C, assembler, VHDL, it still all gets done. But the people who do that sort of work does not have much overlap with the sorts of people who write blogs or articles about how programming has changed over the years.
Reading this article, it's just stupid. Ie, some of these "new" technologies changing how we program: libraries, APIs, virtual machines, developing tools to help development, and performance monitoring. That stuff has existed since the first decade of programming. "New"s stuff includes social
Re: (Score:2)
"New"s stuff includes social media portals. Wow, I don't even know what that is, but it sounds web-ish.
I think that means that modern programming is done via crowd-sourcing, kickstarter, and mechanical turk.
I seem to recall having these modern things called "libraries" when I was programming in small C on CP/M.
Re: (Score:2)
Re: (Score:2)
For "compiling" to machine code, there is a 1:1 mapping of assembler, unless you count macros as something fancy.
Re: (Score:2)
What about reading assembler? How do you deal with core dumps? These still exist, and they still exist on new and modern projects. Apparently you don't do systems software or you'd be hiring someone who knows assembler, someone who can write a run time library, someone who can do board bring up, someone who can modify the OS, etc.
Not changed much (Score:5, Insightful)
I don't see many changes. Vendors, managers, and salespeople change the buzz words every few years and talk of great paradigm shifts. Programmers continue to write code and produce actual results. In a perfect world the programmers get to choose their own tools. In the real world we have to use whatever buzz word compliant tools are thrown in the mix each year. They never actually live up to the hype and you have to dig in and find the code buried within and build stuff that works. I remember when the salespeople were touting dBase II and how programming would be completely changed. Right.
Re:Not changed much (Score:5, Interesting)
I'm not sure I agree 100%.
As a senior engineer today, I'm responsible not only for knowing the primary back end language (C#) for my web application, but also HTML5, CSS3, JavaScript, and the UI toolkit library. I'm also expected to understand database design, including being able to have an intelligent conversation about the physical schema, and I'm expected to be able to design tables, indexes, and optimize queries. I also have to know security, build tools, the automation scripting language for my platform (now PowerShell), and the deployment system (WiX to create MSIs). I'm also the source control administrator (Subversion).
I also have to read requirements that are maybe 5% of the value of those I got 15 years ago, and be a business analyst to figure out the rest.
Now fifteen years ago, I could probably have gotten away with knowing C/C++, a little scripting in Perl/Bash, and be decent at a CLI. I can probably write a multithreaded TCP/IP server in C without need for Google, which I haven't done in at least 12 years, but have to constantly Google things for what I now do daily.
I don't think things have changed fundamentally, but they haven't stayed the same. We're getting shallower, broader, and less efficient for it.
That's you. (Score:3)
That's because you are now holding the position of a senior engineer with 15 years of experience.
Look at what someone who is just starting needs to know. How much different is it than what you needed to know when you started 15 years ago?
Re: (Score:2)
Re: (Score:2)
As a senior engineer today, I'm responsible not only for knowing ...
I thought the exact same thing when I started as a software engineer in 1996, almost 20 years ago. Only back then we actually generated HTML in C++ on the server (with home-brewed "html template" processors.) And we had to deal with things like COM, and browsers were far less standardized. We also had to deal with database design, only we had to make home-brewed Object-Relational Mappings, because the frameworks for that weren't that good either. Marshalling an object from the database through the business
Re: (Score:2)
So basically you just learned how to do a full application (web server and GUI via html) and you think its new. Funny that just happens to be 20 years old as well, and its certainly not the first type someone wrote client server applications.
Nothing you're doing is new other than you're doing it now instead of someone else.
You just learned to do the 'full stack'. I've been doing it for over 20, before the web existed. Different languages, different layout engines, different libraries, same process.
Re: (Score:2)
Re:Not changed much (Score:5, Insightful)
In hobby programming, which is not the real world, the programmers get to choose their own tools. In the Silicon Valley startup bubble, which is also not the real world, programmers have to use whatever buzz word compliant tools are thrown in the mix each year.
In the real real world, programmers use C, C++, .NET, Java, or some other constantly-claimed-by-idiots-to-be-dead language. (And they usually use it to write boring, vertical-market billing software.)
Re: (Score:2)
Re: (Score:2)
Where was I "bashing" hobby programming?
If anything, you're the one "bashing" hobby programming by implying that it is at a lower "level" or at a "small scale" compared to professional programming. As far as I'm concerned, the only difference between it and "professional" programming is profit motive (which is also what makes it not "real world," because "real world" refers to the need to earn a living).
Re: (Score:2)
As far as I'm concerned, the only difference between it and "professional" programming is profit motive
That and on which platforms people are allowed to do it. The video game console makers have made it clear that their platforms are not intended for hobbyists.
Re: (Score:2)
Sony maybe, but Microsoft has long had the Xbox Live Indie Arcade where for $99 a year you can code up something and play it on an Xbox360 and even sell it on an Xbox360.
And Sony did at one point too when the PS3 ran Linux.
Microsoft has/had plans for bringing the program onto the Xbone as well.
Re: (Score:2)
I even remember the days before the word "paradigm" existed.
(yes it's sarcasm you annoying downmodders!)
My list (Score:5, Informative)
How about we make a list of the technologies that have actually impacted us in a real way over... hmm, let's say the past ten or fifteen years? I assume that everyone will have slightly different items, because we all work in different areas. I'm a game developer and use C++, so my perspective will reflect that. Listed in no particular order of importance:
1) C++ 11/14 - It's transformed the language in a fairly dramatic way, making it much safer and convenient to use, while leaving legacy code completely compatible. Modern C++ code feels a lot more like C# at times, just a whole lot uglier.
2) Mobile Platforms - Mobile platforms (smartphones and tablets) as a rising contender has caused a fundamental shift in the balance of power among platforms.
3) Online Gaming and Integration - MMOs and other games are taking advantage of the ubiquitous connectivity to the internet most of us now enjoy.
4) Distributed Version Control Systems - Modern source control systems such as Git and Mercurial (my favorite) are a boon not only to large distributed projects, but even for smaller developers. Traditional development house, for the most part, still use Perforce, though, which works much better for asset management.
5) Online distribution - The ability to quickly and easily download and update games from vendors like Steam, Gog, and Origin are opening up the market to indie and traditional developers alike, and will eventually kill physical distribution channels.
6) Online resources - Better search pioneered by Google teams up with incredibly knowledge-rich sites like StackExchange.com. The result is that damn near any question you have is likely to have already been asked and answered. If not, ask away, and you have a good chance of getting some real help.
7) GPU programming - More and more visual programming is being off-loaded to the GPU, and those have developed into full-blown programming languages of their own.
8) Parallel programming - With the advent of ubiquitous multi-core / multi-threaded processors in the past decade, game developers had to start getting serious about multi-threaded programming, making an already demanding job even tougher.
That's about all I can think of offhand that's really changed over the last fifteen years. Libraries, frameworks, and APIs are not some new phenomenon. They've been around since I started professionally programming, so it's ridiculous to include those. You might as well add "source code", "compilers/linkers", and "editors" to the list if you're going there.
What about in other professions?
Programming evolves. News at 11. (Score:3)
I'm struggling to understand the point of this article. May as well have titled it "You won't believe these 15 new tricks for programmers. The shocking truth the devops guys don't want you to know"
Some quotes:
* "Back to work, slave, the continuous build machine has new tasks for you."
* "You're not a craftsman -- you're a framework-tweaker."
* "It's so much easier, but these IaaS administration Web pages won't buy you a drink after work."
Re: (Score:2)
I'm struggling to understand the point of this article.
It's Infoworld.
The point of the article is twofold:
- To convince Pointy Haired Bosses that they understand what's going on and are riding the cutting edge.
- To sell them new products, implementing new buzzwords, which they can then inflict on their hapless subordinates, making their life hell as they try to get the stuff working and into production.
That's the first two lines of the four-line Slashdot meme. The remaining two are:
(3. Bill
Re: (Score:2)
* "Back to work, slave, the continuous build machine has new tasks for you."
Has anyone ever, anywhere, gotten a task assigned to them by the continuous build machine?
No Assembler? (Score:3)
I think it's the exactly opposite.
The modern programming environment is trying hard to lock the programmer into a box where he can't do much harm...
No one has more control over the computer than an Assembler language programmer.
And there's still lots of Assembly programming going on today.
Re: (Score:2)
Yup. Everyone's amazed at the exciting new worlds of mobile phone apps. And yet, assembler exists underneath that. Someone wrote it. Maybe not the people who responded to the "be a web app developer and earn pennies from your own home!" advertisements. But it exists and those web apps would not exist without it and the people who understand it.
But this is nothing new. Go back 30 years. The vast majority of Unix programmers didn't know assembler either. They were just your 9 to 5 programmers getting
Yes, no, maybe, potato salad (Score:3)
Modern programming languages are a fusion of older programming languages, with chunks taken out. Often, it's the useful chunks.
There is no table, that I know of, that lists all the features ("significant" depends on the problem and who cares about solved problems?) versus all the paradigms versus all the languages. (Almost nothing is pure in terms of paradigm, so you need a 3D spreadsheet.)
Without that, you cannot know to what extent the programming language has affected things, although it will have done.
Nor is there anything similar for programming methodology, core skills, operating systems or computer hardware.
Without these tables, all conclusions are idle guesses. There's no data to work with, nothing substantial to base a conclusion on, nothing to derive a hypothesis or experiments from.
However, I can give you my worthless judgement on this matter:
1) Modern methodologies, with the exception of tandem/test first, are crap.
2) Weakly-typed languages are crap.
3) Programmers who can't do maths or basic research (or, indeed, program) are crap.
4) Managers who fire the rest of the staff then hire their girlfriends are... ethically subnormal.
5) Managers who fire hardware engineers for engineering hardware are crap.
6) Managers who sabotage projects that might expose incompetence are normal but still crap.
7) If you can't write it in assembly, you don't understand the problem.
8) An ounce of comprehension has greater value than a tonne of program listing.
9) Never trust an engineer who violates contracts they don't like.
Re: (Score:2)
1) Modern methodologies, with the exception of tandem/test first, are crap.
2) Weakly-typed languages are crap.
I would only add, "All Languages are Crap. Programmer skill makes the difference."
Sensationalist BS? (Score:3, Insightful)
Re: (Score:2, Informative)
If containers, continuous integration, Iaas, Paas, and other "deployment techniques" aren't dramatically impacting your workflow as a developer, then you're almost certainly wasting a lot of time.
Vagrant + Puppet/Chef = clean new test machine, configured & installed exactly the same way... every time.
Docker = "all my dependencies always travel with my application."
IaaS + PaaS = "if I need a bunch of test nodes to work with, or prototype something, I push a few buttons and wait 20 minutes, at which point
Another Silver Bullet? I don't think so... (Score:5, Insightful)
Here we go again with another silver bullet?. It seems that every generation of noobs comes to this same conclusion and are just as wrong as we where when we said the same thing. It's almost a rite of passage, just like the rebellious teenager or terrible twos kids go though.
Yes, programming has changed some since I started doing it. However, in the long run, nothing has really changed. Programming is Programming, the same skills I used to need when doing assembly, are useful when I dabble in Java. What HAS changed is the programming model and the languages we use. Yea, we can automatically generate a boat load of code and come up with stuff that would have taking years to do in assembly in a few hours, but nothing is really new. When we went from Assembly to C, we could do things in C so much faster than in assembly, but programs only got bigger and slower. C to C++ bumped that up again, but not that much. Java bumped that up, adding mufti-platform capacity, slowing the programs down and making them take more memory. That's how this goes, new tools, bigger programs that run slower, but still requires a programmer to make useful things using those tools.
Truly there is nothing really new for programmers, the job still requires the same kinds of skills and still requires that you know the programming model. Yea, we can pull ready built stuff off the shelf more easily, but like before, new advances really only make programs bigger and slower and still require programmers who know how to design and implement. We keep trying, but this will not change.
So, nice try there syndeq, I think you are wrong. My generation of programmers thought we had achieved the same things you are claiming when we where noobs. We where wrong too. There may be new tools, but you still need a skilled craftsman to use those tools or you get garbage for a program.
I strongly recommend you go get and read "The Mythical Man Month" by Frederick P. Brooks, Jr.. In my day his experience and insights where eye opening for us, and it will be for you too. You don"t have to make the same mistakes we did. I've met some of you guys/gals you can do better, just take my advice.
Re: (Score:3)
I agree, Brooks is as relevant today as it was when it was written. People are still making the same stupid mistakes and still believe that technology can fix their inadequacies. It cannot.
Re: (Score:2)
There's nothing really new for programmers because, if you're doing it right, everything is really new for programmers all the time. Once anything becomes routine, we turn around and automate it, so the work is always this set of tasks we haven't figured out how to automate set.
Re: (Score:3)
There's nothing really new for programmers because, if you're doing it right, everything is really new for programmers all the time. Once anything becomes routine, we turn around and automate it, so the work is always this set of tasks we haven't figured out how to automate set.
If you look at the effects of automation tools, you discover that they really don't didn't fix anything, they just change the specifics of the problem. You are still going to need a programmer to learn the new tool and make your desired program work. That is the point of Chapter 16 and 17 in "The Mythical Man Month" I told you to read....
Re: (Score:2)
That's just what I was saying. The programmer's task is always "automate what was new 3 years ago, and routine 1 year ago, using what got automated last time to help." It's a never-ending cycle, as automating X just allows you to do Y, which eventually becomes straightforward enough to automate.
what a load of utter bullshit (Score:5, Insightful)
I've been doing this full-time since 1985, and the most distressing part is how little real change there has been in all that time!
Re:what a load of utter bullshit (Score:5, Interesting)
The hardest part is trying to get a web browser to act like a desktop GUI, which is what customers want. We have to glue together a jillion frameworks and libraries, creating a big fat-client Frankenstein with versioning snakes ready to bite your tush. Great job security, perhaps, but also an Excedrin magnet. What use is lining your pockets if you die too early to spend it?
It's time for a new browser standard that is desktop-GUI-like friendly. The HTML/DOM stack is not up to the job.
Dynamic languages (JavaScript) are fine as glue languages and small event handling, but to try to make them into or use them for a full-fledged virtual OS or GUI engines is pushing dynamic languages beyond their comfort zone. Static typing is better for base platform tools/libraries. You don't write operating systems in dynamic languages.
Somebody please stab and kill the HTML/DOM stack so we can move on to a better GUI fit.
Re: (Score:3)
Yes. Writing desktop apps in web browsers is a nightmare. I agree with that. It's just that it's not all that different than the nightmare of gluing together incompatible libraries and various GUI/desktop managers from long ago. No matter what decade you talk about, there were always a bunch of idiots pushing a new "paradigm" that was extremely poorly thought out and a huge pain to deal with ;-)
Re: (Score:2)
Somebody please stab and kill the HTML/DOM stack so we can move on to a better GUI fit.
Hmm, perhaps Qt running in a NaCL environment? The only fundamental limitation would be that it's Intel-only, but then again so are most desktops these days.
Re: (Score:2)
Actually, the limitation would be that it only works in 1 browser, Chrome.
Re: (Score:3)
I've been doing this full-time since 1977, and the most distressing part is how little real change there has been in all that time!
Somebody is projecting their delusions... (Score:5, Interesting)
Quite frankly, I just finished a larger project for a customer and what I did strongly resembles what I would have done 30 years ago: Define what the solution must do, do an architecture, a design, define interfaces, and then code the thing. The only thing that is different is that the C code was a web-server module and that the in-memory database may go up to 10G instead of the 100k or so it would have 30 years ago.
Really, nothing has changed much, unless you are at the very-low skill end of things, where you can now produce bad code in ways you could never before.
No retarded like clickbait retarded (Score:5, Insightful)
This is quite possibly the stupidest article ever posted to Slashdot.
Ok, this month.
Re: (Score:2)
This is quite possibly the stupidest article ever posted to Slashdot.
Ok, this month.
I hate it when I have mod points and comments like this are already at 5.
hype (Score:2)
The only differences I've seen the last 20 years are:
1. VMs
2. Average developer skill getting worse
Re: (Score:2)
The more it changes this thing never changes (Score:2)
My experience reaches back to the toggle-and-punch cards days and I don't want want to bore anyone with stories about that.
But one thing I have noticed in all those years a I cannot recall a single year where it wasn't proclaimed by someone that software engineering would be dead as a career path within a few years.
Academia and Industry is actually pretty good at coming up with new and better ways to program. Hundreds if not thousands of new languages, frameworks and tools have appeared over the years and
The tower of babel was already present back then. (Score:4, Interesting)
My experience reaches back to the toggle-and-punch cards days and I don't want want to bore anyone with stories about that.
But one thing I have noticed in all those years a I cannot recall a single year where it wasn't proclaimed by someone that software engineering would be dead as a career path within a few years.
I go back that far, as well.
And the proliferation of languages, each with advocates claiming it to be the be-all and end-all, was well established by the early '60s.
(I recall the cover of the January 1961 Communications of the ACM [thecomputerboys.com], which had artwork showing the Tower of Babel, with various bricks labeled with a different programming language name. There were well over seventy of them.)
Not true! (Score:2)
Re: (Score:2)
Silly me. Wasting all day writing m4 macros to preprocess an assembly language. Should be doing it all in Javascript according to Slashdot wisdom.
Re: We only use JS now? (Score:2)
Depends, how long did you spend on the assembly language?
Re: (Score:2, Insightful)
No mission critical stuff is done on JS anywhere. This joker confuses GUI scripting and programming. And sorry, JS is a real piece of trash. The only "awesome" thing about it is how wrong it gets most things. Of course, when your comparison is PHP, then JS may look pretty good.
Re:We only use JS now? (Score:5, Insightful)
Yeah, it only runs the front end of EVERY WEBSITE IN EXISTENCE (which includes tons of "serious" SaS applications, and more and more "thick client" sites where the bulk of the code is in JS and the server is just used for database work). But yeah, other than that nothing mission critical at all.
Re: (Score:2)
Re: (Score:2)
Yes, yes it is!
https://code.google.com/p/shel... [google.com]
(and yes, this is used in production on mission critical systems)
Re:We only use JS now? (Score:5, Insightful)
And that mentality is precisely why so many web applications suck farts off dead chickens for performance and scalability.
The first step to designing a scalable application is designing a scalable and flexible database model. The database is not an "afterthought", it is the heart of an application.
The code which accesses the database can be tweaked and fiddled, but once you've created your database, it becomes very expensive to change it in the future because of the costs of changing not just the code, but creating and testing database migration scripts to move the data to a new model.
But you go pat yourself on the head that you're a 'leet programmer because you know a scripting language.
And then hang your head in shame when you realize that JS runs in the browser and is only a presentation layer, not the application itself. Only a fool puts the business logic in the client if they have any understanding or concern for transaction consistency and application reliability. You have to assume the presentation client is going to break half way through processing something and leave the database in an inconsistent state if you put the business logic in the front end.
Re: (Score:3)
Only a fool puts the business logic in the client if they have any understanding or concern for transaction consistency and application reliability. You have to assume the presentation client is going to break half way through processing something and leave the database in an inconsistent state if you put the business logic in the front end.
Actually, while that's a valid concern, a much bigger reason for not putting the application logic in the client is that anything in the client can be hacked for malicious purposes.
Server-side code may not be as immediate, but at least access to the code is restricted to functional invocations and not inherently at risk at the instruction level.
Re: (Score:2)
They are obviously talking about in generalities.
That doesn't mean everyone is doing it. Or that it fits every task.
Here is some random survey from 2012 as an example:
58.9% Javascript
58.9% sql
51.1% jquery
37.6% java
37.6% c#
28.9% php
23.4% python
21.1% c++
The year after:
57.9% Javascript
53% sql
37.9% java
37.6% c#
26.2% php
22.5% python
21.7% c++
18% c
10.3% objective-c
9.8% node.js
9.1% ruby
http://blog.stackoverflow.com/... [stackoverflow.com]
I don't know how representative Stack Overflow is or what it means, I just know Javascript is used
COBOL was better than JavaScript. (Score:5, Insightful)
As a former COBOL programmer way back when during the mainframe era, and as somebody who has had to develop and maintain JavaScript code over the past several years, I can say without a doubt that I much preferred using COBOL.
Although COBOL is a verbose language and not always the easiest to use, at least it isn't shit-for-brains stupid like JavaScript so often is. When I use JavaScript, I often sit there wondering, "What the fuck was Eich thinking when he came up with this stupidity?" and then I wonder, "Why the fuck hasn't the JavaScript community fixed these fucking stupid misfeatures?"
So many things about JavaScript are just so stupidly broken, and there's absolutely no reason why they should be like that. They're so idiotically wrong that it's totally worth breaking compatiblity with existing code if it means fixing these problems. COBOL, while not the best language, was never anywhere near as fucking moronic as JavaScript usually is.
Re: (Score:2)
One man's "stupidly broken" is another man's "feature".
Re:COBOL was better than JavaScript. (Score:4, Insightful)
To you, someone who obviously isn't a Javascript programmer, maybe. To someone who writes Javascript code every day, like myself, nothing at all is "broken" with the language (though obviously, like any language, it could use some improvements).
But I'm sure if I started writing COBOL I'd think plenty was wrong with it ...
Re:COBOL was better than JavaScript. (Score:5, Informative)
Someone who writes JavaScript every day and claims that "nothing at all" is broken is either lying or a real moron. There is plenty wrong and "broken" in JavaScript, primarily the retention of exceptionally poor design decisions that have carried all of the way through to today. Reliance on global variables, indeterminate behavior of "this", semicolon insertion, only having support for IEEE floating point numbers, lack of block-scoping, the syntax for the with block, two sets of comparison operators (one of which makes PHP seem coherent), over 50 reserved words of which maybe 20% are actually used and of those the language isn't smart enough to parse them only in their appropriate context.
There's a reason that nobody sane (or intelligent) programs in JavaScript without tools that tell you that your syntactically legit code is a disaster and that there are so many languages that transpile to JavaScript specifically to remove the stupidity.
Re: (Score:2)
indeterminate behavior of "this"
So what you're saying is that you don't even understand the basics of the language. That's your fault.
Re: (Score:3)
Block scope doesn't exist. That's broken.
Re: (Score:2)
Why?
Re:COBOL was better than JavaScript. (Score:5, Funny)
To someone who writes Javascript code every day, like myself, nothing at all is "broken" with the language (though obviously, like any language, it could use some improvements).
Ah, good old Stockholm Syndrome. Don't worry, I feel the same way about C++ ;^)
Re:COBOL was better than JavaScript. (Score:5, Funny)
C++ is the programming language equivalent of a powerful but touchy sports car that's almost guaranteed to crash and burn in the hands of novice drivers, but can perform beautifully in the hands of an expert. C is that same car with the mirrors, safety belts, and airbags removed.
Re: (Score:2)
And yet C ends up being safer because C++ deploys the airbags at random and makes you crash it....:-)
Re: (Score:2)
C++ is the programming language equivalent of a powerful but touchy sports car that's almost guaranteed to crash and burn in the hands of novice drivers, but can perform beautifully in the hands of an expert. C is that same car with the mirrors, safety belts, and airbags removed.
Not to mention the starter motor. And the distributor too. However cranking round the destributor by hand can give you a slight performance boost if you learn to hear the enging just right and can lead or lag by ear. Of course the n
Re:COBOL was better than JavaScript. (Score:4, Informative)
Also keep in mind that Eich was given only 4 days to create the language. I agree that things should have been fixed long ago, while the changes would have been less disruptive.
Re: (Score:3, Interesting)
I don't think that the 4-days claim is a valid excuse. Eich should have known better. It was the middle of the 1990s, for crying out loud! Tcl was well established as an embeddable scripting/extension language by that time. He should have just embedded that. Fuck, he could have also gone with Perl, which was well established at that point, too. Sonofabitch, he could have even gone with one of the newcomers like Lua or Python. Even going with a simple Scheme implementation, like every undergraduate Comp Sci
Re:COBOL was better than JavaScript. (Score:5, Funny)
Thank you for your contribution, but if you'd been paying attention, you would have realized that we are looking for ways it could have been done better here.
Re:COBOL was better than JavaScript. (Score:4, Informative)
Even going with a simple Scheme implementation, like every undergraduate Comp Sci student will develop at one point or another, would have been better than JavaScript.
He wanted to do exactly that. Then someone at Netscape found out what Scheme was and put the kibosh on that plan. (Learn a little history, kid.)
In a way, we were really lucky. What we got was MUCH better. It's a rotten shame so few people here have actually taken the time to learn the language. It's really quite good. The "bad parts", interestingly enough, are the bits Eich was told to include to make it look more like Java (new, constructor functions, etc.)
It's perhaps the worst thing ever to have happened to the computing industry, the worst thing to have happened to the Web
There's a good chance that, without JavaScript, the web would have vanished. You probably don't remember all the hype surrounding the "x internet" back in the early 2000's, but the web was on it's way out. If not for JavaScript (and XHR) the web would likely have been replaced by some other set of technologies.
Re: (Score:2)
Re: (Score:3)
We probably would have ended up with some variant of REXX or TCL on the client-side.
Almost certainly Tcl; the right engineers knew it at the time, but JS managed to get to a shipping browser slightly sooner.
Re:COBOL was better than JavaScript. (Score:5, Insightful)
Javascript needs to die, and I'll find another job before I waste any more time programming this POS "language".
Re: (Score:2)
Try learning it before you use it next time.
Given that the few *actual* complaints about it (not empty 'it sucks' rhetoric) seem to be simple misunderstandings about the language (this, classes, etc.) I'm willing to bet that the problem is the user, not the language.
Really, it's not complicated. It's really very simple. It's different, yes, but far simpler than other, less sophisticated, languages. Take a few days to learn and understand the language. You'll be impressed. It's remarkably well-designed.
Re: (Score:3)
Two words:
"use strict";
Put that at the top of a JS program or function and most of the "stupidly broken" parts of JS are disabled when you're in an ECMAScript 5 environment (i.e. any modern browser).
Most of the remaining complains about JS (like function scope, or prototype-based inheritance) are IMHO not problems at all, but rather reflections that people are far more used to class-based inheritance systems and how other languages work.
Yes, the language design isn't perfect. It was clearly rushed. It is
Re: (Score:3)
Other than the "this" misfunction, which is rememdied by the hack defining "that", what are the terrible misfeatures of JS?
It's not like C/Java/COBOL/FORTRAN/whatever other language someone is used to using.
Re: (Score:3)
Re: (Score:2)
Re:We only use JS now? (Score:5, Funny)
Yes,much like with Regex, you now have 2 problems.
Re: (Score:2)
MyString = MyObject.ToString;
eval("MyObject = " + MyString + ";");
and a few bits to deal with different date formats. Nothing about a runtime environment or browser. Simple class serialization
Not that simple (Score:5, Interesting)
There's another factor, too; the industry really wants young programmers. The costs are less for remuneration, insurance, and vacation; the families are smaller or non-existent, and these people will work much longer hours based on nothing more than back patting and (often empty) promises. One of the consequences here is that some of the deeper skill sets are being lost because they simply aren't around the workplace any longer.
I think there is no question that all of this has changed the face of coding. An interesting exercise is to ask yourself: When was the last time you saw a huge project hit the market. Now ask yourself how many little does-a-couple-of-things projects you've seen hit the market in the same time frame. My contention is that there are very few of the larger projects being undertaken at this point, or at least, being finished.
Just one (retired) guy's opinion. :)
Moar old man complaints (Score:5, Funny)
If you're not writing x86 assembly by hand, you have no right to complain. Then an even older guy goes, "if you're not punching cards, you have no right to complain". Then an even older guy goes, "If you're not flipping switches and soldering wires you have no right to complain". Finally, the oldest man in the room stands up and says: "Before there were machines called computers, there were people who did calculations by hand. They were called computers. Most of them were women. If you didn't marry her, you have no right to complain".
Re: (Score:2)
Sadly, this should be modded Informative.
Re: (Score:2)
To anyone who thinks they can