Monday, 24 April 2017

Practicals before PowerPoints

When I was first teaching Windows programming PowerPoint hadn’t been released, so one of my first projects was to write a program to create and present course slides.  It was written in C (which was all there was for Windows in those days), and it seemed quite elegant to be able to present a course using a (huge) video projector.  When PowerPoint came out I switched to using that, largely because of things like clipart.  Since then using PowerPoint or its equivalents to present courses has become pretty much universal, so much so that it’s often taken for granted.

In the last few years though, I’ve found myself presenting for a week or so as part of long training programmes.  Often students will have had many weeks of sitting watching PowerPoint slides, so I started giving my sections without using PowerPoint past the introduction.  And it has worked really well!  Not only does it give them a break from staring at a projector screen, but it has allowed them to learn better as well.

More recently I read an article in a scientific magazine saying how people often learn more if the traditional approach of talking about something and then doing practical exercises is reversed, and I’ve found this to be true.  The practical-first approach is particularly effective when teaching things like Python to relative beginners, many of whom have never really programmed before.  Python is particularly good for this, as students can write a program which ‘does something’ with almost no background theory at all.

It's harder to do this with subjects like MVC and web applications where some content is really needed before fingers can hit the keyboards, but even then I find I’m preferring to draw things on a nice big whiteboard rather than resorting to PowerPoint.  Better still, every course is a little bit different rather than being the same old sequence of slides, so I enjoy teaching even more.

Tuesday, 8 April 2014

Going Backwards

Recently I've been wondering if PC software development peaked a few years ago, and has declined in some ways.  In the 1980s and earlier it was difficult, with much software being developed in assembler or C.  The 90s brought us things like Visual Basic which were enormously more productive, even if frowned about by some software purists.  Object orientation started to pay dividends, and with the arrival of things like .Net we had very elegant ways to produce powerful applications.

From my point of view as someone who has always worked with networking, things like the elegance of network streams and threading were a boon.  As far as the graphical user interface aspects, WPF was truly wonderful, even if it did require people effectively learning 2 languages.

But recently we seemed to have gained the idea that we must always use patterns, frameworks and middleware.  Things that started out as an elegant solution for some kinds of application, such as MVVM, have become mandatory.  Being able to ‘bolt in’ components where this gave great benefit to some applications became a requirement to use IoC containers for all applications.  Using middleware as a convenient way to connect between disparate systems became the only way of doing things.

I have two motivations for writing this.  The first is reading people’s advice to new developers as to what they ‘must’ do.  For example, someone asked a perfectly reasonable question about naming conventions in WPF, and was shot down with people saying how you ‘must’ not name controls because you ‘should be’ using MVVM.  Despite not knowing what the application was doing, and the fact that MVVM can easily make some applications a good 10 times more complex.  Similarly reading how you ‘must not’ use ‘new’ to create objects, as this is being a ‘control freak’ and an IoC container ‘must’ be used to inject the appropriate object, even if this has zero benefit to the particular application and adds significant complexity.

The second is having taken part in a large graduate program where teams had to compete against each other to produce a medium-sized client server application.  The teams varied enormously in their approaches, although the majority used things like REST, messaging services and Spring.  One team decided on a lower level approach, managing their own threads and using TCP/IP sockets and streams.  This was frowned upon, as it was felt that it would be so much less productive.  In fact they won the competition.  They had achieved much more than anyone else, the application performance was vastly better (it flew whereas the others crawled), and it turned out to be much easier to understand and maintain.

But it also applies in the ‘real’ world.  I remember helping a colleague as he put together a design using MEF, Entity Framework and lots of other enabling technologies, and weeks later was still hitting incompatibilities and the like.  Had he been using a typical approach from a decade ago it would have been completed in that time, and be much more maintainable.


Of course I’m not being extreme on this, just saying there are horses for courses.  Otherwise I’d end up like Linus Torvalds and still just coding in C.  And look where it got him!

Thursday, 19 April 2012

A rant from a confused Windows developer

I started developing for Windows with version 1.02 and back then it was easy. Not easy to develop, as it took days just to create a nice looking dialog box, but easy to decide on the approach to take. You bought the Windows SDK with Microsoft’s C compiler and developed in C, as there wasn’t anything else.

C became C++ and that was the obvious path to follow. Visual Basic appeared, and that was better for some kinds of application. It was fairly easy to know when to use one, the other, or both in combination. Java was great, but didn’t work out as a Windows desktop solution because of politics, and then .Net came along which gave us C#, a near-perfect evolution from C++ and Java, as well as a re-crafted Visual Basic with all the shortcomings removed. The choice of language became a ‘lifestyle’ issue as they were interchangeable, and choosing an application approach was easy - Windows Forms for the desktop and ASP.Net for the web.

