On Sunday, Jul 20, 2003, at 13:42 US/Eastern, Randal L. Schwartz wrote:
Well-written Perl is just as readable as any other language.
Problem is (1) most people don't bother learning Perl as well
as they learn other languages (since it's so easy to do things
with a minimal understanding) and (2) th
I just got back from my trip, I will work on my code over the next week
(Yay, vacation!) and hopefully have some prototype material by then.
On Sunday, Jul 20, 2003, at 03:58 US/Eastern, Randal L. Schwartz wrote:
Why objective-C? Perl would get the job done faster, cheaper, and
with a larger ins
Am Dienstag, 22.07.03 um 11:39 Uhr schrieb Nigel Stanger:
On 21/7/2003 10:26 AM, Max Horn at [EMAIL PROTECTED] spake thus:
For
example the fact that we have completely variable number of fields in
a
package; most DBs (including all (rational) SQL DBs) have a fixed set
of records.
Easy to do in S
Am Sonntag, 20.07.03 um 17:23 Uhr schrieb Randal L. Schwartz:
"Max" == Max Horn <[EMAIL PROTECTED]> writes:
Max> I don't think any of our performance problems are due to perl
anyway,
Max> and so far nobody (including Kyle) has been able to prove
Max> otherwise. All bottlenecks I see so far are di
> "Hisashi" == Hisashi T Fujinaka <[EMAIL PROTECTED]> writes:
Hisashi> On Sun, 20 Jul 2003, Randal L. Schwartz wrote:
>> If there's any part of the Perl programming that is too slow, please
>> demonstrate it with benchmarks.
Hisashi> Reading the code. I can reread most of my code with some wo
On Sun, 20 Jul 2003, Randal L. Schwartz wrote:
> If there's any part of the Perl programming that is too slow, please
> demonstrate it with benchmarks.
Reading the code. I can reread most of my code with some work; perl
takes the most time. :)
--
Hisashi T Fujinaka - [EMAIL PROTECTED]
BSEE(6/86
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Randal L. Schwartz wrote:
You should look into DBD::SQLite then... a complete SQL engine with
transactions, subselects, views, etc... but without the server
running! The entire engine is included in the DBD::SQLite distro.
It's really rather remarkabl
> "Max" == Max Horn <[EMAIL PROTECTED]> writes:
Max> I don't think any of our performance problems are due to perl anyway,
Max> and so far nobody (including Kyle) has been able to prove
Max> otherwise. All bottlenecks I see so far are disk I/O related, or due
Max> to suboptimal algorithms (i.e
Am Sonntag, 20.07.03 um 16:02 Uhr schrieb Benjamin Reed:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Randal L. Schwartz wrote:
Kyle> I would like to propose a new internal engine for fink, based
around
Kyle> an Objective C library that I will call Finch in this email.
Why objective-C? Perl wo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Randal L. Schwartz wrote:
Kyle> I would like to propose a new internal engine for fink, based around
Kyle> an Objective C library that I will call Finch in this email.
Why objective-C? Perl would get the job done faster, cheaper, and
with a larger ins
On Sunday, Jul 20, 2003, at 05:27 US/Eastern, Max Horn wrote:
Just one word "conflict handling". The single most biggest problem.
Plain forward dependencies are trtivial to handle and are already
handled in the existing engine. The hard cases are conflicts, and the
many many border cases, e.g. w
Why objective-C? Perl would get the job done faster, cheaper, and
with a larger installed base of people who can make contributions.
With Perl, it is more difficult to add bindings that make it usable in
C/Obj-C/etc. On the other hand, with C function callbacks to the
Objective C objects, it is
Am Sonntag, 20.07.03 um 07:41 Uhr schrieb Kyle Moffett:
I would like to propose a new internal engine for fink, based around
an Objective C library that I will call Finch in this email. I will
be unavailable for the next 3 weeks, but will work on code in my spare
time. When I get back, I will
> "Kyle" == Kyle Moffett <[EMAIL PROTECTED]> writes:
Kyle> I would like to propose a new internal engine for fink, based around
Kyle> an Objective C library that I will call Finch in this email.
Why objective-C? Perl would get the job done faster, cheaper, and
with a larger installed base of
I would like to propose a new internal engine for fink, based around an
Objective C library that I will call Finch in this email. I will be
unavailable for the next 3 weeks, but will work on code in my spare
time. When I get back, I will send a link to whatever I come up with.
Here is my pro
15 matches
Mail list logo