|
Home | Switchboard | Unix Administration | Red Hat | TCP/IP Networks | Neoliberalism | Toxic Managers |
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix |
[Dec 28, 2001] Digital Mars C and C++ Compilers -- contains free C and C++ compilers and free downloads section.
[Sept 8, 2001] Lisp as an Alternative to Java
Introduction
In a recent study [1], Prechelt compared the relative performance of Java and C++ in terms of execution time and memory utilization. Unlike many benchmark studies, Prechelt compared multiple implementations of the same task by multiple programmers in order to control for the effects of differences in programmer skill. Prechelt concluded that, "as of JDK 1.2, Java programs are typically much slower than programs written in C or C++. They also consume much more memory."
We have repeated Precheltнs study using Lisp as the implementation language. Our results show that Lisp's performance is comparable to or better than C++ in terms of execution speed, with significantly lower variability which translates into reduced project risk. Furthermore, development time is significantly lower and less variable than either C++ or Java. Memory consumption is comparable to Java. Lisp thus presents a viable alternative to Java for dynamic applications where performance is important.
Conclusions
Lisp is often considered an esoteric AI language. Our results suggest that it might be worthwhile to revisit this view. Lisp provides nearly all of the advantages that make Java attractive, including automatic memory management, dynamic object-oriented programming, and portability. Our results suggest that Lisp is superior to Java and comparable to C++ in terms of runtime, and superior to both in terms of programming effort, and variability of results. This last item is particularly significant as it translates directly into reduced risk for software development.
[Aug 30, 2001] Sun plans release of Forte 3
Sun plans a Sept 10 release of version 3 of Forte for Java, an IDE for Java development. Will support C, C++ and Java.
A Coding
Convention for C++ Code
A Coding Convention for C++ Code. ... Purpose. To make it
easier for us to read each
other's code, here are a few guidelines to follow when writing C++
code. ...
www.cs.princeton.edu/~dwallach/CPlusPlusStyle.html - 4k -
Cached -
Similar pages
CC-RIDER C and C++ Source Code
Analysis Navigation ...
CC-RIDER C/C++ Source Code Analysis Documentation
and Visualization. ... Full Language ...
Description: A detailed analysis of your
C or C++ program, allows easy navigation with Call Trees, Hierarchy
Trees,...
Category:
Computers > Programming > Languages > C++ > Tools
www.cc-rider.com/ - 14k -
Cached -
Similar pages
Dr Clue's HTML Guide
[] CGI Programming and C++ Classes .. ...
... C++ Code to make your life easier The Second section
makes getting data into a CGI
program a snap! If you know how to program in C++ you'll fall in love
with Dr ...
Description: Information covering how CGI
works and the different methods of interaction. Includes a free C++
class...
Category:
Computers > Programming > Languages > C++ > Runtime Environments > CGI
www.drclue.net/F1.cgi/HTML/CGI/CGI.html - 11k -
Cached -
Similar pages
An
Abbreviated C++ Code Inspection Checklist
An Abbreviated C++ Code Inspection Checklist. John
T. Baldwin October 27, 1992. Copyright (C ...
www.ics.hawaii.edu/~johnson/FTR/Bib/Baldwin92.html - 34k -
Cached -
Similar pages
Debugging C and C++ code in a Unix environment
Debugging C and C ++ code in a Unix environment. JHM Dassen.
[email protected]. IG Sprinkhuizen-Kuyper. ...
Description: Introduction/overview of
debugging tools and techniques for the Unix environment.
Category:
Computers > Software > Operating Systems > Linux > Projects > Debugging
www.wi.leidenuniv.nl/~jdassen/onderwijs/stuva/debug/debug.html
- 7k -
Cached -
Similar pages
White Paper:
X-Designer and C++ Code Generation
... White Paper: X-Designer and C++ Code Generation. Table
of Contents. ... What does
"X-Designer's C++ code generation is based upon the Doug Young
model" mean? ...
www.ist.co.uk/xd/cpp_white_paper.html - 38k -
Cached -
Similar pages
www.cs.bham.ac.uk/~wbl/ftp/ga-code/four_node/README
Similar pages
C++ Code
Generation Feature
C++ Code Generation Feature. The Professional and
Developers versions of NeuroSolutions have ...
www.nd.com/develop/profver.htm - 4k -
Cached -
Similar pages
SourceForge: Project Info - C
and C++ Code Counter
... Login via SSL New User via SSL. Search. Software/Group Require All
Words. Project:
C and C++ Code Counter. ... C and C++ Code
Counter - Summary. ...
sourceforge.net/projects/cccc/ - 26k -
Cached -
Similar pages
Rational
whitepaper: Performance Testing C++ Code by Neil ...
... Performance Testing C++ Code. By Neil Hunt. Will my
code run fast enough? A popular maxim ...
www.rational.com/products/whitepapers/308.jsp - 29k -
Cached -
Similar pages
[Apr 18, 2001] Technetcast.com:
Bjarne Stroustrup: C++ Fights Back
"Bjarne Stroustrup: C++ Fights Back C++0x will likely
include an upgrade to the standard libraries that will provide standardized,
platform- and vendor-neutral solutions to some of the issues addressed by C# and
Java. An interview with the creator of C++: language standardization, Java and
C#, future directions for C++" RealPlayer video
here.
[Feb 24, 2001] C++ based books of the Algorithms section of the Books Reviews were updated. Includes reviews of:
Data Structures and Other Objects Using C++ by Michael Main, Walter Savitch
[Feb 22, 2001] An interview with Bjarne Stroustrup
LinuxWorld.com: Object-oriented languages have been around since the late 1960s. Yet, the object-oriented revolution took place more than two decades later. How do you explain this delay and which conclusions can we draw from it?
Bjarne Stroustrup: Part of the reason is that changes in people's behavior always take far more time than we are willing to believe. Another major reason is that some people had (and have) unreasonable expectations about "revolutions." The idea that there is one right way to solve essentially every problem for essentially every user is fundamentally wrong. I'm a great fan of the idea of object-oriented programming and the design ideals and techniques that it supports -- originating with Simula 67. However, those are not the only effective techniques. Much programming is best done with techniques that do not fall within a narrow definition of "object-oriented." And if you broaden the definition of "object-oriented" sufficiently for it not to be an obstacle to good programming and design, you get something that is basically meaningless. See my paper, "Why C++ isn't just an Object-Oriented Programming Language."
Yet, another reason is that people pushing "True OO" or "Pure OO" typically do so with languages and systems that impose enormous overheads for simple tasks compared to C and C++ code.
The conclusions that I drew (in 1980 or so) were that a general-purpose programming language must support multiple paradigms and that each paradigm must be supported well and with close-to-optimal runtime and space efficiencies. That said, I find that adoption of new ideas is seriously slowed by conservatism supported with myths of complexity and overheads.
Another problem is that many people, including many programmers, educators, and managers, are simply unwilling to face the complexities of software development. They dream of "silver bullets" and reject effective ideas because they are not perfect and not trivial to use by novices. This leads to real work being done using unnecessarily old languages, tools, and techniques while scarce resources are being squandered on a succession of fads. This underestimation of the problems also leads to every new "silver bullet" being too simplistic to address the rigors of real-world software development. And once something new has adapted to reality, it becomes vulnerable to criticism -- fair and not -- of complexity from the followers of the next "silver bullet."
To get back on a semitechnical note: I think that any language that aspires to mainstream use must provide a broad base for a variety of techniques -- including object-oriented programming (class hierarchies) and generic programming (parameterized types and algorithms). In particular, it must provide good facilities for composing programs out of separate parts (possibly writing in several different languages). I also think that exceptions are necessary for managing the complexity of error handling. A language that lacks such facilities forces its users to laboriously simulate them.
LinuxWorld.com: Which important programming trends are we about to see in the near future? What is the role of functional programming, rule-based programming, generic programming, and other programming paradigms in tomorrow's software world? Will any of these become the mainstream or are they mere academic trifles?
Bjarne Stroustrup: I'm not good at predicting the future, so I won't try, beyond pointing out that the future is usually more like yesterday than we like to believe. Note that COBOL, FORTRAN, and C still are major languages. Generic programming is real (mainstream) and you can see how the Standard Template Library (STL) borrows techniques from the functional programming community and uses them elegantly and efficiently in the context of C++. Rule-based programming (see the R++ link in Resources) has a record of failures and successes on a scale that didn't lead to mainstream adoption. That's a pity, but I don't want to call it an "academic trifle." Many of the ideas we today see as standalone languages will enter the mainstream as facilities and techniques embedded in a mainstream language, such as C++. The future will see much multiparadigm programming and many multilingual systems.
LinuxWorld.com: With the ratification of the new C99 standard, C/C++ compatibility seems more evasive than ever before. Is backward compatibility with C still one of the goals of C++? If so, what should be done to minimize the gaping chasms between the two languages?
Bjarne Stroustrup: C99 focused on extending the low-level facilities of C in the area of numeric programming. It basically ignored the abstraction facilities and the aims of generality embodied in C++. This makes compatibility harder as C adds more ad hoc, special-purpose facilities, where C++ addresses the same programmer needs through libraries implemented using general-purpose language facilities. An example is C99 variable-length arrays vs. C++'s vector. A more coordinated evolution of the two languages would have avoided this split.
My ideal is still a single language, and it is still technically feasible to merge C++ and C99 into a single, reasonably coherent language. I think such a language could meet every rational technical requirement. However, I'm not sure that the political will is there. For starters, it would require a merger of the C and C++ standards committees; it is not possible to have two different groups of people evolving two languages in parallel. Each committee attracts people who don't share the ideals of the majority of the other and who dislike compromising with that majority. Thus, whereas a single committee fosters a shared community, trust, and compromise, two committees provide opportunities for divergence and for ignoring inconvenient facts and opinions. Personally, I think the committees should work out an agreement to merge, and then merge in good time before the ISO C++ standard comes up for renewal. The result would be a better language and a much stronger community.
LinuxWorld.com: Are there any features or concepts in other fledging languages, say Python or Ada95, that you would like to see added to C++? Does C++ need any additional features or libraries at all?
Bjarne Stroustrup: I would like to see the upcoming revision of the C++ standard focus on libraries. The work on the language itself could be limited to correction of mistakes, to making the language more uniform, to provide minor extensions to support popular paradigms, and to provide guarantees needed for libraries. For example, I suspect that concurrency is best supported by a library and that such a library can be implemented without major language extensions. However, such a library might need some additional guarantees written into the standard. In addition, I'd like to see a merger of C and C++.
Consider "major" language facilities often discussed for C++:
- Concurrency: I'd like to see a library supporting threads and a related library supporting concurrency without shared memory.
- Reflection: I'd like to see something like that supported through a library defining the interface to extended type information.
- Persistence: I'd like to see some support in the Standard Library, probably in connection with the extended type information, but I don't currently have any concrete suggestions.
- Hash tables: Of course, some variant of the popular hash_map will be included.
- Constraints for template arguments: This can be simply, generally, and elegantly expressed in C++ as is.
- Assertions: Many of the most useful assertions [a means of code verification and error handling] can be expressed as templates. Some such should be added to the Standard Library.
- Regular expression matching: I'd like to see a pattern-matching library in the standard.
- Garbage collection: I'd like to see the C++ standard explicitly acknowledge that it is an acceptable implementation technique for C++, specifying that "concealed pointers" can be ignored and what happens to destructors for collected garbage. (See section C.4.1 of The C++ Programming Language for details.)
- GUI: It would be nice to have a standard GUI framework, but I don't see how that could be politically feasible.
- Platform-independent system facilities: I'd like to see the Standard Library provide a broader range of standard interfaces to common system resources (where available), such as directories and sockets.
Society
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
Quotes
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Bulletin:
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
History:
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
Classic books:
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|
You can use PayPal to to buy a cup of coffee for authors of this site |
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.
Last modified: March 12, 2019