Then in 2008 we got Windows Presentation Foundation (WPF) which was radically different. Its benefits and evolution were obvious, and although it had a much steeper learning curve than Windows Forms, once I got over that I was an instant addict. The development community were not instantly impressed though, and I found very little appetite for training in it at first - not helped by the fact that the development tools weren’t really ready until the service pack for VS2008 came out. I was once again comfortable that the standard approach for desktop development was clear - WPF together with C# or VB.

Then there was Silverlight. Originally something programmed using JavaScript for the web, it became something you could use with C# ‘out of browser’. I found my customers wondering whether to use WPF or Silverlight for their desktop applications. It should have been very easy - WPF being the whole package, Silverlight a true subset of WPF, but it wasn’t like that. There were coding differences, similar features being added to both which were incompatible with each other, almost as though they were competing products from different companies wishing to outdo each other.

Next there was Windows phone 7. I got myself one of these, which like most things mobile-phone was much more expensive than I had thought (what exactly is a ‘smartphone bolt-on’ anyway?). I could code for it in C# which was nice and use Silverlight, which was fine in theory, except it wasn’t the same Silverlight. And it wasn’t the same framework, with all the things I wanted to use for my first applications being missing (TcpClient comes to mind). Many things were missing because of security and sandboxing, which I could understand to a point, but many were missing because it was a ‘resource limited device’. My phone has 60 times more memory than the first system I used Windows NT on, so not being able to do the things that Windows NT could is silly.

And now there’s Windows 8. It gains a touch screen interface, so that should have been easy - add some new features to .Net and WPF and we can develop WPF applications in the way we know and love and gain touch. But no - it would seem that it has to evolve from Windows Phone, but be different still from that, with features that are just about acceptable when developing for a phone but nonsensical for the desktop. Just like Silverlight, many things seem to be different to ‘classic’ .Net for no good reason. It feels like it was designed to be programmed in HTML and JavaScript, with something similar to .Net tagged on as an afterthought for C# developers. Now I love JavaScript, but only when I’m writing web page code - elsewhere it is just sloppy and error-prone compared to a real language.

The sad thing is that for the first time since my love-at-first-sight relationship with Windows I’m wondering if I can be bothered. The frustrations of hitting things which are different for no good reason mean that I’m starting to look elsewhere. I’ve always developed for Linux as well, but I’m starting to imagine a world where everyone really does start installing Ubuntu for free rather than buying Windows, and someone gets round to finishing Open Office. I’ve started writing for Android - yes the Java environment has been more of a mess than anything in the Windows world but it’s still a nice language.

No doubt I’ll end up loving WinRT in the end, but it feels strange to be considering alternatives to Windows after all these years. One thing is easy - I’m definitely not an Apple fan. Unless of course they decide that C# + WPF + real .Net is their development environment of choice!

Labels:

Tuesday, 25 May 2010

Has VB come of age?

When .Net first came out I tended to use C# by choice, having a history of Java and C++, but I still retained an affection for Visual Basic. Most things could be done in VB rather than C#, but VB was always a little more verbose and had annoying features like having to type in space-underscore to carry a statement onto another line. Provided strict type checking was turned on though it gave the same performance as C#, and of course having been a Java enthusiast strict type checking in itself was very important to me.

This week I wanted to begin a project involving various forms of parallel execution. In the past I would have instinctively gone for C#, but having been training in VB for the previous couple of weeks I decided to begin with VB. And I found myself rather liking it, especially now I don’t need the space-underscores any more. I guess the first thing is that being able to do parallel programming naturally in VB was revealing – something that would have been assumed to be C++ territory a decade ago. But I also found that small changes from the last couple of versions appealed.

For example, let’s imagine that you are issuing an ADO.Net command and getting a data reader back. In 'VB6 style' this would be something like:

Dim cmd As New SqlCommand( sql, connection )
Dim rdr As SqlDataReader
rdr = cmd.ExecuteReader()

VB 200x of course allows 1 less line:

Dim cmd As New SqlCommand( sql, connection )
Dim rdr As SqlDataReader = cmd.ExecuteReader()

But the 2nd line feels a little unnatural to a Java mindset. Type inference allows:

Dim cmd As New SqlCommand( sql, connection )
Dim rdr = cmd.ExecuteReader()

Which is now as concise as it would be in C#. Type inference goes a bit further in VB than C#, for example:

Dim someList As New List(Of SomeClass)
For Each thing in someList

Next thing

Where in C# the type of ‘thing’ needs to be given such as:

foreach( SomeClass thing in someList ) { … }

which is not very different but some reason many people find the SomeClass thing confusing in training courses.

As a last example, this is a trivial example of a lambda in C# which shows a message box (for something to do!) from a thread:

