Technical & Software Blog – ssims.co.uk

Time I think for a bit of variety. I’ve recently started lectures on the subject of artificial intelligence and AI programming, and I have to say I find the whole subject thoroughly interesting if somewhat mind-melting if you think about it too much. There are applications for intelligent systems in the spheres of business and entertainment including game-playing, path-finding, robotics and expert systems.

The programming language we’ve been studying for this module is Prolog which takes some getting used to. We were given further lectures on propositional and predicate logic before we started the Prolog work and this has probably helped to understand the reasoning behind a Prolog declaration and procedure.

A brief point I’d like to make is that many introductory tutorials  will name their variables and predicates (functions if you like) with such helpful convention as X, Y, Z / A, B, C and P, Q, R. Needless to say this doesn’t help to convey much understanding about the operation of such functions. Prolog programming does indeed require a massive shift in perspective from programming in many other languages, and many built-in predicates are defined in this way so it is important to be able to see X, Y, Z for what they are in relation to the application of the predicate. However it might do well to describe your own identifiers more clearly. For example I found it much easier to write a function that finds the maximum number in a list using: CurrentMax and Max than X and Y!

The message is simple, but it might assist those who are struggling to understand more complicated aspects of the programming such as when lists and elements from those lists are utilised. e.g. [X | Y] can become [Element | List].

I remember some years ago that the graphical environment offered by windowed operating systems seemed an immensely rich and interactive experience. The Windows Icons Menus Pointer (WIMP) model opened up the world of computers to an even more diverse range of users. Even more people who probably didn’t have a real need for computing started using them just because their usage became increasingly accessible.

Interestingly this enjoyable rich experience has since become one we take for granted. We wouldn’t ever dream of going back to a command-line interface for every application (although for some things, a command-line does indeed still make sense). Similarly people focused on the glitz of the world wide web early on in its development, and this again brought more diverse people to become users of computing technology.

However since the initial appeal of these media has faded, we have focused on the functionality of these things in getting our business done. As a result we have become much more impatient with the interfaces we use and less interested in the inner workings of the software itself. Instead of seeing abstract components of an interface we tend to see things literally as what they are supposed to represent.

René Magritte's 'this is not a pipe'

This goal-oriented usage of computers has lead to a mostly two-tiered level of understanding amongst users. There are those that see the visual things they are manipulating as exactly what they represent. For them the interaction begins with their direct input put into the system and ends with the output which is generally received instantaneously. Then there are those that are aware of the underlying structures and models that are being manipulated by the software itself in order to carry out their instructions.

This variation in user perspective of computing technology is an interesting area of social differences relating to issues such as software ‘usability’. What is also interesting is the functional manner of usage users will eventually adopt with new technology. It does unfortunately breed a ‘why can’t the computer do a simple task I ask it’ mentality when a user encounters problems with an operation they are trying to perform: even if the operation is in fact actually incredibly complex in terms of the work that is carried out by the ‘computer’ and indeed any networked resources it may utilise.

At the risk of procrastinating other work and becoming a chronic poster, I’m going to go for a second one today.

Following on from my previous post discussing the merits and woes of particular IDEs, an overriding theme which runs through my dislike of the .NET framework is the fact that it is a framework. Taking the literal meaning of the word framework – I can explain my issue with the things quite easily. You see a framework in its true sense is like scaffolding – it is used to hold something up and to keep it together. The trouble is you take the framework away and you are left with something that doesn’t hang together properly. I’m not the only one with this concern about a framework development pattern, plenty of developers share it. Aside from the difficulty of integration with things external to a framework based development environment – it’s hard not to fall into the trap of developing frameworks for your own use. The convenient few classes you have used repeatedly to help you out can grow out of control into something that is horrendous to maintain.

The alternative to framework based development is to ensure as much modularity as possible, which requires thinking about how your programs and classes may be used from another developer’s points of view. The more your code can function autonomously, the easier it will be to maintain.

One of the big problems to avoid when programming is making a whole ‘toolset’ which can only be used on its own. You wouldn’t design a screwdriver that can only be used in combination with a drill and spanner at the same time, so why program like that?

The benefit of writing a blog is that every once in a while you don’t have to be entirely objective in your writing, so as a caveat to this post – that is exactly what I’m going to do.

For a long time I’ve harboured the opinion that Microsoft’s development platforms are not as accessible to a developer looking to learn the technology as other platforms are.

My basis for this belief is Microsoft’s apparent ‘we’ll do things our way’ approach to development. You have a steep learning curve to deal with as everything in Visual Studio is presented as their interpretation of a programming language, so to speak.

I firmly believe that at the very least for a developer learning a language or wanting to simply write some straightforward code for a standalone application – the Express versions of Visual Studio are the way to go. You needn’t worry so much about the IDE trying to make use of a lot of stuff you don’t really want in your project.

