On Fri, 25 Oct 2013 01:12:12 -0700, Peter Cacioppi wrote: > On Monday, October 21, 2013 9:29:34 PM UTC-5, Steven D'Aprano wrote: >> On Mon, 21 Oct 2013 01:43:52 -0700, Peter Cacioppi wrote: >> >> Challenge: give some examples of things which you can do in Python, but >> cannot do *at all* in C, C++, C#, Java? > > Please. No exceptions is huge. No garbage collection is huge.
You have over-trimmed and lost context. The context here is that I maintain that one of the reasons for inventing new languages is to provide useful programming idioms and techniques in a convenient, clean way, that is, with syntactic support and a minimum of needless boilerplate. You have objected to this view, and (if I understand you correctly) believe that there are certain idioms which are *impossible* in C, hence the invention of new languages. I agree with you that garbage collection and exceptions are useful, powerful features. I agree with you that the difference between a language which supports them natively (like Python) and one which does not (like C) is huge. But beyond that I think you are mistaken. C does not natively provide garbage collection, or exceptions, or many other features. But that doesn't make it *impossible* to use these features in C, it just makes them *inconvenient and difficult*. To get the advantage of such features, you have to build a framework that provides them, then exclusively use the framework, while avoiding dropping down into the underlying low-level C features that bypass the framework. This is inconvenient, error-prone, inelegant, and requires discipline, but it is *possible*. Take the framework to the next level: add custom syntax, a parser, and a system for translating your custom syntax to (say) C, or machine code for some (real or virtual) machine. We call this *a programming language*. But that's just an incremental step beyond a framework, which in turn is just an incremental step beyond a library, which in turn is just an incremental step beyond an ad hoc system of useful wrapper functions and conventions. In a very real sense, Python is "just" a convenience wrapper around a bunch of C functions to provide OOP idioms, garbage collection, dynamic typing, runtime introspection, exceptions, and similar. > But you can do anything with a Turing machine. You can do anything in > assembly. The point is to pick the appropriate tool for the job. I agree! And building those tools is one of the reasons why people create new programming languages: to make useful techniques and idioms easier to use. > I can build a house without a nail gun. I can probably even build a > house without a hammer. But it's a waste of time to build things with > the wrong tools. I don't think the right analogy is with the nail gun versus hammer. Both result in the same finished product: two pieces of timber joined together with one or more pointy bits of steel. Sure, a nail gun is faster and easier, but the idiom is the same. A better analogy is to consider the various ways to assemble timber: nails, screws, glue, dowels, biscuits, dovetail joints, etc. These are all *idioms and techniques* for getting the same result (two pieces of wood joined), rather than different tools for performing the same idiom (drive a nail using a nail gun, a hammer or a rock). Each idiom has different pros and cons: biscuits are good for joining chipwood edge-to- edge, but lousy for load bearing structural timbers. Like all analogies, it doesn't pay to take it too far, but essentially you can think of a language like Python as being like a machine shop with a dedicated biscuit joiner, while C is like one without such a device. You can use the same technique in both, but the ease of use, convenience and reliability is quite different: * In Python, you use the biscuit joiner to quickly cut out a matching, nicely machined slot in both pieces of chipboard. * In C, you have to manually and carefully drill out many thin holes in the chipboard, then laboriously cut through to make a slot, then file smooth by hand. Not only is this much more work, but the end result is likely to be less reliable. For anyone who has no idea what I'm talking about when I talk about biscuit joiners: http://en.wikipedia.org/wiki/Biscuit_joiner -- Steven -- https://mail.python.org/mailman/listinfo/python-list
