--Originally published at Computer Systems Engineering

The article, Lisp: good news, bad news, how to win big was written by Richard Gabriel and originally published in 1991.

Troughout the lecture I could grasp that at the time this was written, Lisp was very popular and used but then it got really bad reputation for many reasons like problems withing the language and also how people talked about it damaged its image a lot.

There were a lot of things done right with Lisp that may have inspired a lot of other languages to do the same like standarization, it had good performance, good integration to coexits with the different programing languages that existed, and of course you could do object oriented programming.

Then there were all those things that Lisp failed at, the most remarkable are:

• Simplicity — the design must be simple, both in implementation and interface. It is more important for the interface to be simple than the implementation.
• Correctness — the design must be correct in all observable aspects. Incorrectness is simply not allowed.
• Consistency — the design must not be inconsistent. A design is allowed to be slightly less simple and less complete to avoid inconsistency. Consistency is as important as correctness.
• Completeness — the design must cover as many important situations as is practical. All reasonably expected cases must be covered. Simplicity is not allowed to overly reduce completeness.

It had a different philosophy for this things that at the end of the day didn’t sit well with most. Other things it failed at were that, even thought it might have seem easy to build things with it, it was not that simple to make good programs, there were a lot ofmistakes people could make about the declarations, implementations and bad data structures.

This is a good article to reflect about

Continue reading "Lisp" →

--Originally published at Computer Systems Engineering

We have invested all those time into making those diagrams but now how do we transform them into code?

Imagine we have our uml diagram that we want to make into java code:

We need to create those classes that we stated that we had, in this case we have 4 of them: Passenger, Train, TrainRide and Login. Each have their attibutes that we need to add to the class, plus the methods that we thought each of them should have. THen we alsoneed to consider the type of relationship each class have with one another, it could be a relation of composition or aggregation or some other type of relationship, all that we should correctly translate into the code, making a class an interface, the parent/son of another or just make it a normal class.

This is why we should thrive for better diagrams, if we make the perfect diagram then when we translate it, it will inevitably be good code because it has been well thought through, all the attributes are the right data type, they are all the necesary ones, the methods belong to the class that will hold them and also all the relationships in between the clases are the necesary ones to have comunication inside our program in the most logical and eficient way without compromising the independency of each component (that each class modifies its own attibutes and calls it’s own methods and not the other ones).

References:

http://lazysupply.co/uml-class-diagram-arraylist.html

--Originally published at Computer Systems Engineering

Finally, we are at the last chapter of the book.

This is what we’ve been waiting for, the moment we put all those pices together to make it all part of a single thing. For this we have had followed this developing process:

1. Make sure that your software does what the client wants: here we  do the feature list, use cases diagrams, break up the project and list the requirements.
2. Apply OOP principles to add flexibility: includes domain analysis, preliminary design, and everything to delimit the problem
3. Strive for mantainable and reusable design: this is when we implement the solution and we have to make sure we have an order and clear documentation for when we want to add features, update or whatever we need.

When we were thinking about the project i have to admit that sometimes we were to caught up in what we wanted the program to be that we didn’t stop and think what a customer might want/expect from something like that, so we needed to step back and consider the design process, do it in order to have in mind the customer before the program (i think that’s why we had trouble with the use cases in the delivery of the first partial).

The thing that i learned is that we need to follow like a timeline process and, if it is needed, iterate though it to refine everything and define new things that we might have not considered before. So in conclusion it’s everything about ORDER.

--Originally published at Computer Systems Engineering

Let’s talk about chapter 9 of the book.

Just the title of the chapter speaks so much: how many thimes they ask us for something and in the process we think about some modifications that we think will make it better and forgot what we were asked to do in the first place. I have had this kingo of thought when i had to help build a web page for some people, they gave us the designs and we were just supposed to make it look like that but honestly their designs were find of ugly to me so i had to keep reminding to myself that that’s what they asked me to do and that I should just stick to it.

They talk about how we must think about the user while we build our program, to think all the use cases we can with no limits, to be creative and expect everything to avoid a situation in which out program doesn’t work because we didn’t thought about something that the customer might do. For every scenario that we think of we must make our program work for it, guiding the user to what the right path is in case they make an unexpected action, and that the expected uses work perfectly.

Also, what called my attention is how they say that yeah, all that OO principles and practices that you use to build your program are very helpfull to you and makes things clearer and all but at the end of the day the customer doesn’t care at all about that, they just want you to deliver something that works and solves their problem. That’s why we must think about the client ALL through the process.

Anyways, that is all, enjoy a good song for the morning: