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: fac41,3ef3e78eacf6f938 X-Google-NewGroupId: yes X-Google-Thread: 103376,3ef3e78eacf6f938 X-Google-NewGroupId: yes X-Google-Thread: 108717,3ef3e78eacf6f938 X-Google-NewGroupId: yes X-Google-Attributes: gide91fe56a56,gida07f3367d7,gid5b1e799cdb,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: pjb@informatimago.com (Pascal J. Bourguignon) Newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.modula3,comp.lang.pascal,comp.programming Subject: Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3? Date: Wed, 24 Mar 2010 22:27:01 +0100 Organization: Informatimago Message-ID: <87r5n9s95m.fsf@galatea.lan.informatimago.com> References: <4BA8BA91.4050905@cherrystonesoftware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: individual.net E7ph2pgQY9IOzgkZoh+83QpXVhA3Z7qWAC1lJI4+AnGOzW6H4C Cancel-Lock: sha1:Mjc2ZTMzZjVjMTM5MjI4Y2RhZjllYjFjN2JhMTM3ZDE5Y2I1MjFjZg== sha1:bM1VNQaLyGBJ2s0zlAz1fkV0TUk= Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAQMAAABtzGvEAAAABlBMVEUAAAD///+l2Z/dAAAA oElEQVR4nK3OsRHCMAwF0O8YQufUNIQRGIAja9CxSA55AxZgFO4coMgYrEDDQZWPIlNAjwq9 033pbOBPtbXuB6PKNBn5gZkhGa86Z4x2wE67O+06WxGD/HCOGR0deY3f9Ijwwt7rNGNf6Oac l/GuZTF1wFGKiYYHKSFAkjIo1b6sCYS1sVmFhhhahKQssRjRT90ITWUk6vvK3RsPGs+M1RuR mV+hO/VvFAAAAABJRU5ErkJggg== X-Accept-Language: fr, es, en X-Disabled: X-No-Archive: no User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (darwin) Xref: g2news1.google.com comp.lang.eiffel:536 comp.lang.ada:9750 comp.lang.modula3:156 comp.programming:14673 Date: 2010-03-24T22:27:01+01:00 List-Id: Patrick Scheible writes: > Warren writes: > >> Patrick Scheible expounded in news:w9z39zqlr2s.fsf@zipcon.net: >> >> > Warren writes: >> > >> >> balson expounded in news:4BA8BA91.4050905@cherrystonesoftware.com: >> >> >> >> > Andrea Taverna wrote: >> >> >> Hi folks! >> >> > [snip] >> >> >> In the past I used C, but now I have decided to change language. >> >> >> I'm looking for a "better" one. >> >> >> >> >> >> Here follow the features it should have, ranked approximately by >> >> >> relevance: >> >> >> >> >> >> 0) open-source support and an alive community >> >> >> 1) directly compiled to efficient code >> >> >> 2) statically typed and object-oriented, better if multi-paradigm >> >> >> 3) general-purpose libraries (possibly standardized, either by >> >> >> standard or de facto), including containers and some math >> >> >> abstractions. 4) garbage collected. As an alternative, provide >> >> >> memory management policies via libraries (e.g. memory pools and >> >> >> such) 5) optional run-time checks and some kind of control over >> >> >> compilation and low-level issues >> >> >> 6) "relatively simple and consistent" >> >> > >> >> > Where's performance on this list? >> >> >> >> Performance is mentioned in "1) directly compiled to efficient >> >> code". >> >> >> >> > IOW, stay away from the likes of Java, C#, Pascal. Unless you >> >> > have a >> >> > very specific reason for going in that direction. Your performance >> >> > will suffer. >> >> > Jim >> >> >> >> I don't think many people would be surprised by these results. >> >> After all Java, C# and Pascal (variants) are still largely >> >> interpreted languages, even if they use some sort of compiled >> >> intermediate code. This is wrong. The most common implementations of these languages are all compilers. The fact that the compiled code is later executed by a hardware processor or a software processor (a "virtual machine") is irrelevant to the workings of the implementation of the language. >> > Pascal is not an interpreted language. One of Pascal's selling points >> > was that it was one of the first languages that could be parsed by a >> > simple recursive descent parser without backtracking. >> > >> > -- Patrick >> >> P-code implementations were. > > True. But P-code was for student use, not production, especially not > production in an application where execution time was critical. This is wrong. P-code was designed, and used, exactly like the JVM is today. There even were developed processors that executed directly P-code, natively, like we have JVM implemented in hardware too. -- __Pascal Bourguignon__