Friday, January 21, 2005

def __typecheck__: pass

__typecheck__: documentation, support for IDE, catch typo errors

I'm tired and sick, your finger is sticking into my eye. My
head is resting onto my fist. My ears are leaking connections
and the world is laying flat. Already the clocks are ticking
destructive demand and opposing is Homeric at best. The literature
has never been written, yet the breath is full of critical smoke.
A war is smiling at us.
It's dark and I'm ready to sleep.

- allow a human reader of code to understand better what happens in that code, since programmes can't really right documentation and they must be forced somehow to document their intentions
- this isn't going to be done unless declarations are enforced otherwise is going to remain a mechanism of not writing metadata. Maybe if we are driven into some special mood?
- if we enforce we are OK and flexibility is saved by ignoring any action possibly suggested by declarations
-rules are broken => documentation is less useful maybe is van maybe even more dangerous when trust is going to disappear
- what kind of help is this supposed to give to IDE programmers. Generic genuine help? what does it mean? Is this support the end of IDE request, will programmers ever want more tool support? maybe something that is not possible even with the most strict declarations of types and interfaces?
- function signature lookup? (IDE does import, run, dir?)
- type of current variable (use AST and type inference, or run code?)
- are we afraid to build slow solutions? are we afraid to build resource hungry solutions?
- solution first?, optimization later?, hardware support - embrace distance between script and system ?
- gather some IDE developers and discuss how to make it work, even if code will need be run, probably there are ways to get this without declaring intent
- maybe Python must grow an IDE out of it's core as a standard
- maybe Python needs library enhancement more stringently, maybe it needs to reshape old abstractions ?
- maybe building better abstractions is more useful? (are there any? Erlang, distribution, concurrence, network, Mozart)
- are more abstractions just sugar growing into diabetes ?
- gather people from PyChecker those that built type inferencers, those that built just in time compilers, those that built different semantics with similar syntax as python
- discuss implementation possibilities or design choices?
- 666 ?
- more easily said when you can hire people, harder when you can't?

- is python good as is, what does it need, why. Why doesn't python have types declarations already, is it demand? is it implementation difficulties, is it design? - Is there a philosophy? What is it? what is it for?

- are this declarations to help programmers? What are the trade offs? how much will it help? how much will it introduce confusion? what are the ramifications? what else will it impact?

- who will this make happy? who can use this efficiently? how many? what do the masses need most?
- how does the hardware market look like? where is it moving? are there any trends? is python aware?
- how is the corporate world? where is it moving towards? what does it seek?
- how is the python world? where is it moving towards? what does it seek?
- are there connections? are there too few? too many?


Post a Comment

<< Home