Main Stories
Slash Boxes

Slash Open Source Project

Slashcode Log In

Log In

[ Create a new account ]

Slash BOF at Open Source Convention

posted by pudge on 12:02 PM July 17th, 2000   Printer-friendly   Email story
OK, if you are at the O'Reilly Open Source Software Convention on Tuesday, meet us in San Carlos II for a Slashcode BOF. Hopefully, I and Pat and Brian will all be here. Bring your questions and your hate-filled venom and your suggestions to port Slash to ASP.
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login
Loading... please wait.
  • ... you'd realize how much time you've wasted on such idle wondering. :-)
  • by Anonymous Coward
    Actually it would be nice if the Slash core were written in a such a way that its API were accessible via ANY web scripting language or application server. That way you could have a frontend written in mod_perl, PHP, Zope, ASP, JSP, etc.

    If it were done right you could even put something like an NNTP or mailing list interface onto the comments section.
  • Guys - I just wanted to put my two cents in. PHP is not any more easier than Perl, Java, or C. It's all in what you're good at. If you want to port slash to PHP, then join the PHPSlash contingent. Honest to God, there's no reason anyone should be complaining about the fact that Slash is in perl. It runs Slashdot. What more proof do you need?

    As far as perl not being readable - I completly disagree. I would also like to throw in that I never considered Java a serious language until it recently added RegExp support. Perl is readable if you know how to read.

    Functionally - perl is incredible. I got Slash ported to Interbase in a little under an hour. Right now my Slash installation generates pages from MySQL, Interbase, and SQL Server 7. I know for a fact you can't do it that fast in PHP.

    Again, stick with PHP if it's what you like. PHPSlash is there, and it's not bad. But I'm sure I'm speaking for alot of people when I say that Pure-slash is best left in perl.

    BTW - pudge talked about the lack of support for people using slash in Windows. I agree with him when he says that there are better things to do. But I also realize that working in the corporate world that sometimes Linux is just not an option. I currently have a Windows box running Apache, mod_perl, and slash on WinNT 4.0 - however I'm using Interbase to drive it. Porting it to another database took about 3 hours. You could even use MySQL on Windows if you wanted. I'm preparing a Windows/Slash installation guide when I get some time next month, so I hope to help people out. If you want to help me, however, drop a line.

    To the people who complain about lack of support on Windows - Have you guys even tried installing it yet? It's not that hard....
  • Hell no.

    No, PHP [php.net] is the way to go.

    If I had a dime for every time I've wished that Slash could have been wrítten in PHP...

  • I dream of the day where I can read the line "Slash 2000 announced - new Slash branch, from now on using PHP" on SlashCode... ;-)

    Well, what good would dreams be if they all came true?

    The Apache + mod_perl + Perl requirement is simply too much on Windows, not to speak of the $MAX_INT module requirements

    It shouldn't be too much on Windows. All those pieces run fine on Windows, that I know of. I know Perl is fine. I've heard Apache and mod_perl are fine. And what are you referring to with MAX_INT? I've never been told of any such problems.

    We get no reports about Windows. As far as I know, it could be trivial to get it running on Windows. But I don't know, because I have more important things to do. If someone wants to report back on their specific problems running it on Windows, that could help everyone who wants to run it on Windows (although, be forewarned that because bender has so many code changes, any "fixes" to get it running on Windows may or may not be applicable).

    Even on unix it's a head ache due to the strict version requirements.

    They really are not very strict at all. We give you the versions we have tested on, but any perl 5.005_x, mysql 3.22.y, and Apache 1.3.z should work (and almost every installation of these tools that I can think of adhere to these versions). These restrictions are no more strict than the "Slash clone" you're referring to. I am sure it would not work with every MySQL version out there, nor with old versions of PHP.

    Slash in PHP would also have the advantage of readable code

    This just makes your whole rant look silly. Perl is readable. To the overwhelming majority of hackers, our Perl in Slash is far more readable than any PHP code you could have, simply because more people know Perl. If you cannot read most Perl code, as you say, then it is probably because you don't know much Perl. Well, the solution to that is obvious: learn Perl. And get over it. I don't even need to go into the multitude of reasons why Perl is better. I started to, but I realized it is unnecessary. Those who already know don't need me to tell them, and those unlucky few who disbelieve refuse to be convinced.

    It seems like you are blaming us for forcing you into a duplication of effort. That's just odd. Slash was first. It was done in what I unashamedly note is clearly the best tool for the job, Perl. You disagree, as is your right. What you decide to do from there is your business, your responsibility, and, if it is a problem, your problem.

    I think I've read that the reason Rob chose Perl from the start was that he was used to Perl -- there was no other reason than that.

    I don't know if that is why he chose Perl to begin with, but he continued on with it because he realized Perl is the best choice.

  • by Anonymous Coward
    I don't care about ASP, but Cold Fusion might be nice... :)
  • by Anonymous Coward
    Um, I hereby request that You All rewrite this here Slash package in shell-script, or possbily even MS-DOS batch files.
  • How about an ISO image so I can just burn a CD with EVERYTHING needed for Slash on it? This would save me a tremendous amount of time, AND would be bennificial to the Slash community as it would provide a baseline level set of packages for those of us who don't have everything already installed. It would also be way cool since I have a nice fat pipe at work, and a burner there as well. This would totally rock.
    --


    "How about you interface with my ass? By biting it!" --Bender
  • I'd love your installation guide for windows. There's certainly need for it, because I don't think it's that easy as everybody else seem to think... I could be wrong, and the best thing would probably be to have a step-for-step installation guide to compare with.

    As for Slash clones in PHP, I'd never recommend PHPSlash. PHPSlash requires PHPlib, and it's not better in portability than mod_perl. My recommendation is ThatPHPware [atthat.com] (don't be fooled by that site itself, though, it runs an old copy of the code). The requirements are just PHP3 and MySQL, which makes it a dream in portability.


  • I would just like to point out that slash has been rewritten into many different languages except the fact that none of them are supported by slashdot/code. There is a similar program in php, asp, python/zope, and another in mod_perl. I can't give you the url's to all of these places but I can tell you that they do exist.
  • A few of those modules are availiable as CPAN modules and easily installed.

    All of them are on CPAN. All of them install easily on Unix and even on Mac OS (except for the Apache and Mysql modules, since there is no Apache or MySQL for Mac OS [basically]). As to Windows, well, I don't know.

    We get no reports about Windows.

    That might be because those who are interested in getting something like Slash running on Windows, and then see the Slash INSTALL file, run away screaming. Wordings like

    You MUST install mod_perl and Apache as directed here. OK, that is not strictly true, but it is mostly true. If you already have mod_perl installed, chances are it is not configured properly to work with Slash and you must rebuild it. If you are using the provided httpd.conf file from the slash distribution, and Apache is giving you errors, chances are mod_perl is not installed correctly, and you need to build it from scratch.

    I don't see the problem. People SHOULD run screaming if they read that and want to work on Windows and don't really know what they are doing. That's a good thing.

    That's the problem. None of the Slash developers runs it on Windows, or has even tried it.

    But I don't see that as a problem any more than I see that it isn't tested on VMS as a problem. Yes, it is a problem for you, of course, just as it would be a problem for a VMS user.

    And all work to get it running under Windows would be hard to do, as it would be, as you say, adding some non-prioritized serious changes (can you say "remove Perl module dependencies"?) to a fast moving target.

    The Perl module dependencies will not be removed. They are Good, because they mean less work for us. All of the modules should run fine on Windows. Find a perl for Win32 support group, mailing list, etc. if you need help. You could also note which modules you're having problems with. From the other user who tried it, he basically said (if I am properly representing his experience) that the Perl wasn't a problem, the database porting was.

    The modules come in three parts: general Perl extensions that work everywhere (including MacPerl), Mysql stuff (I have no idea if it will work with Windows), and Apache stuff (it should work the same under Windows as it does under Unix, but you need to find out from mod_perl/Windows users about that). If ActiveState would properly support the CPAN module, installing would be pretty simple. But they don't, so our Bundle::Slash, which makes installlation on Unix a breeze, doesn't help Windows users. Maybe you can get someone to help you build an ActivePerl / PPM package for it. ActivePerl supports bunches of binaries, I am sure Dick & co. over at ActiveState would love to help make Slash work on Windows more easily.

    Both PHP and MySQL are availiable in easily installed binary distributions, and there are no additional module requirements - it doesn't get much simpler than that to use it on another platform.

    But as noted by many people, Slash has many more features than these other systems.

    This just makes your whole rant look silly. Perl is readable. To the overwhelming majority of hackers, our Perl in Slash is far more readable than any PHP code you could have, simply because more people know Perl.

    I don't think that's true. Granted, many people know Perl, and that's because it has existed for so long.

    That is part of the reason why, sure. But it doesn't change the Fact that far more people can read Perl than can read PHP.

    One of my closest friends is also working this summer, and he happened to end up working for a company and put something together as an intranet database interface or so (I don't know exactly what he's doing), and he ended up with having to learn PHP. The learning process never happened - he already knew it. He's a skilled C programmer, so he was already familiar with it (although he has some minor problems with the concept of web programming in general *grin*).

    I don't think there's a lot of Perl success stories like that. I know some people that are good at Perl, but none of them claim that Perl is easy.

    Actually, many people claim Perl is easy. I am one of them. And there are innumerable Perl success stories like that. And your claim of PHP being the same as C is odd, since it is pretty much equal parts Perl and PHP. Those who don't know C or PHP, but know Perl, also have little trouble learning PHP. Probably even less trouble than someone who only knows C.

    Now it's your turn to make a silly argument. What makes Perl better? I've never heard such comparisons in terms of features, and it would be interesting to hear them. But without some back-up, it just makes a silly argument.

    This is not the place, and this post is already way too long. There are plenty of treatises online for why Perl is great.

    I had no preference to begin with, so I think I might have been more objective in my decisions.

    You have biases, too. You are biased toward an appearance of ease of use. But in my learned opinion, it is only an appearance. I don't think PHP is any easier, whatsoever. Maybe to those who don't know either, it is easier to pick up and get going.

    I'm sorry if I'm complaining, but I think input is important.

    Sure. But what are you really complaining about in substance? You want what we cannot give you. You want us to remove module dependencies that make our lives much easier (`perl -MCPAN -e "install 'Bundle::Slash'"`, done!); you want it to work under Windows, which we can't make time to do; you want us to rewrite Slash in a less powerful, less interesting, less fun language that isn't any easier to use. Complaining is fine, it's just that you want what we either can't offer or don't want to offer, all for very good reason.

    In short, he used Perl because he already knew it.

    You forgot about the part where he said he loves Perl. It wasn't just that he knew it. Like many of us, he loves the language.

  • Actually, I'm serious... And as I can't attend that conference, here comes my rant...

    I dream of the day where I can read the line "Slash 2000 announced - new Slash branch, from now on using PHP" on SlashCode... ;-)

    That day my portability problems would just be gone -- I wan't to use a Slash-style site at work, but unfortunately I'm forced to do it on Windows. Getting Slash to work on Windows is a myth as far as I know -- I haven't had any success, and appearantly noone else has. The Apache + mod_perl + Perl requirement is simply too much on Windows, not to speak of the $MAX_INT module requirements. Even on unix it's a head ache due to the strict version requirements.
    In contrast, the Slash clone [atthat.com] I've been looking at just has two requirements - PHP3 and MySQL. Both of them are no problems even on a bizarre platform like Windows. Heck, you can run PHP even with IIS if you have to. I like this freedom.

    Slash in PHP would also have the advantage of readable code -- I know that Perl can be elegantly written, but I also know that it can be written totally unreadable, and in my experience the latter is more common. I, and many others, prefer C-syntactic code. I can read most PHP code just fine, but I can't read most Perl code.

    If you've read this far you're probably asking why I don't use one of the MAX_INT Slash clones. The answer is... yes, I do use one (see above), I've also contributed code to it, but in general these clones often lack a lot of important features that's in Slash -- Slash is simply the original and best in terms of features. Granted, the clone I'm using has both i18n support and themes support, but it lacks a lot of the nice slashbox features (moveable slashboxes is one of them) and most of the user preferences and options in Slash. Features I've got used to and really miss from Slash, and that are really useful... :-(

    I think I've read that the reason Rob chose Perl from the start was that he was used to Perl -- there was no other reason than that. Granted, nowadays when most people working full-time on Slash are professional Perl monks, there's not much incentive to change that decision. But I keep on wishing it could happen some time... and in the mean time, I'll try to help out a clone project. But I really hate the duplicating of efforts...

  • by Anonymous Coward
    PHP all the way...plus can't you convert PHP to ASP real easy like?
  • It shouldn't be too much on Windows. All those pieces run fine on Windows, that I know of. I know Perl is fine. I've heard Apache and mod_perl are fine. And what are you referring to with MAX_INT? I've never been told of any such problems.

    It has been a month since I tried getting Slash up and running, so I hope you forgive me if I don't remember everything perfectly. Anyway:

    Well Apache is fine, as you say. I run the slash clone I'm using with Apache under WinNT Workstation, because I know Apache, and IIS requires WinNT Server. There is a fine binary distribution for Win32, so that's no problem (but although I love Apache I think it's a problem that Slash requires Apache, because Apache under Windows is still beta).

    Then we have mod_perl and Perl. I tried ActiveState Perl at first but then someone here gav me the tip [slashcode.com] that there was a precompiled apache+mod_perl distro for Windows so I tried it, and this was fine. Compiling something developed for another platform is a pain in Windows so recompiling is often simply not an option, even if it's possible in theory.

    After this it was time to install modules - the Slash module requirements listed in the INSTALL are not just a few, hence my MAX_INT sarcasm.

    A few of those modules are availiable as CPAN modules and easily installed. The rest weren't - and - well some of them I could hardly even find, and at least one of them were like two modules in one. This was all just a head ache. To install them, I tried to pack them as CPAN modules (I found some instructions for that) but that didn't always work. In the end, I had some modules that got installed and a lot of modules that I'd found but failed to pack/install.

    We get no reports about Windows.

    That might be because those who are interested in getting something like Slash running on Windows, and then see the Slash INSTALL file, run away screaming. Wordings like

    You MUST install mod_perl and Apache as directed here. OK, that is not strictly true, but it is mostly true. If you already have mod_perl installed, chances are it is not configured properly to work with Slash and you must rebuild it. If you are using the provided httpd.conf file from the slash distribution, and Apache is giving you errors, chances are mod_perl is not installed correctly, and you need to build it from scratch.

    doesn't give someone who is going to get it to work much confidence. See my comment above about recompiling.

    As far as I know, it could be trivial to get it running on Windows. But I don't know, because I have more important things to do. If someone wants to report back on their specific problems running it on Windows, that could help everyone who wants to run it on Windows (although, be forewarned that because bender has so many code changes, any "fixes" to get it running on Windows may or may not be applicable).

    That's the problem. None of the Slash developers runs it on Windows, or has even tried it. I don't blame anyone for that, because I wouldn't do it myself if I weren't forced to use Windows. But it makes it much harder to get it working, because no one even knows if it will work. And all work to get it running under Windows would be hard to do, as it would be, as you say, adding some non-prioritized serious changes (can you say "remove Perl module dependencies"?) to a fast moving target.

    They really are not very strict at all. We give you the versions we have tested on, but any perl 5.005_x, mysql 3.22.y, and Apache 1.3.z should work (and almost every installation of these tools that I can think of adhere to these versions). These restrictions are no more strict than the "Slash clone" you're referring to. I am sure it would not work with every MySQL version out there, nor with old versions of PHP.

    Ok, I might have been off there with the version requirements. I interpreted them as being very strict, not just something like "we've only tested with this, but it should probably work with other versions too".

    But I think you're wrong about the Slash clone. The requirements are PHP, preferably version 3 (there is a known bug with PHP4 in one of the scripts). Most 3.x versions will work, and work out of the box.
    I the case of MySQL, I don't actually know a version requirement for the clone. I run 3.22.21 as I want it under GPL license, but I think any 3.21 or 3.22 version will do.

    Both PHP and MySQL are availiable in easily installed binary distributions, and there are no additional module requirements - it doesn't get much simpler than that to use it on another platform.

    This just makes your whole rant look silly. Perl is readable. To the overwhelming majority of hackers, our Perl in Slash is far more readable than any PHP code you could have, simply because more people know Perl.

    I don't think that's true. Granted, many people know Perl, and that's because it has existed for so long. But learning Perl requires a lot more compared to PHP - PHP is mostly plain C syntax, and the differences are few. The Slash clone in PHP I looked at was my first PHP thing ever - I never had a look at PHP before that. It was one of my "I'll do learn it some time in the future" things, right next to learning Perl. After a week, I was already contributing code. Granted, I don't feel much incentive now after this for learning Perl.

    One of my closest friends is also working this summer, and he happened to end up working for a company and put something together as an intranet database interface or so (I don't know exactly what he's doing), and he ended up with having to learn PHP. The learning process never happened - he already knew it. He's a skilled C programmer, so he was already familiar with it (although he has some minor problems with the concept of web programming in general *grin*).

    I don't think there's a lot of Perl success stories like that. I know some people that are good at Perl, but none of them claim that Perl is easy.

    If you cannot read most Perl code, as you say, then it is probably because you don't know much Perl. Well, the solution to that is obvious: learn Perl. And get over it. I don't even need to go into the multitude of reasons why Perl is better. I started to, but I realized it is unnecessary. Those who already know don't need me to tell them, and those unlucky few who disbelieve refuse to be convinced.

    Now it's your turn to make a silly argument. What makes Perl better? I've never heard such comparisons in terms of features, and it would be interesting to hear them. But without some back-up, it just makes a silly argument.

    It seems like you are blaming us for forcing you into a duplication of effort. That's just odd.

    Naah.. But maybe it's just me. Do I have to add that I think the whole issue of KDE vs. GNOME is unnecessary too? I think all such duplication of efforts is kind of sad, actually. God knows what would have been if all resources were used together.

    Slash was first.

    Granted. Slash was first, and it's probably still the best (in terms of features, I'm really impressed with what you've done!!!). One can even say that Slash was revolutionary -- look how many clones there are now. I'd say that's a good proof of how successful the concept of Slash has been.

    It was done in what I unashamedly note is clearly the best tool for the job, Perl. You disagree, as is your right. What you decide to do from there is your business, your responsibility, and, if it is a problem, your problem.

    Sure. But you're a Perl monk ;)
    I had no preference to begin with, so I think I might have been more objective in my decisions.
    I'm sorry if I'm complaining, but I think input is important. You're free to disregard any of my "complaining" as you wish -- but I'm afraid you would be missing some interesting input and views in doing that.

    I think I've read that the reason Rob chose Perl from the start was that he was used to Perl -- there was no other reason than that.

    I don't know if that is why he chose Perl to begin with, but he continued on with it because he realized Perl is the best choice.

    No, that's not what I've heard. From the Slashdot FAQ [slashdot.org]:

    Have you considered PHP?

    I tried PHP briefly but rejected it in favor of Perl. This is in no way a criticism of PHP, I just knew Perl already and was quite in love with the language. This was several years ago, and I understand PHP has grown and matured greatly since I made this decision, so my guess is that the limitations and awkwardness that made it undesirable to me back then is largely gone. But at this point, we have a substantial code base all written in Perl, and the effort involved in rewriting it would be prohibitive.

    In short, he used Perl because he already knew it.


  • Then do it yourself! That's why it's OpenSourced.