We watched a video in class, "Triumph of the Nerds Part II". It talks about the growth of the computer industry, and how they anchored to the "Bear", which was IBM.

Fun Fact, I've done multiple visits to IBM's campus and every time I visit, it kind of seems like a shell of what it used to be. It is quite interesting to see IBM out of the server business. Selling or spinning it off to Lenovo.

We watched how Microsoft grew out of the small business they had by using "the Bear" to catapult off of their work. By Microsoft licensing BASIC to IBM, they had the control over whatever happened. For me, it is one of the most influential business decisions of the twentieth century.

As Microsoft conserved their lead over IBM by having the control over the development of the software, all IBM basically did is to consult and add management to the work of others. I'm in no position to understand the motivations behind this, but it is absolutely horrific the amount of disregard they had for having smart people, over hard workers.

IBM had good business practices for the previous century, but when the personal computer era came in, it wasn't about smart deals and good business contracts, it was about having enough people to know how to build the best computer systems. This quote by Bill Gates, proves this easily.

"If we weren't still hiring great people and pushing ahead at full speed, it would be easy to fall behind and become a mediocre company."
Bill Gates (Chaire.com, unknown)

This article makes a review of the implementation of the language "Newspeak" introduced by George Orwell in his novel: "1984", where he reviews and explains how language is powerful to express meaning, intention and ability. He starts by stating the premise of newspeak: "To limit and deter people from thinking outside what we want them to".

Newspeak is a language that seeks to remove non-needed words, by limiting the availability of descriptive adverbs, nevertheless establishing a basic context of the words. For example: something very good would be "doubleplusgood" (using modifiers to a word, instead of adding more words before the word). If you wanted to express that something is very bad, you would say: it is "doubleplusbad" which is pretty good. It is interesting to note that this systems works similar to some of the Asian cultures, where the context of a word can be changed by intonation, or the prefix attached to a word.

The author delves deeper into an analysis of the methods of control employed by Orwell in his book to control the mind. By it being optional, but easier to use, it is used to limit the thoughts of the people in the Party's control.

