Opening discussion #1

Open
groundwater opened this Issue Aug 6, 2014 · 67 comments

Comments

Projects
None yet
@groundwater

Shall we discuss our ideas?

@nvcexploder

This comment has been minimized.

Show comment
Hide comment

we shall!

@groundwater

This comment has been minimized.

Show comment
Hide comment
@groundwater

groundwater Aug 6, 2014

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

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

@brycebaril

This comment has been minimized.

Show comment
Hide comment
@brycebaril

brycebaril Aug 6, 2014

Member

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.

Member

brycebaril commented Aug 6, 2014

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.

@maxogden

This comment has been minimized.

Show comment
Hide comment
@maxogden

maxogden Aug 6, 2014

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

maxogden commented Aug 6, 2014

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

@groundwater

This comment has been minimized.

Show comment
Hide comment
@groundwater

groundwater Aug 6, 2014

+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.

+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

This comment has been minimized.

Show comment
Hide comment
@brycebaril

brycebaril Aug 6, 2014

Member

Yes +1 on keeping it positive.

Member

brycebaril commented Aug 6, 2014

Yes +1 on keeping it positive.

@nvcexploder

This comment has been minimized.

Show comment
Hide comment
@nvcexploder

nvcexploder Aug 6, 2014

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

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

@groundwater

This comment has been minimized.

Show comment
Hide comment
@groundwater

groundwater Aug 6, 2014

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

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

@ceejbot

This comment has been minimized.

Show comment
Hide comment
@ceejbot

ceejbot Aug 6, 2014

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.

ceejbot commented Aug 6, 2014

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

This comment has been minimized.

Show comment
Hide comment
@wraithan

wraithan Aug 6, 2014

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.

wraithan commented Aug 6, 2014

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.

@maxogden

This comment has been minimized.

Show comment
Hide comment
@maxogden

maxogden Aug 6, 2014

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

maxogden commented Aug 6, 2014

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

This comment has been minimized.

Show comment
Hide comment
@voodootikigod

This comment has been minimized.

Show comment
Hide comment
@voodootikigod

voodootikigod Aug 7, 2014

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

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

@aredridel

This comment has been minimized.

Show comment
Hide comment
@aredridel

aredridel Aug 7, 2014

@jeffreykegler is all about nothing is sacred with parsers.

@jeffreykegler is all about nothing is sacred with parsers.

@suarasaur

This comment has been minimized.

Show comment
Hide comment
@suarasaur

suarasaur Aug 7, 2014

ahhhhh all of this stuff makes me very excited!

ahhhhh all of this stuff makes me very excited!

@JacksonGariety

This comment has been minimized.

Show comment
Hide comment
@groundwater

This comment has been minimized.

Show comment
Hide comment
@groundwater

groundwater Aug 7, 2014

@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.

@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

This comment has been minimized.

Show comment
Hide comment
@brycebaril

brycebaril Aug 7, 2014

Member

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.

Member

brycebaril commented Aug 7, 2014

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

This comment has been minimized.

Show comment
Hide comment
@taterbase

taterbase Aug 7, 2014

@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).

@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).

@suarasaur

This comment has been minimized.

Show comment
Hide comment
@suarasaur

suarasaur Aug 7, 2014

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

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

@ceejbot

This comment has been minimized.

Show comment
Hide comment
@ceejbot

ceejbot Aug 7, 2014

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?

ceejbot commented Aug 7, 2014

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

This comment has been minimized.

Show comment
Hide comment
@ungoldman

ungoldman Aug 7, 2014

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.

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

This comment has been minimized.

Show comment
Hide comment
@ceejbot

ceejbot Aug 7, 2014

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?

ceejbot commented Aug 7, 2014

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

This comment has been minimized.

Show comment
Hide comment
@shama

shama Aug 7, 2014

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.

shama commented Aug 7, 2014

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

This comment has been minimized.

Show comment
Hide comment
@imakewebthings

imakewebthings Aug 7, 2014

+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.

+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

This comment has been minimized.

Show comment
Hide comment
@othiym23

othiym23 Aug 7, 2014

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?

othiym23 commented Aug 7, 2014

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

This comment has been minimized.

Show comment
Hide comment
@isaacs

isaacs Aug 8, 2014

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 commented Aug 8, 2014

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

This comment has been minimized.

Show comment
Hide comment
@isaacs

isaacs Aug 8, 2014

As evidence of my unique qualifications in this regard, I present you with this: isaacs/http-duplex-client@e71ae14

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

