Slashdot Mirror

As a fellow scientific programmer, I am curious to some of those "I've read a few outstanding books on the subject since then."

Could you be so kind as to give me a few pointers? Thanks a lot!

Ugh. I knew someone would ask that. I don't actually keep a bookshelf with these tomes.

Oh, good - here's an article that has a few: http://www.infoworld.com/artic...

Since college:
"Code Complete" by Steve McConnell (2004)
"The Pragmatic Programmer" by Andrew Hunt and David Thomas

A fun book to do with colleagues:
"Seven Languages in Seven Weeks" - https://pragprog.com/book/btla...

If you're into OO:
"Design Patterns: Elements of Reusable Object-Oriented Software" Gang of four

Not coding, per se, but everyone who works in the field should read and have their boss read:
"The Mythical Man-Month" by Frederick Brooks

The best books from college (I haven't touched in nearly 20 years, but I'm really glad I had 'em back then):
"The C Programming Language" (2nd Edition, 1988) by Brian Kernighan and Dennis Richie
"Compilers: Principles, Techniques and Tools" - the dragon book

I agree. Threads are OK IF YOU USE THEM THROUGH A LIBRARY. It is a horror if you try to go down to the primitives and lock things yourself. shared objects and threads are an absolute no-no. The problem with locks is that they look very simple but the interactions are actually very, very hard. It is like building computers from discrete logic gates. Digital logic is not hard in principle, but the emergent complexity quickly becomes totally overwhelming.

All programmers should be required to read this:

https://pragprog.com/book/pb7c...

and Doug Lea's book about Java Concurrency.

http://www.informit.com/store/...

Lea is so good his stuff became part of the official Java Spec.

• Code Complete 2 was the most influential book I read on how to keep it simple. http://cc2e.com/
• The Pragmatic programmer taught me how to stick it to my manager and push for more time/testing: https://pragprog.com/the-pragm...
• Refactoring taught me how to clean up the code written by developers who didn't read these books. http://www.refactoring.com/
• Clean Code brings it all together. https://sites.google.com/site/...

These books provide much better information on the topic and deserve a place on your shelf alongside the GoF's Design Patterns.

Already got it. :-) It's the 7th entry, right below pragprog ...

* https://pragprog.com/book/ahmi... [pragprog.com]
* http://codecombat.com/ [codecombat.com]

Thanks for the suggestion though!

Can we get a FAQ please? Here are the common answers:

* Visually with Angry Birds characters: http://learn.code.org/hoc/1
* Scratch
* http://coderdojo.com/
* Minecraft mods
* http://www.learntomod.com./
* https://pragprog.com/book/ahmi...
* http://codecombat.com/
* http://boardgamegeek.com/board...
* http://boardgamegeek.com/board...
* http://www.gamebooks.org/show_...
* http://venturebeat.com/2014/06...
* http://meetedison.com/
* BASIC
* Vic-20 C64 Compute! magazine
* Raspberry Pi
* Arduino
* Logo

https://pragprog.com/book/ahmi...

I agree with the idea to study mathematics, as a useful exercise, that would in many cases benefit programmers by giving them a good mental workout, and hopefully reinforce if not expand their understanding of mathematics, logic, and reasoning.

Beyond that I would argue for the study of writing, in a natural (human-oriented) language of your choice.

Programming as a profession, and as an art, is about the meaningful expression of ideas; in a detailed, unambiguous manner that can be processed by a computer. Programming languages are tiny, simplistic, and restrictive in their ability to express ideas, and the execution of these ideas. Writing in a natural language is much more complex, particularly when you strive to remove undesired ambiguity*. The other issue is that as a professional, programming is not done in isolation. Even if you are an independent contractors, you must be able to communicate effectively with clients and users.

*) Ambiguity can be desirable in humor and poetry.

I think that any programmer can benefit from the abilities to make logically sound, comprehensible arguments in a written document; that these abilities will make them better in their ability to understand, and be understood by users, customers, or colleagues.

The argument has been made in the past by Steven C. McConnell in Code Complete, in The Pragmatic Programmer by Andrew Hunt and David Thomas, Coding Horror by Jeff Atwood, and Joel Spolsky (of Joel on Software) in his Introduction to Best Software Writing I and College Advice. And like tons of other software developers, and their managers; repeatedly.

You see, communication is the only really important aspect of software development that people really have trouble with. The rest are details and small bugs, but for really big screw-ups you need miscommunication (or greed)

Okay, assume you're very proficient in C#.

Microsoft Java. It is called "Microsoft Java"

Now sit down with a book and try writing good Haskell or Lisp or Prolog after a weekend.

Boom! Headshot!

O'Reily and Pragmatic Bookshelf and Baen all publish in major formats (pdf, epub, mobi, etc), all DRM-free.

The problem is when you can only get books from one location you are screwed.

Also, the fact that Amazon can retroactively wipe books off the Kindle means even after the sale, they can Take It Back, like if you buy a book from a brick and mortar and they follow you out to your car, throw you up against the side, rifle through your bag, take your book and then drop some coin on the ground (your "refund").

In real life, they'd get shot. Online, they get more money.

ebook/PDF is at http://pragprog.com/book/jkthp/the-healthy-programmer

No digital version? No Kindle, epub, mobi, PDF versions? I find it odd to come across a book for programmers that isn't available in digital form.

+ $27, that feels a bit much for a diet book.

Here we go The Healthy Programmer: Get Fit, Feel Better, and Keep Coding DRM-free Format
Still awfully expensive for my tastes, I'll wait till it goes down in price before I check it out.

I recently switched my scientific programming from R to Python with NumPy and Matplotlib, as I couldn't bear programming in such a misdesigned and underdocumented language any more. R is fine as a statistical analysis system, i.e. as a command line interface to the many ready-made packages available in CRAN, but for programming it's a perfect example of how not to design and implement a programming language. It's also unusably slow unless you vectorise your code or have a tiny amount of data. Unfortunately, vectorisation is not always possible (i.e. the algorithm may be inherently serial), and even when it is, it tends to yield utterly unreadable code. Then there is the disfunctional memory management system which leads you to run out of memory long before you should, and documentation even of the core library that leaves you no choice but to program by coincidence.

As an example of a fundamental problem, here's an R add-on package that has as its goal to be "[..] a set of simple wrappers that make R's string functions more consistent, simpler and easier to use. It does this by ensuring that: function and argument names (and positions) are consistent, all functions deal with NA's and zero length character appropriately, and the output data structures from each function matches the input data structures of other functions.". Needless to say that there is absolutely no excuse for having such problems in the first place; if you can't write consistent interfaces, you have no business designing the core API of any programming language, period.

Python has its issues as well, but it's overall much nicer to work with. It has sane containers including dictionaries (R's lists are interface-wise equivalent to Python's dictionaries, but the complexity of the various operations is...mysterious.) and with NumPy all the array computation features I need. Furthermore it has at least a rudimentary OOP system (speaking of Python 2 here, I understand they've overhauled it in 3, but I haven't looked into that) and much better performance than R. On the other hand, for statistics you'd probably be much better off with R than with Python. I haven't looked at available libraries much, but I don't think the Python world is anywhere near R in that respect.

Anyway, for doing statistics I don't really think there's anything more extensive out there than R, proprietary or not, although some proprietary packages have easier to learn GUIs. In that field, R is not going to go anywhere in the foreseeable future. For programming, almost anything is better than R, and I agree that those improvements you mention are not doing much to improve Rs competitiveness in that area.

Some more:

http://nostarch.com/
http://pragprog.com/
https://www.baenebooks.com/t-drm.aspx
http://www.dragonmount.com/index.php/News/book-news/new-drm-free-ebook-store-r401
http://lifehacker.com/5946956/grab-a-bundle-of-drm+free-ebooks-on-the-cheap

http://codekata.pragprog.com/ This kata is borrowed from the martial arts and some even goes as far as making kata dojos (http://codingdojo.org/cgi-bin/wiki.pl?KataCatalogue)

Wow, Argument from incredulity on teh interwebs.

I've written rails apps that supported a very large newspaper's site, which got well over 15 MILLION pageviews per month. Never once did my apps stumble or crash.

Like anything else, you have to know what you're doing, boychik. Now go read pp 14-16 of the Pragmatic Programmer and learn a little.

IMHO, git is a shining example of bad design. You need too much info on how it works on the inside, to be able to use it. It is simply way too complicated. I regret the fact that it seems to be the most popular VCS for open-source projects. I'd prefer something simpler like bzr.

