InformationResourcesCategories |
Static Analysis of Untyped LanguagesPosted by fred.bertsch in Software at 08:37 | Monday, March 10. 2008Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
but, the problem is that most untyped languages are uncompiled - such as Python, Ruby, etc. Without any compilation step before running the code there is no opportunity to check the types.
As a common user of untyped languages I don't often have the problem of passing wrong types, it has happened, just not very often. I also use the lack of types to my advantage. I have passed variables to a method where said method will work differently depending on what it recieves. Of course, one could rewrite this by doing method overrides - but such a feature generally doesn't exist in untyped languages. I think you should stop worrying about this - unless you're going to create your own untyped language that has some kind of compile step. Maybe you could call it Fruby, or Frython but definitely not FreHFre.
Lol at your language names!
Yes, I would add a step. There are, for example, Eclipse plugins which run similar lint-like programs for other languages. Running them is another step. I suspect that no one uses them, too. I this case, I wouldn't really expect people to use my tool. Perhaps, if there's real interest, I'd write an Eclipse or Visual Studio plugin, but the main goal is simply to see what's going on. I agree that I don't make type errors in untyped languages, either.
I think all languages should be untyped. Adding typing to a language is just building in inefficiency.
Why should I have to state what a variable and then set the variable to that type of thing? Why can't a variable figure out what it's type is based on the thing it is assigned to? Why can't the left hand know what the right hand is doing? Who are you really working for?
> Who are you really working for?
I'm a secret agent working for our competitors! Don't listen to me. > Why can't a variable figure out what it's type is based on the thing it is assigned to? After playing a bit with my project, I think it would be possible to create a language that did exactly that. You could create a strongly typed language that didn't require type declaration. Essentially, it would use the techniques that I'm using to try to deduce the type of each variable and declare an error whenever it failed. The language would be designed to make it as easy as possible to deduce the types. Unfortunately, the rules would be fairly complex. I doubt it would end up being pretty. It might make an interesting topic for another post, though.
> You could create a strongly typed language that didn't require type declaration.
OH you are just evil!!! Listen pal, if I want my string variable to morph magically into an integer; thats my right as a human programmer. And furthermore, you are not being nearly bombastic enough in your responses. A flame war is no fun if you keep responded with sensible, well reasoned statements. Flame it up man! Call me names...
Oooo. Okay, I can use the practice. I'll give it a shot.
> Listen pal, if I want my string variable to morph magically into an integer; thats my right as a human programmer. Magic has nothing to do with this. You interpreted freaks are always claiming that compilers do some "magic". Even if it were magic, you're dealing with the same stuff. Interpreted languages these days compile their code into byte code before executing it! Welcome to the second half of the 20th century, Andy. It's not just values that have types. Variables need it, too.
Now you're flaming! Well done, half-reasoned arguments followed by a snide comment.
So let's keep going... > Even if it were magic See, you're agreeing with me! > It's not just values that have types. Variables need it, too. and again! Why don't you just start arguing my side of the case? You're winning for me. You see, Variables are typed by the type of value they portend to represent. It's so obvious, but when it's get over-analyzed it becomes obfustcated by trivially planned hypotheses that are not founded in the Turing complete upper bounded (by big O, mind you). it's just so obvious...
Wow. That's pathetic, Andy! You can do better than that. You're just shooting yourself in the foot, here.
First of all, there is absolutely no way that trivial planning algorithms can have an upper bound! They always end up in committee! You're argument goes downhill from there: > it's just so obvious... Yeah! Variables have been typed since before the Vietnam war. Stop fighting history and start working with reality. Here's a perfect example from one of your very own Ruby fan bois! http://tinyurl.com/5vjvgq If that doesn't make you see reason, then you're probably still drunk from this morning.
I see what your problem is, you're living in the past.
> Variables have been typed since before the Vietnam war yes, but most programmers weren't born until after that - so maybe you scruffy bearded unix types are the ones caught in a temporal compiler error. So consider this snippet of Ruby, this demonstrates the awe inspiring power of duck-typing... # Accepts an object which responds to the +year+, +month+ and +day+ # methods. def date=(val) [:year, :month, :day].each do |meth| raise ArgumentError unless val.responds_to?(meth) end @date = val end As you can see, with Ruby we can do |meth| which allows us to lazily evaluate the date-ness of the thing we are receiving. Do I care what's typed on the left or right? Of course not, I'm doing each meth and I'll raise an Arugment for any Error you have unless it responds to my meth. geez, why do I have to explain this over and over again?
Andy, I thought you were drunk when you were writing your responses! Are you doing something else instead?
drunk? no, high on Rails my friend
well, I'm declaring myself the victor of this flame-war - looking forward to our next battle of wits |
QuicksearchPollsDid you buy an iPhone 3G?
Archives Login |