I love assembly. It was the language I really started to know what the computer was doing. The problem was asm is not being used extensively in business section and many other portions in developent. Same goes with C, the Unix kernel uses assembly and C. Peter was right to state that each language has their own strengths. Imagine that the program you are maintaining is HTML or written in Java. You just have to use back the same technology to get it working. Again, if the senario was written in C, you could use assembly to rewrite portions of it BUT the developer would miss out the reusability of the current code. I personally do encourage all sort of languages for any dev. work but it has to be within reason. Can the rest of your team read your code? John --- Peter Bindels wrote: > On 01/07/07, Gerhard Fiedler > wrote: > > wouter van ooijen wrote: > > > > >> I think Peter's point is that if you use a > compiler in such an > > >> environment, you better make sure that what you > need is explicitly > > >> specified as reentrant. > > > > > > That is essentially a strawman argument: bad > implementations exist (or > > > could exist), so the language feature is bad. > > > > I don't think it's necessarily a strawman > argument. It's difficult to get > > anything guaranteed by any software vendors these > days; most things are > > specified as "it's working unless it doesn't" :) > The more complex a > > language is, the more difficult is it to make sure > for yourself, and the > > more complex it may be to find out when something > doesn't work as specified > > (which actually happens occasionally :). > > > > IMO this is one of the reasons why C has been > around for so long in the > > area of small embedded systems: it's a workable > compromise. (Which is not > > to say that other such compromises, and better > ones for many situations, > > exist.) > > The sole reason why C is abundant in embedded > systems programming is > because C was abundant in embedded systems > programming. Did you ever > try to convince somebody to NOT do the tread path > and to try something > new? You should try - it gives you a whole new > perspective on why > Windows is used everywhere, why people keep using C > for embedded > systems and why people keep driving SUV's. The main > answer is the > Prisoners Dilemma, which (in short) says that you > have to do > everything that you could do to gain an advantage, > and if you do > something different you most likely have a > disadvantage. > > People use C because they have code in C, people > don't switch to > Pascal because of their C code base. The only > difference would be in > startups - and notably startups have a high failure > rate that isn't > related to the language. Which leads to statistics > showing that using > C gives your project a low chance of failure (in a > noncausal relation) > causing all managers to flock to C. Again. > > As I've been sure of for 20 years (and given my age, > that's an awful > long time for me) people use what's known to work > and if you're the > one that produces what's known to work you only have > to make your > application sufficient. If people accept 10 crashes > per day - so be > it. The entire concept of brands and product lines > never appealed to > me but unfortunately I appear to be a strong > minority in that. I'm for > change if I see the results being better than > before, even if I'm not > sure that the results will be better. > > Apologies for the rant. > > Regards, > Peter > -- > http://www.piclist.com PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist > ____________________________________________________________________________________ Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist