From 5e41b56309d74daf9daa3a19eee1684b2fefbf02 Mon Sep 17 00:00:00 2001 From: Paul Sokolovsky Date: Mon, 30 Jun 2014 10:38:44 -0700 Subject: [PATCH] It's enough if Lua developers call them stubborn themselves --- MicroPythonVsELua.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MicroPythonVsELua.md b/MicroPythonVsELua.md index 2ce0dbb..3fdd3cd 100644 --- a/MicroPythonVsELua.md +++ b/MicroPythonVsELua.md @@ -16,4 +16,4 @@ That's unheard of. In uPy, garbage collection exactly runs when memory allocator 1. Container type is single, associative array (called "table"). (Latest version of Lua work that around by providing dynamic array-vs-map switching underneath.) Multiple issues due to this, like array indexing starting from arbitrary number rather than zero, "length" of table not always corresponding to number of elements in it, etc. 1. Funky OO syntax, like obj:close(). 1. No exceptions, instead pseudo-functional workaround, pcall() and friends. (Also goto in Lua 5.2) -1. http://www.tecgraf.puc-rio.br/~lhf/ftp/doc/hopl.pdf p.23 "We have resisted user pressure to include other data structures, mainly “real” arrays and tuples, first by being stubborn, but also by providing tables with an efficient implementation and a flexible design." Of course, what stubborn Lua developers call efficient implementation is actually *inefficient* implementation: "In Lua 5.0 we introduced a hybrid representation for tables: every table contains a hash part and an array part, and both parts can be empty. Lua detects whether a table is being used as an array and automatically stores the values associated to integer indices in the array part, instead of adding them to the hash part" (p.12). So, Lua wastes memory to store "two parts", then wastes runtime cycles to "detect" which one to use. +1. http://www.tecgraf.puc-rio.br/~lhf/ftp/doc/hopl.pdf p.23 "We have resisted user pressure to include other data structures, mainly “real” arrays and tuples, first by being stubborn, but also by providing tables with an efficient implementation and a flexible design." Of course, what Lua developers call efficient implementation is actually *inefficient* implementation: "In Lua 5.0 we introduced a hybrid representation for tables: every table contains a hash part and an array part, and both parts can be empty. Lua detects whether a table is being used as an array and automatically stores the values associated to integer indices in the array part, instead of adding them to the hash part" (p.12). So, Lua wastes memory to store "two parts", then wastes runtime cycles to "detect" which one to use.