Jean Sammet, co-creator of COBOL, has died | Hacker News Reader

Jean Sammet, co-creator of COBOL, has died

nytimes.com

429 pointsandrewbinstock105 comments

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.

probably not the only ones but the first I hear of, you and your brothers also programmers ?

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!

fantastic ;-)

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.

Also see "Hidden Figures" for a real story about undervalued women (or at least at first) in the science field.

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.

All true. Downvotes wholly unjustified. Penultimate sentence says it all. Great movie though.

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.

Maybe there is a fear that a large portion of people will take it as literally true?

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.

You may find this piece interesting to provide some context to why this was: http://gender.stanford.edu/news/2011/researcher-reveals-how-...

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.

Dijkstra said it best in 1975: https://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/E...

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.)

It's not as sophisticated as you may suppose :)

https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_73/...

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.

Seems like the best language to compare cobol to is probably assembler, with a lot of #defined macro expansions?

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.

PL/I on CP/M? Really? Must've been Subset G :-)

CP/M was written in a different subset of PL/I, PL/M

https://en.wikipedia.org/wiki/PL/M

The PL/M source code for various version of CP/M can be inspected here: http://www.cpm.z80.de/source.html

(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.

yeah, when I'm writing SQL today I get flash-backs to the old punched card lab.

Thanks. This quote is worth repeating:

"Besides a mathematical inclination, an exceptionally good mastery of one's native tongue is the most vital asset of a competent programmer."

And yet, people with much linguistic proficiency are rare in the field of software development. I don't know why this is so, and it is a tragedy.

Is that really true? I have found that typically the best coders are the clearest writers of English as well

> 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 ;)

Why is linguistic proficiency important for programming though? Aside from writing documentation

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.

Maybe the ability do distill the essence and to present it clearly?

Also: https://gettingreal.37signals.com/ch08_Wordsmiths.php

>Unlike FORTRAN and Lisp, it begat nothing.

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++.

That's true for COBOL too.

FORTRAN compilers were great for loop optimizations, but not clear if it pioneered much else worthwhile.

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.

Which programming language was begat by FORTRAN

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.

Come on man, that's harsh. Where's the programming language you made?

HN is full of people who know everything, except how to hold their bladder while standing on the shoulders of giants.

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.

Being a cynic is easy. Which programming language(s) did Dijkstra promote?

Apparently it changed over time:

https://news.ycombinator.com/item?id=1373443 https://tekkie.wordpress.com/2006/05/31/rediscovering-dr-dij...

Her work on the History of Programming Languages conference is enlightening. Good reading if you can get a hold of it.

http://research.ihost.com/hopl/HOPL-I.html

Good reading if you can get a hold of it.

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.)

She had a large impact on modern business. My own mother works in IT and writes COBOL for a living.

Thanks for your contribution, Mrs. Sammet

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.

Don't feel bad. She finds it funny: https://www.youtube.com/watch?v=gv4KrY9GhQQ

I would assume "Jean" to be a woman and "Gene" to be a man.

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.

Visual COBOL:

https://www.microfocus.com/products/visual-cobol/

Compiles to native code, JVM bytecode, or MSIL (.NET).

PL/SQL is a descendant of Ada rather than COBOL, and it's at least as much real programming as making web stuff.

And Ada syntax is in turn derived from Pascal.

"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).

Previous discussion:

https://news.ycombinator.com/item?id=14437092

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.

It'll go back down; there's a spike in demand right now.

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

She proposed natural language programming over 50 years ago. http://dl.acm.org/citation.cfm?id=365274

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.

although there have been some research projects and some closed source applications like Inform7 and WolframAlpha.

Just as an FYI, Inform7[1] is - according to Wikipedia anyway - available under the Artistic License[2].

[1]: https://en.wikipedia.org/wiki/Inform

[2]: https://en.wikipedia.org/wiki/Artistic_License

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].

[1]: http://inform7.com/sources/inweb/ [2]: http://inform7.com/sources/webs/

Currently the status of the publishable release for the ni compiler component is "as of April 2009, about two-thirds done"

Blimey. :-( Here's hoping it sees the light of day at some point!

Black-bar worthy?

Jean Sammet- Your contribution to Software Industry will always be remembered. I really love Cobol. We developers salute to you. RIP Sr. Vice President - IT https://www.globaliim.com/32-it-management-certificates/gene... www.sc-digital-engineering.com

Janet your contribution to Software Industry will always be remembered. I really love Cobol. We developers salute to you. RIP Sr. Vice President - IT GIIM https://www.globaliim.com/32-it-management-certificates/gene... www.sc-digital-engineering.com

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.

DISPLAY SPACES UPON CRT.

No black bar? There's billions of lines of COBOL throughout the world. BILLIONS!

HN should have a black bar in honor of this.

She passed away May 21, which is 2 weeks ago, so this is not exactly news I am afraid.

+1 to this.

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.

Or was it a product of the computers at the time?

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.

https://www.youtube.com/watch?v=f1DtY42xEOI

Just turning the machine on requires coordination between several people using intercom.

Thank you for the video! It was interesting to see the binary adding exercise!

Or perhaps you need to be a frustrated machine language programmer?

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."

http://www.paulgraham.com/hundred.html

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.

Fred Brooks on COBOL - https://cycle-gap.blogspot.in/2009/08/fred-brooks-on-cobols-...

Reply on news.ycombinator.com