Quote:
Originally Posted by Tim
One thing that really gets me is that MS tie a .net release to a version of Visual Studio. This means if you want to develop .net 2.0 apps using Visual Studio you have to upgrade to 2005. I can see the business sense behind this but it does not help developers migrate to newer versions of .net.
|
Yep, it's not really very helpful of Microsoft, and I suspect it's slowed down .NET 2.0 adoption by a significant amount.
Currently, I have to put up with this:
string[] ParseFields(string line)
{
string[] fields = line.Split(delimiter);
foreach (string field in fields)
fields = fields[i].Trim();
return fields;
}
Whilst in 2.0 I could do this:
string[] ParseFields(string line)
{
return line.Strip(delimiter).ConvertAll(delegate(string field) {
return field.Trim();
});
}
And in 3.0, this:
string[] ParseFields(string line)
{
return line.Strip(delimiter).ConvertAll(field => field.Trim());
}
It's still got some way to go before it gets to the same level of expressiveness as Haskell, however:
parseFields = map trim $ split delimiter
Quote:
Originally Posted by Tim
One thing that saddends me is that there is this move away from programming native (as MS call it) code. If you teach someone java or some .net language they dont have to worry about the complexities of the platform. There is no need to teach about memory management or pointers(though in c# pointers are still present). This is all brought about though the use of a managed runtime. This is all great but the memory and cpu overhead it produces makes me want to cry.
I dont understand it, is it just because some people believe the average programmer is completly incompetant and cant be trusted with pointers and memory management? Or is it just the marketing departments of companys such as MS and Sun telling us to use these technologies?
|
There are a number of reasons for doing this. It makes programs easier to port across architectures, and allows programs to be backward compatible without littering the operating system with legacy cruft. I suspect the latter reason is one of the main reasons why Microsoft are pursuing it; they spend a huge amount of money trying to ensure backward compatibility, and virtual machines make that a lot easier.
The other reason is ease of use. Computers are used to do all the tedious mental tasks that we don't want to do. We use spreadsheets to add up changing columns of numbers rather than add them up by hand, and databases instead of filing cabinets to keep track of large amounts of data. Higher level languages are merely an extension of this ideal. Why should I have to worry about memory management, pointers and primitives when I can let my computer deal with it? If you think about it, letting computers handle memory management and other low level concepts is little different to letting computers compile code into executables, rather than writing the machine code ourselves. Sure, a clever assembly hacker might be able to write assembly more efficiently than a compiler could, but a compiler saves time, and allows us to write larger and more complicated programs than we otherwise could.
Abstraction is a trade off between efficient use of the programmer's time, and efficient use of the computers time. Computers double in speed about every two years, whilst humans do not. Thus, it would seem to me as if computers would be the more logical choice to deal with any efficiencies, rather than human programmers.