Good link on .NET

Post #28,326 by ben_tilly 2/14/02 4:12:13 AM Reply	Good link on .NET There is a good link at [link\|http://arstechnica.com/paedia/n/net/net-1.html\|arstechnia]. Having gone through it I now understand what several references I have seen to "managed code" stand for, and I have a much better understanding on the overall .NET architecture. I also am, no surprise, left with the opinion that it doesn't measure up to the hype. Yes, you can run any language you want in it. If they are going to share the nice features, then they need to basically look like the language that .NET was written for. So sorry if you think that dynamic typing, multiple inheritance, or a class library different that the one that Microsoft gives you is desirable. And I am left disagreeing with Miguel on security. Yes, their security model is better than what they had before. But it isn't very good. For instance it does not support selected revocation of privileges. If you want to execute untrusted code in some sort of partial sandbox you are not going to be able to do it within .NET. If you can do it it will be through some mechanism like using .COM for a trusted .NET session to talk with an untrusted one. Which, of course, raises the million dollar question. How will the .NET security model interact with COM? It doesn't matter how good .NET's model is in theory, if in practice .NET winds up calling out to COM freely to interact with components, and COM has a different security design, then there will be a stream of holes in practice along the boundary between the two. Given that is where Microsoft has lots of its problems now, I am dubious that .NET will wind up with a good security track record. Finally I have been left uncomforted with the Mono project's exposure to intellectual property problems. From the looks of it, most of the interesting stuff in .NET is buried away in the forms and class libraries. Most of the useful parts of that aren't going into any standards. What is to keep Microsoft from taking out some patents on key spots in there and holding that in reserve? Oh. Right. Cheers, Ben
Post #28,343 by CRConrad 2/14/02 9:18:17 AM 2/14/02 9:19:06 AM Reply	Just confirms it-who couldn't figure as much 1 or 2 yrs ago? [I meant "one or two", not "one half" -- CRC.] Edited by CRConrad Feb. 14, 2002, 09:19:06 AM EST Expand All History
Post #28,349 by admin 2/14/02 9:41:20 AM 2/14/02 9:43:24 AM Reply	Stack-based security The runtime will check the permissions granted at each point on the stack, and move up the stack until either it finds the permission \ufffd at which point the code will be allowed to continue \ufffd or until it reaches the top of the stack, at which point an exception will be thrown. Now, this is very strange to me. I've written stack-based security systems for MUDs before, and they always behaved exactly opposite to this; ie., every object in the call stack had to have permission to perform the operation (unless explicitly marked bypass, as in the case of a trusted daemon making a write to a secure log file). With Microsoft's system, you just have to somehow get your code called by a trusted component, and away you go. The permissions will be in the call stack, and you'll have free reign. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..." Edited by admin Feb. 14, 2002, 09:43:24 AM EST Expand All History
Post #28,394 by bluke 2/14/02 3:10:00 PM Reply	A different .NET link, makes me sick [link\|http://www.salon.com/tech/feature/2002/02/14/dot_net/index.html\|All hail .Net!] "Microsoft's new software development tools are more than just nifty -- they are a great boon to humanity. ... Visual Studio.Net is going to change the world -- no doubt about it -- so it's time to suck it up and jump on the bandwagon." I thought for sure that the writer was being sarcastic, but lo and behold he really believes this crap. The best line of all is this: "The prime example of this is Microsoft's Passport service. Developers can treat Passport as an object in their code and instantly make use of a thoroughly tested and validated service that works just fine with 160 million user accounts around the globe." Anyone who thinks Passport is thouroughly tested and validated is living in another world.
Post #28,408 by ben_tilly 2/14/02 6:01:24 PM Reply	Some get to be sharks... Most get to be chum. Cheers, Ben
Post #28,450 by wharris2 2/15/02 4:13:01 AM Reply	Blink blink ".NET marks the dawn of the third age of computing"... holy cow, he's not just regurgitating canned Microsoft pap, he's enthusing over it. Most of the work of government does not need to be done. - Attributed to Ronald Reagan, under whose administration the government expanded, of course.
Post #28,512 by CRConrad 2/15/02 12:52:27 PM Reply	Dunno if he really believes it, but he has a reason to gush BLuke is surprised: I thought for sure that the writer was being sarcastic, but lo and behold he really believes this crap. Yeah, well... from the [link\|http://www.salon.com/tech/feature/2002/02/14/dot_net/index2.html\|last page] of the article: About the writer Peter Wright is a software consultant and the author of numerous books on Visual Basic programming. He is currently working on two .Net titles for Apress slated for release later this year. He wants it to succeed, so he can sell books and consulting services. Christian R. Conrad Of course, who am I to point fingers? I'm in the "Information Technology" business, prima facia evidence that there's bats in the bell tower. -- [link\|http://z.iwethey.org/forums/render/content/show?contentid=27764\|Andrew Grygus]
Post #28,395 by tuberculosis 2/14/02 3:10:31 PM Reply	.NET Visual Studio Preview was going on last night at the Metreon. Huge crowd of geeks (I passed thru to get a bite after a little drinking on the boss). Long lines. But not DisneyLand. The average hunter gatherer works 20 hours a week. The average farmer works 40 hours a week. The average programmer works 60 hours a week. What the hell are we thinking?
Post #28,514 by CRConrad 2/15/02 1:01:10 PM Reply	...has at least one security-related compiler bug already See: [link\|http://www.wired.com/news/print/0,1294,50438,00.html\|Hey Bill, Not So Trustworthy] ([link\|http://www.wired.com/news/print/0,1294,50438,00.html\|http://www.wired.co...0438,00.html]). So much for the "thouroughly tested and validated" Passport... No good if you can't call it from an otherwise secure program, is it? Christian R. Conrad Of course, who am I to point fingers? I'm in the "Information Technology" business, prima facia evidence that there's bats in the bell tower. -- [link\|http://z.iwethey.org/forums/render/content/show?contentid=27764\|Andrew Grygus]
Post #28,425 by tonytib 2/14/02 9:55:36 PM Reply	Sounds about like I expected Although better than the JVM, there's still a LCD (lowest common denominator) effect with the CLR: "you can program in any language you want, as long as it looks like C#". Well, I'm exaggerating a little, but the article and your comments reinforce my feeling that you lose a lot by going to the CLR, that there are better ways (at least for some applications) of linking languages -- plus the author doesn't mention the downside of going overboard with different languages in the same project. Because of issue you mention + .NET's method of stack checking permissions, I suspect .NET will be quite insecure. The versioning for shared Assemblies could eliminate DLL hell -- but it sure doesn't accomplish the original purpose of DLL's (sharing code). Good thing for MS that hard drives and memory are so cheap. The Linux SO approach has its advantages. Side note for Ben: FORTH has been implemented on the ADSP21xx DSP's. It looks like it's the only choice besides assembly and C. There is an active Silicon Valley Forth Interest Group, so I have a local source. Ficl (FORTH inspired command language), which is designed to be an embedded language (like Lua) and interface well with C, is interesting, but I suspect it may be too large (>50K). BTW, what I'm looking for is a language that runs in something like 4K program and 4K data memory, since the DSP can address 16K x 24 program and 16K x 16 data directly (although 512K flash program and 8M DRAM data is available indirectly). The language also needs to interface with C, since I will be using an existing, large C library. Tony
Post #28,437 by ben_tilly 2/14/02 11:34:07 PM 2/15/02 8:15:35 AM Reply	Something nasty that I just realized (oops, I was wrong) Content left only so people can understand discussion below. There are quite a few interesting flaws in this design. Here are some of them. First of all why patches and .NET are going to be fscking huge. Suppose that you have a bug in a library. So you fix it. Every module that loads the library needs to be relinked, so you recompile. Everything that links to that also needs relinking. When you are done, how big is your patch? There is a possible major portability gotcha when you have digitally signed code that needs to call out to native code, and on different platforms needs to call out differently. That means different versions, that anything which links to is going to only link to one of, which means that anything anywhere that calls out to native code is going to be platform specific...? OK, we will assume they are not that obvious about it. But still we have a nasty portability trap like this: You write a module that calls out to native code. It gets used by a bunch of people. You want it to become cross-platform. So you make whatever modifications you need to be able to link to native code on multiple platforms. Now everyone who uses your code needs to recompile so that they link to the portable version of your code. Everyone who links to them has to do likewise. Does anyone believe that will happen routinely on a large number of platforms? (Particularly minority platforms like Linux or FreeBSD? Particularly when key components have been written by people who are enough sold on the Microsoft bandwagon to have lept into .NET early?) You know, for a platform that barely runs in 512 MB of RAM, at a time when Microsoft has not really tackled how they are going to do the big 32 to 64 bit conversion, it might not be a smart idea to shoot themselves in the foot like this. And if they intend to get into foot-shooting, it might not be a good idea to join in this endeavour... And this is what Miguel thinks is the greatest thing to hit programming since sliced bread??? Cheers, Ben Edited by ben_tilly Feb. 15, 2002, 08:15:35 AM EST Expand All History
Post #28,441 by a6l6e6x 2/15/02 1:06:55 AM Reply	Not sure you are right about the linking part. If I read it right, they are still using dynamic linking. So, if a module's Interfaces (input and output parameters) have not changed, the module that needs fixing can simply be replaced. So while it is technically a new version of the module, it can be accepted as a revised version of the original. Your hairball scenario takes hold when these interfaces do change. Then, the changed module becomes a significantly different version of the module. The modules that need to call the new version must also be re-issued in new versions, etc. The caller modules that don't need the change could remain untouched and continue to call the old version of the module. Some of the memory savings that the DLL scheme has would evaporate, but it would still work. In the case that a given module requires interface changes in a module that it calls, both the caller and the called module modules would need to be re-issued in a new versions. Depending on the nature of the problem, this may also develop into a hairball scenario. But, it need not necessarily. It boils down to being damned sure you've got the interfaces right the first time. Alex "Of course, you realize this means war." -B. Bunny
Post #28,451 by wharris2 2/15/02 4:17:26 AM Reply	Getting interfaces right It boils down to being damned sure you've got the interfaces right the first time. And Microsoft has such a good record of doing that... oh, but forgive me, they also have such a great record of actually publishing their interfaces... Theoretically, OLE/COM modules have built-in versioning, too, but that doesn't stop them from crackling all over every time Microsoft does a system update. Most of the work of government does not need to be done. - Attributed to Ronald Reagan, under whose administration the government expanded, of course.
Post #28,571 by a6l6e6x 2/15/02 8:40:44 PM Reply	When you're innovating at internet speed,... publishing interfaces would only confuse the developers. Where is that sign, again? :) Alex "Of course, you realize this means war." -B. Bunny
Post #28,582 by wharris2 2/15/02 11:25:26 PM Reply	I know the sign, and I endorse it :=) Where each demon is slain, more hate is raised, yet hate unchecked also multiplies. - L. E. Modesitt, from his Recluse series
Post #28,460 by ben_tilly 2/15/02 8:14:49 AM Reply	D'oh I had misread [link\|http://arstechnica.com/paedia/n/net/net-2.html\|page 2]. I had thought that they just used a hash to sign the file so that any change to the file broke linking. They don't. Instead they cryptographically sign the hash value. Only with access to the private key can you produce a new file which will link with the old. So they can make reasonable patches. It does raise questions about key management though. Cheers, Ben
Post #28,439 by a6l6e6x 2/15/02 12:00:57 AM Reply	Re: Side note for Ben Tony, the "language that runs in something like 4K program and 4K data memory" is called assembler code! :) I'm assuming there is one for the DSP in question. Actually, if you don't use functions like printf C can get you pretty close to assembler sized code. General purpose functions like that are incredible memory hogs. Alex "Of course, you realize this means war." -B. Bunny
Post #28,440 by tonytib 2/15/02 12:47:26 AM Reply	You have to understand the context The dev tools I'm getting include assembler and C compiler, along with a simple OS and a good sized application specific (imaging) library. But there are a lot of advantages to combining assembly and C with a scripting language. It's a lot more flexible. So, if I can do it, I will. The only current language that might work for the ADSP21xx DSP seems to be FORTH (and at least two different people have ported FORTH to these chips). The other alternatives are to roll my own (something I'd prefer not to do) or give up. Tony
Post #28,627 by static 2/16/02 5:44:20 AM Reply	I would miss dynamic typing. That's one the features I most like in modern languages like Icon and PHP. Wade. "All around me are nothing but fakes Come with me on the biggest fake of all!"
Post #28,645 by ben_tilly 2/16/02 11:08:12 AM Reply	Take your pick Which do you prefer. Dynamic typing. Or the ability to have multiple versions of the same library loaded at the same time without any conflict? That is why they made the decision that they did. OK, I understand that. I just think it is complete marketing BS to then claim that they are language agnostic. Cheers, Ben
Post #28,883 by static 2/19/02 12:25:30 AM Reply	Please, sir... Noted about the language agnostic rubbish. :-) But I don't understand why not supporting dynamic typing prevents the version management they want. Wade. "All around me are nothing but fakes Come with me on the biggest fake of all!"
Post #28,887 by ben_tilly 2/19/02 2:50:14 AM Reply	Very simple With static typing you figure out at compile time what versions of everything you will call. That makes it easy to not get confused about different versions. With dynamic typing you need to make the decision at runtime. This quickly gets impossible. Consider the following case. A loads B which loads C. A also loads B' which loads C'. A method in A is then called which will call a constructor which might resolve to C or C'. With static typing you can be required to give enough information up front that the ambiguity can never arise. With dynamic typing you can't predict ahead of time that it won't arise, and what is a good resolution if it does? Cheers, Ben
Post #28,909 by Arkadiy 2/19/02 10:02:52 AM Reply	Versions peresnt during packaging? Could we just assume that versions present when the package was created are the ones we need? A bit of a hack, but would work, I think.
Post #28,927 by ben_tilly 2/19/02 11:43:41 AM Reply	No With static typing you have to declare types at compile time from ones you have available to you. No ambiguity is possible. With dynamic typing at compile time you may have multiple versions of the same library and no way to know that a given module will ever call that library. This is ambiguity that cannot be detected then, and cannot be adequately resolved at runtime. Oh, you can declare a rule for resolving it, such as "last one linked wins". But now if someone you link later decides to link in your library, you get hosed. This is dll hell sneaking back in the back door. Cheers, Ben
Post #28,932 by neelk 2/19/02 12:11:24 PM Reply	To do library versioning dynamically... ...you need a feature called selector namespaces. Dave Simmons' Smallscript language has had them for a few years, but it's being added to the new Javascript 2.0 standard as well. You can find Waldemar Horwat's LL1 presentation on it at: [link\|http://ll1.mit.edu/horwat.ppt\|[link\|http://ll1.mit.edu/horwat.ppt\|http://ll1.mit.edu/horwat.ppt]] Here's the rationale from the JS 2.0 spec: [link\|http://www.mozilla.org/js/language/js20/rationale/versioning.html\|[link\|http://www.mozilla.org/js/language/js20/rationale/versioning.html\|http://www.mozilla....sioning.html]] Incidentally, I met Waldemar Horwat, and discovered how he is managing the Javascript standardization effort. He wrote a formal semantics for JS, and then wrote a program that uses the semantics as an interpreter. Then, whenever someone requests a new feature, he adds it and reports the problems and inconsistencies it causes. Apparently this quells a lot of the bogus feature-creep pressure. This is the most cynically pragmatic use of formal methods I've ever seen, and is IMO totally brilliant. :) (He also automatically generates the standard from the formal semantics, too!) I think Javascript 2.0 stands a very good chance of becoming a language I can actually respect -- the people designing it are doing an excellent job so far. It's more complex than I like, but still remarkably clean.
Post #29,035 by ben_tilly 2/20/02 6:54:05 AM Reply	Huh, interesting That approach does help. I don't think it is usable for what .NET wants to do, but it is an interesting approach. Why not usable? Well two cases. The first is that library authors sometimes make backwards incompatible changes. A functions behaviour changes from one release to the next. Now just knowing that you have only the right functions is not enough, you also want to be sure you have the right implementation. (I think this is a freedom which, once it is available, many library authors will want to take advantage of.) The second case is more extreme. .NET will protect you against the situation where two people independently decided to write CoolModule and they independently created functions with the same names (like new) that do somewhat different things. Now no amount of internal management within the module will get things right since the authors cannot (not knowing of each other) cooperate. For their goal, I think that .NET made the only reasonable technical decision. I am ambivalent about the goal, and hostile to their mismarketing of the result, but I don't see a better answer within that framework. Cheers, Ben
Post #29,018 by static 2/20/02 12:32:47 AM Reply	Yes, it makes sense now. I'd forgotten the object-oriented approach C# requires (strike another for language agnosticism? :-). Thank you. Wade. "All around me are nothing but fakes Come with me on the biggest fake of all!"
Post #30,432 by tablizer 3/1/02 11:15:38 PM Reply	Specify prefered libraries up front >> Consider the following case. A loads B which loads C. A also loads B' which loads C'. A method in A is then called which will call a constructor which might resolve to C or C'. With static typing you can be required to give enough information up front that the ambiguity can never arise. With dynamic typing you can't predict ahead of time .... << What about declaring the prefered libraries up front? If it needs a library not on the list, then it either requests it, like web plug-ins, or fails (depending upon configuration). The library list could also specify priorities by either its position in the list, or a "rank" field. If a specific thing needs a specific library version, then it can specifically request that one. If the specific version is not available, then perhaps it could try to use any newer version around (or fail depending on configuration). Static typing could face similar issues if the prefered library is not around. The developer should have the choice of it using an alternative rather than completely fail. Whether this feature is practical may depend on the environment. A lone user in Alaska may need more options than the cubicle next store. I too have grown to like dynamic typing (or no typing even). The code is more to-the-point than under static typing IMO. You see more business logic and less formality nitty gritty. ________________ oop.ismad.com

Welcome to IWETHEY!