well, technically you're kind of right, but a small example probably will make it clear why you're wrong tho...
a small routine in pseudocode:
code( A, B, C, D ) :- ( find( B, 2, E ), E \= ``, copy( -1, _ ) ~> D ) <~ A ~> C .
Even if I'd send you the plain source of this program, you couldn't do much with it except ask yourself what the heck is this doing ???
or did you figure out that it's a text processor for tab separated stuff etc ?
more readable it looks like:
my_text_split( MyText, Separator, LeftPart, RightPart ) :-
( find( Separator, 2, Found ),
Found \= ``,
copy( -1, _ ) ~> RightPart
) <~ MyText ~> LeftPart .
operation:
'find' looks for the separator item, reading from the 'MyText' variable
if the result is not empty (separator found)
then it copies all characters from the current position into RightPart
the remainder is written to LeftPart
note the beauty of the bidirectional buffer handling and nested output:
(all char IO within parathesis reads from) <~ MyText ~> output
This is probably the most simple (useful) example beyond the classic 'hello world !' stuff and you're welcome to post the c/c++ equivalent
The declarations already would be longer than my whole program.
Btw an average programmer would (most likely) yield less than 10% of the performance because my pseudocode is backed by an assembly language implementation of the supporting pattern matching and buffer handling routines.
(btw the code is a snippet from a real world app)
You got the idea, don't you ?
Scope is the very same but way more complex for signal processing (instead characters) and on top of the pseudocode-layer there's an additional graphic representation.
Of course you can build a Scope device without SDK
You only need to know the specs of the 'pseudolanguage', it's syntax etc...
Then it's fairly easy to write your own compiler for it.

But let's assume (just for fun's sake) that you really succeeded...
For each and every(!) test step during developement you'd have to generate and transfer your device over to the Scope environment. LOL
In SDK a 'live' test environment is provided for interactive work.
There really is no coding whatsoever (in the sense you know it from C programming) going on in SDK or DP.
You can safely giveup that idea - after (almost exactly) 3 years
SDK is pseudocode with it's very own language and it's (almost certainly) 'superior' in performance and processing quality than any average to good 'custom code' implementation.
Just as the text processor above uses high quality machine code for the 'dirty' part of the job, Scope uses processing modules in DSP assembly or X86 code.
People don't seem to like this idea, as there's always some '...but I might do it better...' implied. Rubbish - those who really 'could do it' are smart enough not to bother with such questions at all. They would just act... and appreciate the tremendous amount of help the Scope system offers.