Part of the problem with full Visual Studio is that it is intended for use with Microsoft’s own whole seperate world of development technologies, as an independant package. The whole philosophy of which is that you can’t pick and choose which stuff you like and make use of just that. Generally once you go down the route of developing a Microsoft solution, it must be Microsoft all the way with all the niceties, not-so-niceties, and quirks in between. Of course this is a good business strategy and it also means that Microsoft get total commitment from developers that choose to use their platform commercially. However for many developers who do not have this full unwavering faith (and perhaps financial investment in terms of using / being a stakeholder of Microsoft products) it can be very annoying. Don’t get me wrong, I want to learn about the Microsoft family of development technologies, just not exclusively.

The essence of my argument for Visual Studio Express over the full version is that it is simpler. Personally I like simplicity in development platforms, it helps you understand new concepts better and really get to the root of what is going on behind everything you put into your code. Because you have to pay to gain access to more features of the .NET framework and associated development tools, the free Express editions do less for you and don’t have the annoying habit of trying to integrate features you don’t want in your Visual Studio projects.

Of course my own views on the usability of Visual Studio in general may be shaped by my familiarity with Java integrated development environments (IDEs). Nevertheless I feel my animosity towards Visual Studio is not unfounded having had several ‘bad expriences’ with it.

As an alternative to Visual Studio if you’re really looking to learn a language such as C++ from the ground up, and don’t mind applying an extra bit of your own mental steam, the old school approach of a text editor and compiler/linker is probably one of the best methods.

I think we try to be too clever and do too much in all walks of life, particularly in the computing industry, to the detriment of what we may actually be trying to achieve. It is worth considering that perhaps IDEs need to be much more text-editor like by default and allow you to choose which additional features you want for a project in a very clear and concise manner. I would choose choice of simplicity versus complexity over complexity alone, and I would choose simplicity over complexity if choice is not an option. The latter is why my preference is for Microsoft’s Visual Studio Express Editions over the full version of Visual Studio.

In the process of studying formulated analysis and design approaches relating to modern business information systems (IS) a clear problem presents itself; dealing with the varied nature of information systems in the currently rapidly developing computerised process improvement industry.

In short, stuff has changed an awful lot in just the last 5 years in development of business software. A slow awakening to the need of automated, computerised and online information systems has prompted a growth in varied businesses investing in software development. The wider the range of potential investors in technological business improvement, the harder it is to specify an approach for developing technology based solutions.

As such, texts written on the subject more than just 4 years ago seem outdated in their approach to, at the very least, the implementation phase of proposed systems solution. For example many design techniques may refer to defining file and database ‘records’ that may store data. Today people need to consider the possibility that their system may not deal in files at all considering the internet based nature of many modern business applications, and the database considerations are generally auxiliary to the overall architecture of the solution.

Of course many business systems are so outdated to the point that any form of automation is hugely beneficial. But with organisations in which keeping the level of technology in line with modern standards is necessary (e.g. to do business with other similar organisations), it is critical to make sure that the resulting solution is developed with internal extensibility and compatibility with other information systems in mind.

I think this problem of defining a set approach to the design and development of new solutions is perhaps why current thinking on how to analyse and design business systems seems fragmented and over-cooked. If anything the increasing variety of solutions available (such as web services and multi-tier systems), should lead to a more simplified design process focusing on common milestones required regardless of the potential technology required to implement the solution.

In essence what I’m getting at is there is a need to boil down and distil this avenue of study into a more concrete doctrine which may prolong the future of the interest in the business considerations which are very important to the success of software development projects.

One thing I’ve been thinking about a fair bit lately and trying to develop is an appropriate and concise writing style for this blog, and other technically themed articles. I believe my choice and usage of language is generally reasonably good, but I still read back over some of the things I have written and feel like stamping large sections of my writing with ‘could do better’ in red ink. It’s something that I think most scientific university departments attempt to encourage you to develop but unfortunately (and I suppose rightly) it is not generally ‘on the curriculum’. In light of this I suppose the best course of action is to develop it by practice and by reading well written technical texts and articles. So that’s what I’m attempting to do lately. I have found a short, but nevertheless very useful article here:

http://www1.cs.columbia.edu/~hgs/etc/writing-style.html

So, the summer is over. I’ve completed my period of work in the wacky world of software development and enjoyed my time spent there thanks to the good people who decided to take me on. I’ve learnt a lot, and achieved a lot in a twelve week period.

I travel back to university tomorrow to enjoy a slightly different lifestyle for another year, and as usual am looking forward to it. I do feel an exposure to the practicalities of software dev has really helped to consolidate what I already know and will undoubtedly give me useful experience to draw on in the future. I think college and university courses should offer more vocational experience in some way, because it is a very useful way of accelerating your learning.

The dawn of the new academic year is almost synonymous to a new year by the ordinary annual calendar, and on this academic new years eve I feel ready for anything my next year at uni can throw at me.