Jack
I don't doubt that it's a major project to move away from Perl, but IME of troubleshooting development projects, sometimes you do have to take a step backwards to go further forwards. (I don't know enough to suggest that that's the case here, I hasten to add).
I take your point about the overkill of today's hardware, but that's exactly what's produced all that large, slow, resource hungry un-managable code out there isn't it? Lean & Mean (TM), I say ;-)
The thing is, I'm running a XP on a 2.5G P4 with 256M RAM (not enough I know), with a test db of less that 400 songs and Slimserver with Softsqueeze frequently pauses playing if I pull up a page on the web. The HTML interface and the fishbone skin in particular is really excellent, but the refresh is painfully slow and bit clunky. My concern is that if the average 'joe' tests out slimserver on his windows computer before buying a Squeezebox, and gets the same results, he probably won't bother - and that would be a real shame.
To me it just seems a bit counter-productive to be adding new features on top, if the basic code isn't fast and clean. I can put up with a few bugs, but the music has to keep playing!
Anyway, I think my SB2 might arrive tomorrow; I'm really looking forward to it and I know just how hard everyone at slim devices has worked to get it (and the software to run it) to me. So thanks!
-----Original Message-----
From: discuss-bounces (AT) lists (DOT) slimdevices.com
[mailto:discuss-bounces (AT) lists (DOT) slimdevices.com]On Behalf Of Jack Coates
Sent: 04 April 2005 16:45
To: Slim Devices Discussion
Subject: [slim] "EMPTY" when browsing
Patrick Dixon wrote:
> A couple of things do worry me though, and they are probably a result of my unfamilirity with Perl and the open-source community. I wonder whether the choice of Perl is now causing many of the 'resource hogging' problems that seem to be at the root of many of the complaints. As the size and complexity of the code has increased, is the overhead of an interpreted language just too much? The other thing that worries me is the structure and documentation of the code itself. I know (again from personal experience) that when the pressure's on, dotting 'i's and crossing 't's is the first thing to go, and (to me) Perl looks very terse and unstuctured anyway. That can't make it easy to develop and maintain.
>
Nah. Remember what incredible overkill today's system is, and remember
that all three target OS's are pretty good at multi-tasking. The CPU/RAM
overhead of interpreted language is absolutely nothing.
One thing to realize is that rewriting the source code, test suite, and
build environment from the ground up in cross-platform code written in a
low-level compiled language is a big project. Like, hire three
engineers, buy a couple of servers and estimate 12-18 months from start
to the present level of stability. You think switching meta-data storage
backends destabilized the system? Ha. Then add in the joy of low-level
memory management and security holes galore because the low-level
compiled language expects the programmer to take care of all that.
Cross-platform interpreted languages are a Good Thing(TM). Perl is a
good thing. More importantly, ditching everything and rebuilding from
scratch is a Bad Thing(TM).
I've worked with and sold much buggier products than this one, lighten
up folks. You're getting what you paid for and a lot more. Bugs are part
of the territory.
--
Jack at Monkeynoodle dot Org: It's a Scientific Venture...
Riding the Emergency Third Rail Power Trip since 1996!
I don't doubt that it's a major project to move away from Perl, but IME of troubleshooting development projects, sometimes you do have to take a step backwards to go further forwards. (I don't know enough to suggest that that's the case here, I hasten to add).
I take your point about the overkill of today's hardware, but that's exactly what's produced all that large, slow, resource hungry un-managable code out there isn't it? Lean & Mean (TM), I say ;-)
The thing is, I'm running a XP on a 2.5G P4 with 256M RAM (not enough I know), with a test db of less that 400 songs and Slimserver with Softsqueeze frequently pauses playing if I pull up a page on the web. The HTML interface and the fishbone skin in particular is really excellent, but the refresh is painfully slow and bit clunky. My concern is that if the average 'joe' tests out slimserver on his windows computer before buying a Squeezebox, and gets the same results, he probably won't bother - and that would be a real shame.
To me it just seems a bit counter-productive to be adding new features on top, if the basic code isn't fast and clean. I can put up with a few bugs, but the music has to keep playing!
Anyway, I think my SB2 might arrive tomorrow; I'm really looking forward to it and I know just how hard everyone at slim devices has worked to get it (and the software to run it) to me. So thanks!
-----Original Message-----
From: discuss-bounces (AT) lists (DOT) slimdevices.com
[mailto:discuss-bounces (AT) lists (DOT) slimdevices.com]On Behalf Of Jack Coates
Sent: 04 April 2005 16:45
To: Slim Devices Discussion
Subject: [slim] "EMPTY" when browsing
Patrick Dixon wrote:
> A couple of things do worry me though, and they are probably a result of my unfamilirity with Perl and the open-source community. I wonder whether the choice of Perl is now causing many of the 'resource hogging' problems that seem to be at the root of many of the complaints. As the size and complexity of the code has increased, is the overhead of an interpreted language just too much? The other thing that worries me is the structure and documentation of the code itself. I know (again from personal experience) that when the pressure's on, dotting 'i's and crossing 't's is the first thing to go, and (to me) Perl looks very terse and unstuctured anyway. That can't make it easy to develop and maintain.
>
Nah. Remember what incredible overkill today's system is, and remember
that all three target OS's are pretty good at multi-tasking. The CPU/RAM
overhead of interpreted language is absolutely nothing.
One thing to realize is that rewriting the source code, test suite, and
build environment from the ground up in cross-platform code written in a
low-level compiled language is a big project. Like, hire three
engineers, buy a couple of servers and estimate 12-18 months from start
to the present level of stability. You think switching meta-data storage
backends destabilized the system? Ha. Then add in the joy of low-level
memory management and security holes galore because the low-level
compiled language expects the programmer to take care of all that.
Cross-platform interpreted languages are a Good Thing(TM). Perl is a
good thing. More importantly, ditching everything and rebuilding from
scratch is a Bad Thing(TM).
I've worked with and sold much buggier products than this one, lighten
up folks. You're getting what you paid for and a lot more. Bugs are part
of the territory.
--
Jack at Monkeynoodle dot Org: It's a Scientific Venture...
Riding the Emergency Third Rail Power Trip since 1996!