Jump to content
Sign in to follow this  
  • entries
    45
  • comments
    115
  • views
    54967

Programmers scare me

Sign in to follow this  
Kylotan

369 views

A general reflection on web development earlier led me to think about programming - or rather, programmers - in general.

What started all this thinking off, was XSLT. In essence, it's a simple technology for transforming one XML document into a different one. In practice, this is nearly always about transforming an abstract document into an XHTML document for web display. On the surface, it sounds reasonable. Yet I can see almost no reason whatsoever why I would ever need to use XSL/XSLT again. For starters, this processing is likely to be done by an ASP/PHP/Python/whatever page, based on information from a database. Why generate an abstract XML document from that data and then transform it when you can just transform the data directly? The general argument is that of abstraction, yet the web script already forms a layer between the data and the presentation, so what's the issue? People talk about separating the presentation from the logic that generates the page, but that's what CSS is for. All examples of XSL I've seen could have been replaced with 1/3 the typing if a traditional language had been used to output the XHTML instead. This just seems like a classic example of overengineering, where extra layers of abstraction are added to meet some theoretical utopian design specification at the expense of developer time and the amount of code that needs to be understood and maintained.

A similar thing exists with my complaint about Python web development in the previous entry. Nobody is interested in simple answers to the problems that face most developers; instead, they want a framework that can do absolutely anything, with so much flexibility and abstraction that it provides virtually no benefit to anybody. Instead of simple APIs that only work in one or two places, the result will be a complex API that works everywhere. No-one's a winner. Yet these developers seem very keen on it.

It struck me that the same thing happens here on Gamedev.net. Although attitudes are slowly changing, people still instinctively overengineer things. They write engines instead of games because they want to make sure the engine can accommodate anything their eventual game will throw at it. Often they spend so long on this that they never even get around to writing a game. They worry about low-level optimisation no matter how often we tell them to wait until they've found a problem and profiled it, because they want to be sure that they've got as much performance out of the program as possible, in case they need those CPU cycles later.

About eight years ago, I became more familiar with commercial computing as opposed to the purely game-related computing I had grown up with. One thing that caught my attention was the painful overuse of the term 'solution'. You didn't write programs, they were 'solutions'. Money package? No, 'Personal Finance Solution'. External disk drives? No, 'Portable Storage Solutions'. File-sharing server? No, 'Local Network Collaboration Solution'. 3D shooter? No, 'Alien Elimination Solution'. It drove me crazy. But that's the way of businessmen; to sell a product usually means that you have to promote it as being necessary. And something is only necessary when it provides a solution to a certain problem. Hence calling something a 'solution' is a nice vacuous phrase to make you think that the product they're selling is a complete and working answer to whatever issue is on the customer's mind.

Now, the critical thing here, is that programmers generally hate solutions. A solved problem is not interesting. We enjoy solving the problems - it's the businessmen who enjoy sitting there twiddling their thumbs idly while their 'implemented solution' brings the cash rolling in. That's why the big rich companies have their software 'solutions', but are boring as hell. I can go to Electronics Boutique and buy an off-the-shelf Strategy Game Solution but as a programmer I'm not interested in the end solution, just the act of solving the problem.

As a result we often spend too much developer time on solving problems that we don't really have, whether that's forcing an extra abstraction layer into a web application on the off-chance that we might one day want to display the same data in 2 different ways, or trying to work out a faster alternative to that division in an inner loop just in case it actually is too slow, or trying to develop a standard web development API that is portable across several different servers even though the end user will almost always only use one such server.

Maybe that's just the way of the programmer, more akin to a researcher than an engineer, learning and experimenting rather than building and completing. I'm happy with that, although I often stop to wonder how much could have been achieved if we could change every 100 half-completed projects into 50 completed ones. How much work is wasted? I guess I'll never know.
Sign in to follow this  


5 Comments


Recommended Comments

No matter how many times we reinvent it, a wheel is still a wheel. Your opinions on this matter resonate totally with me these days. Being a recent 'convert' I realised the hard way that the things you were saying above are painfully true. It takes a total paradigm shift to realise that fun can be found outside the problem.

As for XSLT, I agree to some extent. It had more of a purpose in the old ASP style days, where script was woven into the design as it truly allowed a developer to separate the frontend from the underlying page logic. However it seems that in the days of ASP.NET and codebehind the power of XSLT has been diluted somewhat.

Share this comment


Link to comment
The thing is, I can't even see much use for XSLT in traditional ASP. To some degree, the presentation layer needs to know what data it is presenting, and the application level needs to know what data is required for presentation. There's interaction there, no matter how you look at it. I can't think of any reason why you'd want to output XML and let the presentation people create XSL and CSS to format it, instead of outputting XHTML and letting the presentation people use CSS. I expect I'm missing something but I really can't see any benefit here.

Share this comment


Link to comment
I ported my site to use ASP (3.0) XSLT and XML to generate XHTML pages with CSS. The benefits I found were that I could create a single XSL sheet for my entire site and use the ASP to inject relevant sections into an XML stream for processing. It basically allowed me to specify my site structure in XSL, the design in CSS and the content in XML/Database queries. It's funky in the way that you can hotswap layouts, design or content at will, so redesigning my site is a simple case of throwing in a new CSS or XSL file and the old content and logic continues to function without any alterations.

It's very abstracted from traditional web design though as you can't see what you're working on until you pull it all together and it often feels like throwing 4 stones to hit one bird, however it's nice to have a scalable base platform that's capable of running multiple sites with different layouts and design yet still keep the same common scripting components.

Share this comment


Link to comment
So really, the gain there is that you can change the structure easily, because your ASP just outputs the information as XML but not the structure, whereas outputing XHTML is both. That's a fair point: but how often do you really need to change the structure? :) Is this a cool feature that overcomplicates the system or is it truly useful?

For my personal projects, it's largely useless. I spent yesterday looking over my current web development project and I could see no point to adding XML/XSLT to it. This is because I'm developing a visual medium, where the information I want is dependent on the layout and vice versa, and all the stuff that can be abstracted out into a template is already abstracted out into separate functions or CSS. I can't even begin to imagine the XML documents I'd have to create to facilitate such a shift, compared to the current SQL -> list of results -> generate XHTML loops that I use.

Share this comment


Link to comment
Well, for me it's useful. I'm building a platform that's usable in several sites for myself and for my freelance clients. I get to add modular components that are design independent - in this situation it's a really powerful 'plus' as the site has to be design agnostic.

But, I can totally see your point on this. This type of system - because by definition it's independent from design - makes it hard to create the highly visual sites you see. As you say, when design depends on contnet and vice versa it's impossible to achieve this sort of cohesion with a CMS platform (without some hacking, of course).

What it comes down to is context. There's little point using technology for technology's sake if you're running a small site for yourself and likewise, if your site is heavy on the design integration, this particlaur context disallows this sort of generic coding. But if you need to deploy a lot of content in similar ways, or have multiple users updating the content or just need to ensure that several sites can hang off a single content or program logic source it really starts to come into it's own.

But largely, I agree - there's little point if you have a small site that doesn't change much. [smile]

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!