Re: John Carmack glorifying functional programing in 3k words
On 2012-05-02 14:44:36 +, jaialai.technol...@gmail.com said: He may be nuts But he's right: programmers are pretty much fuckwits[*]: if you think that's not true you are not old enough. [*] including me, especially. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is Programing Art or Science?
On 2012-04-03 00:52:35 +0100, Jürgen Exner said: Oh, that's why it is tought in trade schools alongside butchery, plumbing, masonry, and chimney sweeping and why you don't find any programming classes at university. So, you know, no one would do law or medicine at a university. Oh, wait. -- http://mail.python.org/mailman/listinfo/python-list
Re: What Programing Language are the Largest Website Written In?
On 2011-08-02 15:41:06 +0100, ccc31807 said: Most of these are tech companies. Tech companies are very important, but so are other kinds of companies. What do manufacturing companies use, like Ford and Toyota, energy companies like BP and Exxon, pharmaceutical companies, consumer product companies, and so on? What about the big retailers, Sears, WalMart, Target, etc.? A more important metric is how critical the web presence is to the company. For Amazon, say, it's pretty critical, so what they do is likely to be interesting: if their site is broken they're not making any money. For Toyota, say, well, an outage would probably be embarrassing, but it's not anything like as critical to them. Unfortunatly I suspect that with web stuff as with other stuff, the answer is that it entirely depends. I am endlessly horrified by the poor state of software that is really critical to large companies. -- http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing" [OT]
On 2010-10-13 14:20:30 +0100, Steven D'Aprano said: ncorrect -- it's not necessarily so that the ratio of the circumference to the radius of a circle is always the same number. It could have turned out that different circles had different ratios. But pi is much more basic than that, I think. My background is in physics so I tend to do things from the geometrical point of view - and obviously you are correct that there are non-euclidean geometries. But pi crops up, for instance, when dealing with complex numbers (e^(i pi) = -1 is the poster-child formula for this), and there are all sorts of series expressions for pi which have no really obvious geometrical interpretation. (Of course, my view of the pi-in-complex-numbers is that this is because complex numbers turn out to essentially //be// two-dimensional euclidean geometry, but that's mostly because I want eerything to be geometry I think. In any case, I think you can get to pi being important in the same sort of way that you can get to e being important.) (And, it sounds in the above like I think you might not know that pi crops up in complex numbers: that's just clumsy wording, sorry). -- http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
On 2010-10-13 13:21:29 +0100, BartC said: My money would have been on 0.25, based on using 1.0 for a 360° circular angle. It seems far more attractive than using the arbitrary-looking 6.28... It may look arbitrary, but it isn't: it's about as non-arbitrary as it is possible to be. -- http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
On 2010-10-13 02:00:46 +0100, BartC said: But what exactly *is* this number? Is it 0.25, 1.57 or 90? Its pi/2, the same way 90% is 9/10. I can also write 12 inches, 1 foot, 1/3 yards, 1/5280 miles, 304.8 mm and so on. They are all the same number, roughly 1/13100 of the polar circumference of the Earth. They are not numbers they are lengths. -- http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
On 2010-10-12 20:46:26 +0100, BartC said: You can't do all that if angles are just numbers. I think that the discussion of percentages is relevant here: angles //are// just numbers, but you're choosing a particular way of displaying them (or reading them). 100% //is// 1, and 360° //is// 2π. So really, like, for instance, number base, they're things that exist for I/O but not inside the system. At least for the purposes of doing maths: computer type systems often don't have very much to do with maths (for instance floating-point numbers are obviously a very important type, but don't map onto anything that would be interesting to a theoratical physicist). -- http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
On 2010-10-12 11:16:09 +0100, Ben said: Angles aren't "true" units, as they are ratios of two lengths. They are more of a "pseudo" unit. That's right, in fact angles are pure numbers. In general any function which raises its argument to more than one power (for instance anything with a non-trivial power series (Taylor series) expansion) doesn't make much sense if its argument has units. Transcendendal functions are all like that, of course. For instance sin(x) = x + s^3/6 + O(x^5), so sin(1m) would be 1m + 1m^3/6 + O(m^5), and it doesn't make sense to add metres and cubic metres (let alone the infinite number of higher-order terms!). -- http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
On 2010-09-30 13:36:17 +0100, Nick Keighley said: there are some application domains where neither option would be viewed as a satisfactory error handling strategy. Fly-by-wire, petro- chemicals, nuclear power generation. Hell you'd expect better than this from your phone! People always give these kind of scenarios, but actually there are far more mundane ones. In my day job I'm a sysadmin and I spend a bunch of time writing code (typically what would nowadays be called "scripts" rather than programs, but there's no real difference) which does things of the form for every machine in do where is fairly often "modify critical system configuration file". Programs like that have some absolute, non-negotiable requirements: - they must never fail silently; - they must check everything they do however unlikely it seems that it would failm because they will come across systems which have almost arbitrary misconfiguration. - they should be idempotent if possible; - if they come across something odd they either need to handle it, or put things back the way they were and back out; - if they absolutely can not put things back, they need to report this very clearly and carefully preserve any detriitus in such a way that a human can pick up the bits; - whatever they do they need to report in a completely parsable way what happened (success, failure, already done, backed out, not backed out, and so on). These are quite mundane everyday things, but the consequences of getting them wrong can be quite nasty (the worst ones being "the machines will still run, but won't boot"). -- http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
On 2010-09-28 14:39:27 +0100, Malcolm McLean said: he problem is that if you allow expressions rather than terms then the experssions can get arbitrarily complex. sqrt(1 inch + 1 Second), for instance. I can't imagine a context where 1 inch + 1 second would not be an error, so this is a slightly odd example. Indeed I think that in dimensional analysis summing (or comparing) things with different dimensions is always an error. On the other hand sqrt(4 inches^2) is quite well defined. The question is whether to allow sqrt(1 inch). It means using rationals rather than integers for unit superscripts. There's a large existing body of knowledge on dimensional analysis (it's a very important tool for physics, for instance), and obviously the answer is to do whatever it does. Raising to any power is fine, I think (but transcendental functions, for instance, are never fine, because they are equivalent to summing things with different dimensions, which is obvious if you think about the Taylor expansion of a transcendental function). --tim -- http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
On 2010-09-28 10:55:19 +0100, Malcolm McLean said: I'd like to design a language like this. If you add a quantity in inches to a quantity in centimetres you get a quantity in (say) metres. If you multiply them together you get an area, if you divide them you get a dimeionless scalar. If you divide a quantity in metres by a quantity in seconds you get a velocity, if you try to subtract them you get an error. There are several existing systems which do this. The HP48 (and descendants I expect) support "units" which are essentially dimensions. I don't remember if it signals errors for incoherent dimensions. Mathematica also has some units support, and it definitely does not indicate an error: "1 Inch + 1 Second" is fine. There are probably lots of other systems which do similar things. -- http://mail.python.org/mailman/listinfo/python-list
Re: If Scheme is so good why MIT drops it?
On 2009-07-19 19:31:36 +0100, Frank Buss said: (e.g. I don't know of a free modern and stable Lisp implemenation with mulithreading support for Windows, with a licence with which you can use it in closed source commercial programs, like you can do with Python). Openmcl seems reasonably stable to me, is LLGPL-licensed, and runs on these platforms and Solaris x86. It's kind of tragic, of course, that this kind of parasitic behaviour (will not consider a commercial product to use in your commercial system) has now become so common. -- http://mail.python.org/mailman/listinfo/python-list
Re: The fundamental concept of continuations
On Oct 9, 7:34 am, [EMAIL PROTECTED] wrote: > which lambda paper ? Are you Ilias? I think you probably are. -- http://mail.python.org/mailman/listinfo/python-list
Re: The Concepts and Confusions of Prefix, Infix, Postfix and Fully Functional Notations
On Jun 11, 8:02 am, Twisted <[EMAIL PROTECTED]> wrote: > On Jun 11, 2:42 am, Joachim Durchholz <[EMAIL PROTECTED]> wrote: > > > It is possible to write maintainable Perl. > > Interesting (spoken in the tone of someone hearing about a purported > sighting of Bigfoot, or maybe a UFO). > I think it's just obvious that this is the case. What would *stop* you writing maintainable Perl? -- http://mail.python.org/mailman/listinfo/python-list
Re: Why stay with lisp when there are python and perl?
On May 4, 10:13 am, Tim Bradshaw <[EMAIL PROTECTED]> wrote: > Anyway the experience of writing in Python was kind of interesting. > [...] So one of the things I learned was "use a > language with a decent compiler"[*] I think. Bugger, I did not realise until too late that this was going to comp.lang.python as well. I should therefore add a caveat: Use a language with a high-performance (this is what I meant by "decent") compiler if that kind of performance matters to you. It did to us, but there are very many cases where it does not. In other words, despite appearances I'm not particularly trying to slag off Python. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why stay with lisp when there are python and perl?
On May 4, 3:06 am, Jon Harrop <[EMAIL PROTECTED]> wrote: > > Lisp compilers are much more advanced, for one thing. Though I hesitate to respond in this thread (and I didn't actually read the rest of the article) there's actually a valid point here. The last programming job I did involved doing some search stuff in Python. I think Python had been chosen for almost (but actually not) good reasons - people really wanted to use Lisp but it would have been too hard (politically and technically), and the same people had recent first-hand experience of some of the worse horrors of J2EE programming so were negative about Java. Finally Python actually had the required stuff (the ability to mmap files was critical to the proposed technique for doing the search). (The reasons were actually not good because Java could have done it as well, and if we'd had the courage we could have done a POJO-style Java thing which would have been fine and set a good example to other people, which as it was we failed dismally to do. On the other hand they'd not have hired me - despite the fact that even by then I didn't care about language choice with a few exceptions (C++), I didn't look enough like a Java person (and still don't of course).) Anyway the experience of writing in Python was kind of interesting. It had the usual single-implementation issues common to such things which meant we depended on the right version (and I think a later version than the one shipped with the OS since they'd decided to change semantics in some quite major way at some point). But apart from that writing programs that performed well (for us - we actually had performance issues since we wanted to look at a lot of data) turned out to be a matter of making sure that all the performance- critical bits were done in libraries (in C) with Python merely a kind of elaborate glue to get in the way. It was a bit like writing code for an array processor or a DSP or something, except without any good hardware reason for it. So one of the things I learned was "use a language with a decent compiler"[*] I think. --tim [*] No glib comments about Java not having a decent compiler: actually typical implementations do now (or did in 2004/5 and I bet they are better now). -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
On 2007-03-09 07:00:06 +, [EMAIL PROTECTED] (Alex Martelli) said: > (nee "One Laptop Per Child", OLPC, and once known as the "$100 laptop") > uses Python as its preferred (only?-) application language, and it's > slated to be the most widely distributed Python distro if it hits even > half of its ambitious target-numbers... But it won't get anywhere near that because it's a stupid an ill-conceived idea (not because of Python, note!). The electronic gadget people need in the developing world is a mobile phone not a computer. -- http://mail.python.org/mailman/listinfo/python-list
