Reflective and Imperative Programming - Yet Another

Hank

Okay, I've been learning html. By that I mean learning enough so I could actually use it. 

This lead me to learn about CSS.

So this morning I got up and decided to look up what PHP, Ruby, and Ruby on Rails is,was,are?

All stuff I've brushed up against in the last few years but haven't been interested to learn "yet another" F.I.B. (Fill In the Blank ... get it? Pretty clever, huh? Don't answer that.)

When I got to the explanation of Ruby I fell down the rabbit hole of WTF are they saying? Kind of like when I read Scailia's majority opinion on the DC gun law case where he explained his opinion in terms of what it was not in relation to the minority opinion. The minority opinion was a wonderful piece of straight up beautiful English prose and explained the 2nd amendment issue.

The Ruby explanation says that it is imperative programming (WTF is that?) It's programming that is not procedural (that's like a soccer mom yelling don't bunch up around the ball). 

Wait let me quote from wikipedia:

"Ruby is a dynamic, reflective, general-purpose object-oriented programming language that combines syntax inspired by Perl with Smalltalk-like features."

 and

Ruby supports multiple programming paradigms, including functional, object oriented,imperative and reflective.

So what's imperative programming?

I quote

"In computer science, imperative programming is a programming paradigm that describes computation in terms of statements that change a program state. In much the same way thatimperative mood in natural languages expresses commands to take action, imperative programs define sequences of commands for the computer to perform.

The term is used in opposition to declarative programming, which expresses what the program should accomplish without prescribing how to do it in terms of sequences of actions to be taken. Functional and logic programming are examples of a more declarative approach.

Procedural programming is imperative programming in which the program is built from one or more procedures (also known as subroutines or functions). The terms are often used as synonyms, but the use of procedures has a dramatic effect on how imperative programs appear and how they are constructed.

Declarative programming is a non-imperative style of programming in which programs describe the desired results of the program, 

Many imperative programming languages (such as Fortran, BASIC and C) are abstractions ofassembly language.

[edit]

The hardware implementation of almost all computers is imperative;[note 1] nearly all computer hardware is designed to execute machine code, which is native to the computer, written in the imperative style. 

Okay, got it.

Now let's look at reflective programming

In computer science, reflection is the ability of a computer program to examine (see type introspection) and modify the structure and behavior (specifically the values, meta-data, properties and functions) of an object at runtime.[1]

The earliest computers were programmed in their native assembly language, which is inherently reflective as it is programmed by defining the instructions as data.

So it sounds like imperative and reflective are the same thing except reflective allows self-modifying code.

Geez, this reminds me of my sophomore year and there were these two guys who were coming up with any excuse they could to get on a machine: Algol, cobol, Snobol - whatever.

This would have been 1970. There were no PCs. My college had a computer center where you could take decks of Fortran cards to and get a run, maybe two, in a day.

The comp sci dept had some kind of mini that we could do Basic on (twice a week for half an hour each time). 

There was essentially two compiled programming languages: Fortran and Cobol.

And there was Basic.

Then there was all this weird stuff that no one really used.

When I read the imperative reflective stuff I start getting a headache. It sounds like all things to all people. 

Were you around XYZ Corp when they were pushing The Substrate?

I think that's what it was called.

There seemed to be two camps in XYZ's programming section. One was the Next/Apple group that was pushing the substrate - the idea that you could put some kind of diagram or functional objective outline of what you wanted into this software called the Substrate and application code would fall out the bottom. These folks actually believed someone would use something that they didn't understand!

No one understood it but you were supposed to Believe!

I just wonder if any of this stuff can do Hello World

Forget the new line.

Gotta go,

B