About Computational Patterns

Definitely I understand most of structural patterns, but when it comes to computational patters it becomes fuzzy. Maybe because I don’t like much that field (although I recognize its value and importance) or maybe because I have no solid base on that field.

If I must deal with Linear Algebra when solving a problem (linear operations on vectors or matrices), I will totally use a linear algebra library rather than trying to write functions and algorithms myself. That because is pointless to reinvent the wheel when I can save a lot of time using the standard mathematical operations and routines already packed in libraries where people have put a lot effort on.

Computation can help a lot when solving a problem. Graphs are a very good approach if the problem fits with a certain algorithm or known data structure. Experiments as in the Monte Carlo pattern is a technique that might be implemented more easily today using parallelism, since it requires the generation of thousands of experiments, it execution and to aggregate the results into relevant statistical solutions.

Computational patterns and structural patterns are clearly different to me. In structural patterns you are dealing with entities and its relationships and how to come up with good and efficient designs, while in computation patterns you are pushed to come up with mathematical models.

Publicado en CS 527,English,Software Engineering | Sin comentarios

Armstrong Thesis Ch. 4: Programming Techniques

I agree with Armstrong that it is impossible to write concurrent code in a side effect free manner. You can be sure that the code you are writing is free of dead-locks, starvation and similar problems. Even your QA team can say so after testing the program 9 times. But in the 10th run, a problem you didn’t expect might arise.

Thinking of the above paragraph, to abstract concurrency sounds like a very good idea. Factoring out concurrency code make it easy to create and maintain a solid base. The Armstrong idea is to have a generic component which deals with all the concurrency code and different plug-ins written in pure sequential code. That way, expert programmers can code concurrency, and beginners can code the sequential parts.

Software fault-tolerance is possible to achieve using basic techniques like crash catching and timeouts. The thesis also talks about a more advanced techniques using dedicated processes called supervisors, which only task is to handle error. That create two categories of processes: workers and supervisors. That way, workers have not to worry about handling errors.

I think that both, error handling and concurrency abstraction, is possible to achieve using other programming languages (not Erlang) as well. Java could be a good example. I have no experience with those patterns thou, but seems doable.

The Erlang view of the world, everything is a process and that processes can only interact by exchanging messages, helps a lot when creating an HTTP server; spawn a new process for each connection, accept a request from the client and respond appropriately. Lighttpd is a good example: high speed io-infrastructure, scalability and effective management of CPU load by using concurrency.

At the end of the chapter Armstrong talks about Intentional Programming, a style of programming where the reader of a program can easily see what the programmer intended by their code. This style is very useful when maintainability is about.

Publicado en CS 527,English,Software Engineering | 2 Comentarios

Sitios de interés