153 reputation
5
bio website
location
age
visits member for 1 year, 6 months
seen Aug 8 '13 at 14:41

Apr
17
awarded  Critic
Feb
7
comment Good serialization solution for communication between Python AND Haskell programs?
@DeadMG: and yet they are not met in every program, or fulfilled to varying degrees, hence explicit specification.
Feb
7
asked Good serialization solution for communication between Python AND Haskell programs?
Feb
6
answered What to learn and how?
Feb
5
awarded  Commentator
Feb
5
comment Portability: Python's C/C++ libraries/extensions vs JRuby's Java libraries
@JanHudec: sure, but imagine the following scenario: there are Python wrappers for C/C++ libraries A, B and C. A and B are available say on Windows, B and C on Linux and only C is available (ported) to AIX. I have not encountered such scenario in practice apart from trouble of compiling mod_python on AIX (even then this is debatable as mod_python is extension to Apache not Python as such). The question is, is such scenario a real problem, which is my RoR/JRuby colleagues asserted?
Feb
5
asked Portability: Python's C/C++ libraries/extensions vs JRuby's Java libraries
Jan
25
comment Ensuring conceptual integrity in Python project with multiple programmers
@Glen7: I like your answer a lot actually but it is wider re good project management (it should be pinned up on pm stackexchange somewhere I think - is there a wiki here or smth?). Code ownership seems narrower issue here and it just happens to be particularly severe problem area for my team (more so than other areas from my POV) so I'm marking suslik's answer below.
Jan
25
awarded  Scholar
Jan
25
awarded  Supporter
Jan
25
accepted Ensuring conceptual integrity in Python project with multiple programmers
Jan
25
comment Ensuring conceptual integrity in Python project with multiple programmers
@MartijnPieters: re zope.interface (thanks!), a vague realization I had too was to make some classes "culturally untouchable" by declaring them that "those are top-level DESIGN classes, don't mess with them unless you have a good reason". I'm not saying this is a good idea, but you could I think get many people to treat them AS IF they were interfaces. Python bytecode compiler would not protest but if tests or dev lead detected that they could sort of slap wrists around, essentially getting similar human behavior to how Java interfaces seem to affect people's mind/behavior.
Jan
25
comment Ensuring conceptual integrity in Python project with multiple programmers
@suslik: re changing Java interfaces - yeah that's what I wondered too, if somebody wants to mess with a class or even abstract class in Java, why not mess with interface too? :-) Technologically there is no barrier to do it: however, the way people TREAT interfaces is as if they were sort of holy cows: theoretically you could slaughter it, but... they feel sort of "sacred", put above mere classes where you work all the time. Interfaces in Java are treated - for purely psychological and cultural reasons I think - as sort of "medium level design". At least that's my experience.
Jan
24
comment Ensuring conceptual integrity in Python project with multiple programmers
@gnat: thanks! hmm that's still quite sizable project.. I wonder what's going on much with this, as one of those Scala startups moved from Python to Scala precisely bc of experience of one of programmers with Python, that is, he could not sync his Python code with code of another Python programmer - then again, I got the impression (not confirmed out in the open though) that their integration was not quite continuous but more intermittent or spotty. Perhaps that was the source of the problem, I could not really dig deeper for other reasons.
Jan
24
comment Ensuring conceptual integrity in Python project with multiple programmers
@MartijnPieters: well that's what I meant, if not phrased very well: that a developer tends to write unit tests for his code only, and in isolation from other developers (every developer here writes unit tests, but it's not team activity).
Jan
24
comment Ensuring conceptual integrity in Python project with multiple programmers
@gnat: I very much would like my view on this (unit tests as sort of spec) not to be correct as I'd prefer working in Python to working in Java. :-) However, there are a few issues: 1. how big was the project you mention? My current project has about 40 people (20 developers, 20 testers). Would it be practical to scale that big in Python using TDD as spec only? 2. subteams dispersed geographically - now we have 4 teams in Europe and 1 team in California (just beginning the transition so it's too early to tell how it will work). Would unit tests work in this setup?
Jan
24
awarded  Student
Jan
24
comment Ensuring conceptual integrity in Python project with multiple programmers
@gnat: I also feel that unit tests, even written by groups, are not quite (limited) design or spec. They are low level after all and verify details mainly (that's the purpose I think, perhaps I'm in error on this). There's a reason (good maybe?) that Java has interfaces in addition to and not instead of JUnit.
Jan
24
comment Ensuring conceptual integrity in Python project with multiple programmers
Yes I know TDD defense but the problem here is that it is defensive since typically it's one person that writes unit tests. Of course, one could envision 1+ programmers sitting down together and writing unit tests before coding as sort of indirect spec + test but have you seen it done? I haven't.
Jan
24
comment Ensuring conceptual integrity in Python project with multiple programmers
In person: At least 3 times when talking to startups (2 Scala startups, so they have slant towards static typing) and at least once within corp when considering various programming languages for projects. On the web: can't remember this now, I have vague memory of reading it on some OO blogs and forums. Static typing guys (Java, Scala) seem to have been big on this point in my experience (YMMV of course), even though typically static typing and interfaces are usually meant for other things (speed, IDE autocompletion).