Suggest appropriate goals for a super-basic Python class (HS level)

[izzion]

@Benjamin-Hall
I guess their next task should be crafting a WarthogKneelingFactory in Python

[dkf]

@Mason_Wheeler While OOP is a good thing in general, it is not an introductory concept. It instead marks one of the points where the programmer ceases to be a beginner and becomes an intermediate. (Other markers of this are things like a focus on understanding data structures and algorithms.) Without the basics, the more advanced material will just confuse. Understanding expressions and strings and variables and lists and dicts and control logic and functions, those are all higher priority for beginners. And are probably more transferable skills too; Python's OO flavour is a bit of an outlier.

[Mason_Wheeler]

@dkf said in Suggest appropriate goals for a super-basic Python class (HS level):

Python's OO flavour is a bit of an outlier

Boy ain't that the truth! Python OO is just weird.

[Benjamin Hall]

@Mason_Wheeler which is one reason I'm planning to only lightly cover inheritance when I get to classes. Also because I'm no expert myself.

Instead, I think I'm going to use the "advanced topics" part to do things like web scraping and other APIs, basic GUI work in tkinter, etc.

[Mason_Wheeler]

@Benjamin-Hall TBH I wouldn't use Python as a first language to teach students. Sure, you can get started very quickly, but you'll learn a bunch of really bad concepts that will footgun you once you try to do anything complex. (Dynamic typing, just to name the most obvious.)

I ran across a routine in the Python code at work today. It was 17 lines of code, plus whitespace and comments. After ing over it for about 3 minutes, I deciphered what it was supposed to be doing and realized the entire thing could be replaced by a one-liner in LINQ.

Not a particularly simple one; it involves a GroupBy and then running LINQ operators over the individual groups inside the Where operator, but it could be done and it would be a lot more clear. But Python's equivalent of GroupBy is a bit of a footgun with weird behavior that makes it significantly more difficult to use. (I asked about it once and IIRC the answer I got was that it was designed for processing indefinite-sized streams rather than finite data sets.)

[_P_]

@Mason_Wheeler said in Suggest appropriate goals for a super-basic Python class (HS level):

(Dynamic typing, just to name the most obvious.)

Bad programmers are bad, more at 11? If you don't look at what type a specific variable is before doing things to it, you're always shooting your foot with a gun, and strict typing wouldn't help you. Just look at some of the CodeSOD submissions with the ridiculous and unnecessary type hurdle hopping.

@Mason_Wheeler said in Suggest appropriate goals for a super-basic Python class (HS level):

But Python's equivalent of GroupBy is a bit of a footgun with weird behavior that makes it significantly more difficult to use

It's your fault for not reading the documentation and assumes that Python's groupby behaves like LINQ's GroupBy. FWIW, Haskell's groupBy behaves the same as Python's. If you're not trying to look for what you're putting in your code before doing so, you might as well fumble like an actual monkey.

If you want to count occurrences of items, use Counter. If you want to aggregate them to a list, use defaultdict(list) and then append as you loop over all entries. They're basic, standard Python idioms. If you're trying to use groupby, either it means you aren't doing it the primitive way, or it means you haven't learnt these basic idioms. In whichever case, is on your court.

@Mason_Wheeler said in Suggest appropriate goals for a super-basic Python class (HS level):

the answer I got was that it was designed for processing indefinite-sized streams rather than finite data sets

What's the WTF with "designed for processing indefinite-sized streams"? Generators are ubiquitous in Python. If you can't get around with comprehensions and generators you might as well not use Python and learn Java instead.

[Mason_Wheeler]

@_P_ said in Suggest appropriate goals for a super-basic Python class (HS level):

@Mason_Wheeler said in Suggest appropriate goals for a super-basic Python class (HS level):

(Dynamic typing, just to name the most obvious.)

Bad programmings are bad, more at 11? If you don't look at what type a specific variable is before doing things to it, you're always shooting your foot with a gun, and strict typing wouldn't help you.

Strict typing requires you to look at the specific type, though of course if you want to disregard it there are ways around that. With dynamic typing, you can't look at the type if you wanted to, because the information's not there. (If I have a method that receives value as an argument, I have no idea what value is or what it's valid to do with it without searching around and looking up outside information. If the parameter is explicitly value of type Foo, on the other hand... suddenly it's an order of magnitude easier to understand and reason about.)

