everything is an object, but objects arent everything

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
    import time
    for p in range(5):
        print("python 2 was supported up until fig 3.0")
    # this lets you get back to coding in the fig language:


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.

this isnt to say that we would be entirely better off without them. in my opinion, objects are useful for connecting your program with user-interface elements in python and document elements in javascript. i find “object oriented programming” almost tolerable in those situations; sometimes even enjoyable.

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.





2 thoughts on “everything is an object, but objects arent everything

  1. I’d have to argue a slight point I feel like you’ve overlooked: objects serve a single important purpose: to group together bits of data. Consider linked lists (for a simple example). It’s true that you could create multiple lists to store each bit of data, but as complexity grows, so does the issue of keeping track of simultaneous lists. C, while being a primarily function-based language, still needs structs for (what I’ll call) “sane programming”. I’ve come across a number of problems where there was simply no better solution than grouping things as objects. Is there a best solution for things? Well, how about “best set of solutions”? There may be multiple ways of using the same paradigm to solve a problem which are better than solving it without that paradigm. Admittedly, programming is a competition between speed, memory, and security. Pick one, the other two will suffer.

    I’m certainly not confined to pure object-oriented programming. In fact, the language I’m creating is very much function-oriented for a number of reasons I intend to discuss. Ultimately, language essentials boil down to a few simple things that enable you to do everything else any generic language can do. When you realize that, every programming language is, in some senses, the same, and it’s merely a matter of figuring out how that language gives you those essentials before you learn and master that language. Having toyed with a dozen or more languages, I have almost no trouble learning new ones. The only annoying parts are the round about ways you have to go about following certain syntax rules.

    Overall, this is an interesting article, and I find some of your points very agreeable. Maybe it’s just my luck, but I don’t encounter the OOP-is-king crowd that much except on job descriptions that require OOP coding skills. I think many programmers gravitate towards it because of its readability and ease. I, for one, used to program with just functions, but I find it much easier to create and understand the overall structure of software in certain languages when they use OOP. It’s interesting how programmers’ mentalities have had to change in order to work with languages like Rust. Keeping an open mind will certainly benefit you in the long run, and it makes it easier for you to pick the best language for the job rather than one you may have a preference for simply because you enjoy the paradigms you apply when working with it.

    You’re right about goto. As a young programmer, I learned goto was taboo. I didn’t understand quite why for awhile until I read more about it, but even then, it doesn’t have to be evil. I did, in fact, use the C++ goto for a program and it turned out to be the very best option. No matter how much I wanted to use if-else blocks, etc., nothing worked better or was more readable than using goto in that situation. Goes to show that little keyword does have its uses. Saying that to certain people would probably cost a job interview though.

    Liked by 1 person

    1. i didnt quite overlook it. i never have to pass data structures complicated enough to require object hierarchies to manage them.

      i do think there are jobs where oop is probably the easiest thing to do (and in that case i might use them myself.) i also never liked a language more than i like python, and while it should be possible to implement the parts i like without oop underneath, i doubt anyone ever will.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s