isaacs commented Aug 8, 2014

As evidence of my unique qualifications in this regard, I present you with this: isaacs/http-duplex-client@e71ae14

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

@gggritso

This comment has been minimized.

Show comment
Hide comment
@gggritso

gggritso Aug 8, 2014

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."

gggritso commented Aug 8, 2014

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

This comment has been minimized.

Show comment
Hide comment
@jxson

jxson Aug 8, 2014

@gggritso 👍 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.

jxson commented Aug 8, 2014

@gggritso 👍 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

This comment has been minimized.

Show comment
Hide comment
@isaacs

isaacs Aug 8, 2014

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

isaacs commented Aug 8, 2014

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

@nvcexploder

This comment has been minimized.

Show comment
Hide comment
@nvcexploder

nvcexploder Aug 8, 2014

@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 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

This comment has been minimized.

Show comment
Hide comment
@gggritso

gggritso Aug 8, 2014

@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 commented Aug 8, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@gggritso

gggritso Aug 8, 2014

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.

gggritso commented Aug 8, 2014

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

This comment has been minimized.

Show comment
Hide comment
@ceejbot

ceejbot Aug 8, 2014

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).

ceejbot commented Aug 8, 2014

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

This comment has been minimized.

Show comment
Hide comment
@gggritso

gggritso Aug 8, 2014

@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 commented Aug 8, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@gggritso

gggritso Aug 8, 2014

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.

gggritso commented Aug 8, 2014

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

This comment has been minimized.

Show comment
Hide comment
@thethp

thethp Aug 8, 2014

@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

thethp commented Aug 8, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@ceejbot

ceejbot Aug 9, 2014

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?

ceejbot commented Aug 9, 2014

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?

@maxogden

This comment has been minimized.

Show comment
Hide comment
@maxogden

maxogden Aug 10, 2014

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.

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.

@maxogden

This comment has been minimized.

Show comment
Hide comment
@maxogden

maxogden Aug 10, 2014

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

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

@nvcexploder

This comment has been minimized.

Show comment
Hide comment
@nvcexploder

nvcexploder Aug 10, 2014

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
#1 (comment)
.

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
#1 (comment)
.

@suarasaur

This comment has been minimized.

Show comment
Hide comment
@suarasaur

suarasaur Aug 11, 2014

tacos. tacos are sacred.

tacos. tacos are sacred.

@ungoldman

This comment has been minimized.

Show comment
Hide comment

tacos++

@ednapiranha

This comment has been minimized.

Show comment
Hide comment
@ednapiranha

ednapiranha Aug 11, 2014

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.

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

This comment has been minimized.

Show comment
Hide comment
@Maciek416

Maciek416 Aug 11, 2014

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, 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)?

@maxogden

This comment has been minimized.

Show comment
Hide comment
@maxogden

maxogden Aug 11, 2014

@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'.

@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

This comment has been minimized.

Show comment
Hide comment
@isaacs

isaacs Aug 11, 2014

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.

isaacs commented Aug 11, 2014

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

This comment has been minimized.

Show comment
Hide comment
@Maciek416

Maciek416 Aug 12, 2014

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.

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.

@suarasaur

This comment has been minimized.

Show comment
Hide comment
@suarasaur

suarasaur Aug 12, 2014

request for talk: someone deconstruct the tacoid

request for talk: someone deconstruct the tacoid

@gggritso

This comment has been minimized.

Show comment
Hide comment
@gggritso

gggritso Aug 12, 2014

This idea is a little more out there, but here goes.

What if browsers were a little dumber? We're at a point where Chrome is an operating system, and it's only getting more and more powerful. Is this good? What if we worked on other open and free technologies that aren't browsers? What would the world look like if the Skypes, MS Words, Photoshops and Doom 3s of the world weren't shoved into the browser? How would this affect developers and how would it impact the kinds of products we make, how we make them and what happens to them?

It's tempting to say that what I'm talking about is just the software ecosystem of five years ago, but I don't think that's true. What we do with the Internet as a whole is changing, not just the world wide web. They way we make anything is changing, not just websites.

This could be a far-reaching topic, since it will inevitably touch on developer culture, our priorities, our methodologies and both the progress and regression that happens as a result. Or it could be a bunch of navel-gazing.

I feel that the notion that we should do everything in the browser is perhaps not sacred, but taken as obvious. So, maybe we should challenge the obvious and play devil's advocate. If nothing else, maybe we can gain some clarify on how and why we got to where we are.

