First i'd like to begin with saying: this is just my opinion. There will be others, plenty of them, that don't share my thoughts here.
The choice depends on what languages one knows or is familiar with.
First of all, the high level languages will be performing slower, but will be for the programmer a gift if she or he wants to write a program very quickly.
The lower you go, and why not immediatly go to assembly, the faster it will perform. And in theory it will "outperform" any other compiled language, because it is not being compiled, it is directly translated into machine language (well, more or less lol)
In reality if you write in assembly, the higher the risk of memory-leaks and poor performance the longer your code runs. This is because when writing in assembly you need to do everything yourself, and i mean everything.
While using c# for example, the common language runtime will take care of a vast amount of tasks for you, like cleaning up objects that you might have forgotten to close. Once out of scope, there is something like a garbage collector, and it will do just what its name says.
(as for java, it runs in the java virtual machine environment)
It actually comes down to: does the person that wants to write an application a complete novice, or is she/he yet a programmer?
If a beginner, then you wont be writing into assembly immediatly, or even C, C++ or C#. Try python (arrgghhh lol)
If not a beginner, let's say this person knows VBA, then she or he might consider leaving that behind and step up a little. Perhaps VB.Net, and why not C# (also .Net) You'll be writing code that can run on plenty of platforms.
Another thing to consider is the re-usage of what you create/write.
First you'll need to be aware that whatever you use might be "hot" today, it might be obsolete tomorrow.
Take VB6 for example. There's a wide spread amount of software developers that use VB6, but in 2007 (if i recall correctly) Microsoft decided it will no longer provide support for the IDE (development inveronment of VB6).
In fact, MS claims any VB6 application will still run through the life of Windows7, but they make no garantee on that. So one sunny day you might wake up, and find that MS has decided that your OS needed an update, and when you startup, bam, your VB6 application just freezes on you.
VB 6 is at the end of its life. (fyi: VBA is the little brother of VB6, quite little, but heck, still a brother lol)
That is one part.
Another part is that you might consider going OOP (object oriented programming)
You can't read a white paper or it says you'll end up in hell if you decide not to go with OOP.
Some people might say OOP is easy, but in reality it comes down to something simple: you either understand the entire picture and get it, or you don't. (I for one, who has been "raised" in modular programming, have had a hard time switching over, no need to be ashamed about that lol)
The advantage of OOP, as the "Experts" say, is the easy re-usage of your blocks of code. (framework, assemblies & classes --> which has a variaty of exotic terms like inheritance, polymorphism, encapsulation, abstraction, messaging, ...)
What they mean is that you need to think about Lego. One can create a variaty of things using Lego-blocks, even if they come from different boxes.
They are ofcourse right in their mind to say so.
But i wrote classes in VB6, and modules, and i simply re-used them in other applications. No need to re-invent the wheel for each application you start to write.
Anyway, easier said then done.
The main difference, from my point of view, is that some 2 years ago, i still wrote in VB6, and when i did, the code was written automatically, i did not have to think about it very much anymore. As for now, you don't start writing code a few seconds after you had an idea for an application, when using an OOP-language.
You really need to think very carefully what you'll create and how you'll create it, or before you know it you are sending your solution to the recycle bin and start over from scratch.
Simply put: learn a descent language, go C#. (i assume the following links will be allowed, i don't know)
Start here : http://www.homeandlearn.co.uk/csharp/csharp.html
http://en.csharp-online.net/Visual_CSharp_Tutorials
On Microsoft.com you can download a free Visual studio : http://www.microsoft.com/visualstudio/en-us/products/2010-editions/visual-csharp-express
Now because this is a free visual studio editor it is "somewhat" limited, meaning that you'll have to do more work to get things done (in the not-free versions there are tools integrated that take some work of your hands, but using the free version you will learn more, simply because you'll have to do it yourself)
Just remember, before you start on a real project: go for 3-tier at least!
Meaning, 3 seperate layers.
The lowest layer is the DAL, or Data Access Layer. This is where you will be writing your code to talk to your database (or any other storage)
The middle layer is the BLL, or Business Logic Layer. This is a layer will you will implement business logic. (simple example: a zipcode in the USA is different from one in Canada. This is where you will test this input before sending your insert/update command to the DAL)
The highest layer, is the Presentation Tier, it is the User Interface, or better know as GUI (Graphical User Interface)
There are several advantages on building your application this way. (in fact, every solution should at least have these layers!)
For example: today you will be using an MS Access database as your datastorage, so logically in your DAL (data access layer) you will be writing code that talks to an access mdb. Now if tomorrow you decide to move up in the world and go for a full blown SQL Server database, all you need to do is change the DAL. There is no need to change anything in the other 2 layers (the GUI and the BLL)
Another example: if your BLL (business logic layer) is very well tested, and you have functionalities in there you need in another application, it is easy to copy it to the other project.
Something to remember on this: The GUI only knows the BLL exists. It has no knowledge whatsoever of a DAL.
The BLL only knows the DAL exists, it has no knowledge whatsoever of the GUI.
The DAL has no knowledge whatsoever of the other 2 layers.
Keep this in mind when you are writing code inside each of these layers, it will make it very much easier to take a layer and use it in another application/project.
The way you connect them in the Visual Studio is in the GUI you add a reference to the BLL. And in the BLL you add a reference to the DAL. That's all.
(in reality you'll have at least one other layer, which will have structures (classes) that describe certain 'objects'.
Lets say you write an application about Pick4. Most likely you'll have a description of something called a Pick4Number. (with for example properties like Sum, Width, OddEven, etcetera)
Now, if you want to fetch a list of draws between two dates, in the GUI you tell the BLL to get a range of draws. The BLL on its turn will tell the DAL to talk to the database.
In ideal scenario, the DAL will return a list of Pick4Numbers (in that case all the properties are already available on each layer)
So it will pass back a List<Pick4Numbers>. Now, the BLL needs to know this type, so it needs to know the existance of that class Pick4Numbers, just like the DAL.
Again, in your GUI you will need to know the same existance of that class Pick4Number.
This is done using a cross-layer layer. This layer can be referenced in all three your 3-tier layers, without compromising your architecture. One rule: make sure the classes in this layer only have functionalities that stay in the scope of that layer!!! This layer has no knowledge of anything else. Look at it like this: it is used, and only used. It will itself never use something else. (i hope this makes sense)
The logic says that if you ever copy your DAL to another project, it means this new project will be using pick4numbers also, so you'll copy the cross-layer layer also to that new application.
I'm going way of track here haha, moving away from the original question, sorry for that...
I just hope this is of use for anyone.
cheers
Ricky