|
.NET linking ... why not hack mono
Here's a suggestion ...
If the linking problem bothers you so much, why not make use of what's already out there ... mono.
It's a .NET implementation. It's open source. All it needs is some enterprising developer to write the linker functionality, which many here consider pretty easy.
So get to it, and solve your own problem. You don't have to wait for Microsoft to do it for you.
Yes, I know that mono isn't 100% feature complete and bug free yet. However, if you start on the linker now, by the time you're done, it may well be. ;)
Sum Dum Gai
Thursday, January 29, 2004
Or, check out Rotor: http://hosca.com/rotor/index.html
Steve Jones (UK)
Thursday, January 29, 2004
Just a hunch but I think Joel would probably rather spend the time working on his own products than the .NET framework...
John Topley (www.johntopley.com)
Thursday, January 29, 2004
"Just a hunch but I think Joel would probably rather spend the time working on his own products than the .NET framework..."
Oh, so you're telling me that the decision on whether or not to do this might have to be a TRADEOFF?
Perhaps just like the decision on whether to get a quicker time to market by using .NET, or a greater convenience to your users who don't have the framework installed by making a win32 app?
Perhaps it's because development is about tradeoffs, and that's just one you have to make. Perhaps the decision to develop something without a linker is a tradeoff Microsoft had to make to allow them to do some of what they've done with .NET?
(PS: Thank you for providing the launching point I was hoping for when I posted the thread. Call it trolling or call it the Socratic method, I don't care).
Sum Dum Gai
Thursday, January 29, 2004
Always happy to oblige, however unwittingly or unknowingly.
John Topley (www.johntopley.com)
Thursday, January 29, 2004
Brings up an interesting point: Joel seems to be all for obsession over obscure details of things like MFC, and tolerating all sorts of wonderful pixies that are present in the Win32 API, but anything else... forget it.
Could it be that it is just that people are scared of the new and the challenges these new platforms are providing?
Mike Neale
Thursday, January 29, 2004
> Could it be that it is just that people are scared of the new and the challenges these new platforms are providing?
Yes. Challenges like having your app become dependent on policy decisions applied to .Net.
Thursday, January 29, 2004
New isn't necessarily better; Many (most?) "new" technologies aren't really new ideas, but rather new implementations of old ideas, and the new implementations usually suck, until -- and this can take many years -- they mature or die.
Those of us that have some experience hold on to proven technologies until new technologies prove themselves worthy.
Putting the hype aside for a second, there isn't anything you can do in .NET that you couldn't do with comparable ease in Java and/or Python. If your C# program is more than 10% shorter than the equivalent Java, you were using the wrong tools/libraries earlier. If it is shorter than the Python version at all, you were using Python wrong. Packinging a Python program as an indepedent app adds 1 Meg or so to your distribution. The standard python library is, perhaps, not as extensive is .NET's, but it _is_ extensive.
I'm long enough in the business to have a perspective, and landmark paradigm shifts (accompanied by good implementations) in software engineering are extremely rare. Some of them are not for the better.
Most of the difference between software engineering now and twenty years ago is evolution, that can be applied to just about every environment. (Yes, I have seen readable OO in Fortran-77).
New contenders (e.g., .NET now and Java in the past) try to consolidate this evolution into a 'natural' framework. Sometimes they succeed, and often enough they don't. Before I can trust the new shiny paradigm of the day, I want it to mature; Until then, I would mostly be helping MS/Sun test their new brainchild, and I have better things to do.
It's not black or white - I try to evaluate them in a small, controlled scope. Python, which I evaluated when it was still 0.9.4, exceeded my expectations. Java didn't. I haven't had a real in-depth look at .NET yet, but from what I know of it so far, I don't expect to be impressed.
I think in a year or two, .NET will be mature enough to have an in-depth look and evaluate what theories worked and what didn't; and what the benefits of using it really are.
Ori Berger
Thursday, January 29, 2004
screwing around with 'pixies' in MFC puts an inconvenience on Joel. having Joel's customers screw around with the .net runtime puts an inconvenience on Joel's customers.
There's two types of people in this world,
1. those who understand the issue with the above statements.
2. programmers.
:)
Hermaphrodite
Thursday, January 29, 2004
SourceGear has choosen to go this route for their Vault product (a VSS replacement which integrates with FogBugz btw)
http://lists.ximian.com/archives/public/mono-list/2003-June/014334.html
Jon Newton
Thursday, January 29, 2004
Actually, I think the problem is that Microsoft for some unknown reason didn't choose to include the framework in Windows XP or Office 2003, etc. They distribute more software than anyone and it doesn't seem like their doing their own part to distribute this thing that they want everyone to use.
If the framework were part of the OS, there wouldn't be any installing to do.
pdq
Thursday, January 29, 2004
"If the framework were part of the OS, there wouldn't be any installing to do. "
Yes, which begs the question: WHY didn't MS put the framework in the required Windows Update?
If it's good enough for OUR apps, shouldn't it be good enough for Windows?
I think the reason is simple: .net isn't fully baked yet. WE are the beta testers.
The real Entrepreneur
Thursday, January 29, 2004
Well put Hermaphrodite.
I couldn't have said it better myself, although I've been trying to for months now.
The real Entrepreneur
Thursday, January 29, 2004
If MS had bundeled .NET with everything but the kichen sink, they would have been sued once more for "providing decent technology in a market of incompetents".
Oh well, you get the picture.
Just me (Sir to you)
Thursday, January 29, 2004
Mike Neale:
I agree, and this is typical of most developers. The peculiarities of their preferred platform provide evidence of how learned they are in that platform. The peculiarities of other plateforms are evidence that those platforms suck.
I agree with Joel that this is a problem for downloadable "exe" type applications. I think these sorts of applications are increasingly rare. The apps that are becoming more common benefit from the sorts of things that .NET and Java are attempting to do.
name withheld out of cowardice
Thursday, January 29, 2004
Not that I've used it yet, but it seems like RemoteSoft has just the linker Joel is looking for:
http://www.remotesoft.com/linker/
Has anyone had any experience with this
jl
Thursday, January 29, 2004
In fact Joel would not need to hack anything in the Mono runtime to achieve this functionality. It is already there.
Have a look at http://www.ox.compsoc.net/~sheldon/files/assembly-bundle . This exists in the mono-cvs as mono/docs/assembly-bundle
David Sheldon
Thursday, February 5, 2004
 Recent Topics
Fog Creek Home
| 