We can draw an extended comparison between using more difficult languages and standard languages. (Let's assume for a second that difficult languages are functional programming languages, not just because they are difficult by themselves, but because we are less familiarized with them.) Difficult languages let us express our full arrange of human concepts in the language, just as normal language (for example fractions or infinity). Nevertheless they are more difficult to use, so by having available this easier languages, we make the choice to go for the easier ones, whether we like it or not, as Jem Berkes mentions in his essay.

Berkes, Jem. 2000. Consulted November 9th 2017. Written February 27, 2000; Modified May 9, 2000. http://www.berkes.ca/archive/berkes_1984_language.html

I couldn't decide what to write about the Promises of Functional Programming, that is, until I found the blog entries by my partners. In first instance, and I quote, I found Estaban's synthesis fell short.

Something interesting about functional languages is how they manage concurrency and how they maintain the data in a coherent state; the key here is that pure functional code has no variables, which leads to no data coherence issues or need for locking. If there are no variables to lock, then there are no way functions access these non-existent variables and change the way they behave. 

Really man? This is your 8th entry on your clojure blog, and you are still using innmutability as a good resource to judge Clojure? Specially when one of the best topics to get out of the article is the subtle way where he jabs functional programming on the back?

Of course, the answer is no: the pure functional programs I’ve described to this point will just heat up your computer. You need side effects if you want your programto have any interaction with the realworld. But you can and should limit side effects to very few places.

The principal funcionality  of functional programming is that you compute by composing functions. A function in a mathematical is something that always return the same output to the same input without any change.  To solve these we cant use variable in our functions instead we use loops that evaluate a function with different parameters over each turn or lap.

Other of the pure programs’ benefits is the capability to receive a function as an input or produce a function as an output. As weird as it sounds, it is an amazing capability that helps to execute programs inside other programs without the need of stores values (yet again) and produce a faction that produces the expected value over and over 

On this review, we are going to examine Rick Hickey's comments and remarks on the Software engineering Podcast 

"This episode is a conversation with Rich Hickey about his programming language Clojure. Clojure is a Lisp dialect that runs on top of the JVM that comes with – among other things – persistent data structures and transactional memory, both very useful for writing concurrent applications."

The episode features Rick explaining the rationale behind clojure, which proves to be incredible well spoken. The first point he makes is that he wanted to create a language that was portable, so having it on the JVM really provides the flexibility that we've seen on new languages like JRuby. The JVM, has been proven to be incredibly fast. 

He also mentions that clojure has a strong mathematical root, as combining sets, vectors and maps. They resemble more their mathematical equivalent, which is good for solving complex mathematical equations.. For me personally I think computer scientist are going to find the clojure syntax more compatible with complex set theory equations more appellable than other languages. Specially because of the different implications of vectors and maps being bijective.

As mentioned in our previous blog with Dick, Clojure lets immutability be part of our stack, which is a massive advantage over other stacks. as behavior is clearly defined.

Clojure also allows you to have a consistent API with the JVM and Java. Which creates a rich set of applications that can interact with one another that allow different paths of combination. We could think about a website designed in clojure interacting with JRuby and Apache Camel, which by itself, proposes to be quite interesting.

We've seen that Paul Graham is a massive fanboy of Lisp. He mentions that:

"As one data point on the curve, at any rate, if you were to compete with ITA and chose to write your software in C, they would be able to develop software twenty times faster than you. If you spent a year on a new feature, they'd be able to duplicate it in less than three weeks. Whereas if they spent just three months developing something new, it would be five years before you had it too."

(defun foo (n) (lambda (i) (incf n i)))

[](int n, int i){return n + i}

public interface Inttoint { public int call(int i); } public static Inttoint foo(final int n) { return new Inttoint() { int s = n; public int call(int i) { s = s + i; return s; }}; }

Today we are going to discuss the main topic of Dick Gabriel's podcast on Software Engineering Radio.

In this podcast he discusses the creation on Lisp in Stanford.

The topic I want to talk about is: Why functional programming is making a comeback into the software engineering field, and why it didn't do it before.

Having automatic garbage collection and a meta programming via lists on top of a compiler creates a big problem that only processing power solves: Overhead.

When Dick Gabriel invented Lisp, it was considered real slow to implement a program in Lisp. The amount of overhead per instruction is monumental to programs for architectures that handle RAM below 128 MB. Once we had the massive capacity of today's computing power, we can implement Garbage collection in whim, like in Erlang without over-extending our capacity of software.

It is also quite interesting to me that Lisp died down. For me one of the most important things that came out of Lisp is that everyone hates the parenthesis way of coding, Plenty of people have mentioned that they prefer Erlang to Lisp. A Parenthesis based structure also causes overhead to the programmer as he has to make sure that every parenthesis they make matches to another parenthesis.

Nowadays, it seems that the only implementations Lisp has is in very specialized web-apps that require meta-programming to be coded. It is quite interesting that you can code lisp in lisp, as Dick mentioned, but I wouldn't consider it an advantage over other programming languages.

One last thing that was very interesting is the notion that coding can be considered an Art. And the compatibility between writing literature and writing code. They both require a certain discipline to be executed correctly. With enough repetition and enough practice, you can achieve excellence in both according to Dick Gabriel.

This is the first installment in a series of articles that I'll be reviewing to add some content to my blog. The first article to review is going to be "The Semicolon Wars" by Brian Hayes.

The article was published in the acclaimed magazine "American Scientist".This article starts by creating a metaphor between the languages spoken in the world, and the programming languages in the world. One of my highlights of the article, is the following quote:

"That means that we've been inventing one language a week, on average, ever since Fortran."

I recommend this article if you really want to pique your curiosity start, like me, a deep dive in Wikipedia, searching for languages older than Google. One of my favorite searches was the "Simula 67" language. Which is really amazing to see. It looks like the weird son of Visual Basic with C

Simula 67 code for a Sigma function. [Thanks Wikipedia]

Real Procedure Sigma (k, m, n, u);
   Name k, u;
   Integer k, m, n; Real u;
Begin
   Real s;
   k:= m;
   While k <= n Do Begin s:= s + u; k:= k + 1; End;
   Sigma:= s;
End;

There are conventions as long as there are variants, the author mentions. I do think it is a fun and  insightful thought. Which is why I decided to do my opinionated echelon of the best programming languages (and also making other programmers mad in the process.)

Tabs vs Spaces
tabs, as tabs are resizable to each one's comfortable view. But I should probably switch to spaces, because Programmers that use spaces earn more

Naming Conventions
droopyCamelCase for all methods
CamelCase for all classes
_  for private members.
_  for spaces (javascript go away with your - )

IDE
Sublime text for life. IntelliJ and Webstorm for all other things

One of the interesting things that the article made me reflect about is Hendrik Einchenhardt's quote:

"shared mutable state is the root of all evil."

Programming Languages

- My expectations:

I will be able to code in Clojure, observing the new trends in programming languages, including functional programming in an efficient way.

· Your hobbies and personal interests.

I love playing video games, specifically Rocket League, but I also exercise almost daily, and I try to read at least 30 minutes a day. Lately I am very interested in psychology, so I am reading and studying a lot of this.

  Books, music, movies, TV shows, etc. Which you have recently enjoyed.

Books you've enjoyed a lot lately: Influence by Robert B. Ciadini. Rework, by Jason Fried. Think Like a Freak, by Freakonomics, and Paul Allen's Idea Man. Also, the series that I liked the most is Black Mirror.