This idea is a little more out there, but here goes.

What if browsers were a little dumber? We're at a point where Chrome is an operating system, and it's only getting more and more powerful. Is this good? What if we worked on other open and free technologies that aren't browsers? What would the world look like if the Skypes, MS Words, Photoshops and Doom 3s of the world weren't shoved into the browser? How would this affect developers and how would it impact the kinds of products we make, how we make them and what happens to them?

It's tempting to say that what I'm talking about is just the software ecosystem of five years ago, but I don't think that's true. What we do with the Internet as a whole is changing, not just the world wide web. They way we make anything is changing, not just websites.

This could be a far-reaching topic, since it will inevitably touch on developer culture, our priorities, our methodologies and both the progress and regression that happens as a result. Or it could be a bunch of navel-gazing.

I feel that the notion that we should do everything in the browser is perhaps not sacred, but taken as obvious. So, maybe we should challenge the obvious and play devil's advocate. If nothing else, maybe we can gain some clarify on how and why we got to where we are.

@ceejbot

This comment has been minimized.

Show comment
Hide comment
@ceejbot

ceejbot Aug 12, 2014

@gggritso love that topic!

ceejbot commented Aug 12, 2014

@gggritso love that topic!

@iarna

This comment has been minimized.

Show comment
Hide comment
@iarna

iarna Aug 12, 2014

@maxogden Your point around learning motivation and utility is really important. My experience with new learners is that it's very hard to get past the bump into fluency if you can't make something that you personally view as valuable. It being possible to "push through" if the perceived long term gains are viewed as valuable enough. (eg the schooling approach)– but from what I've seen this often produces people who (rightfully!) are suspicious that future learning situations will be similarly painful.

iarna commented Aug 12, 2014

@maxogden Your point around learning motivation and utility is really important. My experience with new learners is that it's very hard to get past the bump into fluency if you can't make something that you personally view as valuable. It being possible to "push through" if the perceived long term gains are viewed as valuable enough. (eg the schooling approach)– but from what I've seen this often produces people who (rightfully!) are suspicious that future learning situations will be similarly painful.

@mikeal

This comment has been minimized.

Show comment
Hide comment
@mikeal

mikeal Aug 13, 2014

Identifying as "Node"

The "Nothing Is Sacred" ethos is certainly identifiable in the Node Community but the real question should be "where did it come from?" Is it simply an accident of history that certain people showed up or were there constraints that encouraged, grew, or co-opted in some way this ethos.

In my view this ethos grew from two sources. The first is a side effect from Node adopting a non-blocking IO event system. This meant that in the earliest days when Node was attracting it's first contributors and creating a culture, the people who wanted to re-write a lot of things that are taken for granted in other platforms that simply bind to C and C++ libraries that have been around for years were the ones that came.

As an example, Ruby and Python bind to most of the same underlying C libraries for common database drivers. That wasn't an option for Node because they all used blocking IO and so we needed new drivers to be written and we attracted people to the project interested in writing that. Because this was so early in the project the mindset of those people had a lasting effect on the culture.