It's your fault for not reading the documentation and assumes that Python's groupby behaves like LINQ's GroupBy.

Where did I say any of that? If I hadn't read the documentation, how would I know its behavior is all wrong? (And yes, the behavior is all wrong. If you're going to name something after a SQL operation, it's a POLS violation to have its semantics diverge radically from the SQL semantics.)

FWIW, Haskell's groupBy behaves the same as Python's.

And nobody uses Haskell, so why is this relevant?

If you want to count occurrences of items, use Counter. If you want to aggregate them to a list, use defaultdict(list) and then append as you loop over all entries. They're basic, standard Python idioms.

I was doing something a bit more complicated than either of those. The defaultdict solution might have worked, but it would still be significantly more code than the LINQ one-liner that you can get with proper, well-behaved operators.

What's the WTF with "designed for processing indefinite-sized streams"?

See above re: if you're going to name something after a SQL operator...

Generators are ubiquitous in Python. If you can't get around with comprehensions and generators you might as well not use Python and learn Java instead.

Was that supposed to be an insult? Because at least Java, for all its flaws, has a proper type system. Python can't even manage that!

[_P_]

@dkf said in Suggest appropriate goals for a super-basic Python class (HS level):

@Mason_Wheeler While OOP is a good thing in general, it is not an introductory concept. It instead marks one of the points where the programmer ceases to be a beginner and becomes an intermediate. (Other markers of this are things like a focus on understanding data structures and algorithms.) Without the basics, the more advanced material will just confuse. Understanding expressions and strings and variables and lists and dicts and control logic and functions, those are all higher priority for beginners. And are probably more transferable skills too; Python's OO flavour is a bit of an outlier.

@Mason_Wheeler said in Suggest appropriate goals for a super-basic Python class (HS level):

@dkf said in Suggest appropriate goals for a super-basic Python class (HS level):

Python's OO flavour is a bit of an outlier

Boy ain't that the truth! Python OO is just weird.

It's only weird if you look at OO the Java way, aka a very specific kind of class-ical inheritance. It only makes sense in Java (and C#, its improvement), and trying to replicate the same thing in other languages where the language model's clearly different from that is . Python doesn't obey it since it didn't start with such a language model, and it was added later on; Ruby is even less since its OO model comes from Smalltalk. And JS is prototype-based. Even JVM-languages like Kotlin does it quite differently.

Also, why is OOP considered an introductory concept? It's like you're teaching someone introductory English and you decide to specifically teach for the format of letters and how to write them. It just doesn't add up.

[dkf]

@Mason_Wheeler said in Suggest appropriate goals for a super-basic Python class (HS level):

TBH I wouldn't use Python as a first language to teach students. Sure, you can get started very quickly, but you'll learn a bunch of really bad concepts that will footgun you once you try to do anything complex.

That's funny, because that's what Python was originally designed for. The problems with it only really crop up when you start doing complicated things. Which is another reason for not teaching about classes; the majority of missteps in the language design are there and in the module system.

The worst misfeatures of Python's classes are mitigated by defining __slots__ on every class you create (where possible). That that piece of syntactic ugly is what you have to do to get some sanity is one of the more things about Python...

[Mason_Wheeler]

@dkf said in Suggest appropriate goals for a super-basic Python class (HS level):

__slots__

[insert casino gambling joke here...]

[_P_]

@dkf said in Suggest appropriate goals for a super-basic Python class (HS level):

The worst misfeatures of Python's classes are mitigated by defining __slots__ on every class you create (where possible).

I think you're using Python .

[Mason_Wheeler]

@_P_ said in Suggest appropriate goals for a super-basic Python class (HS level):

It's only weird if you look at OO the Java Simula way, aka a very specific kind of class-ical inheritance. the original, classical model of OOP.

FTFY

