>From a recent slashdot thread on some speech recognition SW:
While I've been waiting for Sphinx[the package] to mature into
something useful for a long time now, the move to Java makes the
whole package pretty useless to me.
Java is a memory hog, and it's certainly not going to be on any
device I would want speech recognition on. Heck, I don't have Java
installed on any of my machines, mostly because of the absolutely
ridiculous footprint on disk as well as when running in ram.
And integrating Java applications into other applications is very
difficult. Now, Java is good for certain things, but a speech
recognition engine in Java sounds like the worst abuse possible :)
That and I still can't train it to recognise my slight australian
accent, unlike every other bit of SR software I've used on Win32
:P
Whether or not Sphinx-4 works, and whether or not Java is 'fast'
enough to do speech recognition processing, its of no use to me.
s/Java/Lisp/ and this could be any number of articles sent to CLL.
--tim
Greetings! Read the same article. It prompted the post I just sent
enquiring about 'j2cl'. In addition to the objections you cite below,
there is also this one -- the predominant (at least) implementations
are not DFSG free.
There simply aren't enough researchers who would do this is lisp from
the start, but might it be translated?
Take care,
"Tim Bradshaw" <··········@tfeb.org> writes:
> >From a recent slashdot thread on some speech recognition SW:
>
> While I've been waiting for Sphinx[the package] to mature into
> something useful for a long time now, the move to Java makes the
> whole package pretty useless to me.
>
> Java is a memory hog, and it's certainly not going to be on any
> device I would want speech recognition on. Heck, I don't have Java
> installed on any of my machines, mostly because of the absolutely
> ridiculous footprint on disk as well as when running in ram.
>
> And integrating Java applications into other applications is very
> difficult. Now, Java is good for certain things, but a speech
> recognition engine in Java sounds like the worst abuse possible :)
>
> That and I still can't train it to recognise my slight australian
> accent, unlike every other bit of SR software I've used on Win32
> :P
>
> Whether or not Sphinx-4 works, and whether or not Java is 'fast'
> enough to do speech recognition processing, its of no use to me.
>
> s/Java/Lisp/ and this could be any number of articles sent to CLL.
> --tim
>
--
Camm Maguire ····@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Camm Maguire wrote:
> Greetings! Read the same article. It prompted the post I just sent
> enquiring about 'j2cl'. In addition to the objections you cite
below,
> there is also this one -- the predominant (at least) implementations
> are not DFSG free.
>
I think you missed my point, which was that this article was *exactly*
the same thing people say (or said) about Lisp, and wrong for exactly
the same reasons.
Yes, Java/Lisp runtimes are big (especially the class library for
Java), yes Java/Lisp implementations are a little slower than the best
C implementations, yes foreign call (really: calls into C code) is not
(quite) trivial in Java/Lisp. But they're high-level-languages with
large (enormous in Java's case) and reasonably well designed (for
LispIn CL's case - somewhat patchily designed, but the basics seem OK
in Java's case) standard libraries.
Them's the breaks: if you want a high-level language and a huge
standard library for it, it's going to be big. CL implementations now
look relatively small, but that's mostly because CL's standard library
is really small compared to Java's. Imagine how big a CL would be
with a standard library that did everything that's in the J2SE
library, let alone the (largely horrible, I think) J2EE stuff!
j2cl would, I think, not be very interesting unless you could
translate the standard Java library. Better to have CL
implementations which can call Java ones (& vice versa) I think.
(DFSG I care not a hoot about.)
--tim
Greetings!
"Tim Bradshaw" <··········@tfeb.org> writes:
> (DFSG I care not a hoot about.)
I'm just curious -- what do others on this list think about this
issue? (DFSG == Debian Free Software Guidelines, aka. 'open source')
Take care,
--
Camm Maguire ····@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Camm Maguire wrote:
>
> I'm just curious -- what do others on this list think about this
> issue? (DFSG == Debian Free Software Guidelines, aka. 'open source')
>
I have no objection to free software (of course...). I do have
objections to the sub-religious cultism which has grown up around it.
--tim
Camm Maguire wrote:
> Greetings!
>
> "Tim Bradshaw" <··········@tfeb.org> writes:
>
>
>>(DFSG I care not a hoot about.)
>
>
> I'm just curious -- what do others on this list think about this
> issue? (DFSG == Debian Free Software Guidelines, aka. 'open source')
I think some context was just lost. I see benefits in open software, but
I do not see DFSGness as a useful discriminant. The exception being a
mere tautology: any library I want to use in DFSG Cello needs to be DFSG.
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
On 2004-09-30 15:32:11, Camm Maguire wrote:
> I'm just curious -- what do others on this list think about this
> issue? (DFSG == Debian Free Software Guidelines, aka. 'open source')
What issue?
I like having free lisps. I'm a happy user of SBCL 0.8.15
Camm Maguire wrote:
> Greetings!
>
> "Tim Bradshaw" <··········@tfeb.org> writes:
>
>
>>(DFSG I care not a hoot about.)
>
>
> I'm just curious -- what do others on this list think about this
> issue? (DFSG == Debian Free Software Guidelines, aka. 'open source')
>
> Take care,
It's good there is software around that is DFSG compliant. It is also
good that there is software that is commercially supported. Above all
Common Lisp implementations are very good when they are ANSI compliant :)
Cheers
--
Marco
Camm Maguire <····@enhanced.com> writes:
> I'm just curious -- what do others on this list think about this
> issue? (DFSG == Debian Free Software Guidelines, aka. 'open source')
Most of the comp.lang.lisp archives can tell you a lot about this.
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
In the last exciting episode, Camm Maguire <····@enhanced.com> wrote:
> Greetings!
>
> "Tim Bradshaw" <··········@tfeb.org> writes:
>
>> (DFSG I care not a hoot about.)
>
> I'm just curious -- what do others on this list think about this
> issue? (DFSG == Debian Free Software Guidelines, aka. 'open source')
The "near-Trotskyite" discussions that come up on the _Debian_ mailing
lists surrounding matters of "free software purity" are pretty worthy
of causing people to want to sign off of that sort of discussion.
But the result, which is a Linux distribution whose components are all
freely redistributable, seems to be a pretty valuable result. That
they are excruciatingly painfully careful about licensing means that I
can take a Debian CD and feel reasonably confident that I can "do what
I need to" with it, and not need worry that there's someone I might be
forgetting to negotiate with about licenses.
--
If this was helpful, <http://svcs.affero.net/rm.php?r=cbbrowne> rate me
http://linuxfinances.info/info/lsf.html
If a person with multiple personalities threatens suicide, is that
considered a hostage situation?
On 29 Sep 2004 07:27:14 -0700, Tim Bradshaw <··········@tfeb.org> wrote:
> Yes, Java/Lisp runtimes are big (especially the class library for
> Java), yes Java/Lisp implementations are a little slower than the best
> C implementations, yes foreign call (really: calls into C code) is not
> (quite) trivial in Java/Lisp. But they're high-level-languages with
> large (enormous in Java's case) and reasonably well designed (for
> LispIn CL's case - somewhat patchily designed, but the basics seem OK
> in Java's case) standard libraries.
>
Duplicating the entire OS and windows system and lauching it all
for each program that runs is not the answer.
CAPI lies on top of the native windows system.
For this reason it acievs portabillity with a fraction of the memory
consumption of SWING.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
> Duplicating the entire OS and windows system and lauching it all
> for each program that runs is not the answer.
> CAPI lies on top of the native windows system.
So do some of the Java toolkits of course. But, well, I don't write
java stuff that needs GUIs, and it wasn't those libraries I was
worrying about.
--tim
On Wed, 29 Sep 2004 03:10:21 -0700, Tim Bradshaw wrote:
>>From a recent slashdot thread on some speech recognition SW:
>
> While I've been waiting for Sphinx[the package] to mature into
> something useful for a long time now, the move to Java makes the
> whole package pretty useless to me.
>
> Java is a memory hog, and it's certainly not going to be on any
> device I would want speech recognition on.
hmm, two friends of mine work for like 4 years now in a company that
produces walkman-size boxes that do speech recognition and synthesis. They
program these boxes in java.
> s/Java/Lisp/ and this could be any number of articles sent to CLL. --tim
--
gr{oe|ee}t{en|ings}
artm
Artem Baguinski wrote:
>
> hmm, two friends of mine work for like 4 years now in a company that
> produces walkman-size boxes that do speech recognition and synthesis.
They
> program these boxes in java.
>
Right. That's because Java is no more `too big' than CL is, or
alternatively because memory is terribly cheap now.
--tim