Thread t = new Thread( () => MessageBox.Show( "text " ) );
t.Start();

The VB equivalent would be:

Dim t As New Thread(Sub() MessageBox.Show("text"))
t.Start()

I feel this is a case where the VB is more intuitive (and is actually less typing). But that’s just me.

Wednesday, 14 October 2009

WPF 3D, The Beauty of Mistakes

When I first coded graphical applications for Windows using GDI many years ago, one thing I discovered was that coding mistakes could often produce very attractive results, particularly when using things like bitmaps and ROP modes. Not as exciting as some of my first work controlling industrial machines, when a mistake could cause 3 tonnes of metal cutting equipment to crash into its end-stops at high speed, but pretty nonetheless.

With WPF 3D coding it's even better. When writing code I like to test things out as often as possible, and this is particularly beneficial with 3D work as often when trying to visualize things in 3D space it's just easier to build things up gradually. The sad thing is that the intermediate results often look better than the finished article, even if they are not correct. For example, this is a chart before the size of the radial elements was calculated.


This is an incomplete spherical element.
And this is the same item with a little more coding.


Another example of this is the use of normals to influence lighting and shading. I most often build up the mesh by creating the points and triangle indices first, viewing the results for correct positioning etc. While it's undoubtedly better to think about and hopefully calculate the normals at this time, I tend to do it afterwards. I'm then disappointed because although the appearance is definitely more correct, it's often not as attractive. The simple bar chart example below shows this.

The finished article had much better defined edges and smooth colours, but it definitely didn't look as nice!

Thursday, 8 October 2009

Silverlight and WPF

This week I have been doing some work producing charts. Many years ago I sold a product called 'Business Graphics Library' and since then many of my projects have involved special charts written on request for customers. As an experiment I wanted to try porting a chart I called a 'starburst', which had originally been written in Excel VBA, to Silverlight.

The chart had a dynamic layout, so I wrote the new one entirely in C# rather than XAML. As you can imagine it was much more straightforward than the Excel VBA original given the rich graphics supported by SL.


Simple starburst

The next step was to use the same code for a WPF desktop application. The Silverlight control included some data structures for passing the information to be plotted, including colours, and my first attempt was to use these, as well as the chart code itself, directly from the library by simply adding a reference to the Silverlight control DLL into the WPF project. This almost worked, but ultimately failed because the Silverlight classes I used were in different .Net assemblies to their WPF equivalents. Even basic types like Color had this problem.

To solve this I added the classes as existing items to the new project, but used the 'Add As Link' option in the dialog (by clicking the arrow on the Add button). I now had common source between the 2 projects, and I could display my chart on a web page using Silverlight or a desktop app using WPF. So far so good.

At this point it was all driven from C#/VB code. The next stage was to be able to use my control entirely from XAML, so some dependency properties were required. Registering these using DependencyProperty.Register worked fine for WPF, which I did first, but I could not get the same code to compile for Silverlight. It turns out that there are different Register methods, and the arguments I had used for WPF (which has 3 overloads) were not compatible with Silverlight (which has only one). Luckily there is a WPF overload which is compatible with the Silverlight implementation so by passing a null for the 4th argument I had compatible code again.

Slightly disappointing to be entering the area of coding around differences. Having a common API between desktop and web applications is a really good idea, and little differences like this seem to be pointless distractions. Of course there are big differences as well. Having used an image projection in SL I was disappointed not to find it in WPF. But my real goal for the Starburst chart is a true 3D version (the subject of another post shortly), but this can only work for WPF as Silverlight does not support true 3D. Given that Silverlight's one major advantage over Flash is the .Net Framework (IMHO) I would hate to seem them diverge.

Thursday, 5 June 2008

Performance of C# vs C++

Many people see C# as a fine language for business applications, but feel it lacks the low-level capabilities of C++ for software which is close to the metal.

C# includes many features such as the unsafe keyword that allows you to achieve most of what you could do in C++, but even without the use of unsafe code performance-intensive programming is possible. I was recently involved in a large project where I had the opportunity to compete with a C++ team, by writing an equivalent program from scratch in C#. Without wishing to break my NDA, the application involved much bit-twiddling, video, networking and the like. Originally I kept in an existing C++ library, but ended up using C# exclusively.

The C# code was around 20% of the size of its C++ equivalent, measured using a sophisticated tool that ignored layout, comments etc. Performance ended up being about the same – there were initial performance problems with the C++ version which were fixed by some serious coding work.

Where I expected the C# version to fall down was with load times, due to the just-in-time compilation. In fact this was very noticeably faster in the C# version – I presume that the JIT overhead was compensated for by the smaller code size.

It would be nice to try something similar with Visual Basic one day!

Labels: , ,