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: a07f3367d7,3ef3e78eacf6f938 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news1.google.com!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!news.glorb.com!news2.glorb.com!newsfeed.xs4all.nl!newsfeed6.news.xs4all.nl!newsfeed5.news.xs4all.nl!xs4all!news.stack.nl!aioe.org!not-for-mail From: oxhiderubber@getaclue.com Newsgroups: comp.lang.ada Subject: Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3? Date: Mon, 03 Aug 2009 11:19:53 +0000 Organization: Aioe.org NNTP Server Message-ID: References: <2009a75f-63e7-485e-9d9f-955e456578ed@v37g2000prg.googlegroups.com> NNTP-Posting-Host: drWD2v14ZeJIKy2TU35hfw.user.aioe.org X-Complaints-To: abuse@aioe.org X-Notice: Filtered by postfilter v. 0.7.9 Cancel-Lock: sha1:mavNJV9sby7Hsv0zc4o+7UrHEjA= Xref: g2news2.google.com comp.lang.ada:7539 Date: 2009-08-03T11:19:53+00:00 List-Id: Oxide Scrubber whined as follow: > Assembly is good for ought but performance. For readability? Ludicrous. You just don't seem to have a clue, but you sure have a lot of silly uninformed prejudices. As with most languages, readability depends on the coder much more than the language. Of course this can still be a problem with some languages, but assembler is not one of them. Because of the structure of assembler there is plenty of white space for comments as opposed to languages with statements hundreds of characters long. >> 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. Ah, now I see the problem. You're talking about silly GUIs as if they were "major production systems" They aren't, and you're even more out of touch with reality than I first understood from your other silly posts. No money moves on web servers, nothing important happens there, they're just front-ends. More likely than not, the businesses had preexisting ways of interfacing with customers and just added web-enablement on top of existing applications. Do you understand this concept? All of the financial transactions happen on back-end systems (the "major production code systems") written in assembler and COBOL. None of this happens in toy languages like Java and very, very little I'm aware of in C++. >> 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. No, you don't seem to be able to distinguish front-ends from back-ends. Let me help you: front-ends are where data is displayed and gathered. Back-ends are where the real work gets done. Web sites are just e-commerce toys, they are just viewers. They don't actually *do* anything, much like you, I suppose. No major operation uses GC in back-end processing, performance is too important and time windows are short. None of the languages that major production systems are written in (COBOL, Assembler, Ada) have or need GC. > 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. Those are all toy languages used for GUIs and web apps, and no commercial back-ends are written in them. Yes, I understand you think putting data on a colored screen is "major production code" but you're very sadly mistaken. I suppose you might even be a troll for MS. Guess what? No money moves on MS or tiny little x86 boxes either, it moves on mainframes. > There are significant applications that cannot be developed without one > of: > 1. Reference counting. > 2. GC. > 3. Memory leaks. Wrong. We do it all the time. Take a course in data structures some time, you might be amazed at what a competent designer can do without your imaginary limitations. We design and sell performance software to Fortune 500 companies and if we leak memory or don't perform there's no second chance. We just understand what we are doing, and don't depend on other people solving our problems by creating new ones. >> If you would just have control and understand your platform, all of these >> problems would go away. > > BS. Not a very convincing argument! But then nothing you've said has been, it's mostly furious vitriol because your "arguments" are all empty and based on your severely limited view of reality and your complete ignorance of what production systems do and are. >> Because we have never needed them. > > Speak for yourself. I just did, are you unable to read? In my business we have never needed them. Don't you get it? The problems are because you don't understand how to design systems, how to code, or what actually gets executed on the machine. If you did that, you would understand why all of what you are saying is nonsense. You're too far away from what actually happens to have a clue. > 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. You have no argument from me, although I'm sure the C++ camp can find 10,000 awful Java programs for every bad C++ program. Java is for people who're too stupid to be able to code in C++, and need even more protection from themselves. >> 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. You just don't have a clue. More COBOL is in production doing real back-end work than all of your silly academic and GUI languages combined. It's all compiled and runs on metal. > Large order-fulfillment systems are "academic computing" to you? You don't understand that the back-ends of order fulfillment systems are not written in interpreted languages. Only the GUIs are. > Then you should not be posting anywhere but comp.lang.asm.*. Ah I see if someone disagrees with you aside from shouting balderdash and poppycock dozens of times, you also direct them to places you won't have to answer them. Anyway comp.lang.asm is for assembly on toy computers such as you use, not the sort we work on. > Fine. But not every programmer feels as you do. That's because they're not programmers. They just imagine they are. If you don't know what the machine is doing with your code, you're not a programmer. You're just an end-user like a guy watching TV, driving a car, etc. Programming is about knowing exactly how to tell the machine to do what you want it to do, and to be able to verify that it is happening as it should. If you can't do that, you're just playing video games like any other moron. Feel free to continue to masturbate in public on your own time. I've no interest in watching you.