coder . cl

ProView provides a nice I/O API. All devices are controlled through a pair of API calls for reading and writing data from signals. You cannot use channels directly, so every channel should be bound to signals for I/O. All write requests are made using io_write and read requests are made using io_read, where both methods have their context in the ProView application. All devices that should be controlled through any ProView application should use the Process flag set to User2 with value 8. The problem is how to deal with I/O calls centralized in two API calls rather than using device specific I/O calls. Your code should be consistent enough to support that I/O method.

As you know the Fixed Point Combinator, or Y-Combinator, allows to implement recursive functions without using recursive calls, and maybe you are asking yourself what kind of magic is this. The Fixed Point Combinator can be easily implemented on any language with functional features with a consistent anonymous function implementation. The concept comes from Lambda Calculus, a formal system created by the mathematician Alonzo Church, to study functions, and also it allows the representation of computations. The Fixed Point Combinator, as any combinator used to compose functions, creates a composite function that is called recursively without doing recursive calls using an anonymous function to create the recursive call instance.

As you know, I use a well defined set of questions to filter where should I work. If the company does not pass the test, I usually ignore that job offering. For example if I ask “what is your current distributed version control system?” and their answer is “SVN”, they got banned immediately — you know what I mean. The set of questions is pretty simple, and since you are usually interviewed by someone who is hiring or filtering the candidacies, you can do the same asking questions. For example, I am not interested in the company name; it can be Microsoft, but if they tell me “we are using visual source safe”, I do not handle that job offering. For me what is doing and what is using a company is important, because that will tell you how good are they doing their job.

I need to work with a hierarchical state machine. The main problem that I am currently facing is how to pass messages or trigger events on each event transition. Since I am using C Plus Plus, I will use class methods. In this case, I will use a hardware device class method. On each state transition, an event will be thrown, and the given event should trigger an action — in this case a class method — that will complete the state transition. The advantage of the hierarchical state machine is the fact that you can manage composite hardware devices without problems, because each sub-device can be handled individually with its own state, but increases the complexity of the program.

There are three very objective posts about programming at fifty, probably with controversial opinions about being a programmer at fifty. Each post with some truth behind it, but in my opinion the solution to keep working as a programmer at fifty in a safe environment is to be more selective in the type of job that you choose. In the first post, I get the idea that you will be working — if you are working on the consumer applications market — in an ocean of APIs, and the fact that you can’t ever lose the hunger to know more, and almost every task as programmer depend on the involved market. Job filtering is an option, a real option. I currently do not handle any kind of project, and I use very consistent filters.

As you know I am trying to participate on the last challenge on the blog La Sombra de Dijkstra, where you must provide a program that compares two Fortran IV programs and must determine if both programs are equivalent. I have finished the first component, the Abstract Syntax Tree of the program. This will allow me to run the program creating an interpreter, and also will allow me to analyze the program structure — the complete Abstract Syntax Tree as graph — and make some heuristics on it.

Programming requires thinking. You must place instructions correctly, with a logical order, and you must prove that your program will produce the right behaviour. Even doing tests, your programs can fail, so you can use code hardening or similar techniques to avoid errors. The inclusion of a program verification is engaging, but it is limited to prove a limited set of features, even if that verification is made formally, you will need to make remarkably different types of tests to check the program correctness. So, the main problem with programming is reaching correctness, and how do you need to be concentrated to avoid programming mistakes, like passing null pointers to some function, because a program can compile, but cannot work.