Slashdot Mirror
The Extinction of the Programming Species
Max Goff writes "Given the recent chatter surrounding the extinction of the U.S. programmer, /. readers might also be interested in a series of articles I recently penned for java.net -- the Blacksmith and the Bookkeeper (part 1, part 2 and part 3) -- in which I posit that the postmodern programmer (the entire sub-species, not just those domiciled in the U.S.) shares much with the
blacksmith of old, and will become just as extinct in relatively short order. It is not due to work visas or outsourcing, but has much more to do with the evolution of work itself."
Programmers can't reproduce without sex, and sadly, we're not getting any.
Somebody else RTFA! I don't want to know how I'm gonna die.
People should not fear what they do not understand; people should fear because they do not understand.
Tools come and go. Knowledgeable people are here to stay. The problem is many people pretend to have knowledge in fields they're not experts.
It's the same with diet/exercise. As the years go on new diets/plans come and go yet the old school traditional "just eat less crap, more good and get off your ass" philosophy is still here.
Wanna make sure you're employable as a software developer? Make sure you're actually knowledgeable about the science *and* the field. It's good to know about things like Java/C++/etc but it's equally important to know about design theory, algorithms, math, etc.
So if you signed up for some 6 month "computer science" program well don't blame the industry for your unemployable status. Code monkeys are a dime-a-dozen.
Tom
Someday, I'll have a real sig.
It is not due to work visas or outsourcing, but has much more to do with the evolution of work itself
Nonsense. It has to do with the wholesale re-negotiation of the social contract between business and the society it sells to.
Business is no longer satisfied with the simple model of building a product and selling it. That would require work, investment, long-term planning and respect for the skill, education and loyalty of their employees.
Much better, business says, to sell all of that and simply manufacture brands. The modern workplace is therefore obsolete, because business does not want to pay for it. It's really that simple. People are only useful if they are opening their wallets at a cash register. They are not worthy to be employed and paid a fair wage.
There are voluminous statistics to support this, but a few should be sufficient. In the last few years, corporate assets have increased 288%. Employee compensation has increased 9%.
Over half of the working-age population is either a temp, part-time, unemployed or out of the workforce entirely. Read it again: HALF OF THE WORKING-AGE POPULATION IS NOT EMPLOYED FULL-TIME. Companies have no respect for anything: skills, education, experience are all totally meaningless to these companies. ALL that matters is money. That's why it takes five interviews and a credit-check to get hired, but only an e-mail to be fired.
Unless, of course, we're discussing the price tags of all these "brands." Then, it's "you get what you pay for." Like $2500 for a mattress and $4500 for a television, $175 for a basket of groceries and $50,000 for a car. It's nonsense, of course, but everyone's too busy arguing about the problem. Nobody is interested in hearing the facts. All that matters is money.
Business isn't willing to pay for products, innovation and careers, so we get brands, mortgage commercials and layoffs.
The problem lies in the definitions. A bookkeeper of today is nothing like a bookkeeper of the 19th century. The "postmodern" bookkeeper is dependent on a new set of tools -- software written by those outmoded programmers, even. They no longer calculate books by hand, but use automated tools, and they're not so concerned with tracking business' money as they are with audits, GAAP, and finding interesting new ways to conjure a penny more than consensus earnings estimates from the Street.
.NET RAD would be nearly as alien to a systems programmer of forty years ago as a machinist with CAD-driven power machine tools would be to the blacksmith of four hundred years ago.
Similarly, the role of "blacksmiths" evolved. Today, you might call them machinists, or perhaps they're the assembly-line workers. You don't see many blacksmiths making auto parts by hand, but then you don't see many bookkeepers calculating General Electric's quarterly results by hand, either.
It's merely a linguistic quirk that we retained the occupational title for "descendant job 1" and not "descendant job 2". Recall that "computers" themselves were once human beings that did arithmetic.
Similarly, programmers aren't going away, though we may stop calling them "programmers" and the day-to-day details of their methods and tools will change.
And if you are concerned simply with a narrow focus on specific methods of today, then programmers have already survived the postmodern shift. As scarce as blacksmiths are professional programmers who key in word values with switches on the front on their machine, and almost as scarce as those that deal with any significant amount of assembly language. Programmers and their tools have already evolved with time, and a modern programmer mucking about in
The reader comments on these articles are themselves interesting. I especially think this one is telling: "As a Java programmer I haven't looked up searching and sorting algorithms in Knuth". Being a Java programmer myself, I can certainly appreciate having these kinds of algorithms in a standard library. I still think you should spend some time with Knuth or some other book (or online documentation) and understand how they work. That's one problem I see, not enough programmers today learning the fundamentals and just letting the libraries do all the hard lifting for them.
Eric
Thanks to All-Bran, William Shatner 'goes like no man has gone before'
At first I thought, "Of course! Everybody knows that." My wife and I were just chatting about that last night before bed. (Maybe the rest of you should use romantic talk like that, and you'd get some more often.)
Then I realized that the author knew way more words than I do. He must be right.
sigs, as if you care.
A proof of the demise of the programmer the article points out:
The advent of the Codeless Development Environment (CDE)
I wonder if these "Codeless Development" environments are they themselves written in a codeless environment. If you have ever coded in a pure gui environments with boxes and connectors and such you will quickly learn the limitations.
They have been predicting the demise of programmers since the invention of COBOL in the 60s. It was supposed to turn ordinary business users into programmers thanks to its easy, English-like syntax. We're still waiting. Now this writer is talking about "codeless development environments" which are (like the 5GLs and expert systems of yesteryear) supposed to replace programmers.
While I think that programmers are "evolving", the
analogy with "Blacksmith and the
Bookkeeper" is not right.
Bookkeepers, blacksmiths, even secretaries are
disappearing because their jobs can be automated and computers are taking over.
Programmers are disappearing because of a different reason. It is not because computers are
taking over us; to this day no computer can write a program or fix a bug.
I believe that the problem is that the software is
becoming so complex that what could have been done by one-person years ago, takes a team
these days. I remember that in 1991 I wrote several systems like inventory managers, stuff
like that. Today you require testers, DBA expert, GUI designers...
I think it is more like what happened to the
aviation industry. In the 1900 you could build your own airplane, there were people building
airplanes all over the world. Today, only a few companies can do that,
and the demand for airplane-building skills is gone. Well, not gone,
its just that it has changed, now you have to specialize in some area, you can not know ALL what
is required to build an airplane. ( well, unless you are Burt Rutan)
I think that software is evolving the same.
Eventually we will have to specialize in GUI, or DB or whatever. The generic programmer is not
disappearing, just evolving. ( Read with Hannibal Lecters accent. )
My 2 cents...
-Ale
Look, that technology is already here!!
Behold, a program which is capable of designing a new program!!
#include <stdio.h>
int main ( void )
{
FILE * output = fopen ( "c:\\newprogram.c", "w" );
fprintf ( output, "#include <stdio.h>\nint main ( void )\n{\nprintf(\"hello world!\");\nreturn 0;\n}" );
fclose ( output );
return 0;
}
Were all doomed you fools!!
Extinction of the programmer species means for me that I lost a few years of my life and now I have to change my carreer.
If it happened, but it hasn't.
To succeed as a programmer, develop better powers of discernment (by observing others you respect) and learn how to maintain confidence in your decisions.
..."self writing programs in the armchair IT publication "PC World". I think it was the July or August edition. It was about this company that is writing the "next generation" of development tools. They suggest that in the near future everyone will be a programmer because this new approach basically lets anyone build their own applications by pointing and clicking and writing basic text descriptions of what they want the application to do. Then this development environment sets out to building the application to their specs.
To me, I thought... "Aha! He wants to make programming go the way that word processing and data entry did after the 80s". For the youngsters in the audience, believe it or not, but there used to be a very short lived period of time when people went to school to learn how to become word processors or data entry specialists. As soon as GUI based word processing and office suites were released, those people lost their jobs because "anyone could do the tasks". Is that really true though? Read on...
Yes, it is true that pretty much anyone who is plunked down in front of GUI based word processing software or an office suite can build a pretty impressive looking document. It doesn't require schooling anymore, just some introduction and you're off. But, does that mean that same person can design a glossy publication like a magazine or even a well done news letter? No. What about the person who can set up a basic spreadsheet? Would you want them being the DBA for your Oracle database? Probably not. So the titles have changed and the availability of jobs shrunk. I think you're going to see the same thing with programming.
There probably will be a point when the average office jockey will be able to build a basic application for use in their workplace. But that guy isn't going to be a programmer and the program he built isn't going to be efficient, compact or reliable. Programmers will still be needed, but just not in the way that they are now. It's likely that programmers will become more specialized. (Just like you now have graphic design people who are the extension of the more talented word processors of the late 70s) Programmers aren't going to disappear. They are going to become something else.
Un-news
Now this writer is talking about "codeless development environments" which are (like the 5GLs and expert systems of yesteryear) supposed to replace programmers.
The way I see it, if the current demand for software systems doesn't change, this argument may possibly hold *SOME* water. However, users keep pushing what they want onto the cutting edge of what current systems can do.
For an analagous example, look at processing power. When companies come out with faster processors, do we just run the same applications, but now just faster? No. Not only do our standard applications do new and *cough cough* wonderful things, We find new and exciting uses for our extra processing power. which in turn pushes the need for even faster processors.
It seems that the extra time made available by the eases of case tools, intelligent IDEs and more intuitive syntax is being put to use implementing more sophisticated architectures, developing more robust business logic and implementing more useable software overall.
Without the increase in productivity associated with evolving programming tools (ie languages,environments,frameworks) would we have more programmers working on projects of the same scale as today, or the same number of programmers working on projects with less usability?
... from the article, the author states that 'coding is dead' because
Ahh, the mythical Blue Unicorn; users will be able to make their own Uber Apps and developers will sink into the La Brea Tar Pits. That could be the case if development was only banging code. It is actually deconstructing a business process/issue into manageable chunks, then writing code to make those chunks work together. I have yet to meet a business person who can explain the function of their job in a linear process, so there is no way that person could write their own program, unless you had a magical CDE that could translate abstract, random process descriptions into real code (forget about efficient code/processes).
Ahh, the anonymous factory that churns out components that our business person can then assemble into a working application? Been there, tried that with EJB. Somehow that whole promise of component EJBs never really took off. I wonder why? Could it be that this idea is CRAP? Hmm...
Non Sequitur. The number of quality jobs aren't decreasing. The monkeys that thought they could get a MCSE and start making $65k with no experience are (hopefully) flushed out of the pool. Soon the monkeys who are unable to do the work of Business Analyst/Junior Project Manager will also be gone/outsourced. The jobs are there; you just have to know how to look for them.
Another non-sequitur. A degree means nothing in terms of fitness for doing a job---except to PHBs who don't know how to judge a candidate's worth other than by dead trees (resume/degree: equally worthless). You can certainly be a good developer without having ever taken one college class. What matters is skill, experience, adaptability, talent, and self motivation to learn new stuff.
More:
Yes, last week, in fact. I've been plowing through Vol 3 looking for a better way to search a bunch of stuff across multiple iSeries/DB2 files. So what? Reading Knuth doesn't mean you're a better code monkey. It can help, but just like any other resource, it is in the application. Einstein said something to the effect that the most important fact one could know is the Library's address.
Yeah, right.
Slashdot will become extinct if they keep posting this mindless dreck.
/.
I posit that AI out there can already write articles better than this dreck. So perhaps Dreck writing should already be extinct, but here we yet again see more dreck on
About the time we have code writing AI, we will have passed Vinge Singularity and all professions will be extinct.
I have to wonder if the author ever worked on anything other than web pages. Or very simple coding issues.
I work in telecom with a university educated work force (including PHDs and Masters degrees) and these folks have a tough time building quality systems given the constantly changing requirements , competitive demands and huge complexity of the systems.
Complexity is only increasing as we go forward. In almost any field you now have much larger programming teams working on more complex problems.
This is as Naive as when the thought high level laguages (moving from assembly) Cobol, Visual Basic, OOP, 4GL, 5GL etc... would eliminate programming as a profession.
As the tools became more powerfull, the problem space became more complex. If anything there has been a push beyond the toolsets and coding today is more difficult than it has been in the past, rather than simpler.
Programming large scale complex systems is so difficult now that hardly any groups out there consider it manageable.
If there is any profession where we currently can't easily get a handle on, it is programming in the large. Once you have AI that can handle this, what couldn't it do?
You do realize that historically it is normal for around 35-40% of the non-institutionalized working age (ie not imprisoned or commited) population not be employed?
t xt
ftp://ftp.bls.gov/pub/special.requests/lf/aat1.
And if you'd like to see about part-time workers you can get recent statistics here:
http://www.bls.gov/webapps/legacy/cpsatab5.htm
Please note, there's nothing wrong with a part of the population being employed part time by choice. The BLS statistics differentiate these as people employed part time for economic/non-economic reasons... if you look at the stats you'll see around 4-5 million people are employed part-time for economic reasons. You can find those stats here:
http://www.bls.gov/webapps/legacy/cpsatab5.htm
According to the BLS the labor force is around 150 million:
http://www.bls.gov/webapps/legacy/cpsatab1.htm
Out of a labor force of around 150 million that means that we have about 3-4% of the labor force working part time because they can't get full time work. While I'd prefer this to be a lower percentage, it doesn't seem to be a great and shocking problem.
Also, would you please source your data above. Absent primary sourcing I've absolutely no reaon to believe your facts.
1. Article is a bit wordy. If the author's Java code is as wordy as that article, then no wonder he sees code generators replacing him. The trick is factoring repetition so that you don't need code generators. If Java is not dynamic enough to factor, then use Python or Lisp or the like.
2. Automation has NOT been a significant factor in my domain. Code generators are usually used by people who write bloated code to begin with. OOP's poorly-defined relationship with relational databases has also created a demand for tools attempting to bridge that gap by generating code. If anything, this OO/R conflict increased demand for coders. (Note I am not bashing OO here, just saying there is a philosophical conflict with relational that has yet to be resolved, resulting in tedious translation efforts.)
3. AI is irrelavant because cheaper bandwidth means that machines and people can hook up with cheap overseas human brains. Why invent cheap brains when we have billions of starving eager brains around the world?
4. I don't see bookkeeping safe from the same forces. As more and more transactions are electronic, your bookkeeper can be in Asia also, along with the coders. Programmers may be the first hit, but I doubt they will be the last.
Table-ized A.I.
Isnt this pretty obvious? Java and Python are two "machines" that allow me to forget about areas of programming that people had turned into veritable art forms just a decade ago, things like memory management and code portability. People who are still doing that kind of work are the technological equivalent of blacksmiths--still needed for some niche roles (kernel hacking, scientific computing), but by and large a relic. The same may be said for the ever-increasing (quality and quantity) assortment of code libraries available today, and for code reuse in general.
I don't think this is a bad thing; I don't agree with the chicken little tone of this story. If we have a lot of blacksmiths--e.g. high skilled, labor-intensive jobs--dominating any given sector, they should be disappearing at a healthy clip. The US (or any country, for that matter) is left better off as a result. That's just plain and simple Econ. 101: technological advancement drives long term growth and prosperity. Programmers (esp. on Slashdot) are quick to lament the de-commoditization of their profession, because it means lower wages and more competition than that to which they became accustomed in the nineties. But there's no denying that in an overall, macro sense, having a nation full of Java programmers will result in much greater overall well-being than one of 10,000 C haxors and 250 million farmers.
I think there is a world market for maybe five personal web logs.
First of all, your argument comparing programmers to blacksmiths is already a counter-proof for what you are saying.
Sure, we don't have many blacksmiths, but let's look at the role of a blacksmith:
All they did was make things out of metal. They were what we now replaced with machines. The few innovative blacksmiths, who created new advances, were what are now engineers. Nothing has changed - only evolved. And what was once a role for a person is no longer.
Now, you are saying that there will be no need for programmers in the same sense of how we no longer need blacksmiths. But I ask you, do we have a programmer re-type every line of code for each and every piece of software that is sold? Because that would be the role of a 'blacksmith' programmer.
A programmer (or large group of) writes the first piece of software, which must usually be innovative, or better then what exists, in order to provide a use. Sure, there are countless pieces of code being re-written, or written poorly, but that is more for learning than for business, at least if they plan to survive. And when there are copies of software in the mainstream it is merely for economical competition, which will never change.
With the open source movement, or even with API's of old, there is no need to write every line of code over again, but rather to use them to make whatever new piece of software it is that you are planning to make. This involves making software that has never existed, which cannot be automated.
So I conclude that software programmers have never from the start been blacksmiths, or at least have not been for a very long time. What we provide is a constantly changing, evolving, and adapting use of logic in the form of code. No automation will ever replace that.
The number of programmers will not be decreasing to extremely low numbers either, since the more advanced software becomes the harder it is for individuals to create it. Large groups are required, for long periods of time (How long does it take to make a new game or operating system compared to 20 years ago).
You argument is not only wrong in practice, but wrong in theory. It's ridiculous.
Now that I've studied for more than 4 years, I learn it is going to be useless.
College isn't a trade school, and you shouldn't treat it that way. The most important thing you learn in college is how to learn. In many, if not most, fields what you learn in college is outdated by the time you finish (if it wasn't when you started) but it does (or should) give you a strong background from which to learn other things. In graduate school you learn how to learn things that nobody knows yet.
As an example, an undergraduate physics degree from a pretty decent school will get you to about the mid-1950s as far as physics knowledge, with a few little tastes of stuff from the 70s(and maybe even the present, if you work in someone's lab). You can fake your way into a lot of engineering jobs from there, and if you go to graduate school, you catch up to maybe the 70s (or even 80s and 90s) in a lot of areas, and you take one small piece of physics right up to the present day and become a world expert on it, adding new knowledge at the leading edge. All the stuff you learn along the way provides important context and background knowledge, but the most important thing you learn is how to obtain new knowledge. If you need any of that stuff that you didn't have time to learn (because the field has gotten very large) you at least get the tools to go back and catch up quickly. Computer Engineering has to be much the same, if not more so, since things are changing even faster than in physics.
I'm begging someone to take away this blow-hard's keyboard.
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
There's a better model than blacksmiths: musicians.
Before the advent of recorded music, if you wanted music, you paid musicians to come around and play it for you. It was expensive to keep them, they became status symbols, but they were commonplace in wealthy households and courts.
After recorded music came, the number of musicians required dropped off amazingly. Just tanked.
Programmers are increasingly headed in that direction because of automation: better and better libraries, software packages with increased configurability, better management of software projects. It's gradually getting easier to make a given problem go away with fewer and fewer programmers.
The countertendancy - as large problems become cheaper to solve, more people pay for them to be solved - is sustaining us for the moment, but there is no guarentee that those two forces will remain in step indefinitely.
But even in the age of fluidly configurable, massively integrated software packages (try: Apache 2, MySQL4 and WordPress - millions of lines of code with a nice user interface, and all it does is run your blog) there's still a need for the "rockstars" - the programmers who actually produce those systems.
Professional musicians these days have to fight to stay in the game, and they have to be really, really good at *something* even if it's just pouting on posters.
Programming is going the same way: it's no longer the easy option. If you're programming right now for a reason other than "I'm really good at this" or "I love this" and, preferably, both - get out of the game while you still have an income. You have less than ten years, possibly more like five.
Two more jobs, if you're lucky.
But for the rest of us? The people who can hack it under these conditions? I think it's going to be a return to the Golden Age of Hacking - the time when it was a game for the profoundly talented and educated - rather than these hordes of analgorithmic munchkins we've been competing with for years.
Rock star programmers, dude. Not garage mechanics, rock stars. You can see it already in the celebrity accorded to people like Linus, or EvHead. As software is increasingly "one hit, one kill" - packages which simply dominate an entire category - that kind of rapid rise and fall is going to be the norm, rather than the exception, in the publically popular software sphere.
That's the rock star niche.
And the rest of us will be like those touring rock bands you see all over America, or the players at your local symphony hall.
Hexayurt - open source refugee shelter,
The premise of the article is also similar to the kinds of arguments people were making in the '80s about expert systems:
"We can develop inference systems for all these professions with voluminous, but highly specialized knowlege bases, and then we won't need the highly trained professionals anymore".
This also harkens to a software engineering fantasy that we can standardize and simplify hard problems. There are many who disagree with this point of view, including Fred Brooks.
An interesting take on the failures of software is Jaron Lanier's One Half of a Manifesto. (Actually even more enlightening is the debate that ensued around the manifesto (responses, reply).
I think the author was rewarded in school for writing long sentences with big, trendy words. This sort of ridiculous blather is the result.
Some of my favorites:
uh-huh
Sure, they'll mechanize that one any day...
mt
30 years ago, a large percentage of the programmers out there were writing what was basically spreadsheet code. Some manager needed some information, and that meant a programmer had to write a program to read data, generate reports, and add them to the daily jobs. Then came spreadsheets, and the manager could do that work instead. The programmer was out of a job...
Well, no. Instead, he worked on more sophisticated analyses, software that didn't fit in Visicalc or Lotus 1-2-3.
Time after time over the decades there's been predictions that some new productivity tool was going to replace programmers. It hasn't happened. Because what a programmer does, basically, is to do the things that people havethought up that haven't yet become popular enough or common enough to be canned in a tool.
The advent of the Codeless Development Environment
If what you're doing doesn't involve code, it's not development, it's configuration. And that's great, because having programmers wasting time on configuration is a drag on productivity. Anything you already know how to do, that you've already written code to do, you don't do it again. If you do, well, that's a problem you need to fix, write a program to do it, go on to something else...
Chances are if you're a blacksmith in this day and age, you're actually in pretty high demand. My father-in-law does it as a side "hobby". Sells some of his stuff a local craft shows, demonstrates at schools...he's really good, and people are willing to pay decently to get him to make them stuff.
There may come a time when we need fewer programmers, like blacksmiths. But those that are will be special "craftsman". We'll just have to change our style to fit with the times.
Adapt or die...the way of nature.
Sean D.
"Hmm. I am to metaphor cheese as metaphor cheese is to transitive verb crackers!"
I will say that I agree with him on hyper-human skills. Computers are being used in the wrong way. When I worked for a dot com, everyone was raving about alltheworld.com, a flash in the pan search engine. I pointed out that I didn't want 60,000 matches--I just wanted the one that I was really looking for. They all looked at me funny. Computers are being used to flood people with data. What they should actually be doing is giving people the few pieces of data they actually need. And nobody in the dot com world seemed to grasp this. They had no idea what people actually wanted or needed. As Winston Churchill put it, "Give me this day, on one sheet of paper, the following information..."
But the current great extinction has nothing to do with any of the things he's talking about. It has to do with the outsourcing, the bust of the dot com bubble, and a popular belief that now that the dot com bubble has burst, you don't have worry about that computer stuff anymore (I kid you not--a lot of technophobes out there actually think it is all going to go away.)
There is no question that programming will evolve, and that we will work at higher and higher levels in the future. But it is equally true that as the methods ramp up, so will the target, and competition to produce software that reaches that target quickly, efficiently, and easily will demand the best solution, which is always hand tweaked. Build by number tools are always general--2,000,000 lines of code used to do what 1000 lines would do better, because the code is literally written with no idea of what the real task is. And to use these high level tools effectively there are always "Tips, Tricks, and Traps," which require a background knowledge of the underlying architecture to grasp.
And by the way, assembler still does everything better than anything else. Check out Gibson Research (http://www.grc.com/) for proof of that.
As for genetic programming, allow me to contrast the hand coded solution to the genetically designed solution:
Hand coded: 2 + 2 = 4;
Genetic: 1 + 1 + 3 - (4 * 3) + 3 + (6/2) + 2.5 + 1.5 + ln(e) = 4
Yeah, it will give you the right result... eventually. But if you want to read your email, you better book a couple days time with WETA's server farm. Not to mention that it takes as long to train one of these as it does a human--and it takes someone who knows a lot about computers (a very good programmer) to specify the criteria. A good example: the Pentagon wanted a genetic algorithm that could recognize a tank. They got one that seemed to work, until a new set of photos were used. It turned out that all the criteria photos with tanks were taken on a sunny day, and all the others were taken on a cloudy day. So if the sun is out, it's a tank. Doh!
The more sophisticated the software is, the harder it is to fix when something goes wrong. Superficially simple applications for complex tasks are that much harder to diagnose and fix when they fail. Windows appears easy, until a bug rears its head, and then it takes thousands of man hours just to track down the cause. Linux has a steeper learning curve, but a core simplicity once you're over the hump. Simple software is simple because the brain is built in. But that doesn't mean that the brain will always work.
Eventually, someone will have to go down and sing to the metal.
Maybe you guys didn't catch this sure-fire sign of overly-academic writing (sometimes also found outside academia, alas):
The pomo coder stripe has evolved into something quite different than what it once may have been.
You probably thought that word was "porno" -- but no, it's short for post-modern, and it's thrown around all the time for no good reason in academia. I stopped reading the article after seeing that, and a smattering of insofars and posits when I flipped ahead to part 2. Oh yeah, and I ran into this:
But as we will see, the impact on the exogenous environment of remittable activities of autonomous agents can be profound indeed.
Indeed, indeed. That's a great sign that you are reading a paper that will take thousands and thousands of words to argue something that could have been said in three crisp, short paragraphs. Nothing against the writer -- he's got a great vocabulary, and he's using the words correctly... but you see this all the time in academic writing, because "it just doesn't sound right" without a few latin phrases and a "dialectic" or two, because everyone around you is writing like this, too. Sadly, it only complicates or even loses the real argument, and most of your readers who have never been force-fed this kind of fare and made to like it will also be lost. So, to the author: Fight the impulse!! Turn away from the dark side! Therein lies a twisty maze of passages, all alike....