<jesusabdullah>
jesus, that's a blast from the past
<jesusabdullah>
I've worked so much with your abandonware and not-so-abandonware cloudhead you have no idea XD
<whitequark>
nodejs is like cancer
<devyn>
js makes me want to kill myself
<alexgordon>
whitequark: LOL
<purr>
LOL
<alexgordon>
whitequark: but you have to admit, it has something
<alexgordon>
I think Cocoa probably has the edge technically. dispatch_io is fucking magic
<alexgordon>
but node.js is much better in its presentation of IO concurrency
sammcd_ is now known as sammcd
<whitequark>
alexgordon: it has about nothing
<alexgordon>
whitequark: that's just not true
<alexgordon>
it has a runloop
<whitequark>
oh right, that's what nodejs has invented, right
<alexgordon>
it's amazing how few languages actually have a runloop by default...
<whitequark>
perhaps because you can write a runloop in about three lines of code?
<whitequark>
it's not a language feature.
<alexgordon>
not efficiently
<whitequark>
wat
<alexgordon>
well you can't just do while (1) { process_events(); } unless you want to sit at 100% CPU
<whitequark>
(besides the fact that nodejs is not a language)
<whitequark>
um
<whitequark>
yes, if you want to wait on external events, you'd need OS support.
<alexgordon>
but waiting on external events would kinda defeat the point of having one in the first place
<whitequark>
eh
<whitequark>
while(1) { epoll; process_events; }
<alexgordon>
anyway the point is that GCD is God ;)
<alexgordon>
but libuv is almost as good
<alexgordon>
and damn better than the shitty ones that ruby and python have come up with
<whitequark>
all of that can be easily implemented in any language which has or can imitate closures
<whitequark>
i.e. C and... literally everything more complex than C.
<alexgordon>
maybe this is a prejudice of mine, but I don't trust a language implementation unless the core bits are written in C or C++
<whitequark>
define "core bits"
<alexgordon>
depends on the efficiency of the language
<whitequark>
ocaml is implemented in ocaml (except for libc shims)
<alexgordon>
ruby and python are so slow that "core bits" is a lot
<whitequark>
compiler, stdlib, etc
<alexgordon>
java is fast enough that they can get away with implementing stuff in java
<whitequark>
it also maps fairly directly to the metal, as long as you're looking at a specific implementation.
<whitequark>
and by "fairly directly" I mean "it's not very hard to guess which assembly is going to be generated"
<whitequark>
also
<whitequark>
"efficiency of language" is something that does not exist
<whitequark>
"efficiency of particular implementation for a particular workload" does
<alexgordon>
I guess core bits is mostly stuff that involves either basic data structures (strings, arrays, dictionaries, balanced trees), syscalls and threading
<alexgordon>
whitequark: I don't really agree. python has locals() which returns a dictionary of the currently set local variables
<alexgordon>
that kind of thing brings down the efficiency of the whole language
<alexgordon>
also the integers have to be bignums as of py3k
<whitequark>
both are shitty features, especially locals()
<alexgordon>
I suppose it could be said that languages don't have efficiency, but they do have *inefficiency*
<whitequark>
by the way, pypy can optimize it.
<alexgordon>
whitequark: right, but they're part of the language
<whitequark>
it's really no different from java, except your prejudice is shifted the other way because efficient implementations of java exist
<whitequark>
see, java is dynamically typed in essence
<whitequark>
because type erasure
<alexgordon>
I don't believe it's possible to implement Ruby or Python as efficiently as Java
<whitequark>
yet for monomorphic call sites, dispatch is free, and by free I mean free
<whitequark>
huh
<whitequark>
it is
<alexgordon>
it's never been done!
<whitequark>
pypy
<whitequark>
and topaz
<alexgordon>
pypy just isn't as fast as the jvm
<whitequark>
topaz is incomplete, yet I, being rather familiar with ruby internals, don't see any significant obstacles they didn't solve yet.
<whitequark>
proof?
<alexgordon>
every benchmark ever?
<whitequark>
let's look
<alexgordon>
usually at this point I would say that benchmarks don't count because they tend to be hyperoptimized and don't represent real world code
<alexgordon>
but I think *even* with that, JVM comes out on top every time
<whitequark>
benchmarks, if done correctly, represent real-world numeric workloads
<whitequark>
so in some cases they do indeed matter
<whitequark>
(there are benchmarks which i.e. are eaten by the optimizer. these don't.)
<alexgordon>
well in reality you don't get dozens of people working on one file for weeks on end
<whitequark>
oh you totally do
<alexgordon>
unless that file is sha3.c ;)
<whitequark>
for example I used to work with bioinformatics
<alexgordon>
usually it's more like a day, then move on to the next job
<whitequark>
that's basically what it is
<whitequark>
protein folding, for example.
<whitequark>
or, I dunno, weather prediction
<alexgordon>
sure, but most apps on the app store are not like that
<whitequark>
doesn't matter
<alexgordon>
you have marketing goals, deadlines, etc
<whitequark>
you can write most apps on the appstore in BASIC and nothing would change
<whitequark>
because language efficiency doesn't matter to them
<whitequark>
don't change the topic.
<alexgordon>
what was the topic?
<whitequark>
efficiency of ruby/python
<alexgordon>
it just seems obvious to me
<whitequark>
it's probably false then ;)
<alexgordon>
for instance java has type information
<whitequark>
hardly
<whitequark>
it has type erasure.
<alexgordon>
and each object has a set layout
<whitequark>
as I've said: Java is dynamically typed with *some* annotations which mostly sit unused in HotSpot (AFAIK).
<alexgordon>
whitequark: sure but that happens afterwards usually
<whitequark>
after what?
<whitequark>
it happens during compilation
<alexgordon>
right
<alexgordon>
so does optimization
<whitequark>
you don't know the type of elements in a generic collection, it's Object
<whitequark>
no
<whitequark>
Java compilers don't optimize
<alexgordon>
lol sure they don't
<purr>
lol
<whitequark>
Java runtime does, and at that point it doesn't have all typing information available
<whitequark>
narrowing casts and generic collections.
<whitequark>
so, it recovers types via inline caches at call sites, just as your typical dynlang runtime would
<whitequark>
javac does not perform optimizations on bytecode, ask someone else why it doesn't
<alexgordon>
not on bytecode
<whitequark>
and on what?
<alexgordon>
before codegen
<whitequark>
proof?
<whitequark>
if we're talking about hotspot, javac is naively translating ASTs right into the stack-machine bytecode
<joelteon>
lel
<joelteon>
are you guys having this discussion again
<whitequark>
joelteon: we're having fun don't you see
<joelteon>
yeah i see it
<alexgordon>
whitequark: I really find that impossible to believe. I mean codegen to bytecode itself is a form of optimization (vs just serializing the parse tree)
<joelteon>
looks like the fun I have
<alexgordon>
lol
<purr>
lol
<whitequark>
alexgordon: it's a fact dude
<alexgordon>
I don't believe it
<whitequark>
should I point you to javac sources?
<whitequark>
lol.
<joelteon>
did you guys know my office chair cost $800?
<joelteon>
why would someone buy a chair that expensive?
<whitequark>
alexgordon: btw, the dynamism JVM has to deal with is *the* reason JVM is sort-of-a-good-fit for dynlangs and is so popular with them these days.
<whitequark>
re object layout: JRuby lays out objects just the same*
<whitequark>
* if you don't abuse instance_variable_set and friends very much
<whitequark>
but that would be just like saying "omg I store all my data in java hashes and it's slow". don't do it.
<alexgordon>
whitequark: ruby doesn't have a set object layout though
<alexgordon>
there's no declaration of instance variables
<whitequark>
so?
<alexgordon>
you can do @foo at any time
<alexgordon>
boom new iv
<whitequark>
jruby infers that from usage
<whitequark>
a form of static analysis
<alexgordon>
can't you load in a module at any time?
<joelteon>
yeah
<alexgordon>
I don't really know ruby, only that it's like objc
<whitequark>
yes, and then it would take the slow route and store stuff into a hash
<joelteon>
@foo = true if rand(2) == 1
<alexgordon>
lol
<purr>
lol
<whitequark>
joelteon: no, that's ok
<whitequark>
it'll just store nil there then
<joelteon>
but @foo is already nil
<joelteon>
oh wait
<joelteon>
ok
<whitequark>
lol
<alexgordon>
point is that java knows the exact ivs a class has, and it knows their types
<whitequark>
alexgordon: no, it doesn't know their types
<alexgordon>
it's not my fault if it doesn't fucking do anything with the information
<alexgordon>
it still knows
<whitequark>
no, it doesn't. for ivar of type A, it knows that the value is a *subtype* of A
<whitequark>
this shit matters
<whitequark>
*the type of value
<whitequark>
unless A is a final class, but as I've said: in general case it has no idea
<alexgordon>
well yeah but not for primitive types
<whitequark>
ok, very well
<alexgordon>
so basically
<alexgordon>
fuck all languages
<alexgordon>
they're stupid
<whitequark>
so you see my point now? it doesn't do anything with the info, just like a ruby impl could not (because it would not have the info), and yet it's fast
<whitequark>
lol
<alexgordon>
if it doesn't, then that's the implementation's fault
<alexgordon>
not java itself
<alexgordon>
the language gives the information
<whitequark>
yet you were saying that the language cannot be fast
<alexgordon>
java?
<whitequark>
ruby
<whitequark>
jav
<whitequark>
*java
<whitequark>
whichever
<alexgordon>
lol
<purr>
lol
<alexgordon>
ruby cannot be fast because it does not encode enough information into the source code
<whitequark>
but java's fast, and it doesn't need that information
<whitequark>
to be fast
<alexgordon>
java can be faster because the source has more information, so it can use less indirection
<whitequark>
proof?
<whitequark>
before you waste your time
<whitequark>
no, it cannot: it can already optimize out *all* indirection
<whitequark>
it can easily inline functions and all that
<alexgordon>
ruby?
<whitequark>
java
<alexgordon>
but that's what I said
<alexgordon>
-_-
<whitequark>
and ruby, yeah, in case of jruby
<alexgordon>
there's more to it than that
<whitequark>
if we're talking about method dispatch, java and ruby are on the equal terms
<alexgordon>
function calls yes, but also variables
<whitequark>
even just on hotspot
<whitequark>
ok, that works about the same
<whitequark>
JVM is too dumb to represent changes in object layout, but there are runtimes which are not
<whitequark>
PyPy
<whitequark>
Common Lisp, for that matter
<alexgordon>
pypy is facing an uphill battle against the Management
<whitequark>
so on those runtimes, you could even perform well in the general case with loadable modules
<whitequark>
and i_v_set
<alexgordon>
every time they get anywhere guido goes and fucks them up with another misfeature ;)
<whitequark>
hahaha
<whitequark>
the only sort-of-valid point you have is bignums
<whitequark>
but!
<whitequark>
nothing in the language prevents a library from providing efficient fixed-width types
<alexgordon>
eh
<alexgordon>
nobody's gonna use it
<alexgordon>
also
<whitequark>
so?
<alexgordon>
you can't force *other* people to use it
<alexgordon>
if I use a python library
<alexgordon>
it will use the default integers
<alexgordon>
even if I went to the considerable effort of converting all my code to fixed width integers
<alexgordon>
I can't do that for all the libraries I use too
<whitequark>
what you said is that python, as a language, somehow prevents this efficiency from happening
<whitequark>
but that is simply not true
<alexgordon>
well I have a more practical definition of language
<whitequark>
what prevents it is people's inertia, perhaps, but not the language
<alexgordon>
a language is defined by its native speakers
<whitequark>
i.e. no one?
<alexgordon>
heh
<alexgordon>
"python code" is not just the rules of the reference implementation, but also the code that people write
<whitequark>
"python code" is what conforms to the python standard
<alexgordon>
if something is very far away from normal python code, then it's not really "python" in any meaningful way
<whitequark>
period
<whitequark>
uh, there's no python standard, so fuck it
<alexgordon>
that's very prescriptivist of you ;)
<whitequark>
"ruby code" is what conforms to ISO Ruby
<whitequark>
by definition
<whitequark>
or you could even say "conforms to RubySpec", though it would be more vague
<whitequark>
and more practical
<whitequark>
all major impls pass RubySpec
<alexgordon>
I just disagree though. It may be nominally ruby, but languages are about more than just specifications
<alexgordon>
it's about the community, social norms, people, all those kinds of soft stuff
<whitequark>
language is exactly just specification
<whitequark>
everything else has to do under some other term
<whitequark>
"ecosystem" is what cool kids like these days
<alexgordon>
goto is part of C but if social norms prevent you from using it, it's at most a second class feature
<whitequark>
and if you'd say that the way people write python code, that python code will be slow, I'll agree
<whitequark>
but this is in no way related to python as a language
<alexgordon>
that's how I think about language though. not just a specification, but the entirety of what goes on in someone's noggin' when they use it
<whitequark>
the problem is that there may be a lot of ways to write code in a language
<whitequark>
dozens in case of C/C++, for example
<alexgordon>
yeah, and to the credit of python, they have "one (preferably obvious) way to do it" as a design criteria
<whitequark>
except they fucked it up themselves
<whitequark>
core python is incredibly inconsistent
<whitequark>
it went *slightly* better in 3k
<alexgordon>
true
<whitequark>
well, my point was that by your definition, C is not a language
<whitequark>
which sorta disagrees with... everyone else's definition of a language
<alexgordon>
whitequark: everyone else is wrong ;)
<devyn>
proper wifi authentication at university makes me happy
<whitequark>
yeah, I know that article
<whitequark>
it could be relevant, if it wasn't first and foremost describing people for whom quality of the product is of comparatively minor importance
<joelteon>
alexgordon: that article is fantastic
<whitequark>
funny thing
<whitequark>
eric lippert has basically retold this article in late 2012 or early 2013
<whitequark>
he did a talk
<whitequark>
the slides were basically this article, but mixed 1:3 with cats
<whitequark>
what the fuck is wrong with you people
<whitequark>
why everyone in tech has an attention span of 4-year-old
<joelteon>
i don't
<joelteon>
i read the whole thing
<joelteon>
but i'm glad i wasn't in a talk at the time
<joelteon>
there's something about sitting down in an auditorium that just murders my attention span
<joelteon>
i can read an entire book while i'm waiting for test suites to run, but put me in a dark room watching a speaker and i fall asleep in 10 minutes
<micahjohnston>
joelteon: truth
<whitequark>
hur hur
<joelteon>
why is that
<joelteon>
i don't know why it is
<alexgordon>
furrooooow
<alexgordon>
xD
<micahjohnston>
whitequark: generally, expecting everyone to have more patience and self control is not a good solution to social problems
<micahjohnston>
people have been wishing that for millenia
<micahjohnston>
:p
<micahjohnston>
alexgordon: k
<micahjohnston>
;)
<alexgordon>
micahjohnston: FURROW
<micahjohnston>
or actually
<whitequark>
micahjohnston: that's why you have entry barriers in most professional settings
<micahjohnston>
the improved thing that is like k
<micahjohnston>
that is frp
<micahjohnston>
that i am making
<micahjohnston>
:o
<whitequark>
I wonder
<micahjohnston>
shouldn't have steeped this tea so long
<joelteon>
you know what's shit? working with VMs all day
sharkbot has quit [Remote host closed the connection]
sharkbot has joined #elliottcable
<micahjohnston>
alexgordon: maybe this will show you something cool
<micahjohnston>
alexgordon: this is J:
<micahjohnston>
to calculate average
<micahjohnston>
+/ % #
<micahjohnston>
/ is fold, so +/ is sum
<micahjohnston>
# is length
<micahjohnston>
and % is divide
<micahjohnston>
so that calculates the sum divided by the length
<micahjohnston>
isn't that fucking awesome
<joelteon>
yeah i've used J
<joelteon>
it's fun
<alexgordon>
micahjohnston: ...
<joelteon>
i used to know a lot of J, but I purged it
<alexgordon>
micahjohnston: it's neat, but I still wouldn't want to use it
<micahjohnston>
yeah i understand
<micahjohnston>
just thought that that was a particularly beautiful example
<micahjohnston>
J's way better at non-imperative solutions to things than K is I'd say
<alexgordon>
micahjohnston: In Furrow that would be: sum(xs) / #xs
* micahjohnston
nods
<alexgordon>
I feel like functional programming is the real hero
<micahjohnston>
though I'm disappointed at how often J degrades to imperative stuff
<micahjohnston>
like for the gUI
<micahjohnston>
GUI
<micahjohnston>
and it has like
<micahjohnston>
full on imperative control structures with keywords
<micahjohnston>
it's awful
<alexgordon>
like haskell? :D
<joelteon>
what
<micahjohnston>
lol what
<purr>
lol
<alexgordon>
micahjohnston: full on imperative control structures with keywords
<joelteon>
can we all agree that godaddy sucks balls?
<micahjohnston>
yeah
<joelteon>
ok
<ELLIOTTCABLE>
alexgordon: around?
<ELLIOTTCABLE>
whitequark: you did bioinformatics? have you met audy?
eligrey has joined #elliottcable
<ELLIOTTCABLE>
alexgordon: I'd like to re-open work on the Paws spec, some time in the near future
<alexgordon>
hi ELLIOTTCABLE
<alexgordon>
back in 1 hour
<alexgordon>
ELLIOTTCABLE: but sure
<ELLIOTTCABLE>
not now, anyway
<ELLIOTTCABLE>
phone call to make I suppose
<ELLIOTTCABLE>
and just grumpy
PragCypher has joined #elliottcable
<micahjohnston>
ELLIOTTCABLE:
<ELLIOTTCABLE>
?
<micahjohnston>
biohack
<ELLIOTTCABLE>
meh
<micahjohnston>
:p
<ELLIOTTCABLE>
meh, meh, everything is meh
<micahjohnston>
ya
<ELLIOTTCABLE>
no, but really, I'd love to do that
<ELLIOTTCABLE>
dunno how I'm going to find time
* micahjohnston
nods
<ELLIOTTCABLE>
unless I break up with girlfriend *and* drop paws entirely to learn an entirely new skill set …
<ELLIOTTCABLE>
idk. sounds like a reasonable barrier-to-entry to me.
<micahjohnston>
ELLIOTTCABLE: thought of ideas for paws higher level:
<ELLIOTTCABLE>
wat
<micahjohnston>
like the abstraction stuff
<micahjohnston>
so like
<ELLIOTTCABLE>
go
<ELLIOTTCABLE>
icky, need to shower, and make important phone calls, and I haven't even acquired lunch
<micahjohnston>
sometimes you want to be taken control of by the time series of events
<ELLIOTTCABLE>
and I'm so, so, so, so thirsty
<micahjohnston>
like the default
<ELLIOTTCABLE>
but fuck it, go
<micahjohnston>
print(list each)
<micahjohnston>
but sometimes you want to take control of it
<micahjohnston>
so we should have nice library functions for
<micahjohnston>
accumulate.into.a.list(list each)
<micahjohnston>
and
<ELLIOTTCABLE>
“taken control of by the time series of events”
<micahjohnston>
sum.over.time(list each)
<micahjohnston>
as in
<micahjohnston>
called multiple times
<ELLIOTTCABLE>
hm
<micahjohnston>
without the multiple times knowing about each other
<ELLIOTTCABLE>
so,
<ELLIOTTCABLE>
you're speaking of functions being *able* to, if they want to,
<ELLIOTTCABLE>
use multiple-reception-calling-stuff, to their own benefit? under their own control?
<micahjohnston>
yeah
<micahjohnston>
and i mean
<micahjohnston>
it's very possible
<micahjohnston>
with the current primitives
<micahjohnston>
to make library functions like that
<ELLIOTTCABLE>
oh, definitely
<ELLIOTTCABLE>
thinking about whether that's *desirable*, though, no?
<ELLIOTTCABLE>
hm
<ELLIOTTCABLE>
I mean, there's, I feel, more Paws-y idiomatic ways to handle each of those situations
<ELLIOTTCABLE>
drawbacks, probably, though
<ELLIOTTCABLE>
lessee
<ELLIOTTCABLE>
accumulate(<producer>) becomes, if we don't want a multi-aware thing,
<ELLIOTTCABLE>
multi-consumption-aware* thing,
<ELLIOTTCABLE>
actually, you're entirely right
<ELLIOTTCABLE>
although in reality it'd be something more like,
<ELLIOTTCABLE>
create.accumulator
<ELLIOTTCABLE>
accumulator(<producer>)
<ELLIOTTCABLE>
right?
<ELLIOTTCABLE>
some crap like that?
<micahjohnston>
hmmmm maybr
<micahjohnston>
i like it more just
<micahjohnston>
a <- accumulate(producer)
<ELLIOTTCABLE>
perhaps a list *type* that accumulates when juxtaposed against
<micahjohnston>
then it sits right in the ast
<ELLIOTTCABLE>
i.e. a “callable list”
<ELLIOTTCABLE>
a (<producer>)
<ELLIOTTCABLE>
gotta get Paws.js running code,
<ELLIOTTCABLE>
gotta work through more of the spec with alexgordon,
<ELLIOTTCABLE>
micahjohnston: help me not suck at life. help me make this a thing.
<micahjohnston>
ok
<micahjohnston>
right now I want to make something that is:
<micahjohnston>
halfway between apl/j/k and frp and paws
<micahjohnston>
lol
<purr>
lol
<micahjohnston>
but yeah
<micahjohnston>
i will help paws
* ELLIOTTCABLE
laughs
<ELLIOTTCABLE>
of course you do
<ELLIOTTCABLE>
isn't that our plight as programmers?
<ELLIOTTCABLE>
what I need more than anything else, is somebody *above* me
<ELLIOTTCABLE>
I wish I could hand the Paws project off to some sort of executive-officer.
<ELLIOTTCABLE>
I would give bucket loads of cash for a “sephr I could trust.”
<ELLIOTTCABLE>
I just want to be *organized*. That is, be the target, of the verb, to-organize. I want somebody to organize me, delegate tasks individually, and figure out which tasks can safely be delegated *away* from elliottcable without losing the flavor of the project.
<ELLIOTTCABLE>
I'm so, fucking, jealous of my girlfriend: she's the lead designer at her studio right now, at least, as far as I can break down their management structure; but she's got a coworker whose entire job is just to break down the shit that needs to happen for clients, and hand out to-do's and deadlines to everybody else.
<ELLIOTTCABLE>
The person isn't a boss. Just, a planner.
<ELLIOTTCABLE>
And what she says *goes*, because she's such a great planner, and so mud hgets done.
<ELLIOTTCABLE>
vil!
<ELLIOTTCABLE>
vil: come Paws with micahjohnston, alexgordon, and I. Let's get this some form of *done*.
<micahjohnston>
I think we need to make it way less of a turing tarpit
<micahjohnston>
and, just imo, less dynamic
<micahjohnston>
in syntax
<micahjohnston>
idk what you think on that though
<ELLIOTTCABLE>
have actionable suggestions?
<micahjohnston>
well like
<ELLIOTTCABLE>
mostly, I want to avoid big *changes*. Only the changes necessary for error-handling and distribution.
<micahjohnston>
maybe scoping and statements can be syntax-level
<micahjohnston>
so my vision is:
<micahjohnston>
within a block every statement can be connected through referencing each other's name bindings, but they are not executed in textual order
<ELLIOTTCABLE>
oh
<micahjohnston>
{ a; b; c}
<ELLIOTTCABLE>
“less dynamic in syntax”
<ELLIOTTCABLE>
didn't properly read that
<ELLIOTTCABLE>
thought you meant make the language less dynamic, which made very little sense. lol.
<purr>
lol
<ELLIOTTCABLE>
it's hard to argue for/against this without writing a really basic IPP to work with.
<ELLIOTTCABLE>
now we've got a good idea what “canonical paws code” looks like, having a dozen or so examples to work with
<ELLIOTTCABLE>
really simple shit, but still, at least I can *think* in that mode now
PragCypher has quit [Quit: Leaving]
<ELLIOTTCABLE>
but I don't know what's reasonably do-able at a higher level, with the current design
<ELLIOTTCABLE>
is munging up the simple syntax we have now, actually necessary?
<micahjohnston>
ipp?
<micahjohnston>
well
<micahjohnston>
it's like
<micahjohnston>
really hard to think anything in our turing tarpit
<ELLIOTTCABLE>
I agree with that.
<micahjohnston>
this makes thinking in the language not a brainfuck puzzle
<micahjohnston>
and simplifies everything
<micahjohnston>
imo
<ELLIOTTCABLE>
I feel like Paws *should* be small enough that we can “be done with” the tarpit, though
<micahjohnston>
and is closer to the ideal of paws
<ELLIOTTCABLE>
and work entirely at higher levels of abstraction for the most part
<ELLIOTTCABLE>
disagreement?
<micahjohnston>
well yeah but i mean this works just as well or better as the lowest level
<ELLIOTTCABLE>
hm
<ELLIOTTCABLE>
I see your point, more than I ever have previously.
<ELLIOTTCABLE>
I love, this channel. Been too long since I last properly appreciated it. ('=
<micahjohnston>
haha :)
<ELLIOTTCABLE>
mmmmm,
<ELLIOTTCABLE>
I don't like the naming-statements thing too much
<ELLIOTTCABLE>
how do I phrase this …
<ELLIOTTCABLE>
the IPP's a given. I want dynamic syntax, definitely.
<micahjohnston>
oh yeah ipp
<micahjohnston>
ok sure assignments can be dynamic
<ELLIOTTCABLE>
and that *particular* approach to untarping the lowest level, doesn't seem too compatible with my design.
<micahjohnston>
but I think statements should be syntax
<ELLIOTTCABLE>
but perhaps now, that we have a *good feel* for the lowest-levels of Paws thought, *is* a good time to rethink the syntax
<ELLIOTTCABLE>
statements-as-syntax is such a goddamn simple change that I'm not worried about it, y'know?
<micahjohnston>
sure
<ELLIOTTCABLE>
we can cross that bridge when we come to it.
<micahjohnston>
i just don't like () being locals
<micahjohnston>
and shit
<ELLIOTTCABLE>
hm
<ELLIOTTCABLE>
hmmm
<ELLIOTTCABLE>
all the overloading, you mean?
<ELLIOTTCABLE>
here's a thought for you:
<ELLIOTTCABLE>
a lot of the revulsion of stuff like that, is that we often see it when somebody is trying *unnecessarily* to map the set of operations onto the most-compressed-possible-set of syntax. Arbitrarily. For no reason.
<ELLIOTTCABLE>
which *is* disgusting, and a really good way to waste a lot of time, effort, and make everything messy.
<ELLIOTTCABLE>
But here, we *have* got a good reason (not to imply I'm not open to considering adding more syntax):
<ELLIOTTCABLE>
the less syntax we have any meaning for, at all, in the *parser* level, the more syntax we can *define* (as opposed to overload) at a higher level in the IPP.
<ELLIOTTCABLE>
or, to put it another way:
<ELLIOTTCABLE>
I'd like, wherever possible, to *add a new, independent operation* to the language's syntax (at least at the lowest levels of fresh, new abstraction), rather than overload an existing one with new functionality right at the start.
<micahjohnston>
uhuh
<micahjohnston>
i just think
<micahjohnston>
a (b) vs a b
<micahjohnston>
is not-fun and puzzley
<ELLIOTTCABLE>
rephrase?
<micahjohnston>
like obviously parentheses are for grouping
<micahjohnston>
but like
<micahjohnston>
the thing about (((a)))
<micahjohnston>
and ()
<micahjohnston>
and shit
<micahjohnston>
is not fun
<ELLIOTTCABLE>
hm
<ELLIOTTCABLE>
hm
<ELLIOTTCABLE>
here's a radical thought for you:
<ELLIOTTCABLE>
[]
<ELLIOTTCABLE>
[[[a]]]
<ELLIOTTCABLE>
;)
<micahjohnston>
lolol
<purr>
lolol
<ELLIOTTCABLE>
nobutreally
<ELLIOTTCABLE>
I'm in this discussion to change the syntax. Sure. But I'm actually not being facetious here.
<ELLIOTTCABLE>
replacing all the parens with brackets would make the raw code look less lisp-y, and imply JavaScript/Ruby-style indexing (which is sort of what it is)
<ELLIOTTCABLE>
and if you've written Ruby, and are familiar with the dynamic lookup redirection, then they can *also* look like function-calls to you, sort of
<jesusabdullah>
ELLIOTTCABLE: jthon
<micahjohnston>
hm i kind of want improvement on a deeper level than that
<ELLIOTTCABLE>
which does a good job of implying what [] actually does
<ELLIOTTCABLE>
oh, sure
<jesusabdullah>
ELLIOTTCABLE: a lisp that's JSON-compliant
<ELLIOTTCABLE>
I'm happy to talk about more
<ELLIOTTCABLE>
but how about, here and now, () -> []?
<jesusabdullah>
ELLIOTTCABLE: everyone would hate it
<ELLIOTTCABLE>
I see no drawbacks, and plenty of advantages.
<micahjohnston>
yeah I think we should stick with ()
<ELLIOTTCABLE>
“real-world code”, or as close as we're going to get right now
<ELLIOTTCABLE>
now, mind you, I don't want to optimize my damn language based on a single example that got pulled out of my ass.
<ELLIOTTCABLE>
but we can draw *some* conclusions from that.
<ELLIOTTCABLE>
it's also important to differentiate shit that's “only hard because there's no IPP yet” and shit that's *actually abstruse*
<ELLIOTTCABLE>
I think you're obviously right about statements.
<ELLIOTTCABLE>
let's assume that's happening, for now.
<ELLIOTTCABLE>
as for foo[] implying the passing of self, that seems like an *excellent* hack, to me. I feel like, although it's non-intuitive to people whose minds area already couched in other languages, it's *very* intuitive, inherently
<ELLIOTTCABLE>
in Paws, other people need you, to do many useful things. If you're not passing them something specific, then the most useful thing to pass them, *is you*.
<ELLIOTTCABLE>
right/wrong? refute?
<ELLIOTTCABLE>
ugh. yeah. I think I need to implement some sort of half-arsed IPP just to *talk* about some of these subjects.
<vil>
-clouds
<purr>
vil: is stuck up in the clouds; hilight 'em if you want 'em.
<vil>
hi guys
<vil>
I concur with square brackets, it's not nearly that big of a problem.
<vil>
I'm also used to Obj-C, though
<ELLIOTTCABLE>
I think it's straight-up just what I want out of the syntax.
<ELLIOTTCABLE>
To me, typability is a big deal. Location on QWERTY and Dvorak matter to me.
<ELLIOTTCABLE>
hence the unusual dot.case … and brackets are fairly in-line with that.
<vil>
also I agree with wanting someone to manage me, I would be so much more productive with set deadlines
<vil>
(reading a bit out of order here)
<vil>
-ground
<purr>
vil: is no longer stuck up in the clouds.
<ELLIOTTCABLE>
lol
<purr>
lol
<ELLIOTTCABLE>
vil: hey. clone Paws.js, and code. 'k? 'k.
<ELLIOTTCABLE>
I know micahjohnston will, if he's bored enough, and he's productive, so I don't have to push him; so I'll push you instead. :D
<vil>
fair warning that I just started a new semester so time will be limited
<vil>
I don't feel too bad because he also retweeted mine
<ELLIOTTCABLE>
I saw
<micahjohnston>
sorry girl visited room
<micahjohnston>
took priority
<joelteon>
gay
<micahjohnston>
ya
<micahjohnston>
vil: haha
<micahjohnston>
ELLIOTTCABLE: i like some kind of special syntax for self
<micahjohnston>
like @ or some shit
<micahjohnston>
like, this is drastic rehaul and maybe bad
<joelteon>
haha nerd
<micahjohnston>
but i kind of don't like the difference between a (b) and a b
<micahjohnston>
joelteon: ya
<micahjohnston>
so like maybe get rid of that
<joelteon>
what are you talking about anyway
<micahjohnston>
joelteon: paws
<ELLIOTTCABLE>
splain
<micahjohnston>
the reason this channel exists
<micahjohnston>
like
<joelteon>
oh
<micahjohnston>
in haskell and k and stuff
<micahjohnston>
you just do
<micahjohnston>
f x
<ELLIOTTCABLE>
joelteon: lol are you for real?
<purr>
lol
<joelteon>
yeah i like that
<micahjohnston>
and optionally f (x)
<joelteon>
i am real
<micahjohnston>
so i mean that doesn't mesh with our current design at all but
<micahjohnston>
but
<ELLIOTTCABLE>
hopping in the shower in a sec
<ELLIOTTCABLE>
but are you suggesting,
<ELLIOTTCABLE>
that *one* set of wrapping brackets be special-cased?
<ELLIOTTCABLE>
so “foo bar” and “foo [bar]” are identical, and you need “foo [[bar]]” to de-reference?
<ELLIOTTCABLE>
oh god, the wikipedia of it
<ELLIOTTCABLE>
or am I mis-hearing
<ELLIOTTCABLE>
hopping in shower, procuring food, making phone calls. I guess. Ugh. I like talking about Paws. I miss feeling productive.
<micahjohnston>
no that's not what i intend at all
<micahjohnston>
I want brackets to be idempotent/nilpotent
<ELLIOTTCABLE>
oh, just grouping
<ELLIOTTCABLE>
well, that defeats the entire design so far
<ELLIOTTCABLE>
indirection is a fundamental operation
<micahjohnston>
sure idk what the solution is
<ELLIOTTCABLE>
what would you have `foo [bar baz]` mean, in terms of preformed jux's?
<ELLIOTTCABLE>
just brainstorming here
<micahjohnston>
idfk
<micahjohnston>
hm
<ELLIOTTCABLE>
what does “grouping” even *mean*, in terms of Paws
<ELLIOTTCABLE>
in the context of*
<ELLIOTTCABLE>
hm
<ELLIOTTCABLE>
we could get rid of the implicit juxtaposition against locals
<ELLIOTTCABLE>
I mean, that'd break everything forever
<ELLIOTTCABLE>
but take it and run with it. what'd that give us.
<micahjohnston>
but then we could have
<micahjohnston>
atoms
<ELLIOTTCABLE>
`foo [bar]` is `foo :bar`
<micahjohnston>
no not that
<micahjohnston>
i mean
<ELLIOTTCABLE>
?
<micahjohnston>
like the lisp way you talk about atoms
<micahjohnston>
the leaves of the syntax
<micahjohnston>
asdf is an atom that evaluates to its value in the scope, and 3 is an atom that evaluates to itself
<micahjohnston>
or whatever
<micahjohnston>
yknow
<micahjohnston>
idfk
<micahjohnston>
idfk
<ELLIOTTCABLE>
re-reading that
<ELLIOTTCABLE>
so have different types of things, some of which evaluate to themselves, some of which imply indirection *in and of themselves*?
<ELLIOTTCABLE>
we could disconnect grouping and indirection, although I dislike that
<ELLIOTTCABLE>
let's say, colon for indirecting the next value
<micahjohnston>
nahnah
<micahjohnston>
oh yeah
<micahjohnston>
for names
<micahjohnston>
yeah
<ELLIOTTCABLE>
so old-world `foo (bar)` becomes `foo :bar`
<micahjohnston>
like ruby
<micahjohnston>
except
<micahjohnston>
it gets ugly in that case
<ELLIOTTCABLE>
and `foo (bar baz)` becomes `foo (:bar baz)`
<ELLIOTTCABLE>
yeah just an example
<ELLIOTTCABLE>
brainstorming here
<ELLIOTTCABLE>
not remotely interested in implementing this.
<micahjohnston>
aight yeah
<micahjohnston>
ughghghh
<ELLIOTTCABLE>
just, trying to run with your complaint about grouping being operational.
<ELLIOTTCABLE>
then you could also have `foo [bar]` that is a no-op, with `foo [:bar]` being the indirected version
<ELLIOTTCABLE>
`"foo"["bar"]` and `"foo"[bar]`, respectively, in JS notation
<ELLIOTTCABLE>
then what does `foo [bar baz]` mean, sans colon? :x
<ELLIOTTCABLE>
hm
<ELLIOTTCABLE>
well, directly juxtaposing 'baz' to 'bar' which doesn't make a lot of sense in that context.
<ELLIOTTCABLE>
so, that's icky.
<ELLIOTTCABLE>
*but* the idea is sound.
<ELLIOTTCABLE>
I feel like multiple-colons for several indirections is much more understandable than multiple brackets, no?
<ELLIOTTCABLE>
`foo :::bar`
<ELLIOTTCABLE>
PHP-ish
<ELLIOTTCABLE>
and that leaves our old self-passing “function call” to go from `foo()` to `foo:`
<ELLIOTTCABLE>
just as an example
<ELLIOTTCABLE>
okay. tabling that.
<ELLIOTTCABLE>
any other ways we could fix brackets to be idempotent? I feel like anything else needs *sweeping* changes of how we design juxtaposition itself, so that indirection is unnecessary entirely.
<ELLIOTTCABLE>
brb shower.
<micahjohnston>
aight brb lunch
<whitequark>
ELLIOTTCABLE: (audy) don't think so
<whitequark>
also wow paws
<ELLIOTTCABLE>
whitequark: ?
<ELLIOTTCABLE>
I briefly considered using a single-period token as self-reference
<ELLIOTTCABLE>
But I dislike the feel of func[.][abc][123] comparatively
<vil>
how about ~?
<ELLIOTTCABLE>
I genuinely feel that func[][abc][123] is intelligent, elegant, and intuitive.
<vil>
kind of like "home"
<ELLIOTTCABLE>
That is, once you understand what paws is doing *at all*.
<ELLIOTTCABLE>
(IRCcloud for iPhone is just about the best thing that's ever happened to the universe.)
yorick has quit [Remote host closed the connection]
<ELLIOTTCABLE>
Potbelly sandwiches,
<ELLIOTTCABLE>
get in me.
<ELLIOTTCABLE>
I want to just arrange a sit-down with this city.
<ELLIOTTCABLE>
“Hey. Chicago. Things are going well, between us. I'll even go as far as saying better than I'd hoped for.”
<ELLIOTTCABLE>
“But honey.”
<ELLIOTTCABLE>
“This heat? It's gotta stop.”
<ELLIOTTCABLE>
“I have limits, okay? And you're crossing *all* of them.”
<alexgordon>
hi ELLIOTTCABLE
<ELLIOTTCABLE>
alexgordon: hi, alex
<vil>
ELLIOTTCABLE: don't worry, it's about to get very cold
<ELLIOTTCABLE>
vil: *that* I can handle.
<vil>
yep
<vil>
same
<vil>
I love winter
<ELLIOTTCABLE>
IRCcloud on my iPad. Wonderful.
<ELLIOTTCABLE>
So, paws? alexgordon, micahjohnston, vil?
<alexgordon>
ELLIOTTCABLE: sure
<ELLIOTTCABLE>
Alex: Today, we're talking syntax.
<ELLIOTTCABLE>
It's a good time to revise.
<ELLIOTTCABLE>
So, let's hear your vicious opinions, unleashed.
<alexgordon>
YAY BIKESHEDDING
<ELLIOTTCABLE>
Exactly.
<ELLIOTTCABLE>
It's something *everyone* has an opinion on, and feels qualified to argue about.
<ELLIOTTCABLE>
Thus, I've always categorically shut down any discussion on that topic.
<ELLIOTTCABLE>
“Bike-weeding.” Giving the *important*, but timid/unqualified ideas space to flourish.
<ELLIOTTCABLE>
Now's a good time to poke through the weeds. Yah?
<whitequark>
no, screw syntax
<whitequark>
just do *anything*
<ELLIOTTCABLE>
Overall theme here is “cPaws is a bit of a Turing tarpit. Let's fix that.„
<ELLIOTTCABLE>
Go.
<joelteon>
i need a jacket
<alexgordon>
ELLIOTTCABLE: you never finished explaining how it works
<alexgordon>
so I can't possibly talk about syntax
<ELLIOTTCABLE>
whitequark: generally, agreed. Specifically relenting here, though. Just for a day. Can't hurt.
<whitequark>
ELLIOTTCABLE: what I try to say is a bit more constructive
<whitequark>
think about how you would want to use cPaws; then allocate *arbitrary* short character sequences to those usage patterns.
<whitequark>
this requires no discussion and is quick.
<whitequark>
bonus points if it looks like $language_you_already_like.
<ELLIOTTCABLE>
alexgordon: huh?
<ELLIOTTCABLE>
I disagree heavily there. I think the developer experience with the keyboard, with his typeface, is a thousand times more important than choice of GC algorithm or even of object model.
<ELLIOTTCABLE>
DX matters, nothing else does, except where it intersects that. Andy the vanguard of a developer's entire experience is sitting down with the text editor.
<ELLIOTTCABLE>
I don't, honestly, care too much about syntax. But that's a personal preference; I still believe it to be of *utmost* importance; and I almost wish I had a little more patience with caring about it.
<whitequark>
alexgordon's right: the only thing syntax needs to do is to map well to semantics
<alexgordon>
OMG
<alexgordon>
whitequark said I'm right
<ELLIOTTCABLE>
That's a bit like saying “code just needs to map efficiently to machine operations.”
<whitequark>
ELLIOTTCABLE: for a systems language, that is simply true.
<ELLIOTTCABLE>
First off, it's wrong, that's not remotely “just” what it has to do;
<ELLIOTTCABLE>
and second, it *massively* simplifies a very complex and important topic, and implies it shouldn't be discussed in detail.
<alexgordon>
ELLIOTTCABLE: I'm saying, I can't talk about syntax until I understand the semantics
<ELLIOTTCABLE>
Brb. Walking home. Probably doing things with girlfriend, but should be in and out a bit.
<whitequark>
ELLIOTTCABLE: think about it: when you're writing code, your main goal is not to produce something beautiful. you want to produce something a) that works and you can efficiently reason about (this concerns almost entirely semantics), b) that your colleagues can efficiently reason about (this concerns the mapping between syntax and semantics)
<alexgordon>
whitequark: beauty helps if you want the language to gain traction though
<whitequark>
well, you could also want to have an appeal to existing groups of developers, i.e. like Java did, but that's an entirely different matter and it's not really about language design, more about preexisting constraints
<whitequark>
alexgordon: beauty is very subjective
<whitequark>
there are a few things about syntax which can be discussed rather well, e.g. lexical scope
<whitequark>
arguably they're on the intersection between syntax and semantics (think about RAII and the like for the lexical scope example)
<micahjohnston>
whitequark: it's not simply true for systems langauges
<whitequark>
micahjohnston: elaborate?
<micahjohnston>
whitequark: for instance C doesn't map very well to asm anymore, and asm doesn't map very well to the underlying processor anymore
<micahjohnston>
so you don't want to just map as exactly as possible
<whitequark>
well, C isn't a good systems language imo
<micahjohnston>
you want to abstract while giving the tools to have precise control
<whitequark>
perhaps it was, on PDP-11
<whitequark>
but the thing you said about asm is weird
<whitequark>
and I believe just wrong
<whitequark>
prove it?
<vil>
can I just say that, as the most average programmer in this room, syntax is extremely important
<whitequark>
or did you mean that abstract microarchitecture of modern processors is in huge disagreement with actual microarchitecture?
<ELLIOTTCABLE>
<3
<micahjohnston>
whitequark: pipelining
<micahjohnston>
nuff said
<vil>
the whole fucking point of abstracting things into languages is so that we don't have to think exactly like the fucking computer
<vil>
if syntax was unimportant, we'd be writing binary
<whitequark>
vil: you're missing it
<whitequark>
the point of abstracting things is to enable more efficient, and more local (which is more or less the same) reasoning about the code
<vil>
and if I'm distracted by awful syntax, that's not going to happen
<whitequark>
more efficient for *humans* (not only humans)
<whitequark>
micahjohnston: VLIWs are sort of a failure, think about it
<whitequark>
I'm convinced this another layer of abstraction between opcodes and specific underlying silicon is very beneficial
<whitequark>
besides, 1:1 mapping was not at all what I meant. you just need it to be predictable and local
<micahjohnston>
sure, I just mean C and asm are neither of those in some cases
<whitequark>
neither of what?
<whitequark>
vil: you've missed my second point tho. I'm not saying syntax is unimportant. I'm saying syntax should map to the semantics of the language, which you hopefully design so that it's convenient for you to think about
<vil>
correct, which means that picking arbitrary crap without giving it any overall thought is a Bad Idea™
<vil>
I'm all for the syntax fitting the language, obviously
<vil>
but the syntax should also be a cohesive thing in and of itself
<whitequark>
eh
<vil>
humans don't always think in the most efficient way, even if that's the point of syntax
<vil>
anything you can do to help is good
<whitequark>
where did I say it should not be cohesive?
<whitequark>
you better have sensible and simple semantics, and if you make your syntax so that it maps well to that... you're bound to get cohesive syntax?
<whitequark>
in other words, things to discuss: "should the language have lexical scope?"
<whitequark>
things to not discuss: "should the language use [] or () in method calls?"
<vil>
but that's something that you do need to discuss with other people, because other people are going to be using it
<vil>
and each element of the syntax has an effect on all the others
<whitequark>
you know what people will tell you? "it's not like $my_favorite_language, therefore it sucks"
<whitequark>
I've had that conversation countless times, it's always the same.
<vil>
so if you're putting a lot of effort into a language, you should put similar effort into making sure it's usable
<vil>
true, but that's a separate problem
<whitequark>
do what people want, but don't do what they *say* they want.
micahjohnston is now known as cuttle
<whitequark>
because they have no fucking clue.
<vil>
the solution to that is to pick better people to discuss with ;)
<vil>
that's why we're in here
<ELLIOTTCABLE>
Micah is now a fish.
<vil>
yep
<whitequark>
ELLIOTTCABLE: *that*s what you reply to the wall of text?
<ELLIOTTCABLE>
This conversation has therein reached its logical conclusion.
<whitequark>
meh.
<vil>
ELLIOTTCABLE++
<purr>
Let it be known that vil loves ELLIOTTCABLE.
<ELLIOTTCABLE>
Walking.
<cuttle>
y does @taken
<cuttle>
@cuttle taken*
<cuttle>
i mean
<cuttle>
:(
cuttle is now known as mrcuttle
mrcuttle is now known as rcuttle
rcuttle is now known as drcuttle
drcuttle is now known as cuttle
<ELLIOTTCABLE>
cuttle: lolwat
<purr>
lolwat
<ELLIOTTCABLE>
Sorry, accidentally got laid.
<cuttle>
ELLIOTTCABLE: switched so I could nickserv group em
<cuttle>
lol fuckyou
<ELLIOTTCABLE>
Very distracting from syntax
<alexgordon>
ELLIOTTCABLE: ...
<ELLIOTTCABLE>
So, as was preparing to say, while reading all that and walking …
<alexgordon>
how does one "accidentally" get laid?
<whitequark>
ELLIOTTCABLE: if you were truly dedicated to programming languages
<whitequark>
you'd just flat out refused that.
<ELLIOTTCABLE>
Hm. Lemme get dried off, dressed, and sit down at keyboard
<cuttle>
alexgordon: so my idea is: make an frp language that is like J, and make /: and #: the temporal equivalents of / and #, so now +/: % #%
<cuttle>
alexgordon: i imagine being in a long term relationship helps
<alexgordon>
cuttle is micah?
<cuttle>
alexgordon: mistyped
<cuttle>
alexgordon: +/: % #:
<cuttle>
alexgordon: ya
<cuttle>
is running average
<cuttle>
over time
<alexgordon>
cuttle: dont you mean ¶•¡€§ª¡€ª•º
<whitequark>
cuttle: i imagine it's not very hard to accidentally get laid without any relationship either
<whitequark>
in fact, that would contribute to the surprise factor significantly
<cuttle>
whitequark: well it's a lot harder
<alexgordon>
cuttle: viagra can help with that
<alexgordon>
whitequark: you should listen to cuttle, he has like 4 girlfriends
* whitequark
casts a black stare at alexgordon
<whitequark>
*blank.
<whitequark>
I'm not sure what a black stare is.
<alexgordon>
whitequark: you're just jealous of cuttle's enlaidment skills
<cuttle>
lack of
<cuttle>
:
<alexgordon>
cuttle: YOU HAVE FOUR GIRLFRIENDS
<cuttle>
alexgordon: no i actually don't
<cuttle>
i have 0
<alexgordon>
NONSENSE
<alexgordon>
cuttle: aren't you at college?
<whitequark>
it's well known that in order to design a language you have to be a virgin
<cuttle>
alexgordon: yeah, and so far that fact hasn't helped much at getting me laid
<whitequark>
don't be ridiculous
<whitequark>
all of you
<alexgordon>
cuttle: isn't american college a non-stop sexfest?
<alexgordon>
I HAVE watched american pie, you know
<alexgordon>
you can't fool me with your lies
<alexgordon>
I know what it's like
<alexgordon>
cuttle: seriously no girlfriend?
<cuttle>
alexgordon: yeah
<alexgordon>
for shame
<cuttle>
had one from february to april
<cuttle>
made out once in july and apart from that had no success since then :p
<cuttle>
anyway we have zero contact now because i realized she's a fucking awful person
<cuttle>
and also she moved 2 hrs away
* alexgordon
laughed out loud and then felt bad
<cuttle>
lol
<purr>
lol
<cuttle>
-stop
<cuttle>
lol
<alexgordon>
cuttle: there there, it's okay. You have ELLIOTTCABLE to teach you his ways