Extremely Serious Bug in Monkey C!!!

Travis, you're confusing or conflating two entirely orthogonal aspects of programming language design: type checking versus information hiding (object oriented data structure extension).

Yes. Definitely conflating. The statically typed languages that I'm familiar with provide facilities for multi-level information hiding, and the few dynamic languages do not, or they do so as an afterthought.

At least with a type checking system, if the colliding variables are of different types you will get a compiler error;

Yes, a statically typed language would give you an error at compile time, but by definition a dynamically-typed language isn't statically typed. And now we're no longer discussing multi-level information hiding in MonkeyC, we're arguing the disadvantages of a dynamically-typed language.

in the absence of type checking, you have to find this problem by way of testing.

Yes. This is one of my biggest frustrations with dynamically-typed languages. The type isn't known until the code is executed, and that is often the wrong time to find an issue. Even if you write unit tests it is easy to have a program explode because a parameter of the wrong type was provided to some operation.

Could someone tell me what the motivating factor for Monkey C in an embedded system is?

Obviously I can't answer that one, but my guess is that had a lot to do with barrier to entry. Personally, I'd rather have seen an existing language (any existing language). I think it would have given us access to a wealth of knowledge about the existing tool chain, and would likely have given us access to useful tools (like a debugger) long ago. I'm betting that another compiler could be provided in the future, but I'm not betting on it.

Sounds like one real solution is to have it be guaranteed that all stock objects follow a certain naming convention. You indicate they all start with m[Capital Letter]. Not quite as good as the __ names for python. This helps with system libraries. Are there even third party libraries that could be an issue here? Do we know that all the system libraries follow this convention?

I think the real issue that Peter is getting at is that it is a real problem if your code behavior changes just because you happen to use the same variable name as a base class, that you have no way of knowing you are using the same name. Or if the base class changes with updates to use a name that conflicts with your super class.

If the only way to write code is through trial and error, I would agree with Peter that it is a broken language. It should be deterministic, which unless the stock libraries follow a strict naming convention, this would not be.

If there is a standard naming convention that I can know to avoid certain names, that solves this problem, short of 3rd party libraries.

I think the real issue that Peter is getting at is that it is a real problem if your code behavior changes just because you happen to use the same variable name as a base class, that you have no way of knowing you are using the same name.

Yes, I think adding private or local support to MonkeyC, with behavior similar to that of the double-underscore prefix in python, is a totally reasonable enhancement. I think it would also be useful for the compiler to be updated to complain if you declare a variable with the same name in a hierarchy.

Or if the base class changes with updates to use a name that conflicts with your super class.

Yes. If a new name is added to a class in the library, and that name conflicts with a name in existing user code, there would be problems and there is no way to know without recompiling the user code.

If the only way to write code is through trial and error, I would agree with Peter that it is a broken language.

So are python (and similar duck or dynamically-typed languages) broken?

If there is a standard naming convention that I can know to avoid certain names, that solves this problem, short of 3rd party libraries.

Not ideal, but you could adopt a convention for all variables that is sufficiently obscure that it wouldn't possibly collide. Something as simple as using the python system for obscuring names (prefix the variable with __classname_) would be sufficient for most cases.

Travis

Do you have any experience with dynamically-typed languages (Lua, Ruby, Phthon, ...)?

So are python (and similar duck or dynamically-typed languages) broken?

Hm... C# is dynamic language which I mainly use and it is not broken :). But I avoid 'dynamic' keyword because there are much more disadvantages than benefits.

If you considered the prefix m[A-Z] to be reserved for the implementation, you'd be very unlikely to step on any toes.

