This is described at having a 500MHz CPU. I can go to ASL,
a Linux workstation vendor, and buy an 750MHz AMD machine for $997. Sun doesn't have some pixie dust
that makes their machines magically faster at the low end. The 1998 Ultra 10 I used for a year or two
was about as fast as the comparable Linux workstations at the time -- but the Sun box was about twice as expensive.
Unless you're in the world of 64-processor servers, or you need to run some bizarre application that's only available for Solaris,
there is no reason to buy a Sun workstation; an x86 running Linux or *BSD is much more cost effective and more pleasant for desktop use.
It also makes life easier for programmers of custom internal apps.
Say you have a complex set of objects implementing your business rules in Python, Java, C++, or whatever. If you want to add handheld support using PalmOS, you have to
either reimplement all of them in Palm C/C++, or keep the handheld an idiot that understands nothing of the objects and just have it talk to a server
program that runs on a full OS and does understand the business objects. With a Linux PDA, the port would be much easier since the objects can probably run on it.
PGN has been arguing all along that new voting systems must have their source code available; see comp.risks for the past few months. So why refer to some fearful "them"?
I don't believe it started with Minix code. Quoting from this Wired article:
Linus began to experiment with his own hacks, using Minix as
scaffolding to develop a new program. "I made two processes and made
them write to the screen and had a timer that switched tasks," he
recalls. "One process wrote A, the other wrote B, so I saw AAAA, BBBB,
and so on."
I believe this means he wrote a really simple multitasking kernel that switched between two processes, compiling it on Minix but not using Minix code. Then he wanted to turn that simple 2-process kernel into a terminal emulator, which raised the question of drivers, and it was on its way to being a real kernel.
(If you look at the Linux-activists archive (warning: 600K archive), early Linux seems much cruder than Minix, something which wouldn't have been the case if Linux == Minix being rewritten piece-by-piece.
Try looking at the source for the Python interpreter (the C version; I know little about JPython).
Like any sizable program it has its messy bits, but overall the organization is quite clear, the implementation leans toward the simple and straightforward instead of the weirdly optimized and obscure,
and it's one of the more pleasant medium-sized programs I've worked on.
(Where is the boundary between medium-sized and large programs, anyway? Python is roughly 150,000 lines of code, though over half of that is in the various extensions that come with the
source distribution; the core interpreter itself is around 60,000 lines.)
TeX is a Turing-complete language; this makes it difficult to do automated things to tex documents, because
an innocent \foo could contain anything -- paragraph breaks, page after page of automatically generated text. This is why tools such as LaTeX2HTML still occasionally fail on documents that do fancier things than the conversion program is prepared to handle.
MathML is verbose, but it's also purely declarative (at least for now), and therefore easier to process. You could
create a TeX subset for math equations only -- no \def allowed -- but then it's not TeX any more.
Besides, most of the developers have already moved to K5.
I think Advogato is more of a developer hangout (thanks in large part to its wonderfully draconian trust metric), while K5 is more of a media/culture discussion area these days.
I'm always on the lookout for languages that match Python in simplicity and power. From what I know of it, which comes mostly just from reading the docs, Ruby's the closest thing I've seen yet.
However, it seems to look more at Perl for its syntax, which means it has implicit arguments for functions, magical character prefixes in certain spots, and cryptic names for some global such as $$.
It's also a much younger language, and given that Matz doesn't seem very parsimonious in his design; I wonder if the interpreter will become painted into a corner by growing complexity. This tendency is hard to avoid; look at Perl or Zope for examples of the snarl that can result. On the other hand, I think Ruby's syntax and semantics may be essentially complete at this point, meaning there's nothing left to add; I don't know what Matz's thoughts are.
In short, I think I agree with another poster's comment that instead of waiting for Perl6, you should look at Ruby instead. Not as pleasant to read Ruby code as Python code, though, and its syntax isn't as clean, so it won't be replacing Python for me just yet.
I wouldn't worry too much about overcomplexity, since GvR is quite careful in adding new features these days; for example, he's against adding continuations since they're complicated to understand and it seems likely few people will use them. Instead, it's more likely that useful abstractions such
as coroutines will be added, providing the abstractions people usually use continuations to build. In fact, I wish GvR was a bit less cautious; there are several problems where I think new keywords would be the best solution, but anything that calls for a new keyword has a significant obstacle to overcome.
As for improving module building and other things, I hope to make significant steps in that area for 2.1.
Because raw performance matters less due to network latency or connecting to other servers (your RDBMS or other backend). Given that setting up a TCP connection and downloading the HTML and images take a certain amount of time, any savings from writing in a
compiled language are neglible. For example, say the
user's computer can download a page in five seconds. Say my Python program takes 0.5 sec, while your C program takes 0.005 seconds (100x faster); who cares about 0.5 vs..005 sec for the actual processing?
Also, I think people often envision themselves running Amazon-scale services with thousands of hits per second and therefore need CPU usage pared down to the bone, but practically I think many Web sites are low-volume. The one I work on for my day job probably can expect 5000 or 10000 registered users, tops,
and so the CPU is never heavily loaded at all, so there's no reason to give up the ease of programming and debugging for unneeded speed improvements.
Re:Python to perl interpreter
on
Perl 6 Showcase
·
· Score: 2
This is what Guile originally aimed to do by writing translators from Tcl/Python/Perl to Scheme, yet where are the translators today?
People already using their Python interpreter, which is a well-tested and stable hunk of code by now, don't want to chuck it and start using a translator on top of an entirely different execution engine. The problem is that specifying a general VM is a difficult job. Java didn't manage it (can't implement Scheme's continuations on the JVM), Microsoft's CLR didn't (no multiple inheritance, so Eiffel# had to have MI
stripped out of it), and it seems quite likely that the Perl engine will similarly make it possible to write code in vague amalgams of Perl's semantics and some other language's syntax, but capturing the semantics of the other language will prove impossible, since Perl's view of the world will permeate the VM in subtle ways.
It seems you're claiming that a script written in Python is derivative of the Python interpreter. But that's wrong, because it would mean you can't write a GPLed Delphi program (because Delphi isn't GPLed) or a GPLed set of Excel macros, which is silly; the fact that you're using a non-GPLed development environment doesn't mean you can't write a GPLed program for that environment. Otherwise, how could you legally run the GNU tools on a non-GPLed OS like Solaris?
People seem under the impression that RMS pronounced a verdict ex cathedra about the new license. That's wrong; the Pythoneers explicitly went and asked him for an opinion on the new license's GPL compatibility. RMS has not said you should not use Python; RMS has not said that Python's license is bad. He was asked if it's GPL compatible, and his legal advisors don't think it is, that's all. If you blame anyone, blame GvR and BeOpen for considering GPL compatibility an important criterion. I think they're right, and expect the situation to be resolved somehow by the time Python 2.0final arrives.
I don't see why Debian cares whether the Python licence is compatible with the GPL, though. The licence certainly seems to be DFSG-free, and I'm not aware of any GPLed software that has ever incorporated Python bodily. (People have written GPLed software in Python, of course, but that's a different thing; there's no requirement GPLed software be written using a GPLed system or platform.)
No, the beta period for 2.0 should be fairly short (knock on wood), with a 2.0final release within a month or two. 1.6 is a release born of legal quibbling, not of technical reasons.
I'm pretty certain it can't. a might be an instance of a user class with a __getitem__ method that does something arbitrarily strange. For example, if the __getitem__ deleted the key before returning it, you'd get a KeyError on evaluating the LHS.
Umm... Red Hat did not write Linuxconf; they simply use it. So if it's technically flawed, it's not because Red Hat designed it that way or built it that way.
Note, however, that having regexes as an add-on module means they can be dropped if you don't need them, such as if your interest is in wrapping numeric code or using it as an embedded language.
This is why there's already an early version of Python for PalmOS, while Perl for PalmOS doesn't seem to exist yet.
And calling python "academic", as if that's a term of derision, is simply silly. It's not a language that has attempted to create new ideas in programming languages; it simply starts with different design principles and, unsurprisingly,
ends up in a different place. See Tim Peters's "19 Pythonic Theses" for a (retroactively coined) list of principles.
It's true that it's difficult to do much without creating an object at some point.
However, you can do quite a lot of useful work in Python without understanding
the OO model, inheritance, or any of those concepts. To me, the difference between C's "file = fopen(...); fread(file,...)"
and Python's "file = open(...) ; file.read(...)" is simply a matter of syntactic sugar.
But you don't need to subclass some generic file class in order to create a file that's unbuffered, or is for writing instead of reading. Java's I/O library seems far more OO to me, in that you have to instantiate the right StreamWriter/Reader class.
Re:One good point -- too much C in open software
on
KDE Strikes Back
·
· Score: 2
Take a look at the language binding page. I can only speak about the Python bindings from some slight experience; they're quite nice and seem complete.
Benchmarking servlets against regular CGI is a bogus comparison. Are servlets faster than Python/Perl/whatever using FastCGI, Persistent CGI, or an embedded Apache module? Are they more convenient to write? Doubtful, on both those aspects...
The submission of CLI is very interesting, and I'm looking forward to seeing what the spec looks like. It might well be bletcherous and icky (this is Microsoft, after all, which doesn't like to have one API where 7 will do). But it's impressive that you can write a C# class and then subclass it from VB or Python, and vice versa; this is a degree of unification which languages on Unix badly lack.
Slashdot Mirror
This is described at having a 500MHz CPU. I can go to ASL, a Linux workstation vendor, and buy an 750MHz AMD machine for $997. Sun doesn't have some pixie dust that makes their machines magically faster at the low end. The 1998 Ultra 10 I used for a year or two was about as fast as the comparable Linux workstations at the time -- but the Sun box was about twice as expensive. Unless you're in the world of 64-processor servers, or you need to run some bizarre application that's only available for Solaris, there is no reason to buy a Sun workstation; an x86 running Linux or *BSD is much more cost effective and more pleasant for desktop use.
See recent python-dev summaries for what ESR is up to. Such as this one (adding string methods) and this one (speculating about Tk's fate).
It also makes life easier for programmers of custom internal apps. Say you have a complex set of objects implementing your business rules in Python, Java, C++, or whatever. If you want to add handheld support using PalmOS, you have to either reimplement all of them in Palm C/C++, or keep the handheld an idiot that understands nothing of the objects and just have it talk to a server program that runs on a full OS and does understand the business objects. With a Linux PDA, the port would be much easier since the objects can probably run on it.
PGN has been arguing all along that new voting systems must have their source code available; see comp.risks for the past few months. So why refer to some fearful "them"?
I believe this means he wrote a really simple multitasking kernel that switched between two processes, compiling it on Minix but not using Minix code. Then he wanted to turn that simple 2-process kernel into a terminal emulator, which raised the question of drivers, and it was on its way to being a real kernel. (If you look at the Linux-activists archive (warning: 600K archive), early Linux seems much cruder than Minix, something which wouldn't have been the case if Linux == Minix being rewritten piece-by-piece.
(Where is the boundary between medium-sized and large programs, anyway? Python is roughly 150,000 lines of code, though over half of that is in the various extensions that come with the source distribution; the core interpreter itself is around 60,000 lines.)
TeX is a Turing-complete language; this makes it difficult to do automated things to tex documents, because an innocent \foo could contain anything -- paragraph breaks, page after page of automatically generated text. This is why tools such as LaTeX2HTML still occasionally fail on documents that do fancier things than the conversion program is prepared to handle. MathML is verbose, but it's also purely declarative (at least for now), and therefore easier to process. You could create a TeX subset for math equations only -- no \def allowed -- but then it's not TeX any more.
I think Advogato is more of a developer hangout (thanks in large part to its wonderfully draconian trust metric), while K5 is more of a media/culture discussion area these days.
People are working on a Python equivalent; give us (me, mostly) a few months...
In short, I think I agree with another poster's comment that instead of waiting for Perl6, you should look at Ruby instead. Not as pleasant to read Ruby code as Python code, though, and its syntax isn't as clean, so it won't be replacing Python for me just yet.
As for improving module building and other things, I hope to make significant steps in that area for 2.1.
Also, I think people often envision themselves running Amazon-scale services with thousands of hits per second and therefore need CPU usage pared down to the bone, but practically I think many Web sites are low-volume. The one I work on for my day job probably can expect 5000 or 10000 registered users, tops, and so the CPU is never heavily loaded at all, so there's no reason to give up the ease of programming and debugging for unneeded speed improvements.
This is what Guile originally aimed to do by writing translators from Tcl/Python/Perl to Scheme, yet where are the translators today? People already using their Python interpreter, which is a well-tested and stable hunk of code by now, don't want to chuck it and start using a translator on top of an entirely different execution engine. The problem is that specifying a general VM is a difficult job. Java didn't manage it (can't implement Scheme's continuations on the JVM), Microsoft's CLR didn't (no multiple inheritance, so Eiffel# had to have MI stripped out of it), and it seems quite likely that the Perl engine will similarly make it possible to write code in vague amalgams of Perl's semantics and some other language's syntax, but capturing the semantics of the other language will prove impossible, since Perl's view of the world will permeate the VM in subtle ways.
It seems you're claiming that a script written in Python is derivative of the Python interpreter. But that's wrong, because it would mean you can't write a GPLed Delphi program (because Delphi isn't GPLed) or a GPLed set of Excel macros, which is silly; the fact that you're using a non-GPLed development environment doesn't mean you can't write a GPLed program for that environment. Otherwise, how could you legally run the GNU tools on a non-GPLed OS like Solaris?
People seem under the impression that RMS pronounced a verdict ex cathedra about the new license. That's wrong; the Pythoneers explicitly went and asked him for an opinion on the new license's GPL compatibility. RMS has not said you should not use Python; RMS has not said that Python's license is bad. He was asked if it's GPL compatible, and his legal advisors don't think it is, that's all. If you blame anyone, blame GvR and BeOpen for considering GPL compatibility an important criterion. I think they're right, and expect the situation to be resolved somehow by the time Python 2.0final arrives.
I don't see why Debian cares whether the Python licence is compatible with the GPL, though. The licence certainly seems to be DFSG-free, and I'm not aware of any GPLed software that has ever incorporated Python bodily. (People have written GPLed software in Python, of course, but that's a different thing; there's no requirement GPLed software be written using a GPLed system or platform.)
No, the beta period for 2.0 should be fairly short (knock on wood), with a 2.0final release within a month or two. 1.6 is a release born of legal quibbling, not of technical reasons.
I'm pretty certain it can't. a might be an instance of a user class with a __getitem__ method that does something arbitrarily strange. For example, if the __getitem__ deleted the key before returning it, you'd get a KeyError on evaluating the LHS.
Umm... Red Hat did not write Linuxconf; they simply use it. So if it's technically flawed, it's not because Red Hat designed it that way or built it that way.
And calling python "academic", as if that's a term of derision, is simply silly. It's not a language that has attempted to create new ideas in programming languages; it simply starts with different design principles and, unsurprisingly, ends up in a different place. See Tim Peters's "19 Pythonic Theses" for a (retroactively coined) list of principles.
It's true that it's difficult to do much without creating an object at some point. However, you can do quite a lot of useful work in Python without understanding the OO model, inheritance, or any of those concepts. To me, the difference between C's "file = fopen(...); fread(file, ...)"
and Python's "file = open(...) ; file.read(...)" is simply a matter of syntactic sugar.
But you don't need to subclass some generic file class in order to create a file that's unbuffered, or is for writing instead of reading. Java's I/O library seems far more OO to me, in that you have to instantiate the right StreamWriter/Reader class.
Take a look at the language binding page. I can only speak about the Python bindings from some slight experience; they're quite nice and seem complete.
Benchmarking servlets against regular CGI is a bogus comparison. Are servlets faster than Python/Perl/whatever using FastCGI, Persistent CGI, or an embedded Apache module? Are they more convenient to write? Doubtful, on both those aspects...
The submission of CLI is very interesting, and I'm looking forward to seeing what the spec looks like. It might well be bletcherous and icky (this is Microsoft, after all, which doesn't like to have one API where 7 will do). But it's impressive that you can write a C# class and then subclass it from VB or Python, and vice versa; this is a degree of unification which languages on Unix badly lack.
Who was it who said that Libertarianism starts off talking about man's freedom but then always deteroriates into whining about income tax?