Opening discussion

[groundwater]

Shall we discuss our ideas?

[nvcexploder]

we shall!

[groundwater]

I would suggest we keep this process open, because that seems like the "nothing is sacred" approach

[brycebaril]

The main concept I have in mind for "Nothing Is Sacred" is the idea that reinvention and experimentation on "solved" problems should be healthy and encouraged, not shut down or shunned.

We should be willing to eschew or at least test/validate "best practices" and tear scaffolding down in order to rebuild something new.

One reason I brought @groundwater into this is his work around NodeOS and RuntimeJS -- these are fantastic examples of this concept.

I originally had the idea for this concept because of LevelDB, but I've also been working on some stuff around Date/Time.

Getting systemic changes from any of these ideas would be a crazy uphill battle, but even failures would help to highlight the things which are currently holding us back.

[max-mapper]

lets start a grassroots campaign to implement 64 bit integers in javascripts

[groundwater]

+1 on leveldb, databases are very "sacred" +1 on time/date stuff

I would also like to encourage people away from saying the existing situations are "stupid" or "bullshit" etc and just talk about how we're just standing on the shoulders of great work that came before us. For example, nodeos tries to replace linux user land, but wouldn't be possible without having come so far with other distros.

[brycebaril]

Yes +1 on keeping it positive.

[nvcexploder]

Are there specific environments that can help foster these types of ideas/projects?

[groundwater]

I would obviously like to talk about nodeos/runtime and why writing a kernel with javascript is tons of fun.

[ceejbot]

Reinventing wheels a) teaches you how wheels work and b) sometimes improves the wheel a whole lot. So nothing should be safe from being considered for reinvention.

[wraithan]

I'm in the process of building my own bike computer from random components on websites and some of my own ideas. This is considered a solved problem that you can't really compete with garmin or one of the others. But it is super fun to me and I hope to come out of it with a bunch of material for others who would like to also pave their own way.

I think that cooking could be a good example of how "solved" problems still warrant experimentation. Cookies are pretty solved, but there are so many types. And you can always add a new filling or try different base ingredients. There are out of the box solutions, and sometimes you start with those then deviate, other times you go from scratch and must first invent the universe.

[max-mapper]

half thought out rant: I would to disassociate myself with "node" and replace it with something that better represents the shared values that I have with the people I write and teach and learn software with. Mostly because of all of the corporate ownership of "node" that makes the community look bad, but also because the identity/branding of node today doesn't do much to explain to newbies what I think my corner of the community is about

[kamilogorek]

+1 @maxogden

[voodootikigod]

@maxogden there isnt enough <3z I can give to this.

[aredridel]

@jeffreykegler is all about nothing is sacred with parsers.

[junosuarez]

ahhhhh all of this stuff makes me very excited!

[ColemanGariety]

<3 @maxogden

[groundwater]

@maxogden I don't know what you have in mind, but browserify has really shown there is a place for the "module ecosystem" outside of node. This would be a fantastic presentation, because nothing is more sacred to node people than node itself.

[brycebaril]

Music (or art in general) has a more common practice of doing something like this, perhaps @substack or @obensource might be interested in helping us explore that.

@maxogden would it be taking it too far to say you're suggesting building a community around an ethos versus a technology? I could definitely get behind this concept.

[taterbase]

@brycebaril @maxogden I love the sound of that. It seems like a natural step forward. Building strong compassionate communities centered around a particular language/runtime can only serve to limit them (although node and javascript have definitely pushed those limits rather far).

[junosuarez]

I'm struck by a phrase from @jxson's cascadiajs talk - "ask for help, not for permission"

[ceejbot]

Package managers: npm is an example of a re-invented package manager that solved lots of the problems of earlier package managers. But npm isn't sacred! What does the next generation of package managers look like? Do they have to stick to one language or platform? Can we distribute the data so that no one site has to handle world-wide load? How do we trust we're getting the right bits if we do that? What are some other problems with npm's solution that we can solve with mad science in MetaPackageManager?

[ungoldman]

I would suggest taking a look at how the @maptime folks are going about building community -- focusing on being a positive and welcoming environment for beginners, avoiding jargon, defining terms, exploring ideas as a group. I like their guiding philosophy quite a bit.

[ceejbot]

Build systems: make is the one to use if you want to build complicated things & not want to defenestrate the build machine & everybody associated with it. Often. Make is vintage 1977. Everybody hates it. Everybody keeps trying to reinvent it, but doing a much, much worse job than make did. We all seem to want to express our dependencies in the hip language of the moment: XML (every java one ever), Ruby (rake), Coffeescript (cake, please), Javascript (jake, gulp), JSON (Grunt). Misery ensues.

