Rediscovering The Fun Of Computer Programming

[anonguest]

Since I have previously received very generous and helpful advice on various 'techie' matters do I post this here.....

After not having done any computer programming since..........errrr, how to put it without divulging my age, the monochrome screen display and command prompt era......I have very recently, for intellectual fun, started to learn to program in C++.

I have been lucky enough to use someone elses licence of Microsoft Visual C++, and as a result also get a thrill of being able to make my own 'proper' Microsoft Windows compliant applications (although admittedly very very very simple and crude so far!).

There are a couple of considerations, and resulting questions to pose here, for me to consider.......

For reasons to long to go into here I do want, for the time being, to stick to producing only applications with GUIs that have a proper Windows look and feel.

As far as I know the above mentioned Visual Studio application is the ideal one for that job? True/False

Also, again for reasons not for discussion, I want to use the development tool, whatever it may be, as a locally installed version and not some 'cloud' based licenced option.

I am aware that MS have offered a free 'Express' version of their Visual Studio application BUT that this omits MFC capability - which, ideally, I want to use or at least have at my disposal.

Thus, are there any recommendations for IDEs that can compete well with Visual Studio (e.g ease of use, robustness, MS compatibility, etc) BUT which are either free or very much cheaper than Microsofts prices (I do not want to spend several hundred pounds on a computer programming IDE tool for what may well end up being only casual programming)

As always TIA

[MarkG]

I am aware that MS have offered a free 'Express' version of their Visual Studio application BUT that this omits MFC capability - which, ideally, I want to use or at least have at my disposal.

I haven't programmed on Windows in years, but, as far as I remember, it used to be that you could just download the relevant SDKs to install and the Express version then worked fine.

[JoeDavola]

Congratulations on taking up programming again.

Did you originally program in the days before object oriented programming? If so you'll obviously need a good book about OO principles. Once you've got that down, if you want to be really clever you can look into what are called 'design patterns' which are 'types' of object models that have cropped up over the years and can be useful for solving certain problems.

However if you're not writing uber-complex enterprise level stuff, design patterns might be overkill. Still, something to think about.

If you want to develop in C++ MFC, I'd stick with visual studio. I think it's a wonderful IDE and it's the natural choice obviously for MFC C++ stuff. Being a fellow programmer I'd love to know what kind of stuff you're going to be writing that needs C++ levels of control with the windows API, but I understand if it's a secret

For any programming questions, Stack Overflow is your friend. For example, this one is quite appropriate for you and the reply is quite detailed, might be of use as it reccomends some books:

http://stackoverflow.com/questions/18165076/prerequisites-for-learning-mfc-programming

[hirop]

C++ is a heck of a way to have #fun# programming. But, yes, VS is the relevant ide, and will be for any of the MS languages. I'm sure you have your reasons, but cracking on via c# would be my own suggestion - simply because your range of projects is broader (Windows GUI\WPF, Windows Services,WCF for web services, various flavours of web app development) in terms of whats more common, and with vast quite readily available knowledge via t'internet resources.

When I was a student being force-fed C and C++, I recall Borland c++ was the rival IDE and library, but feck knows if that is still around.

[spyguy]

Python or Squeak.

C++ is not really 'fun'.

VS IDE is a total rat hole.

[Turned Out Nice Again]

Oo and design patterns for fun? You'll have him doing unit testing next!

I think mobile apps are his best bet for fun in coding these days.

[sPinwheel]

I think mobile apps are his best bet for fun in coding these days.

+1

[dgul]

Hmm. If you really want to program in C++ and write applications for Windows VS is the only way to go.

If you want 'fun' then probably just about anything else would be better. Apart from Cobol.

[not that C++ VS is bad - it is very good and very powerful - probably the only way to write an large and powerful application for (paid) distribution]

We develop for 'proof of concept' in something faster (python or java depending on platform) - then speed up the bottlenecks with faster code where necessary.

[spyguy]

OK,

I would recommend you look at setting up VMs - either VMware/Xen, or Virtual PC. All available at £0.

Try putting a small Linux disto on, or Minix

Language wise: C++11, Python, C99.

If you want to 'look and learn' from code: BSD ZFS module, FreeRTOS, or more obscure, Erlang's BEAM VM.

[spyguy]

GUi stuff - QT.

[porca misèria]

If you want to work on Windows, get used to paying up, again and again and again. Or else doing battle with the system to work as a pirate. Either way, expect to have to upgrade regularly.

For a bit more fun at no cost, install something more sensible. For example, Linux or BSD.

[gaztastic]

I used to do c++ programming as a hobby before I started working a programmer and it's a great way to pass time.

I would assume that visual studio express will do whatever you want, but you may need to bend it a bit if it doesn't support what you want straight out of the box.

