Slashdot Mirror


Why Doesn't .NET Include a Linker?

CrypticSpawn asks: "I read an article on Joel on Software it talks about Microsoft missing one important thing from the .NET infrastructure, and I wanted to know what Slashdot readers thought were Microsoft's reasons for leaving [a linker] out?"

2 of 113 comments (clear)

  1. silly objection, and- you can get a linker! by RevAaron · · Score: 4, Interesting

    where is the surprise in this?

    first of all, you can get a linker for .NET if you want. like similar tools for perl and python, it packages everything up that you need into one exe. this took 10 seconds to find via google. Perhaps Joel should try google next time. What is this, ask slashdot? :)

    there is nothing different about the way .NET does this and any other system. Sure, there isn't a way to link it all into one .exe file, but that may come in the future. that is, in perl and python (among others) that was the case at first- you had to download a big runtime and possibly other libraries to get your app working. these days, you can distribute your app in that way- a 20KB download of your .pl files,or a big-ass executable that integrates all the requisite libraries, VM/runtime system, etc etc. however, this often ends up giving you a file that it almost as big, but at least, it is a little simpler on the user.

    again, Java does this too. If i have a .class file or jar, there isn't some way to encapsulate it all into one double-clickable executable file that I can share. I have to have my users download a big package, the other libraries, and then my app. .NET is no different, and there is no reason to expect it to be. joel gripes, saying that microsoft will come out with a new version every few months. just like with new versions of perl, python or java, there is no reason that the user would neccesarily have to have the brand-spankinest newest version. if your app requires it, you make it a requirement. put it on the CD, and say- install this if you don't have it yet. big deal. if you were smart, you'd write your apps against the most common verison- .NET 1.0 or 1.1 for now, just like a lot of Java apps are still written for Java 1.1, not even Java 2! Most folks don't write apps for the newest Java, 1.4.x unless they really need it.

    what the hell is so different about how .NET does it?

    --

    Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
  2. wow, what planet is that guy from? by ajagci · · Score: 4, Interesting

    For some reason, Microsoft's brilliant and cutting-edge .NET

    Actually, .NET is neither "brilliant" nor "cutting-edge"--it's a modest evolution from Java, which is itself 1970's technology.

    The tool in question? A linker. Here's what a linker does. It combines the compiled version of your program with the compiled versions of all the library functions that your program uses. [...] Instead, .NET has this idea of a "runtime" ... a big 22 MB steaming heap of code that is linked dynamically and which everybody has to have on their computers before they can use .NET applications.

    Well, that's roughly like saying that automobiles leave out the horses and the whip. The whole point of .NET and Java is to run inside a runtime, a runtime that provides garbage collection, dynamic typing, and just-in-time compilation.

    Runtimes are a problem, much like DLLs, because you can get into trouble when application version 1 was designed to work with runtime version 1, and then runtime version 2 comes out, and suddenly application version 1 doesn't work right for some unpredictable reason.

    Well, duh. So, I guess operating systems are a problem, too.

    We solve that sort of thing by having standards and sticking to them. Oh, I forget, besides being rather confused about software in general, Spolsky also actually seems to like Microsoft Windows, so the notion of "standards" and "compatibility" must be rather foreign to him. .NET and Java do have serious design problems. Foremost, safe runtimes like that should run all applications on a machine in a single address space. Then, you can get rid of a lot of useless machinery for inter-process communication, and the overhead gets amortized over dozens of programs. Again, old stuff. But Spolsky's criticism is just missing the point completely.