This is mine naming convention too :(. So as I see I have a real problem.

I think the name is mJustification. It isn't documented, so I don't think you should rely on it.

Thank you Travis but it must be something else. Actually I wonder why this value isn't available.

Peter

...
So are python (and similar duck or dynamically-typed languages) broken?
...

I have very little experience with these languages so really can't speak to them. But I've always felt/been taught you should theoretically be able to write code that you know will work without first running it through the compiler or just just running it. Yes, I know in practice this would never happen for code of any complexity (more than 2 lines probably :) With this kind of system, you are going to run into cases that there is no way for you to know you aren't writing working code. You could spend days debugging a conflict due to this issue if it manifested itself in unpredictable results, especially if it were only causing issues on the actual device under real world conditions without full debugging ability.

I used to work on low level OS code and loved the fact that I could see the source code for every single line of executed code including in the kernel. No hidden surprises. Here you are calling black boxes where you have no clue what is going on, but even their name convention can impact you.

Not ideal, but you could adopt a convention for all variables that is sufficiently obscure that it wouldn't possibly collide. Something as simple as using the python system for obscuring names (prefix the variable with __classname_) would be sufficient for most cases.

We appreciate the discussion going on here, and despite the (valid) criticism, I'm happy to see that people are passionate about what we're doing and how we're doing it. Due to the OP's initial comments, we've had some conversations that mirror some of what's been said here. In particular, we've talked about something similar to what Travis suggested above, because the most emergent concern we have is name collision with undocumented class or module variables.

The merits of strongly typed vs. dynamically typed languages is an argument that goes way beyond the scope of Connect IQ, so I doubt we'll get any of that solved here. However, we can take action to improve Monkey C and address some of the concerns. I encourage everyone to add their comments on this, because it's a great conversation. However, I don't think that it's constructive to suggest that we simply switch to a different language/compiler. :) That will quickly devolve into a language war (if it hasn't already), and we all know where that goes.

On an unrelated note, vi is the best text editor ever, there are no reasons why anyone should use anything else, and if you don't use it you should switch immediately. (I kid, I kid.)

Yes, I agree completely! It seems to me that if MonkeyC were to be fully developed out - after much pain, tribulation, and learning - they will replicate one of C#, Java, or Smalltalk. Yet, of course, all of these languages are available as either a commercial product or an open source project; all of these can be targeted for whatever the CPU on these watches is, and all of these have fully mature toolchains and development environments. I don't see any benefit - and a lot of loss - to the roll your own approach, especially when the DIY approach doesn't break any new ground and offers no special functionality.

It would have been groundbreaking had they chosen Erlang, and one year in they would be way ahead of the current state at vastly lower net cost.

One thing that must be considered in something other than Monkey C (like Java or Smalltalk) is the size and performance of the VM on devices. I actually had a job porting Smalltalk to various embedded platforms, and there was always a concern with the size of the VM vs functionality, so in some cases, it wasn't a full-functioned Smalltalk VM in the end, and at other times, things had to change to get the required performance.

One thing that must be considered in something other than Monkey C (like Java or Smalltalk) is the size and performance of the VM on devices. I actually had a job porting Smalltalk to various embedded platforms, and there was always a concern with the size of the VM vs functionality, so in some cases, it wasn't a full-functioned Smalltalk VM in the end, and at other times, things had to change to get the required performance.

Understood, and been there and done that exact project myself. But note that MonkeyC is a fully dynamic, everything-objects language with single inheritance, full memory management (currently reference counting), modules / globals / classes for scoping, and exception handling. We've seen lots of other languages exactly like this - and we've seen how long those have taken to mature. (Anyone remember the early days of JavaScript on desktop browsers? How many years was it before threads were reasonably ok to use?!) Maybe the MonkeyC team will be able to implement their language super quickly with all that existing knowledge, but the fact that this thread has popped up over a year after release doesn't bode all that well....

I hope the MonkeyC team gets this language evolved and right, and I hope they are able to do it quickly: these watches are great hardware with great styling. But the current development platform that we 3rd party developers have access to has a lot of shortcomings and only lets us develop apps that are 2nd class citizens. (Shortcomings: even Pebble gives us two threads and wakeups, communication with the mobile is woefully lacking, and there are zero tools for ensuring programs are correct; 2nd class citizens: native Garmin apps can interact with files and there are provisions for communication between widgets and apps, widgets and apps start instantly.)

Shortcomings: even Pebble gives us two threads and wakeups

Cannot compare apples and oranges.
Each has their own market segments