[Vm-dev] HackerNews + vm-dev = a lightbulb saying "STACK!"

[Igor Stasenko]

On 11 October 2012 19:26, Bert Freudenberg <bert at freudenbergs.de> wrote:
>
> On 11.10.2012, at 03:54, Igor Stasenko <siguctua at gmail.com> wrote:
>
>> If/when you hit that limit, you can always refactor the code to use dictionary to hold/cache parsers instead of inst vars.
>
> It's a pain in the neck having to deal with this. Also, you lose an order of magnitude in efficiency, unless you support both styles and only flow over into dictionaries when needed. Makes the code way more complicated. Also, debugging is not as nice as with real variables. Etc.
>

I disagree. You have problems in a first place because of bloat. When
you have over 255 variables to track, it makes little difference for
humans how are they stored.
Please do not mix cause and effect together.
Human brains is simply do not fit for accounting that much
information, and there is no way how humans can make sense out of so
much various state grouped into a single entity. Not saying about
unbearable complexity of code which needs to manage that amount of
state meaningfully inside a single entity.

If language allows you to do something, it doesn't means you should do
it and exploit it up to the point of total absurd.
(STL and especially Boost C++ libraries is a good example of such abuses :)

And yes, for a simple demonstration, can you compare following two
snippets of code and say, which one is more bearable/readable and
easier to work with:

Object subclass: #Point
	instanceVariableNames: 'x y'
	classVariableNames: ''
	poolDictionaries: ''
	category: 'Kernel-BasicObjects'

-----
ObjectMemory subclass: #Interpreter
	instanceVariableNames: 'activeContext theHomeContext method receiver
instructionPointer stackPointer localIP localSP localHomeContext
localReturnContext localReturnValue messageSelector argumentCount
newMethod currentBytecode successFlag primitiveIndex
primitiveFunctionPointer methodCache atCache lkupClass
reclaimableContextCount nextPollTick nextWakeupTick lastTick
interruptKeycode interruptPending semaphoresToSignalA
semaphoresUseBufferA semaphoresToSignalCountA semaphoresToSignalB
semaphoresToSignalCountB savedWindowSize fullScreenFlag
deferDisplayUpdates pendingFinalizationSignals compilerInitialized
extraVMMemory receiverClass interpreterProxy showSurfaceFn
interruptCheckCounterFeedBackReset interruptChecksEveryNms
externalPrimitiveTable primitiveTable globalSessionID jmpBuf jmpDepth
jmpMax suspendedCallbacks suspendedMethods profileProcess
profileMethod profileSemaphore nextProfileTick metaclassSizeBytes
statIOProcessEvents statCheckForEvents statQuickCheckForEvents
statProcessSwitch statPendingFinalizationSignals gcSemaphoreIndex'
	classVariableNames: 'AtCacheEntries AtCacheFixedFields AtCacheFmt
AtCacheMask AtCacheOop AtCacheSize AtCacheTotalSize AtPutBase
BlockArgumentCountIndex BlockMethodIndex BytecodeTable CacheProbeMax
CallerIndex ClosureMethodIndex CompilerHooksSize CrossedX DirBadPath
DirEntryFound DirNoMoreEntries DoBalanceChecks EndOfRun HomeIndex
InitialIPIndex JitterTable MaxExternalPrimitiveTableSize MaxJumpBuf
MaxPrimitiveIndex MillisecondClockMask PrimitiveExternalCallIndex
PrimitiveTable SemaphoresToSignalSize TempFrameStart'
	poolDictionaries: 'VMBasicConstants VMMethodCacheConstants VMObjectIndices'
	category: 'VMMaker-Interpreter'

--------
you know, sometimes for me it even hard to tell whether i need to add
a new state variable
or there's already some variable what i can reuse.. neither i can
clearly tell, what the purpose of each and every of variables in that
bloated class without spending a considerable amount of time groking
the code.

And do you really think that debugging its code would be significantly
easier comparing if that state would be held in dictionary?

> The code limits are something that not many people run into, but hitting the limit hurts, hard. Kudos to Eliot for taking this on.

Again, it hurts hard not because you reached those limits, the fact
that you reached them is indication
that your design contain severe problems which you should deal with
first, instead of patching the language
to allow you continue exploiting and building even more bloat.

>
> - Bert -


-- 
Best regards,
Igor Stasenko.