The second place I believe this comes from is the culture of the web. Once Node was perceived as usable (it probably wasn't in reality) it immediately started attracting web developers because it was written in JavaScript. Almost everything has had to be re-written for the web and web developers have never been able to rely on all these old sacred cows written in previous languages.

Considering this, I think that it would be best to fly the JS flag. The "JS community" has come to represent the broadest set of interests and the modern spirit of the web all in a tiny yellow square.

Another important aspect of web culture that found its way in to Node and, I believe, should be part of Nothing Is Sacred, is a push towards amateurization. It's missing in the current messaging I've seen here but a big part of the motivation behind all of these efforts isn't just re-thinking these perceived sacred technologies because effort is also made to ensure that the result is more accessible than what came before it. If a kernel is written in JS the development of it is accessible to people who would not have been able to hack on a Linux or BSD kernel.

Anyway, I think that associating with "JS" would be a great thing, for Nothing Is Sacred as well as for the JS community.

mikeal commented Aug 13, 2014

Identifying as "Node"

The "Nothing Is Sacred" ethos is certainly identifiable in the Node Community but the real question should be "where did it come from?" Is it simply an accident of history that certain people showed up or were there constraints that encouraged, grew, or co-opted in some way this ethos.

In my view this ethos grew from two sources. The first is a side effect from Node adopting a non-blocking IO event system. This meant that in the earliest days when Node was attracting it's first contributors and creating a culture, the people who wanted to re-write a lot of things that are taken for granted in other platforms that simply bind to C and C++ libraries that have been around for years were the ones that came.

As an example, Ruby and Python bind to most of the same underlying C libraries for common database drivers. That wasn't an option for Node because they all used blocking IO and so we needed new drivers to be written and we attracted people to the project interested in writing that. Because this was so early in the project the mindset of those people had a lasting effect on the culture.

The second place I believe this comes from is the culture of the web. Once Node was perceived as usable (it probably wasn't in reality) it immediately started attracting web developers because it was written in JavaScript. Almost everything has had to be re-written for the web and web developers have never been able to rely on all these old sacred cows written in previous languages.

Considering this, I think that it would be best to fly the JS flag. The "JS community" has come to represent the broadest set of interests and the modern spirit of the web all in a tiny yellow square.

Another important aspect of web culture that found its way in to Node and, I believe, should be part of Nothing Is Sacred, is a push towards amateurization. It's missing in the current messaging I've seen here but a big part of the motivation behind all of these efforts isn't just re-thinking these perceived sacred technologies because effort is also made to ensure that the result is more accessible than what came before it. If a kernel is written in JS the development of it is accessible to people who would not have been able to hack on a Linux or BSD kernel.

Anyway, I think that associating with "JS" would be a great thing, for Nothing Is Sacred as well as for the JS community.

@mikeal

This comment has been minimized.

Show comment
Hide comment
@mikeal

mikeal Aug 13, 2014

Laptop, as a form factor for programmers, is hugely sacred. I'd love to hear from @maxogden and @rvagg about their experiments using alternative portable computing devices for development. For a while Max was using a Kindle as a terminal screen because the battery was basically infinite.

mikeal commented Aug 13, 2014

Laptop, as a form factor for programmers, is hugely sacred. I'd love to hear from @maxogden and @rvagg about their experiments using alternative portable computing devices for development. For a while Max was using a Kindle as a terminal screen because the battery was basically infinite.

@wraithan

This comment has been minimized.

Show comment
Hide comment
@wraithan

wraithan Aug 13, 2014

@mikeal We are already going to be super JS heavy because of the reasons you have just outlined. I find that to actually be a counter point to "fly the JS flag". We already do this, there is very little or no need to alienate or otherwise push away other communities by making it sound like it is a JS community event. Preaching to the choir is not the best way to change the world, at least in my experience

@mikeal We are already going to be super JS heavy because of the reasons you have just outlined. I find that to actually be a counter point to "fly the JS flag". We already do this, there is very little or no need to alienate or otherwise push away other communities by making it sound like it is a JS community event. Preaching to the choir is not the best way to change the world, at least in my experience

@btford

This comment has been minimized.

Show comment
Hide comment
@btford

btford Aug 14, 2014

Late to the party, but +1 @othiym23 ––> #1 (comment)

I think someone could talk about that in a language-agnostic way.

I also have some staggeringly bad ideas about dynamic analysis and self-modifying code that I'm eager to share.

btford commented Aug 14, 2014

Late to the party, but +1 @othiym23 ––> #1 (comment)

I think someone could talk about that in a language-agnostic way.

I also have some staggeringly bad ideas about dynamic analysis and self-modifying code that I'm eager to share.

@rvagg

This comment has been minimized.

Show comment
Hide comment
@rvagg

rvagg Aug 16, 2014

Non-mac & Linux environments for dev (sacred++ for many web-related developer communities): @creationix for ChromeOS & @domenic for Windows

rvagg commented Aug 16, 2014

Non-mac & Linux environments for dev (sacred++ for many web-related developer communities): @creationix for ChromeOS & @domenic for Windows

@suarasaur

This comment has been minimized.

Show comment
Hide comment
@suarasaur

suarasaur Aug 16, 2014

As a developer who currently uses Windows, I agree with @rvagg. However, to keep it interesting and not just devolve into a tooling love/hate-fest, maybe the aspect is that monoculture is not sacred.

As a developer who currently uses Windows, I agree with @rvagg. However, to keep it interesting and not just devolve into a tooling love/hate-fest, maybe the aspect is that monoculture is not sacred.

@aredridel

This comment has been minimized.

Show comment
Hide comment
@aredridel

aredridel Aug 16, 2014

Even more: Multiple environments show you assumptions you make. Portability is a win!

Even more: Multiple environments show you assumptions you make. Portability is a win!

@creationix

This comment has been minimized.

Show comment
Hide comment
@creationix

creationix Aug 18, 2014

I constantly use different platforms for development. I'm always trying to find new and novel ways to develop. The only reason I recently bought a macbook (I've not had one for about a year since my last one died) was the battery life. Also I had a consulting client who only tested their software on macs and I was getting tired of spending all my time fixing their lack of cross-platform tools.

But going back to @mikeal's comment about the early node days. I completely agree that there was an ethos that we should rewrite everything. My recent work with js-git / tedit / chrome os / firefox os / tablet and phone programming UX, etc. all feels the same. I have to develop my own package management system because there is no node on most of these platforms and thus I can't use npm. I implemented git in js because it solves most my technical problems. Git certainly isn't sacred and it's creator it by no means a model of ideal human behavior. But I love the challenge of creating everything from scratch. I've built my own programming languages, my own IDEs, my own build tools, my own compilers, runtimes, test frameworks, etc... Some days I'm so deep in the meta-ness of this project that I expect to wake up from a dream and finally see reality.

Some days I feel like I'm betraying node by not using it or browserify and instead rebuilding everything, but don't worry, that feeling doesn't last long. I enjoy creating new things so much that it overshadows feelings of loyalty or wastefulness. (My nick is based on the word "creation" and software after all)

So what are we talking about? I got tagged into this conversation while on vacation and have no idea what the goal here is.

I constantly use different platforms for development. I'm always trying to find new and novel ways to develop. The only reason I recently bought a macbook (I've not had one for about a year since my last one died) was the battery life. Also I had a consulting client who only tested their software on macs and I was getting tired of spending all my time fixing their lack of cross-platform tools.

