Sounds about like I expected

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

Welcome to IWETHEY!