Programming and Legos

[MyndFyre]

I was browsing through really, REALLY old BotDev posts, and saw this:

I still blame CupHead!!

Programming is not equivalent to legos or jigsaw puzzles.

I'm curious, Grok: do you still believe that?

I wrote a blog entry last fall about a geek-out project that I was working on, and decided that I ended up liking programming because it's a lot like playing with Legos, like I did when I was a kid: http://geekswithblogs.net/robp/archive/2008/08/20/software-development-and-legos.aspx

Specifically, I wrote this:

Everything is done in components.  We have a frame, then a wing, then another wing.  The bridge.  All of these go together with little regard for how the rest of the ship is built.  Just like we build software.  We try to solve a problem, but we try to make sure that our components can be used or adapted to solve another problem as well.

How do you all approach software engineering?

[Yegg]

I agree that it can be compared to building legos, but that's not a comparison I make when I'm working on something myself. I don't think I really compare it to any activity that is done outside of computers. I just see the language as a tool to manipulate date a particular way. I build different parts of the program one at a time and put it all together, much like building blocks, but I never think about it that way when I'm doing it.

This turned out to be a harder question to answer than I thought, but this is probably the best way I can explain it.

[Warrior]

I believe only fairly recently has componetized programming become something of standard practice.
I think a good question to ask yourself would be, back then, did you yourself think of programming in that manner?

I've only really seen composite applications take root fairly recently, certainly today the comparison is valid, but I'm not so sure about back then.

[Yegg]

I believe only fairly recently has componetized programming become something of standard practice.
I think a good question to ask yourself would be, back then, did you yourself think of programming in that manner?

I've only really seen composite applications take root fairly recently, certainly today the comparison is valid, but I'm not so sure about back then.

Grok was referring to when he was around our age. 

[MyndFyre]

I believe only fairly recently has componetized programming become something of standard practice.
I think a good question to ask yourself would be, back then, did you yourself think of programming in that manner?

I've only really seen composite applications take root fairly recently, certainly today the comparison is valid, but I'm not so sure about back then.

Really?  Code Complete, First Edition was published in 1993 and talked extensively about componentization.  OLE was part of Windows 3.x and was Microsoft's first framework for componentization, which later was superceded by COM.

[Warrior]

That's cool, and a lot of that precedes me as a programmer, but my question still remains did it become a standard practice? Something can exist without it being something used on a widespread basis.

Cool nonetheless.

[RiffRiot]

Well, I can say that I loved Legos when I was a kid and I still have a huge box of them.  Occasionally I will get them out and make something.  In regards to components, I believe it does resemble some programming logic but like Yegg said, when you're getting down to it I am thinking more of manipulating data in a particular way, although, with Legos you are manipulating certain pieces in a certain way to get a desired result.

[MyndFyre]

That's cool, and a lot of that precedes me as a programmer, but my question still remains did it become a standard practice? Something can exist without it being something used on a widespread basis.

Cool nonetheless.

Procedural programming was the first programming language paradigm, following imperative programming, to create subsets of functionality.  In procedural programming, the basic unit (building block) is the procedure; today, we might think of these as subroutines, methods or functions.  Wikipedia even notes that it allows programs "the ability to be strongly modular or structured."  COBOL, Fortran, and Algol were among the first procedural languages, and the specification for COBOL was developed in 1959.

So, yes, I would say that it's highly likely that componentization was pretty standard practice.

[Grok]

I don't think componentization became widely popular until Visual Basic introduced the VBX.  The other examples you gave are structured, but that is not componentized.  And you can hardly call modular and componentized the same thing.  I don't remember using any COBOL tools (prior to VB3 days) that allowed wrapping up units into reusable packages the way you could with Visual Basic and its VBX.  But then I didn't use very many packages.  I think Borland eventually released (bought or created) a COBOL based package that did, but it was years after VBXs.

Myndfyre you know the answer to your question.  The reason you are able to compare programming and legos are because of the OOP principle of inheritance.  Both types of projects are derived from the superclass of "constructing/building things".  No surprise there.

In the quote, I apparently said they were not equivalent.  Neither are Secretary and Manager but you can talk all day about their Employee features that are in common.

But Legos are cool, so that might trump all other arguments.

[Yegg]

That's cool, and a lot of that precedes me as a programmer, but my question still remains did it become a standard practice? Something can exist without it being something used on a widespread basis.

Cool nonetheless.

Procedural programming was the first programming language paradigm, following imperative programming, to create subsets of functionality.  In procedural programming, the basic unit (building block) is the procedure; today, we might think of these as subroutines, methods or functions.  Wikipedia even notes that it allows programs "the ability to be strongly modular or structured."  COBOL, Fortran, and Algol were among the first procedural languages, and the specification for COBOL was developed in 1959.

So, yes, I would say that it's highly likely that componentization was pretty standard practice.

Was imperative programming the next paradigm that arrived after procedural? LISP was developed in 1960. Wikipedia and other sources state that imperative programming began in the 1960s.

[MyndFyre]

I don't think componentization became widely popular until Visual Basic introduced the VBX.  The other examples you gave are structured, but that is not componentized.  And you can hardly call modular and componentized the same thing.  I don't remember using any COBOL tools (prior to VB3 days) that allowed wrapping up units into reusable packages the way you could with Visual Basic and its VBX.  But then I didn't use very many packages.  I think Borland eventually released (bought or created) a COBOL based package that did, but it was years after VBXs.

Myndfyre you know the answer to your question.  The reason you are able to compare programming and legos are because of the OOP principle of inheritance.  Both types of projects are derived from the superclass of "constructing/building things".  No surprise there.

In the quote, I apparently said they were not equivalent.  Neither are Secretary and Manager but you can talk all day about their Employee features that are in common.

But Legos are cool, so that might trump all other arguments.

I was more describing the general practice of encapsulation than creating components like VBXes.  Functions can be components, but dynamically-linked libraries even provided for componentization.

Was imperative programming the next paradigm that arrived after procedural? LISP was developed in 1960. Wikipedia and other sources state that imperative programming began in the 1960s.

I would generally classify imperative programming as something like machine-language or assembly language.  Although high-level assembly eventually supported things like procedures, this wasn't a feature of early assembly languages.  Procedural programming was an evolution of imperative programming.

Lisp is more of a functional or declarative programming approach and is contrasted to imperative programming.

[Grok]

MicroFocus COBOL is the one I could not remember.