<purr>
<micahjohnston> DALEKSGORDON: thought you should know
<joelteon>
stop
<gq>
he said, two minutes later.
<gq>
ELLIOTTCABLE: hihihihihihihi
<nuck>
You panged?
<nuck>
-what @ gq
<purr>
<Nuck> I guess, but I don't care about build quality or looks, I just want a good cup
<nuck>
:3
<gq>
nuck: :)
<gq>
-nuck @ nuck
<purr>
nuck: shut up nuck you are a nuck
<nuck>
shut up gq you are a gq
<gq>
nuck: i currently am a protect op on the R sever you linked me to
<gq>
nuck: at least i'm prettier than you
<nuck>
R server?
* gq
combs hair delicately, blows #elliottcable a kiss
<gq>
nuck: Rizon.
<nuck>
oh
<nuck>
hah
<gq>
protected*
<nuck>
Well... I'm staff at Hummingbird.me :D
<gq>
nuck: better to reign in hell than serve in heaven ;)
<nuck>
#goml
<gq>
nice
<nuck>
My code runs on something like 50,000 computers a month
<gq>
very fancy!
<gq>
brb
gq has quit []
<ELLIOTTCABLE>
nuck: shut up gquck you are a gquck
<nuck>
gquck you ELLIOTTCABLE
<ELLIOTTCABLE>
gq: hello
<ELLIOTTCABLE>
gq: hello
<ELLIOTTCABLE>
gq: hello
Sorella has quit [Quit: Ex-Chat]
<nuck>
ELLIOTTCABLE: hello hello hello
<ELLIOTTCABLE>
nuck: hello
<ELLIOTTCABLE>
nuck: i like you more than gq
<ELLIOTTCABLE>
nuck: hello
<nuck>
lol
<purr>
lol
<nuck>
but gq is so much fun
<ELLIOTTCABLE>
yes
<ELLIOTTCABLE>
but you are responsive
<nuck>
It's like that one crazy friend who will smoke or inject any drug he is handed on the street
<ELLIOTTCABLE>
responsive ≥ fun, any day
<nuck>
Today I dealt with the awfullest perl programmers in the world
<ELLIOTTCABLE>
no
<nuck>
Enid's programmers are so awful that they recreated TLS on top of UDP because UDP "is lighter weight"
<nuck>
s/Enid/AniDB/
<nuck>
I think that at least puts them in the running for "worst perlists ever"
<nuck>
Oh yeah and it's stateful by IP
<ELLIOTTCABLE>
oh gods
<nuck>
Wanna upload an avatar? You have to go to their "image upload system" and then upload an image which it gives you an ID for, which you then paste back into a text area on your profile edit page
<nuck>
"Export your list as invalid XML! We forgot the root node! But who cares!"
<nuck>
(the export template is 5 years old. Nobody noticed the XML lacked a root note FOR FIVE FUCKING YEARS)
<katlogic>
Cheery: like cheery mix between coffeescript and lisp
<Cheery>
good. :)
<Cheery>
katlogic: thinking about input methods. been looking at the videos and there's one thing I'm marking up.
<Cheery>
even if the input is text, one is modifying them as semantics
<katlogic>
well, the vi-like nav was a neat placeholder, but certainly not something i'd use
<Cheery>
hmm.. what would you use?
<katlogic>
if i'd wanted vi bindings i'd use vim (I use very similiar macros to navigate blocks in fact)
<katlogic>
Cheery: Well, the whole idea of visual for me is to get rid of keyboard.
<katlogic>
Keyboard is powerful, but certainly falling out of fashion.
<Cheery>
I think we still need a keyboard to code big. so I'm designing a method. But you're right
<katlogic>
(Same for mouse. Fat fingers only.)
<Cheery>
keyboard isn't entirely needed. except for inputting symbol names and writing communicators.
<Cheery>
communicators - the kind of stuff that happily stays text. non-structural text.
<Cheery>
but there's important thing here anyway
<Cheery>
and I think it applies anywhere
<Cheery>
katlogic: have you studied how are you coding with text editor?
<katlogic>
Only superfcially. A lot of motor memory. Especially for things with tedious syntax.
<Cheery>
yup. vim exploits that one.
<katlogic>
a bit like typing english. since i learned english online, i can barely speak in real world out of the blue until i code switch. actually have to imagine myself typing and read it out loud for a while.
<Cheery>
well I'm noticing at my videos. I'm doing about 40 keystrokes to create a variable or whatever else. big jumps around the text.
<katlogic>
yeah, navigation amounts to a lot
<katlogic>
also common transposition
<Cheery>
but why they're needed is because we're doing certain semantic operations for the code
<katlogic>
raw text typed is like 10% for me, or maybe even less.
<Cheery>
we add a variable, or lift variable into a function argument..
<Cheery>
or partition expression into pieces
<katlogic>
everything falls into transposition
<katlogic>
transform contexts of existing text, without typing new one.
<Cheery>
yup
<Cheery>
when typing new one, it's always slow. but you're doing that bottom up rather than top down.
<katlogic>
Ideally, i'd imagine i (multi)select some sentence and and drag and drop it somewhere.
<Cheery>
you create text communicators, then combine them
<katlogic>
the editor bruteforces all possible variations which are syntactically/type correct
<katlogic>
and offers me to choose one
<Cheery>
I think the operations can, and better be unambiguous.
<katlogic>
naturally you have to learn to select and paste enough context so the amount of choices is reasonable
<Cheery>
but there's fixed amount of such "common" operatioens that are rather high level.
Sorella has joined #elliottcable
<Cheery>
I think there's way to model the editor around those.
<katlogic>
Cheery: vim works by picking *huge* amount of source context, and then providing another huge amount of destination context.
<katlogic>
this is unwieldable on touchscreen.
<katlogic>
try to imagine common transforms as i said.
<katlogic>
sublimetext already does it, to small degree.
<Cheery>
yup. but.. I'm imagining this is actually something that becomes easy in my editor
<Cheery>
and I think I should pivot to it
<Cheery>
at laest for now
<katlogic>
the central tenet is, the editor is syntax aware
<katlogic>
and wont allow you to perform syntactically invalid transform. however most transforms yield initially invalid result.
<Cheery>
well.. it's not syntax awareness. what I need is semantics/structure awareness
<katlogic>
so it applies a lot of heuristics to provide valid choices.
<katlogic>
for C/C++ its easy - as long it compiles
<katlogic>
for dynamic languages, its very tough one
<Cheery>
and I think it's okay if it visits syntactically invalid transforms.
<katlogic>
yeah, for your lisp case
<Cheery>
as long as they're structurally coherent.
<katlogic>
nearly every transformation yields syntactically valid construct :)
<katlogic>
since lisp has no syntax to speak of anyway
<Cheery>
it has.
<Cheery>
( ) are syntax
<katlogic>
yes. the only rule is parens must match.
<katlogic>
thats literally the whole syntax :)
<katlogic>
same could be said about forth and so on.
<Cheery>
also some are special forms when they are formed right
<Cheery>
I actually removed special forms
<katlogic>
Cheery: yes, i hate those too
<katlogic>
special forms for atoms, null terminators and such
<katlogic>
makes lisp feel ugly, though its a handy shortcut, lisp itself is hardcore spartan
<Cheery>
one can just label the lists that need special treatment
<Cheery>
heh... even 'cr' is just a labelled marker.
<Cheery>
one can adjust amount of decorations or change it.
<katlogic>
what you're doing is just simple ast transforms. in true s-expr those are rendered void, exactly as you do.
<Cheery>
it's not pure freedom. the communicators must still come in order. but the list labels let you affect that too
<katlogic>
Cheery: Anyhow, the freedom dynamic languages provide seems worrysome for me.
<katlogic>
To realize my simpleton-friendly editor would equal to fair amount of machine learning.
<Cheery>
the layout engine will be probably controlled entirely from the editor.
<katlogic>
ie your pinpoint-precise transpositions fed into feedforward NN
<katlogic>
the NN tries to assist you later on based on what it learned
<Cheery>
funny thing. you realise you still need these same things under
<Cheery>
?
<katlogic>
because initially, the transpositions will be very tedious to do by hand :(
<Cheery>
pure structures -category structure editor basically.
<katlogic>
Cheery: I'm not exactly interested in editing s-exprs, or mild ast extensions on top of it.
<katlogic>
Those forms allow still for too much of freedom.
<katlogic>
It's a blessing and a curse at the same time.
<Cheery>
maybe
<katlogic>
What I'm talking, in schoolbook examples: You remember what function a variable refers too, and also usual arity of that functions (because typically your functions are highly vararg).
<Cheery>
we don't yet have *any* kind of structure editor that would have become mainstream
<katlogic>
When you transpose something into invocation of that function (it looks it up from function value observed at runtime on given var), it tries to munge code to match typical arity.
<Cheery>
I figure there have been attempts, but lack of knowledge or discipline to create a successful system.
<katlogic>
There is some research for NN assisted bug auditing.
<katlogic>
Not exactly the same, but some basics are common.
<katlogic>
Cheery: Indeed we're stuck in the 70s as far as programming interfaces go. Borland introduced some reinessance, for UIs, with QT carrying the legacy, but for general algorithmics? Naah.
<katlogic>
Cheery: btw, a lot of ideas i'm peddling here is just some lucid babbling inspired by 'an editor', if you've not seen it yet.