Itook a look at the Turbak/Gifford book, but it's too long-winded; I thought Winskel would be fine, but I have no access to it (it's not in our University library, and I'm short on money), and I'm not even sure if it's not dated. Slonneger seems OK, but the practical part makes it somewhat too long, and I'm not very comfortable with his style.
It all depends how deep you want to go, and how much you already know. For a beginner Winksel's book is really nice, but yes, it's not introducing you to the state of the art in semantics as it was written about 20 years ago. Nevertheless it's still a good first introduction to the subject. It might also be worthwhile pointing out that T. Nipkow has formalised a substantial chunk of Winskel's book in Isabelle/HOL, see here. So if you want to learn using interactive proof assistants together with understanding the semantics of programming languages, you have a lot of coherent material to draw on.
Gunter, Semantics of Programming Languages, a more advanced book focussing on denotational semantics, an approach to semantics, which hasn't lived up to expectations. Focusses on purely functional lanugages and ignores concurrency. This is the book that I taught myself semantics from as an undergraduate, and in retrospect I wish I had used Winksel's book instead. Gunter is not an easy read for a beginner.
Books like Pierce's TAPL are very nice, but focus narrowly on one aspect of programming languages, namely types, as important as that is. I would not recommend it as a first introduction to the general area of programming languages, but it is mandatory to read for anyone who wants to learn about types.
Truth be told, I think there's currently no up-to-date introductory book on language semantics that reflects the substantial progress the last decade has seen, with its decisive shift away from denotational methods and sequential computation to concurrency (process calculi and game semantics), axiomatics semantics and the use of interactive proof assistants in verification.
which can be seen as 'Winskel in Isabelle/HOL'. It's an introduction to thesemantics of programming languages (primarily operational andaxiomatic) but unlike previous pen-and-paper-based approaches, thisbook expresses all its mathematics in Isabelle/HOL. In other words,it's at the same time a book about theorem proving.
I would divide the books on programming language semantics into two classes: those that focus on modelling programming language concepts and those that focus on the foundational aspects of semantics. There is no reason a book can't do both. But, usually, there is only so much you can put into a book, and the authors also have their own predispositions about what is important.
Winskel's book, already mentioned, does a bit of both the aspects. And, it is a good beginner's book. An equally good, perhaps even better, book is the one I started with: Gordon's Denotational description of programming languages. This was my first book on semantics, which I read soon after I finished my undergraduate work. I have to say it gave me a firm grounding in semantics and I never had to wonder how denotational semantics differs from operational semantics or axiomatic semantics etc. This book will remain my all-time favourite on denotational semantics.
Tennent's Semantics of programming languages, which is a more-or-less uptodate book on the semantics of imperative programming languages. It is easy to read. However, it tends to be abstract in later parts of the book and you might have to struggle to see why things are being done in a particular way.
Reynolds's Theories of programming languages. Anybody specializing in semantics should definitely read this book. It is after all by Reynolds. (David Schmidt once remarked to me, "even if Reynolds is reading out the morning newspaper to you, you want to listen carefully, because you might learn something important"!) It has good coverage of both the modelling aspects and foundational aspects.
The best books on foundational aspects are Gunter's (which I regard as a graduate text book), and Mitchell's (which is good reference book to have on your bookshelf because it is quite comprehensive).
I really enjoyed reading Winskel when I was taking the undergrad course on semantics. I can't tell if it's dated, though, since I don't do research in this field. A plus of Winskel is that you can find it translated in other languages than English.
For a further reading, more at a graduate level, I'd suggest John Mitchell's books Foundations for Programming Languages and Concepts in Programming Languages. If you read only the first chapters, I guess they also meet your requirement of conciseness.
First, there are some people who have already read the book and provided reviews on it. For instance, for the Winskel book The Formal Semantics of Programming Languages (see [1] and [2]) I found reviews on Amazon.
This book confuses between syntax and semantics since the beginning, like separating the literals from its values. No special notations were used to differentiate them. This is a crucial issue that the author should address in a topic like this. Also, some other notations he used is quite confusing, like showing the premises and conclusions.
The author seemed to assume that you have ALL the necessary prerequisites as he explained the background materials in a first few chapters (i.e. set theory, operational semantics, inductions, inductive definitions) very briefly. The style the author used in introduction is to put two or three paragraphs of texts and put some formulas then give exercises. Which is, for me, quite frustrating...
Second, Amazon offers Types and Programming Languages and Basic Category Theory for Computer Scientists along with this book. On another topic Dave Clarke offers these books as excellent ones on "Type Systems and Programming Language Semantics." Again, I'm not an expert, but those might be useful for you.
For a complete beginner studying operational semantics, I would suggest Programming Languages and Operational Semantics by Maribel Fernndez. Everything is explained in a very simple manner which is easy to understand. -1-4471-6367-1
I have it very similar. I feel like whenever I need to understand a topic better, I rush and buy a book about it. Or whenever PragProg releases something Elixir related or interesting in some other way, I do the same.
Then after reading few chapters, I just skim the rest of the book to get some kind of overview to know where to look if I need more information.
A good programming book encourages you to open your programming IDE and actually type the code, to experiment, think or thicker. Reading books also allows you to understand and develop a common language with your collogues.
Something I have found though (and I wonder if any of you have too) is that I find it harder to get into the mindset to read, and I think this is because of how our brains are changing thanks to social media/dopamine hits. I read recently that young people can only concentrate for short bursts now, I find that worrying.
So, not all books worth being studied, specially this way, some of them requires a brief reading and some books are meant to be used as a reference, meaning that you only need to know which book contains which information, so you know where to look for when you need that information.
I am checking whole book like quick reading about 1 or 2 hours, and try to create a simple project and apply the simple properties from the book. For me the best way create the project is the best to become talented developer.
@Juan: I know Juan, I know - but there are some things that can only be learned by actually getting down to the task at hand. Speaking in abstract ideals all day simply makes you into an academic. It's in the application of the abstract that we truly grok the reason for their existence. :P
@Keith: Great mention of "The Inmates are Running the Asylum" by Alan Cooper - an eye opener for certain, any developer that has worked with me since I read that book has heard me mention the ideas it espouses. +1
While this doesn't teach you programming, it teaches you fundamental mathematics that every programmer should know. You may remember this stuff from university, but really, doing predicate logic will improve you programming skills, you need to learn Set Theory if you want to program using collections.
The idea being that there are failing parts in any given piece of software that are masked by failures in other parts or by validations in other parts. See a real-world example at the Therac-25 radiation machine, whose software flaws were masked by hardware failsafes. When the hardware failsafes were removed, the software race condition that had gone undetected all those years resulted in the machine killing 3 people.
Extreme Programming Explained: Embrace Change by Kent Beck. While I don't advocate a hardcore XP-or-the-highway take on software development, I wish I had been introduced to the principles in this book much earlier in my career. Unit testing, refactoring, simplicity, continuous integration, cost/time/quality/scope - these changed the way I looked at development. Before Agile, it was all about the debugger and fear of change requests. After Agile, those demons did not loom as large.
This book explains a lot of things about software engineering, system development. It's also extremly useful to understand the difference between different kind of product developement: web VS shrinkwrap VS IBM framework. What people had in mind when they conceived waterfall model? Read this and all we'll become clear (hopefully)
Excellence in programming demands an investment of mental energy and a dedication to continued learning comparable to the professions of medicine or law. It pays a fraction of what those professions pay, much less the wages paid to the mathematically savvy who head into the finance sector. And wages for constructing code are eroding because it's a profession that is relatively easy for the intelligent and self-disciplined in most economies to enter.
3a8082e126