Suppose we're going to reinvent Make and Get It Right, This Time For Sure(tm). What should we do? What is the build tool problem anyway?

[shama]

Conferences are not sacred: attending as an outsider / loneliness, cost, elitism, how much does one actually learn, originality, what could be better, etc. Opportunity for a meta talk to discuss how the current conference is doing, i.e: I wish @nvcexploder had more clothespins to keep the sheet from blowing about in the wind.

[imakewebthings]

+1 @shama. I'm interested in this as well as exploring alternate talk formats, feedback mechanisms, track structures, anything that may contribute to shaping the higher level concerns you've mentioned.

[othiym23]

How far can we take JavaScript itself? @briantford and I have both spent a lot of time pushing the limits of metaprogramming in JavaScript and have learned an inordinate amount about what can and can't be done with raw JavaScript as a result. How far can you get and how fast, even without transpilers, AST parsers, or macro systems? And how much further can we go when we add those into the mix?

[isaacs]

I would like to give a talk about code style in JavaScript.

I feel that I am uniquely fit to give this talk at this conference.

[isaacs]

As evidence of my unique qualifications in this regard, I present you with this: https://github.com/isaacs/http-duplex-client/commit/e71ae14

Note the red segments. (I did accept Mikeal's pull request, because the unsacredness of code style is not sacred.)

[gggritso]

In the spirit of re-building what's already there, what about a talk about framework-less JS? This is particularly relevant for front-end code, where framework choices are the Big Thing to spend time on thinking about, building, shouting, presenting at conferences, etc. For me personally, this ties into a million concepts:

• what real productivity does and doesn't look like in an organization
• why do we fear writing code and don't fear magic
• how much could we learn from not using a framework at all?
• could our code be better if it's made for our specific problem, instead of shoving it into someone else's structure

I'm thinking about this a lot lately because of something @brycebaril said on Twitter: "You start with a language that can do anything, then remove features from there by writing code."

[jxson]

@gggritso :+1: This is something near and dear to my heart, there should be more thought and talk about the problem space the tools (frameworks) serve rather than which specific tool to use.

[isaacs]

@gggritso Couldn't you say that a framework is just a language with a lot of features pre-removed for you?

[nvcexploder]

@gggritso that's how I felt for years in Java culture - everything shoe-horned into existing solutions even when they didn't suit (ESPECIALLY when they didn't suit).

I definitely think it's a good topic to broach, especially in regards to productivity, both personally and within an organization.

[gggritso]

@isaacs Absolutely! You're completely right, you could say that, and everyone is saying it. I'd love for someone to take a step back, out of this pool of pared-down languages and explore the whole landscape (JavaScript itself).

It's become rare for us to be in control of exactly what's removed for us, we just choose from one of many of these "languages" because ... well, I don't know why! Why do we, as an industry do that?

[gggritso]

As a sidenote, what about auth? Auth is so sacred that almost no one is allowed to touch it. It's the blackest box I know, and everyone is telling me to not even think about it.

[ceejbot]

Let's flip that viewpoint around! Writing code/apis/frameworks can be considered as "finding a DSL with which to express your problem". Once you have the dsl, you can implement the solution. Function/method names are verbs in your DSL. So you are not so much paring things away from your language as using it to build a very specific, purpose-focused sub-language. Writing things in languages like Lisp makes this DSL construction kinda obvious.

In other words, I find this topic a great one & heartily support its appearance at NISConf (tm)(patent pending).

[gggritso]

@ceejbot I love this take on it. It's more positive, and it's very functional and pragmatic while focusing on the heart of the topic.

[gggritso]

I don't mean to flood, but another small idea I had is Battle Stories from Boring Trenches. I think it would be fun to hear people talk for just 2-3 minutes about a funny little mundane problem they had in their day-to-day work and how it affected them. I have to admit that every now and again I'll waste an hour or two because I'm doing something fundamentally stupid. Examples: editing a compiled file instead of the source, using a library from a CDN but not setting the version to have it be pulled from under me and break everything. Each of these things caused a small change in how I work, and I would love to hear some of these itty horror stories from other people.

[thethp]

@gggritso Offered what I would think of first to: the idea of the frameworkless code. There are so many frameworks and more keep getting made.

The idea of something being finished or done in general is a concept that is confusing and confining in an industry where everything is always evolving. I feel like we consistently are told to move on to new frameworks that are being made with new problems instead of working with whatever exists or evolving whatever exists to work with new knowledge and information

[ceejbot]

The metric system is not sacred. Having only 2 and 5 as divisors for units is a bummer. Nobody actually cares whether they measure what they drive in miles or kilometers. Measurement systems are arbitrary at some level: let's admit this & design one for the future. Base 16? Or were the Babylonians right and 60 = 2^2 * 3 * 5 is the best human-centric choice?

[max-mapper]

Discussing programming languages as it relates to teaching and how easy things are to understand for learners is too intellectual. Syntax is a red herring and takes up the majority of the conversation. From a cognitive science standpoint (gentle introduction here) there are a lot of other factors that make something learnable.

E.g. because JS is everywhere, which causes it to have a high utility value, that you can translate that utility value into motivation to learn (sort of a learning ROI). In this sense JS is like English. Nobody speaks Esperanto/Lojban. Other factors include how many rabbit holes you get exposed to when googling an error message, how isolated you feel when learning something or how easy it is to find a mentor, how good the curriculum you are following is in getting you into a 'flow' state. Stop talking about syntax! ES6,7,8,9 won't make that much of a difference in making JS easier to learn compared to other more important things.

[max-mapper]

cooking shows are not sacred. why can they not be staffed entirely by javascript programmers and filmed in my kitchen?

[nvcexploder]

Why can't they be animated with stop motion and include fireworks?

On Sat, Aug 9, 2014 at 9:27 PM, Max Ogden notifications@github.com wrote:

cooking shows are not sacred. why can they not be staffed entirely by javascript programmers and filmed in my kitchen?

— Reply to this email directly or view it on GitHub https://github.com/nothingissacred/meatspace/issues/1#issuecomment-51705973 .

[junosuarez]

tacos. tacos are sacred.

[ungoldman]

tacos++

[operatorjen]

I just started this project (still WIP) which is a concept of allowing advanced and new programmers to create really basic service APIs that conform to a specific set of restrictions. The API call only accepts one input and sends out one output.

The services can be hosted on any server and written in any language, as long as the API is consistent. Users run a one-time token to generate a script that runs through 1-4 services to mutate their original input.

A description of it is on the revisit.link site

Currently there is only one service API I've added, but need to add more and the spec is still changing.

[Maciek416]

Max, your point from above (admittedly somewhat non-sequitur) reminds me of the sometimes snarling 10-minutes-of-hate discussions and debates around CoffeeScript, which I feel are such an unfortunate cultural artifact of language bigotry and developer sensitivity about personal choices. We can have better discussions about programming languages.

I thought CS was, if nothing else, a really fun exercise in restating the same thing in a different form so that we could learn something about the original thing. It's difficult to do this with English because foreign languages become unintelligible (though can usually express nearly identical if not downright identical thoughts), but learning German or French or Norwegian can illuminate some interesting aspects about English nonetheless. I won't make any claims about whether those languages help you learn English, however.

In the case of CS, it's literally the same language as JS with the same capabilities, and unlike the linguistics example above I'd argue alternate syntax has shown that for some people, restating the same thing as a slightly different uncanny valley bizarro-world form can reveal hidden things to some set of the audience, or make it easier to learn. Adding the kitchen sink of future-ESx may not solve any fundamental learning problems with the learning curve for people who are trying to step up onto the hello-world plateau, but who knows, alternate syntaxes for JS may reveal or illuminate learning paths.

Thought experiment. How ridiculously different can alternate forms (useful illuminating ones, I'm not talking about compiled machine code) get while being remaining more or less productively equivalent (or better)?

[max-mapper]

@Maciek416 good points all around. I don't think syntax is irrelevant, I just think it is perceived as ~10x more important than it actually is. It would be fun to have a debate thingy at nothing-is-sacred-conf about what makes things 'productively equivalent'.

[isaacs]

Tacos are practically the definition of not sacred. They're a foodstuff of expedience and modernity if ever there was one. They can be done artfully, yes, as neither expedience nor modernity require that food be lacking in art, but they are not some sacred tradition handed down from the ages. They didn't even exist 40 years ago, and they're continually changing.

[Maciek416]

As far as I can tell, the same is true of sushi. Tacoids in general (I consider sushi / maki / etc to be a tacoid) seem to be a relatively recent innovation.

[junosuarez]

request for talk: someone deconstruct the tacoid