The first time I heard about the Lua programming language was back in 2003. My coworkers were working (quite hard) at porting FarCry to PlayStation 2. The game code and engine rely heavily on the Lua language.I am a sort of split about using script language to define game and character behaviors in a game. The good part is that an interpreted language offers several benefits like no need to recompile the whole engine (or a dll) for even a small change, gentler learning curve so that even non-programmers could write a piece of the higher level code of the game. Even if they cannot write it, at least they could get a clue of what the code is doing. Moreover if the language is tailored for the domain (Domain Specific Language) then coding with that language could be easier than using a general purpose one.
On the other hand I had usually bad experiences – the language interpreter itself it is usually not enough to develop code, a debugger is needed as well and creating a good debugger is not an easy task. Moreover integrating the script language with the engine could be either boring or error prone (usually both). The domain specific language tends to evolve into a general purpose one as soon as its users discovers that they need exactly the effect of that instruction only slightly different.
As soon as the barrier from Domain Specific to General Purpose is crossed, the nice and cute language turns into a wild beast ready to bite your back at the first oversight.
The lack of constraints, typical of scripting language, enables a quick prototyping or a quick development of small programs, but leave you alone when facing with mid-sized application. Coherence and consistency should be achieved by using rules, conventions and strict discipline.
So… how does lua stacks in those respects?
After reading about half the book Lua I should say that stacks pretty bad. According to the book, Lua is intended for solving problems with a few hundreds lines of code. And many of the language design choices are biased toward this direction. The first that comes to mind is that variables have a global scope by default. Actually this is a bad design decision since the global namespace tends to be polluted rather quickly and generally global variables are considered a bad programming practice.
One of the most confusing part is that list and multiple values are quite freely mixed with varying semantic. A function may return a multiple value, so that you can write something like:
a, b = f(x)
If f(x) returns two values then they are respectively assigned to ‘a’ and ‘b’. If f(x) returns one value then ‘a’ gets it, while ‘b’ is assigned with ‘nil’. If f(x) returns three or more values then ‘a’ and ‘b’ get the first pair other are silently discarded.
But it doesn’t hold true everytime. In fact if you write:
a, b = f(x), 1
then ‘1’ is assigned to ‘b’ and only the first returned value from f(x) is assigned to ‘a’. In other words the extra return values from f(x) are discarded. If f(x) doesn’t return any value then ‘a’ gets the ‘nil’ value. Frightening, isn’t it?
What if the result of a function is passed as argument to another function, as in ‘f(g())’ ?
Somewhat of a nightmare. If the function is the only argument then all the result values are passed as arguments to the outer function, if other arguments are given then just the first return value is taken.
Consider that a function can be invoked with more or less than the specified number of arguments without error and you get the whole creepy plot.
This approach could do for a very few hundred lines of code, crossing this boundary requires the application of strict rules and conventions in order to keep things working without falling into chaos.
The book I’m reading seems quite oriented to a prototype level of application, in fact shows with good detail how to load and save data as source code. This is fine with your home app, but it is what you don’t want to do in a real application if you even slightly care about security.
I found rather elegant the use of associative container (the table) as a mean both for structuring data and for implementing the concept of class (I haven’t yet touch the point that deals with inheritance). Although the (ab)use of syntactic sugar in the language is likely to lead to syntactic diabetes.
According to what I read around it took about 10 years to fully master a programming language. I could agree, even if I think that within a year and a good amount of code you should be proficient. So my considerations are based on the first impression and my understanding of the language is far even from a beginner. Nonetheless I daresay that Lua has some problems in scaling up.
It took a good deal of time, but at last, it made it and it’s not Java. Also it proves that Microsoft was right. Back in the 90s Microsoft was darn right to fear Netscape and the web browsers for they would have stolen users away from Windows.Maybe it is thanks to Microsoft efforts to take Netscape off the scene (or even thanks to Netscape mistakes in riding the browser wave) that it took so long, but eventually we are about to no longer be bound to a specific OS or even a specific computer, everything is going on-line, accessible from every Internet node around the world. gmail, writely and irows are the forerunners of the next frontier, the on-line application that looks exactly like your desktop application. But as long as new toolkits and frameworks are developed more are to come. Until now I had a look at a couple of framework that looked very promising yet quite clumsy in performance. But have a look at Bindows. It is pretty fast, slick and responsive, it also looks and behaves exactly like a desktop application.
Ironically, although Microsoft fought Netscape and Java, it was Microsoft itself that developed the base components for Ajax technology. Funny, isn’t it?
If I had to pick an adjective for this book I would be in doubt between irritating and disappointing. Book publishing is a sort of time machine – first the last book of an author is published, then, if the book is successful, every writing of the author, going back to the youth works, is published. This is a nearly zero risk strategy for the publisher (since it fully harvest top money in a short time), while it is highly risky both for the reader (that can quickly became dissatisfied and lose the trust in the writer) and for the writer himself (that is going to lose his readers and therefore his income).
So what’s wrong with “Digital Fortress” (apart from being retitled into “Crypto” for the Italian translation)?
Most of the book. Let’s start from the beginning, the NSA is one of the American secret services. In this book, Dan imagines that NSA has developed a supercomputer that exploits the massive parallelism of one gazillion of CPUs in order to decrypt any message by brute force.
Then the writer proves his deep ignorance of every the most basic aspect of cryptography. He messes up bits with characters. Then he shows that he hadn’t spent a couple of seconds for looking up what the Caesar cipher is and presents a wrong description. Also he hadn’t a clue about computation complexity and that just adding a bit to a keyword the time needed for a brute force attack doubles.
He hadn’t the palest idea of how computer security works, what network security is.
If you succeed to get through all this jungle of ignorance then the story is that a hacker sends a code that cannot be decrypted by brute force (!!) to NSA to black mail them in order to reveal the existence of the supercomputer to the world (!!).
The hacker dies in the beginning and a civilian (the boyfriend of a cryptologist employed by NSA) is sent to investigate (!!).
Anyway the code is eating up the supercomputer resources because the NSA CTO is willing to break it (!!).
Aside from this technological nonsense, there are the usual Brown strengths and weakness. More of the last since this is an old writing by him (1998!) and for sure his technique has improved with time.
The book is not hooking as the others, has an intriguing rhythm, but it is not a page turner.
About the weakness, as usual characters are not developed, they are flat, doing their brain-work and acting like SWAT agents. Also, as already found, the reader is tricked away from the solution of many puzzles pretending that skilled professionals don’t see the obvious solution.
The plot is always the same. Four books, the same plot, the same main character betrayed by what he/she thought was a friend. So the usual upturn near the end, when the hidden plot is revealed.
Don’t buy it, unless you are doing some research work on this author, don’t read it either.
Software project management… I read a number of books about this since, as I said in one of the previous post, it is an intriguing matter. One of the most frustrating aspects is how far are the best practices preached in those books from the industrial realities that I have experienced or that my friends and ex-coworkers tell me about.
I am quite confident that the techniques and approaches proposed in my readings are correct and proper, but everything has been written by Americans, based on researches in the US companies and deeply rooted in the US working culture.
Sometimes this is not applicable here in Italy. E.g. if in your team you have a person with a negative attitude toward the work and the team, at least one book suggests to fire him/her. This works in US where employees have not the right to be fired only for Good Reasons, not just because the employer changed his/her mind.
But this is mostly about details. There are stronger issues.
One could argue that part of the approach to working and to solve problems is part of the culture. I mean, every (US) study reports that programmers are by far more productive when they have their own private office. Peopleware suggests team-oriented (quiet) offices with no more than 4-5 people. In Mediterranean culture, people is considered much more socially oriented, so it could be possible that an Italian programmer would be more productive in an open space environment.
In the same way it could be possible that those, who would considered bad managers by the current literature standards, would be instead the best managers for Italians.
There is just one possible answer: try different approaches and measure the outcoming.
Given the current state of the Italian software development industry (which industry?) I am really doubtful that this could happen. Our industry is composed by ridiculously small companies that could face bankruptcy at every project gone wild. In this situation daring to risk a new approach that is known to work elsewhere, but could possibly not work here.
From my experience I could tell that I am much more comfortable (and productive) when the office is empty, rather than when it is crowded; also I am quite annoyed by interruption, not always, but I’d like to have a flag “do not interrupt” to have consistent time to concentrate. But… ehy I don’t like soccer, could I be considered Italian? 🙂
Apart from jokes, what do you think?
According to the Dilbert’s rule everyone gets promoted to his/her highest level of incompetence. In the computer programming field this is dramatically true: brilliant programmers, after few years or less are turned into management. First they are promoted to lead programmer roles and, if they have the double DNA, they could grow in the management career. Why is required a double DNA? Because programming has to do with machines, while management has to do with people. And people tend to get upset when treated like machines.
Moreover programming is about reaching a goal worrying about the smallest detail, while management is about setting goals for other people letting them sort out the minutiae.
When I became a lead programmer I hadn’t a clue about this and no one cared about telling. I just was asked about when my team would complete the application.
The project was rather successful, but it could have been far better. That’s why, with the next job I started reading books about management.
This book is the first I read about the next level: it is about managing lead programmers. The book is simple, easy reading and well structured. It is not as brief as “One minute manager”, but is very concise; you can read it in a couple of days. More than once I wished that my boss had read it.
The authors use a fictional character to make their points and providing a running example. This character is a just hired manager to which six lead programmers are reporting and who has the goal of reducing costs and increasing the value of his departments work.
Authors propose a number of techniques for managing proficiently. As implied in many parts the job of the manager is to facilitate the work of people reporting to him/her, removing obstacles and providing support.
One-to-one is a meeting held weekly during which the manager meets just one lead face to face. The meeting lasts about one hour and the manager gathers information, provides supports, sets skill development goals and coaches the lead.
Team meetings are held weekly too and the goal is to provide integration between teams, exploit synergies, and prevent inefficiencies.
Coaching is to help leads to develop skills that are beneficial both to the company and to the lead herself.
The manager is encouraged in:
Assess attitudes and interests of the lead teamers. It doesn’t make sense to force someone to do something that she’s not interested in;
Managing by walking around, that is taking some time just to wander around in the teams to taste the mood of teams and the rhythm of work;
Enabling the lead team jelling;
Give feedback immediately. Do not wait to the next event (end of week, yearly review or the like), people need to know if they’re doing right or wrong immediately.
Acknowledge good work
The book also instructs the reader on influencing and resolving contrast. Influencing is for the best of the influenced one, it can’t work in the long term otherwise. Resolving contrast is much sticking with facts and trying to put in the other one shoes.
The planning is dealt with a weekly resolution for a couple of month. It is defined by leads and their teams and can be arranged in terms of priorities or delegation by the lead meetings. Beyond two month the planning is very rough. Also the planning is suggested to be kept is a meeting room in the form of a panel with sticky notes so that it is clear for everyone that it isn’t carved in stone.
Problem solving techniques to employ in meetings are proposed. Many of them relies on the brain storming techniques with some modification to ensure that everyone (even shy people) could participate.
The book contains a great deal of tips and aids to do management things. Usually there is an example, the motivation, a ‘to-do’ list for the technique and then there is a recap frame at the end of the book.
I highly recommend this book to all those managing lead programmers or the likes. I still recommend this book to lead programmers since many of the presented techniques are still applicable in the smaller context and can be helpful to back-coach the manger in a more sound behavior.
As most engineers I know I have a rather childish part of me that refuses to grow up with the rest of the body and the mind. I still like to play, I like cartoons, I am fascinated by toys and so on. For the same reason I usually lurk in the teen section of bookstores because I’m sure to find some hidden pearls. Sometimes I get burnt (Time Stops for No Mouse was way too childish even for me), other times my research is successful.
Artemis Fowl is one of those successful cases. Although it is not at the same level of Harry Potter (here Good and Evil aree pretty distinct and the Evil one has no good intentions) it is an entertaining reading.
This is the fourth book in the series. The plot is following from the previous book: Artemis and Butler (Leale in Italian) have undergone a mind-wipe and they don’t recall anything about the people and LEPrecon. Opal is in coma, and Holly Short (Spinella Tappo) is about t be promoted.
In this book you’ll find the usual wealth of futuristic gadgetry, Artemis will be back in full… mind and will begin to grow some sentiments.
Opal plan is astute and well thought.
I found Folay (Polledro) character to be a little underutilized and he’s doing the idiot-savant a bright guy that cannot think about the obvious.
I am not fully satisfied by the dwarf Mulch Diggums (Bombarda Sterro). It seems like that when the writer finds no way out for a given situation he forges a new secret dwarfs ability. A cheap Deus Ex Machina gimmick to solve problems. I have not checked, but it is possible that this brings some inconsistencies to the previous books.
An easy book that flows in a couple of days full of techies and action.
What happens when Terry Pratchett and the tale of the magic flute meet? The answer is this book. Of course this is not a story, so the magic boy, his cat and mice are a well organized mob that sets up mice infestations just to collect money to free towns from rodents. But Überwald is a county where chilling things are bound to happen. So the new town looks pretty strange even to this oddly assorted gang.
The usual Pratchett humor and wit are in this book as well. Although this is not one of my favorite Pratchett’s book, this is nonetheless a pleasant reading and some thoughts of the writer about intelligence, conscience and consciousness are really good food for thoughts.
Robots. Much time has past since the definition of “robot” although the idea of an artificial being created by men dates a long back. The current idea of robot includes electronics and software supplanting what was considered back in the fifties and in the sixties (of the past century) when a robot was built from gears, springs and occasional electricity wires. The brain was made by something yet to be invented then, so every author imagination could go wild on this. In this book brains are either made by mercury or by antimatter…. well to be honest still today we don’t know what exactly is supposed to fill the cloud depicted on robot schematics labeled with “brain”. We know how to build simple mechanism… basically computers on wheel, but we are quite far from devising a fully featured robot as presented in sci-fi literature. This is the fourth book by Stanislaw Lem that I read. I found the first two (Eden and Fiasco – “Il pianeta del silenzio” in Italian) to be really great. They are mainly focused on how much alien can be alien. Beings living in remote and insulated region of space could well spoil behaviors that we could hardly identify as rational or intelligent.
The third book was “Solaris” although focused on the same subject the narrative pace is extremely slow. The story is much oriented to introspection and character psychology.
My expectations for Robot Tales were quite high, so I was rather disappointed to find a collection of children stories. Robots are just and excuse for telling space stories. Some of the stories are pretty well written and touchy, some are just variation of the king-promising-his-daughter-to-the-one-who-will-do-something.
One of the main features of the book is being precise about astronomy science. Stars, nuclear reactions, radioactivity and so on are woven in the stories with a good degree of accuracy. This is intriguing (at least for the engineers within me), but is untuned with the robot description that is far from scientific accuracy.
It is hard to find a reader profile for this book. Children can be easily bored by scientific description, while teenagers are surely dissatisfied by the plots.
Note that the book is published in Italy with the title “Fiabe per Robot” (Tales for Robots) while in english has been translated into two volumes – “Mortal Engine” and “The Cosmic Carnival of Stanislaw Lem“