Bigger guns in defence of Pascal. Even if one doesn't think of C as being fat and flabby, C++ certainly is.
This quote comes from John Backus: Can Programming be Liberated from the von Neumann Style? http://www.thocp.net/biographies/papers/backus_turingaward_lecture.pdf 1. Conventional Programming Languages: Fat and Flabby Programming languages appear to be in trouble. Each successive language incorporates, with a little cleaning up, all the features of its predecessors plus a few more. Some languages have manuals exceeding 500 pages; others cram a complex description into shorter manuals by using dense formalisms. The Department of Defense has current plans for a committee-designed language standard that could require a manual as long as 1,000 pages. Each new language claims new and fashionable features, such as strong typing or structured control statements, but the plain fact is that few languages make programming sufficiently cheaper or more reliable to justify the cost of producing and learning to use them. Since large increases in size bring only small increases in power, smaller, more elegant languages such as Pascal continue to be popular. But there is a desperate need for a powerful methodology to help us think about programs, and no conventional language even begins to meet that need. In fact, conventional languages create unnecessary confusion in the way we think about programs. For twenty years programming languages have been steadily progressing toward their present condition of obesity; as a result, the study and invention of programming languages has lost much of its excitement. Instead, it is now the province of those who prefer to work with thick compendia of details rather than wrestle with new ideas. Discussions about programming languages often resemble medieval debates about the number of angels that can dance on the head of a pin instead of exciting contests between fundamentally differing concepts. Many creative computer scientists have retreated from inventing languages to inventing tools for describing them. Unfortunately, they have been largely content to apply their elegant new tools to studying the warts and moles of existing languages. After examining the appalling type structure of conventional languages, using the elegant tools developed by Dana Scott, it is surprising that so many of us remain passively content with that structure instead of energetically searching for new ones. The purpose of this article is twofold; first, to suggest that basic defects in the framework of conventional languages make their expressive weakness and their cancerous growth inevitable, and second, to suggest some alternate avenues of exploration toward the design of new kinds of languages. On 17 Nov 2010, at 09:35, Ian Joyner wrote: > On 17 Nov 2010, at 06:49, Pascal Robert wrote: > >> >> Le 2010-11-16 à 14:42, Antonio Petri a écrit : >> >>> >>> Of course, the sad reality is that our industry loves to just syntactically >>> masturbate with different languages and pretend that we're much better for >>> it when the reality is that basically nothing has changed in 30 years in >>> terms of how we actually solve problems. >>> >>> I get this as iTunes, Google and Twitter could have well been built using >>> Pascal (the language...) >> >> No, because Pascal is too fat :-) At least that was one of my teachers said >> in college when we had to do a DOS (!!) app to send files over a NULL modem >> and he said that we will do the project in C because Pascal is too fat... > > C is both fat and lean - the wrong way round - fat with traps and bereft of > sensible patterns, like good string and array handling. It is sad to see how > teachers like that helped establish C - the worst thing that ever happened to > computing - in a dominant position. Now that really SUCKS! > > I think I'll reiterate Bob Barton's quote: > > "Systems programmers are high priest of a low cult" > > http://www.smalltalk.org/smalltalk/TheEarlyHistoryOfSmalltalk_VI.html > >> >>> >>> On Nov 15, 2010, at 8:50 PM, Ian Joyner wrote: >>> >>>> I agree with this too. Problem or fixed complexity must be dealt with >>>> somewhere in the system, and arguments often abound as to where that >>>> should be done (almost always without people recognizing that fact). I >>>> wrote on that recently too: >>>> >>>> http://www.ianjoyner.name/Ian_Joyner/Complexity.html >>>> >>>> so am in vehement agreement. >>>> >>>> It's always a problem getting something to run quickly, like Twitter, to >>>> see if it succeeds or fails, before committing significant resources, and >>>> then like Twitter maybe rewriting your message queues in Scala for speed. >>>> (Something done by WO, I think?) >>>> >>>> But getting something quickly done in WO, might be a problem. Pascal's >>>> words about "learning cliff" still ring in my ears ;-) >>>> >>>> Ian >>>> > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/webobjects-dev/ianjoyner%40me.com > > This email sent to ianjoy...@me.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