It only makes sense in Java (and C#, its improvement),

...and everything else in the Simula family tree, which you appear to be profoundly ignorant of. Java did not invent this model, not even close! It just happened to be in the right place in the right time to get popular off of it when the complexity that Simula-style OOP excels at dealing with was starting to become mainstream in software development.

Also, why is OOP considered an introductory concept?

Because these days it's something you need to know in order to write software that doesn't suck.

It's like you're teaching someone introductory English and you decide to specifically teach for the format of letters and how to write them. It just doesn't add up.

Wait... what? How exactly do you propose to teach someone to read and write basic, introductory English without knowing the letters?

[dkf]

@_P_ said in Suggest appropriate goals for a super-basic Python class (HS level):

@dkf said in Suggest appropriate goals for a super-basic Python class (HS level):

The worst misfeatures of Python's classes are mitigated by defining __slots__ on every class you create (where possible).

I think you're using Python .

I knew someone would bring that up.

Let's just say that I disagree, based on both performance data and ease of support for users.

[dkf]

@Mason_Wheeler said in Suggest appropriate goals for a super-basic Python class (HS level):

@_P_ said in Suggest appropriate goals for a super-basic Python class (HS level):

It's like you're teaching someone introductory English and you decide to specifically teach for the format of letters and how to write them. It just doesn't add up.

Wait... what? How exactly do you propose to teach someone to read and write basic, introductory English without knowing the letters?

I think he means letter as in "thing you write on paper to an aged relative in another country".

[Mason_Wheeler]

@dkf Huh. OK, that makes a little bit more sense. Still a weird argument.

[_P_]

@Mason_Wheeler said in Suggest appropriate goals for a super-basic Python class (HS level):

Strict typing requires you to look at the specific type, though of course if you want to disregard it there are ways around that. With dynamic typing, you can't look at the type if you wanted to, because the information's not there. (If I have a method that receives value as an argument, I have no idea what value is or what it's valid to do with it without searching around and looking up outside information. If the parameter is explicitly value of type Foo, on the other hand... suddenly it's an order of magnitude easier to understand and reason about.)

That's why you need to validate your arguments. It's not different from performing null checks.

Also, doing both of them incurs very different design choices. Sure, with strict typing you can tell the parameter is of type Foo. But at somewhere else you'd be making tons of hidden interfaces too just because you only need a intersection type/union type for two of the types you have. Type systems in most languages are shit and can't handle them in a sane way. Unless you're using something like TypeScript, but I doubt we're talking about that here.

@Mason_Wheeler said in Suggest appropriate goals for a super-basic Python class (HS level):

how would I know its behavior is all wrong? (And yes, the behavior is all wrong. If you're going to name something after a SQL operation, it's a POLS violation to have its semantics diverge radically from the SQL semantics.)

@Mason_Wheeler said in Suggest appropriate goals for a super-basic Python class (HS level):

See above re: if you're going to name something after a SQL operator...

SQL invented groupby?

@Mason_Wheeler said in Suggest appropriate goals for a super-basic Python class (HS level):

And nobody uses Haskell, so why is this relevant?

Just because you don't use Haskell doesn't mean it's not relevant.

Can you git gud and provide some actually good counter-points, like Ruby having slice_when for Python groupby behaviour and group_by for the LINQ groupby behaviour?

But, look, FFS, you're importing groupby from itertools. Repeat with me, itertools. The module where every function inside is for handling iterables the functional programming way. It's not collections.groupby. When you import something from a module, the module's name should give you an expectation what the things inside should be for. So if they really put your groupby in itertools that'd be the real WTF, since it wouldn't belong to itertools anymore.

@Mason_Wheeler said in Suggest appropriate goals for a super-basic Python class (HS level):

Because at least Java, for all its flaws, has a proper type system. Python can't even manage that!

Did you know that since Python 3.5 there's a typing module that provides type hints? If you don't want dynamic typing Python, use it. If you don't want dynamic typing JS, use TS. If you don't want dynamic typing PHP, P++ is currently under proposal. You can't just say it doesn't exist because you don't know about them

[_P_]

This post is deleted!

[Mason_Wheeler]

@_P_ said in Suggest appropriate goals for a super-basic Python class (HS level):

That's why you need to validate your arguments. It's not different from performing null checks.

Yeah, about that... a lot of research right now is going into being able to move that into the type system too, because you shouldn't have to deal with nulls in a context where null is not a valid value.

making tons of hidden interfaces

Wait, wait, what? When did we suddenly start talking about Go?

SQL invented groupby?

SQL invented the name. It was around for over a decade before Python even existed, much less the itertools package within Python's standard libraries. So my point stands: if you're going to copy the name, but deviate significantly from the semantics implied by that name, you're screwing the whole thing up.

Just because you don't use Haskell doesn't mean it's not relevant.

This is true. Me not using Haskell does not make it irrelevant. What makes it irrelevant is its utter irrelevance because nobody is using it. (Just for context, it's currently ranked 49th on the TIOBE index, below COBOL, Fortran, Lisp, Ada, RPG, and Prolog!)

But, look, FFS, you're importing groupby from itertools. Repeat with me, itertools. The module where every function inside is for handling iterables the functional programming way. It's not collections.groupby. So if they really put your groupby in itertools that'd be the real WTF, since it wouldn't belong to itertools anymore.

And yet somehow .NET manages to get the semantics right with Enumerable.GroupBy, which--as per your criteria, and also as expected from looking at the name--operates on enumerables (exactly equivalent to Python's iterables) and not collections.

[_P_]

@Mason_Wheeler said in Suggest appropriate goals for a super-basic Python class (HS level):

SQL invented the name. It was around for over a decade before Python even existed, much less the itertools package within Python's standard libraries. So my point stands: if you're going to copy the name, but deviate significantly from the semantics implied by that name, you're screwing the whole thing up.

@Mason_Wheeler said in Suggest appropriate goals for a super-basic Python class (HS level):

And yet somehow .NET manages to get the semantics right with Enumerable.GroupBy, which--as per your criteria, and also as expected from looking at the name--operates on enumerables (exactly equivalent to Python's iterables) and not collections.

LINQ is supposed to provide an interface to handle collections query languages. itertools is supposed to provide a set of tools that handle infinite iterables lazily the FP way. You perform query languages in Python through comprehensions (list, set and dict), not itertools. And have fun implementing tee in LINQ.

Yeah you're just completely and expect apples to behave like oranges or otherwise it's a .

[Mason_Wheeler]

@_P_ said in Suggest appropriate goals for a super-basic Python class (HS level):

@Mason_Wheeler said in Suggest appropriate goals for a super-basic Python class (HS level):

SQL invented the name. It was around for over a decade before Python even existed, much less the itertools package within Python's standard libraries. So my point stands: if you're going to copy the name, but deviate significantly from the semantics implied by that name, you're screwing the whole thing up.

@Mason_Wheeler said in Suggest appropriate goals for a super-basic Python class (HS level):

And yet somehow .NET manages to get the semantics right with Enumerable.GroupBy, which--as per your criteria, and also as expected from looking at the name--operates on enumerables (exactly equivalent to Python's iterables) and not collections.

LINQ is supposed to provide an interface to handle collections query languages.

...which is totally why the implementation is contained in a class called Enumerable. Because it's there to handle collections, not enumerables. Yep, that checks out.

itertools is supposed to provide a set of tools that handle infinite iterables lazily the FP way.

Oh, you mean like Enumerable does, where everything is lazy-evaluated that can be reasonably implemented as such? (For obvious reasons, this does not include things that require evaluating the entire enumerable sequence, such as ToArray, ToDictionary, OrderBy or GroupBy.)

You perform query languages in Python through comprehensions (list, set and dict), not itertools.

And how do you GroupBy with a dictionary comprehension?

And have fun implementing tee in LINQ.

...why is this even relevant? Itertools's tee isn't implemented on top of itertools; it's part of itertools. And the reference implementation wouldn't be particularly difficult to copy to C#.

Yeah you're just completely and expect apples to behave like oranges or otherwise it's a .

Once again, words have meaning. If you name something after an existing concept (such as GROUP BY in SQL) that carries with it an expectation that it will behave like the thing that it's named after. It's a bit bizarre for you to say that that expectation is rather than a system that violates that expectation.

[Zecc]

@dkf said in Suggest appropriate goals for a super-basic Python class (HS level):

Python's OO flavour is a bit of an outlier.

Understatement of the year so far.

[Zecc]

@Mason_Wheeler said in Suggest appropriate goals for a super-basic Python class (HS level):

I ran across a routine in the Python code at work today. It was 17 lines of code, plus whitespace and comments. After ing over it for about 3 minutes, I deciphered what it was supposed to be doing and realized the entire thing could be replaced by a one-liner in LINQ.
Not a particularly simple one; it involves a GroupBy and then running LINQ operators over the individual groups inside the Where operator, but it could be done and it would be a lot more clear. But Python's equivalent of GroupBy is a bit of a footgun with weird behavior that makes it significantly more difficult to use. (I asked about it once and IIRC the answer I got was that it was designed for processing indefinite-sized streams rather than finite data sets.)

Sounds like you're dealing with something you don't comprehend.

[dfdub]

@Mason_Wheeler said in Suggest appropriate goals for a super-basic Python class (HS level):

It's a bit horrifying to see so many supposedly competent programmers in here bashing on OOP.

That's not an accurate description of what we said in this thread. At all.

So what do you do? You organize it. And as is common for organizational systems, the best way to do it is to take the same basic concept and repeat it at a smaller scale. You can think of the entire program as one big object with some data and some functions that operate on that data... so now we create smaller objects with their own data and their own methods that operate on that data.

1. I don't think that's a great way to explain OOP. IMHO, you should start with polymorphism, because that's the main benefit of OOP, and then immediately mention SOLID. And those concepts require some experience to understand.
2. In Python (and other sane languages, i.e. languages that aren't called "Java"), you don't need OOP to organize your code base and hide implementation details. That's why modules and packages exist. In fact, I think it's fundamentally wrong to teach that OOP should be used for this purpose unless you're only trying to teach Java instead of general concepts.

[dfdub]

@Mason_Wheeler said in Suggest appropriate goals for a super-basic Python class (HS level):

With dynamic typing, you can't look at the type if you wanted to, because the information's not there. (If I have a method that receives value as an argument, I have no idea what value is or what it's valid to do with it without searching around and looking up outside information. If the parameter is explicitly value of type Foo, on the other hand... suddenly it's an order of magnitude easier to understand and reason about.)

RTFM before you make such claims: https://docs.python.org/3/library/typing.html

Obviously, this is not equivalent to static typing, but you're acting as if type hints don't exist in Python 3.

[dfdub]

@Mason_Wheeler said in Suggest appropriate goals for a super-basic Python class (HS level):

Because these days it's something you need to know in order to write software that doesn't suck.

We're talking about an introductory class here. Why are you acting as if the students are expected to write complicated software after that?

Also, no, you can write software that doesn't suck without knowing about OOP, but the FP thread is and this is the wrong category for discussing this. It's also the wrong category for your anti-Python rants, BTW.

[dfdub]

@Mason_Wheeler said in Suggest appropriate goals for a super-basic Python class (HS level):

That's why you need to validate your arguments. It's not different from performing null checks.

Yeah, about that... a lot of research right now is going into being able to move that into the type system too, because you shouldn't have to deal with nulls in a context where null is not a valid value.

null is the easiest case. Ultimately, to actually solve the problem, you'd need something like Ada's derived types.

@_P_ said in Suggest appropriate goals for a super-basic Python class (HS level):

But at somewhere else you'd be making tons of hidden interfaces too just because you only need a intersection type/union type for two of the types you have. Type systems in most languages are shit and can't handle them in a sane way.

The unfortunate truth is that the type systems of most widely-used statically typed languages are not powerful enough and as a consequence can be very annoying. It also means that they don't prevent as many mistakes as they could and probably should. Which is not a good argument against static typing in general, but a reason why people choose dynamically typed languages in practice.

[acrow]

Might I suggest including at least one assignment/excercise that uses a GUI library? A simple "make cat-pic rotate by adding code between these markers"?

As fun as OO and SQL are, they don't exactly fan the spark for most people. After the command-line Hello Worlds are done, students may still find the connection between them and those fancy vidjagames a mystery. Doing one GUI exercise might de-mystify it.

[_P_]

@acrow said in Suggest appropriate goals for a super-basic Python class (HS level):

Might I suggest including at least one assignment/excercise that uses a GUI library? A simple "make cat-pic rotate by adding code between these markers"?

As fun as OO and SQL are, they don't exactly fan the spark for most people. After the command-line Hello Worlds are done, students may still find the connection between them and those fancy vidjagames a mystery. Doing one GUI exercise might de-mystify it.

OO and SQL are fun?

I'm pretty sure most people who end up still coding would be delving down the road of making yet another ASCII roguelike instead. And let's hope they don't mistake GUI as OpenGL...

[Carnage]

@_P_ O-PL/SQL?

[pie_flavor]

@_P_ said in Suggest appropriate goals for a super-basic Python class (HS level):

Even JVM-languages like Kotlin does it quite differently.

How?

[pie_flavor]

@dfdub said in Suggest appropriate goals for a super-basic Python class (HS level):

Ultimately, to actually solve the problem, you'd need something like Ada's derived types.

Swift does this (sort of).

[pie_flavor]

@Mason_Wheeler said in Suggest appropriate goals for a super-basic Python class (HS level):

If you're going to teach a programming class, you'll be doing the kids a massive disservice if you don't teach them about OOP, because OOP is what the world of programming runs on.

Who cares? You didn't read the post. Suggestions aren't supposed to be evaluated on whether they're something a programmer needs to know, but on whether they're teachable to people who barely know how to navigate a file system. Not to mention, you talk like the primary purpose of OOP is procedural abstraction rather than dynamic polymorphism, which tells me that to you everything looks like a nail.

[Mason_Wheeler]

@pie_flavor said in Suggest appropriate goals for a super-basic Python class (HS level):

Who cares? You didn't read the post.

Yes I did. Did you read my post?

Suggestions aren't supposed to be evaluated on whether they're something a programmer needs to know, but on whether they're teachable to people who barely know how to navigate a file system.

Again, did you read my post? I specifically didn't recommend starting with OO on day 1. By the time they get to OOP, they won't be "people who barely know how to navigate a file system" anymore.

Not to mention, you talk like the primary purpose of OOP is procedural abstraction rather than dynamic polymorphism, which tells me that to you everything looks like a nail.

I talk like the primary purpose of OOP is managing complexity, which it is, explain how to build that concept in a student's mind from the ground up, and present polymorphism, which is the crown jewel of OOP, at the end. What exactly is wrong with that approach?

[hungrier]

@Mason_Wheeler said in Suggest appropriate goals for a super-basic Python class (HS level):

a one-liner in LINQ.

Not a particularly simple one; it involves a GroupBy and then running LINQ operators over the individual groups inside the Where operator, but it could be done and it would be a lot more clear.

Sounds like the kind of thing that would be a lot clearer split up into about 17 lines

[Mason_Wheeler]

@hungrier It's really not. It used the old "sort everything, initialize aggregation variables at the top, then loop over everything, processing as you go, adding to the result set and resetting the variables when the key changes, then at the end repeat the 'add to the result set' logic outside the loop for whatever's left over" anti-pattern I'm sure you've seen a dozen times and probably written once or twice. Big, bulky, hard to read, much simpler to express in LINQ.

[hungrier]

@Mason_Wheeler I didn't say "do the exact same thing as the original implementation that you didn't like". But if you're doing more than one LINQ operation (at least two that you mentioned explicitly), putting them all on one line is only helpful if you're code golfing.

[Mason_Wheeler]

@hungrier Well, there's also the "put each operator in the chain on its own line" style, in which case it would have taken 4 lines. I generally prefer that style when the chain gets long enough that you'd have to scroll horizontally to read it, or one-liners when it doesn't. It didn't get that long in this case.

[pie_flavor]

@Mason_Wheeler Because the primary purpose of OOP isn't about managing complexity. It's about dynamic polymorphism. I literally just said that, except I worded it "procedural abstraction" instead of "managing complexity".

[Mason_Wheeler]

@pie_flavor And why is dynamic polymorphism useful? Because it's so incredibly helpful in managing complexity.

[Dragoon]

@Mason_Wheeler

I say let them write something complex without it, so they can actually see the usefulness of polymorphism. In my experience, far to many of the intro to OOP examples are far to simple for people to really see what you can gain with OOP. Leaving the student feeling like they have added complexity, not removed it.

Until you have actually designed something complex without OOP and than refactored it with OOP you won't fundamentally grasp what OOP provides. You will just be one more coder who just follows what other people tell them, no thought involved.

[Mason_Wheeler]

@Dragoon I agree. Which is why I said it's best to start off teaching procedural programming and then introduce OO concepts. (Which @pie_flavor seems to have missed out on.)

[Carnage]

@Dragoon Also, lets not forget that slathering on a thick helping of "OOP" also increases complexity. Case in point, any old system written in Java. Interfaces for things with only one implementation in a deep hierarchy with all sorts of "lets shove every single thing into an object!" so that you have a wrapper class for every sort of primitive use your codebase contains and fun stuff like that.

[dkf]

@dfdub said in Suggest appropriate goals for a super-basic Python class (HS level):

Which is not a good argument against static typing in general, but a reason why people choose dynamically typed languages in practice.

The fundamental issue with types is that you generally want them to be simpler than the program itself, just so that programmers can cope with them and to keep compilation complexity down. Without the type system being Turing-complete, there's always going to be (many!) properties of the program that it can't reason about. Exactly which properties should be characterised by the type system is something that people definitely do not agree about, and people who prefer dynamic typing tend to be less bothered about trying to prove fancy properties ahead of time.

The big problems with being type-strict everywhere tend to show up in larger applications, where more and more of the logic becomes focused on mapping between independent strict type domains. People who haven't worked on a large enough project won't believe me on this, but the more integration work being done, the more strict type systems get in the way. (In theory you could have a single type system to handle all of that which makes everything really easy. In practice, you instead have warring components where each simply tell everything else to adopt its model, and the integrator has to shim everything together and hope they didn't screw up…)

[Carnage]

@Mason_Wheeler That is what pretty much everyone in this thread also said, and you went ahead and read it as everyone saying not to teach OOP at all.

[ObjectMike]

@_P_ said in Suggest appropriate goals for a super-basic Python class (HS level):

Did you know that since Python 3.5 there's a typing module that provides type hints? If you don't want dynamic typing Python, use it. If you don't want dynamic typing JS, use TS. If you don't want dynamic typing PHP, P++ is currently under proposal. You can't just say it doesn't exist because you don't know about them

My understanding is the type hints in python 3 are only suggestions. The problem with Typescript's typing is that it's not required. You can write plain old Javascript in your Typescript and that's valid.

[Mason_Wheeler]

@Carnage said in Suggest appropriate goals for a super-basic Python class (HS level):

@Mason_Wheeler That is what pretty much everyone in this thread also said, and you went ahead and read it as everyone saying not to teach OOP at all.

Hmmm...

@Carnage said in Suggest appropriate goals for a super-basic Python class (HS level):

I think OOP may be unecessary. And considering a lot of professional programmers can't do OOP properly, inflicting it upon an introductory programming class for people with no computer skills might be a bit of waste of time.

@anonymous234 said in Suggest appropriate goals for a super-basic Python class (HS level):

Here's a point no one has talked about: after teaching basic imperative programming (fuck that OOP noise), teach the basic ideas behind code design.

@topspin said in Suggest appropriate goals for a super-basic Python class (HS level):

I just want to concur that OOP has no place in such a very beginner’s course (it’s not the 90s anymore).

...you were saying?

[Carnage]

@Mason_Wheeler said in Suggest appropriate goals for a super-basic Python class (HS level):

@Carnage said in Suggest appropriate goals for a super-basic Python class (HS level):

@Mason_Wheeler That is what pretty much everyone in this thread also said, and you went ahead and read it as everyone saying not to teach OOP at all.

Hmmm...

@Carnage said in Suggest appropriate goals for a super-basic Python class (HS level):

I think OOP may be unecessary. And considering a lot of professional programmers can't do OOP properly, inflicting it upon an introductory programming class for people with no computer skills might be a bit of waste of time.

@anonymous234 said in Suggest appropriate goals for a super-basic Python class (HS level):

Here's a point no one has talked about: after teaching basic imperative programming (fuck that OOP noise), teach the basic ideas behind code design.

@topspin said in Suggest appropriate goals for a super-basic Python class (HS level):

I just want to concur that OOP has no place in such a very beginner’s course (it’s not the 90s anymore).

...you were saying?

That you misread what everyone said in this thread. Thank you for proving my point.

[hungrier]

@mikehurley said in Suggest appropriate goals for a super-basic Python class (HS level):

The problem with Typescript's typing is that it's not required. You can write plain old Javascript in your Typescript and that's valid.

That's kind of true, in the sense that it all compiles down to Javascript eventually, and you can mark things with any which tells the compiler to ignore any type issues with that variable. But in general it'll highlight errors and warnings and fail to compile if you've done something wrong.

[ObjectMike]

@hungrier said in Suggest appropriate goals for a super-basic Python class (HS level):

@mikehurley said in Suggest appropriate goals for a super-basic Python class (HS level):

The problem with Typescript's typing is that it's not required. You can write plain old Javascript in your Typescript and that's valid.

That's kind of true, in the sense that it all compiles down to Javascript eventually, and you can mark things with any which tells the compiler to ignore any type issues with that variable. But in general it'll highlight errors and warnings and fail to compile if you've done something wrong.

I think the biggest thing that bothered me about Typescript was it didn't fix how "this" is handled.

[Captain]

@dkf said in Suggest appropriate goals for a super-basic Python class (HS level):

It instead marks one of the points where the programmer ceases to be a beginner and becomes an intermediate.

This should be high school now. :-)