On Wed, 6 Apr 2016 09:06 pm, BartC wrote: > On 05/04/2016 06:48, Gordon( Hotmail ) wrote:
>> The problem I am finding is most of the sites claiming to help understand >> Python devote far too much space bragging about the wonders of Python >> instead of... I'd like to see these sites. I suspect that "bragging" actually means "taking for granted powerful features that are unthinkable in BASIC". If it makes you feel better, Bart, your opinion about Python is somewhat similar to my opinion on the more esoteric areas of Lisp and Haskell programming. That's the Blub paradox in action again. But the difference is that I'm completely aware that my ignorance of Lisp and Haskell is *my* ignorance, not their wilful obscuration. Well, except for Monads. I'm convinced that Monads are a long-running April Fool's gag that has gotten completely out of hand... *wink* > I fully agree. But you don't have to use classes, exceptions, > decorators, generators, iterators, closures, comprehensions, meta > classes, ... the list of meaningless buzzwords just goes on. "Meaningless buzzwords"? Every one of those terms have meaning. They are technical jargon, not buzzwords. Honestly, hearing you say that makes you sound just tired and lost, an old dog who has given up on the possibility of learning any new tricks. That's sad, because none of those technologies above (with the possible exception of metaclasses, which are kinda mind-bending the first eighty or ninety times you read about them) are that complicated or difficult to use. They're just *different*. I feel for you -- when I hear folks talking about asynchronous programming, or databases, I feel just as lost. But I'm not so arrogant to imagine that those people are just flapping their mouths making random noises that have no meaning, or that they're just sprouting buzzwords. I don't get async programming because I've never taken the time to learn it. That doesn't make it a "meaningless buzzword", it makes it something I personally know little or nothing about. I should do something about it, and the fact that I don't is *my loss*. Unless you think that you have learned everything there is to know about programming, you should know better than to describe modern programming features as "meaningless buzzwords". > It'll cope with ordinary coding as well, although such programs seem to > be frowned upon here; they are not 'Pythonic'. What's "ordinary coding" mean? Most people, I imagine, know what a Zippo lighter is, even if they've never owned one or smoked: http://www.zippo.com/lighters.aspx?c=1230 You can light a fire with one by flicking them open and letting the lighter do most of the work. That's "Pythonic". But there's another way: you could, if you wish, clutch the lighter in one hand, and a piece of flint in another, and strike the flint against the lighter hard enough for sparks to come off. Direct the sparks into a small pile of extremely fine wood shavings, or punk wood, and blow ever-so-gently until the tinder catches alight. It won't be as easy or efficient as using a proper flint and steel, but it will (probably) work. https://en.wikipedia.org/wiki/Fire_striker Is that what you mean by "ordinary coding"? There's nothing wrong with lighting a fire with steel and flint, if you're in the wilderness, or after civilization has collapsed, and you can no longer get hold of lighter fluid or friction matches. It was a technology that lasted for literally thousands of years, it works, and isn't inherently *bad*. And for those who prefer to use human effort rather than products of advanced technology (like butane lighter fluid), a steel and flint is the more attractive option. But, frankly, using a Zippo lighter as the steel *is* inherently bad, since its the wrong sort of steel and will be very inefficient. That's not what Zippo lighters are designed to be. In an emergency, with no other steel around, using a Zippo lighter as a fire-striker may be justified by necessity, but it should never be PREFERRED over using it the way it was designed to be used. Of course programming is rather more complex that lighting fires, and there's no hard and fast line between using Python in a Pythonic fashion and misusing it in a non-Pythonic fashion. This isn't unique to Python: in *every* language, there is "good coding style" and "poor coding style", both of which depends on the strengths and weaknesses of the specific language being used. >> Liberty Basic >> for n = 32 to 255: print n;chr$(n) : next n >> >> REM BBC Basic >> FOR c = 1 TO 15 : COLOUR c >> PRINT "Color ";c >> NEXT c > > Python apparently has hundreds of libraries to do this stuff, which is a > downside: there are as many libraries as Basics probably! And each seems > to work a little differently from the other... > > I haven't tried graphics in Python, but I would start by googling > 'python basic graphics' or some such phrase. Unfortunately, technology has moved on, and there's nothing I've seen that comes close to the simplicity of graphics programming in 1980s-era BASICs. The closest is, perhaps, the turtle graphics module in Python, based on Logo, but I think the honest truth is that for all the advantages of modern GUI systems, the old low resolution, handful of colour PCs had their charms, and I think we've lost a certain something in their passing. Not that I would ever go back to the bad old days when 64K was considered more memory than anyone would ever need. But still, it's not just nostalgia, there really was something awesome about turning on a brand new computer for the first time and being able to immediately start doing graphics programming. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
