27 languages to improve your Python

Nick Coghlan writes:

One of the things we do as part of the Python core development process is to look at features we appreciate having available in other languages we have experience with, and see whether or not there is a way to adapt them to be useful in making Python code easier to both read and write. This means that learning another programming language that focuses more specifically on a given style of software development can help improve anyone’s understanding of that style of programming in the context of Python.

To aid in such efforts, I’ve provided a list below of some possible areas for exploration, and other languages which may provide additional insight into those areas.

The languages and areas are:

  • Procedural programming: C, Rust, Cython
  • Object-oriented data modelling: Java, C#, Eiffel
  • Object-oriented C derivatives: C++, D
  • Array-oriented data processing: MATLAB/Octave, Julia
  • Statistical data analysis: R
  • Computational pipeline modelling: Haskell, Scala, Clojure, F#
  • Event driven programming: JavaScript, Go, Erlang, Elixir
  • Gradual typing: TypeScript
  • Dynamic metaprogramming: Hy, Ruby
  • Pragmatic problem solving: Lua, PHP, Perl
  • Computational thinking: Scratch, Logo

Free Data Science Books

I came across a collection of free data science books:

Pulled from the web, here is a great collection of eBooks (most of which have a physical version that you can purchase on Amazon) written on the topics of Data Science, Business Analytics, Data Mining, Big Data, Machine Learning, Algorithms, Data Science Tools, and Programming Languages for Data Science.

Most notably, there are introductory books, handbooks, Hadoop guide, SQL books, social media data mining stuff, and d3 tips and tricks.  There’s also plenty on artificial intelligence and machine learning, but that’s too far out for me.

How does a relational database work

databases

How does a relational database work” is an excellent (lengthy, technical, but simply written and well explained) article on some of the most important bits inside the relational database.  It’s somewhat of a middle ground between a theoretical database discussion in college and vendor-specific documentation of a database engine.

Though the title of this article is explicit, the aim of this article is NOT to understand how to use a database. Therefore, you should already know how to write a simple join query and basic CRUD queries; otherwise you might not understand this article. This is the only thing you need to know, I’ll explain everything else.

I’ll start with some computer science stuff like time complexity. I know that some of you hate this concept but, without it, you can’t understand the cleverness inside a database. Since it’s a huge topic, I’ll focus on what I think is essential: the way a database handles an SQL query. I’ll only present the basic concepts behind a database so that at the end of the article you’ll have a good idea of what’s happening under the hood.

Whether you are a young programmer or an experienced DBA, I think, you’ll still find something in there which you either didn’t know or didn’t think about in this particular way.   Even if you know all this stuff, it’s a good memory refresher.

Strongly recommended!

Software Engineering Radio : CAP Theorem

On the way to work today I enjoyed an excellent episode of Software Engineering Radio which featured an interview with Eric Brewer, a VP of Infrastructure at Google,  probably more famous for his CAP Theorem.

In theoretical computer science, the CAP theorem, also known as Brewer’s theorem, states that it is impossible for a distributed computer system to simultaneously provide all three of the following guarantees:

  • Consistency (all nodes see the same data at the same time)
  • Availability (a guarantee that every request receives a response about whether it succeeded or failed)
  • Partition tolerance (the system continues to operate despite arbitrary message loss or failure of part of the system)

The discussion around “2 out of 3” was very thought-provoking and, at first, a little bit counter-intuitive.  If you don’t want to listen to the show, read though this page, which covers the important bits.

The easiest way to understand CAP is to think of two nodes on opposite sides of a partition. Allowing at least one node to update state will cause the nodes to become inconsistent, thus forfeiting C. Likewise, if the choice is to preserve consistency, one side of the partition must act as if it is unavailable, thus forfeiting A. Only when nodes communicate is it possible to preserve both consistency and availability, thereby forfeiting P. The general belief is that for wide-area systems, designers cannot forfeit P and therefore have a difficult choice between C and A. In some sense, the NoSQL movement is about creating choices that focus on availability first and consistency second; databases that adhere to ACID properties (atomicity, consistency, isolation, and durability) do the opposite.

This puts some of the current trends into perspective.

First computer – Tesla PMD 85-1

Once in a while people ask me what was the first computer I could get my hands on.  Mistakenly, I’ve often answered that it was Commodore 64.  But today I did some digging and realized that it wasn’t true.  I did use Commodore 64 too, but that was mostly for playing games – my uncle was a head of a nearby Fire Station and he had one of these in the office, but that wasn’t the first computer I used, and it wasn’t the one I learned to program on.  That honor goes to Tesla PMD 85-1.  Here is a picture to give you an idea (thanks to root.cz):

pmd85

We had a computer lab in school, with 11 of these things.  10 were used by the students and 1 was for the master station for the teacher.  Some of the highlights that I still remember: black and green monitor, cassette tape drive for loading and saving programs (sorry, no hard drives or floppies, or network really, except for printing on a slow and very load dot-matrix printer), a very uncomfortable yet colorful  keyboard.  The keyboard is worth a separate mention.  As seen above, it had blue, red, and grey keys.  It didn’t have an Enter or Escape keys.  But it had two EOL (end of line) keys right next to each other – I don’t remember why though.  And STOP and RST (reset) buttons.  And it was almost QWERTY.  Here is a close-up image from Wikipedia:

PMD_85-1

For some reason, I remember the keyboard slightly different.  Those blue K-keys were to the left of the main area, organized into two vertical columns.  But I was unable to find an image of such model, so it must be my memory failing.

When I was back in 5th grade (that must have been … hmm … somewhere around the year 1990), a new Informatics (that’s how Computer Science was called back then) teacher at school opened up an after hours Computer Club, which allowed all students, and not just the high graders access to the machines.  I don’t remember the name of the guy, or how I got involved with it, but I do remember that I got hooked on it pretty much immediately.

A few times a week, we’d stay for an hour or two after classes and learn Basic programming language.  He’d explain to us some basic concepts such loops, conditions, and variables, and then would let us work on our code.  For the rest of the days, I remember, I was walking around with the paper notepad, in which I’d write source code by hand, debug it, test it, and improve it, so that I could spend less time doing so in the lab.  Machine time was limited (an hour or two per session, with some of it taken for loading the program from tape, typing in changes, and saving back to tape), so you’d optimize for using it to actually run the program, verify the result, and, maybe, try one or two more ideas.

If I remember correctly, I worked on these machines for two or three years.  Then, my other uncle, who was the first real IT guy I knew, got me an IBM XT machine.  It wasn’t an original IBM, but a mix of Soviet countries manufacturers.  But that was great!  That was the closest thing to the modern PC – CGA graphics with 4 colors, 640 KB of RAM, 10 MB hard disk, and a floppy drive!  I thought nothing better was possible until I saw a VGA monitor with 16 colors.  I think then I realized that I’ll never catch up to the technology developing so fast.

And one last bit of memory.  Even though I wrote quite a bit of Basic code while learning English in a specialized school, it wasn’t until I came to Cyprus and started learning Pascal programming language in Intercollege, that I realized that all those words I’m typing into the computer to make it do things are ACTUAL ENGLISH WORDS!  Now that was both embarrassing and empowering at the same time…

Oh, good old days.

P.S.: Yes, I’ve played on Atari too at my friends’, but I never owned one of those.