Typed Lua: An Optional Type System for Lua [pdf](lifl.fr)
lifl.fr
Typed Lua: An Optional Type System for Lua [pdf]
http://www.lifl.fr/dyla14/papers/dyla14-4-typed-lua-an-optional-type-system.pdf
5 comments
I think what happens with Lua (which does, incidentally, have many solid ecosystems built with it) is that it just gets quietly used in industrial-strength ways which don't require too much fanfare/promotion in order to propagate it as a tool - which is not the case with node, which aims to be a solution to industry-wide problems which Lua solves in other ways.
One thing that I think people get confused about Lua is that its simultaneously a VM, a language, and a very minimal framework, around which many, many things can be glommed. The glomming of those things is so flexible and versatile that - indeed perhaps we see too much diversity in the Lua appliance world, for there to be any common centralized traction around promoting it, as has happened with node.
If you want to see how Lua really has a solid ecosystem, then you have to look for projects that have embedded the VM and are using it as the basis for their application run loop. And indeed, there are plenty of projects out there doing this, that it can't really be said Lua doesn't have traction; it just doesn't attract as much hype. Lua has plenty of libraries; its just that the "FFI all the things!" approach means that you can, pretty much, indeed FFI all the things. No standards committee required!
One thing that I think people get confused about Lua is that its simultaneously a VM, a language, and a very minimal framework, around which many, many things can be glommed. The glomming of those things is so flexible and versatile that - indeed perhaps we see too much diversity in the Lua appliance world, for there to be any common centralized traction around promoting it, as has happened with node.
If you want to see how Lua really has a solid ecosystem, then you have to look for projects that have embedded the VM and are using it as the basis for their application run loop. And indeed, there are plenty of projects out there doing this, that it can't really be said Lua doesn't have traction; it just doesn't attract as much hype. Lua has plenty of libraries; its just that the "FFI all the things!" approach means that you can, pretty much, indeed FFI all the things. No standards committee required!
Same with P4 :)
You may want to take a look at openresty [1] moonscript [2], Lapis [3] and Kepler [4] . There has been some more direct efforts to port the "Node.js way" to Lua, one such is luvit [5] (significant overlap in the developers list) on the otherhand luv [6] exposes the underlying libraries slightly differently.
Lua really ought to be considered JS done right and Eich should really have been given enough time to bring scheme to the browser (syntax could have been negotiable). Another interesting project is Typed Racket http://docs.racket-lang.org/ts-guide/index.html?q=typed and Guile http://wingolog.org if this sort of things interests you.
[1] http://openresty.org/
[2] http://moonscript.org/
[3] http://leafo.net/lapis/
[4] http://www.keplerproject.org/
[5] http://luvit.io/
[6] https://github.com/richardhundt/luv
Lua really ought to be considered JS done right and Eich should really have been given enough time to bring scheme to the browser (syntax could have been negotiable). Another interesting project is Typed Racket http://docs.racket-lang.org/ts-guide/index.html?q=typed and Guile http://wingolog.org if this sort of things interests you.
[1] http://openresty.org/
[2] http://moonscript.org/
[3] http://leafo.net/lapis/
[4] http://www.keplerproject.org/
[5] http://luvit.io/
[6] https://github.com/richardhundt/luv
Another related effort is http://turbolua.org/
There is, kind of, with the highly underrated OpenResty [1] and Lapis [2]. The benchmarks [3] for the pair is also way ahead of node, all w/o callbacks.
1. http://openresty.org/
2. http://leafo.net/lapis/
3. http://www.techempower.com/benchmarks/#section=data-r7&hw=i7...
1. http://openresty.org/
2. http://leafo.net/lapis/
3. http://www.techempower.com/benchmarks/#section=data-r7&hw=i7...
Lua is a great language and this is cool research. But cool as it is, saying that Lua "now has optional typing" because a research extension to the language has implemented it isn't really realistic. By that token, you could say that Java has every imaginable language feature because in the 00's, adding features to Java was how most PL research was done. You can have Lua lots of ways: if you use standard Lua, then it comes with a large number of nice C libraries; if you use LuaJIT then it's very fast; if you use this research version, then it has optional types. But you can't have all of these ways at the same time.
For the most part, you can. You can definitely use Typed Lua + nice C libraries or LuaJIT + nice C libraries.
Typed Lua says it only works with Lua >= 5.2. LuaJIT runs a language that is somewhere between Lua 5.1 and Lua 5.2, so it's not clear whether it will work with Typed Lua. The 5.2 requirement may just be to run tlc (and not the code it outputs), in which case you could run LuaJIT + Typed Lua + nice C libraries.
Typed Lua says it only works with Lua >= 5.2. LuaJIT runs a language that is somewhere between Lua 5.1 and Lua 5.2, so it's not clear whether it will work with Typed Lua. The 5.2 requirement may just be to run tlc (and not the code it outputs), in which case you could run LuaJIT + Typed Lua + nice C libraries.
Lua is very popular in some niches, like games and embedded stuff.
Language adoption is a very social thing though. Maybe if Rails was a Lua framework we would be wondering why Ruby never made it big.
Language adoption is a very social thing though. Maybe if Rails was a Lua framework we would be wondering why Ruby never made it big.
Agreed.
Lua is embedded in things like Redis, and is often uses as an extension/configuration language for small projects.
I based my mail client(http://lumail.org/) around Lua as a configuration language because I kept getting annoyed by the almost-configuration-language used in mutt.
Actually writing applications in Lua is also possible, for example the chat/Jabber server Prosody.
Lua is embedded in things like Redis, and is often uses as an extension/configuration language for small projects.
I based my mail client(http://lumail.org/) around Lua as a configuration language because I kept getting annoyed by the almost-configuration-language used in mutt.
Actually writing applications in Lua is also possible, for example the chat/Jabber server Prosody.
The thing I love about Lua is that I can integrate it into my existing ecosystem.
Note though it does lack some syntactical sugar, and arguments not passed are silently 'nil', so it is not strictly superior.
Note though it does lack some syntactical sugar, and arguments not passed are silently 'nil', so it is not strictly superior.
[deleted](1)
Is it just me, or does anyone else feel that gradual/optional typing isn't good enough? I've been trying out Typescript in a couple of nontrivial projects, and sure, it does catch some errors, but as long as you're forced to integrate with an unityped world it doesn't really catch enough problems to be worthwhile, IME. You can of course write type declarations for all your "foreign" libraries, but that's just an added burden that you (the programmer, not the language) have to get right. Plus, since the unityped language is so flexible (and thus conventions are different vs. a multityped language), there are things in the unityped language that cannot be sensibly typed without just resorting to saying "any" (which is the only type of the unityped language).
The biggest benefit of Typescript in my opinion is the potential for stronger tooling. There's definitely room for improvement (I suspect type unions would fix a majority of the times you are forced to use "any"), but I have found type declarations to be relatively low overhead for a substantial gain.
Re: foreign libraries, as long as you are using TSD / DefinitelyTyped (http://definitelytyped.org/tsd/), that burden is crowdsourced. I've written a few library type declarations, but used many more from others. The flipside of the complaint is that I've found it really quite nice to have type checking for libraries I don't know inside and out. And you can always cheat and declare your external libraries as "any" for the sake of making the compiler happy, if you don't want to go through the effort to get the reward.
Obviously, to get something like DefinitelyTyped going, you need a critical mass of developers, so that may or may not work out for Typed Lua.
Re: foreign libraries, as long as you are using TSD / DefinitelyTyped (http://definitelytyped.org/tsd/), that burden is crowdsourced. I've written a few library type declarations, but used many more from others. The flipside of the complaint is that I've found it really quite nice to have type checking for libraries I don't know inside and out. And you can always cheat and declare your external libraries as "any" for the sake of making the compiler happy, if you don't want to go through the effort to get the reward.
Obviously, to get something like DefinitelyTyped going, you need a critical mass of developers, so that may or may not work out for Typed Lua.
My experience is that DefinitelyTyped definitions are actually not very accurate in practice. This may be a consequence of language restrictions or just typical (and understandable) programmer laziness ("good enough!") -- or, as you say, the lack of type unions. It's better than nothing, but not really good enough. But then I have been spoiled by Ocaml and Haskell, so...
(There's also the whole external/internal module confusion in TS, but that's not related to the general theme of gradual typing per se, so it's not really relevant to non-TS contexts.)
(There's also the whole external/internal module confusion in TS, but that's not related to the general theme of gradual typing per se, so it's not really relevant to non-TS contexts.)
If you've only used TypeScript, then you haven't really seen what gradual typing can do. In Typed Racket, you get actual guarantees about your types, and a type system that works for almost all existing untyped code. Of course, it might be more work to make it type check, since you have to get it right. ;)
This is also true of other systems like GradualTalk, and other systems like Typed Clojure have much more expressive type systems than TypeScript, even if they don't guarantee soundness in the presence of untyped code.
The designers of TypeScript went for simplicity first. This has real advantages, but also disadvantages, which you seem to be running into.
This is also true of other systems like GradualTalk, and other systems like Typed Clojure have much more expressive type systems than TypeScript, even if they don't guarantee soundness in the presence of untyped code.
The designers of TypeScript went for simplicity first. This has real advantages, but also disadvantages, which you seem to be running into.
(Typed) Racket has been on my radar, though there have been some worries, e.g. the performance issues when crossing the typed/unityped boundary. Hopefully those can be fixed.
I know it's my own failing, but I've also had a lot of trouble with the incredible amount of parens and symbols in TR/TC -- I'm used to the near-math notation of Haskell dammit! :). It's just one of those things -- I have actually written non-trivial code in Scheme, but I've been spoiled by Haskell. Intellectually, I deeply appreciate the value of homoiconicity, but sadly I just can't get past the aesthetics.
EDIT: FWIW, if I were to go with gradual typing, I think TR would probably be close to ideal. It's an amazingly well thought-through language in terms of module system, integration of the macro system with modules, the syntax-parse macro system, etc. Kudos!
I know it's my own failing, but I've also had a lot of trouble with the incredible amount of parens and symbols in TR/TC -- I'm used to the near-math notation of Haskell dammit! :). It's just one of those things -- I have actually written non-trivial code in Scheme, but I've been spoiled by Haskell. Intellectually, I deeply appreciate the value of homoiconicity, but sadly I just can't get past the aesthetics.
EDIT: FWIW, if I were to go with gradual typing, I think TR would probably be close to ideal. It's an amazingly well thought-through language in terms of module system, integration of the macro system with modules, the syntax-parse macro system, etc. Kudos!
I think that the biggest thing missing from Typescript is contract checking. The idea is that you use the type information to add assertions in the program and that should let you get more accurate stack traces even for the dynamic errors. An example would be getting an error in the line where you set a variable to null instead of getting an error latter on in the line where you try to call a method on that null variable.
Link to the missing github page (maybe the paper is written before his github page was ready)?
https://github.com/andremm/typedlua
https://github.com/andremm/typedlua
The github page has always been there, even before he started writing the paper. Its still very experimental though and I don't think its ready for general use yet.
Luajit is awesome too, but if you are looking for tighter debugger integration in MSVC then look at HavokVM - which is lua vm - you can mix native/lua callstack and it works just fine.
http://www.havok.com/products/script
http://www.havok.com/products/script
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 Lua (okay, almost exclusively games). What would be the use cases for this? In my tiny brain, it makes as much sense as dynamic C.
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
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?)
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.
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.
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.
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.
> 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.)
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.)
>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?
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?
> 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.
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.
Dynamically typed languages are good for very small programs. Typed Lua is going to be a big innovation.
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.
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.
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.
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.
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! :)
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! :)
> What makes a language 'okay for smaller projects' but suddenly unsuitable when it gets larger
As projects get larger the benefits of tooling (automated testing, automated type checking, efficient compilation, etc) become more relevant and the costs of using the tools become less relevant compared to the costs of writing the program itself.
> 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
Actually, I don't think any dynamic languages used in practice actually do this right now. Most dynamic languages only check base types (numbers, null, "object") but fail to check for higher order types (functions and objects). For example if you code
As projects get larger the benefits of tooling (automated testing, automated type checking, efficient compilation, etc) become more relevant and the costs of using the tools become less relevant compared to the costs of writing the program itself.
> 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
Actually, I don't think any dynamic languages used in practice actually do this right now. Most dynamic languages only check base types (numbers, null, "object") but fail to check for higher order types (functions and objects). For example if you code
MyClass x = new OtherClass();
x.foo();
> 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! :)
I think you're missing the point; static typing doesn't let you write more programs, it specifically lets you write fewer programs, by ruling out ill-typed programs. If I see a Haskell variable of type "Int -> String" then I can be quite confident that it's a function turning Ints into Strings; in, say, Python I can't be confident of much without analysing the entire codebase.
I think you're missing the point; static typing doesn't let you write more programs, it specifically lets you write fewer programs, by ruling out ill-typed programs. If I see a Haskell variable of type "Int -> String" then I can be quite confident that it's a function turning Ints into Strings; in, say, Python I can't be confident of much without analysing the entire codebase.
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
What makes it okay? This Python program will not throw an exception when ran
def f(x):
return x
if False:
f(1,2)
> 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:
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.
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
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.
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.
Lua 5.3 (work 2 already available) introduces integer subtypes so now you can have both floating point and integers.
Is there empirical evidence of your first claim? Or any claim, honestly.
Not a rhetorical question: How many flight-control codebases are written in a dynamically typed language ? Or for that matter, life support systems deployed in ICU's, really curious.
About the dynamic vs Static typing debate, I think it progresses firmly along Upton Sinclair'ish lines,
"It is difficult to get a man to understand something, when his salary depends upon his not understanding it!"
About the dynamic vs Static typing debate, I think it progresses firmly along Upton Sinclair'ish lines,
"It is difficult to get a man to understand something, when his salary depends upon his not understanding it!"
I don't know the answer, sadly. My sardonic response is to ask how many are in what would be called a modern statically typed system?
That is, I expect the tooling around them is ridiculously high. Probably done with a model based development system. Probably not, however, what is typically seen as static typing in the modern landscape. (i.e. Haskell)
Honestly, I wouldn't be surprised to find some lisp in there, just because. :)
I'm open to being proven wrong.
That is, I expect the tooling around them is ridiculously high. Probably done with a model based development system. Probably not, however, what is typically seen as static typing in the modern landscape. (i.e. Haskell)
Honestly, I wouldn't be surprised to find some lisp in there, just because. :)
I'm open to being proven wrong.
> what would be called a modern statically typed system?
Now we are splitting hairs and looking for the one true scotsman. You asked for quantitative evidence, but the problem is that you have already made up your mind (perhaps only subconciously) and you will find a way to lookaway from the evidence or logic (which you term just an appeal). Lookup birthers for instance.
I for one have'nt heard of any flight control or life support software written in a dynamically typed language, whereas have heard of plenty written in what would qualify more as a statically typed than dynamically typed language. ADA in particular comes to mind. I dont discount that there might exist some written in a dynamic languages. Lets agree that they are quite hard to find. I wont be surprised with prototypes written in dynamic languages though.
> I wouldn't be surprised to find some lisp in there, [...] I'm open to being proven wrong.
Now that would be the Russel's teapot fallacy. I am not ruling it out, but for such assertions, the burden, I think, lies on the one making the assertion. You handed out an epistemic sucker punch there. The proof that you desire requires presenting the entire set of Lisp programs, or the entire set of flight control programs, both are quite ridiculous. BTW I do love lisp a whole freaking lot.
Curious about this: Say you have to be (god forbid) irradiated. There are two pieces of software written by two groups, one that uses statically typed, another that uses dynamically typed and this is all the information you have. Which one would you pick ? There is no right or wrong answer.
I will pick the one written by the group that uses statically typed language because of their cultural obsession with correctness. That is just a Bayesian prior, there are exceptions of course. Sqlite is indeed afflicted by the same obsession.
EDIT: @taeric
> If they are in a static language, then this should be an easy debate for you. Merely give me some evidence and we are done.
Ah! then lookup ADA's resume
> I'd pick the one that has the better track record and has been proven with more tests.
You are dodging the (silly) question sir :) I said thats the only thing you know. Anyways wasnt an important question and here's wishing that you never need to get irradiated with any such thing, seriously.
Now we are splitting hairs and looking for the one true scotsman. You asked for quantitative evidence, but the problem is that you have already made up your mind (perhaps only subconciously) and you will find a way to lookaway from the evidence or logic (which you term just an appeal). Lookup birthers for instance.
I for one have'nt heard of any flight control or life support software written in a dynamically typed language, whereas have heard of plenty written in what would qualify more as a statically typed than dynamically typed language. ADA in particular comes to mind. I dont discount that there might exist some written in a dynamic languages. Lets agree that they are quite hard to find. I wont be surprised with prototypes written in dynamic languages though.
> I wouldn't be surprised to find some lisp in there, [...] I'm open to being proven wrong.
Now that would be the Russel's teapot fallacy. I am not ruling it out, but for such assertions, the burden, I think, lies on the one making the assertion. You handed out an epistemic sucker punch there. The proof that you desire requires presenting the entire set of Lisp programs, or the entire set of flight control programs, both are quite ridiculous. BTW I do love lisp a whole freaking lot.
Curious about this: Say you have to be (god forbid) irradiated. There are two pieces of software written by two groups, one that uses statically typed, another that uses dynamically typed and this is all the information you have. Which one would you pick ? There is no right or wrong answer.
I will pick the one written by the group that uses statically typed language because of their cultural obsession with correctness. That is just a Bayesian prior, there are exceptions of course. Sqlite is indeed afflicted by the same obsession.
EDIT: @taeric
> If they are in a static language, then this should be an easy debate for you. Merely give me some evidence and we are done.
Ah! then lookup ADA's resume
> I'd pick the one that has the better track record and has been proven with more tests.
You are dodging the (silly) question sir :) I said thats the only thing you know. Anyways wasnt an important question and here's wishing that you never need to get irradiated with any such thing, seriously.
:( Why are we replying without going down the chain? I almost didn't even see you put more of a response to me.
Regardless, I'm familiar with Ada. I'm also familiar with some fun disasters using software by Ada.[1] Now, do I blame that it was in Ada? No. However, the attitude you are displaying of "if all you know is it was in Ada, then it is safer than the alternatives" seems to be the exact problem that led to that disaster.
If the only thing I know of two irradiation devices is one was statically typed and the other wasn't, I'd likely pass on both. Or I'd like to know how much radiation each is capable of outputting. Consider, x-ray machines far predate what we realize as programmable computers. And much more goes into the safety of the devices than just the language used.
[1] http://www.adapower.com/index.php?Command=Class&ClassID=FAQ&...
Regardless, I'm familiar with Ada. I'm also familiar with some fun disasters using software by Ada.[1] Now, do I blame that it was in Ada? No. However, the attitude you are displaying of "if all you know is it was in Ada, then it is safer than the alternatives" seems to be the exact problem that led to that disaster.
If the only thing I know of two irradiation devices is one was statically typed and the other wasn't, I'd likely pass on both. Or I'd like to know how much radiation each is capable of outputting. Consider, x-ray machines far predate what we realize as programmable computers. And much more goes into the safety of the devices than just the language used.
[1] http://www.adapower.com/index.php?Command=Class&ClassID=FAQ&...
> :( Why are we replying without going down the chain?
I dislike deeply nested, indentation cramped and tangential threads, so sometimes if I dont have anything that important to say I inline it. More so when everyone has left the building.
> I'm also familiar with some fun disasters using software by Ada.
I dont think we were ever discussing whether using Ada or some other statically type checked language immunizes a project against all other peripheral errors. That would be a supremely ridiculous and stupid claim to make.
Typechecking proves either that the code is type error free or that the typechecker has a bug. In the case of the latter, you try and fix it and the benefit percolates to every software verified by it. Testing proves that it passes only those specific test cases and only if the programmer tested it at all.
BTW the very first line says the fault had nothing to do with Ada. The source of the error was beyond the scope of typechecking.
To backtrack, our discussion was on whether there are notable examples of software written in dynamically typed languages where the cost of error is high.
Runtime error while spaceshuttle descends backs to earth, no thank you, on a fly-by-wire unit, when the pilot is breaking out of a loop, again no thank you. There are times when, no pun intended, you just cannot bail out and wash your hands off the situation, without terrible consequences. In such cases I would rather have the error surfaced in an environment where I can control the consequences, meaning early, and as exhaustively as possible.
Most importantly typechecking does not preclude/replace testing, it complements it.
Everything cannot be statically verified or insured against, but that does not mean that just because we cannot verify everything statically, we should verify nothing statically.
BTW Typical x-ray machines do not have the power to kill you in a single exposure, radiotherapy units absolutely can, example Therac.
I dislike deeply nested, indentation cramped and tangential threads, so sometimes if I dont have anything that important to say I inline it. More so when everyone has left the building.
> I'm also familiar with some fun disasters using software by Ada.
I dont think we were ever discussing whether using Ada or some other statically type checked language immunizes a project against all other peripheral errors. That would be a supremely ridiculous and stupid claim to make.
Typechecking proves either that the code is type error free or that the typechecker has a bug. In the case of the latter, you try and fix it and the benefit percolates to every software verified by it. Testing proves that it passes only those specific test cases and only if the programmer tested it at all.
BTW the very first line says the fault had nothing to do with Ada. The source of the error was beyond the scope of typechecking.
To backtrack, our discussion was on whether there are notable examples of software written in dynamically typed languages where the cost of error is high.
Runtime error while spaceshuttle descends backs to earth, no thank you, on a fly-by-wire unit, when the pilot is breaking out of a loop, again no thank you. There are times when, no pun intended, you just cannot bail out and wash your hands off the situation, without terrible consequences. In such cases I would rather have the error surfaced in an environment where I can control the consequences, meaning early, and as exhaustively as possible.
Most importantly typechecking does not preclude/replace testing, it complements it.
Everything cannot be statically verified or insured against, but that does not mean that just because we cannot verify everything statically, we should verify nothing statically.
BTW Typical x-ray machines do not have the power to kill you in a single exposure, radiotherapy units absolutely can, example Therac.
The accidents occurred when the high-power electron beam
was activated instead of the intended low power beam, and
without the beam spreader plate rotated into place.
Previous models had hardware interlocks in place to
prevent this, but Therac-25 had removed them, depending
instead on software interlocks for safety. The software
interlock could fail due to a race condition.
Well, apologies for the nesting. :( I agree it is ugly, but is easier to spot changes. (Also.... I went to sleep. Sorry. Which, also, I was tired. My tone has been terrible in some of these messages. Apologies for that, as well. To all involved.)
I am aware, and agree with the opinion, that Ada had nothing to do with the error. However, I don't think many would disagree that the fact the code was in Ada gave the team that decided to reuse it more faith that it was "safely" reusable than had it been written in another language.
This is still not the fault of Ada, but it was the exact reasoning you are using to say I should prefer the statically typed solution over another, if that is all I know. My point is if that is all you know, you don't know enough to make a decision.
So, in my mind, our discussion was not over whether there are notable examples of software written in dynamically typed languages where the cost of error is high. The discussion is whether there have been studies showing that statically typed languages produce less bug prone software.
So, to your own example, what was Therac written in? Because, honestly, right off I don't know. I would not be surprised to know it was in a statically typed language. And note, I would not use that as an example of where typed safe languages are failures.
And then to wrap up back to your question. It doesn't take a lot of googling to find that Nasa used to use a Symbolics Lisp machine in their work. http://stackoverflow.com/a/563378/392812
I am aware, and agree with the opinion, that Ada had nothing to do with the error. However, I don't think many would disagree that the fact the code was in Ada gave the team that decided to reuse it more faith that it was "safely" reusable than had it been written in another language.
This is still not the fault of Ada, but it was the exact reasoning you are using to say I should prefer the statically typed solution over another, if that is all I know. My point is if that is all you know, you don't know enough to make a decision.
So, in my mind, our discussion was not over whether there are notable examples of software written in dynamically typed languages where the cost of error is high. The discussion is whether there have been studies showing that statically typed languages produce less bug prone software.
So, to your own example, what was Therac written in? Because, honestly, right off I don't know. I would not be surprised to know it was in a statically typed language. And note, I would not use that as an example of where typed safe languages are failures.
And then to wrap up back to your question. It doesn't take a lot of googling to find that Nasa used to use a Symbolics Lisp machine in their work. http://stackoverflow.com/a/563378/392812
> that the fact the code was in Ada gave the team that decided to reuse it more faith that it was "safely" reusable than had it been written in another language.
And you are making ridiculous analogies from the Ariane example. Ada had no bearing on the failure. They plugged in a controller for a different vehicle entirely.
The question is about relative confidence between a statically typed and a runtime typed software. The fact remains that given a fixed/finite budget of testing, wise people will not even think of deploying a runtime typed system for such tasks. These tasks cannot afford runtime errors, so it is imperative that due diligence be made to prove that they cannot happen.
(You cannot send several manned missions to the moon just to test) I am not aware of runtime typed systems that afford such proofs before running it and if some do, it is a statically proven system to begin with.
Revisit my points about runtime errors on a flight controller. Or to be less fancy, runtime error in trading software, "oops sent the wrong million dollar transaction request and bailed out because of runtime error". Has happened, and run companies to the ground.
> what was Therac written in? Given its age, I would assume it was some fairly low level language. Whatever it was, it was something that did not prove that such races cannot happen, in other words it was open to runtime error, which is exactly what we want to eliminate as far as possible. We will run it a few times and see what gives, is not a tenable strategy for many important tasks.
> It doesn't take a lot of googling to find that Nasa used to use a Symbolics Lisp machine
You are being slightly disingenuous here, I was talking about deployed flight controllers that actually control the thing when its on flight.
As I have said its like arguing with birthers, you have made up your mind and no matter what I say you will try to avoid the logic of eliminating costly runtime errors.
And you are making ridiculous analogies from the Ariane example. Ada had no bearing on the failure. They plugged in a controller for a different vehicle entirely.
The question is about relative confidence between a statically typed and a runtime typed software. The fact remains that given a fixed/finite budget of testing, wise people will not even think of deploying a runtime typed system for such tasks. These tasks cannot afford runtime errors, so it is imperative that due diligence be made to prove that they cannot happen.
(You cannot send several manned missions to the moon just to test) I am not aware of runtime typed systems that afford such proofs before running it and if some do, it is a statically proven system to begin with.
Revisit my points about runtime errors on a flight controller. Or to be less fancy, runtime error in trading software, "oops sent the wrong million dollar transaction request and bailed out because of runtime error". Has happened, and run companies to the ground.
> what was Therac written in? Given its age, I would assume it was some fairly low level language. Whatever it was, it was something that did not prove that such races cannot happen, in other words it was open to runtime error, which is exactly what we want to eliminate as far as possible. We will run it a few times and see what gives, is not a tenable strategy for many important tasks.
> It doesn't take a lot of googling to find that Nasa used to use a Symbolics Lisp machine
You are being slightly disingenuous here, I was talking about deployed flight controllers that actually control the thing when its on flight.
As I have said its like arguing with birthers, you have made up your mind and no matter what I say you will try to avoid the logic of eliminating costly runtime errors.
What the shit? Your question: "You are given two systems, one implemented in language class X, one implemented in language class Y, pick the one you trust." Me: "Not enough information to make a valid answer."
To be clear, I think mistakes have been made with all paradigms of programming. In many cases, the mistakes were made completely outside the realm of the program. Like the Ariane example. I only mentioned it as a "failure" of static typing because of your bloody question.
Seriously, it is your hypothetical: "Here is a rocket where the control system was implemented in Ada. Do you trust it more than a competing one that was implemented in machine language?" That is essentially the question you gave me. I turned it around precisely to show that just knowing the type of language that something was implemented in is bloody worthless.
I have made up my mind. To remain skeptical of claims that are not backed by empirical evidence. I'm optimistic enough to think that static typing is actually a good thing. The arguments used to put it lack any backing with verification. (Which, I find ironic, since they are supposed to be about verification.)
To be clear, I think mistakes have been made with all paradigms of programming. In many cases, the mistakes were made completely outside the realm of the program. Like the Ariane example. I only mentioned it as a "failure" of static typing because of your bloody question.
Seriously, it is your hypothetical: "Here is a rocket where the control system was implemented in Ada. Do you trust it more than a competing one that was implemented in machine language?" That is essentially the question you gave me. I turned it around precisely to show that just knowing the type of language that something was implemented in is bloody worthless.
I have made up my mind. To remain skeptical of claims that are not backed by empirical evidence. I'm optimistic enough to think that static typing is actually a good thing. The arguments used to put it lack any backing with verification. (Which, I find ironic, since they are supposed to be about verification.)
Ah I see what happened. We somehow managed to talk past each other and go out of sync and ended up responding to something that was not on the others mind.
If you thought I am not in agreement with this comment of yours, then let me assure you that I am (with certain differences).
My point remains that your Ariane example is irrelevant, it shows that statically typed systems can still fail if there are failure modes outside of the purview of the typechecker. That is obvious and was never in contest. What was in contest, however, was the relative safeties of statically typed vs dynamically typed. Your example has no bearing in clearing that question. I am claiming superiority of the static paradigm because no one has been forthcoming in putting their money and lives in control of a dynamically typed controller. You are just refusing to concede this because it affects your view in some way, and I dont expect to see any change in that behavior.
Let me put forward my main claim (and ignore the silly hypothetical ones): dynamically typed/checked languages are unsuitable and dangerous for cases where runtime errors are egregiously costly because they cannot prove that such eventualities cannot happen before they actually happen. Because of these risks involved such systems are sensibly not implemented in dynamically typed/checked languages. Statically typed languages cannot immunizes against all possible failures, yet they are better than dynamically typed languages in this scenario because they can eliminate a large class of these runtime errors that dynamically typed languages just cannot (if they can they are statically typed by definition), whereas testing applies equally to both.
BTW a dynamically typed language with exhaustive static analysis is a statically typechecked language.
If you thought I am not in agreement with this comment of yours, then let me assure you that I am (with certain differences).
My point remains that your Ariane example is irrelevant, it shows that statically typed systems can still fail if there are failure modes outside of the purview of the typechecker. That is obvious and was never in contest. What was in contest, however, was the relative safeties of statically typed vs dynamically typed. Your example has no bearing in clearing that question. I am claiming superiority of the static paradigm because no one has been forthcoming in putting their money and lives in control of a dynamically typed controller. You are just refusing to concede this because it affects your view in some way, and I dont expect to see any change in that behavior.
Let me put forward my main claim (and ignore the silly hypothetical ones): dynamically typed/checked languages are unsuitable and dangerous for cases where runtime errors are egregiously costly because they cannot prove that such eventualities cannot happen before they actually happen. Because of these risks involved such systems are sensibly not implemented in dynamically typed/checked languages. Statically typed languages cannot immunizes against all possible failures, yet they are better than dynamically typed languages in this scenario because they can eliminate a large class of these runtime errors that dynamically typed languages just cannot (if they can they are statically typed by definition), whereas testing applies equally to both.
BTW a dynamically typed language with exhaustive static analysis is a statically typechecked language.
I'm not trying to play the scotsman's game. Though, I can confess that that is the direction I am somewhat steering this. Not my main goal. My aim is more against the claims of the parent post. Note that there is a big difference between static tooling and statically typed languages. I have high regard for the both. And I've seen more evidence of the former in older, less statically typed, languages than I have the latter.
So, part of my point is I haven't ever "heard" what language those systems are written in, period. It isn't that I have heard they are in dynamic or static languages. I flat out never hear. If they are in a static language, then this should be an easy debate for you. Merely give me some evidence and we are done.
I do know that the older languaged programs I have seen are typically not in what one would call a statically typed language. There is plenty of static tooling on them, but to pretend that there is statically "typed" tooling around any software that ran something such as the space program feels like it is reaching. Heavily.
So, to your silly question. I'd pick the one that has the better track record and has been proven with more tests. I don't care if they are dynamic tests, statically typed assertions, statically analyzed assertions on a dynamically typed codebase, whatever. There are too many tools to care. Because I can hazard a guess that all of the things that have irradiated me in my years have not been by the strongest statically typed languages out there. :)
So, part of my point is I haven't ever "heard" what language those systems are written in, period. It isn't that I have heard they are in dynamic or static languages. I flat out never hear. If they are in a static language, then this should be an easy debate for you. Merely give me some evidence and we are done.
I do know that the older languaged programs I have seen are typically not in what one would call a statically typed language. There is plenty of static tooling on them, but to pretend that there is statically "typed" tooling around any software that ran something such as the space program feels like it is reaching. Heavily.
So, to your silly question. I'd pick the one that has the better track record and has been proven with more tests. I don't care if they are dynamic tests, statically typed assertions, statically analyzed assertions on a dynamically typed codebase, whatever. There are too many tools to care. Because I can hazard a guess that all of the things that have irradiated me in my years have not been by the strongest statically typed languages out there. :)
What sort of evidence are you looking for? E.g.
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 :-).
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 :-).
Empirical evidence. Studies indicating that software developed in statically-typed languages has fewer defects. Research into the speed of development and the ability to accommodate major changes in requirements and functionality would be useful as well.
Last I looked, there isn't a great deal of literature on this, and what there is is fairly old (dealing with '80s-'90s languages) and inconclusive.
Last I looked, there isn't a great deal of literature on this, and what there is is fairly old (dealing with '80s-'90s languages) and inconclusive.
Is the presentation not good enough?
> Research into the speed of development and the ability to accommodate major changes in requirements and functionality would be useful as well.
You kind of slipped those in, we were talking about correctness.
> Research into the speed of development and the ability to accommodate major changes in requirements and functionality would be useful as well.
You kind of slipped those in, we were talking about correctness.
No we weren't. We were talking about "being less bug prone" and "easier to read."
Though, I'm not entirely sure that really changes much. :(
Look, I'm not against static typing. I confess to being somewhat in love with lisp at the moment. And, I'm trying to learn MIXAL for some unholy reason. At the same time, I try to type my systems as well as I can. I am far from convinced that typing will be the way to go.
Especially if you consider auxiliary tools. Having used Coverity some, it is down right impressive the stability you can bring to a C codebase with proper discipline and the appropriate tooling. Compared to using something such as a Scala codebase, where right now your only recourse is the compiler.
That is, static analysis does not begin and end with the compiler. Sadly, in moving to "newer" statically typed languages, you through out many of the tools that currently exist in the older languages.
And this is not just for "correctness". Having finally added "-march=native" to my flags for a build of software, I'm literally amazed at how well optimized a compile can be versus just using "-O3". Optimizations in the modern world are quite amazing without necessarily needing "better types."
Though, I'm not entirely sure that really changes much. :(
Look, I'm not against static typing. I confess to being somewhat in love with lisp at the moment. And, I'm trying to learn MIXAL for some unholy reason. At the same time, I try to type my systems as well as I can. I am far from convinced that typing will be the way to go.
Especially if you consider auxiliary tools. Having used Coverity some, it is down right impressive the stability you can bring to a C codebase with proper discipline and the appropriate tooling. Compared to using something such as a Scala codebase, where right now your only recourse is the compiler.
That is, static analysis does not begin and end with the compiler. Sadly, in moving to "newer" statically typed languages, you through out many of the tools that currently exist in the older languages.
And this is not just for "correctness". Having finally added "-march=native" to my flags for a build of software, I'm literally amazed at how well optimized a compile can be versus just using "-O3". Optimizations in the modern world are quite amazing without necessarily needing "better types."
Remind me, what's the typing discipline of the languages supported by Coverity?
Isn't that a touch of a diversion? With the large target area of code covered by C, it makes the most sense that that is the heaviest targetted area. This list[1] shows that there are plenty of options to go around. Even Perl gets some love. :)
[1] http://en.wikipedia.org/wiki/List_of_tools_for_static_code_a...
[1] http://en.wikipedia.org/wiki/List_of_tools_for_static_code_a...
You do realize that all those tools for dynamic languages are code formatters right? That they won't catch any real bugs. You do realize that right? Why do you think that they can't catch any real bugs? Hint: it has to do with static typing or lack thereof.
That is like claiming a tool like lint can't be used to catch bugs. And... not all of them are. Did you read all of the tools in the "mixed languages" section? Quite a few of the really good tools can find mistakes in dynamic languages.
Shit, this is no different than the article making the rounds talking about the many "gotchas" in bash scripting. Just making a tool that spots those is likely to catch and help correct errors.
Shit, this is no different than the article making the rounds talking about the many "gotchas" in bash scripting. Just making a tool that spots those is likely to catch and help correct errors.
The presentation was interesting, but if there were any studies cited I didn't see them. I'm looking for deductive research into the proposal that using a modern statically-typed language results in a better outcome than a modern dynamically-typed one.
The related research I mentioned is useful because if development in a given language improves correctness but also increases development time by an order of magnitude it might still be more effective to develop software in the "worse" language and spend the additional available time mitigating the risk or building additional features.
The related research I mentioned is useful because if development in a given language improves correctness but also increases development time by an order of magnitude it might still be more effective to develop software in the "worse" language and spend the additional available time mitigating the risk or building additional features.
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.
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.
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.
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.
Where's the appeal in my argument? It was an example.
It is an appeal to how logical the example seems. That is, it sounds like it would be applicable "at large." However, evidence seems to show that, "at large," it is mostly a non sequitor.
That is, you get better systems the more programmers you have that do have a good grasp on the whole system. Ironically, you have better arguments against knowing specifics of the system -- that is, at the individual function level -- than you do the high level picture. Consider, Linus knows the linux kernel better than I can really comprehend. I doubt he knows every function's return value.
That is, you get better systems the more programmers you have that do have a good grasp on the whole system. Ironically, you have better arguments against knowing specifics of the system -- that is, at the individual function level -- than you do the high level picture. Consider, Linus knows the linux kernel better than I can really comprehend. I doubt he knows every function's return value.
Why have we not seen an effort to build a solid ecosystem around it the way node has with JS? Lua with equivalent libraries to Python/Ruby/Javascript/PHP would be superior to any of them.