Let's keep going. At this point I've talked a lot about different programming languages. But, the more important question that needs to be answered is, what programming languages should you learn? More than that which programming languages are easiest to learn?
My answer to those questions is...that depends. Yea, I know that's a cop out but it really does. The context in which you want to program is really important and I'll cover some of the biggest contexts and what languages would be most helpful for each one in this post.
Thursday, September 19, 2013
Tuesday, September 17, 2013
Coding 101: Object Oriented Programming
Next topic, let's talk about 'Object Oriented Programming', often abbreviated OOP. OOP is a topic that often comes up when talking about programming languages. So what is it exactly?
OOP is the concept of treating the world as a collection of objects. If you want an apple in your program, create an apple object, if you want a dog in your program, create a dog program. Internally, these objects have properties which describe them, for apples you might have a property for color and another for shelf life. For a dog, you might have properties like breed or age.
So far so simple right? Every 'thing' that you want to exist in your program should be defined as some kind of object, easy. Generally, when talking about OOP, these objects are represented as classes.
So, what does OOP accomplish for programmers? OOP often times is described as allowing for a particular set of things. Depending on who you talk to, you get different answers, as I was taught OOP allows for 3 things, encapsulation, inheritance, and polymorphism each of which I will talk in detail if you wish to continue.
OOP is the concept of treating the world as a collection of objects. If you want an apple in your program, create an apple object, if you want a dog in your program, create a dog program. Internally, these objects have properties which describe them, for apples you might have a property for color and another for shelf life. For a dog, you might have properties like breed or age.
So far so simple right? Every 'thing' that you want to exist in your program should be defined as some kind of object, easy. Generally, when talking about OOP, these objects are represented as classes.
So, what does OOP accomplish for programmers? OOP often times is described as allowing for a particular set of things. Depending on who you talk to, you get different answers, as I was taught OOP allows for 3 things, encapsulation, inheritance, and polymorphism each of which I will talk in detail if you wish to continue.
Friday, September 13, 2013
Coding 101: Typing
Next lecture in my Coding 101 series. Looks like September is another one of those coding based months. Anyways, this post is about typing.
What do I mean by typing? Surely I don't mean the act of typing on a keyboard. While an interesting topic, see Dvorak, this post is not about that. This post is however about programming languages, more precisely the type safety of a language.
In particular this post is about the difference and examples of statically typed and dynamically typed languages.
What do I mean by typing? Surely I don't mean the act of typing on a keyboard. While an interesting topic, see Dvorak, this post is not about that. This post is however about programming languages, more precisely the type safety of a language.
In particular this post is about the difference and examples of statically typed and dynamically typed languages.
Saturday, September 7, 2013
Coding 101: Types of Languages (Imperative and Declarative)
Let's push forward with Coding 101. The topic for this segment is the different types of programming languages. I mean for this to be a high level post and maybe in the future I'll go into more depth about them. Anyways, let's get started.
First off are the languages that most people first get introduced to in computer science courses. These languages are the 'imperative languages'. Examples of this kind of language are languages like C, Java, Python, or Ruby. The reason why these are called imperative languages are because each line of code you write is an instruction. It's a command. You can think of languages like these as recipes. You tell the computer a set of instructions that have to be done in a specific order. Logically, these kinds of languages are relatively simple to grasp once you understand the syntax that goes with the language, much like learning French or Mandarin. Since things (almost always) happen exactly in the order that you write them, it's usually pretty simple to figure out when something goes wrong because there is an order that things happen in. There are some wonky edge cases but as a whole this is true.
On the other side of the language fence are declarative programming languages. Examples of this kind of language are Lisp, Haskell, Scheme, or parts of SQL (select queries in specific). These languages differ in that the idea behind them is to declare what to do with your data. For example, imagine you have a bushel of apples, some of them are red and the others are green. Now, imagine you want to know how many red apples there are. In an imperative language, you would have to take each apple out, examine if it's red or green and take a count. In a functional programming language you would apply a function of whether something is red or green to the bushel and get the subset of red apples from which you can take the count. Or you might just ask to get all the red apples from the bushel. Internally, it's quite possible that the two approaches look the exact same, but from our perspective as coders they look quite different.
First off are the languages that most people first get introduced to in computer science courses. These languages are the 'imperative languages'. Examples of this kind of language are languages like C, Java, Python, or Ruby. The reason why these are called imperative languages are because each line of code you write is an instruction. It's a command. You can think of languages like these as recipes. You tell the computer a set of instructions that have to be done in a specific order. Logically, these kinds of languages are relatively simple to grasp once you understand the syntax that goes with the language, much like learning French or Mandarin. Since things (almost always) happen exactly in the order that you write them, it's usually pretty simple to figure out when something goes wrong because there is an order that things happen in. There are some wonky edge cases but as a whole this is true.
On the other side of the language fence are declarative programming languages. Examples of this kind of language are Lisp, Haskell, Scheme, or parts of SQL (select queries in specific). These languages differ in that the idea behind them is to declare what to do with your data. For example, imagine you have a bushel of apples, some of them are red and the others are green. Now, imagine you want to know how many red apples there are. In an imperative language, you would have to take each apple out, examine if it's red or green and take a count. In a functional programming language you would apply a function of whether something is red or green to the bushel and get the subset of red apples from which you can take the count. Or you might just ask to get all the red apples from the bushel. Internally, it's quite possible that the two approaches look the exact same, but from our perspective as coders they look quite different.
Thursday, September 5, 2013
Coding 101: What's the big deal?
New segment on an old topic. Let's get down to it. Recently (not so recently), I've come to realize that coding is quite intimidating. There are tons of resources out there and a bunch of them honestly suck. Even the good ones don't do a great job at explaining just how diverse and multi-dimensional the world of coding is.
Now I'm sure I've noted that computer programming or coding is important and that you should get started. But really, it is quite intimidating. For one, there are a ton of programming languages, from C to Python to Perl to PHP to Haskell. While they all kind of look the same they all have their own nuances and their own strengths and weaknesses. As a beginning coder, it's hard to wrap your head around what a pointer is or why dynamically typed languages are 'slow' or what 'slow' even means.
The point of this segment, Coding 101, is to go over things at a high level. Things like, why program or what are the different kinds of programming languages. Why pick one programming language over another, what tools are available for you as a coder to use. I'll try to keep things simple, but as with any technical subject there is a lot of jargon to absorb.
Hopefully someone will find this useful and I hope to cement what I've learned and observed for myself. So let's begin with why program?
Now I'm sure I've noted that computer programming or coding is important and that you should get started. But really, it is quite intimidating. For one, there are a ton of programming languages, from C to Python to Perl to PHP to Haskell. While they all kind of look the same they all have their own nuances and their own strengths and weaknesses. As a beginning coder, it's hard to wrap your head around what a pointer is or why dynamically typed languages are 'slow' or what 'slow' even means.
The point of this segment, Coding 101, is to go over things at a high level. Things like, why program or what are the different kinds of programming languages. Why pick one programming language over another, what tools are available for you as a coder to use. I'll try to keep things simple, but as with any technical subject there is a lot of jargon to absorb.
Hopefully someone will find this useful and I hope to cement what I've learned and observed for myself. So let's begin with why program?
Tuesday, September 3, 2013
Big Data
Big data is a topic that many people spout off and one that is quite interesting to talk about. If you're unaware, the idea behind big data is that every website you hit, every search you put into Google, every Facebook post you like is stored somewhere and in turn those companies use that data to better predict what users like you want to search for or buy or might want to look at and like later. So why is this 'big' data? Well for one, there are billions of people on the internet every second of every day. For each person, there is some amount of data being created and stored somewhere on some server belonging to some company. How much data does this equate to? Well here are some ideas. Easily put, it's way more than you can sit and look at even if you had multiple lifetimes to look.
Now that we've established just how big the internet is and how much data there is, how do we deal with that? These numbers are so large that they are beyond what we normally think of outside physics, in particular physics of an astronomical scale. Let's put these numbers in perspective. There are roughly 3 million emails sent per second every day. Now 3 million is a large number I think we can agree on that. But that also means that there are roughly 90 trillion (107 trillion if you're looking at the infographic in the second link) emails sent per year. Sure, a great deal of those are spam, but even the 10% that isn't amounts to over 10 trillion actual emails. If we assume, that each email is just one line long and that there are 50 single spaced lines per page, 100 as we'll even let them be double sided. Let's be so bold as to say that a novel is generally 500 pages, to make the math easier. 10 trillion emails would then be 100 billion pages long or 200 million novels worth, and that's only what we're generating per year!
Personally, I find big data intriguing. There's this idea that this is a internet related problem and so people might call this problem an 'internet scale problem' but honestly, 'Big Data' just sounds better. It's simpler and doesn't really require you to know why these things are necessarily problems. Be assured though, big data is a problem that many people are trying to figure out. As the years go by, more and more ways of handling it emerge from transitioning to NoSQL, to using MapReduce, among other things. If you didn't care for the post, I hope you at least enjoyed the infographics. Until next time.
--CsMiREK
Now that we've established just how big the internet is and how much data there is, how do we deal with that? These numbers are so large that they are beyond what we normally think of outside physics, in particular physics of an astronomical scale. Let's put these numbers in perspective. There are roughly 3 million emails sent per second every day. Now 3 million is a large number I think we can agree on that. But that also means that there are roughly 90 trillion (107 trillion if you're looking at the infographic in the second link) emails sent per year. Sure, a great deal of those are spam, but even the 10% that isn't amounts to over 10 trillion actual emails. If we assume, that each email is just one line long and that there are 50 single spaced lines per page, 100 as we'll even let them be double sided. Let's be so bold as to say that a novel is generally 500 pages, to make the math easier. 10 trillion emails would then be 100 billion pages long or 200 million novels worth, and that's only what we're generating per year!
Personally, I find big data intriguing. There's this idea that this is a internet related problem and so people might call this problem an 'internet scale problem' but honestly, 'Big Data' just sounds better. It's simpler and doesn't really require you to know why these things are necessarily problems. Be assured though, big data is a problem that many people are trying to figure out. As the years go by, more and more ways of handling it emerge from transitioning to NoSQL, to using MapReduce, among other things. If you didn't care for the post, I hope you at least enjoyed the infographics. Until next time.
--CsMiREK
Monday, September 2, 2013
So behind
So I'm sure you've noticed I'm horribly behind. Between working somewhat odd hours and procrastinating on anything and everything I have neglected this blog. Fear not! I am working to back fill all the entries I have skipped. Unfortunately, I will have to let go of August's updates as there were much too many planned and I'm still behind from May. It's been a crazy few months but I think I'm almost ready to get back into this updating thing. Expect lots of new stuff coming up as I have learned much from my job in terms of programming and have had time to work on some interesting side projects of a musical nature.
--CsMiREK
--CsMiREK
Subscribe to:
Posts (Atom)