But going back to @mikeal's comment about the early node days. I completely agree that there was an ethos that we should rewrite everything. My recent work with js-git / tedit / chrome os / firefox os / tablet and phone programming UX, etc. all feels the same. I have to develop my own package management system because there is no node on most of these platforms and thus I can't use npm. I implemented git in js because it solves most my technical problems. Git certainly isn't sacred and it's creator it by no means a model of ideal human behavior. But I love the challenge of creating everything from scratch. I've built my own programming languages, my own IDEs, my own build tools, my own compilers, runtimes, test frameworks, etc... Some days I'm so deep in the meta-ness of this project that I expect to wake up from a dream and finally see reality.

Some days I feel like I'm betraying node by not using it or browserify and instead rebuilding everything, but don't worry, that feeling doesn't last long. I enjoy creating new things so much that it overshadows feelings of loyalty or wastefulness. (My nick is based on the word "creation" and software after all)

So what are we talking about? I got tagged into this conversation while on vacation and have no idea what the goal here is.

@brycebaril

This comment has been minimized.

Show comment
Hide comment
@brycebaril

brycebaril Sep 4, 2014

Member

Due to weather and other scheduling complexities, it looks like the first iteration of this will be at JSFest in Oakland this December.

Those of you above who put proposals in here that want to specifically propose the talk for that event, please do so here: https://github.com/mikeal/jsfest-oakland-cfp

That will be the "official" Oakland JSFest Nothing Is Sacred talk proposal location, but I'd love to keep this as the main discussion forum for the concept.

Otherwise, all of the above are still considered "live" for other future Nothing Is Sacred gatherings!

Member

brycebaril commented Sep 4, 2014

Due to weather and other scheduling complexities, it looks like the first iteration of this will be at JSFest in Oakland this December.

Those of you above who put proposals in here that want to specifically propose the talk for that event, please do so here: https://github.com/mikeal/jsfest-oakland-cfp

That will be the "official" Oakland JSFest Nothing Is Sacred talk proposal location, but I'd love to keep this as the main discussion forum for the concept.

Otherwise, all of the above are still considered "live" for other future Nothing Is Sacred gatherings!

@jory

This comment has been minimized.

Show comment
Hide comment
@jory

jory Sep 5, 2014

Everyone is scared.

jory commented Sep 5, 2014

Everyone is scared.

@kid-icarus

This comment has been minimized.

Show comment
Hide comment
@kid-icarus

kid-icarus Sep 5, 2014

Rojy is scared.

Rojy is scared.

@othiym23 othiym23 referenced this issue in jsfest/2014-oakland-cfp Sep 5, 2014

Open

MONKEYPATCH THE PLANET #23

@gggritso gggritso referenced this issue in jsfest/2014-oakland-cfp Sep 17, 2014

Open

