I've been watching a TV called "Halt and Catch Fire", about the early PC industry in the 1980's. I've enjoyed it very much, but sometimes I feel like the writers sacrifice historical plausibility to create strong female leads for a contemporary audience.
Ironically, so many of the GIANTS of computing's earliest days were female. Even at the rank-and-file level, women made up an astonishing number of early programmers. If you talk to retirement age people in our field, you'll find that mainframe developers were commonly female all through the 1960's and 1970's. It wasn't until the PC revolution that the field shifted to become more exclusively male.
I wonder when we'll see writers and TV/film producers start to explore that period of history? I'm sure there are some amazing stories that could be told. The crazy thing is, even if you just presented the field as-is without any embellishment, most people would assume that you were re-writing history in the name of political correctness. Most of the general public (hell, most young professionals in our field) just has no idea about this.
I started my career in 1996 working in the University mainframe department at UAB (Birmingham, AL) that ran the administrative systems (grades, bursar bills, departmental accounting). Our team was half women, my manager was a woman, and most of the institutional knowledge of the systems was in the head of one amazing woman (Joyce Iannuzzi) who had worked there for 20 years and insisted on working from an original IBM 3270 terminal.
I've worked with mainframe programmers and power users and they clung to their genuine 3270 terminals for good reason. All the emulators and substitutes had issues with keyboard differences and iffy keymapping.
My mother was a programmer in the mid to late 60s, a job at which she met my father — at the time married with four children. They were married in September 1969, a month before my brother was born.
I doubt that my siblings and I are the only 40-something children of two programmers, but I suspect that there are fewer 30-somethings that can say the same thing
I'm 28 and both of my parents were engineers back in Ukraine (at the time Soviet Union). My dad was not primarily a programmer (ended up becoming a marine surveyor), but I am fairly sure he had to be involved with it at some point in his studies and career back then. I remember my mom would bring stacks upon stacks of used punched cards for us to doodle on to avoid wasting blank paper.
My older brother is an IT manager, I'm a Principal Engineer at Amazon, my sister has worked variously in real estate, finance, and education.
Of my four half-brothers, I believe that two work in the industry (we're not close). One certainly wrote a book on X programming before I even knew what X was!
The way that Halt and Catch Fire was unrealistic is that the women I've known who enjoyed and were good at programming were not emotionally volatile at all.
HBO's Silicon Valley does a much better job portraying this personality type.
I stopped watching HCF after the first season because I was tired of the show going out of its way to point out that all the main characters are a bunch of screwed-up emotionally unstable whackjobs.
Not just the female characters, either. Remember Gordon's breakdown when he dug up his backyard?
Watching the show made me feel like I was babysitting every less-than-stable person I've interacted with all at the same time, and it was so emotionally exhausting I couldn't bring myself to watch another season.
It's a shame, too, because I really love the premise of the series. A show about the early days of the PC industry set in my hometown? I was so excited about it... but I just couldn't continue.
The truth behind Hidden Figures was in some ways more heartening, but less amenable to a film centered around social-justice issues, than thr movie showed. For instance, Katherine Johnson never had to run all the way across the complex to use the colored bathroom. She used the white ladies' bathroom and no one batted an eyelash.
It was not all peaches 'n' gravy for these women and their contributions are unfortunately overlooked today. But Hidden Figures was made to make a point, and its narrative serves that end.
I disagree. The downvotes are completely justified because of the penultimate sentence. It has been a trend by "alt-right", "white nationalists", etc. to put sufferings of African Americans under the umbrella of everything but racism - e.g. discrimination was on economic/gender/political basis but not on race. This rewriting of history cannot be supported.
Also look at the comment from "throwawayhf" to find if the African American women were indeed forced to use colored bathrooms. Racism is not an invention by Hollywood.
Yes, to be clear, the "social-justice" "narrative" in the film is a relatively hamfisted and shallow one saying segregation is bad. A large portion of the film is a (good) story about the daily lives of black women in the 1950s, which is also by far the most fictionalized, and therefore editorialized, part. I mean, at the end of the day these women were working for an organization that was a mix of propaganda and military-industrial complex. The work they were doing is, within the film, contrasted to political radicalism of the period (much of which in turn we would consider run-of-the-mill today).
"The point" it was trying to make is a straightforward one: NACA/NASA employed a shitload of black women, several of whom offered extraordinary contributions to the USA's space program. As if an ordinary contribution to such a major national myth weren't already noteworthy enough!
To bring it back to Jean Sammet, because this is her thread: To the extent the film is political it's because we've forgotten or hidden the foundational contributions of women to so many aspects of science and technology, and likewise raise a disturbing aura of exceptionalism among those we do remember. Sammet did good work and shared her expertise in the field for many years, or as Booch put in the obit "Jean Sammet was a strong, consistent voice of integrity in [engineering discipline]." Would that any of us be so fortunately remembered!
I've done my small part to reduce the negative score of these comments, but I think it's worth noting that at least some of them may have come from lack of sourcing in the original comment, and your followup defending it. That might have reduced or eliminated downvoting (I would like to think it would eliminate it, but...)
If someone has enough information to call out a representation as wrong in certain aspects, generally they have the ability to include the source of that knowledge, or at least why they can't include it (I seem to recall a book but can't remember the title... etc).
It's true but it's also misleading. For instance, it's true that Johnson didn't have to run across the campus to the bathroom, but Jackson did. (And someone did complain about Johnson's use of the unmarked bathroom, but only after she had been working there for long enough she had the social capital to ignore the complaint until segregation nominally ended.)
The film does suffer from trying to compress a whole office of computers into just three people, and a whole remaining government bureaucracy into another handful (Costner, Parsons, etc). It also has to do this while covering a part of the space program most people today are not familiar with (technically NACA not NASA, Atlas and earlier). At the same time, it's reasonable to cut out the 90% that's normal office work, because it's boring and doesn't help us understand the time or situation.
Most of the events have strong factual footing, with the notable exception of Costner's white savior moment. If you want more information, the book is dry and a little disorganized, but of course much more thorough about the timeline and who did what.
Well said. I would also add: why did this bathroom thing even need to be pointed out?
Is it not obvious that it and other moments in this movie were hollywood slices of a horrific, decades-long, deliberate campaign of dehumanization and oppression?
Was the point that because the bathroom scenes as depicted were not 100% historically accurate that the oppression of African Americans was somehow misrepresented or exaggerated?
Maybe the commenter is aware that all of the memorable vignettes in Apollo 13 did not occur exactly as presented there because they were exciting distillations of what actually happened. Do they normally call those out when talking about the meaningfulness of the movie Apollo 13? I doubt it.
Possibly because it presents these things without any backup sources, and because donning the guise of agreeability but undermining a point (especially a 'social justice' one) is a fairly common tack among 'alt right' and 'dark enlightenment' types. I didn't downvote it, but I can see how someone might reflexively.
I wonder if that was because in the very early (punch card) days it was not uncommon for women to be employed as "coders" literally typists who would transcribe code onto cards from written code sheets prepared by programmers.
It would be natural for many of them to learn how to program from reading so much code.
Even some movies about the male giants would be a start (I guess there was one about Turing, but I haven't seen it).
Otoh maybe the subject doesn't lend itself so much to movie making, as most of the action happens inside of people's heads. So far the movies that have been made seem to focus on some other drama going on in the depicted person's lives.
And before you get angry at me, answer this simple question: have you actually ever used COBOL? I spent a year of my life translating a COBOL mess into Delphi. It was horrible - the code I was working with had no functions (unless you think of a module defined in an entire file as a function), global scope on variables, and tons of ugly COBOL boilerplate, as dictated by the language.
And it's no surprise that COBOL was a historical dead-end. Unlike FORTRAN and Lisp, it begat nothing.
That's why I'm hard-pressed to venerate anyone that had anything to do with perpetuating that mess.
COBOL was designed for organizations transitioning accounting systems from unit record equipment. It makes sense in that context, and could have been much worse. Someone said (I think about FORTRAN, but it still applies) that criticizing the designers of those early languages is like criticizing Lewis & Clark for not taking Interstate 90.
> Unlike FORTRAN and Lisp, it begat nothing.
Cross-platform portability.
And long-windedness, though I don't count that a positive.
It's useful to review what the computing landscape looked like back then. The choice of language was either fortran, cobol, or assembler. And if you were automating business processes, your programs were reading fixed length lines of data off a tape.
So compared to assembler, cobol was a dream. Sure it was a dead end, and its creators seemed to lack the insight and sophistication of the Algol creators, but no one ever claimed it to be a general purpose language, and it did its job well.
Sure it's fun to bloviate, denigrate, and opine, in ignorance, but there are good reasons why it was widely used for so long, and why there are billions of loc still in production.
"your programs were reading fixed length lines of data off a tape"
COBOL could actually do more sophisticated stuff than that. For example, it had the "occurs depending on" construct, where you could read a record that had variable numbers of repetitions of a sub-structure, with the number of repetitions specified by one of the fields. (I never actually programmed in COBOL, but I've had to deal with code that had to support COBOL-style data structures.)
I've used COBOL for about 2 years. Like any other tool, you could get used to it and it got the job that it was intended for done. The fact that it didn't have the niceties of modern languages is simply because it was conceived of long before those modern niceties existed or were validated outside of the realm of research.
So beware of criticizing an old programming language from a modern viewpoint, just like FORTRAN and Lisp it taught us a lot of valuable lessons. If all the COBOL code in the world that is still running would stop working tomorrow morning at 9 am you'd definitely notice.
Delphi was launched decades after COBOL and so of course had many more modern language concepts built into it. It also had a fantastic little IDE and in general was a more comfortable environment to work on (by way of being on a PC rather than a mainframe).
To really appreciate COBOL you should look at the entirety of the environment that it was used in rather (where batch processing was the norm and subroutines rather than function s where the code blocks) than to compare just the language features. You also may have noticed the occasional 'CALL' verb, which was COBOL's way of modularization.
I think that your impression of COBOL may have been a little bit clouded by that one job. I've seen some really readable COBOL, and given that the alternative was assembler and that those programs were patiently put together line-by-line on punched cards and never ever were refactored using an interactive editor should go a long way towards understanding why we make progress in little steps rather than in huge strides.
Delphi came into existence by way of Pascal, which is from the ALGOL family of languages, an entirely different branch on the tree of programming languages. Comparing Delphi with COBOL directly is not really very useful because you'd be comparing a language made for interactive applications on PCs in the late 80's with a language made for batch applications on mainframes in the 60's. The 20 years in between were the most important years for the IT industry when it comes to language development.
That would have probably been the alternative but assemblers in those days did not usually support macros and if they did they were of very limited power.
Also, the GPP was rather adamant about COBOL being a dead-end but Pascal actually owed a fairly large chunk of its data structures to COBOL and without the 'record' construct I highly doubt Pascal would have gone as far as it did, it was a good idea whose time was ripe and COBOL being business oriented had immediate need to support this (as well as data files), and then there was the fact that COBOL more or less introduced platform independence (though in practice that translated into 'less work than otherwise').
All in all it really is not fair to label COBOL a 'dead end'.
> And it's no surprise that COBOL was a historical dead-end. Unlike FORTRAN and Lisp, it begat nothing.
Not entirely true. One obvious thing it influenced was PL/I, which was supposed to unify FORTRAN and COBOL along with block-structured programming from Algol. PL/I was only ever moderately successful. While it saw some use in business data processing, COBOL was always more popular for that task. I think its biggest successes were systems programming (e.g. Multics, CP/M, MVS, Honeywell CP-6) and compiler development (e.g. the compiler for the HAL/S language used to program the space shuttle computers). (In most of those applications, they didn't use pure standard PL/I, rather dialects such as PL/M, PL/S, XPL). In those applications, compound data structures are very important, and the PL/I syntax for those was obviously influenced by COBOL (in the use of level numbers). And PL/I has in turn influenced several other languages, I think the most notable would be REXX, although I'm not sure how much of the COBOL influence survives in those descendant languages.
Other languages COBOL arguably influenced include DIBOL (a business programming language developed by DEC, it was a mishmash of COBOL, FORTRAN and BASIC) and ABAP (SAP's application programming language, derisively nicknamed "German COBOL").
Ada annex F (Information Systems) was consciously influenced by COBOL, especially in the concept of "picture strings". I think the influence of COBOL picture strings can be seen in other languages also, e.g. the date formatting syntax used by java.text.SimpleDateFormat. So in that small area, arguably Java is descended from COBOL.
I personally think the syntax of SQL shows some definite stylistic influence from COBOL. A similar wordiness and proliferation of keywords. Since SQL was designed by IBM in the 1970s, and the first implementations of it ran on IBM mainframes, obviously the team that invented it were very familiar with COBOL, and it shows.
English Wikipedia reports that the legacy telecommunications programming language CHILL (CCITT High Level Language) was influenced by COBOL–no idea how true that is. Polish Wikipedia reports the existence of a mid-1960s Soviet language called "Algek", which was based on Algol and COBOL. Around 2000 someone invented a language called "CobolScript", which was supposed to help COBOL programmers get into web development – it didn't take off.
This is all odds-and-ends, but it isn't literally nothing.
(Maybe I am being somewhat inaccurate in calling PL/M a "PL/I subset"; maybe it would be more accurate to say that PL/M is a distinct language which was heavily influenced by PL/I, a member of the PL/I language family.)
> CP/M was written in a different subset of PL/I, PL/M
It is somewhat amazing to me that I can't recall that I ever knew that, despite once having owned a CP/M machine and having written some software for it. I always assumed it was written in assembly.
> the best coders are the clearest writers of English as well
Thats what I found as well, which is why we need more of them. Maybe it is a german thing, but I can tell you that we don't have a lot of those types doing software development. Maybe because people here are more likely to study humanities instead than in the US? I really don't know.
I heard that good lawyers can earn more than good coders. And dunno about Germany, but in my country brain drain is also a problem. And I'm not sure if there really are that many smart people to begin with ;)
If you can sum up algorithm or object structure you create in a single paragraph reading of which saves me four hours of puzzle solving, then it is super useful. Same with one line explanation of clever unusual hack.
Also, code review comment that teaches something instead of just vaguely alludes that "this is bad". It is better when junior learn why instead of memorizing seemingly arbitrary rules.
Also, communication in the team and out of team. If you can explain why the estimate is too small or that users/managers/customers naive idea is, well, naive (without using that word), then you are the gold. If you can ask the question in a way that makes people understand what you are asking and gives you answer, you are double gold.
If you can explain why the proposed design change or style guide change would be helpful, then you don't have rely on snark and put-downs when pushing for those changes (and thus avoid long term consequences such style has). And so on and so forth.
Which programming language was begat by FORTRAN? The ALGOL family seems rather independent to me.
Both FORTRAN and COBOL had the misfortune to be created before structured programming. Others, like FORTH and LISP were lucky that they are flexible enough to easily add new programming conventions.
You could probably say that modern report generators were begat by COBOL to some degree (even though FORTRAN had formatted output too)
It seems programming languages designed to be "easy to use" suffer from lots of people writing really terrible code with it. Excel or VB have similar issues.
Since Fortran had a large amount of existing code soon after it was invented, the standards committee has always tended to add new features to Fortran after other languages had already tried them out and perhaps discovered pitfalls.
From my experience working on compilers, the thing Fortran begat the most was advanced compiler optimization algorithms, which then trickled down into C and C++.
FORTRAN pioneered expressions which were used in addition to statements. This was huge. Modern languages are still expanding on the idea of programming with expressions (especially functional languages).
BASIC was clearly begat by FORTRAN. This is easier to see in the 1960s versions of both languages, which used line numbers and GOTO statements for program flow, although later versions of both FORTRAN and BASIC borrowed structured programming elements from the ALGOL family.
Fortran->Matlab->Julia is a pretty obvious family tree. Much of how numpy and similar libraries do numerics is also quite obviously influenced by Matlab (and thus Fortran).
"Projects promoting programming in "natural language" are intrinsically doomed to fail."
And yet Python became a thing. In Djikstra's defense, Python's design philoshophy is more about striving to be a "highly readable language" rather than to emulate a "natural language", but the two are almost interchangeable in practice.
Then again, the argument is not against the wide use of the language, but the way the ideas are manifested. For all we know, Dijkstra might have hated Python.
>"For all we know, Dijkstra might have hated Python."
Dijkstra died in 2002, which was after Python was released. There may be some comments from him out there about the language, though I can't be bothered to look them up, I don't find Dijkstra to be particularly insightful.
It's worth noting that Dijkstra was a computer scientist, not a programmer. From Wikipedia:
> Despite having invented much of the technology of software, Dijkstra eschewed the use of computers in his own work for many decades. Even after he succumbed to his UT colleagues' encouragement and acquired a Macintosh computer, he used it only for e-mail and for browsing the World Wide Web.
I think Dijkstra was writing from a very specific perspective, and that is mostly only relevant today from a historical viewpoint.
I was reading through a survey of programming language history the other day in Michael Marcotty's Software Implementation, which includes this quote from Jean Sammet (1969): "COBOL ... encourages a certain amount of verbosity. The benefit gained from this, however, is increased readability and understandability in looking at programs."
Marcotty writes: "The important thing is not whether the committee was right in its conclusion, but that a serious effort was being made to design a programming language for communication between people as well as with computers."
To put this in context, consider this quote from Backus and Heising (1964) about Fortran: "[Our group] had one primary fear: ... an important application ... would run at half the speed of the hand-coded version. It was felt that such an occurrence ... would almost completely block acceptance of the system."
I wrote a fair bit of COBOL back in the 90s, and read a lot more of it.
There are so many different ways that software can be bad. COBOL had plenty of warts, sure, but it also had a very top-down simplicity to it. I'm the FNG at a new job and have been given a shitpile of Magento to shovel; I think I'd rather have the COBOL. (I'm pretty sure Magento is the absolute worst example of what somebody can do with PHP.)
COBOL didn't support any of the abstractions that programmers today abuse to as an excuse to build out intractably tangled messes of code so that they could refer to themselves as "software architects". That alone has kept a soft spot for it in my heart.
In addition to that paper, I raged against COBOL for a long time.
It wasn't until on my first consulting gig writing RPG III for a year, that the IBM guy installed COBOL on the system 34, and Presto COBOL wasn't all that bad.
For its time it was better than alternatives. After a while, not so much.
Many public library systems have inter-library loan arrangements with universities. This is a great way to get access to research works like the HOPL proceedings.
(I live in Montgomery County Maryland and just checked to see if I can get them via my local public library branch. Yup.)
I guess it says something sad about my prejudices that I saw the name "Jean" and assumed it was a man's name. I forgot that the field was so much more inclusive of women back then.
I was thinking French. I kept seeing notable programmers with female-sounding names like Jan and then realizing it was a non-Anglophonic man's name that's spelled like an English woman's name.
Cobol's legacy lives as PL/SQL, ABAP, and other enterprise data handling languages. While everybody is quick to point that this is not "real programming", they required astonishing amounts of engineering efforts to make things work.
I would love to see a decent, modernized COBOL -- the same way they have modernized Fortran, so it is now a pretty decent numerical computing language. It would be a great hit.
COBOL has been "modernized" quite a few times, but the syntax still looks pretty archaic, most likely to avoid breaking too much existing code. I'm sure backward compatibility is of paramount importance for it.
I saw that there's a version that compiles to .NET bytecode, so you could conceivably write an XBox game in COBOL.
"real" programming like all the "C"-type languages e.g. JavaScript etc., are just filled with gobbly-gook special characters that lead to mistakes. However, it wraps spooky robes around those eho choose or have to master this junk. COBOL was/is bulky, but at least it attempted to be somewhat understandable unlike the "real" programming.
I disagree. "Real" programming languages attempt to be understandable by choosing and building around an appropriate set of abstractions for their purpose.; it's true that some were designed around various types of resource constraints based on the environments for which they were designed that involve terse expression of the abstractions, bit that's done to make them usable in that environment, not to “wrap spooky robes” around the programmers.
And excessive verbosity can be as much of an impediment to clarity as excessive terseness.
COBOL 2002 is object oriented. Not sure if that is what you mean by modernized and I'm also not sure how many people actually use it. I have the specification for COBOL 2002 and have been meaning to write a compiler for it but just haven't taken the time to sit down and actually do it (especially because there is no simple BNF grammar in the spec and I'd have to piece it all together).
Although Ms. Sammet's passing has been previously discussed here on HN, this new NYT article provides a different and somewhat more colorful perspective on the life of this remarkable woman. Worth a read.
Her book "Programming Languages: History and Fundamentals" is not available as an eBook and is out of print and costs over $100 used on Amazon. Would be great if there was a cheaper way to read it.
Coincidentally I had bought this book from abebooks.com just a couple weeks before Ms. Sammet's passing. I looked again just now, and there are a few copies available for less than $100. However, the prices seem rather higher than they were when I bought my copy.
Though it looks only useful for the listing and factual description of languages at that time:
47[12].- -JEAN E. SAMMET, Programming Languages: History and Fundamentals,
Prentice-Hall, Inc., Englewood Cliffs, N. J., 1969, xxx $ 785 pp., 24 cm. Price
$18.00 ($13.50 student edition).
Programming Languages: History and Fundamentals is a monumental and encyclopedic
treatment of its field. The primary aim of the book, as stated by the
author, is to provide, ". . . in one place, and in a consistent fashion, fundamental
information on programming languages, including history, general characteristics,
similarities,'and differences." This aim has without doubt been achieved, and achieved
well. A second aim is"... to provide specific basic information on all the significant,
and most of the minor, higher level languages developed in the United States." This
aim also has been achieved; there is an impressive collection of about 120 languages
described in varying amounts of detail.
The book is organized into three introductory chapters, six chapters on languages
grouped more or less according to application areas, and two chapters on unimplemented concepts and future long-range developments. The organization is well
thought out and suits the author's purposes admirably. The first chapter is devoted
to defining what is meant by a programming language, to pros and cons of higherlevel
languages, to classifying and categorizing languages, and to a presentation of
factors influencing the choice of a language. Omitted from consideration are most
European programming languages, and certain languages that are not, by the
author's definition, higher-level programming languages, e.g., Report Generator,
Autocoder, APL and SLIP. The second and third chapters are devoted to describing
functional and technical characteristics of programming languages, partly with the
aim of developing a format for the later discussions of specific languages. Functional
characteristics, roughly, are the historical, political, economic, and pragmatic
aspects of a language, i.e., those that are not part of its definition. Technical characteristics
have to do with the actual syntax and semantics of the language. This
outline of discussion is spelled out in some detail and generally adhered to in the
sequel. The fact that approximately equal amounts of space are devoted to functional
and technical characteristics is an indicator of the tone of the discussion. The
author does not attempt to teach the reader how to program in any of the languages
discussed, and indeed, one certainly would not learn programming from this book.
As a reference work for background on specific programming languages, the
book is a success. As a textbook on programming languages as a field of study, it
is not. The tone of the introductory chapters is too platitudinous, and the technical
information, both in depth and in organization, is inadequate to the task of imparting
a feeling for what programming languages are all about. The difficulty is that
this feeling can ultimately be achieved only by actually writing programs in various
languages and thus coming to appreciate their fine points. Thus, the uniformity of
organization across languages is achieved at the cost of omitting really deep examination
of a few of them. The chapter on technical characteristics attempts to raise
the issues of what choices a language designer must make, but the question of how,
historically, they have been made is scattered among the different language discussions
and never really explored in depth. Questions such as scoping rules, extensibility,
and the structuring of data aggregates are never treated in a unified way, and
the material on minor languages and on functional characteristics tends to deemphasize
the importance of the technical characteristics of the major languages.
There are no exercises in the book, and, indeed, the material provides no basis for
exercises.
In summary: Programming Languages: History and Fundamentals is a fine source
for factual knowledge, but a poor source for gaining understanding.
PAUL ABRAHAMS
There still hasn't been a whole lot of progress, although there have been some research projects and some closed source applications like Inform7 and WolframAlpha.
The most interesting part that translates the natural language Inform 7 code to the more traditional Inform 6 code has not been open sourced. Graham Nelson talked about wanting to release the code as literate programs[1]. Currently the status of the publishable release for the ni compiler component is "as of April 2009, about two-thirds done"[2].
COBOL was a foundation language in CS101 30 years ago and it was outdated then. There were jobs in legacy COBOL. Probably still are. It sucked but not as hard as RPG II.
To like COBOL, you need to posess a particular kind of rigid corporate mindset. I wonder whether it's fathers/mothers had the mentioned physic structure, or it was a fruit of 50's salaryman mental subjugation. No offense ment.
Here's a 1959 computer, donated to a school in 1965. This was filmed in 1969. One of the children wrote a language - minigol - so the younger children didn't have to use assembler.
Engineers can create amazing applications in any a language. I worked on General Ledger:Millennium (GL:M) as a youngster and I quickly came to appreciated it for what it was : an engineering marvel.
2030: "To like Perl, you need to possess a particular kind of BOFH mindset, a fruit of an 80s abused nerd mental subjugation."
2050: "To like Roar and Yavascript, you need to possess a particular kind of startup bro mindset, a fruit of a 10s ZIRP mental subjugation."
Well, Alan Kay already said it better. "Pop culture is all about identity and feeling like you're participating. It has nothing to do with cooperation, the past or the future — it's living in the present. I think the same is true of most people who write code for money. They have no idea where [their culture came from]..."
"I think that, like species, languages will form evolutionary trees, with dead-ends branching off all over. We can see this happening already. Cobol, for all its sometime popularity, does not seem to have any intellectual descendants. It is an evolutionary dead-end-- a Neanderthal language."
What is this point of this quote? I downvoted this comment because it does not contribute to the discussion. A common tactic is to post a quote, wait for people to refute the most common/charitable interpretation of the quote's meaning in the context of discussion, then to reply with "that's not what I meant" and end it satisfied.
So tell us, what is the point of bringing up this quote?
Poster isn't biting on this request. Somewhat ironically the quote is sourced from an article about a disfavored language arguing why cobol should be a disfavored language.
Engineering is subject still to styles and fads, I guess the quote is just furthering that general mentality. COBOL isn't "cool" whatever that should mean.
The purpose of species is to reproduce themselves. The purpose of programming languages is not to produce other languages but to write software. It seems Cobol served this purpose well at the time.
Ironically, so many of the GIANTS of computing's earliest days were female. Even at the rank-and-file level, women made up an astonishing number of early programmers. If you talk to retirement age people in our field, you'll find that mainframe developers were commonly female all through the 1960's and 1970's. It wasn't until the PC revolution that the field shifted to become more exclusively male.
I wonder when we'll see writers and TV/film producers start to explore that period of history? I'm sure there are some amazing stories that could be told. The crazy thing is, even if you just presented the field as-is without any embellishment, most people would assume that you were re-writing history in the name of political correctness. Most of the general public (hell, most young professionals in our field) just has no idea about this.