3 ms·

I think that's a little too black and white back the other way. Don't get me wrong, I live in python, I create classes on the odd occasion I need them and not

by aidos 13y ago

I think that's a little too black and white back the other way. Don't get me wrong, I live in python, I create classes on the odd occasion I need them and not before it's definitely required. That said, there's nothing wrong with sitting down and modelling the problem you're trying to solve on paper to try to understand what's involved. You don't need to implement it that way. Whatever you do, stop and take a moment to think it through.

chaosphere2112 13y ago
The thing that I keep finding myself wanting in Python is a more structured way to refer to data; fortunately, that's what namedtuple[1] is for. >>> DataType = namedtuple("DataType", ["field1", "field2"]) >>> datum = DataType(1, "a") >>> datum DataType(field1=1, field2='a') >>> datum.field1 1 >>> datum.field2 2 Keeps my code a bit more sensible than constantly indexing into tuples, imo. [1]: http://docs.python.org/2/library/collections.html#collections.namedtuple http://docs.python.org/2/library/collections.html#collection...
- textminer 13y ago
  It was personally strange to start programming in earnest with Python, and think namedtuples (or classes with __slots__) were so cool and efficient, and then learn C and just think "oh yeah. Structs."
- jayferd 13y ago
  What's really missing though is unions with destructuring `case`. Once you start coding in a language with proper unions, it's hard to go back. In python it might look something like this: DataType = union({ 'type1': ['field1', 'field2'], 'type2': ['field3'] }) DataType.type1(val1, val2) DataType.type2(val3) # pretend syntax case datum: DataType.type1(a, b): doSomethingWith(a, b) DataType.type2(c): doSomethingWith(c)
azov 13y ago
It's not philosophically wrong to model the problem upfront, it's just very hard to get it right in practice. You don't literally have to start with one function. If you've solved a similar problem before you may have a good idea of what the code structure is going to be (this is what design patterns are all about). Frameworks may force a structure on you. There are shortcuts. But even then, I've been bitten more then once by the problems that looked awfully similar to what I've done before only to turn out to be very different at the end.
ollysb 13y ago
I think this is the right way to start learning OO. The difficulty with OO modelling though is that many of your classes are abstract ideas that don't have a real-world counterpart. How to group information into classes can be decidedly unintuitive. For this type of modelling it's better to group information into classes according to their lifecycle. Normally the only way you can really know this is to build the system and refactor as the lifecycles become more obvious. On another note, the problem with the way OO, and really programming in general at the uni level, is taught is that it's always in the context of toy apps that aren't going to grow. This encourages an up front planning process and you can get away with it because all you have to do is make it work. You're only learning how to tell the computer what to do, not how to build a system that can adapt to a changing user base for instance. Perhaps it's necessary that you learn to just talk to a computer first and with experience learn to build growable systems. The problem though is that the upfront planning process is taught as _the_ way to build a system.

by aidos 13y ago

chaosphere2112 13y ago

The thing that I keep finding myself wanting in Python is a more structured way to refer to data; fortunately, that's what namedtuple[1] is for. >>> DataType = namedtuple("DataType", ["field1", "field2"]) >>> datum = DataType(1, "a") >>> datum DataType(field1=1, field2='a') >>> datum.field1 1 >>> datum.field2 2 Keeps my code a bit more sensible than constantly indexing into tuples, imo. [1]: http://docs.python.org/2/library/collections.html#collections.namedtuple http://docs.python.org/2/library/collections.html#collection...

textminer 13y ago
It was personally strange to start programming in earnest with Python, and think namedtuples (or classes with __slots__) were so cool and efficient, and then learn C and just think "oh yeah. Structs."
jayferd 13y ago
What's really missing though is unions with destructuring `case`. Once you start coding in a language with proper unions, it's hard to go back. In python it might look something like this: DataType = union({ 'type1': ['field1', 'field2'], 'type2': ['field3'] }) DataType.type1(val1, val2) DataType.type2(val3) # pretend syntax case datum: DataType.type1(a, b): doSomethingWith(a, b) DataType.type2(c): doSomethingWith(c)

azov 13y ago

It's not philosophically wrong to model the problem upfront, it's just very hard to get it right in practice. You don't literally have to start with one function. If you've solved a similar problem before you may have a good idea of what the code structure is going to be (this is what design patterns are all about). Frameworks may force a structure on you. There are shortcuts. But even then, I've been bitten more then once by the problems that looked awfully similar to what I've done before only to turn out to be very different at the end.

ollysb 13y ago

I think this is the right way to start learning OO. The difficulty with OO modelling though is that many of your classes are abstract ideas that don't have a real-world counterpart. How to group information into classes can be decidedly unintuitive. For this type of modelling it's better to group information into classes according to their lifecycle. Normally the only way you can really know this is to build the system and refactor as the lifecycles become more obvious. On another note, the problem with the way OO, and really programming in general at the uni level, is taught is that it's always in the context of toy apps that aren't going to grow. This encourages an up front planning process and you can get away with it because all you have to do is make it work. You're only learning how to tell the computer what to do, not how to build a system that can adapt to a changing user base for instance. Perhaps it's necessary that you learn to just talk to a computer first and with experience learn to build growable systems. The problem though is that the upfront planning process is taught as _the_ way to build a system.