If you're keen to make some windows look n feel applications, it's well worth having a look at forms and c#. From my experience with c#, it takes away a lot of the rough edges of c++ (lack of a true object model, STL syntax issues, memory management and so on) and gives you a language where you can get a lot done in very little time. Forms and xaml are very similar in those regards, in terms of reducing the time taken to go from ideas to implementation.

Whatever you end up doing, have a lot of fun with it.

[MrPin]

Learning programming for the sake of it is very difficult, without having some end project in mind. Like learning a lot of chords with no tune in mind.

[Battenberg]

Failing all of the above you could always ask a Barclays Digital Eagle.

[Deft]

As a similar story, my programming experience / interest was initially spurred by a colleague giving me some VBA lessons for doing things in Excel (I use Excel a lot in my day job). I then dabbled in Python (Pygame for making mini games and Scipy for more scientific computing). I found Python fun and easy to use. I then tried to learn some C (too much like hard work for a hobbyist, but it did open my eyes to things like pointers), a bit of C++ (still hard work) and then C#. I'd spent a lot of time learning VBA and got at least mediocre at it, so C# felt very familiar. If you want to go Visual Studio Express then C# seems like the best starting point so you don't get too bogged down in the real nuts and bolts.

Like MrPin says, I got a lot better at VBA simply because I had loads of ideas of work related things I could automate. I lost momentum on the other things because after I had done some examples from books etc. I didn't really have a clear thing I wanted to do.

[MrPin]

As a similar story, my programming experience / interest was initially spurred by a colleague giving me some VBA lessons for doing things in Excel (I use Excel a lot in my day job). I then dabbled in Python (Pygame for making mini games and Scipy for more scientific computing). I found Python fun and easy to use. I then tried to learn some C (too much like hard work for a hobbyist, but it did open my eyes to things like pointers), a bit of C++ (still hard work) and then C#. I'd spent a lot of time learning VBA and got at least mediocre at it, so C# felt very familiar. If you want to go Visual Studio Express then C# seems like the best starting point so you don't get too bogged down in the real nuts and bolts.

Like MrPin says, I got a lot better at VBA simply because I had loads of ideas of work related things I could automate. I lost momentum on the other things because after I had done some examples from books etc. I didn't really have a clear thing I wanted to do.

The beauty of VBA in MS Office, is that it can automate a lot of boring tasks. It's not really a "nice" language to use but it does the job. Good books on it are very hard to find! If you can recommend one, I will buy it. If you can make it useful you will be a STAR in the office!

[The XYY Man]

The beauty of VBA in MS Office, is that it can automate a lot of boring tasks. It's not really a "nice" language to use but it does the job. Good books on it are very hard to find! If you can recommend one, I will buy it. If you can make it useful you will be a STAR in the office!

Testify Brother Pin.

Where I work, traceabillity data is kept mainly in Access databases, but Excel is the tool of choice for most people reporting data-based information within the factory.

The problem is that Access frightens the shit out of most of them as it's ever so slightly more difficult to produce their key bargaining weapon with the bean-counters - that of lots of graphs - in the pretty simple way they have learned in Excel. So they stick to the tried and tested - despite it often taking much longer to collate and paste all that data into a spreadsheet.

But once you get the grip of VBA, you realise you can do the number-crunching directy in Access with it's powerful queries, and then simply run an Excel macro that brings all the data into their "master graph.xls" spreadsheet at the touch of a VB button.

You turn 3 days of cutting and pasting raw CSV data to Excel into a few minutes of queries and macros being ran automatically in the background before magically appearing in their Excel front-end - and at the same time, you become the one-eyed man in the kingdom of the blind...! Factory managers tend to get a bonk-on over this kind of thing.

And be sure to make all your variable names swear-words - just to piss them off more when they ask you to show them the source code. "Let Pissflaps = 2" is one of my personal favourites...

XYY

[spyguy]

Python does have good COM bindings - google PyWin Mark Hammond (?)

Find the COM documentation and you'll be sorted.

I missed the bit about GUI + Windows only.

Try Python + QT - PyQT

[spyguy]

Testify Brother Pin.

Where I work, traceabillity data is kept mainly in Access databases, but Excel is the tool of choice for most people reporting data-based information within the factory.

The problem is that Access frightens the shit out of most of them as it's ever so slightly more difficult to produce their key bargaining weapon with the bean-counters - that of lots of graphs - in the pretty simple way they have learned in Excel. So they stick to the tried and tested - despite it often taking much longer to collate and paste all that data into a spreadsheet.

But once you get the grip of VBA, you realise you can do the number-crunching directy in Access with it's powerful queries, and then simpy run an Excel macro that brings all the data into their "master graph.xls" spreadsheet at the touch of a VB button.

You turn 3 days of cutting and pasting raw CSV data to Excel into a few minutes of queries and macros being ran automatically in the background before magically appearing in their Excel front-end - and at the same time, you become the one-eyed man in the kingdom of the blind...! Factory managers get a bonk-on over this kind of thing.

