Dreaming of new generation IDE
Vladimir Ignatov
I am sitting here for quite some time, but usually keep silent ;-) I
use Python since 2003 both "professionally" and for my hobby projects
and love it a much.
I notice however, that "maintaining" existing/older python code is may
be not so enjoyable task. It may be even harder than supporting old
code written in some type of "static" languages (like Java or C++).
Surely "dynamic" nature of python comes with price.
Finally I develop a feeling that strong instrumentation / tools can
bring us the best of two worlds. That I am dreaming on is an absolute
new type/class of IDE suitable for Python and potentially for other
dynamic-type languages. Instead of current text-oriented IDEs, it
should be a database-centric and resemble current CAD systems instead
of being just "fancy text editor". Source text should be an output
product of that CAD and not a "source material" itself.
Well. I understand that it is a very ambitious and experimental stuff.
Great efforts and motivation needed even to get something "runnable".
So I am looking for someone to get in kind of "virtual partnership".
If someone interesting it that soft of stuff, I would like to talk and
discuss this system.
Vladimir Ignatov
Paul Rubin
> I notice however, that "maintaining" existing/older python code is may
> be not so enjoyable task. It may be even harder than supporting old
> code written in some type of "static" languages (like Java or C++).
> Surely "dynamic" nature of python comes with price.
Yes, this is a well known drawback of dynamic typing. The usual remedy
is lots and lots of test automation (a full suite of unit and
integration tests that you run on every build, that check the properties
of basically every function in your program).
> Instead of current text-oriented IDEs, it
> should be a database-centric and resemble current CAD systems
I've never used a current CAD system, so I can't make any sense of this.
I don't see how databases would help.
Stefan Behnel
>> Instead of current text-oriented IDEs, it
>> should be a database-centric and resemble current CAD systems
>
> I've never used a current CAD system, so I can't make any sense of this.
> I don't see how databases would help.
Just like they help in current IDEs to index the source code.
Stefan
Adam Tauno Williams
> Hello,
> I am sitting here for quite some time, but usually keep silent ;-) I
> use Python since 2003 both "professionally" and for my hobby projects
> and love it a much.
> be not so enjoyable task. It may be even harder than supporting old
> code written in some type of "static" languages (like Java or C++).
> Surely "dynamic" nature of python comes with price.
Yes, it certainly does. Not that you'll get many Pythonistas to confess
to that fact. Somehow those who brag about the readability and
expressiveness of source code just cannot admit that:
class.method(sting name, int count)
- is *obviously* more expressive than -
class.method(name, count)
Oh, well.
This is obvious even in the Python documentation itself where one
frequently asks oneself "Uhh... so what is parameter X supposed to be...
a string... a list... ?"
Not knocking Python; Python is great. I maintain a rapidly growing
Python code base. But the above is almost comically funny sometimes
[sand.insert_head(pythonista)].
> Finally I develop a feeling that strong instrumentation / tools can
> bring us the best of two worlds. That I am dreaming on is an absolute
> new type/class of IDE suitable for Python and potentially for other
> dynamic-type languages. Instead of current text-oriented IDEs, it
> should be a database-centric and resemble current CAD systems instead
> of being just "fancy text editor". Source text should be an output
> product of that CAD and not a "source material" itself.
Ugh, please NO! This has been attempted many many times in many
environments - it always fails *terribly*.
Stefan Behnel
> This is obvious even in the Python documentation itself where one
> frequently asks oneself "Uhh... so what is parameter X supposed to be...
> a string... a list... ?"
>
> Not knocking Python; Python is great. I maintain a rapidly growing
> Python code base. But the above is almost comically funny sometimes
> [sand.insert_head(pythonista)].
So, what's "pythonista" in the above? A dummy?
Stefan
Jean-Michel Pichavant
> Yes, it certainly does. Not that you'll get many Pythonistas to confess
> to that fact. Somehow those who brag about the readability and
> expressiveness of source code just cannot admit that:
>
> class.method(sting name, int count)
>
> - is *obviously* more expressive than -
>
> class.method(name, count)
>
>
"""Return the cap'tain's age.
name: a string giving the name of the cap'tain daughter
count: an int giving the number of fingers left in the cap'tain
right hand
"""
In python, attributes/parameters have no type (but you know that). By
specifying them in the method signature, you're just duplicating the
information hold in the docstring.
JM
Vladimir Ignatov
> frequently asks oneself "Uhh... so what is parameter X supposed to be...
> a string... a list... ?"
Exactly. Often I don't need to know the exact type, but to figure out
that "kind of type" it is.
>> should be a database-centric and resemble current CAD systems instead
>> of being just "fancy text editor". Source text should be an output
>> product of that CAD and not a "source material" itself.
>
> Ugh, please NO! This has been attempted many many times in many
> environments - it always fails *terribly*.
Can you give some examples of such systems? (maybe just names for
googling for) I don't see anything dirt in storing some additional
meta-information about the code under development and using it later
for all kind of benefits (easy refactoring for example). As with your
example with "parameter x", some additional information can be
"attached" to this paramer. Later it can be used during
code-generation phase and placed as "comment" in source code or placed
in popup tag in html-style presentation.
Vladimir Ignatov
Marco Salden
The maintenance thing may be true but for me that doesn't outweigh the
clear benefits I get from using Python i.s.o. e.g. C++: the fact that
I have much less code that is more compact and for me more directly
readable is a clear advantage when doing maintance on code I didnt
touch for a while. Documenting the essential parameters used with some
examples and some logging helps (for me at least...).
The type of IDE you are looking for is more something like Rational
Rose (e.g. RRT?) type of tooling perhaps? There you "CAD" components
and their statebehavior and the system generates C or C++ code.
Regards,
Marco
Paul Rubin
> class.method(string name, int count):
> """Return the cap'tain's age.
>
> name: a string giving the name of the cap'tain daughter
> count: an int giving the number of fingers left in the cap'tain
> right hand
> """
>
> In python, attributes/parameters have no type (but you know that). By
> specifying them in the method signature, you're just duplicating the
> information hold in the docstring.
It's not enough to just document (except as an aid to remembering) since
the compiler and runtime don't enforce the documentation. You have to
use static typing or write tests, to flag all the call sites if you
change the signature. One nice trick with static types is if you change
what the method does (even if its type signature doesn't change), you
can rename the method:
class.method2(string name, int count): # change 'method' to 'method2'
and recompile your codebase. Every place in the code that called
'method' now gets a compile time "undefined method" error that you can
examine to see if you need to update it. This is something you can't
catch with unit tests because the call sites can be in distant modules.
Vladimir Ignatov
> clear benefits I get from using Python i.s.o. e.g. C++: the fact that
> I have much less code that is more compact and for me more directly
> readable is a clear advantage when doing maintance on code I didnt
> touch for a while. Documenting the essential parameters used with some
> examples and some logging helps (for me at least...).
Python is very easy to write. But with code grow and time passes,
things get worse. Currently I tries to reanimate one of my old
freeware project and faced it again.
> The type of IDE you are looking for is more something like Rational
> Rose (e.g. RRT?) type of tooling perhaps? There you "CAD" components
> and their statebehavior and the system generates C or C++ code.
Perhaps. I newer use Rational Rose but hear about it. But I use some
other Rational* products and they scare me a lot. So maybe Rose can be
used for "inspiration" but not much more. Actually I don't want to
put programmer in GUI-fashioned env. with a lot of buttons and
switches. I think about "classic" text-like view but that actually
"understands" that are you doing (typing) on. So your types goes in
"datastore" first and then renders back as a text representation.
Something like this.
Vladimir Ignatov
David Cournapeau
<awil...@opengroupware.us> wrote:
> On Wed, 2010-02-03 at 14:10 +0300, Vladimir Ignatov wrote:
>> Hello,
>> I am sitting here for quite some time, but usually keep silent ;-) I
>> use Python since 2003 both "professionally" and for my hobby projects
>> and love it a much.
>> I notice however, that "maintaining" existing/older python code is may
>> be not so enjoyable task. It may be even harder than supporting old
>> code written in some type of "static" languages (like Java or C++).
>> Surely "dynamic" nature of python comes with price.
>
> to that fact. Somehow those who brag about the readability and
> expressiveness of source code just cannot admit that:
Static typing sounds "obviously" better only if you assume everything
else being equal. But the typing system also often goes in the way
when developing large codebases, when you need to refactor things,
etc... So if for a *given* codebase, you get type information, it is
almost certainly very helpful. But when you need to change this
codebase, maybe not so much.
There was a nice paper from people at Adobe which mentioned this very
aspect, focusing on how to maintain a significant codebase, from
prototype-kind of development to maintenance-kind of development:
http://www.ecmascript.org/es4/spec/evolutionary-programming-tutorial.pdf.
It strikes me as a good way to look at this tradeoff between static
and dynamic typing, where the dynamic typing for some "mostly frozen"
code areas has diminishing returns,
David
Adam Tauno Williams
> Yes, it certainly does. Not that you'll get many Pythonistas
> to confess
> to that fact. Somehow those who brag about the readability
> and
> expressiveness of source code just cannot admit that:
> - is *obviously* more expressive than -
> class.method(name, count)
> This is obvious even in the Python documentation itself where
> one
> frequently asks oneself "Uhh... so what is parameter X
> supposed to be...
> a string... a list... ?"
> But I thought that was the one of beauties of Python, you don't need
> to know if the input parameter is a list or a string.
You don't need to know; unless of course you want the expected result.
Vladimir Ignatov
> linear hierarchical structure like python objects and modules.
Imagine simple operation like "method renaming" in a simple "dumb"
environment like text editor + grep. Now imagine how simple it can be
if system "knows" all your identifiers and just regenerates relevant
portions of text from internal database-alike representation.
> You mean something like LabView ?
No, I don't think so. I never use LabView but imagine it something
very "graphical-oriented". No, I think about more "classic" text view.
But back-ended with "smart" underlying system - not just obvious
"text".
Vladimir Ignatov
Stef Mientki
>> I don't see what the advantage of the use of a database is in a fairly
>> linear hierarchical structure like python objects and modules.
>>
> Imagine simple operation like "method renaming" in a simple "dumb"
> environment like text editor + grep. Now imagine how simple it can be
> if system "knows" all your identifiers and just regenerates relevant
> portions of text from internal database-alike representation.
>
cheers,
Stef
banibra...@gmail.com
From: Vladimir Ignatov
Sent: 03/02/2010 7:24:26 pm
Subject: Re: Dreaming of new generation IDE
> This is obvious even in the Python documentation itself where one
> frequently asks oneself "Uhh... so what is parameter X supposed to be...
> a string... a list... ?"
Exactly. Often I don't need to know the exact type, but to figure out
that "kind of type" it is.
>> should be a database-centric and resemble current CAD systems instead
>> of being just "fancy text editor". Source text should be an output
>> product of that CAD and not a "source material" itself.
>
> Ugh, please NO! This has been attempted many many times in many
> environments - it always fails *terribly*.
Can you give some examples of such systems? (maybe just names for
googling for) I don't see anything dirt in storing some additional
meta-information about the code under development and using it later
for all kind of benefits (easy refactoring for example). As with your
example with "parameter x", some additional information can be
"attached" to this paramer. Later it can be used during
code-generation phase and placed as "comment" in source code or placed
in popup tag in html-style presentation.
BD> probably close to Java annotations perhaps? And as for the CAD approach, would a UML reverse engg tool help ? If yes, perhaps you could give BOUML a shot.
Regards,
Banibrata
Vladimir Ignatov
>> environment like text editor + grep. Now imagine how simple it can be
>> if system "knows" all your identifiers and just regenerates relevant
>> portions of text from internal database-alike representation.
>>
>
> I think every IDE (not older than 20 years) does that already.
And fix every reference to it in all files? For python? I don't think
so. I even don't think this is possible at all. That if several
different objects have a similar named method? How will IDE "classify"
calls and renames only some of calls and not others?
Vladimir Ignatov
Phlip
> Finally I develop a feeling that strong instrumentation / tools can
> bring us the best of two worlds. That I am dreaming on is an absolute
> new type/class of IDE suitable for Python and potentially for other
> dynamic-type languages. Instead of current text-oriented IDEs, it
> should be a database-centric and resemble current CAD systems instead
> of being just "fancy text editor". Source text should be an output
> product of that CAD and not a "source material" itself.
That's fine so long as I can also treat the source as source, at need.
You may have just reinvented Smalltalk's Squeak editor (reputedly the
testbed for all of modern GUIs...).
Current editors suck because they can't see into the code and browse
it - unless it's so statically typed it's painful.
That's why I wrote this:
http://www.oreillynet.com/onlamp/blog/2008/05/dynamic_languages_vs_editors.html
John Bokma
> Finally I develop a feeling that strong instrumentation / tools can
> bring us the best of two worlds. That I am dreaming on is an absolute
> new type/class of IDE suitable for Python and potentially for other
> dynamic-type languages. Instead of current text-oriented IDEs, it
> should be a database-centric and resemble current CAD systems instead
> of being just "fancy text editor". Source text should be an output
> product of that CAD and not a "source material" itself.
Your idea is certainly not new. Moreover, I've been using such an IDE
and implemented support for a (small) language in it:
Programs are hierarchical compositions of formulae satisfying
structural and extra-structural relationships. A program editor can
use knowledge of such relationships to detect and provide immediate
feedback about violations of them. The Synthesizer Generator is a
tool for creating such editors from language descriptions. An editor
designer specifies the desired relationships and the feedback to be
given when they are violated, as well as a user interface; from the
specification, the Synthesizer Generator creates a full-screen editor
for manipulating programs in the language.
http://portal.acm.org/citation.cfm?id=390010.808247
It might be a good start to read as much as possible on the Synthesizer
Generator if you want to write such an IDE for Python. I am sure you
could write such an IDE in the Synthesizer Generator, but I have no idea
if it's still available. And back when I used it (at university) one had
to pay for it, and most likely was closed source as well.
See also: http://www.google.com/search?q=synthesizer%20generator
--
John Bokma j3b
Hacking & Hiking in Mexico - http://johnbokma.com/
http://castleamber.com/ - Perl & Python Development
Stef Mientki
>>> Imagine simple operation like "method renaming" in a simple "dumb"
>>> environment like text editor + grep. Now imagine how simple it can be
>>> if system "knows" all your identifiers and just regenerates relevant
>>> portions of text from internal database-alike representation.
>>>
>>>
>> I think every IDE (not older than 20 years) does that already.
>>
> And fix every reference to it in all files? For python? I don't think
> so. I even don't think this is possible at all.
> That if several
> different objects have a similar named method? How will IDE "classify"
> calls and renames only some of calls and not others?
>
the IDE's I use have as the beste "search / select / rename".
But how often do you must/want to rename something (mature) ?
cheers,
Stef
> Vladimir Ignatov
>
Adam Tauno Williams
> On Feb 3, 3:10 am, Vladimir Ignatov <kmis...@gmail.com> wrote:
> > Finally I develop a feeling that strong instrumentation / tools can
> > bring us the best of two worlds. That I am dreaming on is an absolute
> > new type/class of IDE suitable for Python and potentially for other
> > dynamic-type languages. Instead of current text-oriented IDEs, it
> > should be a database-centric and resemble current CAD systems instead
> > of being just "fancy text editor". Source text should be an output
> > product of that CAD and not a "source material" itself.
> That's fine so long as I can also treat the source as source, at need.
> You may have just reinvented Smalltalk's Squeak editor (reputedly the
> testbed for all of modern GUIs...).
> Current editors suck because they can't see into the code and browse
> it - unless it's so statically typed it's painful.
? I edit Python in MonoDevelop 2.2; and I can browse my file,
classes, etc... So I don't know what you mean by "can't see into the
code". It works pretty well.
Of course it can't tell that I've set x = {an integer}, as that only
happens at runtime.
Phlip
wrote:
> > Current editors suck because they can't see into the code and browse
> > it - unless it's so statically typed it's painful.
>
> ? I edit Python in MonoDevelop 2.2; and I can browse my file,
> classes, etc... So I don't know what you mean by "can't see into the
> code". It works pretty well.
>
> Of course it can't tell that I've set x = {an integer}, as that only
> happens at runtime.
>
> > That's why I wrote this:
> > http://www.oreillynet.com/onlamp/blog/2008/05/dynamic_languages_vs_editors.html
You just said that your code browsing "works pretty well, except when
it doesn't".
Hence my blog entry. If your editor analyzed your code at runtime,
instead of just static analysis, then it could see that x = an
integer, or an object, no matter how dynamic your language.
--
Phlip
http://zeekland.zeroplayer.com/Uncle_Wiggilys_Travels/1
John Bokma
In Perl:
my $x = ( 5, "hello", sub {}, [], {} )[ int rand 5 ];
what's $x? The answer is: it depends.
Moreover, even if your editor analyzes your code at runtime (which is
certainly not always desirable) it might not be able to find out what
the type is of x, simply because it would take too much time to find it
out. (It sounds like you want an editor that solves the halting problem
;-) )
I agree with you that to /some extent/ and editor can do analyses, if it
does compilation as well (and even runs the code, but the latter is not
always desirable). I mentioned the Synthesizer Generator before, which
can do compilation on the fly, if you implement it (or if it has been
implemented for the language you edit with it). I've written a very
simple assembler in it, ages ago, which did assembling on the fly.
Robert
> dynamic-type languages. Instead of current text-oriented IDEs, it
> should be a database-centric and resemble current CAD systems instead
> of being just "fancy text editor". Source text should be an output
> product of that CAD and not a "source material" itself.
can you sketch an example/use case more concretely?
Robert
Phlip
> my $x = ( 5, "hello", sub {}, [], {} )[ int rand 5 ];
>
> what's $x? The answer is: it depends.
That's why my blog post advocated (as usual for me) developer tests.
Then you either mock the rand, like all developers should, or you get
what you pay for, and Principle of Least Surprise still applies...
Over the past decade, teams discovered that developer tests more than
made up for the lack of rigor in dynamic languages. A dynamic language
with tests can be more productive than a static language, even with
its runtime type checks AND with its tests.
However, our editors must catch up to us. When I test, I am statically
declaring a set of types, even if the language would prefer to
dynamically fling them hither and yon. We should leverage that.
--
Phlip
John Bokma
> John Bokma wrote:
>
>> my $x = ( 5, "hello", sub {}, [], {} )[ int rand 5 ];
>>
>> what's $x? The answer is: it depends.
>
> That's why my blog post advocated (as usual for me) developer tests.
> Then you either mock the rand, like all developers should, or you get
> what you pay for, and Principle of Least Surprise still applies...
Yup, I agree with you that (to some extent) an IDE should be able to
determine types, especially if programmers don't reuse variables, like
(again Perl):
my $result = .... # int
:
:
if ( ... ) {
$result = .... # string
}
# $result can be still an int, or either a string, depending on the
# test.
> Over the past decade, teams discovered that developer tests more than
> made up for the lack of rigor in dynamic languages. A dynamic language
> with tests can be more productive than a static language, even with
> its runtime type checks AND with its tests.
Yup, this matches up with my experience. I can't recall that I ever
bumped into an issue in Perl (the dynamic language I've been using
the most for the past years). Not saying that it hasn't happened, but I
just can't recall. Probably also the reason why a "new" language I am
learning is also dynamic: Python ;-)
> However, our editors must catch up to us. When I test, I am statically
> declaring a set of types, even if the language would prefer to
> dynamically fling them hither and yon. We should leverage that.
I am all for testing, but it should IMO not get into the way. I am quite
happy with Emacs as an editor (I "recently" switched), it satisfies most
(if not all) of the items on the check list.
John Bokma
I guess Vladimir means what's called a structure editor. The (by me)
aforementioned Synthesizer Generator is an example of such an editor
(environment).
http://en.wikipedia.org/wiki/Structure_editor
http://portal.acm.org/citation.cfm?doid=358746.358755
Vladimir Ignatov
Sorry, I don't have anything written down. I just have some rough idea
of implementation and some concrete features I would like to see in
such system. For example:
1) Instant refactoring. No more needs for manual
search/inspect/rename. Since system knows exactly that is going on,
the refactoring will be fully automatic.
2) Show "xref table" for each function. How often this function used?
Where is it used? (code snippets of calls) What functionality is
supported by this function?
3) Extended statistics. How many objects this object/function
interacts with? Popular functions, dead/unused functions.
4) Code smell detector - too long functions, too much interaction with
other objects, global objects, etc.
...
Vladimir Ignatov
Robert Kern
I believe that Smalltalk came pretty close to what Vladimir is asking for. You
wrote the methods as linear plain text, but you used the GUI three pane class
browser to define and navigate classes. You could export class definitions to a
text file and read them back in, but in Vladimir's terms, the text files were
not the "source material" themselves.
http://www.cosc.canterbury.ac.nz/wolfgang.kreutzer/cosc205/smalltalk1.html
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
Vladimir Ignatov
> aforementioned Synthesizer Generator is an example of such an editor
> (environment).
Maybe. Yes, it kind of "generator". It has (entered somehow) internal
representation of target program. Then it generates code out of this
internal data. Yes, it is imaginable system, I don't have any working
prototype yet. But about to start making it. For prototype I choose
python 2.x as implementation language, sqlite as internal database and
Django as UI.
Vladimir Ignatov
Steven D'Aprano
> On Wed, 2010-02-03 at 14:10 +0300, Vladimir Ignatov wrote:
>> Hello,
>> I am sitting here for quite some time, but usually keep silent ;-) I
>> use Python since 2003 both "professionally" and for my hobby projects
>> and love it a much.
>> I notice however, that "maintaining" existing/older python code is may
>> be not so enjoyable task. It may be even harder than supporting old
>> code written in some type of "static" languages (like Java or C++).
>> Surely "dynamic" nature of python comes with price.
>
> Yes, it certainly does. Not that you'll get many Pythonistas to confess
> to that fact. Somehow those who brag about the readability and
> expressiveness of source code just cannot admit that:
>
> class.method(sting name, int count)
>
> - is *obviously* more expressive than -
>
> class.method(name, count)
Obviously? I don't know about that. Being told that "count" is an int
doesn't really help me -- it's obvious just from the name. In a well-
written API, what else could it be?
And surely count should be positive or zero but not negative? Saying it's
an int is misleading. Or perhaps count can be negative, in which case
maybe negative counts have some special meaning that isn't obvious from
the function signature. Can I pass None to get the default behaviour?
Either way, I need to read the docs, so the supposed added expressiveness
doesn't actually add much.
And why is count limited to an actual int type, rather than anything
which is integer-like? Why can't I pass 3.0 or Decimal(3)? If you have a
good reason for that limitation, great, but if it's just there to satisfy
the compiler, then boo hiss to you.
I cheerfully admit that *sometimes* there are type restrictions which
make sense, and of course we know that there are sometimes useful
performance gains to be made with static typing. Any compiler which
requires types to be declared is far too 1970s though -- a good modern
static language should use type inference to reduce the number of
declarations needed.
As for Pythonistas refusing to accept this, how do you explain function
annotations then?
Quoting Guido:
"Optional static typing has long been requested as a Python feature."
http://www.artima.com/weblogs/viewpost.jsp?thread=85551
More on function annotations and type inference for Python:
http://lambda-the-ultimate.org/node/1519
http://www.python.org/dev/peps/pep-3107/
http://www.python.org/workshops/2000-01/proceedings/papers/aycock/aycock.html
> This is obvious even in the Python documentation itself where one
> frequently asks oneself "Uhh... so what is parameter X supposed to be...
> a string... a list... ?"
The answer is usually "both, and anything else that obeys some subset of
the sequence or iterable protocols".
--
Steven
Steven D'Aprano
> One nice trick with static types is if you change
> what the method does (even if its type signature doesn't change), you
> can rename the method:
>
> class.method2(string name, int count): # change 'method' to
> 'method2'
>
> and recompile your codebase. Every place in the code that called
> 'method' now gets a compile time "undefined method" error that you can
> examine to see if you need to update it. This is something you can't
> catch with unit tests because the call sites can be in distant modules.
I don't understand why that won't work with unit tests. If you change the
name of a method, surely your unit tests will now start failing with
AttributeError?
--
Steven
Steven D'Aprano
> Imagine simple operation like "method renaming" in a simple "dumb"
> environment like text editor + grep. Now imagine how simple it can be if
> system "knows" all your identifiers and just regenerates relevant
> portions of text from internal database-alike representation.
Something like Bicycle Repair Man then:
http://bicyclerepair.sourceforge.net/
--
Steven
Steven D'Aprano
Says who? If you're free to assume the function requires a certain type,
we're free to assume the function is polymorphic and doesn't.
--
Steven
Paul Rubin
>> and recompile your codebase. Every place in the code that called
>> 'method' now gets a compile time "undefined method" error that you can
>> examine to see if you need to update it. This is something you can't
>> catch with unit tests because the call sites can be in distant modules.
>
> I don't understand why that won't work with unit tests. If you change the
> name of a method, surely your unit tests will now start failing with
> AttributeError?
Unit tests only test the code in the local module or package ("unit").
Obviously you also need other tests to exercise the interaction between
local and remote modules, but it's harder to be as thorough with those,
or write them as reflexively, in part because they're often written
by a separate group of programmers.
John Bokma
You might check out articles that mention the Synthesizer Generator, etc.
http://citeseer.ist.psu.edu/cis?q=synthesizer+generator&cs=1
http://citeseer.ist.psu.edu/cis?q=structure+editor&cs=1
The idea is not new (at least 30 years old), and those articles might
help you.
Terry Reedy
> class.method(sting name, int count)
>
> - is *obviously* more expressive than -
>
> class.method(name, count)
So write
class.method(name:str, count:int)->return_type # 3.x
if you really prefer.
In spite of you disparagement of 'pythonistas', it seems that the head
pythonista *did* admit that some people, at least, would prefer such
annotations.
3.0 also added abstract base classes so one can better specify object
classes without losing duck-typing.
import numbers
class.method(name:str, count:numbers.Integral)->return_type
Now one is documenting that count should be an integral value that acts
like an integer even if it is not an int per se. Of course, this is too
broad as it allows (presumably invalid) negative values.
Terry Jan Reedy
Robert Kern
Let's say we have class "A" with a method named "foo" that we change to "bar".
We have another class "B" with a method that accepts and A() instance and calls
the .foo() method on it. It is perfectly reasonable (and often necessary) for
the unit test of class B to use a mock object instead of a real A() instance.
The unit test for class B will fail to catch the renaming of A.foo() to A.bar()
because it never tries to call .foo() on a real A instance.
Of course, in a static language, it's much harder to make mock objects to do
this kind of (very useful!) testing to begin with.
Robert Kern
> On Wed, 03 Feb 2010 08:18:40 -0500, Adam Tauno Williams wrote:
>
>> On Wed, 2010-02-03 at 14:10 +0300, Vladimir Ignatov wrote:
>>> Hello,
>>> I am sitting here for quite some time, but usually keep silent ;-) I
>>> use Python since 2003 both "professionally" and for my hobby projects
>>> and love it a much.
>>> I notice however, that "maintaining" existing/older python code is may
>>> be not so enjoyable task. It may be even harder than supporting old
>>> code written in some type of "static" languages (like Java or C++).
>>> Surely "dynamic" nature of python comes with price.
>>
>> Yes, it certainly does. Not that you'll get many Pythonistas to confess
>> to that fact. Somehow those who brag about the readability and
>> expressiveness of source code just cannot admit that:
>>
>> class.method(sting name, int count)
>>
>> - is *obviously* more expressive than -
>>
>> class.method(name, count)
>
> Obviously? I don't know about that. Being told that "count" is an int
> doesn't really help me -- it's obvious just from the name. In a well-
> written API, what else could it be?
A bool. As in telling the method whether or not it should count something.
That said, I agree with your later point that this kind of information is better
provided by the docstring, not the call signature. Not least because the "type"
may be something wishy-washy and ad-hoc like "sequence" or "string or list of
strings". I do wish that people would document their parameters with this
information a little more consistently, though.
Steven D'Aprano
>>> class.method(name, count)
>>
>> Obviously? I don't know about that. Being told that "count" is an int
>> doesn't really help me -- it's obvious just from the name. In a well-
>> written API, what else could it be?
>
> A bool. As in telling the method whether or not it should count
> something.
Ha ha, good point. I question that this is a well-written API: such flags
to change the behaviour of a function/method are generally poor design.
If method behaves differently depending on whether or not you want it to
count something, then it is usually better design to have two methods,
one that counts and one that doesn't.
In any case, yes, the weakness of naming conventions is that there are
always odd-corner cases of natural language. Perhaps `name` is also a
flag telling the method whether or not to name something.
But then, one can write crappy APIs in any language.
--
Steven
Robert Kern
> On Wed, 03 Feb 2010 16:38:21 -0600, Robert Kern wrote:
>
>>>> class.method(name, count)
>>>
>>> Obviously? I don't know about that. Being told that "count" is an int
>>> doesn't really help me -- it's obvious just from the name. In a well-
>>> written API, what else could it be?
>>
>> A bool. As in telling the method whether or not it should count
>> something.
>
> Ha ha, good point. I question that this is a well-written API: such flags
> to change the behaviour of a function/method are generally poor design.
> If method behaves differently depending on whether or not you want it to
> count something, then it is usually better design to have two methods,
> one that counts and one that doesn't.
I prefer Guido's formulation (which, naturally, I can't find a direct quote for
right now): if you expect that a boolean argument is only going to take
*literal* True or False, then it should be split into two functions. There is a
use case for a boolean argument like this when you can expect to pass around a
variable between multiple functions.
Of course, this also might be the private API that the public API (with two
distinct methods for each case) uses internally in order to avoid code
duplication. Private APIs need to be documented, too.
> In any case, yes, the weakness of naming conventions is that there are
> always odd-corner cases of natural language. Perhaps `name` is also a
> flag telling the method whether or not to name something.
>
> But then, one can write crappy APIs in any language.
Well, I'm not trying to make Paul's point that other languages are better in
this regard. I think that type documentation is quite helpful, but requiring
static type declaration to get that documentation is an undesirable tradeoff for
most of the code that I want to write. I do think it is worthwhile to recognize
that the tradeoff does cut the other way, too. It just so happens that Python
has docstrings and argument annotations to document argument types without the
burden of static typing.
Not all good, clean APIs are always going to have argument names that clearly
inform the kind of type it expects. And what an author thinks is obviously
deducible while writing the API is often quite different from what a new user
thinks is obvious. There isn't much reason to place that cognitive burden on the
(many) readers of the code when the (single) author can put in a word or two
into the docstring (once) to describe what the parameter is expected to be.
Figuring out how to use an API to solve your real problem is hard enough without
having your brainpower nickled-and-dimed at every turn.
Steve Holden
>> can you sketch an example/use case more concretely?
>
> of implementation and some concrete features I would like to see in
> such system. For example:
>
> 1) Instant refactoring. No more needs for manual
> search/inspect/rename. Since system knows exactly that is going on,
> the refactoring will be fully automatic.
You'll probably want to take a look at "Bicycle Repair Man", which
offers Python refactoring functionality.
> 2) Show "xref table" for each function. How often this function used?
> Where is it used? (code snippets of calls) What functionality is
> supported by this function?
Bear in mind this information can only ever be partial, since functions
are first-class objects and aren't always referred to by their original
name.
> 3) Extended statistics. How many objects this object/function
> interacts with? Popular functions, dead/unused functions.
> 4) Code smell detector - too long functions, too much interaction with
> other objects, global objects, etc.
> ...
>
Also take a look at pylint and pychecker, which are already built to
perform that kind of check on Python code.
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
PyCon is coming! Atlanta, Feb 2010 http://us.pycon.org/
Holden Web LLC http://www.holdenweb.com/
UPCOMING EVENTS: http://holdenweb.eventbrite.com/
alex23
> frequently asks oneself "Uhh... so what is parameter X supposed to be...
> a string... a list... ?"
Could you provide an actual example to support this?
The only places I tend to see 'x' as a parameter in the Python library
docs are where it's clearly a number, or the text immediately beneath
it explains exactly what it is.
random.seed([x])
Initialize the basic random number generator. Optional
argument x can be any hashable object.
Everywhere else, the docs seem to declare what the parameters should
be _and_ explains them in the text:
itertools.combinations(iterable, r)
Return r length subsequences of elements from
the input iterable.
If you're finding places in the docs where this isn't the case, I'd
treat them as a documentation bug and report them. If it's not obvious
to you what an iterable is, well, I'm sure you've got a disparaging
term for those of us who do...
Ben Finney
> On Wed, 03 Feb 2010 18:48:12 +0300, Vladimir Ignatov wrote:
> > […] system "knows" all your identifiers and just regenerates
> > relevant portions of text from internal database-alike
> > representation.
You will probably want to learn about “refactoring” to see if that's
related to what you mean <URL:http://www.refactoring.com/>.
> Something like Bicycle Repair Man then:
Bicycle Repair Man has not shown any development activity since 2004.
Which is a shame, because it's an awesomely appropriate name for what it
does :-)
The niche is now occupied by the Rope library and tools
<URL:http://rope.sourceforge.net/>.
--
\ “Holy knit one purl two, Batman!” —Robin |
`\ |
_o__) |
Ben Finney
Ben Finney
> It is perfectly reasonable (and often necessary) for the unit test of
> class B to use a mock object instead of a real A() instance. The unit
> test for class B will fail to catch the renaming of A.foo() to A.bar()
> because it never tries to call .foo() on a real A instance.
Right, which is one good reason why unit tests are *necessary* but not
*sufficient*. You also need so-called “integration” tests (make sure
modules work together as expected) and “system” tests (make sure the
whole running system behaves as expected).
This need for testing is true regardless of whether you're using a
statically-typed or dynamically-typed language, of course. (I hope
no-one here thinks that static typing obviates the need for integration
and system tests in the test suite.)
--
\ “It is far better to grasp the universe as it really is than to |
`\ persist in delusion, however satisfying and reassuring.” —Carl |
_o__) Sagan |
Ben Finney
Vladimir Ignatov
>> > relevant portions of text from internal database-alike
>> > representation.
>
> You will probably want to learn about “refactoring” to see if that's
> related to what you mean <URL:http://www.refactoring.com/>.
I mean if system actually "understands" your code (instead of try to
figure it out from existing text files with source code), then much
more complex refactoring is possible. My favorite refactoring is
"Replace Method with Method Object". It is hard to imagine "external"
tool that can provide such refactoring for python code.
>> Something like Bicycle Repair Man then:
> Bicycle Repair Man has not shown any development activity since 2004.
> Which is a shame, because it's an awesomely appropriate name for what it
> does :-)
I believe it still live under the hood of PyDev plugin. I use it
almost every day and need to say that it don't provide much more than
simple renaming (which works right in 80% of cases in recent version).
Vladimir Ignatov
David Cournapeau
>>> > […] system "knows" all your identifiers and just regenerates
>>> > relevant portions of text from internal database-alike
>>> > representation.
>>
>> You will probably want to learn about “refactoring” to see if that's
>> related to what you mean <URL:http://www.refactoring.com/>.
>
> figure it out from existing text files with source code), then much
> more complex refactoring is possible. My favorite refactoring is
> "Replace Method with Method Object". It is hard to imagine "external"
> tool that can provide such refactoring for python code.
You may be interested by this project, then:
http://sourceforge.net/mailarchive/message.php?msg_name=9c768dc61001121642t5bd...@mail.gmail.com
It seems limited to Jython implementation unfortunately,
cheers,
David
purui
> This is obvious even in the Python documentation itself where one
> frequently asks oneself "Uhh... so what is parameter X supposed to be...
> a string... a list... ?"
>
That is partially why I created this search engine for python, to see
what parameters other people feed in.
http://nullege.com/
Vladimir Ignatov
> what parameters other people feed in.
> http://nullege.com/
Thank you for excellent effort! I found it very useful and start using
it on almost everyday basis. It's much simple to learn from real live
examples.
Vladimir Ignatov
Vladimir Ignatov
Thanks a lot! That is a great reference (a must read for everybody
interested). Reading just this: "Internally at Google we have a
language-neutral representation shared by all our language analyzers,"
make me jumping ;-) Googlers can't be wrong.
Vladimir Ignatov
Arnaud Delobelle
> I prefer Guido's formulation (which, naturally, I can't find a direct
> quote for right now): if you expect that a boolean argument is only
> going to take *literal* True or False, then it should be split into
> two functions.
So rather than three boolean arguments, would you have eight functions?
--
Arnaud
Steve Holden
I statement that calls one of two functions depending on the value of a
Boolean is normally considered to be better coupling than calling a
single function with the Boolean as an argument.
As with everything else you have to apply a certain amount of common sense.
bartc
"Steve Holden" <st...@holdenweb.com> wrote in message
news:mailman.1998.1265399...@python.org...
> Arnaud Delobelle wrote:
>> Robert Kern <rober...@gmail.com> writes:
>>
>>> I prefer Guido's formulation (which, naturally, I can't find a direct
>>> quote for right now): if you expect that a boolean argument is only
>>> going to take *literal* True or False, then it should be split into
>>> two functions.
>>
>> So rather than three boolean arguments, would you have eight functions?
>>
> If there's genuinely a need for that functionality, yes.
So you want a function such as drawtext(s, bold=true, italic=false,
underline=true) to be split into:
drawtext(s)
drawtextb(s)
drawtexti(s)
drawtextu(s)
drawtextbi(s)
drawtextbu(s)
drawtextiu(s)
drawtextbiu(s)
Which of course is going to be fun if the bold/italic/underline values are
not constants; instead of writing:
drawtext(s,b,i,u)
you have to say:
if b==0 and i==0 and u==0:
drawtext(s)
elif b==1 and i==0 and u==0:
drawtextb(s)
and so on. With half-a-dozen or more booleans, this becomes completely
impractical.
--
Bartc
Robert Kern
Then you refactor to
drawtext(s, font)
Steve Holden
>
> "Steve Holden" <st...@holdenweb.com> wrote in message
> news:mailman.1998.1265399...@python.org...
>> Arnaud Delobelle wrote:
>>> Robert Kern <rober...@gmail.com> writes:
>>>
>>>> I prefer Guido's formulation (which, naturally, I can't find a direct
>>>> quote for right now): if you expect that a boolean argument is only
>>>> going to take *literal* True or False, then it should be split into
>>>> two functions.
>>>
>>> So rather than three boolean arguments, would you have eight functions?
>>>
>> If there's genuinely a need for that functionality, yes.
>
> So you want a function such as drawtext(s, bold=true, italic=false,
> underline=true) to be split into:
>
> drawtext(s)
> drawtextb(s)
> drawtexti(s)
> drawtextu(s)
> drawtextbi(s)
> drawtextbu(s)
> drawtextiu(s)
> drawtextbiu(s)
>
implement significantly different logic flow for the two different
values of the Boolean.
> Which of course is going to be fun if the bold/italic/underline values
> are not constants; instead of writing:
>
> drawtext(s,b,i,u)
>
> you have to say:
>
> if b==0 and i==0 and u==0:
> drawtext(s)
> elif b==1 and i==0 and u==0:
> drawtextb(s)
>
> and so on. With half-a-dozen or more booleans, this becomes completely
> impractical.
>
It's completely impractical the way you've written it anyway, since the
drawtext function shouldn't be required to know whether it's printing
bold, italic, etc. - those properties should be attributes of the font.
Steven D'Aprano
> "Steve Holden" <st...@holdenweb.com> wrote in message
> news:mailman.1998.1265399...@python.org...
>> Arnaud Delobelle wrote:
>>> Robert Kern <rober...@gmail.com> writes:
>>>
>>>> I prefer Guido's formulation (which, naturally, I can't find a direct
>>>> quote for right now): if you expect that a boolean argument is only
>>>> going to take *literal* True or False, then it should be split into
>>>> two functions.
>>>
>>> So rather than three boolean arguments, would you have eight
>>> functions?
>>>
>> If there's genuinely a need for that functionality, yes.
>
> So you want a function such as drawtext(s, bold=true, italic=false,
> underline=true) to be split into:
>
> drawtext(s)
> drawtextb(s)
> drawtexti(s)
> drawtextu(s)
> drawtextbi(s)
> drawtextbu(s)
> drawtextiu(s)
> drawtextbiu(s)
No, of course not. But one might prefer a function with an alternate API,
such as:
style = TextStyle(bold=True, underline=True, size=12, font='helvetica')
drawtext(s, style)
style.italic = True
drawtext(s, style)
Other alternatives might be to pass the style information as a string
"BU" (bold underline) or a numeric flag (BOLD & UNDERLINE).
In general, if your implementation looks like this:
def function(args, flag):
if flag:
do_this()
else:
do_that()
then this is a good candidate for splitting into multiple functions.
Likewise:
def function(args, flag):
result = do_this()
if flag:
result = modify(result)
return result
or similar.
The point is that such a function uses the flag to select between two
different semantics. From a API perspective, it is generally better to
make each behaviour an independent function (perhaps calling a third,
private, function implementing any common behaviour). For example,
instead of:
def extreme(sequence, biggest=True):
"""Return the extreme value from sequence.
If biggest is a true value, return the maximum value, otherwise
return the smallest.
"""
pass # implementation left as an exercise
have two functions, max and min.
--
Steven
Gabriel Genellina
> "Steve Holden" <st...@holdenweb.com> wrote in message
> news:mailman.1998.1265399...@python.org...
>> Arnaud Delobelle wrote:
>>> Robert Kern <rober...@gmail.com> writes:
>>>
>>>> I prefer Guido's formulation (which, naturally, I can't find a direct
>>>> quote for right now): if you expect that a boolean argument is only
>>>> going to take *literal* True or False, then it should be split into
>>>> two functions.
>>>
>>> So rather than three boolean arguments, would you have eight functions?
>>>
>> If there's genuinely a need for that functionality, yes.
>
> So you want a function such as drawtext(s, bold=true, italic=false,
> underline=true) to be split into:
>
> drawtext(s)
> drawtextb(s)
> drawtexti(s)
> drawtextu(s)
> drawtextbi(s)
> drawtextbu(s)
> drawtextiu(s)
> drawtextbiu(s)
Note the *literal* part. If you (the programmer) is likely to know the
parameter value when writing the code, then the function is actually two
separate functions.
By example, foo.get_path(absolute=True) should be written as
foo.get_absolute_path() and foo.get_relative_path()
It gets worse when one parameter alters the type of the returned value, or
even the number of returned values. This is an actual example:
def build_image(self, zone=-1, return_sizes=False):
...
if return_size:
return img, sizes
else:
return img
image = foo.build_image(3)
but:
image, sizes = foo.build_image(3, True)
It should be split onto two separate functions; in this particular case,
computing 'sizes' required actually drawing the image, so the solution was
to make those 'sizes' attributes of the returned image.
--
Gabriel Genellina
Arnaud Delobelle
Thanks, I understand what Steve Holden meant now.
--
Arnaud
bartc
news:m28wb6y...@googlemail.com...
I've just noticed that 'literal' part. But I think I still disagree.
For a real-world example, it means instead of having a room with a
light-switch in it, if I *know* I want the light on or off, I should have
two rooms: one with the light permanently on, and one with it permanently
off, and just walk into the right one.
--
Bartc
Steven D'Aprano
> For a real-world example, it means instead of having a room with a
> light-switch in it, if I *know* I want the light on or off, I should
> have two rooms: one with the light permanently on, and one with it
> permanently off, and just walk into the right one.
I don't think you can apply real-world analogies to software in that way.
They're too different.
Think of the objections to having two rooms, one permanently lit up, the
other permanently not:
(1) Having two rooms is expensive and wasteful of physical space, which
is in short supply.
(2) You typically use rooms for storing things (furniture and smaller
objects), having two rooms mean you would need to clone every object
inside it and somehow keep them in perfect synchronisation.
(3) the light that is always on will use electricity 24 hours a day,
regardless of whether you are inside it or not.
But none of those objections apply to functions:
(1) Functions are cheap and live in memory, which is not in short supply
unless you're programming for an embedded device.
(1a) Even if you are programming in a device that is short of memory, the
overhead of a second function is minimal. There's little difference
between:
def func(flag):
if flag:
blockA
else:
blockB
and
def funcA():
blockA
def funcB():
blockB
for any non-trivial code blocks, particularly if any common code is
factored out into another function which you call.
(2) Functions aren't typically used for storage, and when they need
external data, it is easy to have them access a common data store.
(3) Functions don't use CPU cycles just by existing.
--
Steven
Alf P. Steinbach
I agree with your reasoning :-), but it's not either/or.
Consider, sometimes one wants to do
switch.off()
and sometimes one wants to do
original_switch_state = switch.state()
switch.off()
# ... Do things that are best done in utter darkness.
switch.set_state( original_switch_state )
E.g. the "switch" might be the enabled/disabled state of some GUI widget.
So IMHO it depends.
Sometimes one wants both kinds of "protocols".
Cheers,
- Alf
Gabriel Genellina
I think this would be a better analogy: A multiple screwdriver like this
one
http://img.alibaba.com/photo/204461747/Multi_function_screwdriver_screwdriver.jpg
You use it when you need flexibility, or you don't know in advance what
kind of screws you're going to encounter; they're mostly for hobbysts.
On the other hand, you have separate tools like this:
http://i277.photobucket.com/albums/kk43/hightecelectronica/021-482.jpg
You choose one of them when you know exactly what you want. If the stuff
you're working on uses exclusively certain kind of screws, you don't need
flexibility, and you can choose in advance. They're also professional's
choice.
--
Gabriel Genellina
Steve Holden
Fuzzyman
> On Feb 3, 10:57 am, Adam Tauno Williams <awill...@opengroupware.us>
> wrote:
>
> > > Current editors suck because they can't see into the code and browse
> > > it - unless it's so statically typed it's painful.
>
> > ? I edit Python in MonoDevelop 2.2; and I can browse my file,
> > classes, etc... So I don't know what you mean by "can't see into the
> > code". It works pretty well.
>
> > Of course it can't tell that I've set x = {an integer}, as that only
> > happens at runtime.
>
> > > That's why I wrote this:
> > >http://www.oreillynet.com/onlamp/blog/2008/05/dynamic_languages_vs_ed...
>
> You just said that your code browsing "works pretty well, except when
> it doesn't".
>
> Hence my blog entry. If your editor analyzed your code at runtime,
> instead of just static analysis, then it could see that x = an
> integer, or an object, no matter how dynamic your language.
>
The Wingware Wing IDE has an integrated debugger. The IDE does type
inferencing through static analysis to provide autocomplete and code
navigation features. If you run the code under the debugger it will
also use 'actual' type information to augment the static analysis.
Michael Foord
catonano
On Feb 3, 12:10 pm, Vladimir Ignatov <kmis...@gmail.com> wrote:
> Hello,
>
> I am sitting here for quite some time, but usually keep silent ;-) I
> Finally I develop a feeling that strong instrumentation / tools can
> bring us the best of two worlds. That I am dreaming on is an absolute
> new type/class of IDE suitable for Python and potentially for other
> dynamic-type languages. Instead of current text-oriented IDEs, it
> should be a database-centric and resemble current CAD systems instead
> of being just "fancy text editor". Source text should be an output
> product of that CAD and not a "source material" itself.
I don't know CAD systems, but I want to share my comments about this.
I self learned to program with Squeak Smalltalk at 17. Later, I worked
with VisualAge for Java, that was a Smalltalk IDE applied to Java.
Now, I can tell you that in Smalltalk IDEs the code is not written in
files. It's stored in a thing called "image".
You have these frames, in the first frame you have the classes, in the
second frame you have the child classes and in the third frame you
have the methods of the child class you selected.
A bigger frame showed the code of the single method you had selected.
You modified the method, hit ctrl-s and it was COMPILED and saved in
the image.
You had a frame in which you could interactively call your objects,
some of them represented things that were "showable" on the monitor
and you could see these things pop up as you instantiated them.
Then, you had some specialized browsers in which you could search, for
example, all the places a method was called in (a thing I have
difficulties with, in python, today)
VisualAge had its own management version system such that EVERY TIME I
saved a method, it became a VERSION and there was a specialized
browser for browsing the versions (the image tended to grow, that's
it) while the regular browser defaulted on the last version and there
was a tool for freezing a version as a milestone.
Today, I tried to understand the twisted.web.client code and I found 3
methods I couldn't find by who were called.
I asked on the mailing list and they suggested me where they were
called and that the tool for such thing is "grep".
So, you grep, you get a list of files, you open each one of them and
keep scrolling and switching from one file to another... endlessly.
Maybe I'm getting old, but I tend to get lost in the process.
I can't believe the code editing situation today is in a such sorry
state.
Is this what you meant ?
If it's this, then it's not experimental at all, it's been done
already and been put apart.
Crap won :-(
You write:
> Instead of current text-oriented IDEs, it
> should be a database-centric
well, it seems you agree with Alan Kay, (the Smalltalk inventor) when
he wrote that programming is NOT glorified text editing.
He called it "direct manipulation" every method was a live thing you
could send messages to and the source code that implemented it was
just an attribute of the method.
So you could have had a World Of Warcraft like interface, to
manipulate your methods.
You know what I'm doing now ? I'm drawing the map of
twisted.web.client on a paper with a pencil :-(
Bye
Catonano
Steve Holden
[... much wishing for the "good old day" of SmallTalk ...]
> Today, I tried to understand the twisted.web.client code and I found 3
> methods I couldn't find by who were called.
>
> I asked on the mailing list and they suggested me where they were
> called and that the tool for such thing is "grep".
>
> So, you grep, you get a list of files, you open each one of them and
> keep scrolling and switching from one file to another... endlessly.
> Maybe I'm getting old, but I tend to get lost in the process.
>
was given you so that it would be useful whether or not you were using
an IDE.
> I can't believe the code editing situation today is in a such sorry
> state.
>
It isn't. There are many IDEs that will allow you to easily locate the
calls of specific methods.
> Is this what you meant ?
>
> If it's this, then it's not experimental at all, it's been done
> already and been put apart.
>
> Crap won :-(
>
It seems you yearn for the days of the SmallTalk image. Unfortunately
this didn't allow for conveniences like using external data stored in
files whose contents persisted and which could be transferred between
different machines.
I would never call SmallTalk "crap": it was a ground-breaking system
almost 40 yers ago. But the environment suffered from many limitations
of which you appear to be entirely unaware.
> You write:
>
>> Instead of current text-oriented IDEs, it
>> should be a database-centric
>
> well, it seems you agree with Alan Kay, (the Smalltalk inventor) when
> he wrote that programming is NOT glorified text editing.
>
> He called it "direct manipulation" every method was a live thing you
> could send messages to and the source code that implemented it was
> just an attribute of the method.
>
This aspect of SmallTalk was one of the things that made software
engineering rather difficult. Everything could be changed on the fly.
> So you could have had a World Of Warcraft like interface, to
> manipulate your methods.
>
> You know what I'm doing now ? I'm drawing the map of
> twisted.web.client on a paper with a pencil :-(
>
Well why don't you get yourself a sensible tool like Wing IDE or Komodo?
They at least will let you solve the problem you currently face without
having to poke around in the innards of a running virtual machine the
way we used to in SmallTalk.
alex23
> You know what I'm doing now ? I'm drawing the map of
> twisted.web.client on a paper with a pencil :-(
You're a programmer. Why are you complaining about the problem instead
of endeavouring to solve it?
Bruno Desthuilliers
(snip)
> Today, I tried to understand the twisted.web.client code and I found 3
> methods I couldn't find by who were called.
>
> I asked on the mailing list and they suggested me where they were
> called and that the tool for such thing is "grep".
>
> So, you grep, you get a list of files, you open each one of them and
> keep scrolling
May I suggest reading grep's FineManual ? with proper options, you'll
get not only the file, but also the exact lines (and lineno) where the
expression appears.
> If it's this, then it's not experimental at all, it's been done
> already and been put apart.
>
> Crap won :-(
Ever read "worst is better" ?-)
Now, image-based systems like Smalltalk do have their share of quirks
and drawbacks too.
Also, Smalltalk's toolbox can only be used by and for Smalltalk. A bit
autistic, he ?
I'm doing mostly web development nowadays. That means that I'm
constantly switching between server-side code (mostly Python or PHP but
can be almost any other language), shell scripts, SQL, html + whatever
templating language is used by this project, javascript and css. And of
course quite a few configuration file formats...
So well, as far as I'm concerned, not having to learn 42+ different
toolboxes is a big plus (having to remember 42+ different languages is
already hard enough) - I can use a same code editor (Emacs) and standard
unix/linux text-handling tools on all my codebase.
Francis Carr
> state.
> Today, I tried to understand the twisted.web.client code and I found 3
> methods I couldn't find by who were called.
>
> I asked on the mailing list and they suggested me where they were
> called and that the tool for such thing is "grep".
>
> So, you grep, you get a list of files, you open each one of them and
> keep scrolling and switching from one file to another... endlessly.
> Maybe I'm getting old, but I tend to get lost in the process.
Maybe the relevant lesson to be taken from Smalltalk is *not*
"put it all in one image"
but instead
"write code to solve problems, e.g., reading code"
I suggest defining a few shell functions to *automate* the search, for
example in zsh
function allf () {
# Recursively find files with suffix matching comma-separated list
in $1.
# For example, "allf cpp,hpp" finds all "*.cpp" and "*.hpp".
find . -type f | grep -E "\.(${1//,/|})$"
}
function src () {
# Similar to "allf", then search for a regex among the results.
find . -type f -print0 | grep -zE "\.(${1//,/|})$" | xargs -0 grep -
lE $2
}
function srcl () {
# Similar to "src" (see above),
# then search for a pattern among the results,
# and pass matching files to "less".
src $1 $2 | xargs less -p $2
}
Smalltalk's images are cool. But they are such a huge hammer, and
they impose so many additional requirements! The costs outweigh the
cool.
-- FC
Aahz
Steve Holden <st...@holdenweb.com> wrote:
>bartc wrote:
>> "Arnaud Delobelle" <arn...@googlemail.com> wrote in message
>> news:m28wb6y...@googlemail.com...
>>> "Gabriel Genellina" <gags...@yahoo.com.ar> writes:
>>>>
>>>> Note the *literal* part. If you (the programmer) is likely to know the
>>>> parameter value when writing the code, then the function is actually two
>>>> separate functions.
>>>
>>> Thanks, I understand what Steve Holden meant now.
>>
>> I've just noticed that 'literal' part. But I think I still disagree.
>>
>> For a real-world example, it means instead of having a room with a
>> light-switch in it, if I *know* I want the light on or off, I should
>> have two rooms: one with the light permanently on, and one with it
>> permanently off, and just walk into the right one.
>
>Congratulations. That has to be the most bogus analogy I've seen on
>c.l.py this year.
Aww, c'mon, it's less than two months into the year, don't be so
hyperbolic.
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
"At Resolver we've found it useful to short-circuit any doubt and just
refer to comments in code as 'lies'. :-)"
Aahz
Bruno Desthuilliers <bruno.42.de...@websiteburo.invalid> wrote:
>
>Ever read "worst is better" ?-)
Nope -- maybe you mean "worse is better"?
http://www.jwz.org/doc/worse-is-better.html
(Nitpicking because you need the correct term to search.)
catonano
On Feb 11, 6:30 pm, Francis Carr <coldtort...@gmail.com> wrote:
> > I can't believe the code editing situation today is in a such sorry
> > state.
>
> I can't believe an old coder is feeling so sorry for himself.
Ok, I'm feeling sorry; still, I think I made a point.
> > Today, I tried to understand the twisted.web.client code and I found 3
> Maybe the relevant lesson to be taken from Smalltalk is *not*
> "put it all in one image"
> but instead
> "write code to solve problems, e.g., reading code"
> I suggest defining a few shell functions to *automate* the search, for
> example in zsh
>
> function allf () {
> Smalltalk's images are cool. But they are such a huge hammer, and
> they impose so many additional requirements! The costs outweigh the
> cool.
Francis, I disagree on the final balance statement about the Smalltalk
images and I thank you for your suggestions on how to use grep and
shell scripting.
I also have no problem to admit I was feeling sorry for myself.
But today I found something I think is relevant to this thread.
It's here:
http://www.cs.brown.edu/people/acb/codebubbles_site.htm
it's about a IDE for Java called Bubbles.
It sports a zooming interface and the MAIN idea it proposes, in my
opinion, is that the code is NOT thought as files content, rather as
fragments, called bubbles.
And then you arrange your bubbles in a 2d space a little bit like in a
videogame.
I think it's very similar to the Smalltalk image thing (as a concept,
if not as an implementation), with its live things and direct
manipulation.
If you open the footage directly in youtube, you can go to some
"related" footages about a similar thing made by Microsoft that of
course ditches the main idea retaining the concept of files and
directories, overlapping the concept of files and classes (sigh).
I didn't imagine such a research existed and the discovery confirms to
me that the bother I indicated in this thread is somewhat shared by
someone, around the world.
As for my feelings, I swear I'm taking care of them in a way that
doesn't involve bothering anyone on any newsgroup ;-)
Steve, does Bubble gets any closer to your vision than the "ugly"
Smalltalk thing ?
Bye
Catonano