if youve read my comment on this already, this post will probably be redundant. but one of the things this blog is about is making it easier to learn programming, so i thought i would talk about how many people struggle with objects.
i designed a language with the aim of removing every feature you didnt need, and focusing on the ones that apply to most programming. it runs on top of the python language, and the “inline python” feature is there to make certain that nothing vital was left out. it also makes the language easier to extend, if you want to. (its good to provide a path from an educational language to a “real” one, even if people prefer to tinker with the former.)
to wrap your python code, simply include it in this block:
# the next command starts inline python python import time for p in range(5): print("python 2 was supported up until fig 3.0") time.sleep(.1) # this lets you get back to coding in the fig language: fig
in python, “everything is an object”: just look at “time.sleep” for a hint of that. when i learned to code, there wasnt nearly as much hype about objects as there soon would be for more than a decade.
what do you need to know about objects to code in python? practically nothing. python has lots of object support– youve got just about every feature. and yet if youre not interested, you can pretty much skip it.
one of my favorite things about python is that you can even abstract the annoying.dotted.hierarchies as simply as wrapping up the imported function (“method” if you like) in another python or fig function. the function command in fig maps 1:1 to pythons def command, so once you create your own function you can use it like any other command.
objects are supposed to make complicated things easier and more maintainable, and they can. however, a lot of what you need to do doesnt strictly require all the myriad details that object oriented design introduces.
i like abstractions that are easy to get into, easy to “desugar” and unabstract when necessary. unfortunately, getting into an object is like getting past red tape: objects are based on an ideal of making things easier, but the way they get used in the real world tends to create a fine mess of everything.
i would definitely make more direct use of objects if i wanted to make a web browser, or a game that had lots of characters; creating and tweaking instances of objects lends itself really well to that.
one of the worst things that ever happened to objects was their fanbase: oop was written into some revolutionary languages and bolted on to many others, and theres no consensus on implementation. when people talk about the advantages there is too much one-size-fits-allism and one-wayism, and yet so much everyday programming can be done (more easily, in easier to understand ways) without objects.
i would go so far as to say that programming in general would be a lot easier without them. on the other hand, the use of objects lends itself to more flexible typing (objects are not the only way to do this! but the design lends itself to an increase of it) and i do really love that flexibility in python.
i love it almost as much as the fact that python doesnt really require you to think about objects, if they dont assist you in your design or education. for so many years ive heard that “objects are the future!” in much the way you hear hype around functional programming now.
because cpu chips are not gaining speed like they used to, but instead gaining cores, concurrency is the new “wave of the future.” im not sure whether this can be avoided or not; but because of this, functional programming is the new “elite” paradigm, and as far as i can tell its easier to understand and teach than objects are.
im not much more excited about functional programming than i was about objects; it remains to be seen whether it can really solve all the problems it tries to address. i do find it interesting and educational, but more than that im happy to see the hype moving away from the one-wayism of objects-for-everything, and to find more honest individuals forced to admit that we really dont know (or necessarily need to know) what the future of programming really looks like.
to me, thats a much more mature and reasonable stance on what “good coding” is. it allows a lot more room to examine and solve real problems, including the problem of how to make programming easier for both students and professionals.
after all, youre in much better shape to learn things and find solutions if you dont believe you know the “best way” already. objects are not the one-true anything, theyre a tool you can use. if the tool youre using is getting in your way, either figure something out or put it down, and try another. there is still room for other ideas, and i am very thankful to see more people admitting it.
a side point that i hope will drive the message home, regards the poor old “goto” command and the debate that may never end: goto after all, is truly in everything we do. so much of programming has moved past mapping the simple jmp from asm or ml to higher level languages, though underneath the computer does so many “gotos,” it is one of the computers primary functions.
this means that goto itself cannot possibly hurt you: only its misuse. its true that overusing goto in a higher level language can ultimately paint you into corners, and that abstracting the process in a useful way can actually save you a great deal of trouble.
objects can be a useful abstraction, but like structured programming, they are never intrinsic to the operation of the computer. there is nothing inherently terrible about a processor instruction/address jmp, but abstracting it can benefit. likewise, there is nothing inherently beneficial about objects, but they suit some uses well enough to make inventing them worthwhile.
the costs of using objects are well documented and well argued. no one that believes they are a solution for every purpose will care that objects have design limitations– they will simply work around them, sometimes going to absurd lengths.
you however, have choices you get to make about those costs. you get to decide how much time you want to spend getting under the hood of something with as much notable overhead as object-oriented programming. ultimately, you get to decide how much trouble its worth to you.
we have at least moved to a point in the evolution of language design (which is not linear, but often convergent– i mean look at your own species– youre still using limbs? and hey, a spinal column: thats original!) where not everything has to be an object to be taken seriously.
well, finally! that means we at least have the option of moving forward.
- license: creative commons cc0 1.0 (public domain)