<ELLIOTTCABLE>
katlogic: “Indeed that is the epitome of what is all wrong with C++.”
<ELLIOTTCABLE>
katlogic: how wso?
<ELLIOTTCABLE>
9:19 AM <+alexgordon> I included one boost header once and it added over a minute to my compile time
<ELLIOTTCABLE>
prophile, alexgordon. morning.
<prophile>
hey elliott
vil has quit [Ping timeout: 264 seconds]
<alexgordon>
hi ELLIOTTCABLE
<katlogic>
ELLIOTTCABLE: Using overly general primitives in systems language.
<katlogic>
I mean, thats cool in Java, JS or Ruby, but C++? Naaa.
<katlogic>
(Cue the usual joke of every second C program implementing its own hash tables)
<alexgordon>
it occurs to me that a language need only call malloc once per function, if that
<katlogic>
wat?
<alexgordon>
I KNOW IT SOUNDS CRAZY
<katlogic>
!!
<katlogic>
U MADMAN
<katlogic>
YOU DOING MALLOC EVERY FUNCTION CALL AND DOES NOT AFRAID OF ANYTHING
<katlogic>
Though to be fair: STL does the sensible thing. If vector is static sized, it will do the right thing.
<alexgordon>
katlogic: basically in C++ and all languages really, a lot of time is spend mallocating, and then freeing memory that only ever spans a one maybe two function calls
<alexgordon>
and that's patently absurd
<katlogic>
Rarely happens in properly written in C, though.
<katlogic>
(especially as there is not even working malloc sometimes)
<alexgordon>
ELLIOTTCABLE: why aren't you using python?
<ELLIOTTCABLE>
not a fan of python.
<ELLIOTTCABLE>
or, for that matter, of high-level programming languages for simple tasks.
<alexgordon>
ELLIOTTCABLE: what, bash is lower level than python? lol
<purr>
lol
<ELLIOTTCABLE>
Shell-script is a perfectly passable solution, a skill *every* programmer should engender, and is faster, lighter, and requires less of the user/collaborator/spelunker.
<ELLIOTTCABLE>
alexgordon: no, bash isn't a programming language.
<alexgordon>
ELLIOTTCABLE: erm, yes it is
<ELLIOTTCABLE>
I consider ‘scripts’ to be a different thing from ‘programs.’
<ELLIOTTCABLE>
Sure, you can write a file-server in bash, but that doesn't mean bash is *ideal* for that task;
<ELLIOTTCABLE>
and sure, you can write a five-line script in Python, but that doesn't mean Python is *ideal* for that task.
<alexgordon>
all scripting languages are programming language, a programming language is some turing complete system for executing computations (which bash is)
<ELLIOTTCABLE>
If I was writing simple tasks for my own use, then I'd probably use ruby. Easier, faster, etceteras.
<alexgordon>
ELLIOTTCABLE: dude get out of your head and try using python :P
<alexgordon>
it works better™
<alexgordon>
ok ruby then
<alexgordon>
anything but bash
<ELLIOTTCABLE>
But anything I'm sharing with anybody else? **Especially** additional tasks or meta-shit associated with a project *not* in Ruby (or Python, for you)? Hell no I'm not going to require the user to install or deal with python.
<ELLIOTTCABLE>
The “anything but bash” for a non-Ruby, non-Python, non-Perl projects, is the language itself; and usually, that language is not suited to such tasks.
<alexgordon>
it's so controlled
* ELLIOTTCABLE
sighs
<ELLIOTTCABLE>
Not having this argument.
<ELLIOTTCABLE>
for JavaScript projects, I will continue to write my relatively trivial tasks as POSIX-compatible shell scripts. I have good reasons, whether you'll listen to them or not.
<alexgordon>
I don't understand your reasoning
<ELLIOTTCABLE>
Have you ever installed a program, gone to modify the source, and discovered that you have to wrangle <insert other language's package installer here> just to run the tests, or just to compile the source?
<alexgordon>
one of python's main uses is as a scripting language for people making games
<alexgordon>
in C++
<ELLIOTTCABLE>
Canonically, CPAN or Perl, but if you're an actual perlista, that's not sufficiently scary-sounding.
<ELLIOTTCABLE>
you're missing my point.
<alexgordon>
just because you're using C++ doesn't mean you can't use python to automate your own tasks
<ELLIOTTCABLE>
I didn't say they're not *scripting langauges*. There's a break-down of language, here.
<alexgordon>
[22:36:30] <+ELLIOTTCABLE> Have you ever installed a program, gone to modify the source, and discovered that you have to wrangle <insert other language's package installer here> just to run the tests, or just to compile the source?
<alexgordon>
personally I'm much happier when I find the thing is held together by python scripts than by shell scripts
<ELLIOTTCABLE>
yes.
<ELLIOTTCABLE>
because you know python.
<alexgordon>
shell scripts = nobody fucking knows how it works
<ELLIOTTCABLE>
That's my fucking point.
<alexgordon>
ELLIOTTCABLE: even if it's held together by ruby, I'm happier
<alexgordon>
and I don't know ruby
<ELLIOTTCABLE>
What if it's held together by JavaScript scripts, targeting Grunt?
<ELLIOTTCABLE>
and you don't know any of those languages or toolsets?
<alexgordon>
I can work out ruby, with 10 minutes and a web browser. shell scripts are completely impossible whether you know how to write them or not
<ELLIOTTCABLE>
What if, to install it, you have to set up your system for npm? What if npm is hugely a pain in the ass to install and configure?
<alexgordon>
reading a shell script is like reading a regex
<ELLIOTTCABLE>
You don't *need* to read them. They're project-management shit.
<alexgordon>
ELLIOTTCABLE: ok but everybody has ruby and python installed, and if they don't, it's dead easy to do so
<ELLIOTTCABLE>
The user-experience of a shell script associated with a project is *not* its source-code; they are rarely, if ever, modified. The user-experience is the effort required for a new contributor to start contributing.
<ELLIOTTCABLE>
“everybody”
<ELLIOTTCABLE>
no[e.
<ELLIOTTCABLE>
nope.*
<ELLIOTTCABLE>
“dead easy”
<ELLIOTTCABLE>
nope.
<ELLIOTTCABLE>
*Especially* nope, lol.
<purr>
lol
<alexgordon>
... even if you're using windows there's a GUI installer for python
<ELLIOTTCABLE>
You say that because you know Python well. And you say that because you've dealt with Ruby before, and forgotten how hard it was the first time.
<ELLIOTTCABLE>
Oh, yes, because ease-of-use for a developer is having a GUI installer available! Clearly!
<ELLIOTTCABLE>
Python's a goddamn nightmare for somebody who doesn't know it.
<alexgordon>
well your shell scripts certainly aren't going to work on windows anyway ;)
<ELLIOTTCABLE>
Not as bad as CPAN, but … if I see a project, and wish to contribute or patch or fix a bug or even spelunk, I will goddamn walk away if the README says I have to run a python command to do so.
<ELLIOTTCABLE>
anyway. off to continue writing my robust, simple shell-scripts that don't require the user who's just git-cloned the project to install any further software to use them.
<alexgordon>
ok, I'll continue to think poorly of anybody still using fucking shell scripts in 2014
<ELLIOTTCABLE>
The friendliness to simple, shell-script based project-management frameworks/systems, is one of the only things I like about npm.
<ELLIOTTCABLE>
It gets this shit *right*.
<ELLIOTTCABLE>
“<tool> has no use-case, and should universally be replaced by <bigger, more complex, and more multi-purpose tool> in all cases, forever!”
<ELLIOTTCABLE>
— C++ users
<alexgordon>
that would be FINE if shell scripts were any good
<alexgordon>
but you yourself admit that they suck
<ELLIOTTCABLE>
brb abandoning all of the tasks for which C, shell-scripts, non-WebSocket HTTP requests, and `nano` are useful for.
<ELLIOTTCABLE>
Huh? I never said they suck. I said writing them is a *huge* context-shift from working in any sort of programming-language.
<ELLIOTTCABLE>
Surprisingly, client-side-JavaScript–to–shell-script is probably the least context-shift possible. Writing either is primarily an effort of compatibility.
<ELLIOTTCABLE>
glowcoil: darp
glowcoil has quit [Remote host closed the connection]
glowcoil_ has quit [Read error: Connection reset by peer]
<ELLIOTTCABLE>
ಠ_ಠ
Rusky has quit [Quit: Leaving.]
Rusky has joined #elliottcable
manveru has joined #elliottcable
<manveru>
yorickpeterse: yo :)
<ELLIOTTCABLE>
manveru!
<fwg>
<+ELLIOTTCABLE> Surprisingly, client-side-JavaScript–to–shell-script is probably the least context-shift possible. <<< you cannot be serious!
<fwg>
shell script is arcane black magic
<manveru>
i just wanted to say the same about js :)
<manveru>
then again, they are pretty much around the same wtf/m
<fwg>
haha
<manveru>
anw, off to bed, nice to see you again
<ELLIOTTCABLE>
manveru: sleep well
<ELLIOTTCABLE>
manveru: lurk moar <3
<ELLIOTTCABLE>
5:20 PM <manveru> then again, they are pretty much around the same wtf/m
<ELLIOTTCABLE>
fwg: but seriously!
<ELLIOTTCABLE>
most of the wtf's in shell-scripting are either A) forgetting the basic nuts-n-bolts abstraction of shell scripts, which is STRINGS R EVERYTHAN', or B) writing crap scripts that stop working as soon as you try to run them on another system.
<ELLIOTTCABLE>
which pretty much describes most non-experts' woes with JavaScript: A) not properly understanding prototypal inheritance or coercion, coming from Ruby or Java or whatever; and B) writing bad JS that stops working as soon as somebody accesses it with a two-year-old version of their browser.
<katlogic>
When people complain about JS being arcane ball of hacks, unix shell is indeed vicious retort.
<katlogic>
(It is interesting to learn history of unix shell since early 80s)
<fwg>
ELLIOTTCABLE: so you are saying that because you are constantly shooting your left foot, you should definitely start shooting your right as well, because the new pain will only need so little context shift?
<katlogic>
Then again, prototypes as done in JS is something horrid. Schoolbook example how to not clone smalltalk / self.
<fwg>
__proto__ to the rescue :/
<katlogic>
yay for Object.create (not!)
<ELLIOTTCABLE>
5:34 PM <fwg> ELLIOTTCABLE: so you are saying that because you are constantly shooting your left foot, you should definitely start shooting your right as well, because the new pain will only need so little context shift?
<ELLIOTTCABLE>
not at all.
<ELLIOTTCABLE>
Just saying that being shot in the right foot is the most similar pain to having been shot in the left foot.
<ELLIOTTCABLE>
:P
<ELLIOTTCABLE>
Statement of situational fact, not suggestion.
<katlogic>
Dunno how JS is even remotely related to unix philosophy tho.
<katlogic>
Since only existing ecosystem for JS is Node, and async stuff is awkward fit for unixish everything-is-file / pipes.
<katlogic>
(perl or python come closer simply by being pipe friendly and having vast array of libraries too)
<fwg>
ELLIOTTCABLE: what about just bundling your dependencies... then future contributors/users won't have to set things up via <package management>
<fwg>
npm for example has the awesome shrinkwrap command
<fwg>
ELLIOTTCABLE: that's the main pain point you are having against a more fancy language instead of shell scripts, right?
<ELLIOTTCABLE>
hm, not exactly
<ELLIOTTCABLE>
it's *mostly* (let's say 80%) installation,
<ELLIOTTCABLE>
but also somewhat spelunking.
<fwg>
I had to look up that word. please elaborate :)
<ELLIOTTCABLE>
as alexgordon insists, yes, reading a shell-script as a spelunker is way more obstruse than reading equally-carefully-written Ruby (i.e. I can make a Ruby script much more spelunker-friendly than I can a shell-script, with the same amount of effort)
<ELLIOTTCABLE>
*but*, reading <arbitrary language I don't know anything about> is, in my estimation, *even worse than reading shell-script*. No matter how well-written the arbitrary-language source is.
<ELLIOTTCABLE>
So, the pervasive knowledge of the command-line makes anything written in similar language very attractive.
<alexgordon>
ELLIOTTCABLE: rut
<alexgordon>
ELLIOTTCABLE: most languages are extremely similar, if you know one you know them all
<ELLIOTTCABLE>
Disagree immensely.
<alexgordon>
I don't do much java, but I can work out what java does
<ELLIOTTCABLE>
They're *similar*, but not *similarly easy to read*.
<alexgordon>
I don't know much ruby but I can work out what ruby does
<ELLIOTTCABLE>
Too much boilerplate, syntax, and NIH involved with any language community for that to be remotely true.
<alexgordon>
shell scripts.. no fucking clue
<katlogic>
ELLIOTTCABLE: Case in point: TCL
<ELLIOTTCABLE>
sure, 'cuz Ruby is easy. And Ruby would definitely be my second choice behind shell-scripts for such a task.
<katlogic>
We can all agree how well that fared
<ELLIOTTCABLE>
But Perl? or Python? or Java? Fuckno.
<katlogic>
(not exactly well)
<ELLIOTTCABLE>
katlogic: I actually haven't the slightest clue what tcl/t<whateveritwas> are.
<katlogic>
TCL was supposed this shell-ng
<ELLIOTTCABLE>
I hear the terms occasionally, but it's like GNU shit to me: some strangely insular community, involving a project that's irrelevant to the real-world as far as I can tell.
<katlogic>
Nah, you're too closed in your hipster Ruby/JS bubble. TCL was pretty popular in early 90s. Then perl came along.
* ELLIOTTCABLE
nods
<ELLIOTTCABLE>
that was long before my time, so like I said, I know little about it.
<ELLIOTTCABLE>
(interesting that you say that; whitequark likes to accuse me of almost exactly the same thing.)
<katlogic>
Likewise my arguing with archeology does not hold much water in this day and age.
<ELLIOTTCABLE>
wat
<fwg>
perl is actually kind of nice, I have found. if you get past the access qualifiers $%@
<alexgordon>
ewww
<ELLIOTTCABLE>
fwg: I don't dislike the language as many do.
<ELLIOTTCABLE>
I just think it's a motherfucking terrible choice for writing scripts that anybody else, anywhere, will ever see.
<katlogic>
Perl will eventually die. I'm really afraid JS is where stuff will be at. You know, lowest common denominator sort of stuff.
<alexgordon>
perl is like a good shit
<fwg>
hahahaha
<ELLIOTTCABLE>
katlogic: I love JS, and I'm totally pro-that-outcome.
<alexgordon>
it's been flushed ages ago but the smell still hangs around
<ELLIOTTCABLE>
alexgordon: “perl is like a good shit. it's been flushed ages ago but the smell still hangs around.” wat.
<purr>
beep.
<katlogic>
ELLIOTTCABLE: As far as scheme-family go, JS is freaking trainwreck.
<ELLIOTTCABLE>
scheme-family?
<katlogic>
But it is still scheme-family, so better than nothing.
<katlogic>
You haven't noticed? :)
<ELLIOTTCABLE>
since when is JavaScript a lisp-family language?
<katlogic>
Not syntactically, but semantically.
<ELLIOTTCABLE>
can-be-used-functionally, sure. That's about the only connection I see.
<alexgordon>
I actually prefer PHP to perl, that's how bad perl is
<ELLIOTTCABLE>
I care little about semantics; I'm asking how you see that connection in terms of semantics :P
<ELLIOTTCABLE>
if perl is a good shit, then PHP is a bad shit.
<fwg>
if only JS were more like Scheme
<ELLIOTTCABLE>
also, my OS X consistently auto-corrects PHP to Php. ಠ_ಠ
<ELLIOTTCABLE>
katlogic: genuinely curious! elaborate at me!
<katlogic>
ELLIOTTCABLE: Anything with proper not-so-broken scoping semantics is basically scheme in my book.
<alexgordon>
fuuuuuuu this function is 75% comments and 25% actual code
<katlogic>
Unfortunately many modern languages broke that shit horribly.
<ELLIOTTCABLE>
Interesting.
<katlogic>
Whereas ES6 goes the right direction with let
<katlogic>
(ie made it block level as it should be)
<ELLIOTTCABLE>
We have a particular brain-abstraction we throw around in here to describe the programming environment we live in, called “oases”
<fwg>
finally
<ELLIOTTCABLE>
so I parsed your scheme-family in those terms. But I see what you mean, in this case.
<ELLIOTTCABLE>
what's the argument for block-scoped variables?
<ELLIOTTCABLE>
I've always considered them fairly pointless. Enlighten me.
<fwg>
function scope is THE major wtf for JS IMO
<katlogic>
ELLIOTTCABLE: By scheme family as in, writing schemesque-language-to-js transpiler is not terribly difficult. Things map relatively easily. Try that with python.
<katlogic>
fwg: Unfortunately for python too.
<katlogic>
Can be workaround by having every block as lambda, but meh.
<katlogic>
Viva la let
<fwg>
haven't done a lot of python, that makes me not want to go there
<katlogic>
(ie got rid of _all_ vars and rewrote all functions to let name = function() the second ES6 let landed in V8)
<ELLIOTTCABLE>
fwg: … again, how so?
<katlogic>
fwg: problem with python is that you _cant_ easily nest functions like in js, so that workaround does not really work either
<fwg>
ELLIOTTCABLE: have you never fucked up your internal representation of what was going on in your JS by variable hoisting?
<katlogic>
so ... you're pretty much stuck with broken scoping in python
<ELLIOTTCABLE>
oh, *hoisting* is fucking terrible
<ELLIOTTCABLE>
but what's bad about not having *block*-local variables?
<fwg>
no, the problem is that ALL vars are not block-local, but instead function-scoped
<katlogic>
For one, assisting compiler so it does not have to make hoist guesses. Second, encapsulation.
<katlogic>
Like I accidentaly variable I set god-knows-where in deep scope
<ELLIOTTCABLE>
again, I don't see what's wrong with the variables' scoping; only with the fact of hoisting.
<ELLIOTTCABLE>
If you leave hoisting in, and add block-local variables, all you've managed to do is slightly tighten the scope in which your mind can become fucked, in some cases. Hoisting is still just as unintuitive to the user when it happens.
<katlogic>
ELLIOTTCABLE: The problem is simply vars from inner block magically appearing on upper levels and introducing bugs there.
<alexgordon>
yah
<ELLIOTTCABLE>
that's only a problem if the user is coming from a language with block-local variables.
<alexgordon>
that bites me in python all the time
<alexgordon>
ELLIOTTCABLE: no e.g. I'll set a variable in a loop but forget to initialize it before the loop
<ELLIOTTCABLE>
I don't see variables being local to arbitrary sub-units of code as being particularly intuitive; and if you don't have any preconceived notions of “this variable is specific to my for-loop!” from some other language, it's not remotely confusing.
<katlogic>
ELLIOTTCABLE: Well, uh, most sane languages have proper lexical scoping
<alexgordon>
then I get variables from the previous outer loop
<katlogic>
broken languages, like php, js or python dont
<katlogic>
easy as that
* katlogic
likes his little monochrome world
<katlogic>
not schemescque lexical scopes, you're out
<ELLIOTTCABLE>
In fact, I think it's *extremely* intuitive, and easing-to-the-mind of newcomers, for there to be exactly one sort of scope.
<ELLIOTTCABLE>
♪ Booty Swing, Parov Stelar
<purr>
ELLIOTTCABLE is listening to “Booty Swing”, by Parov Stelar
<katlogic>
ELLIOTTCABLE: Let me guess, it probes only grooveshark?
<ELLIOTTCABLE>
katlogic: have you written a Paws yet?
<ELLIOTTCABLE>
katlogic: yep
<alexgordon>
the idea of "educational languages" is just misplaced
<ELLIOTTCABLE>
tiny song has a nice API, but it's *by* the Grooveshark people
<katlogic>
I think you asked already, not Paws believer yet.
<ELLIOTTCABLE>
die alexgordon
* alexgordon
dies
<ELLIOTTCABLE>
katlogic: oh, expect me to ask a couple times a day. ;)
<ELLIOTTCABLE>
“Go write a paws” is my favourite salutation.
<ELLIOTTCABLE>
it's like an 80%-scheme; it's a trivial task.
<katlogic>
alexgordon: Anyway, the theory goes like: if you have infinite number of monkeys pounding JS away as npm modules, eventually something good comes up
<katlogic>
So the quest is to not educate quality coders, but get infinite monkeys
<alexgordon>
katlogic: hasn't happened yet
<katlogic>
For that, you need monkey-friendly language
* katlogic
thinks he is really offensive towards js now
<katlogic>
But thats where it is, it happened to Perl too
<katlogic>
PHP is perl for monkeys
<fwg>
then comes the network effect and you get shit swimming on the surface
<ELLIOTTCABLE>
man, you guys are so offensive to my sensibilities.
<ELLIOTTCABLE>
fuckin' programmers. :P
<alexgordon>
the only languages I've ever had fun using are
<alexgordon>
1. python, 2. haskell
<katlogic>
fwg: Indeed, you'll get immense ocean of monkey piss npm is now
<alexgordon>
the rest are shitebaskets
<katlogic>
fwg: But in there, occasionaly drop of water shows up
<fwg>
katlogic: it spans for miles and miles
<fwg>
oh god the freshwater has run out
<fwg>
James has started to gnaw on his toes
<alexgordon>
oh fuck oh fuck I'm sitting on a chair
<fwg>
I think I'll go mad if we don't see land in the next 7 days
<katlogic>
Anyways, I think this does not extend only to PL, but human cultures in general.
<katlogic>
Its the ultimate counter-elitist argument.
<fwg>
the monkey argument?
<katlogic>
Yup
<katlogic>
Breed monkeys, some will wise up.
<katlogic>
More monkeys, more wise monkeys.
<fwg>
simple statistics :)
<ELLIOTTCABLE>
er
<katlogic>
I think there is some factor of diminishing returns though
<ELLIOTTCABLE>
that's not counter-elitist, that's fuckin' extremely *elitist*.
<ELLIOTTCABLE>
ಠ_ಠ
<katlogic>
As number of monkeys increase, so does the backwards monkey culture.
<katlogic>
Useless memes proliferiate more and infect otherwise healthy monkey individuals.
<ELLIOTTCABLE>
I think I'm expanding the set of banned topics in this channel to “<x> group of people shouldn't be allowed to program.” Or anything else particularly exclusionary.
<katlogic>
ELLIOTTCABLE: Elitist would be to say: I am not a code monkey.