From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 5b1e799cdb,3ef3e78eacf6f938 X-Google-Attributes: gid5b1e799cdb,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news4.google.com!feeder.news-service.com!de-l.enfer-du-nord.net!gegeweb.org!aioe.org!not-for-mail From: Oxide Scrubber Newsgroups: comp.lang.scheme,comp.lang.ada,comp.lang.c++,comp.programming Subject: Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3? Followup-To: comp.lang.java.programmer Date: Wed, 29 Jul 2009 13:02:10 -0400 Organization: Aioe.org NNTP Server Message-ID: References: <2009a75f-63e7-485e-9d9f-955e456578ed@v37g2000prg.googlegroups.com> NNTP-Posting-Host: UPADzacy6hUmpG8kCE4xzg.user.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org X-Antivirus-Status: Clean X-Notice: Filtered by postfilter v. 0.7.9 X-Antivirus: avast! (VPS 090728-0, 28/07/2009), Outbound message Cancel-Lock: sha1:ALWsAh+6nT2zPJNjXcoBdsp8hJM= User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) Xref: g2news2.google.com comp.lang.scheme:6161 comp.lang.ada:7414 comp.lang.c++:48538 comp.programming:12120 Date: 2009-07-29T13:02:10-04:00 List-Id: learn2code@yourdesk.com wrote: > ["Followup-To:" header set to comp.lang.ada.] Sorry, no can do. You post tripe to four newsgroups, you get corrected in four newsgroups. > On 2009-07-29, Oxide Scrubber wrote: >> learn2code@yourdesk.com wrote: >>> ["Followup-To:" header set to comp.lang.ada.] >> Sorry, no can do. You write complete nonsense in four newsgroups, you >> get corrected in four newsgroups. > > Same to you. But I don't write nonsense, unlike you. > Besides, I was just responding to the silly post, if he hadn't > splattered his goo all over usenet my response would have been in one group > as well. Ray Blaak's post did not strike me as either "silly" or "goo". >>> On 2009-07-29, Ray Blaak wrote: >>>> fft1976 writes: >>>> My problem with it is the lack of a garbage collection. That is just not >>>> acceptable to me these days. If you manually allocate memory, then you >>>> pretty much have memory bugs, it's as simple as that. >>> That is simply not true. If you don't know how to do resource management >>> properly, you're not ready to write commercial code in any environment. >> What utter balderdash. You make GC sound like training wheels > > Exactly what it is Bull. >> when in fact it is very useful even for major production-code systems. > > No, it's not useful Ridiculous. > I work on large systems and we write all our code in assembler. Then may God have mercy on your soul. > Simple is good for performance, for readability, and for just about > everything else. Assembly is good for ought but performance. For readability? Ludicrous. > I would hate to see the "major production-code system" that relied on GC. Well too bad, because there's more and more of them every day and some such confrontation is inevitable, probably the next time you use a web server since so many of them use JSP or other JVM-based technologies. > I can tell you this with certainty, no bank, insurance company, airline, or > any other online realtime operation uses such nonsense. Folderol. Lots of these use Java on their web sites. > Of course they have some bits here and there written in C++ but the code > that keeps them online and serving customers is written in COBOL, assembler > or Ada Rubbish. Dollars to doughnuts they all use ten times as much Java as Ada. > That's production. No, that's hokum, directly out of your very own fertile imagination. > If you're talking about academic (know-nothing) or hobbyist languages I can > understand how GC would be a virtue along with all the other mind-numbing > "improvements" made over the years. GC is hardly restricted to "academic or hobbyist languages". Java, for one, is neither. There are also practical uses for Lisp and, though it's really *not* a very good idea, technically for C# also. >> Consider memory management of an object that is shared and passed around >> at need among many related parts of a program. Keeping track of when >> it's no longer in use rapidly becomes nontrivial as the complexity of >> the code using it goes up. Eventually, you'll be reference counting or >> doing something else like that, and before long, you'll end up with an >> ad-hoc, informally specified, slow, bug-ridden implementation of half of >> a garbage collector. (This will probably in turn be a part of an ad-hoc, >> informally specified, slow, bug-ridden implementation of half of Common >> Lisp.) > > This is how most uninformed people deal with fundamental lack of knowledge > and discipline in the design and coding of systems of any significant size > and scope. They just go from bad to worse by using spit and bailing wire > instead of understanding the issues and avoiding fundamentally incorrect and > inappropriate practices and language implementations. Know your tools and > you can avoid these problems entirely. The "spit and bailing wire" would be destructors, auto_ptr, roll-your-own reference counted pointers, and so forth, of course. > Reference counting and other such silly schemes are as much rubber crutches > as GC. There are significant applications that cannot be developed without one of: 1. Reference counting. 2. GC. 3. Memory leaks. Smart programmers avoid #3, and really smart ones avoid #1 as well, since it copes poorly with circular data structures. :) > All of the need for this sort of rubbish is based on the basic > inability to design and implement properly. Nonsense. > If you would just have control and understand your platform, all of these > problems would go away. BS. >> Why not save yourself the trouble and use a real GC, then? Especially >> since a properly-used GC will actually improve execution speed. > > Because we have never needed them. Speak for yourself. > And nobody else does unless they want to strap themselves into Java or > other bloated run-time systems, as I said. Yes, you did say that, along with quite a lot of other tripe. > Traditional compiled languages have no need for GC. Utter crap. Common Lisp is a glaring counterexample; often compiled to native code. >>> Garbage collection is a throwback to interpreted languages and bloated >>> run-time systems. >> Poppycock. > > And then you go on to give examples of interpreted languages with bloated > runtimes like Lisp, Smalltalk, Clojure, etc. Codswallop. 1. All of those tend to be bytecode-compiled. I'm unaware of any Smalltalk dialect that's interpreted, and the only implementation of Clojure thus far also compiles to bytecode. And then, via JIT, to native code. Many Lisps are directly compiled to native code. 2. The "bloated runtimes" you speak of are a result of having a large, featureful standard library and using much of it, instead of the impoverished, miserable excuse for one that C/C++ comes with. (What, no graphics? Sound? Networking? Threads? Memory-mapped file I/O? Oh, come ON! You can't even write a portable C++ app with a real user interface FFS.) This has nothing whatsoever to do with either GC or compiled vs. interpreted. 3. Some of the most bloated apps it's ever been my displeasure to audit via top and ps were written in C++. DESPITE C++'s lack of a really featureful standard library. > We don't get fooled by VMs, they're still interpreters. What a silly thing to say. > Compiled code runs on bare metal with no runtime. That's the distinction. Bunkum. If that were true, then the only "compiled code" in existence would be operating system kernels. Which are often written in assembly, NOT compiled. Yeesh. >>> Normal compiled languages get along very well without any such thing >>> at all. >> Many implementations of Common Lisp are compiled. All have GCs. Are none >> of them "normal" compiled languages? > > No, they're still based on run-time systems and have fundamental flaws that > create the need for GC. Bullshit. Name one such "fundamental flaw". > At any rate, they're not used in large systems and not where performance > is essential. Horsefeathers. Lisp has been used in a lot of performance-requiring applications, including on NASA fucking space probes. Ever heard of "Deep Space 1"? As for "large systems", some very large ecommerce companies have used Lisp to implement very large databases or web apps. Java is used even more in such situations (excluding NASA probes). > I don't have any interest in those sorts of applications. Academic > computing is only interesting to academics. Large order-fulfillment systems are "academic computing" to you? Then you truly are lost. > I work on code that has to work and has to perform. As do I. > None of the languages you mention will do for any serious sort of work. Balderdash. >>> You need to understand your tools and not rely on the rubber crutches >>> overglorified scripting platforms like Java have taught people to put >>> blind faith in. What ever happened to competent coders? >> They've all seen C++ for the unholy mess it is > > On this we agree! > >> and migrated to languages like Java, Scala, and Clojure that let you get >> something done without worrying about micromanaging memory? > > Memory and resource management generally are fundamental aspects of software > engineering discipline. True. Although a little automation can go a long way, as it can in many areas of endeavor. > Java is not a language, it's a scripting platform Ludicrous. > I think you ought to have total control over what you're writing and how > it works Then you should not be posting anywhere but comp.lang.asm.*. >> Now if only we could stop worrying about streams and window handles and >> other such nonsense too and have the computer automation take care of >> those sorts of niggling details too, as is the computer's job. :) > > That's a fundamental point of disagreement. I would not be surprised if you disagreed with me if I said the Klein 4-group was abelian, so you'll pardon me if I don't consider your statement here to be very informative or meaningful. :) > I don't want anything done for me. Fine. But not every programmer feels as you do. > I'll tell the machine what to do, and that's what I want. The father > you get from your hardware, the less efficient your executable Poppycock. I've got Clojure code right here that takes arithmetic expressions, massages them in various ways, compiles up some Java byte code, lets the Hotspot server JIT have at it, and winds up running at the same speed as hand-tuned assembly. Except that it can cobble this stuff up on the fly from Lisp s-expressions constructed or obtained at run-time. Try doing THAT with actual assembly. Clojure sits on Java, sits on JVM bytecode, sits on C/C++ implementation of JVM, sits on assembly, sits on x86 bare metal yet can do something as efficiently as assembly -- self-modifying machine code even -- and yet do so much more safely and from the comfort of a high level language with garbage collection. You lost this fight the instant you picked it, because you are, quite simply, dead wrong. > the less control you have A properly designed HLL provides ways to gain back some control if need be. Java has WeakReference, finalizers, and other means to gain back some from the GC when necessary (which is rarely). It has JNI and JIT for when you need assembly's speed or to interface to C libraries. Lisps tend to have some form of foreign function interface (Clojure can easily call Java code, so Java foreign functions are easy there; indirectly it can call C foreign functions via Java code that uses JNI.) > and the more protection from yourself you need. Ridiculous. You need "more protection from yourself" when you're doing raw pointer arithmetic and unchecked casts and crap like that. In other words, C and assembly. And that's when you have the least protection. > I don't want anybody to blame but myself. Well, then you'll just have to go into the woods, use some vines and sticks to make a crude shovel, dig up some dirt, make a fire, somehow manage to forge silicon chips in the dirt, mine other materials with your bare hands, slap together a ZX Spectrum kit or something from all this, assemble it, and start toggling in an operating system and compiler one opcode at a time. Most of us prefer to use the fruits of industrial civilization, even though sometimes that means getting hit by other peoples' bugs. *shrug* > If you don't agree, then why stop there? Just write application and code > generators and be done with it. Be sure to let me know when they've solved strong AI, and then I'll do that. >> Funnily enough, it's similar to Java notation. > > That's not by accident Whoosh! >> Of course, you might find CLOS notation worse -- all those >> parentheses. Smalltalk too -- no actual monolithic class file, just >> individual methods browsable from a list, and possibly mixed in with >> methods of other classes when dumped to a file. C# is like Java, with >> some funky extras. Am I missing any? Oh, yeah, Modula 3. And don't get >> me started started on Objective C... > > The pattern seems to be that OO implementations are necessarily inefficient > compared to their predecessors Piffle. > and as a result of a few years of relying on their self-protection, coders > have become less and less competent, further away from the machine, and more > dependent on nannying. Poppycock. > I don't want my car to drive itself to the store, I'll steer it, use > the gas and brakes, and make it do what I want, thanks very much. Luddite. > I realize every so-called coder under the age of 30 has been brainwashed > into thinking OO is the silver bullet but that's simply not the case. Indeed; functional is the silver bullet. OO is only bronze. > This misapplication and misimplementation of OO has done far more damage > than good and now we are seeing the results as people become more reliant > on self-protection and less and less capable of doing anything themselves > without 3rd party libraries, GC, and layer upon layer of middleware, etc. Hogwash. > Where does it stop? With the signing of your civil commitment papers. >>> Ada is readable. It's clean, it's orderly, it's so much better and safer >>> than C++ that there isn't any comparison at all. >> And it's at least as verbose as Java. Eeeuw. If you can cope with deeply >> nested parentheses, Lisp FTW. Otherwise maybe stick with C? :) > > Ada is not verbose at all. Fiddle-faddle. Unless it has syntactic abstraction, anyway. > I don't understand how you can make that statement. It's quite simply, really. First I typed an 'A', then an 'n', then a 'd' and a space, then "it's", and "at", and "least" and "as", and "verbose", and "as" again, and then, finally, "Java" and a period. You really ought to try it sometime. > Java is a sloppy mess like its cousins. Yes, it is. Fortunately, Lisp isn't. > Ada makes reading the code simple and that was a design goal of Ada. They said that about BASIC too. >> I'm more worried about the wackos that think manual memory management is >> a must-have. > > And why is that? Is personal responsibility somehow not relevant to coding? Non-sequitur. The one has nothing whatsoever to do with the other. Unless you genuinely believe that the use of automation and personal responsibility are mutually exclusive, in which case there's a hunter-gatherer tribe out there somewhere that is missing its village idiot. > Is understanding your hardware and making it do what you want no longer the > goal of programming? It still is if you're just a hobbyist hacker. Us professionals are in the business of understanding customers' hardware and making it do what they want at their push of some buttons. :)