I'm pretty much a beginner on this dynamic language thing. My background mainly is from assembly, C/C++, Java and C#, all the static typing languages. While, I do have a bit experience with Hashkell in my university years, I haven't put much effort on learning it (it's just for a class project, mainly using lists and functional programming). So my questions are maybe a bit newbie-ish, bear with me.

Ruby has been a buzz for quite a while for now and it's come to my attention to learn it. However, I still couldn't grasp the 'feeling' on using Ruby.

1. Is it like using the C++ Template mechanism? Like when you could just place a template T and call like T.something() but the type inferring is done in runtime as oppose to C++ compile time?

2. Isn't that going to be pretty hard to track down the source of problems when it happens? I had a terribly awful experience with hunting these kind of bugs when one of my programmer puts everything as objects in a Map class and he accidentally put an object of a different type in the map. How do you hunt those kind of bugs in Ruby? Do we have to keep checking the object type lwith 'is-a' mechanism? That would be awful and it wouldn't show me where the bug does actually occur. So, maybe the question is, how to debug or how debuggable is Ruby (and other Dynamic Languages also). My experiences with javascripts which I think is a kind of DL has taught me that DL is hard to debug. It also taught me to always strongly typed things to shield me from these kind of mistakes which i often call 'stupid mistakes'. Am I wrong?

3. From the architect perspectives, in particular Design Patterns, is it applicable in DL? Will it streamlines patterns? For instance if Im using the Strategy patterns, then I do not need to declare an abstract base class. In the video, you discussed this. But isn't that bad? I mean, I can throw anything to my 'engine' any object that have a 'process()' function althought that might mean very different. The Strategy pattern will most likely lose its meaning.

4. Can I draw/architect appropriate/sane softwares out of it? It seems like Class diagrams is also losing its meanings. And without a map, I cant picture how my software will turn out to be. How can you assess bugs?

5. How can I restrict/restrain my inexperienced and clumsy programmers from doing some stupid mistakes? In statically typed world, I can restrict them by strongly typing everything and mking sure they play by my rules. How do you implement that kind of leash on them?

I still have doubts about DL. And I have to confess that right now I cant picture building a large software using DL. If I cant get off my head from the 'stupid mistakes' how can I possibly focus on 'clever mistakes'? In other words, if I cant asses that the lower layers, the basic things will run fine, how can I build something reliable on top of it? My picture of DL right now is like building a building on sand.

This is still my preliminary opinion though, I dont really have professional experiences on any DL and I still need to learn about it.

Anyway thanks for the video, and sorry for the long post