Updated aside about Declarative syntax

content/blog/2017/2017-02-14-declarative-notifications.adoc

@@ -156,35 +156,35 @@ def sendNotifications(String buildStatus = 'STARTED') {
 }
 ----
 
-// TODO clean this vvvvvvvvv up.  Don't spend so much space on it.
-
-== Declarative is still Jenkins Pipeline
-
-At this point, some of you will be saying,
+.Declarative is still Jenkins Pipeline 
+****
+Jenkins Declarative Pipeline is still *Jenkins*, still *Pipeline*, and still *Groovy*.
+Declarative Pipeline - everything inside
+the `pipeline {}` block - is a domain-specific subset is Groovy, but outside that
+we can still access all the facilities of Java, Groovy, and Scripted Pipeline.
+
+Looking at the method definition above, some of you will be saying,
 "Wait minute, wasn't Declarative Pipeline was supposed to get me away from
-Grooy, function definitions, and conditional logic?"
+Groovy, function definitions, and conditional logic?"
 When I first saw this, that's certainly what I said, only with a few more expletives.
 
-Let me start by stating the obvious - Jenkins Declarative Pipeline is
-still *Jenkins* and still *Pipeline*.  That means that underneath Declarative
-you will still find Java, Groovy, and all the Pipeline facilities.
-That is a good thing.  That is what ensures Steps that work in Scripted Pipeline
-will work the same way Declarative.
-
-Declarative Pipeline is intended to work with Pipeline, enhance it.
-Declarative, as it name suggests provides a way of *declaring* the overall
-flow of your pipeline.
-
-Declarative encourages clarity by guiding you towards separating your pipeline into
-two levels: an overall flow and individual steps.
-
-This is similar to Jenkins plugins.
-We declare the overall flow, but the complex logic and technology-specific work is handled by Steps.
-
-Here we've essentially created a Step called `sendNotifications` that takes a parameter
-and does some work based on that.  When reviewing the overall structure of the pipeline,
-we don't have to dig through the details of each step.  Like classic Jenkins plugins.
-// TODO clean this ^^^^^^^ up.  Don't spend so much space on it.
+Once I got past the original shock and started working with it,
+I found Declarative still being Groovy was actually a huge advantage.
+Coming from Scripted Pipeline, it meant I was already familiar with the basic syntax of Declarative Pipeline.
+For beginning Pipeline users, I this the same will be true in the other direction -
+the basic syntax of Declarative Pipeline is simpler introduction to Groovy that is
+used through out Pipeline.
+As we'll see in the remainder of this post, Declarative and Scripted Pipeline both being Groovy
+makes building up from simple to more complex Pipelines much smoother.
+
+Declarative Pipeline provides a structured way of *declaring* the overall flow of Steps in our pipeline.
+The complex logic and technology-specific work is handled by Steps.
+At the same time, Declarative doesn't care about how those Steps are implemented.
+Many Steps come from plugins, but here we've essentially created a Step called
+`sendNotifications` that takes a parameter
+and does some work based on that. When reviewing the overall structure of our Pipeline,
+we don't need to know the implementation details of Step.
+****
 
 == Adding Notifications