24 Sep
2010
24 Sep
'10
8:45 p.m.
Am 23.09.2010 07:17, schrieb Louigi Verona:
Ha! Thanks, exactly, I think used this one.
Thank you very much for the script!
You are welcome :-)
of course you can replace the call for convert with any command you like
-- such as flac or sox etc ;-)
ahhh -- yes: in that case you may want to replace the search-pattern for
ls also:
for img in `ls *.wav`
;-)
24 Sep
24 Sep
9:05 p.m.
New subject: No batch processing on Linux?
On 09/24/10 20:45, Hartmut Noack wrote:
Am 23.09.2010 07:17, schrieb Louigi Verona:
..and in case there are files with whitespaces in the filename, change
the default string separator:
#/bin/bash
IFS=:
# do stuff
unset IFS
Cheers!
robin
Ha! Thanks, exactly, I think used this one.
Thank you very much for the script!
You are welcome :-)
of course you can replace the call for convert with any command you like
-- such as flac or sox etc ;-)
ahhh -- yes: in that case you may want to replace the search-pattern for
ls also:
for img in `ls *.wav`
;-)
9:13 p.m.
New subject: No batch processing on Linux?
On Fri, Sep 24, 2010 at 3:05 PM, Robin Gareus <robin(a)gareus.org> wrote:
..and in case there are files with whitespaces in the
filename, change
the default string separator:
my own personal experience with trying to write shell scripts that can
actually handle the full range of characters found in the filenames of
our 13,000 file music collection is ...
*** don't use shell scripts ***
i just switched to using perl and it was all so vastly less error prone.
9:19 p.m.
New subject: No batch processing on Linux?
On 09/24/10 21:13, Paul Davis wrote:
On Fri, Sep 24, 2010 at 3:05 PM, Robin Gareus
<robin(a)gareus.org> wrote:
Amen.
..and in case there are files with whitespaces in
the filename, change
the default string separator:
my own personal experience with trying to write shell scripts that can
actually handle the full range of characters found in the filenames of
our 13,000 file music collection is ...
*** don't use shell scripts *** i just switched to using perl and it was all so vastly
less error prone.
1+
9:40 p.m.
New subject: No batch processing on Linux?
also python scripts, right? :-)
2010/9/24 Robin Gareus <robin(a)gareus.org>rg>:
On 09/24/10 21:13, Paul Davis wrote:
On Fri, Sep 24, 2010 at 3:05 PM, Robin Gareus
<robin(a)gareus.org> wrote:
Amen.
..and in case there are files with whitespaces in
the filename, change
the default string separator:
my own personal experience with trying to write shell scripts that can
actually handle the full range of characters found in the filenames of
our 13,000 file music collection is ...
*** don't use shell scripts *** i just switched to using perl and it was all so
vastly less error prone.
1+
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
10:49 p.m.
New subject: No batch processing on Linux?
On Fri, Sep 24, 2010 at 8:40 PM, Bernardo Barros
<bernardobarros2(a)gmail.com> wrote:
also python scripts, right? :-)
Not so much. Perl is far more trustworthy than Python 2.x when it
comes to strange encodings -- Python's troubles with multi-byte
character encodings are well known and the scale of change involved to
fix them is one of the main reasons for the general shift to Python 3
being so slow. Nobody gets filename encodings right first time in a
Python 2 program.
Perl switched to Unicode strings in a minor release (5.6, a decade
ago), in a way that does the right thing so well as to be practically
magic.
Disclaimer: though I'm fond of Perl, I wouldn't really go for writing
anything big in it if you ever want to read it again. Python is much
more maintainer-friendly. In this particular case, though, Perl is
very impressive.
Chris
25 Sep
25 Sep
9:40 a.m.
New subject: No batch processing on Linux?
On Fri, Sep 24, 2010 at 09:49:25PM +0100, Chris Cannam wrote:
Disclaimer: though I'm fond of Perl, I
wouldn't really go for writing
anything big in it if you ever want to read it again. Python is much
more maintainer-friendly.
Well, you've hooked me with that!
How big are you talking about? Big in any language is hard.
Software architecture is a big part of succeeding with
big projects.
I don't see how the choice of language could ever
be more important than the design of the application.
When it comes to choice of perl, is not just the language
itself.
Perl has incredible testing tools, and testing is a big
part of succeeding with big projects.
Perl is typically developed with modules, and many of the
freely available modules come with extensive tests.
One needs discipline to develop large projects in
C, assembly, lisp or COBOL, too, but we hardly ever hear
of it.
With all the subtle craft of software development,
I find it suprising to hear a truism that
it's hard to read perl. Harder than lisp?
Hard than C? Harder than Forth?
I guess I am reacting to what I imagine is language
preference projected onto absolute judgment on merits of a
particular language.
Perhaps you are speaking from years of software development
experience. In that case, I am reacting to a broad statement
that does not reflect your hard-won wisdom (which I am sure
would be much more interesting to hear about than a truism.)
Or perhaps you are seeking to win over others' mindshare
to the Path of the Snake. In that case, why shouldn't Python's
virtues stand on their own.
But I sense I am going too far with this, as the rest of
your post sounded rather even handed.
All the best to you, (and anyone seeking to develop
in any language!)
Cheers,
Joel
Chris
--
Joel Roth
10:49 a.m.
New subject: No batch processing on Linux?
On Sat, Sep 25, 2010 at 8:06 AM, Joel Roth <joelz(a)pobox.com> wrote:
I guess I am reacting to what I imagine is language
preference projected onto absolute judgment on merits of a
particular language.
Perhaps you are speaking from years of software development
experience.
I have quite a lot of (mostly enjoyable) experience writing Perl over
the years, including some fairly big programs, and hardly any
experience with Python (a language I dislike on instinct). But my
experience with Perl has been that returning to my own projects is
harder than it should be, and harder than in languages like C and C++.
That is probably due to my own limitations, particularly when it
comes to discipline, but it's empirically true in my case.
The real assumption I made back there was that Python code is any
easier to return to -- I haven't the experience to judge, really, I'm
just going on hearsay from friends and acquaintances.
Chris
1 p.m.
New subject: No batch processing on Linux?
On Saturday 25 September 2010 10:49:35 Chris Cannam wrote:
On Sat, Sep 25, 2010 at 8:06 AM, Joel Roth
<joelz(a)pobox.com> wrote:
Python actually forces you to be more disciplined. Which really make returning
to the code easy.
Using python for small apps/tools is easy. Using python for large projects is
easy.
Extending your C/C++-project with python is easy.
Using your own C/C++ parts in python is easy.
Porting parts of your python project to C/C++ is easy (think prototyping in
python and port to compiled-language once the interface is finished and the
optimizations begin).
I for one am very glad I learned python a few years back. Its fun.
Disclaimer: I don't have any experience in perl, but what I get from the perl-
snapshots in German Linux-Magazin, it looks harder then python...
Have fun,
Arnold
I guess I am reacting to what I imagine is
language
preference projected onto absolute judgment on merits of a
particular language.
Perhaps you are speaking from years of software development
experience.
I have quite a lot of (mostly enjoyable) experience writing Perl over
the years, including some fairly big programs, and hardly any
experience with Python (a language I dislike on instinct). But my
experience with Perl has been that returning to my own projects is
harder than it should be, and harder than in languages like C and C++.
That is probably due to my own limitations, particularly when it
comes to discipline, but it's empirically true in my case.
The real assumption I made back there was that Python code is any
easier to return to -- I haven't the experience to judge, really, I'm
just going on hearsay from friends and acquaintances.
8:21 p.m.
New subject: No batch processing on Linux?
On Sat, Sep 25, 2010 at 01:00:29PM +0200, Arnold Krille wrote:
On Saturday 25 September 2010 10:49:35 Chris Cannam
wrote:
I believe that's the philosophy that there should be one
right way to approach a particular task. Perl suffers (and
benefits) from its motto TIMTOWTDI (pronounced tim-toady --
this is more than one way to do it.)
On Sat, Sep 25, 2010 at 8:06 AM, Joel Roth
<joelz(a)pobox.com> wrote:
Python actually forces you to be more disciplined. Which really make returning
to the code easy. I guess I am reacting to what I imagine is
language
preference projected onto absolute judgment on merits of a
particular language.
Perhaps you are speaking from years of software development
experience.
I have quite a lot of (mostly enjoyable) experience writing Perl over
the years, including some fairly big programs, and hardly any
experience with Python (a language I dislike on instinct). But my
experience with Perl has been that returning to my own projects is
harder than it should be, and harder than in languages like C and C++.
That is probably due to my own limitations, particularly when it
comes to discipline, but it's empirically true in my case.
The real assumption I made back there was that Python code is any
easier to return to -- I haven't the experience to judge, really, I'm
just going on hearsay from friends and acquaintances. Using python for small apps/tools is easy. Using
python for large projects is
easy.
Extending your C/C++-project with python is easy.
Using your own C/C++ parts in python is easy.
That's a big advantage of python over perl right now: python's
ctypes library. There is a project now to port ctypes to
perl.
Perl had previously borrowed Python's object mechanism. Just
now it is finally being replaced, by Moose/Mouse in Perl 5,
and the internal object system in Perl 6.
I, for one, have had a great time with the python-derived
perl object system.
Otherwise, perl's vast CPAN libraries, cover many problem
domains.
Porting parts of your python project to C/C++ is easy
(think prototyping in
python and port to compiled-language once the interface is finished and the
optimizations begin).
For optimizing perl, we have Devel::NYTProf, which
profiles the time spent in each subroutine. (As the name
suggests, the New York Times underwrote the development
costs.)
I for one am very glad I learned python a few years
back. Its fun.
Good for you! So is perl. :-)
I thought I would like to learn some other language, either
python, ruby, Tcl or Forth, but usually I have some
practical problem to get done, and the more familiar
language gets used.
Disclaimer: I don't have any experience in perl,
but what I get from the perl-
snapshots in German Linux-Magazin, it looks harder then python...
Perl does have a few syntax quirks. The deferencing syntax
is particularly awkward. There is also the oddity (and
feature) of list/scalar context.
For me, reading music is awkward, and so is reading python,
but I don't blame the notation in either case.
Best,
Joel
Have fun,
Arnold
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
--
Joel Roth
10:38 p.m.
New subject: Script processing on Linux? Ruby?
On 09/25/2010 02:21 PM, Joel Roth wrote:
...
I thought I would like to learn some other language, either
python, ruby, Tcl or Forth, but usually I have some
practical problem to get done, and the more familiar
language gets used.
I'm in the same situation. I've boiled it down to choosing between
learning Python or learning Ruby.
So ... we've been talking about Perl and Python. Does anyone have any observations on
how Ruby fits (or doesn't) into this picture?
-Can it be used for scripting (the original subject)?
-Is it as C-compatible as Python?
Thanks,
John
On 09/25/2010 02:21 PM, Joel Roth wrote:
On Sat, Sep 25, 2010 at 01:00:29PM +0200, Arnold
Krille wrote:
On Saturday 25 September 2010 10:49:35 Chris
Cannam wrote:
I believe that's the philosophy that there should be one
right way to approach a particular task. Perl suffers (and
benefits) from its motto TIMTOWTDI (pronounced tim-toady --
this is more than one way to do it.)
On Sat, Sep 25, 2010 at 8:06 AM, Joel Roth
<joelz(a)pobox.com> wrote:
Python actually forces you to be more disciplined. Which really make
returning
to the code easy.
I guess I am reacting to what I imagine is
language
preference projected onto absolute judgment on merits of a
particular language.
Perhaps you are speaking from years of software development
experience.
I have quite a lot of (mostly enjoyable) experience writing Perl over
the years, including some fairly big programs, and hardly any
experience with Python (a language I dislike on instinct). But my
experience with Perl has been that returning to my own projects is
harder than it should be, and harder than in languages like C and C++.
That is probably due to my own limitations, particularly when it
comes to discipline, but it's empirically true in my case.
The real assumption I made back there was that Python code is any
easier to return to -- I haven't the experience to judge, really, I'm
just going on hearsay from friends and acquaintances.
Using python for small apps/tools is easy. Using
python for large projects is
easy.
Extending your C/C++-project with python is easy.
Using your own C/C++ parts in python is easy.
That's a big advantage of python over perl right now: python's
ctypes library. There is a project now to port ctypes to
perl.
Perl had previously borrowed Python's object mechanism. Just
now it is finally being replaced, by Moose/Mouse in Perl 5,
and the internal object system in Perl 6.
I, for one, have had a great time with the python-derived
perl object system.
Otherwise, perl's vast CPAN libraries, cover many problem
domains.
Porting parts of your python project to C/C++ is
easy (think prototyping in
python and port to compiled-language once the interface is finished and the
optimizations begin).
For optimizing perl, we have Devel::NYTProf, which
profiles the time spent in each subroutine. (As the name
suggests, the New York Times underwrote the development
costs.)
I for one am very glad I learned python a few
years back. Its fun.
Good for you! So is perl. :-)
I thought I would like to learn some other language, either
python, ruby, Tcl or Forth, but usually I have some
practical problem to get done, and the more familiar
language gets used.
Disclaimer: I don't have any experience in
perl, but what I get from the perl-
snapshots in German Linux-Magazin, it looks harder then python...
Perl does have a few syntax quirks. The deferencing syntax
is particularly awkward. There is also the oddity (and
feature) of list/scalar context.
For me, reading music is awkward, and so is reading python,
but I don't blame the notation in either case.
Best,
Joel
Have fun,
Arnold
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
11:10 p.m.
New subject: Script processing on Linux? Ruby?
On Sat, Sep 25, 2010 at 9:37 PM, John List <johnlist(a)gulfbridge.net> wrote:
So ... we've been talking about Perl and Python.
Does anyone have any
observations on how Ruby fits (or doesn't) into this picture?
-Can it be used for scripting (the original subject)?
Yes.
Ruby is an effective and concise language that has a good enough
filesystem API to be used for scripting. Its syntax is weird to an
eye familiar with C-style idioms, and surprisingly formally complex to
any eye (it isn't an elegant language with few special cases like Lisp
or whatever, it has quite a few oddities), but it is certainly a
language that some programmers seem to find friendlier and more
natural in many contexts than C, Python or Perl.
-Is it as C-compatible as Python?
No idea. I've only ever dealt with Ruby in single-language web applications.
Chris
26 Sep
26 Sep
8:33 p.m.
New subject: Script processing on Linux? Ruby?
I vote for Genie . If it's as fast as Vala (
http://spekle.googlecode.com ), i'm sold.
http://live.gnome.org/Genie
///// ///// ///// ////
Genie is a new programming language, in the same vein as Vala, that
allows for a more modern programming style while being able to
effortlessly create and use GObjects natively.
The syntax is designed to be clean, clear and concise and is derived
from numerous modern languages like Python, Boo, D language and
Delphi.
Genie is very similar to Vala in functionality but differs in syntax
allowing the developer to use cleaner and less code to accomplish the
same task.
Like Vala, Genie has the same advantages:
Programs written in Genie should have have similar performance and
resource usage to those written directly in Vala and C
Genie has none of the bloat and overhead that comes with many other
high level languages which utilize a VM (e.g. Python, Mono, Java)
Classes in Genie are actually GObjects so Genie can be used for
creating platform code like widgets and libraries where GObjects are
required for binding to other languages
///// ///// ///// ////
Niels
http://nielsmayer.com
PS: Chris -- Any suggestions on generating VAPI's (
http://live.gnome.org/Vala/Bindings ) for the Vamp plugins SDK so they
could easily be used fom vala/genie. Anybody else doing this? Any
interest? I guess I should see how or what was done in
http://vamp-plugins.org/vampy.html ??
8:27 a.m.
New subject: Script processing on Linux? Ruby?
Excerpts from John List's message of 2010-09-25 22:37:58 +0200:
On 09/25/2010 02:21 PM, Joel Roth wrote:
Hi John,
just to mention another language, even less known than ruby: Lua
I've only dabbled in a couple of languages, and so far I like Lua best,
it's simply fun to write, simple stuff is simple to do, for hard stuff
there are usually libraries to help you. It's a small language and you
build stuff with only a few language features, which is the beauty of
it, imho.
It was designed to be embedded in C programs to script those and as a
configuration language, its C interface is said to be better than
pythons. You can use it on its own as well, but for simple scripts bash
likely has its benefits (over probably every other language).
Same as Joel uses Perl, I use Lua to develop an ecasound frontend (but
it's not generally useful yet).
Regards,
Philipp
...
I thought I would like to learn some other language, either
python, ruby, Tcl or Forth, but usually I have some
practical problem to get done, and the more familiar
language gets used.
I'm in the same situation. I've boiled it down to choosing between
learning Python or learning Ruby.
So ... we've been talking about Perl and Python. Does anyone have any observations on
how Ruby fits (or doesn't) into this picture?
-Can it be used for scripting (the original subject)?
-Is it as C-compatible as Python?
Thanks,
John 
3:52 p.m.
New subject: Script processing on Linux? Ruby?
On Sun, Sep 26, 2010 at 11:57 AM, Philipp Überbacher
<hollunder(a)lavabit.com>wrote;wrote:
Excerpts from John List's message of 2010-09-25
22:37:58 +0200:
For C (and C++) interfacing, python has a variety of styles ranging across
- the basic (builtin) C interface
- ctypes
- pyrex and cython
- swig, sip
- SCXX, PyCXX,
- Boost
(I think Ive missed a couple :-)
On 09/25/2010 02:21 PM, Joel Roth wrote:
learning Python or learning Ruby.
...
I thought I would like to learn some other language, either
python, ruby, Tcl or Forth, but usually I have some
practical problem to get done, and the more familiar
language gets used.
I'm in the same situation. I've boiled it down to choosing between
So ... we've been talking about Perl and Python. Does anyone have any
observations on how Ruby fits (or doesn't) into this picture?
-Can it be used for scripting (the original
subject)?
-Is it as C-compatible as Python?
Thanks,
John
25 Sep
25 Sep
11:24 p.m.
New subject: No batch processing on Linux?
On Saturday 25 September 2010 20:21:22 Joel Roth wrote:
On Sat, Sep 25, 2010 at 01:00:29PM +0200, Arnold
Krille wrote:
Hm. The idea I mainly have in mind is not to optimize your python code, but
prototype your app with its functionality in python and when all works as
expected (more or less), port the time-critical parts to c/C++. Not because
python is slow (it is compared to native asm) in general, but because it is
definitely to slow for various tasks like audio. And because python afaik still
has the big interpreter lock, effectively suppressing any python multi-
threading. Which you work around by re-implementing your heavy-math parts in C
and run them outside the interpreter lock (but still from within threads
created and managed from python)...
Have fun,
Arnold
Porting parts of your python project to C/C++ is
easy (think prototyping
in python and port to compiled-language once the interface is finished
and the optimizations begin).
For optimizing perl, we have Devel::NYTProf, which
profiles the time spent in each subroutine. (As the name
suggests, the New York Times underwrote the development
costs.)
26 Sep
26 Sep
6:46 a.m.
New subject: No batch processing on Linux?
On Sat, Sep 25, 2010 at 11:24:26PM +0200, Arnold Krille wrote:
On Saturday 25 September 2010 20:21:22 Joel Roth
wrote:
That seems like a great way to develop applications.
I mention perl's profiler, because in developing Nama,
it was quite convenient.
I developed functions naively, without caching
provisions. When I noticed it was running slow for
hundreds of tracks, Devel::NYTProf showed me
exactly how many subroutine calls were taking
how much time.
Porting time-critical functions to c/C++ hasn't been
much issue for me, since I already use a speed
optimized engine for audio processing (Ecasound :-)
On Sat, Sep 25, 2010 at 01:00:29PM +0200, Arnold
Krille wrote:
Hm. The idea I mainly have in mind is not to optimize your python code, but
prototype your app with its functionality in python and when all works as
expected (more or less), port the time-critical parts to c/C++. Not because
python is slow (it is compared to native asm) in general, but because it is
definitely to slow for various tasks like audio. Porting parts of your python project to C/C++ is
easy (think prototyping
in python and port to compiled-language once the interface is finished
and the optimizations begin).
For optimizing perl, we have Devel::NYTProf, which
profiles the time spent in each subroutine. (As the name
suggests, the New York Times underwrote the development
costs.) And because python afaik still
has the big interpreter lock, effectively suppressing any python multi-
threading. Which you work around by re-implementing your heavy-math parts in C
and run them outside the interpreter lock (but still from within threads
created and managed from python)...
What, no native threads. Mock horror!
Best,
Joel
Have fun,
Arnold
--
Joel Roth
11:11 p.m.
New subject: No batch processing on Linux?
On Sunday 26 September 2010 06:45:42 Joel Roth wrote:
On Sat, Sep 25, 2010 at 11:24:26PM +0200, Arnold
Krille wrote:
Native threads: Yes.
But only one python interpreter to run. At least in python2.X.
As long as you call long-running non-python functions in the other threads,
you are fine (like the run() function of your audio-apps jack-engine).
Arnold
And because python afaik still
has the big interpreter lock, effectively suppressing any python multi-
threading. Which you work around by re-implementing your heavy-math parts
in C and run them outside the interpreter lock (but still from within
threads created and managed from python)...
What, no native threads. Mock horror!
11:24 p.m.
New subject: No batch processing on Linux?
On Sun, Sep 26, 2010 at 11:10:59PM +0200, Arnold Krille wrote:
On Sunday 26 September 2010 06:45:42 Joel Roth wrote:
Interesting. There do seem to be a growing number of python
apps for audio, video and music.
So far the unix process model serves my needs well enough.
Regards,
Joel
On Sat, Sep 25, 2010 at 11:24:26PM +0200, Arnold
Krille wrote:
Native threads: Yes.
But only one python interpreter to run. At least in python2.X.
As long as you call long-running non-python functions in the other threads,
you are fine (like the run() function of your audio-apps jack-engine). And because python afaik still
has the big interpreter lock, effectively suppressing any python multi-
threading. Which you work around by re-implementing your heavy-math parts
in C and run them outside the interpreter lock (but still from within
threads created and managed from python)...
What, no native threads. Mock horror! Arnold
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
--
Joel Roth
11:34 p.m.
New subject: No batch processing on Linux?
This seems to change everything for Audio with Python:
http://code.google.com/p/pyo/
2010/9/26 Joel Roth <joelz(a)pobox.com>om>:
On Sun, Sep 26, 2010 at 11:10:59PM +0200, Arnold
Krille wrote:
On Sunday 26 September 2010 06:45:42 Joel Roth
wrote:
Interesting. There do seem to be a growing number of python
apps for audio, video and music.
So far the unix process model serves my needs well enough.
Regards,
Joel
On Sat, Sep 25, 2010 at 11:24:26PM +0200, Arnold
Krille wrote:
Native threads: Yes.
But only one python interpreter to run. At least in python2.X.
As long as you call long-running non-python functions in the other threads,
you are fine (like the run() function of your audio-apps jack-engine). And because python afaik still
has the big interpreter lock, effectively suppressing any python multi-
threading. Which you work around by re-implementing your heavy-math parts
in C and run them outside the interpreter lock (but still from within
threads created and managed from python)...
What, no native threads. Mock horror! Arnold
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
--
Joel Roth
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
8:13 a.m.
New subject: No batch processing on Linux?
Excerpts from Arnold Krille's message of 2010-09-25 13:00:29 +0200:
On Saturday 25 September 2010 10:49:35 Chris Cannam
wrote:
Isn't this only about indentation? Indentation might be important for
readability, but whether it's forced by the language or not doesn't seem
to be such a big deal for me.
On Sat, Sep 25, 2010 at 8:06 AM, Joel Roth
<joelz(a)pobox.com> wrote:
Python actually forces you to be more disciplined. Which really make returning
to the code easy. I guess I am reacting to what I imagine is
language
preference projected onto absolute judgment on merits of a
particular language.
Perhaps you are speaking from years of software development
experience.
I have quite a lot of (mostly enjoyable) experience writing Perl over
the years, including some fairly big programs, and hardly any
experience with Python (a language I dislike on instinct). But my
experience with Perl has been that returning to my own projects is
harder than it should be, and harder than in languages like C and C++.
That is probably due to my own limitations, particularly when it
comes to discipline, but it's empirically true in my case.
The real assumption I made back there was that Python code is any
easier to return to -- I haven't the experience to judge, really, I'm
just going on hearsay from friends and acquaintances. Using python for small apps/tools is easy. Using
python for large projects is
easy.
Extending your C/C++-project with python is easy.
Using your own C/C++ parts in python is easy.
Porting parts of your python project to C/C++ is easy (think prototyping in
python and port to compiled-language once the interface is finished and the
optimizations begin).
I for one am very glad I learned python a few years back. Its fun.
Disclaimer: I don't have any experience in perl, but what I get from the perl-
snapshots in German Linux-Magazin, it looks harder then python...
Have fun,
Arnold
11:16 p.m.
New subject: No batch processing on Linux?
On Sunday 26 September 2010 08:13:32 Philipp Überbacher wrote:
Excerpts from Arnold Krille's message of
2010-09-25 13:00:29 +0200:
Don't underestimate that!
Write some non-trivial code, let it rest for 2 months (where you focus on
other things) and come back to your code. If you where displined to document a
lot, python makes it easier for you to come back to your code than other
languages I know (C, C++, javascript, basic, pascal, fortran, LabView, heck it
even simplier than pd I think).
With python it seems to be "only" intendation, but this results in clearer
structures of code and less parenthesis. Which results in a much higher
readability. Sure, you can write readable code in other languages too. But how
many people do you know that write readable code (in non-python) when the
projects deadline is only two weeks away?
And pythons inbuilt documentation-system saves you another three days of that
deadline...
Have fun,
Arnold
On Saturday 25 September 2010 10:49:35 Chris
Cannam wrote:
Isn't this only about indentation? Indentation might be important for
readability, but whether it's forced by the language or not doesn't seem
to be such a big deal for me. On Sat, Sep 25, 2010 at 8:06 AM, Joel Roth
<joelz(a)pobox.com> wrote:
Python actually forces you to be more disciplined. Which really make
returning to the code easy. I guess I am reacting to what I imagine is
language
preference projected onto absolute judgment on merits of a
particular language.
Perhaps you are speaking from years of software development
experience.
I have quite a lot of (mostly enjoyable) experience writing Perl over
the years, including some fairly big programs, and hardly any
experience with Python (a language I dislike on instinct). But my
experience with Perl has been that returning to my own projects is
harder than it should be, and harder than in languages like C and C++.
That is probably due to my own limitations, particularly when it
comes to discipline, but it's empirically true in my case.
The real assumption I made back there was that Python code is any
easier to return to -- I haven't the experience to judge, really, I'm
just going on hearsay from friends and acquaintances. 
27 Sep
27 Sep
8:30 a.m.
New subject: [OT]: Scripting and programming languages (WAS: No batch processing on Linux?)
Arnold Krille wrote:
[...]
Don't underestimate that!
[...]
>>> On Sat, Sep 25, 2010 at 8:06 AM, Joel
Roth<joelz(a)pobox.com> wrote:
>>>> I guess I am reacting to what I imagine is language
>>>> preference projected onto absolute judgment on merits of a
>>>> particular language.
>>>>
>>>> Perhaps you are speaking from years of software development
>>>> experience.
>>>> I have quite a lot of (mostly
enjoyable) experience writing Perl over
>>>> the years, including some fairly big programs, and hardly any
>>>> experience with Python (a language I dislike on instinct).
I guess
programming languages are, first of all, the tools one uses for
telling computers ('stupid' machines) what to do. So the choice of the
tool depends on many factors amongst which personal preference. Of
course using bash to write a DAW wouldn't probably be the best choice,
but if anyone managed to... praise to them! :)
>>>> But my experience with Perl has been
that returning to my own projects is
>>>> harder than it should be, and harder than in languages like C and C++.
[...]
Python actually forces you to be more disciplined.
Which really make
returning to the code easy.
Isn't this only about indentation? Indentation
might be important for
readability, but whether it's forced by the language or not doesn't seem
to be such a big deal for me. With python it seems to be "only"
intendation, but this results in clearer
structures of code and less parenthesis. Which results in a much higher
readability. Sure, you can write readable code in other languages too. But how
many people do you know that write readable code (in non-python) when the
projects deadline is only two weeks away?
I agree. In the last few years I've
really come to love python... I also
find it one of the best languages when it comes to 'writing down' an
idea, an algorithm etc. without being 'berried' by the language syntax,
idioms etc. (the indentation is well worth the semicolon saving :)). The
nice thing of python is that it allows both functional
'hackerish-script' for quick and dirty stuff and very elegant
object-oriented styles (and if you like you can even mix them). Even the
first seems always 'cleaner' and more readable than many other languages.
Much of it, I guess, is also thanks to the ability of running python
'real-time' and experimenting with it... A bit like pd for audio where
you can hack and experiment (prototype?) stuff in real time and then
make the 'real' app/script when you are ready.
But again... What would life be without variety?
Lorenzo
And pythons inbuilt documentation-system saves you
another three days of that
deadline...
Have fun,
Arnold
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
7:51 p.m.
New subject: No batch processing on Linux?
Excerpts from Arnold Krille's message of 2010-09-26 23:16:05 +0200:
On Sunday 26 September 2010 08:13:32 Philipp
Überbacher wrote:
Documentation has nothing to do with indentation, and there probably
are documentation systems for every language. I wonder whether some of
you guys tried literate programing (noweb for example), it should beat
every documentation system, in theory.
Excerpts from Arnold Krille's message of
2010-09-25 13:00:29 +0200:
Don't underestimate that!
Write some non-trivial code, let it rest for 2 months (where you focus on
other things) and come back to your code. If you where displined to document a
lot, python makes it easier for you to come back to your code than other
languages I know (C, C++, javascript, basic, pascal, fortran, LabView, heck it
even simplier than pd I think).
With python it seems to be "only" intendation, but this results in clearer
structures of code and less parenthesis. Which results in a much higher
readability. Sure, you can write readable code in other languages too. But how
many people do you know that write readable code (in non-python) when the
projects deadline is only two weeks away?
And pythons inbuilt documentation-system saves you another three days of that
deadline...
Have fun,
Arnold On Saturday 25 September 2010 10:49:35 Chris
Cannam wrote:
Isn't this only about indentation? Indentation might be important for
readability, but whether it's forced by the language or not doesn't seem
to be such a big deal for me. On Sat, Sep 25, 2010 at 8:06 AM, Joel Roth
<joelz(a)pobox.com> wrote:
> I guess I am reacting to what I imagine is language
> preference projected onto absolute judgment on merits of a
> particular language.
>
> Perhaps you are speaking from years of software development
> experience.
I have quite a lot of (mostly enjoyable) experience writing Perl over
the years, including some fairly big programs, and hardly any
experience with Python (a language I dislike on instinct). But my
experience with Perl has been that returning to my own projects is
harder than it should be, and harder than in languages like C and C++.
That is probably due to my own limitations, particularly when it
comes to discipline, but it's empirically true in my case.
The real assumption I made back there was that Python code is any
easier to return to -- I haven't the experience to judge, really, I'm
just going on hearsay from friends and acquaintances.
Python actually forces you to be more disciplined. Which really make
returning to the code easy.
9:35 p.m.
New subject: No batch processing on Linux?
On Monday 27 September 2010 19:51:35 Philipp Überbacher wrote:
Excerpts from Arnold Krille's message of
2010-09-26 23:16:05 +0200:
That is correct. But I wasn't talking about inbuilt documentation helping
indentation. I was talking about inbuilt documentation helping you to
(re-)evaluate code you (or others) wrote some time ago.
And I was talking about "help(someclass.function)" inside python to get the
documentation for that python class. Try that in C(++) :-)
Have fun,
Arnold
And pythons inbuilt documentation-system saves
you another three days of
that deadline...
Documentation has nothing to do with indentation, and there
probably
are documentation systems for every language.
9:54 p.m.
New subject: No batch processing on Linux?
Excerpts from Arnold Krille's message of 2010-09-27 21:35:50 +0200:
On Monday 27 September 2010 19:51:35 Philipp
Überbacher wrote:
Ok, so indentation and documentation are completely unrelated issues,
except when well done, both help you to understand the code at some
later time. Python forces you to use consistent indentation and has some
built in documentation system.
Excerpts from Arnold Krille's message of
2010-09-26 23:16:05 +0200:
That is correct. But I wasn't talking about inbuilt documentation helping
indentation. I was talking about inbuilt documentation helping you to
(re-)evaluate code you (or others) wrote some time ago. And pythons inbuilt documentation-system saves
you another three days of
that deadline...
Documentation has nothing to do with indentation, and there
probably
are documentation systems for every language. And I was talking about
"help(someclass.function)" inside python to get the
documentation for that python class. Try that in C(++) :-)
Have fun,
Arnold
I guess you do that from some python shell, so I don't see the big
difference to any other way to search documentation/classes/whatever.
10:16 p.m.
New subject: No batch processing on Linux?
On Mon, 27 Sep 2010, Arnold Krille wrote:
And I was talking about
"help(someclass.function)" inside python to get the
documentation for that python class. Try that in C(++) :-)
Thank you!! I had no idea that existed. This beats the
heck out of doing `print someclass.function.__doc__` all the
time.
As for C/C++... the libc and libstdc++ man pages are about
the same. Plus, `apropos` kicks butt.
-gabriel
28 Sep
28 Sep
1:16 a.m.
New subject: No batch processing on Linux?
On Mon, Sep 27, 2010 at 03:16:09PM -0500, Gabriel M. Beddingfield wrote:
On Mon, 27 Sep 2010, Arnold Krille wrote:
guys ?
use a proper python shell.
ipython is there for quite some time.
and i recently discovered bpython
http://ipython.scipy.org/moin/
http://bpython-interpreter.org/
this is where the fun starts
also help() works nicely on instances.
doctests also pretty much kick ass.
http://docs.python.org/library/doctest.html
one of the problems with python and big projects is in my opinion that
it dynamically typed.
and refactoring stuff in python can get pretty awkward. type errors are
only detected at runtime.
so you need to have your test coverage in the 80% realm.
nose-tests helps you a bit with this stuff. including coverage analysis,
etc. http://somethingaboutorange.com/mrl/projects/nose/0.11.2/index.html
And I was talking about
"help(someclass.function)" inside python to get the
documentation for that python class. Try that in C(++) :-)
Thank you!! I had no idea that existed. This beats the heck out of
doing `print someclass.function.__doc__` all the time.
As for C/C++... the libc and libstdc++ man pages are about the same.
Plus, `apropos` kicks butt.
-gabriel
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
--
torben Hohn
25 Sep
25 Sep
11:08 a.m.
New subject: No batch processing on Linux?
Joel Roth wrote:
With all the subtle craft of software development,
I find it suprising to hear a truism that
it's hard to read perl. Harder than lisp?
Hard than C? Harder than Forth?
I don't. I find perl utterly unreadable. Even simple basic perl stuff
eludes me. It's gobbledeygook. But then, I've yet to succeed in even
basic RegEx stuff regardless of language, so maybe I'm not good at
cryptic expressions in general.
Lisp I've glanced at. I think the nesting would drive me crazy.
C and C++ I can at least read.
I used to program in Forth. Forth is very readable - as long as you keep
the context and the stack in mind as you dive deeper into the vocabulary
of the particular program you're reading. (Forth programmers are also
famous for contests in writing the most unreadable one-line programs
that do something non-trivial. They like to do that - popup a one-line
program and challenge another Forth programmer to figure out what it
does. Don't ask me for one of those!)
Regardless of the programming language, the important part is the
design, architecture and coding discipline. Any programmer can write
unreadable, unmaintainable, cryptic code in any language. Explains why
perl is the way it is! ;-)
--
David
gnome(a)hawaii.rr.com
authenticity, honesty, community
4963
days inactive
4966
days old
linux-audio-user@lists.linuxaudio.org
28 comments
15 participants
participants (15)
-
Arnold Krille -
Bernardo Barros -
Chris Cannam -
david -
Gabriel M. Beddingfield -
Hartmut Noack -
Joel Roth -
John List -
Lorenzo -
Niels Mayer -
Paul Davis -
Philipp Überbacher -
Robin Gareus -
Rustom Mody -
torbenh