Re: Idea. Removing nils from the language.

[Eduardo Ochs <eduardoochs@...>]

Szbnwer, you're my hero!!!

This is the first post in this thread that I found myself not just
skimming through but reading and rereading it several times, finding
more layers of meaning in it every time!...

Thanks a lot =),
  Eduardo Ochs
  http://angg.twu.net/

On Sun, Jan 11, 2015 at 1:45 PM, szbnwer@gmail.com <szbnwer@gmail.com> wrote:
> hint 4 readin: imagination keep going foreward and dont skip stuff wich
> still izn undestood in the whole
>
> sorry 1st i didn read all the messages but my logic gave theze 4 this
> problem:
>
> - math containz 0 and it made the life better than previously it was, cause
> we can handle the empty and dead-end thingz not just the existent and
> continuous thingz, if u name sumtin uve grab it and later u can uze it, if
> we make a taboo from 0 its okhay 4 us humanz we will kno how to handle stuff
> without say any zero, but if u dont build it for a comp it wont kno, first u
> shud delete it from the life science from the end twice of a hundred and
> from a bit also
>
> - if you want to make a system more abstract u gonna go farer from the
> platform and go nearer to the ppl. for a programmer its okhay to kno how to
> handle a 0 and anyway we shud get something for it even if its not a 0 but
> its eyecandy, the computer gonna work with it in the background anyway and u
> can define it with any word but its 4 u, but for a computer any longer stuff
> for the shortest eaziest and most uzed stuff (all the endings, and it can be
> farer and more only but it will b there...) it wudnt b a good thing to
> implement it in a longer form. 4 the user give nice rounded colorful buttons
> and well declared informationz, when u cant go anywhere as far as the
> program has done its job
>
> - my main concept is if therez a default exit door from anywhere, then we
> wont stuck and we can terminate to the origin, like orderingz and the uzer,
> as i thinx its the main goal 4 programming to give the ppl what they wanted,
> or we still can say we kudnt got it sorry and not stay and wait for a
> miracle. the other end of the story is we didnt get the end of the road - we
> are building from the funds and from 0 to be sumthin and not organizing the
> whole which we can reach by default cuz we dont... <--herez a 0-end 4 u :D
>
> - this exit door is for terminate and give the stuff for the orderer, its
> the way to the 'outside the box' wich is the main goal for everything, the
> terminatin. as we dont like infinite cuz its a boring repetitive loop or an
> undone idle task or a random stuff wich is alwayz different but these
> endless stuffz makes ppl insane in long term and take their life, or they
> shud leave it behind without getting or knowing its end and mainly is not
> what they like. its only good for the reality wherez not needed the magical
> red button under our hand :) anyway life gonna push it a thouzend times
> hopefully to give place for our future and chill - slavery is flowering
> without exit inside any loop!
>
> - in programming every single endin of a tree graph (even if there are
> circles inside it - but their end can b a 1 for eg) are zeros as i mentioned
> earlier, wich is the point we shudn make more (longer) stuffz, why would we
> pollute the codes then with anything else? we also can go forward with a
> default if its needed to be handled automatized or stuff like, but why we
> shud build a construction for the ends if we have a default separated, wich
> gonna be called and wich we are more than abled to do in programming because
> therefore we have reusable parts namespaces functions circular and callable
> stuffz, and in Lua where we can make metatables and its so easy for us (poor
> other programmers ... sigh). thats why programming is for the machines to
> automatize raw math is for a piece of paper for make a single stuff and
> every leaf are for the tree for work together parallel - the reason for they
> are exists is the main angle
>
> - why wud i put anything there, where i dont kno what gonna b or where is
> actually/still nothing? if theres the possibility to continue a chain we
> have everything we may need and the comp has no junk. you can put the stuff
> behind a 0 to the uzerz screen, u can alias it for urself, and u can make ur
> stuff better if u compile ur stuff and the computer filter ur junk behind
> the procedures, but i think the perfect way would be if all of us make the
> valuable info 4 the human and the valuable procedures for the computers
> strictly separated and linked only (hint: linked root with the same tree and
> namespaces would b enough 4 make it) - the reazonz behind it are theze
> mainly: programs dont need our junk at execute, but we need it to go
> foreward with developing; it can make everything faster and reverzible; we
> can have then selected sets from it also like maximal minimal default uzer
> secified or optimized 4 speed space jobs taste anything; and it wont break
> to small unhandleable disconnected forgotten origined/purposed and even
> closed stuff as its organized like in apt github luarockz, but these are
> still not perfect because they alwayz (ok not alwayz...) cut themself off
> from the origins and start to b individual, but at the rootz wherez a lotsa
> zeroz and stuff we can compare everything easily cuz therez no too much
> different implementations for the stuff, like we kno a few methodz 4 the
> integral calculus and less for an addition - it wud b good to collect
> organize declare (4 ppl) optimize and make instant developeable compatible
> reversible and resolveable everything as we are abled to do it, we have
> everything already made just they are needed to b fully compatible, and the
> way is to automatically detect and handle diffs and dont cut the roots only
> put it away where its not needed and even dont try to compare stuff wid
> different pplz junk mixed wid the raw math, and anyway we have sourcecodes
> compilers JIT we are abled to do from these an implementation wich is
> runtime written for computerz strictly or fully surety 4 ppl or both
> parallel as the situation wishez it
>
> - anyway infinite much programmerz uzin 0 wid workin rezoult and readability
> comes from the structures, info can come with error msg/code parallel with a
> 0, or can be read from the background or resolved from the state, if one
> task can make one failure we can handle it with a single 0 and if it can
> exist then we shud check it out, we can make check-handle circles and a 0 is
> enough for it, if we can have various errors in one step or we comin back
> from a farer journey or a closed system ('black box') and we shud bring a
> proper error description we need to check and mark it with a 0 or anything
> else but we shud do before trigger anything depending on our anything we
> got/xcepted
>
> - its better to get an unambiguous 0 (4 sur im thinkin about nil null none
> and the stuff like, cuz if we need a number 0 wudnt b cool 4 us as the
> error/end hotline) than any other value wich can harm our code eazyer wid
> undetectable problems or give place for the uzr to do thingz like XSS, and
> if 0 can come we need a handler before we are moving or right after we moved
> at least a mark that its still not the expected stuff. and if u have an
> integer in a typed language like C u cant give it a 0 or a string or
> anything if u still dunno what gonna b there (anyway everything is solveable
> u can flag it when u start to use it and previously put a randint inside...)
>
> - a few paces where i can see thoze evil zeroz behind the scenes are stuff
> etc it this that . ... ' ' (<--its a space) univerzal formz unfinnished
> formz deleted ignored stuff and the like or even behind a smile they are
> dead ends full stops and terminatin...
>
> pm sry 4 meh gramma buddyz i luw it, fight 4 knowledge :) thx 4 watchin see
> u next week
>
> 2015-01-10 23:28 GMT+01:00 Javier Guerra Giraldez <javier@guerrag.com>:
>>
>> On Sat, Jan 10, 2015 at 3:36 PM, Dirk Laurie <dirk.laurie@gmail.com>
>> wrote:
>> > 2015-01-10 19:09 GMT+02:00 Enrique Arizón Benito
>> > <enrique.arizonbenito@gmail.com>:
>> >
>> >> Your example is really good to probe the "madness" of nil.
>> >
>> > Lua has lived with that madness for over 20 years.
>> > Though it be madness, yet there is method in it.
>>
>>
>> while i'm typicall a conservative in the common "change Lua" threads,
>> this one has a slightly different take, more like "imagine a language
>> with this uncommon trait... Lua seems a good platform to experiment".
>> In that light, the "we've always done things like this" argument isn't
>> so valid... maybe not even "i like it like it is".
>>
>> unfortunately, the premise "imagine a nil-less Lua" is flawed on several
>> points:
>>
>> - the "NULL is a bug" rant is a very specific rant on a very specific
>> set of languages.  maybe not even full languages, more like the common
>> practices on those languages
>>
>> - a big part of the "NULL problem" is that it's a value that can be
>> assigned to every pointer type, breaking type safety, or at least
>> making it harder to have strong types on static type systems.   but on
>> dynamic type systems, where the type is in the value and not in the
>> variable, there's no problem with nil (or None, or null), it's a
>> different type with a single value.  that's why some of the strongest
>> type systems are seen in dynamic type languages (or those with very
>> sophisticated type inference and automatic types).   in short: even if
>> NULL is a problem, it doesn't imply that nil is too.
>>
>> - neither type statics nor type strength is a value on itself.
>>
>> - the "removing nil would allow Lua to have static types!" argument
>> seems a non-sequitur, and a drawback if you happen to like dynamic
>> types.
>>
>> - the original post ended in something like "i've done the easy part,
>> and i don't have time to do the rest", which is ok if somebody else
>> sees any value in the proposal... if not, then that should be the end
>> of it until the author finds time to either advance the code or to
>> draft a more consistent language design.
>>
>>
>> --
>> Javier
>>
>