Git is very often explained wrong. Especially for those brain-damaged by the use of CVS or SVN. (I myself was/am too). And yes, 'brain-damaged' is a quite fitting term in this case. Think switching from Basic to OOP Java. That's the magnitude we're talking about here.

A matter of fact is that Git is extremely easy to understand, as every concept it covers is exactly everything you need to know about versioning in order to understand versioning correctly. The main problem I think is that with distributed Git, everything one knows about Subversion as a commit actually is covered by 'git push' which, as it involves merging two single repositories, allways includes a merge. Imperative merges are rarely done in regular use of centralized subversion, which is why Git may seem cumbersome initially. However, it never gets more complicated that understanding that concept of 'git push', your regular special-case superset of a merge. In fact, this is one of the great advantages of the Git workflow. Since basically everything team related always has a merge involved, merges begin to lose their scare and become a part of every-day regular versioning usage. Which is exactly how it should be.

Once one has gotten over the initial speed bump in learning, especially the one involved in moving from Subversion to Git, the insights are bedazzling. If you've used Git correctly in a Subversion replacement scenario, going back to SVN appears like going from Linux to DOS and you finally understand what Linus Torwalds was ragging about in that famous Google TechTalk on Git. And that's just for the regular versioning stuff you know from SVN, and not even including things like 'git rebase' or other luxuries.

I find a great introduction into the right way of grasping Git for the 'impaired by SVN usage' is this commercial video lecture by the PragProg people (10min Preview for free).

Their book on Git seems to be in the same ballpark quality wise.

After moving from SVN to Git - which took a few weeks time to get the hang of - I have to say that I now would second almost everything Linus Torwalds has to rag on about Subversion. Whenever I'm at my job where we use SVN, it feels like I've stepped back a decade or two. The crappyness of subversion and the elegance of git are simply unfathomable if you haven't used both extensively in versioning your projects. I personally find that even if you use Git as a drop in replacement for Subversion, mimicking the workflows including a centralised repos only used for pushing towards and pulling from, it still is light-years ahead of Subversion in every (un)imaginable way. Even the small things like configuring your ignores compare like Linux and DOS commandline between Git and Subversion respectively.

My KO criteria for Git 2-3 years ago used to be the lack of usable GUIs for Git and the abundance of mature SVN GUIs. However, today I'd stick with Git, even if all GitGUIs would vanish overnight.

My conclusion:
I strongly suggest you bite the bullet and wrap your head around what that what appears first as some arcane concept of Git and get to use it regularly. You'll very quickly find that Git has it right and Subversion has it wrong in countless ways you weren't even aware of. That's my experience anyway. ... The downside of that will be, of course, that you will lose your blissfull ignorance of the crappyness of subversion and will suffer whenever required to use it, be it at your job or elsewhere. :-)

My 2 cents.

IMHO, git is a shining example of bad design. You need too much info on how it works on the inside, to be able to use it. It is simply way too complicated. I regret the fact that it seems to be the most popular VCS for open-source projects. I'd prefer something simpler like bzr.

Git is very often explained wrong. Especially for those brain-damaged by the use of CVS or SVN. (I myself was/am too). And yes, 'brain-damaged' is a quite fitting term in this case. Think switching from Basic to OOP Java. That's the magnitude we're talking about here.

A matter of fact is that Git is extremely easy to understand, as every concept it covers is exactly everything you need to know about versioning in order to understand versioning correctly. The main problem I think is that with distributed Git, everything one knows about Subversion as a commit actually is covered by 'git push' which, as it involves merging two single repositories, allways includes a merge. Imperative merges are rarely done in regular use of centralized subversion, which is why Git may seem cumbersome initially. However, it never gets more complicated that understanding that concept of 'git push', your regular special-case superset of a merge. In fact, this is one of the great advantages of the Git workflow. Since basically everything team related always has a merge involved, merges begin to lose their scare and become a part of every-day regular versioning usage. Which is exactly how it should be.

Once one has gotten over the initial speed bump in learning, especially the one involved in moving from Subversion to Git, the insights are bedazzling. If you've used Git correctly in a Subversion replacement scenario, going back to SVN appears like going from Linux to DOS and you finally understand what Linus Torwalds was ragging about in that famous Google TechTalk on Git. And that's just for the regular versioning stuff you know from SVN, and not even including things like 'git rebase' or other luxuries.

