ChanServ changed the topic of #elliottcable to: drugs
eligrey has joined #elliottcable
<purr> <whitequark> back in 80s or 90s though you had electronics that died if you looked angry at it.
sharkbot has quit [Remote host closed the connection]
sharkbot has joined #elliottcable
gozala has quit [Quit: Connection closed for inactivity]
alexgordon has quit [Quit: Textual IRC Client: www.textualapp.com]
<purr> <devyn> If I don't go now, all of my dream characters will escap
<purr> <sephr> the dom doesn't let me generate invalid xml
eligrey has quit [Quit: Leaving]
<whitequark> sooo I dropped my laptop
<whitequark> and killed the hinge mount
<whitequark> so I did this: http://i.imgur.com/hRcQI0z.jpg
<whitequark> drilled it with my CNC and put nice, thick, long screws through
<purr> <whitequark> I think purr is a bot ...
<whitequark> LOL
<purr> LOL
cloudhead has joined #elliottcable
PragCypher has joined #elliottcable
prophile has joined #elliottcable
Willox_ has quit [*.net *.split]
audy has quit [*.net *.split]
sammcd has quit [*.net *.split]
jesusabdullah has quit [*.net *.split]
irclogger_com has quit [*.net *.split]
inimino has quit [*.net *.split]
sammcd has joined #elliottcable
inimino has joined #elliottcable
Willox_ has joined #elliottcable
audy has joined #elliottcable
PragCypher has quit [Remote host closed the connection]
irclogger_com has joined #elliottcable
PragCypher has joined #elliottcable
PragCypher has quit [Client Quit]
jesusabdullah has joined #elliottcable
alexgordon has joined #elliottcable
<purr> <ec> and I was like … so you're going to build a non-Paws language, on top of non-Paws bits of a Paws?
<purr> <prophile> people find human cloning repulsive, why not identical twins
<prophile> thank you for that purr
yorick has joined #elliottcable
audy has quit [Changing host]
audy has joined #elliottcable
Determinist has joined #elliottcable
* Determinist moans
<whitequark> lol
<purr> lol
<Determinist> umm
<Determinist> have you guys tried atom.io?
* Determinist pokes alexgordon
eligrey has joined #elliottcable
eligrey has quit [Quit: Leaving]
<alexgordon> Determinist: hi
<alexgordon> Determinist: yes
prophile has quit [Quit: The Game]
<Determinist> alexgordon: impressions?
<alexgordon> Determinist: it's very young
<Determinist> alexgordon: looks pretty stable to me @0.7.5
<alexgordon> Determinist: I dunno I find it too annoying to use, too many little things are broken (like the home key)
<Determinist> alexgordon: i love the ability to customize pretty much everything
<alexgordon> I don't :P
<alexgordon> I hate customization
* alexgordon grumbles
<whitequark> Determinist: node.js
<whitequark> nuff said
<whitequark> and I mean, wtf, it's proprietary. if I have to use some proprietary crap, let it be sublime, it's in well-written C++
<Determinist> well, once i'm done customizing mine, i usually hate the extra options, but having the ablility to change the gutter font size, the indent guides colors, having loads of packages that can change the editor in meaningful ways
<Determinist> whitequark: having something written in C++ isn't all that, tbh.
<Determinist> whitequark: node should be plenty fast for a text editor
<alexgordon> Determinist: IMO an editor should come out of the box the way it's supposed to work
<alexgordon> customization is a crutch by software designers too lazy to do proper UI design
<alexgordon> I'm probably in the minority with that view though
<Determinist> alexgordon: or they realize that text editors are really a very personal thing to each developer. take a look at the old scool vim/emacs people
<Determinist> sec, daughter throwing a fit
<alexgordon> Determinist: some things are personal, most aren't
<alexgordon> e.g. vim has syntax coloring disabled by default. why? WHY
<Determinist> alexgordon: colors, sizes, which parts are needed by whom, etc.
<alexgordon> colors... sort of
<alexgordon> it's nice to have themes yeah
<alexgordon> but you don't need to be able to customize every color
<alexgordon> that should be automatic
<alexgordon> just set some base colors
<alexgordon> I don't want to customize "button top highlight"
<alexgordon> :P
<Determinist> alexgordon: several examples come to mind: customizing the file explorer, the overall theme, turning off stuff you don't need, installing stuff you do via an "npm" style system. where's the bad part here exactly?
<Determinist> performance? it'll improve with time
<alexgordon> Determinist: my problem comes when developers offload things to users
<alexgordon> first launch experience is important
<alexgordon> you should be able to jump in and start editing things, not have to do a bunch of setup and customization
<Determinist> more examples: changing the folding behavior in ST2 is a nightmware. I really like the textmate F1 behavior. just did that with atom in two mins. I also like the ESC key completion from Textmate, so i've changed atom's behavior to that.
<alexgordon> which vim really fails at, atom is better
<Determinist> alexgordon: that really depends on who your users are and what they expect.
<alexgordon> Determinist: no, not really
<Determinist> alexgordon: mind you, we're not talking about the average consumer application. this isn't an "app", it's a text editor
<alexgordon> Determinist: haha you haven't met some of my users ;)
<alexgordon> no but seriously, non-developers use text editors too
<alexgordon> lots of html coders do, for instance
<alexgordon> bloggers
<Determinist> alexgordon: this is what other editors are for, i suppose. this is meant as a VIM/textmate/ST competitor. not IA Writer's.
<alexgordon> but I disagree with the premise anyway that developers should expect a shoddy UI and have to fix it themselves
<Determinist> alexgordon: sure, assuming the UI is still shoddy at 1.0.0
<alexgordon> yeah...
<alexgordon> anyway I have more faith in github to figure these things out than vim
<Determinist> alexgordon: look, i'm not advocating for Atom here, i'm advocating for the right tool to the right user. I like configurable editors. I realize i'm not your average computer user, but then most users wouldn't look at Atom, they'd use a simpler alternative.
<Determinist> alexgordon: yes, definitely. the GH guys seem to be on the right side.
<alexgordon> I think you'd be surprised how many average computer users use text editors
<Determinist> alexgordon: that are not the default editor of their OS of choice?
<alexgordon> yeah
<Determinist> alexgordon: interesting. care to ellaborate?
<alexgordon> Determinist: hm well there's mathematicians who write latex, there's bloggers who write markdown, there's web drones that convert photoshop mockups into html markup :P
<Determinist> web drones :)
<alexgordon> none are programmers per se, although you might expect a greater than average computer proficiency
<Determinist> markdown - there are really good editors for. math - isn't there a tool for that? something that knows how to deal with latex?
<alexgordon> there are, but they suck :P
<Determinist> never needed one, so I don't know, tbh
<Determinist> i really don't get why people are knocking on atom being node based tho.
<Determinist> most people wouldn't know the difference if it wasn't mentioned
<alexgordon> *I'm* not, although I'm surprised it's even possible
<alexgordon> I've had to rewrite lots of objc code into C++ because it was too slow
<alexgordon> the fact they can do it with JS is kinda insane
<Determinist> alexgordon: why wouldn't it be? if you can use a bloated web page, why wouldn't a text editor be able to use the same presentation tools?
<alexgordon> Determinist: take the "go to file" window
<alexgordon> needs to index possibly tens of thousands of files
<alexgordon> then search through every one of them
<Determinist> alexgordon: actually, since I became aware of V8, i've redefined my notions of "possible" when it comes to JS
<Determinist> alexgordon: so they'll probably offload some of the heavy lifting to native modules.
<alexgordon> yeah but they don't seem to do that as much as I'd expect
<alexgordon> syntax highlighting is another big one, just impossible to do that in anything other than C++
<Determinist> alexgordon: give them time. these guys are not noobs. 'sides, if they don't do it, someone eventually will.
<alexgordon> I'm sure they must offload that
<Determinist> i'm honestly intruiged at what they're going to do re: performance
<alexgordon> rewrites, rewrites everywhere :P
<Determinist> probably :P
<Determinist> good software takes time
<Determinist> not sure why, but I've personally never found C++ to be an interesting language. I've written my share of code in it, just never actually liked it.
<Determinist> to me a non-C++ editor is a good thing
<Determinist> someone just needs to do a good "C++" without all of the crap
<Determinist> and no, Go doesn't count
<alexgordon> Determinist: FURROW
<Determinist> alexgordon: hm?
<alexgordon> Determinist: Furrow
<Determinist> alexgordon: Furrow to you to.
<Determinist> alexgordon: google doesn't know of a "Furrow"
<alexgordon> Determinist: it's my programming language
<Determinist> alexgordon: great, where?
<alexgordon> this IS a proglang channel, you know
<Determinist> yes, I vaguely remember paws
<alexgordon> Determinist: it's not finished and may never be https://github.com/fileability/furrow
<alexgordon> maybe when I'm ~80
<Determinist> alexgordon: i've always wanted to do something like that. why C++ tho and not something lower level like LLVM?
<Determinist> or even simpler: just C?
<alexgordon> Determinist: C++ is compatible with C, but C is not compatible with C++
<alexgordon> there's lots of good C++ libraries out there
<alexgordon> google does a lot of C++
<Determinist> alexgordon: I am aware of this, but C is simpler and simpler is usually better when you're debugging generated code
<Determinist> i should know. i was one of the guys who wrote ParticleCode (was sold to Appcellerator a couple of years ago)
<Determinist> long story short: translate AS3, Java or C# into ObjC, Java, C++, JS or C#
<alexgordon> O_O
<Determinist> with some limitations
<alexgordon> Determinist: haha anyway it's just for easy of implementation really
<alexgordon> I want to take advantage of C++'s RAII and move support
<Determinist> alexgordon: not worth it, if you ask me.
<alexgordon> it is worth it, if you ask me
<Determinist> alexgordon: ok, i'll bite. how so?
<alexgordon> I just said :P
<Determinist> :P
<alexgordon> oh also templates
<Determinist> i can see how that might be useful
<alexgordon> Determinist: basically furrow is medium syntactic sugar over C++, so if I compiled to C I would have to reimplement large amounts of C++
<Determinist> alexgordon: depending on which libraries you end up using or what kind of stdlib you're offering
<Determinist> s/or/and/
<alexgordon> I really want to implement everything
<Determinist> yeah, but then there's reality
<alexgordon> well it's easier if you generate C++
<alexgordon> since everything already exists for C++
<Determinist> which deps do you have? Boost?
<alexgordon> possibly parts of boost, I'll have to see
<Determinist> i'm not underestimating the value of the huge amount of great well tested C++ libs out there, but i'm worried about complexity. is the language GC or do you offer something smarter? ARC?
<alexgordon> Determinist: no GC
<alexgordon> it's RAII
<Determinist> alexgordon: might help if there was some kind of language ref somewhere :P
<alexgordon> let's see
* alexgordon waits for google
* Determinist blinks
<alexgordon> Determinist: this is maybe 18 months old and not very detailed but it's still valid I think: https://docs.google.com/document/d/1kgSzKcSTZGdxw8VJfupYolRAbAZ7JrqsJZXrz1t-hDo/edit?usp=docslist_api
<Determinist> this is like some kinda whacky python C++ hybrid
<alexgordon> Determinist :D
<alexgordon> exactly
<Determinist> not bad
<Determinist> ever felt like writing a coffeescript/javascript to C++ translator?
<alexgordon> Determinist: tag line is "The bastard child of lua and haskell"
<alexgordon> Determinist: WHY WOULD I DO THAT :P
<Determinist> alexgordon: might be awesome :P
<alexgordon> problem with JS is the GC
<alexgordon> turns everything into slow
<Determinist> alexgordon: sure. imagine tho: a system that allows you to write node C++ modules using JS :P
<alexgordon> Determinist: but my main goal with furrow really is just to make a language that I can implement a standard library in :P
<Determinist> and yes, i tend to agree: GC tends to become a mess if you're doing anything that actually requires a good amount of RAM and a long runtime (a server, basically)
<alexgordon> like the scheme philosophy - make a tiny language and then build a standard library to make it usable
<Determinist> alexgordon: that's a very sane approach
<alexgordon> yeah and web servers don't really need memory management anyway, since they don't have long-term state
<Determinist> well, i'd just be satisfied with a version of C++ that doesn't suck, is consistent and prevents all of the famous pitfalls
<alexgordon> that version of C++ almost exists, the only problems are all the legacy features, and also things like operator[] not being safe
<Determinist> that's the issue tho: it's always almost and you can't really ignore the legacy stuff if you're doing anything realistic
<alexgordon> exactly, what's needed is *drumroll* a fresh start
<Determinist> bingo
<Determinist> just use the subset of C++ that doesn't suck
<Determinist> and by that i mean translate into that
<Determinist> and offer a nicer cleaner syntax
<alexgordon> yeah but what about the libraries you link
<alexgordon> you've got to trust them
<Determinist> sure, but that applies regardless
<alexgordon> I dunno, in Java you can be fairly sure that if you link X library you won't get buffer overflows
<Determinist> sure, but then... you're using Java
<alexgordon> right
<alexgordon> that's my point
<alexgordon> in C++ you don't have that certainty, unless everybody uses a safe subset of C++ (which isn't very accessible anyway)
<Determinist> hence, a screwed up ecosystem
<Determinist> but eventually... you have to compromise
<Determinist> tbh, one of the things I like about node is the fact that it is consistent in the sense that Ruby isn't (if you've ever dealt with EM, you know what i'm talking about)
<Determinist> or C++ for that matter
<Determinist> it didn't reinvent JS, it just used it in a sane kinda way
<alexgordon> my favourite part of node is npm, it's really the only language that doesn't screw up package management
<Determinist> i completely agree
<alexgordon> python is just about getting there with virtual envs
<alexgordon> ruby is... miles behind :P
<Determinist> gems, pip (or whatever's the flavour in the python world these days), PEAR, CPAN... all broken and annoying
<Determinist> and don't get me started on C++ versioning and system versions and what not.
<Determinist> I once had to figure out a way to run a system (which I didn't write) on a modern linux distro after I've had to basically gut the whole thing to make it compatible with the libs that came with the more modern version of centos
<Determinist> I do not care to repeat that
<Determinist> the system was written for a 2.4 kernel era distro
<alexgordon> Determinist: that's one thing I want to nail with furrow, all packages have to be content-addressed, and it has to be able to handle internal vs external dependencies
<alexgordon> e.g. if you have a library that depends on another library, but doesn't expose that library in its external interface, then it should get its own copy of that library
<Determinist> alexgordon: that's not a simple goal.
<alexgordon> indeed but it's important
<Determinist> might end up with pretty beefy executables
<alexgordon> I'm ok with that! :P
<alexgordon> obviously if you have two versions of the same library which are the same, then you don't need two copies of them
<Determinist> alexgordon: you're a smart guy and i'm sure you've done your homework.
<alexgordon> but if a library is built to work with Foo version 2.4.5 then you shouldn't use it with Foo version 2.4.6 or 2.4.3
<Determinist> alexgordon: sure. how do you differentiate the two? a build setting?
<alexgordon> as long as it's an internal dependency
<alexgordon> Determinist: differentiate what?
<Determinist> alexgordon: which version is being used, especially if you're only using headers for certain things
<Determinist> erm, nm...
<Determinist> had a brain fart
<Determinist> scratch that
<alexgordon> like node really
<alexgordon> you have a node_modules folder with all your internal dependencies
<alexgordon> the compiler comes along and compiles the whole module
<Determinist> alexgordon: sure, but think about native modules which rely on system libs... example: the mongo native driver. unless i'm mistaken about that module's deps
<Determinist> brb, looking
<alexgordon> Determinist: I'm not really interested in that :P If it's impossible to make them into an internal dependency, then they would be external dependencies
<Determinist> does node have any of those tho?
<Determinist> aside from the built-in modules, that is
<alexgordon> node doesn't quite work the same because it doesn't have an explicit notion of "interface"
<alexgordon> in furrow each function is declared as either internal or external
<alexgordon> the external functions form the API of the module
<alexgordon> additionally all the types are known, so if you use something of type X and that's in another module, then that becomes an external dependency
<Determinist> i see
<Determinist> same translation unit rules, i'm assuming?
<alexgordon> Determinist: yeah I mean, I want to support incremental compilation
<alexgordon> Determinist: a "module" in furrow terms is a directory with many source files
<Determinist> why not one module per file?
<Determinist> module.exports style?
<alexgordon> I dislike that
<Determinist> why?
<alexgordon> because it means your module size is tied to your file size
<alexgordon> then people start to split a module into multiple modules simply because their file was getting too big
<Determinist> not really, if you're a semi decent programmer and know how to break down your modules correctly. not to mention the idea of dirs as modules with package.json/index.js/.coffee
<alexgordon> Determinist: I don't believe in "breaking down" modules
<Determinist> this isn't a problem you can solve at the language level. too ad-hoc.
<Determinist> or at least i think so
<alexgordon> large modules are better because they are simpler to reason about
<alexgordon> at least I find that to be the case
<Determinist> alexgordon: that would depend on the module and your definition of large
<alexgordon> a module should be as large as is necessary, it shouldn't be broken down into smaller pieces just-because
<alexgordon> e.g. Cocoa is only three modules: Foundation, AppKit and CoreData
<Determinist> one could argue that this isn't necessarily a good thing
<alexgordon> I don't see why not
<alexgordon> it's a good thing to me
<Determinist> let's contrast that with Node
<alexgordon> yeah I find in node the modules are too small
<alexgordon> you have all these little tiny things
<alexgordon> have to keep track of far too much
<Determinist> makes sense if you ask me. if you need something, you load it. i don't like the "get stuff wholesale" approach
<alexgordon> that kind of mentality is only helpful in languages that don't have Dead Code Elimination ;)
<whitequark> i.e. every single scripting language
<Determinist> and i like the fact that dirs can be modules in node and that you can hide loads of functionality behind a seamingly simple interface.
<alexgordon> Determinist: btw, I'm not talking about "namespaces", I'm talking about "modules"
<whitequark> or pretty much all languages without a proper module system, in fact
<whitequark> e.g. C++
<whitequark> ;D
<alexgordon> Determinist: each _file_ has its own namespace, and you can bring in other things via "import"
<alexgordon> Determinist: so you can import just a simple function from another module, you don't get the whole module
<Determinist> i get that
<Determinist> just basic C++ really
<alexgordon> Determinist: all files in a module get all other modules imported into their namespace
<alexgordon> but they don't *export* it
<Determinist> with some conventions
eligrey has joined #elliottcable
<alexgordon> e.g. if you write an internal function "foo" in FileA then it will also be available in FileB, but external users of the module won't see "foo" because it's internal
<alexgordon> you can do a lot of stuff with a compiler :)
<Determinist> sounds a bit like ruby
<Determinist> without the "everything's open" approach
<alexgordon> yeah
<alexgordon> Determinist: but anyway I really really believe that a directory is the correct granularity
<alexgordon> Determinist: e.g. I was writing the standard library yesterday, and I noticed the "gcd()" function was getting a bit long, so I moved it into another file
<alexgordon> gcd.fur
<alexgordon> but it's still part of the math module or whatever
<Determinist> the overheard of adding a bunch of require statements at the top of each file... i don't see that being a real problem, tbh.
<alexgordon> Determinist: not saying it is, like I said, require is all about namespaces, which is distinct from modules
<Determinist> right, i keep overlooking that.
<Determinist> sorry
<Determinist> not sure why, but this idea is just stuck in my head O.o
<alexgordon> haha
<alexgordon> require is a way to transfer part of one namespace into another, whereas a module is a receptacle for code
<Determinist> yes, of course, i *know* this (or at least i hope)
<alexgordon> actually, this is my other controversial gripe
<Determinist> coffee time, brb. it's been a long day :P
<alexgordon> I really hate submodules
<Determinist> oh, here we go
<Determinist> why?
<alexgordon> not git submodules, but modules inside a module
<Determinist> the equivalent of having a node_modules inside a module?
<alexgordon> Determinist: nah, that's dependencies
<alexgordon> well
<alexgordon> you could probably use that for sub modules
<alexgordon> Determinist: C# is the worst offender
<Determinist> java.lang.Foo
<Determinist> you'd rather just have a flat "Foo"
<Determinist> or am i still stuck with my issue from before?
<alexgordon> or java.Foo
<alexgordon> Determinist: System.Net.Http.Headers.AuthenticationHeaderValue
<Determinist> oh, jesus, yes
<alexgordon> why not Net.AuthenticationHeaderValue
<Determinist> C# and java are like siblings with retarded parents
<alexgordon> Determinist: actually haskell agrees with me
<alexgordon> they treat "." as part of the name
<Determinist> cute, but risky
<Determinist> i mean... not really risky, just error prone with a bunch of people already used to having submodules
<alexgordon> they use it more for tidiness
<alexgordon> e.g. if your module is about data structures you call it "Data.Blah"
<alexgordon> I like that
<Determinist> personally, the whole submodule thing is just being too anal with things. "where does this go? should it be a submodule?" you spend too much time with that shit
<alexgordon> yah
<Determinist> brb for real
<alexgordon> o7
<Determinist> i'm definitely down for no submodules
<purr> <Nuck> elliottcable fucks nothing but the best globes.
<nuck> indeed, purr
<Determinist> globes.......
<Determinist> do i even wanna know?
<nuck> I couldn't tell you context if I wanted to, Determinist
<Determinist> how will I survive? oh the humanity!
<Determinist> is google being slow today?
<Determinist> alexgordon: yo, what's a good up-to-date C++ book? It appears I need to freshen up
<alexgordon> Determinist: hm
<yorick> Madark: friend of mine says they might have done this so it's overall more accurate because they only do 6 degrees of taylor series
<alexgordon> Determinist: best way to learn C++ is to ignore all the C++ programmers :P
<alexgordon> Determinist: check out http://en.cppreference.com/w/
<yorick> wait, how did I end up here
<alexgordon> it has all the C++11 and C++14 stuff
<alexgordon> hi yorick
<alexgordon> Determinist: and read some code
<alexgordon> like llvm's code
<Determinist> alexgordon: minus the inconsistent crap from before? it's been several years since my last dance with C++
<alexgordon> Determinist: yeah, like pointers are out now :P
<Determinist> alexgordon: aha. much appreciated.
<Determinist> alexgordon: does C++ have unicode support for strings these days ala @"foo"?
<Determinist> nm, i'll google that shit
<yorickpeterse> alexgordon: hi
<Determinist> alexgordon: i wonder if dynamic languages can even do dead code elimination. taking JS as an example: given that almost always have weird ways to load/access certain things would make code elimination by static analysis pretty much impossible.
<Determinist> assume the sentence above has the correct spelling.
<Determinist> alexgordon: not to mention implicit globals (depending on the execution environment)
<alexgordon> Determinist: yeah, no they can't
<alexgordon> Determinist: to do dead code elimination you first need declarations
<alexgordon> which JS doesn't have
<Determinist> alexgordon: i'm sure google's closure is doing something smart there, the main problem is implicit globals, unless i'm missing something here
<alexgordon> Determinist: that and eval
<Determinist> alexgordon: sure.
<alexgordon> say you want to remove a function. to do that you need to make sure that nothing ever calls it
<Determinist> alexgordon: could be interesting if the use of eval and/or implicit globals can be disabled and if a common-js module system can be assumed, you could probably do it
<Determinist> strict mode should probably help too
Determinist has quit [Ping timeout: 246 seconds]
Determinist has joined #elliottcable
cloudhead has quit [Quit: Lost terminal]