7 ms·

I'm good with options, but I like the way Lua is, as it is. I don't really accept that types are needed for safety in my games, or any application I've used Lu

• adamnemecek 12y ago
  Generally, statically typed languages are less bug prone than dynamically typed languages. Dynamically typed languages are OK for smaller projects but as projects grow in size, you have to write a lot of tests to be sure that everything works. Also, projects written in statically typed languages are easier to read and navigate for humans and it's also easier to write static analysis tools for them.
  • fithisux 12y ago
    Dynamically typed languages are good for very small programs. Typed Lua is going to be a big innovation.
  • srean 12y ago
    If there are consequential performance gains to be had then even better. An interesting case is Dart. The implementers have a strong dynamic typing bias and wanted to keep Dart as dynamically typed as possible. Their position was we dont need any static typing for speed. They have since relented. You realize that you just planted a good solid troll magnet of the "I never make any type errors" variety. Some people get annoyed by the notion that you can enlist the compiler (using succinct syntax) to write and validate tests that they ought to be writing. They would rather write the tedious tests themselves. @spankalee They had a blogpost along those lines, sadly not bookmarked, but you might be able to find it.
    • spankalee 12y ago
      What makes you say that Dart "relented" on not using type annotations in the runtime? The VM basically throws the type annotations away. In production mode, the type annotations can be completely wrong and your program will still function, and still be just as fast.
  • taeric 12y ago
    Is there empirical evidence of your first claim? Or any claim, honestly.
    • adamnemecek 12y ago
      What sort of evidence are you looking for? E.g. http://www.infoq.com/presentations/Types-Tests http://www.infoq.com/presentations/Types-Tests ? But googling something like static vs dynamic typing will give you enough results to choose from. Or go to your local Haskell user group meetup :-).
      • taeric 12y ago
        No, googling those results doesn't really work. :) You get a ton of dogma with a lot of logical arguments. All of which are very appealing. Appealing arguments worry me, though. What I have not seen, is evidence that any of your claims are true. I have seen easy to read programs in both dynamic and static languages. So far, I've seen very little correlation between the two as to which is desirable. The static languages are typically a bear on some algorithms because you have to provide so much more to the compiler for it to trust you. This does feel like it would lead to less bugs, but it goes against the "readable" and possibly the "more productive" ideas.
        • adamnemecek 12y ago
          How do you determine the return value of a C function? You look at the function prototype. How do you determine the return value of a Python function? You have to read the whole thing. If you are working with large code bases, reading the whole thing is not really possible.
          • taeric 12y ago
            You are just trying to make an appealing argument. This literally adds nothing to the debate. A simple survey of open source software would be more convincing. And even that wouldn't be definitive.
  • fit2rule 12y ago
    There isn't really much evidence of this out there, other than groupthink, in my opinion. What makes a language 'okay for smaller projects' but suddenly unsuitable when it gets larger? Having a minimal set of types doesn't necessarily mean you're going to have 'more bugs as the codebase grows' - the only place it really makes sense to say that dynamically-typed languages 'break' is when they don't have the types that the application needs. In Lua's case, the only thing I can think of it missing is native floating-point support, and that's really it. Everything else: you can get there with nil, number, string, function, CFunction, userdata, and table. (But CFunction and userdata should be enough for anyone! :)
    • adamnemecek 12y ago
      If nothing else, it kind of follows from Curry-Howard correspondence. What makes it okay? This Python program will not throw an exception when ran def f(x): return x if False: f(1,2) even though the types are wrong. Are you 100% certain that you will never make a bug like this even when there are 10^13 conditions and the call stack is deeper than the Mariana trench? Note that that this is not the only type of bugs that static typing prevents.
    • dottrap 12y ago
      Lua already has native floating support (by default). The number type is double by default. Lua 5.3 (work 2 already available) introduces integer subtypes so now you can have both floating point and integers.
    • Jtsummers 12y ago
      > What makes a language 'okay for smaller projects' but suddenly unsuitable when it gets larger? One and one makes two. Two and two makes four. Four multiplied by eighteen is seventy-two. Compare to: 1+1=2 2+2=4 4*18=72 Notation, aka language, has scaleability as a feature, whether the designers intended it or not. Dynamically typed languages are nice, I love them for prototyping, and some of them, I think, are suitable for large scale applications. But not all of them. The notations made available in some languages just make large scale development easier or harder (for various reasons). Consider using maps/json objects to produce data constructs, this is a sort of duck typing unless you add some sort of schema checker to it. At which point it's either a runtime error or you're running your code through a static analysis tool. Why not use an actual type system for this that the compiler checks at compile time? I feel like a broken record this past week. Dynamic languages are good, I can't imagine doing the sort of exploratory/prototyping stuff I've done in them with typical statically typed languages. I wouldn't even object to using erlang for a large scale project (actually, I'd love to do this), it's got features in both syntax (bit syntax, I love it) and semantics (concurrency) that make it ideal for certain problem domains. It's got dialyzer which gets back a lot of the static analysis that statically typed languages offer. On the other hand, javascript offers duck typing, weak typing, dynamic typing, it's fine for certain applications (and essential for anything living in a web browser these days), but it's type system holds it back for large scale work. Experienced programmers may be able to get passed it with relatively few errors, but it's still going to suffer huge performance issues because there's only so much that can be known about the values passing through a block of code. Does `a + b` mean we're adding two numbers? A number and a string? two strings? The result changes depending on those circumstances and the interpreter/compiler just doesn't know enough to optimize it significantly. Similarly, it doesn't know that one is an error right away, the actual error may start here, but only appear in some function that's a child/parent/cousin in the call tree, obfuscating the cause and creating a great deal of work for the developer and tester.
  • dragonwriter 12y ago
    > Dynamically typed languages are OK for smaller projects but as projects grow in size, you have to write a lot of tests to be sure that everything works. Or build your large systems as compositions of smaller systems. If dynamically typed languages are really okay for smaller systmes, than avoiding bad architecture of large tightly-coupled systems in favor of loosely coupled compositions of smaller subsystems means that it is also okay for large systems. > Also, projects written in statically typed languages are easier to read and navigate for humans This is not my experience. > and it's also easier to write static analysis tools for them. Well, yes, since you have to write a static analysis tool for a statically typed language (since the compiler must include such a tool), its not at all surprising that the structure of statically-typed languages is always designed specifically to serve static analysis tools. IME, that's why they've historically been harder to read and navigate for humans, though some exceptional modern statically typed languages have largely closed that gap (but not reversed it, IMO.)
    • imanaccount 12y ago
      >If dynamically typed languages are really okay for smaller systmes, than avoiding bad architecture of large tightly-coupled systems in favor of loosely coupled compositions of smaller subsystems means that it is also okay for large systems. It doesn't mean that at all. You might as well say "if shoes are good enough for going to the corner store, then multiple pairs of shoes are good enough for going to the moon". The notion that large systems are no more complex than small systems if you simply make the large system out of small systems is not supported by anything I can find. >IME, that's why they've historically been harder to read and navigate for humans That doesn't make any sense at all. How is having information written down instead of having to constantly remember and/or deduce it an impediment to reading?
      • dragonwriter 12y ago
        > It doesn't mean that at all. You might as well say "if shoes are good enough for going to the corner store, then multiple pairs of shoes are good enough for going to the moon". A large system can be decomposed into a set of loosely-coupled smaller systems (indeed, that's often a preferred architecture for a variety of reasons independent of whether the language is static or dynamic). A trip to the moon cannot be decomposed into a series of walks equivalent to a walk to the corner store. Therefore, no, your analogy is not valid. > That doesn't make any sense at all. How is having information written down instead of having to constantly remember and/or deduce it an impediment to reading? Visual (and mental, really) noise, mostly -- there is a reason why clear, effective, easy-to-read writing is often not writing that avoids all potential ambiguities and is sure to define as much as possible to avoid people having to deduce things. Making everything explicit is generally generally in tension with readability, not an aid to it.