I find a great introduction into the right way of grasping Git for the 'impaired by SVN usage' is this commercial video lecture by the PragProg people (10min Preview for free).

Their book on Git seems to be in the same ballpark quality wise.

After moving from SVN to Git - which took a few weeks time to get the hang of - I have to say that I now would second almost everything Linus Torwalds has to rag on about Subversion. Whenever I'm at my job where we use SVN, it feels like I've stepped back a decade or two. The crappyness of subversion and the elegance of git are simply unfathomable if you haven't used both extensively in versioning your projects. I personally find that even if you use Git as a drop in replacement for Subversion, mimicking the workflows including a centralised repos only used for pushing towards and pulling from, it still is light-years ahead of Subversion in every (un)imaginable way. Even the small things like configuring your ignores compare like Linux and DOS commandline between Git and Subversion respectively.

My KO criteria for Git 2-3 years ago used to be the lack of usable GUIs for Git and the abundance of mature SVN GUIs. However, today I'd stick with Git, even if all GitGUIs would vanish overnight.

My conclusion:
I strongly suggest you bite the bullet and wrap your head around what that what appears first as some arcane concept of Git and get to use it regularly. You'll very quickly find that Git has it right and Subversion has it wrong in countless ways you weren't even aware of. That's my experience anyway. ... The downside of that will be, of course, that you will lose your blissfull ignorance of the crappyness of subversion and will suffer whenever required to use it, be it at your job or elsewhere. :-)

My 2 cents.

fwiw, I'm having fun learning Clojure.
fyi: Programming Clojure (2nd edition) by Stuart Halloway and Aaron Bedra

You're never too old to learn. I'm in a similar situation to you: I learned a number of computer language and now, being almost 40, I don't do any programming at work anymore, I just do fancy diagrams. That doesn't prevent me from maintaining my programming skills in my spare time and learning new stuff. In the past couple of years, I've dabbled in Vala http://live.gnome.org/Vala, Python (to create scripts and desktop apps rather than web apps), re-acquainted myself with ANTLR and played with a number of other languages. If you want to have a go at an interesting variety, get yourself a copy of "Seven Languages in Seven Weeks" by Bruce Tate: http://pragprog.com/book/btlang/seven-languages-in-seven-weeks.

Yeah, Ruby is not what I would do either. Ruby is dying fast. While I'm not a huge Python fan, it's not a bad language. If you're on the UX side you should look at learning HTML5 and javascript libraries like jQuery and javascriptMVC.

Funny, after attending RailsConf last month, I'd say that reports of Ruby's demise are greatly exaggerated. In fact, if your perspective comes from a UX-oriented side of things, I couldn't imagine a better language/framework for you to get started with than Ruby/Rails.

It's only moving more in that direction. Rails 3.1 will include jQuery as the default JS library, supports CoffeeScript and Sass by default, and the new asset pipeline makes it easier than ever to build out your app with a backend REST API and do the heavy lifting on the client with MVC frameworks like Backbone.js

What you should learn first depends on your goals. Are you just curious about programming? Or do you really want to make a shift in your career path? If you work in a Ruby/Rails environment, and really want to get into the coding where you work, then that's the obvious choice. If you're completely new to coding, Ruby is also a marvelous first language to learn. I started with C and Perl, and I WISH Ruby had existed then.

If you just want to understand the dev side of things better, you could start by learning the basics of web development from something like Code School. Their Rails for Zombies course is a great place to start, and better yet, it's free. If you want to get your Ruby up to snuff, try Edge Case's Ruby Koans.

IMHO, much of the Ruby-hating is jealousy. If you're new to programming, you might be unfamiliar with holy wars. Coders develop religious issues over everything from languages, to tooling, to operating systems. You'll have to decide for yourself where you want to start. But Slashdot opinions are probably not the way to make that decision. My advice: Pragmatic Programmers has a very basic intro-to-Ruby book called Learn to Program. It might be too basic, it might not. But then you can check out Seven Languages in Seven Weeks and decide whether you prefer Ruby, Scala, Erlang, Clojure, etc.

I heartily encourage you to learn to code, whether you find it professionally or personally rewarding. Maybe you can contribute to some open source projects, even if you decide it's not right for your career. Either way, have fun with it.

In interest of full disclosure, I'm a committed Rubyist. We tend to be opinionated loudmouths. But also beware the Pythonistas. They tend to be disgruntled contrarian CS students.

Yeah, Ruby is not what I would do either. Ruby is dying fast. While I'm not a huge Python fan, it's not a bad language. If you're on the UX side you should look at learning HTML5 and javascript libraries like jQuery and javascriptMVC.

Funny, after attending RailsConf last month, I'd say that reports of Ruby's demise are greatly exaggerated. In fact, if your perspective comes from a UX-oriented side of things, I couldn't imagine a better language/framework for you to get started with than Ruby/Rails.

It's only moving more in that direction. Rails 3.1 will include jQuery as the default JS library, supports CoffeeScript and Sass by default, and the new asset pipeline makes it easier than ever to build out your app with a backend REST API and do the heavy lifting on the client with MVC frameworks like Backbone.js

What you should learn first depends on your goals. Are you just curious about programming? Or do you really want to make a shift in your career path? If you work in a Ruby/Rails environment, and really want to get into the coding where you work, then that's the obvious choice. If you're completely new to coding, Ruby is also a marvelous first language to learn. I started with C and Perl, and I WISH Ruby had existed then.

If you just want to understand the dev side of things better, you could start by learning the basics of web development from something like Code School. Their Rails for Zombies course is a great place to start, and better yet, it's free. If you want to get your Ruby up to snuff, try Edge Case's Ruby Koans.

IMHO, much of the Ruby-hating is jealousy. If you're new to programming, you might be unfamiliar with holy wars. Coders develop religious issues over everything from languages, to tooling, to operating systems. You'll have to decide for yourself where you want to start. But Slashdot opinions are probably not the way to make that decision. My advice: Pragmatic Programmers has a very basic intro-to-Ruby book called Learn to Program. It might be too basic, it might not. But then you can check out Seven Languages in Seven Weeks and decide whether you prefer Ruby, Scala, Erlang, Clojure, etc.

I heartily encourage you to learn to code, whether you find it professionally or personally rewarding. Maybe you can contribute to some open source projects, even if you decide it's not right for your career. Either way, have fun with it.

In interest of full disclosure, I'm a committed Rubyist. We tend to be opinionated loudmouths. But also beware the Pythonistas. They tend to be disgruntled contrarian CS students.

First, I love how everyone here is bashing him as a troll, calling him a non-developer, etc, etc. Yet anytime we get some glowing salespiece in favor of Apple, the fanboys start crawling out of the woodwork and modding down anyone who calls them on their BS.

Aw, does it hurt to have your favorite little toy's failings pointed out?

Looking at the tone of the piece, I'm pretty sure it's not a troll and it's not a marketing hit piece, and in case you were too lazy to click the link above, he *is* a professional developer. I think it's straight from the heart, and it hit so many chords with me, I couldn't help but wipe a tear from my eye. And I don't even do web development.

Second, I love how everyone is ignoring the points he backed up well. Any takers for the packaging mess in OSX that resembles Windows more and more? How 'bout that price tag? Sure, keep telling yourself you're paying for higher quality or "design".

As for some of the attacked points:

• Emacs: until you've written code with it - and I mean plenty of code - you just won't understand. Can anyone even name an editor/IDE besides vi where you don't have to remove your hands from home row all day? I've tried other IDE's (mainly Eclipse-based) that people have recommended. It always pains me how clumsy, slow, and resource intensive they are. Why should I have to break my flow to move my hand to the mouse to do something? Or even off of home row? Also, It is well-regarded advice that your editor should be configurable, extensible and programmable. Emacs and vi are the only two editors I've ever used that meet this criteria.
• His website design: don't know about you, but lack of Flash and JavaScript, as well as an elegant, readable layout are signs of a mature web dev, one who has gotten over the point-and-click to create a website phase.
• Portability/platform issues: this really shouldn't be an issue, especially with something as high-level as web dev, but unfortunately, it sounds like an OSX problem. Probably related to the packaging problem he mentioned (and no one has challenged). He's not the only who's had issues with OSX (and in case you don't know who Randall Schwartz is, you need to GTFO of slashdot and web dev right now).

Quite frankly, I'm glad to see this kind of article get posted. We have far too many Apple and MS fanboys here; slashdot was created by Linux users for Linux users, and this kind of from the heart, in the trenches opinion piece is much more worthy than some marketing piece about the latest shiny piece of crap to come out of Steve Jobs' ass.

It is available as an e-book here . US$30.59

Another e-book on the subject (I've started reading it and liked it, but didn't get around to finishing it yet) is Hello Android.

One thing I like about The Pragmatic Bookshelf is that they deliver directly to your Kindle. They are also DRM-free (Packt says they are too).

The Pragmatic Programmers.

The Pragmatic Programmers do a great job of this. Their books and videos are all DRM-free and all but the oldest books are available as unlimited downloads in ePub, mobi, and PDF format, so I keep copies on my eReaders (plural), phone, home, and work computers without any issues.

Lots of good suggestions on how to learn what to do.

This is a good book to show you common ways you can get yourself in trouble and how to avoid them: http://pragprog.com/titles/bksqla/sql-antipatterns

J

I recommend this one by the author of ANTLR, which is a far superior alternative to lex/flex yacc/bison IMHO. The book uses ANTLR as an example, but is not limited to it. It explores the theory of DSLs and the design around them. A great buy if you need to do this for a project.

http://pragprog.com/titles/tpdsl/language-implementation-patterns

The nice thing about the iPad, as opposed to the Kindle or the Nook, is that there are many ways to buy a book.

There are, in fact, many ways to buy a book for the Kindle and (even moreso) the Nook; both, in addition to supporting DRM-laden purchases from the device vendors own e-bookstore, support content in a variety of DRM-free formats (a slightly wider variety on the Nook) acquired outside the vendors e-bookstore.

And plenty of publishers with their own online bookstores make ebooks available DRM-free in PDF (usable directly on the Nook, and usable, as I understand, after jumping through some hoops on the Kindle), epub (usable directly on the Nook), and/or mobi (usable directly on the Kindle) formats. (The Pragmatic Programmers, for instance, do all three -- and you don't have to pay for them separately.)

The only "advantage" the iPad has in terms of more ways to buy books is that, since it can run different vendors e-bookstore apps, you have more ways to buy DRM-laden books from competing vendors.

TFA explains it: main() isn't the true start of the program, _start is. That resides in ctrl.o, which fires off a bunch of setup stuff before calling __libc_start_main, which in turn kicks off main(), and off your program goes.

If a programmer doesn't know this, they aren't competent to be programming, much less programming in spaces that may be critical (such as embedded). Don't use wizard code you don't understand. And it's "crt1.o", BTW.

Let me follow this up by saying that I don't want to discourage anyone from /learning/ how to program, especially the GP, as he or she seems interested enough in it to search out things like this. What I mean by "they aren't competent to be programming" is that until someone is familiar enough with the language and underlying hardware and software, they shouldn't try to pass off their programs as the most reliable or efficient things around. Things like the The Pragmatic Programmer are especially cogent to becoming a better programmer, even if you only take away this one lesson: understand the abstractions you use. The layers of computing have been built and tested for decades, and most of the time they make sense and make your life easier (that's what they are *for*). But make sure you at least use them properly, and the surest way to make sure you use them properly is to *understand* them, eg, know that GCC will attach a whole bunch of stuff to your program (because almost all programs use it) that you might not need.

TFA explains it: main() isn't the true start of the program, _start is. That resides in ctrl.o, which fires off a bunch of setup stuff before calling __libc_start_main, which in turn kicks off main(), and off your program goes.

If a programmer doesn't know this, they aren't competent to be programming, much less programming in spaces that may be critical (such as embedded). Don't use wizard code you don't understand. And it's "crt1.o", BTW.

http://projecteuler.net/index.php?section=problems
http://www.spoj.pl/problems/classical/
http://programmingpraxis.com/
http://codekata.pragprog.com/2007/01/code_kata_backg.html

At a Java con I went to a talk by Dave Thomas, one of the authors of The Pragmatic Programmer. The line that stuck with me was "A comment is a lie waiting to be believed."

These guys can't do math at all: http://www.pragprog.com/write-for-us

50%? Oh noes! They'll go bankrupt by the end of the year!

It was more of a programming language than an Operating System, but ERLANG has the stuff to do multi-core, well. Using ERLANG, they've actually achieved nine nines of uptime. That works out to well under a SECOND of downtime in a year. It scales (near) linearly as the number of cores go up, IO is the limitation.

You can read all about it here. Concepts like message passing and immutability is what makes it work.

Erlang actually lets you update the program while it's running. It has extensive error recovery. It's lack of shared state means you can not only go multi-core, but multi-system over networks - invisibly.

Seriously, It's the cat's meow for ultra-high-end high-performance, industrial-grade software solutions. If I were writing a stock exchange management system, I would probably consider ERLANG.

I once managed a junior programmer who would insist that the compiler had a bug in it when she couldn't get her program to work.

We eventually fired her.

Why do I mention this? Because, as a programmer, when I get results I don't expect, I tend to assume that I have made a mistake somewhere. I don't assume that the underlying theory of how computers work is in error.

Your anecdote looks almost entirely ripped off from The Pragmatic Programmer . :-) No, I'm sure this really happened in your company, but the book goes into this sort of thing at length... I believe the anecdote provided in the book talks about a developer who insisted there was a bug in a linker or loader on a particular system.

Like others who have commented here, I too have discovered a compiler bug on an old SPARC system that used register-based argument passing to functions. (A C function took a float argument, but the calling code used a 0 instead of 0f or 0.0, so the compiler dutifully stuffed a 0 into an integer register, while the called function attempted to read from one of the floating point registers, which sometimes contained leftover garbage. Type coercion/promotion was clearly not happening.) Like others, I know this is a rare occurrence, so I don't look for it except under exceptional circumstances.

That said, if they are indeed not seeing what they think they are seeing (at least insofar as what the object is, regardless of the behavior), then that's cause for alarm -- other observations of exoplanets come into question. But it's entirely possible that some unforeseen dynamics are coming into play, perhaps some kind of relativistic effect that isn't being accounted for. It wouldn't necessarily mean that all we know about orbital mechanics is "wrong," it just means someone didn't model the system right, and something important got left out.

I'm also pretty sure the scientists investigating this hot Jupiter exoplanet have done their due dilligence, have tried chasing down all the likely suspects, and are still left with a conundrum. I doubt they leaped to any conclusions right away that our basic understanding of physics is wrong, and based on TFA, it looks as though they still are being careful not to draw any undue conclusions.

Except that Clojure is NOT a dialect of Common Lisp. I wouldn't give someone an 'intro to Java' book if they wanted to learn C#.

Why not read a book specifically tailored to Clojure?

We pay 50% royalties for our technical books. We take what we receive for a book, subtract direct costs (printing, copy edit, artwork, and a few other things) and split it with you.

My first book (Ship It! http://pragprog.com/titles/prj/ship-it ) was with the prags and it was a great experience. The book is now in 6 foreign languages editions and I keep getting quarterly checks. The editorial process was incredibly difficult, but that's because they push you to be the best you can.

And the 50% royalty rate is really what you get. I can tell you exactly how many books have been bought and returned, PDFs vs paper books, etc. I've not heard of anyone being able to match the level of information they provide authors.

The build system is also insanely cool. You can render the book on your local box, so you can see how it looks as you go. That's really motivating.

I just published a book on Lulu.com (for a variety of reasons, none negative towards the prags), and it was nearly painless. If you do publish on Lulu, be sure to start with their Word template and that eliminates a ton of the pain. But Career 2.0 ( http://www.lulu.com/content/5925115 ), my latest, has so many more typos, etc in it that Ship It!... it was easier to write, but the editing quality suffered a bit.

Regardless of who you publish with, you'll sell if you market it. Otherwise it won't. You write articles (InfoQ, DZone, etc), you set up a blog, you go to user's groups... you're the main PR arm for your book. You'll get out of it what you put into it.

I'm surprised more people aren't recommending Pragmatic Bookshelf.

They seem to have great terms for their authors. I guess the only drawback could be that your particular open source book isn't something that fits with their established bookshelf, but it never hurts to ask.

Loading PDFs is trivial. The DX shows up as a standard USB flash drive, allowing you to drag and drop files into its Documents directory from any modern OS.

PDFs display well, though you'll want to turn the DX on its side to more closely approximate the width of a printed page. The DX can't reflow PDF text like it can with standard Kindle books. It became very obvious why Amazon didn't bother with PDF support on their smaller Kindles. Pragmatic Programmers offers their eBooks in .mobi format, so I redownloaded my existing library and copied the files over USB. Serious props to Pragmatic for being so... pragmatic. Manning's PDF books display well. O'Reilly, OTOH, adds huge and extremely obnoxious copyright headers and footers to their Safari PDF downloads that results in the actual book page being shrunk to a small illegible island in the middle of the screen. I've complained to O'Reilly about this, no word back yet. Outside of that inexplicable piece of design dysfunction every PDF I've thrown at the DX has worked well.

If you have trouble with eye strain like I do (Convergence Insufficiency, use the website to direct you to a clueful optometrist if you have trouble staying focused while reading or have vaguely ADD-like symptoms), the non-backlit Kindle screen is VERY nice. It's at least as easy on my eyes as paper, if not moreso due to the font flexibility.

You will want the Mighty Bright LED reading light Amazon recommends (requires 3 AAA batteries, not included), as well as the protective leather cover that Amazon should have included and you'll feel like a schmuck paying $50 for.

The Sprint-driven Whispernet wireless service is excellent. Being able to receive free book samples, read them, then purchase the full book from wherever I am (so long as I don't stray too far from civilization) is dangerously convenient.

I've very glad I waited for the DX over the smaller Kindle 2. If you have the cash, or have simply given up on paying off your credit card, I highly recommend it.

It is the Unix philosophy, as expressed in many places like The art of Unix programming or here (first paragraph, "small, sharp tools") or the Pragmatic Programmers (under Occam's razor).

Programming Erlang

First: Programming Erlang: Software for a Concurrent World
by Joe Armstrong
http://www.pragprog.com/titles/jaerlang/programming-erlang

The Erlang programming language is well suited to develop concurrent programs with.

The second book I'd recommend is
Distributed Systems: Principles and Paradigms, 2/E
by Andrew S. Tanenbaum
http://www.pearsonhighered.com/educator/academic/product/0,,0132392275,00%2Ben-USS_01DBC.html

Not specific to any programming language, but a very good introduction to the concepts and methods used developing distributed systems, as all multi-threaded programs are.

I highly recommend the book Learn to Program. http://pragprog.com/titles/fr_ltp/learn-to-program My teenage brother started with this book and loved it because it was clear and easy to understand and wasn't boring. Even my dad started to get into it.

The original Pragmatic Programmer book is excellent I think.
http://pragprog.com/the-pragmatic-programmer
And since I also think an "agile" approach to managing software development projects is essential for most companies (certainly for any web-oriented development), I'm planning to check out their Practices of an Agile Developer book.
http://www.pragprog.com/titles/pad/practices-of-an-agile-developer
Jim

The original Pragmatic Programmer book is excellent I think.
http://pragprog.com/the-pragmatic-programmer
And since I also think an "agile" approach to managing software development projects is essential for most companies (certainly for any web-oriented development), I'm planning to check out their Practices of an Agile Developer book.
http://www.pragprog.com/titles/pad/practices-of-an-agile-developer
Jim

if they follow the "pragmatic programmer's" approach:

hard copy: $36.95
pdf: $22.50

http://pragprog.com/titles/jaerlang/programming-erlang

Also, they do "social DRM", adding "Prepared exclusively for YOUR_NAME" as a small footnote on each page. I kinda like it.

Agile programming is a lot like what is described in the paper you linked to.

http://www.pragprog.com/titles/pad/practices-of-an-agile-developer
http://product.half.ebay.com/_W0QQprZ45402847QQcpidZ1294591165

I'm a big fan of agile, and each one of the points in that paper. I hope you do well; you can't put a price on good design principles!

it is likely that many of the examples will no longer work as described. I know that is the case with current version Agile Web Development with Rails.

One of the problems i have after going from FF2 to FF3beta on linux is that some specific pages (eg. http://www.pragprog.com/titles/ruby/programming-ruby) takes ages to render, hogging all CPU, and again when you switch to other tab and back (or simply overdraw the FF window). Now this may as well be problem in the Xorg or nvidia drivers, but other browsers and FF2 seems unaffected.

Another problem is the occasional flash freezing on 64bit, but that is problem of the flash plugin itself, not FF.