Things I have learned

The design of an application is greatly affected by the compiler. I use the term "compiler" to mean the thing that interrupts our programming action requests. Our application development process is a Wine Glass Technology

1. For a 100 line application it showed the inconsistency in our software development technology
2. Each "compiler" is not just a "compiler" it is also a design paradigm.  You are not free to design software, you are force to use another person's logic
3. Automated translation of an application from one language to another is not realistically possible (with brute force anything is possible)
4. All programming languages are the same
5. Scratch does not work in IE, it should (I had to write my own emulator)
6. Access to system parameters greatly changes the design
7. Speed of execution changes the design
8. Variable Scope conventions of the compiler changes the design
9. Orientation of the screen changes naming conventions and logic
10. No real benefit shown by any of the compiler's conventions
11. Time to implement was the same for all compilers
12. Readability of code was the same
13. Documentation reading was required and about the same for all development
14. Trivial capabilities were never consistent across languages
15. The drag and drop programming did not make it easier
16. I found python the most irritating to program, forcing me to do things the compiler could have done (1 Pass -- order dependencies, scope,...)
17. Every system had good and bad things that were arbitrary, I attributed this to the talent of the compiler's developer
18. Teaching any of these languages is the act of knowledge transfer of language conventions not logic or design
19. None of the languages were simple, meaning I needed to know far too much
20. All these systems were written by/for developers, not for application-ist
21. Coding style is very much language specific
22. Python seemed to be the least readable
23. Assembler used the keyword "invoke", why not just use "CALL", something else for me to remember.... developers have to pee on every tree
24. Variable names were not always precise, they were adjectives of a value, not the value itself (in one design correct, in another not correct)
25. The compiler's global scope conventions change the design and readability
26. The early choice of a variable name is often wrong (I used "x_bounce, y_bounce", maybe should have been "x_direction, y_direction")
27. Java had a messy form size and an odd graphic coordinate system, a lot of overhead
28. Documentation on Python seemed version dependent, had to try a few different methods to determine if the window had closed
29. Scratch was prone to a messy work area (difficult to manage), organization of blocks difficult to navigate
30. Scratch project files (*.sb3) are ZIP files (rename to .zip) then unzip, containing SVG images and a "project.json" file of blocks, comments, images, sounds and costumes
31. Writing the Scratch Emulator was simple enough, a few hours, I only handled the block types, about 12 of them, that I used in my bouncing ball example
32. In Assembler I had more trouble with keyword collisions, poor error messages
33. Debugging was hit or miss, C++ (visual studio) and JavaScript (browser) debuggers best for teaching, I did not try all the support environments for the other languages
34. Comments -- the compilers seemed to go out of their way to use something different...
35. implementation was based on experience and on documented online examples
36. we have no technology, we have a house of cards, everything will fail.
37. Program size difference (bytes),  Java: 3,225   Python 1,976   Scratch 131,072   C++ 3,740   Assembler 5,318   C#  2,220   JavaScript 2,134   Jane 175