And be sure to make all your variable names swear-words just to piss them off more when they ask them to show you the source code. "Let Pissflaps = 2" is one of my personal favourites...

XYY

Access frighten the shit out of me - and Im OK with DBs.

Its all a bit wing and prayer (still).

I think all these copnaies buyeing more and more into Excel to do bascially run + model the compnay are jus igging themselves a big whole.

One, Excel number precision for Integer + Floats is poor.

Two, spreadshets lump data + code together, making it hard to test.

[sPinwheel]

GOTO 10

[Deft]

The beauty of VBA in MS Office, is that it can automate a lot of boring tasks. It's not really a "nice" language to use but it does the job. Good books on it are very hard to find! If you can recommend one, I will buy it. If you can make it useful you will be a STAR in the office!

I have automated so much of our departmental data organisation and analysis it has saved us collectively loads of time. Looping through network share folders to extract data from templates and generating pivot tables / charts automatically. I have little tools that re-organise things from scientific databases, generate labels for our warehouse guys, spam e-mail people to allocate materials, fit non-linear equations to data. Loads of fun to help me learn and still satisfying when they run! I am so productive I just sit back and relax all day. I try to teach people too, to stop scientists spending too much time copy/pasting and also organising their data so our proper statisticians can more easily look at it in SAS.

The best general book I'd say is Power Programming with VBA by John Walkenbach (http://www.amazon.co.uk/Excel-Power-Programming-Spreadsheets-Bookshelf/dp/1118490398)

The other book I have found useful was Programmers Reference (2007) (http://www.amazon.co.uk/Excel-2007-Programmers-Reference-Programmer/dp/0470046430/). Although they never updated it, not much has changed in VBA since then. There are probably plenty of others that are decent. Beyond those two I have resorted to Google for specific things. Power Programming with VBA covers 95% of what most VBA people will need. I have also found the Chip Pearson site great for some specific things (http://www.cpearson.com/Excel/MainPage.aspx).

[MrPin]

Testify Brother Pin.

Where I work, traceabillity data is kept mainly in Access databases, but Excel is the tool of choice for most people reporting data-based information within the factory.

The problem is that Access frightens the shit out of most of them as it's ever so slightly more difficult to produce their key bargaining weapon with the bean-counters - that of lots of graphs - in the pretty simple way they have learned in Excel. So they stick to the tried and tested - despite it often taking much longer to collate and paste all that data into a spreadsheet.

But once you get the grip of VBA, you realise you can do the number-crunching directy in Access with it's powerful queries, and then simply run an Excel macro that brings all the data into their "master graph.xls" spreadsheet at the touch of a VB button.

You turn 3 days of cutting and pasting raw CSV data to Excel into a few minutes of queries and macros being ran automatically in the background before magically appearing in their Excel front-end - and at the same time, you become the one-eyed man in the kingdom of the blind...! Factory managers tend to get a bonk-on over this kind of thing.

And be sure to make all your variable names swear-words - just to piss them off more when they ask you to show them the source code. "Let Pissflaps = 2" is one of my personal favourites...

XYY

[MrPin]

Testify Brother Pin.

Where I work, traceabillity data is kept mainly in Access databases, but Excel is the tool of choice for most people reporting data-based information within the factory.

XYY

I testify Brother XYY, for I have seen the light! Don't let you manager use a database! For they think they have become wise!

One of my colleaugues had to tell off our boss for "tinkering with data", and coming up with very bad ideas! His very "reasonable" point was "you are employing two database analysts, so you don't have to do it yourself!

[SNACR]

Hmm, who knew a load of lorry drivers had so much programming knowledge.

Fortran's where it's at for the cool kids.

[stormymonday_2011]

Access frighten the shit out of me - and Im OK with DBs.

Its all a bit wing and prayer (still).

I think all these copnaies buyeing more and more into Excel to do bascially run + model the compnay are jus igging themselves a big whole.

One, Excel number precision for Integer + Floats is poor.

Two, spreadshets lump data + code together, making it hard to test.

The problem with all the Office products and their macros is that what works for Joe Bloggs in Dept A does not scale if attempts are made to run it across the wider enterprise or when taken off local servers and stuck in the Cloud as many companies do know. I have seen such applications bring whole networks to their knees in the worst examples. In addition documentation, code control, configuration management, quality assurance before release and security is often poor or non existent. As a consequence when the aforementioned Mr Bloggs gets plastered and falls under a bus everyone else takes it up the Wazoo. Moreover, sooner or later some bright spark in senior management decides that Google's tools or some open Office suite is going to be cheaper than MS and all those lovingly crafted VBA macros suddenly wind up on the great code junk pile of history which is I believe where MS themselves want to put them eventually as .NET not the old Component Object Model is the favoured way forward (though the former does contain much of the latter under the wrapper).

https://en.m.wikipedia.org/wiki/Visual_Basic_for_Applications