• anonymoushn 12y ago
  I make an online card game. The rules are pretty simple, about as complex as Duel of Champions. There are no ongoing effects, no instants, no stack, no replacement effects, and so on. What the game does have is literal thousands of triggered abilities. When combat happens, the attacker's triggered abilities will happen, then the defender's triggered abilities, then the attacker will attack the defender. Lots of triggered abilities interact with the attacker or defender, and some may cause it to die (it dies immediately, not at the end of combat). Subsequent triggered abilities might crash if they depend on the attacker or defender existing. In my implementation, these triggered abilities are functions with signature triggered_ability(player: Player, my_idx: number, my_card: Card, skill_idx: number, other_idx: number, other_card: Card?) Having the type system enforce null checks on uses of other_card (and also on all uses of cards from other zones, like the opponent's battlefield or the player's hand) would have saved me a lot of trouble. As it is, I use a fuzzer to play lots of games between AI players and look for errors, but most of the errors I look for could have been caught by a compiler instead.
• ufo 12y ago
  The main advantage is that anything that you can turn into a a type error will be reported at compilation time, much earlier in the development cycle. This is not just a matter of safety but also helps in terms of refactoring and testing. This includes things like typos (wrong method names, etc) but where types really shine is refactoring. If you want to add or remove a parameter from a function or change a string field to an integer then you can use guidance from the type checker to be sure that you didn't forget to update anything. Its a bit like adding bumpers to the side of the bowling lane - it lets you be more reckless, updating things until the compiler shuts up without needing to carefully go through each line. --- Also, don't forget that gradual typing solutions such as Typed Lua are all about letting you program dynamically if you want. The idea is that you would only convert to the typed dialect in the parts of your program where that would suit you.