I believe it is, provided it isn't "circumvention" as opposed to just getting a client working.
Like, if you just re-wrote RealPlayer, you should be fine. Just don't save it to a file, because apparently decoding the file format is ok, but converting it isn't.
I know that doesn't make any sense. However, you could probably record everything that goes through/dev/audio. In that case, Real does all the circumvention for you. (Shouldn't be too hard to implement, right?) --- pb Reply or e-mail; don't vaguely moderate.
Read the law; section 1201 isn't even enforcable for another month.
1201. Circumvention of copyright protection systems
(a) VIOLATIONS REGARDING CIRCUMVENTION OF TECHNO-LOGICAL
MEASURES. (1)(A) No person shall circumvent a techno-logical
measure that effectively controls access to a work protected
under this title. The prohibition contained in the preceding sentence
shall take effect at the end of the 2-year period beginning on the
date of the enactment of this chapter.
And, even if you are right, apparently they'd have to take it up with a librarian... --- pb Reply or e-mail; don't vaguely moderate.
I have seen some code that plays older realaudio files, but that's about it. Also, I don't know a whole lot about audio codecs... --- pb Reply or e-mail; don't vaguely moderate.
Why is this not allowed with a plug-in architecture? If RealNetworks doesn't like it, then they shouldn't have offered the functionality, or should stop everyone from using plug-ins.
More specifically, could someone tell me what StreamBox was doing that was illegal, or is it just that RealNetworks and "The Powers That Be" don't like it, and will therefore make up a reason later...
Actually, Real is probably just jealous because they don't have a name like "Ferret"...;) --- pb Reply or e-mail; don't vaguely moderate.
I couldn't find it at all; I did eventually find Capitol's website, and they have a Pink Floyd section with some entire songs in low-quality realaudio, and various different bitrates (up to 96kbps) for windows media.
However, for Dark Side of the Moon (and another 10 discs), they just link to Amazon. --- pb Reply or e-mail; don't vaguely moderate.
I'd appreciate it if I didn't get moderated down for absolutely no reason, okay? If you do moderate either of these posts down, logout, and state your reason anonymously; I don't care about the karma, 'cause it'll take me a while to get back down to 50, high karma being meaningless now and all..... --- pb Reply or e-mail; don't vaguely moderate.
I believe I already got a meaningless reply to that end, and ignored it.
This is stupid philosophical tripe.
How do you know that information is meaningless without humans? Don't you think that supernatural beings, aliens, badgers, or plants might use it to make decisions? For that matter, how do you know that information doesn't have a collective consciousness, impressed upon it from its owners?
Well, these are pretty silly points I'm bringing up, but the point is, you don't know. In fact, you can't know. And if you think you do, you could still be wrong.
And that is meaningless philosophical debate.
Now let me use my anthropomorphisms in peace. --- pb Reply or e-mail; don't vaguely moderate.
I think that's 'horsepucky'. Did the rogue spell-checker bite you, Nick?
Also, some information *does* want to be freely available, like the whois database, or the song lyrics servers, and these are freely contributed, and unlawfully (in my opinion) restrained.
...so instead of trying to cash into the Napster phenomenon, do some *real* research, and find out something new. --- pb Reply or e-mail; don't vaguely moderate.
About global variables: well, *real* novices don't know about subroutines, anyhow!;)
I'm sure Perl has modules geared towards language processing, and I might even look it up; but for some reason, I have a desire to implement that part myself at a lower level, as well. Maybe by learning lex better, for starters...
Another site I found that looks pretty useful for Perl info is "perldoc.com"; it looks like most of the 'new, bolted-on' features of perl started in 1993, with the development of Perl 5; they're debating about what'll go into Perl 6 now...
...And I like the mythology reference.:) --- pb Reply or e-mail; don't vaguely moderate.
I haven't used exceptions; so far, it looks like a way to check for error codes after something has already screwed up, and I'm not convinced its a good approach yet. However, I'm also starting to learn Java, so I'm sure I'll see how they use it.
I'm not even a huge Perl advocate, but I learned it for my job and thought it was pretty handy, especially for getting the job done quickly. I revamped a script to add accounts, and integrated a domain registration system with a credit card processing system; (the first was written in Perl; the second had a Perl API interface, and I found a credit-card module for another processing system that was also already in Perl...) I'm sure there's a lot of Python code out there too, but Perl is quickly becoming a favored language for CGI interactions. On the server side, there's also PHP and Java now, and PHP also looks a lot like Perl (and probably like Python too...).
I haven't played with Perl's Object system much, but I know it has one, so I can't really compare those two; it seems to work pretty well, though.
I'd argue over the syntax being more familiar to CS types, because I consider myself to be one, and I never learned awk, either, but Python syntax doesn't look incomprehensible. But this is such a matter of taste that I'd fear to mention it, because syntax flamewars really are useless.
I think "my" is a feature, I just wish it was the default. However, Perl defaults to something simple for the novice--making variables global. Many other languages default to something similar. However, there's nothing wrong with telling a programmer to declare all (or almost all) of their variables with 'my' as a good programming practice; if they really want dynamic scope, they can use 'local', but they probably don't. I don't mind when Perl gives me a few options; actually, I like it. If I'm feeling Scheme-ish, I can use lexical scope and recursion; if I'm just quickly hacking, I can use global variables, iteration, and implicit looping (command-line switches for text filters...) and stuff. I'm sure you could hack a version of 'use strict' that enforces whatever particular programming paradigm you like better, (it favors 'my' variables in modules, incidentally) but that's a decision that I'd rather leave up to the programmer.
Perl can also compile to an intermediate byte-code form, and generally a well-written Perl program performs at a minimum as fast as your average interpreted language, and in a best case faster than C, (using nifty built-in data types and whatnot) but generally somewhere in between.
Incidentally, writing a simple C program is generally fastest, although there are a few instances where the C++/STL solution is faster. (the STL is incredibly well implemented on g++) Most interpreted procedural languages are generally about 10x slower, and most shell scripting languages are generally 10x slower than that, (100x slower than C!) but for some problems, certain interpreters pull ahead of the pack.
For instance, Python (and many functional languages) have a built-in arbitrary-precision number capability that is pretty well implemented. Perl has a module for this, but it is pretty slow; I think there's a faster one available, too. I know there are libraries to do this in C (like gmp), but they aren't necessarily there by default.
Not only is Perl extremely portable, and indeed already ported just about everywhere, but since it can generate code for itself in Bytecode and C, it's even more portable and flexible. (assuming you can compile the resultant C code...)
AFAIK, both Perl and Python use reference-counting garbage collectors; I know that there are a lot of great features slated for the *next* versions of Perl, and one of them on the drawing board is a real garbage collector; but that's probably on the TODO for the Python people as well.:)
Actually, I think the two are pretty even. Although I think Perl supports traditional functional programming better, I doubt many people would do it in Perl. (although I might try my hand at either writing a Scheme interpreter in Perl, or yet another Nth generation language; I'm silently debating to myself over syntax-parsing and data-type handling at the moment.) I agree that Python has a sparse looking syntax, but I'm not convinced that I like it yet, and therefore that's a style issue. Also, Perl is great for speeding up old shell scripts and migrating from sed or awk, and provides wonderful modules for CGI and database integration. I suppose Python has its own modules for this, but I like writing web pages in Perl better than writing them in HTML, and that's saying something, since I'd never use an "HTML Editor", either.
On the other hand, I think Python might make a good stepping-stone for people coming from a more academic, functional-programming background, and ultimately want to learn, say, Java. Although Perl has closer syntax, Python has some of the comforts of home, and has built-in exception handling. But ultimately, I guess it depends on what you want in a language, in the first place. --- pb Reply or e-mail; don't vaguely moderate.
If there's one thing I miss on Linux, it's good Codec support. I'd love to see a good, high-quality encoder come out of this, much like the LAME project did for mp3's.
...and if an open one is written, I'm sure all the other free OS people will be very happy too... --- pb Reply or e-mail; don't vaguely moderate.
Well, it was just a simple example of how to add syntax, really, but notice how cleanly it integrates into the rest of Perl; that's the impressive part.
I tend to use "my", and parse "@_", but like I said before, you can always pass a single reference as an argument, or use a reference to a hash essentially to pass around a namespace...
Perl does ask for more explicit information about everything, yes, and a friend of mine told me that there is a pretty fast third-party Perl compiler that his company uses internally, (so of course I haven't gotten to see it myself...:[ ) and maybe one day the Perl->C translator will get that good. I haven't really used Tcl either, but it looks like it has its own unique, interesting syntax, like every other glue language these days...
Also, the PerlC stuff makes it really easy to just import and use headers and libraries like native Perl stuff, I think that's the real feature there. They do make it harder to implement C extensions, but again most of the time you probably don't need to do that, and CPAN has more than enough modules for doing everything else... --- pb Reply or e-mail; don't vaguely moderate.
Probably all the Perl info you'd want can be found here. Near the bottom there's a section called "C and Perl", and that pretty much covers any C/Perl integration questions, and how to write extensions in C.
Perl supports prototypes, which let you control your function argument behavior, and create new syntax. The example I gave with exceptions is actually very clean, with no C-style hackery required.
The interesting thing about & is that you can generate new syntax with it:
sub try (&@) {
my($try,$catch) = @_;
eval { &$try };
if ($@) {
local $_ = $@;
&$catch;
}
}
sub catch (&) { $_[0] }
try {
die "phooey";
} catch {
/phooey/ and print "unphooey\n";
};
That prints "unphooey". (Yes, there are still unresolved issues having to do with the visibility of @_. I'm ignoring that question for the moment. (But note that if we make @_ lexically scoped, those anonymous subroutines can act like closures...
(Gee, is this sounding a little Lispish? (Never mind.))))
Otherwise, Perl implicitly takes argument lists; in fact, everything you pass to a non-prototyped function behaves exactly like an array of arguments (sort of like main() in C), and if you don't like that, you can always pass a reference to your own structures. More on all of this in the perlsub documentation. Check it out, it's very flexible as to how it handles function arguments and return values, and prototypes simply extend this further.
I agree that shell looks somewhat backwards compared to Pascal or C, (I never had to use Algol!) but it's a great tool for getting the job done, and that's why Perl is often patterned after it. It's like a shell language with support for everything in C and the standard Unix tools built-in, including the ideas of regexps from grep, the sort from qsort(), and whatnot. However, Perl doesn't have any arbitrary quoting, scoping, and argument-passing rules. It's quite clear on all of these points, and the quoting rules especially are very handy. And from what I've heard here, Python has some interesting scoping rules that aren't lexical or dynamic scope, while Perl supports either one, and more.
As to the variable names, well, I think I covered that point already. It might turn newbies away from Perl, but I think it isn't a bad paradigm to try. It at least makes you think about what type your variable is, which is something you should do anyhow. (In Scheme, you constantly check for it instead, which I also like; in C, well, you'd better remember which one you meant, as well...)
By the way, thanks for the feature debating! You don't have to stop just yet, but I want you to know that I actually find this part of the discussion fascinating, and fun. I was debating to myself just last night about how many details a language should really be allowed to handle, and how much of that a programmer should be able to tweak, and I'm sure there's a compromise in there somewhere. But you can't expect any language to really do the right thing without being too unwieldy to use... --- pb Reply or e-mail; don't vaguely moderate.
Perl supports lexical scope through the use of 'my' variables, and closures through the use of references to anonymous subroutines. Therefore, you can basically write Scheme-style function-returning functions, if you want to...
Its built-in data-types consist of scalars, (which can be numbers, strings, some weird stuff, and references to other stuff...:) arrays and hashes, and this can be extended through modules, objects, or essentially providing other methods for the built-in data types. (for example, you can tie a hash to a database instead of using the database calls)
Perl doesn't have a built-in exception system, but it has prototypes, which basically lets you add syntax to the language; there's a simple example (in Programming In Perl, I think) that adds a try..catch construct to the language.:)
Objects were definitely added to Perl later; I don't use them very often, and indeed could write it all myself if I had to, (lexical scoping, closures, and tools for adding syntax, right?:) but, that having been said, it also doesn't look that ugly to me, (maybe ugly is in the eye of the beholder...) and I've worked with many object-based Perl modules just fine. Actually, usually they provide *both* interfaces, and support operator overloading and type-conversion as well.
Perl does have features for integrating with other languages, and I've compiled Perl programs into C before as well, (it's generally about 30-40% faster, nothing impressive--it compiles too much of the Perl runtime into it still) and it also has a bytecode format, if people want that.
Python might follow the 'principle of least surprise' for someone unfamiliar with programming languages, but Perl looks like a few popular (also ugly?) languages, and might be better for migrating old Unix hackers as needed.:)
I don't think it'd be too hard to make a pre-processor to do either behavior; actually, I think a language with a flexible front-end tokenizer would be somewhat interesting, provided people always included their modifications in the source, or the program could always convert their code back to "standard" code.:)
Yeah, the built-in types vs. objects is always interesting; for the record, I don't like how Perl does it. References can be somewhat clumsy, and I'd rather be able to determine which type a scalar *really* is than automatically convert it. At least references know what type they are, though.
Obviously a lot of people don't like Perl syntax, and here are some of my thoughts on the matter:
I didn't like having to use $, @, and % all the time, either; it makes it look like a strict BASIC variant where you'd have to specify $, #, or % for different types. However, once I learned it, I found out two things: Most of the time, you just stick $ in front of a variable, because generally you're just working with scalars. Also, it forces you to think about which types you're using, and that can often be a good thing.
The braces and semicolons are pretty familiar for anyone who has used C and Pascal. With the way I write my code, I don't think I'd want whitespace as a seperator; I'll just use a pretty-printer for that. The other alternative, parentheses... well, a lot of people don't like that either.
There are lots of default arguments to functions in Perl, and they're pretty straightforward, and well-documented. But, that having been said, you don't have to use them. Pass as many useless parameters as you like, it's perfectly legal. But I don't find the way Perl handles default values that confusing, and if I don't know, well, I could always pass a variable to a function like usual, like I probably would if I didn't know that Perl had default values...
Other than that, I think that's about it; the two languages have a lot of similar features. From what I've seen here, it looks like Python has some interesting and powerful ones, but Perl generally has more flexibility, and maybe more of a learning curve, too. (don't ask me, it only took me a couple of days to learn, and a couple of weeks to get pretty comfortable with it...) --- pb Reply or e-mail; don't vaguely moderate.
*sigh* More nitpicking. Feel free to read my posts without actually understanding them.
Or... start debating programming language freatures. Not syntax; not grammar; not debating.
Is that so hard to understand?
If you like, you can read the *entire* series of posts yourself, and make your own conclusions, instead of picking one of them apart, out of context.
For instance:
Whether or not this is true (and I don't suppose you have a shred of proof)
I haven't seen any proof for the syntactic and styliistic "better" claims so far; why should I provide it? I *have* mentioned various different language features, and this has so far gone unnoticed.
That's no excuse for presuming to gainsay him on whether or not he had in fact used the languages in question.
My excuse for that was that he was debating syntax and the usefulness of linked lists, not lexical scope or closures. That is to say, he either managed to use Scheme without even *noticing* the useful features it provides, or didn't mention them in his reply.
You're generalizing from one poster on/. to the whole Python community?
Yes. That's how advocacy works. You play nice, and promote your language. Once you start being rude, you lose respect. You can analyze this at your leisure the beginning of this thread.
...but you don't seem to mind launching into an extended meta-debate. Personally, I think even the style debate was probably more worthwhile than a bunch of "did too, did not".
I don't think it was; I thought it was incredibly stupid, and I think this is too. But if I don't feel that you understood my post, then I will attempt to keep replying until you do.
Now here's the test. All that text before this line, what did it accomplish? Well, not much. So let's try again.
Riddle me this: does Python have lexical scope, closures, useful built-in data-types, familiar syntax, functions, variables, looping constructs, or objects? How does it help you manage a program better than, say, Perl? What does it *not* let you do that you might conceivably want to do, and how ugly are the methods used to get around this?
These are real questions, because I don't know Python. As I've said before, on the surface an average Python program looks like a Perl program without the curly brackets and the semicolons; instead it has labels and indentation and whitespace, which is strange, but still workable. Its arrays look pretty similar on the surface, it has modules and an object system, it appears to have built-in regexps, and it is also an interpreted scripting language.
So PLEASE tell me what I'm missing. To date, this entire flamewar has been completely useless, apparently based on semantics, or perhaps an incomprehensible hatred of the '@' symbol. All the Python code I've seen thus far could be run through a trivial translator to change the notation, and 90% of it would be workable Perl code, requiring little human translation.
So, if you can, tell me what's the big deal, and keep it clean this time. If you can't, well, don't reply again. --- pb Reply or e-mail; don't vaguely moderate.
No, I was talking about syntax vs. features, but that's okay.
Thanks for the links, I might check it out some more, later. However, I don't see anything incredibly new and different as compared to Perl; I guess liking the syntax better *is* the reason to use Python, because the featureset looks relatively similar.
(I like the built-in set support, but the __main__ stuff looks like a nasty hold-over from C; so far, this is all looking like another useless flame-war over two languages of very similar functionality and very different weird syntactical limitations...)
I picked Python over Perl years ago. However, if I were to make the choice today based on the behavior of each's proponents in this discussion I'd make it the same way.
Someone else said something about Perl's lower "barriers to entry" resulting in a high percentage of its advocates being inexperienced and immature programmers. I think that's exactly right, except that the inexperience applies to advocacy as well as coding styles.
I think that could be interpreted as being against low barriers to entry, but in any case, you can't get my quotes right either, so I wouldn't flame anyone else for it if I were you...
Also, I haven't 'picked' Python or Perl; I just don't know Python. But you haven't been terribly supportive, encouraging, or informative about it, so I think I like the Perl community better, so far. Of course, choosing a Language based on the behavior of its programmers is somewhat silly, but I did that with my Operating System as well.
In my experience, BSD Zealots tend to be rude and insufferable, while Linux Zealots are generally just enthusiastic. From this thread, it looks like Python Zealots are equally obnoxious due to their marginalized presence; perhaps they just feel persecuted.
This is just a generalization; I know there are some very polite and interesting BSD and Python users out there; but they can't seem to find their way to Slashdot, or are drowned out by whoever shouts the loudest. --- pb Reply or e-mail; don't vaguely moderate.
You took my fair test quote out of context; I will post what I said again, with emphasis, so you understand. Language syntax is one thing, but let's work on English first.
I dismiss syntax issues because that is a stylistic issue. You don't like Perl syntax, and from what I've seen, I don't like Python syntax.
Why? Well, you sit someone familiar with either C or shell script (like me) down in front of two moderately complicated Perl or Python programs, and see which one they figure out first.
Is that a fair test? No. Is that a test that goes on every day? Yes.
The test I was talking about has a slight difference; anyone with a C or shell script background would surely find Perl a more comfortable language. But I disregard this, because I'd rather hear about language features, and I don't consider Python 'syntax' a feature. It looks like Perl, but the braces and semicolons are gone, and it doesn't allow some other stuff. Ooo. I don't care.
Also, yes, you can write line noise in Perl. But you can also write clean code in Perl. It's your choice. The same is true for C. I don't necessarily *want* a language that ties my hands based on what the *implementors* thought was good and right and just; I might occasionally have a reason for what I want to do. I know someone who would love to have an actual goto statement in Java, for instance; and he has a very sane reason for it. If you don't believe in gotos either, well, I don't want to talk to you, either. My point is, there's nothing wrong with letting the programmer do more. If they don't want to do it, they won't; if they need to, they can. This goes for syntax *and* features, and sometimes the one gets in the way of the other.
My comments were based on his emphasis of syntax over features, even after I explicitly asked him to discuss language features. I think these are an important part of any language, because if a given feature is not supported, no amount of syntax will help you. If, after my request, he told me about the superior features Python had instead of demeaning Perl and Scheme, (with no real facts, just stylistic opinions, I might add!) I might have been kinder as well.
I mentioned BASIC not out of rudeness, but merely because it is a great example of a language with clean syntax and bare functionality.
I'd love to know more about Python, but if this is your idea of Python advocacy, I don't want it. There are friendlier communities of programmers out there, who would be happy to tell me about the language features and think that is important. At least you mentioned an example program that might be easier in Python; that interests me. The syntax flame-wars do not; I saw all that in the big Pascal/C flamewar back in the day. (I was sympathetic to the Pascal side, because Turbo Pascal 7 was dominant at the time, and it really did have all the features you'd want from C, except perhaps the 'unsigned longint' type, and maybe the C-style 'switch' statement; therefore, it was just another stupid syntax flamewar)
Anyone who wants to program in a structured way can; they can learn that discipline by having their compiler/interpreter shout at them, or by doing it themselves. I probably learned a lot of structure by moving from BASIC to Pascal; but I learned a lot more about power and simplicity by moving to C. I'd much rather see the discipline imposed by the programmer and not the language, but yes, that has to be learned somewhere along the way.
...and the advocacy bit was a cheap shot, and you didn't help your case any by calling me rude and quoting me out of context. Read my post again and apologize, or just reply to this one and tell me what features make Python a better language. I don't want to debate style with you. REALLY. --- pb Reply or e-mail; don't vaguely moderate.
I dismiss syntax issues because that is a stylistic issue. You don't like Perl syntax, and from what I've seen, I don't like Python syntax.
Why? Well, you sit someone familiar with either C or shell script (like me) down in front of two moderately complicated Perl or Python programs, and see which one they figure out first. Is that a fair test? No. Is that a test that goes on every day? Yes.
But I wasn't going to ask you that question, because syntax flamewars are meaningless. Also, judging from the Python code you have on your website, well, it looks a lot like perl code, without some braces and semicolons, and if that isn't a trivial syntax issue, then I don't know what is.
You're right that Scheme's syntax is particularly easy to parse, but it isn't just about linked-lists. Built-in linked-list support is *very* handy, and Perl offers something about as powerful with its arrays; I gather Python does as well. Also, as another poster mentioned, lexically-scoped variables and closures are also potentially very handy, and this can be done in Perl as well. (by passing and returning references to anonymous subroutines and by using 'my' variables; Perl also has dynamic scoping if you need it, but you probably don't want to do that...)
It sounds like you like Python, but it doesn't sound like you've *really* used all three languages. Or rather, you seem to appreciate syntax over language features. If this is the case, then try out BASIC, and you will see my point. --- pb Reply or e-mail; don't vaguely moderate.
1) Perl is a pretty cool language; I've used it. Cryptic, yet powerful, much like C. Also, I like being able to write some simple, powerful text processing, without being bogged down by the details.
2) Scheme is a pretty cool language; I've used it. Simple, with interesting choices for primitives and control structures. I like being able to make and extend a program with an amazing amount of flexibility, and easily implement new features.
3) Python might very well be a cool language as well. However, I haven't used it; I'd have to try it out and find a use for it, and it looks pretty weird. However, since you've offered no actual facts for your argument, and bashed two other languages that I consider to be pretty good, (even if they are generally slower than C;) then you haven't won any points with me; actually, you've lost a few.
4) Therefore, from (3), that's flamebait, not advocacy. Please reply with reasons that make Python a better choice than Perl or Scheme for a given problem domain, instead of "Python is so much better, and Perl and Scheme just suck". Syntax issues are irrelevant; I could probably write a tokenizer to get rid of the syntax issues involved, if I had to. Language support for features is relevant; (i.e. Scheme's choice of first-class types vs. Perl's references) also, implementation decisions are relevant (Perl and Scheme can be interpreted *or* compiled depending on the implementation, but generally are still slower than a truly compiled language because of their feature-sets, like "eval"). --- pb Reply or e-mail; don't vaguely moderate.
Slashdot Mirror
Actually, I was wrong: it's even easier.
:)
RealPlayer 7 on Linux uses esd, so just use esdmon to dump whatever input esd gets. Then encode it, it should be 44.1kHz, 16-bit audio by default.
I just dumped the sample sound, now I'll have to grab a decent encoder.
---
pb Reply or e-mail; don't vaguely moderate.
I believe it is, provided it isn't "circumvention" as opposed to just getting a client working.
/dev/audio. In that case, Real does all the circumvention for you. (Shouldn't be too hard to implement, right?)
Like, if you just re-wrote RealPlayer, you should be fine. Just don't save it to a file, because apparently decoding the file format is ok, but converting it isn't.
I know that doesn't make any sense. However, you could probably record everything that goes through
---
pb Reply or e-mail; don't vaguely moderate.
And, even if you are right, apparently they'd have to take it up with a librarian...
---
pb Reply or e-mail; don't vaguely moderate.
I have seen some code that plays older realaudio files, but that's about it. Also, I don't know a whole lot about audio codecs...
---
pb Reply or e-mail; don't vaguely moderate.
Why is this not allowed with a plug-in architecture? If RealNetworks doesn't like it, then they shouldn't have offered the functionality, or should stop everyone from using plug-ins.
;)
More specifically, could someone tell me what StreamBox was doing that was illegal, or is it just that RealNetworks and "The Powers That Be" don't like it, and will therefore make up a reason later...
Actually, Real is probably just jealous because they don't have a name like "Ferret"...
---
pb Reply or e-mail; don't vaguely moderate.
That looks like a handy little device, there...
WebTV on Linux, anyone?
Now, where does it say how much it costs? This might make a good, cheap X-terminal as well...
---
pb Reply or e-mail; don't vaguely moderate.
Embedded Java? On a bike?
Oh well, I guess that silly Java-on-a-wristwatch joke isn't as far away as I'd like it to be.
---
pb Reply or e-mail; don't vaguely moderate.
I couldn't find it at all; I did eventually find Capitol's website, and they have a Pink Floyd section with some entire songs in low-quality realaudio, and various different bitrates (up to 96kbps) for windows media.
However, for Dark Side of the Moon (and another 10 discs), they just link to Amazon.
---
pb Reply or e-mail; don't vaguely moderate.
Okay, I'll bite; how was my comment redundant?
I'd appreciate it if I didn't get moderated down for absolutely no reason, okay? If you do moderate either of these posts down, logout, and state your reason anonymously; I don't care about the karma, 'cause it'll take me a while to get back down to 50, high karma being meaningless now and all.....
---
pb Reply or e-mail; don't vaguely moderate.
I believe I already got a meaningless reply to that end, and ignored it.
This is stupid philosophical tripe.
How do you know that information is meaningless without humans? Don't you think that supernatural beings, aliens, badgers, or plants might use it to make decisions? For that matter, how do you know that information doesn't have a collective consciousness, impressed upon it from its owners?
Well, these are pretty silly points I'm bringing up, but the point is, you don't know. In fact, you can't know. And if you think you do, you could still be wrong.
And that is meaningless philosophical debate.
Now let me use my anthropomorphisms in peace.
---
pb Reply or e-mail; don't vaguely moderate.
I think that's 'horsepucky'. Did the rogue spell-checker bite you, Nick?
Also, some information *does* want to be freely available, like the whois database, or the song lyrics servers, and these are freely contributed, and unlawfully (in my opinion) restrained.
...so instead of trying to cash into the Napster phenomenon, do some *real* research, and find out something new.
---
pb Reply or e-mail; don't vaguely moderate.
About global variables: well, *real* novices don't know about subroutines, anyhow! ;)
:)
I'm sure Perl has modules geared towards language processing, and I might even look it up; but for some reason, I have a desire to implement that part myself at a lower level, as well. Maybe by learning lex better, for starters...
Another site I found that looks pretty useful for Perl info is "perldoc.com"; it looks like most of the 'new, bolted-on' features of perl started in 1993, with the development of Perl 5; they're debating about what'll go into Perl 6 now...
...And I like the mythology reference.
---
pb Reply or e-mail; don't vaguely moderate.
I haven't used exceptions; so far, it looks like a way to check for error codes after something has already screwed up, and I'm not convinced its a good approach yet. However, I'm also starting to learn Java, so I'm sure I'll see how they use it.
:)
I'm not even a huge Perl advocate, but I learned it for my job and thought it was pretty handy, especially for getting the job done quickly. I revamped a script to add accounts, and integrated a domain registration system with a credit card processing system; (the first was written in Perl; the second had a Perl API interface, and I found a credit-card module for another processing system that was also already in Perl...) I'm sure there's a lot of Python code out there too, but Perl is quickly becoming a favored language for CGI interactions. On the server side, there's also PHP and Java now, and PHP also looks a lot like Perl (and probably like Python too...).
I haven't played with Perl's Object system much, but I know it has one, so I can't really compare those two; it seems to work pretty well, though.
I'd argue over the syntax being more familiar to CS types, because I consider myself to be one, and I never learned awk, either, but Python syntax doesn't look incomprehensible. But this is such a matter of taste that I'd fear to mention it, because syntax flamewars really are useless.
I think "my" is a feature, I just wish it was the default. However, Perl defaults to something simple for the novice--making variables global. Many other languages default to something similar. However, there's nothing wrong with telling a programmer to declare all (or almost all) of their variables with 'my' as a good programming practice; if they really want dynamic scope, they can use 'local', but they probably don't. I don't mind when Perl gives me a few options; actually, I like it. If I'm feeling Scheme-ish, I can use lexical scope and recursion; if I'm just quickly hacking, I can use global variables, iteration, and implicit looping (command-line switches for text filters...) and stuff. I'm sure you could hack a version of 'use strict' that enforces whatever particular programming paradigm you like better, (it favors 'my' variables in modules, incidentally) but that's a decision that I'd rather leave up to the programmer.
Perl can also compile to an intermediate byte-code form, and generally a well-written Perl program performs at a minimum as fast as your average interpreted language, and in a best case faster than C, (using nifty built-in data types and whatnot) but generally somewhere in between.
Incidentally, writing a simple C program is generally fastest, although there are a few instances where the C++/STL solution is faster. (the STL is incredibly well implemented on g++) Most interpreted procedural languages are generally about 10x slower, and most shell scripting languages are generally 10x slower than that, (100x slower than C!) but for some problems, certain interpreters pull ahead of the pack.
For instance, Python (and many functional languages) have a built-in arbitrary-precision number capability that is pretty well implemented. Perl has a module for this, but it is pretty slow; I think there's a faster one available, too. I know there are libraries to do this in C (like gmp), but they aren't necessarily there by default.
Not only is Perl extremely portable, and indeed already ported just about everywhere, but since it can generate code for itself in Bytecode and C, it's even more portable and flexible. (assuming you can compile the resultant C code...)
AFAIK, both Perl and Python use reference-counting garbage collectors; I know that there are a lot of great features slated for the *next* versions of Perl, and one of them on the drawing board is a real garbage collector; but that's probably on the TODO for the Python people as well.
Actually, I think the two are pretty even. Although I think Perl supports traditional functional programming better, I doubt many people would do it in Perl. (although I might try my hand at either writing a Scheme interpreter in Perl, or yet another Nth generation language; I'm silently debating to myself over syntax-parsing and data-type handling at the moment.) I agree that Python has a sparse looking syntax, but I'm not convinced that I like it yet, and therefore that's a style issue. Also, Perl is great for speeding up old shell scripts and migrating from sed or awk, and provides wonderful modules for CGI and database integration. I suppose Python has its own modules for this, but I like writing web pages in Perl better than writing them in HTML, and that's saying something, since I'd never use an "HTML Editor", either.
On the other hand, I think Python might make a good stepping-stone for people coming from a more academic, functional-programming background, and ultimately want to learn, say, Java. Although Perl has closer syntax, Python has some of the comforts of home, and has built-in exception handling. But ultimately, I guess it depends on what you want in a language, in the first place.
---
pb Reply or e-mail; don't vaguely moderate.
Well, I'm going to check it out because the AVI plug-in claims to already play MPEG4-encoded files (.ASF).
;)
(But don't post too loudly, or the download site will get slashdotted!
---
pb Reply or e-mail; don't vaguely moderate.
Hmm. Whether you like Quicktime or not, I'm not sure if this will fly.
Can you make a module for a proprietary program under the GPL? Wouldn't it have to be LGPL'ed?
Someone enlighten me on this one, 'cause I'm not positive about it.
---
pb Reply or e-mail; don't vaguely moderate.
If there's one thing I miss on Linux, it's good Codec support. I'd love to see a good, high-quality encoder come out of this, much like the LAME project did for mp3's.
...and if an open one is written, I'm sure all the other free OS people will be very happy too...
---
pb Reply or e-mail; don't vaguely moderate.
Well, it was just a simple example of how to add syntax, really, but notice how cleanly it integrates into the rest of Perl; that's the impressive part.
:[ ) and maybe one day the Perl->C translator will get that good. I haven't really used Tcl either, but it looks like it has its own unique, interesting syntax, like every other glue language these days...
I tend to use "my", and parse "@_", but like I said before, you can always pass a single reference as an argument, or use a reference to a hash essentially to pass around a namespace...
Perl does ask for more explicit information about everything, yes, and a friend of mine told me that there is a pretty fast third-party Perl compiler that his company uses internally, (so of course I haven't gotten to see it myself...
Also, the PerlC stuff makes it really easy to just import and use headers and libraries like native Perl stuff, I think that's the real feature there. They do make it harder to implement C extensions, but again most of the time you probably don't need to do that, and CPAN has more than enough modules for doing everything else...
---
pb Reply or e-mail; don't vaguely moderate.
Perl supports prototypes, which let you control your function argument behavior, and create new syntax. The example I gave with exceptions is actually very clean, with no C-style hackery required.
Otherwise, Perl implicitly takes argument lists; in fact, everything you pass to a non-prototyped function behaves exactly like an array of arguments (sort of like main() in C), and if you don't like that, you can always pass a reference to your own structures. More on all of this in the perlsub documentation. Check it out, it's very flexible as to how it handles function arguments and return values, and prototypes simply extend this further.
I agree that shell looks somewhat backwards compared to Pascal or C, (I never had to use Algol!) but it's a great tool for getting the job done, and that's why Perl is often patterned after it. It's like a shell language with support for everything in C and the standard Unix tools built-in, including the ideas of regexps from grep, the sort from qsort(), and whatnot. However, Perl doesn't have any arbitrary quoting, scoping, and argument-passing rules. It's quite clear on all of these points, and the quoting rules especially are very handy. And from what I've heard here, Python has some interesting scoping rules that aren't lexical or dynamic scope, while Perl supports either one, and more.
As to the variable names, well, I think I covered that point already. It might turn newbies away from Perl, but I think it isn't a bad paradigm to try. It at least makes you think about what type your variable is, which is something you should do anyhow. (In Scheme, you constantly check for it instead, which I also like; in C, well, you'd better remember which one you meant, as well...)
By the way, thanks for the feature debating! You don't have to stop just yet, but I want you to know that I actually find this part of the discussion fascinating, and fun. I was debating to myself just last night about how many details a language should really be allowed to handle, and how much of that a programmer should be able to tweak, and I'm sure there's a compromise in there somewhere. But you can't expect any language to really do the right thing without being too unwieldy to use...
---
pb Reply or e-mail; don't vaguely moderate.
Perl supports lexical scope through the use of 'my' variables, and closures through the use of references to anonymous subroutines. Therefore, you can basically write Scheme-style function-returning functions, if you want to...
:) arrays and hashes, and this can be extended through modules, objects, or essentially providing other methods for the built-in data types. (for example, you can tie a hash to a database instead of using the database calls)
:)
:) but, that having been said, it also doesn't look that ugly to me, (maybe ugly is in the eye of the beholder...) and I've worked with many object-based Perl modules just fine. Actually, usually they provide *both* interfaces, and support operator overloading and type-conversion as well.
:)
:)
Its built-in data-types consist of scalars, (which can be numbers, strings, some weird stuff, and references to other stuff...
Perl doesn't have a built-in exception system, but it has prototypes, which basically lets you add syntax to the language; there's a simple example (in Programming In Perl, I think) that adds a try..catch construct to the language.
Objects were definitely added to Perl later; I don't use them very often, and indeed could write it all myself if I had to, (lexical scoping, closures, and tools for adding syntax, right?
Perl does have features for integrating with other languages, and I've compiled Perl programs into C before as well, (it's generally about 30-40% faster, nothing impressive--it compiles too much of the Perl runtime into it still) and it also has a bytecode format, if people want that.
Python might follow the 'principle of least surprise' for someone unfamiliar with programming languages, but Perl looks like a few popular (also ugly?) languages, and might be better for migrating old Unix hackers as needed.
I don't think it'd be too hard to make a pre-processor to do either behavior; actually, I think a language with a flexible front-end tokenizer would be somewhat interesting, provided people always included their modifications in the source, or the program could always convert their code back to "standard" code.
Yeah, the built-in types vs. objects is always interesting; for the record, I don't like how Perl does it. References can be somewhat clumsy, and I'd rather be able to determine which type a scalar *really* is than automatically convert it. At least references know what type they are, though.
Obviously a lot of people don't like Perl syntax, and here are some of my thoughts on the matter:
I didn't like having to use $, @, and % all the time, either; it makes it look like a strict BASIC variant where you'd have to specify $, #, or % for different types. However, once I learned it, I found out two things: Most of the time, you just stick $ in front of a variable, because generally you're just working with scalars. Also, it forces you to think about which types you're using, and that can often be a good thing.
The braces and semicolons are pretty familiar for anyone who has used C and Pascal. With the way I write my code, I don't think I'd want whitespace as a seperator; I'll just use a pretty-printer for that. The other alternative, parentheses... well, a lot of people don't like that either.
There are lots of default arguments to functions in Perl, and they're pretty straightforward, and well-documented. But, that having been said, you don't have to use them. Pass as many useless parameters as you like, it's perfectly legal. But I don't find the way Perl handles default values that confusing, and if I don't know, well, I could always pass a variable to a function like usual, like I probably would if I didn't know that Perl had default values...
Other than that, I think that's about it; the two languages have a lot of similar features. From what I've seen here, it looks like Python has some interesting and powerful ones, but Perl generally has more flexibility, and maybe more of a learning curve, too. (don't ask me, it only took me a couple of days to learn, and a couple of weeks to get pretty comfortable with it...)
---
pb Reply or e-mail; don't vaguely moderate.
*sigh* More nitpicking. Feel free to read my posts without actually understanding them.
/. to the whole Python community?
...but you don't seem to mind launching into an extended meta-debate. Personally, I think even the style debate was probably more worthwhile than a bunch of "did too, did not".
Or... start debating programming language freatures. Not syntax; not grammar; not debating.
Is that so hard to understand?
If you like, you can read the *entire* series of posts yourself, and make your own conclusions, instead of picking one of them apart, out of context.
For instance:
Whether or not this is true (and I don't suppose you have a shred of proof)
I haven't seen any proof for the syntactic and styliistic "better" claims so far; why should I provide it? I *have* mentioned various different language features, and this has so far gone unnoticed.
That's no excuse for presuming to gainsay him on whether or not he had in fact used the languages in question.
My excuse for that was that he was debating syntax and the usefulness of linked lists, not lexical scope or closures. That is to say, he either managed to use Scheme without even *noticing* the useful features it provides, or didn't mention them in his reply.
You're generalizing from one poster on
Yes. That's how advocacy works. You play nice, and promote your language. Once you start being rude, you lose respect. You can analyze this at your leisure the beginning of this thread.
I don't think it was; I thought it was incredibly stupid, and I think this is too. But if I don't feel that you understood my post, then I will attempt to keep replying until you do.
Now here's the test. All that text before this line, what did it accomplish? Well, not much. So let's try again.
Riddle me this: does Python have lexical scope, closures, useful built-in data-types, familiar syntax, functions, variables, looping constructs, or objects? How does it help you manage a program better than, say, Perl? What does it *not* let you do that you might conceivably want to do, and how ugly are the methods used to get around this?
These are real questions, because I don't know Python. As I've said before, on the surface an average Python program looks like a Perl program without the curly brackets and the semicolons; instead it has labels and indentation and whitespace, which is strange, but still workable. Its arrays look pretty similar on the surface, it has modules and an object system, it appears to have built-in regexps, and it is also an interpreted scripting language.
So PLEASE tell me what I'm missing. To date, this entire flamewar has been completely useless, apparently based on semantics, or perhaps an incomprehensible hatred of the '@' symbol. All the Python code I've seen thus far could be run through a trivial translator to change the notation, and 90% of it would be workable Perl code, requiring little human translation.
So, if you can, tell me what's the big deal, and keep it clean this time. If you can't, well, don't reply again.
---
pb Reply or e-mail; don't vaguely moderate.
No, I was talking about syntax vs. features, but that's okay.
Thanks for the links, I might check it out some more, later. However, I don't see anything incredibly new and different as compared to Perl; I guess liking the syntax better *is* the reason to use Python, because the featureset looks relatively similar.
(I like the built-in set support, but the __main__ stuff looks like a nasty hold-over from C; so far, this is all looking like another useless flame-war over two languages of very similar functionality and very different weird syntactical limitations...)
---
pb Reply or e-mail; don't vaguely moderate.
I think that could be interpreted as being against low barriers to entry, but in any case, you can't get my quotes right either, so I wouldn't flame anyone else for it if I were you...
Also, I haven't 'picked' Python or Perl; I just don't know Python. But you haven't been terribly supportive, encouraging, or informative about it, so I think I like the Perl community better, so far. Of course, choosing a Language based on the behavior of its programmers is somewhat silly, but I did that with my Operating System as well.
In my experience, BSD Zealots tend to be rude and insufferable, while Linux Zealots are generally just enthusiastic. From this thread, it looks like Python Zealots are equally obnoxious due to their marginalized presence; perhaps they just feel persecuted.
This is just a generalization; I know there are some very polite and interesting BSD and Python users out there; but they can't seem to find their way to Slashdot, or are drowned out by whoever shouts the loudest.
---
pb Reply or e-mail; don't vaguely moderate.
The test I was talking about has a slight difference; anyone with a C or shell script background would surely find Perl a more comfortable language. But I disregard this, because I'd rather hear about language features, and I don't consider Python 'syntax' a feature. It looks like Perl, but the braces and semicolons are gone, and it doesn't allow some other stuff. Ooo. I don't care.
Also, yes, you can write line noise in Perl. But you can also write clean code in Perl. It's your choice. The same is true for C. I don't necessarily *want* a language that ties my hands based on what the *implementors* thought was good and right and just; I might occasionally have a reason for what I want to do. I know someone who would love to have an actual goto statement in Java, for instance; and he has a very sane reason for it. If you don't believe in gotos either, well, I don't want to talk to you, either. My point is, there's nothing wrong with letting the programmer do more. If they don't want to do it, they won't; if they need to, they can. This goes for syntax *and* features, and sometimes the one gets in the way of the other.
My comments were based on his emphasis of syntax over features, even after I explicitly asked him to discuss language features. I think these are an important part of any language, because if a given feature is not supported, no amount of syntax will help you. If, after my request, he told me about the superior features Python had instead of demeaning Perl and Scheme, (with no real facts, just stylistic opinions, I might add!) I might have been kinder as well.
I mentioned BASIC not out of rudeness, but merely because it is a great example of a language with clean syntax and bare functionality.
I'd love to know more about Python, but if this is your idea of Python advocacy, I don't want it. There are friendlier communities of programmers out there, who would be happy to tell me about the language features and think that is important. At least you mentioned an example program that might be easier in Python; that interests me. The syntax flame-wars do not; I saw all that in the big Pascal/C flamewar back in the day. (I was sympathetic to the Pascal side, because Turbo Pascal 7 was dominant at the time, and it really did have all the features you'd want from C, except perhaps the 'unsigned longint' type, and maybe the C-style 'switch' statement; therefore, it was just another stupid syntax flamewar)
Anyone who wants to program in a structured way can; they can learn that discipline by having their compiler/interpreter shout at them, or by doing it themselves. I probably learned a lot of structure by moving from BASIC to Pascal; but I learned a lot more about power and simplicity by moving to C. I'd much rather see the discipline imposed by the programmer and not the language, but yes, that has to be learned somewhere along the way.
...and the advocacy bit was a cheap shot, and you didn't help your case any by calling me rude and quoting me out of context. Read my post again and apologize, or just reply to this one and tell me what features make Python a better language. I don't want to debate style with you. REALLY.
---
pb Reply or e-mail; don't vaguely moderate.
I dismiss syntax issues because that is a stylistic issue. You don't like Perl syntax, and from what I've seen, I don't like Python syntax.
Why? Well, you sit someone familiar with either C or shell script (like me) down in front of two moderately complicated Perl or Python programs, and see which one they figure out first. Is that a fair test? No. Is that a test that goes on every day? Yes.
But I wasn't going to ask you that question, because syntax flamewars are meaningless. Also, judging from the Python code you have on your website, well, it looks a lot like perl code, without some braces and semicolons, and if that isn't a trivial syntax issue, then I don't know what is.
You're right that Scheme's syntax is particularly easy to parse, but it isn't just about linked-lists. Built-in linked-list support is *very* handy, and Perl offers something about as powerful with its arrays; I gather Python does as well. Also, as another poster mentioned, lexically-scoped variables and closures are also potentially very handy, and this can be done in Perl as well. (by passing and returning references to anonymous subroutines and by using 'my' variables; Perl also has dynamic scoping if you need it, but you probably don't want to do that...)
It sounds like you like Python, but it doesn't sound like you've *really* used all three languages. Or rather, you seem to appreciate syntax over language features. If this is the case, then try out BASIC, and you will see my point.
---
pb Reply or e-mail; don't vaguely moderate.
Yes, that is flamebait, and I'll tell you why.
;) then you haven't won any points with me; actually, you've lost a few.
1) Perl is a pretty cool language; I've used it. Cryptic, yet powerful, much like C. Also, I like being able to write some simple, powerful text processing, without being bogged down by the details.
2) Scheme is a pretty cool language; I've used it. Simple, with interesting choices for primitives and control structures. I like being able to make and extend a program with an amazing amount of flexibility, and easily implement new features.
3) Python might very well be a cool language as well. However, I haven't used it; I'd have to try it out and find a use for it, and it looks pretty weird. However, since you've offered no actual facts for your argument, and bashed two other languages that I consider to be pretty good, (even if they are generally slower than C
4) Therefore, from (3), that's flamebait, not advocacy. Please reply with reasons that make Python a better choice than Perl or Scheme for a given problem domain, instead of "Python is so much better, and Perl and Scheme just suck". Syntax issues are irrelevant; I could probably write a tokenizer to get rid of the syntax issues involved, if I had to. Language support for features is relevant; (i.e. Scheme's choice of first-class types vs. Perl's references) also, implementation decisions are relevant (Perl and Scheme can be interpreted *or* compiled depending on the implementation, but generally are still slower than a truly compiled language because of their feature-sets, like "eval").
---
pb Reply or e-mail; don't vaguely moderate.