|
Yes Joel you May Have a Linker!
I've just read Joel's article from 28th Jan 'Please Sir May I Have a Linker' (OK I'm a slow reader). I'm moved to comment as I'm interested in language design issues and have long disliked the move to runtimes which IMO are not 100% reliable.
Joel, in a sense the answer has always been in front of you. As you know if you use C, C++ or Delphi you can produce statically linked EXEs which don't suffer runtime issues. In http://www.lingolanguage.com I've spent a lot of effort making sure runtime inconsistencies can never occur (OK Lingo uses some runtime DLLs but these are versioned by filename and checked at startup). In Lingo I would guarantee there can never be any versioning issues, irrespective of what version of Windows you're using, and irrespective of whether other versions of Lingo (earlier or later) have been installed on the same PC. There's nothing special about Lingo in this regard, you can do the same with any language supporting static linking.
I also read http://weblogs.asp.net/jasonz/archive/2004/01/31/65653.aspx (Jason Zander's reply). His main objection to a .NET linker is security but this is a red herring. Security issues do not reside in run time library code that gets linked in. Eg in C/C++ I can pass NULL as a dest pointer to strcpy() and crash the program (or possibly cause an 'exploit'). Although the crash is in strcpy() this is not a C runtime bug - the C runtime is doing what it should and the fault is mine for calling it wrongly. So I think security holes are fixed by patching the app source, recompiling and redistibuting the new compiled app.
The penalties of separate dynamically linked language runtimes are clear. There are VB issues with installing the correct versions of OCX controls. When I worked at IBM we had to write an installer that switched between two different versions of the Java runtime, since the app we wrote (AO Manager) had some Java code developed locally and some developed by IBM in India, and they used different versions. Now that PCs have 512MB main memory and 60GB+ hard disks I don't see static linking as an issue.
On a minor pedantic note I think Fortran came out around 1956 and I guess the first linkers would date from then. Being British I claim the first stored program computer was invented at Manchester University in 1949 so I think 1950 is too early for a linker.
Bill Rayer
Bill Rayer
Sunday, February 22, 2004
>> His main objection to a .NET linker is security but this is a red herring. Security issues do not reside in run time library code that gets linked in
Maybe I read that article too fast, but what I understood, is that they'd rather you call .Net API's so that when a bug is found by MS, it can be more easily patched the next time you upgrade the .Net framework.
OTOH, apps that just copy a sub-set of the .Net framework in their EXE statically will be left with the bug,with no way to force the developers who wrote those to grab the latest version of whatever .Net code they took,recompile, and send an update to all their customers.
Fred
Sunday, February 22, 2004
Quick nitpick, absolutely unrelated to the original post. Sorry, can't help it.
Even though (sadly) many programmers using a C++ compiler still use str*() for their string manipulation, and get burned for being irresponsible about buffer management, str*() aren't the C++ string manipulation routines.
std::string and std::vector<char> are great string systems, and don't suffer from the security ailments of str*(). C++ can give you as little or as much help in reliability as you want, although the default is ver little :-)
Ok, sorry to waste everyone's time...
H. Lally Singh
Sunday, February 22, 2004
It comes down to this:
There is probably at LEAST a 100:1 ratio of vertical business applications to horizontal customer applications (and I think I'm being generous here, personally). To design the system so that it best suits corporate apps instead of consumer apps is a no-brainer.
Sure, it bugs him, because he's in the 1% (or less). What I don't get is that Joel has a big brain, and has mentioned on at least one occasion: "consider the cost". How can be objectively look at this, and yet still bitch about it? As has been pointed out so often, he has a ton of other options, including options from Microsoft.
This topic (in general) really needs to die.
Brad Wilson (dotnetguy.techieswithcats.com)
Sunday, February 22, 2004
"There is probably at LEAST a 100:1 ratio of vertical business applications to horizontal customer applications "
What do you base this on?
(I think you may be right, but I'd like to know)
That would explain the sinking feeling I, as a *commercial* (shrinkwrap) software developer feel, of being tugged around by MS's development language choices. There's a simple reason:
Microsoft isn't focused on shrinkwrap sw development with .net. So they don't care about my needs or Joel's needs.
One more reason NOT to use .net for my programs.
The real Entrepreneur
Sunday, February 22, 2004
I have no hard stats, just time in the industry and a rough guess. I'm not sure there are hard stats.
Brad Wilson (dotnetguy.techieswithcats.com)
Sunday, February 22, 2004
Interesting. So basically Microsoft doesn't care about adding a linker to .NET because most of their customers (corporations) don't need one. And the ones that do (shrink-wrap programmers), are such a small part of Microsoft's customer base that it isn't worth their time to provide one. Additionally, it seems like MS might even have an incentive to make shrink-wrap programmers' jobs harder, because the shrink-wrappers may be working on an app that competes with one of MS's own desktop apps.
There's no reason to make your competition's jobs easier if you don't have to.
Chris
Monday, February 23, 2004
This is exactly right, of course... the REAL reason Microsoft doesn't want to provide a linker is that they have absolutely no incentive whatsoever to make life easier for horizontal or systems software developers who compete against Microsoft.
Joel Spolsky
Fog Creek Software
Monday, February 23, 2004
Buy 5 different, general software development magazines. Read them.
What is in them?
I tell you: Java, Java, Java, Java, Java, Java, Java, Java, Java, Java, Java, Java, Java, and a few other things.
The conclusion is simple: the market needs a Java-like system, and not a Delphi-like system.
Delphi is more powerful than Java in several points:
1. fast native code compiler makes code run a lot faster than Java (yes, I have tested this several times, it's true, the diference is huge)
2. true linker, single .EXE deployment
3. lots of excellent user interface components, light years ahead compared to the ones in Java
4. ready access to Windows API, you don't need to import functions, just call them
5. excellent IDE
Yet the market prefers Java. Why?
Because Java has ONE key advantage: Frameworks (EJB, etc) for enterprise applications.
Yes, Delphi has them too. But Borland was stupid enough not to market it properly - they didn't beat the drums hard enough, and they didn't focus on this.
So: the market requires dev environments which are targetted to large enterprise developers, PERIOD.
That's what Microsoft is trying to do with .NET, and I think they are progressing quite well.
It's amazing - it doesn't matter if a dev env is full of bugs, if the components are crappy, etc. All the market cares about is enterprise, enterprise, enterprise.
If your development environment has an enterprise framework, the market will adopt it like crazy.
That's my advice for the guy who makes Lingo: reorient the language towards the enterprise. Make lots of libraries for enterprise and database and web work, and make up some well-sounding names like EJB.
Every page of your manual, and of your web site, should mention the word enterprise, and should beat the drums about how your programming language can be used in the enterprise, how it will revolutionize the enterprise IT, how enterprises can save money.
Repeat this mantra every day:
enterprise ... enterprise architecture ...
hype makes enterprises purchase
enterprise architecture ... enterprise ...
ROI
enterprise enterprise enterprise
hype hype hype
for the enterprise architecture
.. and, with a bit of luck and hype, you shall succeed with your development environment beyond your wildest dreams.
MX
Monday, February 23, 2004
Well, Joel, that's a possible real reason, but perhaps a little harsh? (Or maybe not?). What if you look at it from "What does MS have to gain by helping shrinkwrap devs out?" How are they going to get more sales by having a program that runs .NET on Windows versus native Win32 code? They're going to push people there once Longhorn comes out, sure. But meanwhile, if you've invested tons of time writing Win32 specific code in any language, well, your customers are still going to buy Windows. Windows has it's own benefits and doesn't necesarily need .NET (for Windows dev). OTOH, Windows isn't as strong as it should be for server-side dev.
Michael Giagnocavo
Monday, February 23, 2004
I don't think it's harsh. I think it hits the nail right on the head.
Brad Wilson (dotnetguy.techieswithcats.com)
Monday, February 23, 2004
How do I run a win32 .exe (which is what the result of the linker will be) in a sandbox?
On Windows 98?
Just me (Sir to you)
Monday, February 23, 2004
Just me: A Win32 exe as output by a linker will run on any version of Windows released in the last 9 years (OK, except Win CE, and assuming proper API use).
Chris: "So basically Microsoft doesn't care about adding a linker to .NET because most of their customers (corporations) don't need one. And the ones that do (shrink-wrap programmers), are such a small part of Microsoft's customer base that it isn't worth their time to provide one." I agree 100% with this.
Microsoft's actions often don't make sense if you view them as being done to make software easier to use, but they do make sense if you view them as being done to ensure Microsoft's survival and growth. (hope that made sense).
So basically changes to Word, Windows, s/w dev tools etc are done more to keep us on our toes and keep us running, rather than to help us get jobs done. I view the bloating and increased complexity of s/w dev tools as an example of this. The move to complexity is making it impossible for new programmers to get started (there are ~400m people netted now and some % of them want to code). My work on Lingo is intended to reduce this complexity.
Anyway, I liked the linker article, altho I'm surpsised I got away with my claim to the UK having invented the first computer...
Bill Rayer
Monday, February 23, 2004
"A Win32 exe as output by a linker will run on any version of Windows released in the last 9 years "
Bill, I know, but I was refering to the sandboxing capabilities of .NET.
The control panels> Administrative tools> Microsoft .NET Framework configuration stuff.
Just me (Sir to you)
Monday, February 23, 2004
Shrink-wrap software produces do not see sandboxes as a benefit to their work.
MsgBox("Save failed because you have not enabled File Write permission for this application. Go to your UberSandbox Control Panel, click on File Permissions, paste in the GUID of this program, and check the box that says, 'Enable File Write permissions for this process.'");
UI nightmare I tell ya. There are places where Sandboxes and granular .NET assembly permissions make sense, like on a local Intranet or web-deployed applications, but those are not the areas screaming for a <= 8MB deployment package.
Richard P
Monday, February 23, 2004
Brad, so you're saying that Microsoft makes Windows hard to develop for so that no one can write software for it? Wouldn't it make more sense to make most of the Win32 API private then? I don't see why they'd spend money on making cool things like Whidbey's Win Forms, XAML, etc. if they are afraid of others using it.
Michael Giagnocavo
Monday, February 23, 2004
Michael,
There is a massive difference between deliberately hindering your competition and not going out of your way to help them.
Ged Byrne
Tuesday, February 24, 2004
But what's being suggested is that MSFT is refusing to make a linker (even though they admit it'd be easy to do). That's deliberate, not "going of of their way".
Michael Giagnocavo
Tuesday, February 24, 2004
 Recent Topics
Fog Creek Home
|