Not The Browser #40

@dominictarr

This comment has been minimized.

Show comment
Hide comment
@dominictarr

dominictarr Nov 22, 2014

okay one thing that is too sacred to javascript is javascript, if we are gonna ever realize atwoods prophesy we need to bring in outside, non javascripters. There are lots of interesting ideas in other language communities that are not in javascript yet... so maybe we should have speakers at our conferences who don't write javascript.

okay one thing that is too sacred to javascript is javascript, if we are gonna ever realize atwoods prophesy we need to bring in outside, non javascripters. There are lots of interesting ideas in other language communities that are not in javascript yet... so maybe we should have speakers at our conferences who don't write javascript.

@xantronix

This comment has been minimized.

Show comment
Hide comment
@xantronix

xantronix Nov 22, 2014

I would like to avail myself as an emissary of the Tcl community and ecosystem.

I feel that Tcl has many prescient ideas that Node.js shares in common, things that have long since been in the base library of the language since the introduction of Tk itself: Namely, a first-class event loop. Because of this well-considered pattern easily accessible from within any scope or namespace in a Tcl program, it becomes quite easy, nearly trivial, even to make two pieces of event-driven software coexist within the same process image. To wit, some Internet genius has taken it upon himself to integrate tänzer (http://tanzer.io/) into the well-known IRC bot Eggdrop, and it appears to have been done with minimal effort. Oh, and Tcl itself also carries a pretty solid standard library and out-of-the-box experience, with Tcl 8.6's first class object system and the usual bits you'd get with a comparable language like Python.

Oh, more on tänzer. It's a reasonably minimalist (in terms of code-per-feature and cohesiveness, not necessarily in feature set) HTTP/1.1 framework implemented as a hopefully thin layer on top of Tcl's event loop. I try to make the layers of code and concepts on top of the event loop and the HTTP/1.1 semantics tänzer implements as thin and cohesive as possible, and deferring to the semantics of RFC 2616 to make writing web apps more straightforward for those who are willing to defer to the RFC themselves.

I find that there are many opportunities for learning, for myself and other members of the Tcl community, at a Node.js conference, in terms of social concerns of inclusion, promotion, marketing, and outreach. Not to mention, there are many technical innovations and programming patterns that have been fleshed out by the vast numbers of Node.js practitioners that are worthy of exploration.

To restate, for the aforementioned reasons, I'd like to submit myself as lamb and martyr for a healthy and positive exchange of ideas between one long-established programming language and environment, and a new, exciting, burgeoning one with loads of enthusiasm. I see nothing but lovely opportunities for growth and hugs, on at least my part. :)

Best,
Xan

I would like to avail myself as an emissary of the Tcl community and ecosystem.

I feel that Tcl has many prescient ideas that Node.js shares in common, things that have long since been in the base library of the language since the introduction of Tk itself: Namely, a first-class event loop. Because of this well-considered pattern easily accessible from within any scope or namespace in a Tcl program, it becomes quite easy, nearly trivial, even to make two pieces of event-driven software coexist within the same process image. To wit, some Internet genius has taken it upon himself to integrate tänzer (http://tanzer.io/) into the well-known IRC bot Eggdrop, and it appears to have been done with minimal effort. Oh, and Tcl itself also carries a pretty solid standard library and out-of-the-box experience, with Tcl 8.6's first class object system and the usual bits you'd get with a comparable language like Python.

Oh, more on tänzer. It's a reasonably minimalist (in terms of code-per-feature and cohesiveness, not necessarily in feature set) HTTP/1.1 framework implemented as a hopefully thin layer on top of Tcl's event loop. I try to make the layers of code and concepts on top of the event loop and the HTTP/1.1 semantics tänzer implements as thin and cohesive as possible, and deferring to the semantics of RFC 2616 to make writing web apps more straightforward for those who are willing to defer to the RFC themselves.

I find that there are many opportunities for learning, for myself and other members of the Tcl community, at a Node.js conference, in terms of social concerns of inclusion, promotion, marketing, and outreach. Not to mention, there are many technical innovations and programming patterns that have been fleshed out by the vast numbers of Node.js practitioners that are worthy of exploration.

To restate, for the aforementioned reasons, I'd like to submit myself as lamb and martyr for a healthy and positive exchange of ideas between one long-established programming language and environment, and a new, exciting, burgeoning one with loads of enthusiasm. I see nothing but lovely opportunities for growth and hugs, on at least my part. :)

Best,
Xan

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment