If you haven’t seen the Rust programming language before, this image shows the example from the front page of the Rust website. The site states, “Rust is a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety.”
“There are only two kinds of programming languages: those people always complain about, and those nobody uses.”
~ Bjarne Stroustrup
I’ve become a fan of Mary Rose Cook’s work over the last year or so, and in this article she shares four programming skills that she considers critical.
This is another good quote from a blog post titled The Downfall of Imperative Programming: “Did you notice that in the definition of ‘data race’ there’s always talk of mutation?”
“A language memory model is a specification that describes the circumstances under which a write to a variable becomes visible to other threads ... a purely functional programming language, which doesn’t support mutations, does not need a memory model at all.”
I try to leave no stone unturned when writing a book, so I’m taking a little time to learn Erlang to write my book about functional programming in Scala. The two books are Programming Erlang and Learn You Some Erlang for Great Good.
One last quote from Joe Armstrong, which highlights how a person looks at something based on their background: “If you’re coming from the Erlang/Haskell world you’ll think, ‘Swift is verbose and a bit of a mess,’ but if you’re coming from Objective-C you’ll think, ‘Swift is concise and elegant.’”
We should grow things (software applications) by adding more small communicating objects, rather than making larger and larger non-communicating objects.
Concentrating on the communication provides a higher level of abstraction than concentrating on the function APIs used within the system. Black-box equivalence says that two systems are equivalent if they cannot be distinguished by observing their communication patterns. Two black-boxes are equivalent if they have identical input/output behavior.
When we connect black boxes together we don't care what programming languages have been used inside the black boxes, we don't care how the code inside the black boxes has been organized, we just have to obey the communication protocols.
Erlang programs are the exception. Erlang programs are intentionally structured as communicating processes — they are the ultimate micro-services.
Large Erlang applications have a flat “bus like” structure. They are structured as independent parallel applications hanging off a common communication bus. This leads to architectures that are easy to understand and debug and collaborations which are easy to program.
~ From this post by Joe Armstrong, author of the book Programming Erlang: Software for a Concurrent World
In the “Maintaining the Erlang View of the World” section of his book Programming Erlang: Software for a Concurrent World, Joe Armstrong writes, “The Erlang view of the world is that everything is a process, and that processes can interact only by exchanging messages. Having such a view of the world imposes conceptual integrity on our designs, making them easier to understand.”
androidpolice.com is among those reporting about Android Studio 2, and near the bottom of their article I was reminded of this xkcd.com cartoon about programmers slacking off because their code is compiling.
Computer programming languages ranked by "expressiveness", from http://redmonk.com/dberkholz/2013/03/25/programming-languages-ranked-by-expressiveness/
A description of 'beautiful code' by Ward Cunningham. From the book, Clean Code.
From Urban Dictionary: The theory that computer programmers obtain quasi-magical, superhuman coding ability when they have a blood alcohol concentration percentage between 0.129% and 0.138%.
From this terrific article on parallelism vs concurrency.
From the original article by Joe Armstrong:
Concurrent = two queues and one coffee machine.
Parallel = Two queues and two coffee machines.
This is one of the best comics I’ve seen in a while. Why you shouldn’t interrupt a programmer (at least not while they’re coding). Here’s a link to the full comic.
I don’t remember where I first saw this, but I just ran across it yesterday.
I’m not sure if there’s a joke in here somewhere, but some interesting people are talking about the anic programming language (http://code.google.com/p/anic/), while its wiki page shows that the project itself is dead.
I love this comment from Martin Odersky, from the image shown, which comes from this link:
“Initially, things were too fluid to invest in tests. I simply did not know whether the design would hold up, had to fit a lot of pieces together first. But now is a good time to put these tests in place.”
So often people talk about “Test First Development” that I think they’re insane, or just regurgitating marketing-speak to sound good. There are times when you’re coding things like SARAH where you don’t know how things are going to shake out that “Test First” just doesn’t make sense. If you know what you’re getting into when you’re coding, Test First sounds good, but when you’re exploring, “Oh, this is how SARAH should work”, or, “I thought an FTP server worked like this but it works like that”, Test First doesn’t make sense. (Once you understand the domain, giddyup, test your heart out.)
Monday, Monday, la la, la la la ... image from this link on Twitter.
Google software development information, from this Twitter link.
