Slashdot Mirror
The Technologies Changing What It Means To Be a Programmer
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.
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...
systemd is Roko's Basilisk.
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.
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."
Speak before you think
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.
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.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
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.
I don't see a single point in the article that would represent any profound change in how programmers work. In fact, points like 1 or 4 are laughable simply because even though these are true, they also happened decades ago. Point 9 is exactly like programming in Lisp (do everything in a single generic language), the only difference being using Javascript instead of Lisp. Others are of interest as deployment techniques, not as a programming workflow change. Etc.
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.
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
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!
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?
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.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
This is quite possibly the stupidest article ever posted to Slashdot.
Ok, this month.
Yes,much like with Regex, you now have 2 problems.
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.
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 an amazing number of them were designed with the idea that "you don't need a programmer anymore." They're still doing it.
If you have been around long enough, you realize it will never happen.
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....
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
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. :)
I've fallen off your lawn, and I can't get up.
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?
Irony: Agile development has too much intertia to be abandoned now.
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, 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.)
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
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".
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
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.
I do not fail; I succeed at finding out what does not work.
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.