Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Opening discussion #1

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

Opening discussion #1

groundwater opened this issue Aug 6, 2014 · 67 comments

Comments

@groundwater
Copy link

@groundwater groundwater commented Aug 6, 2014

Shall we discuss our ideas?

@nvcexploder
Copy link

@nvcexploder nvcexploder commented Aug 6, 2014

we shall!

@groundwater
Copy link
Author

@groundwater groundwater commented Aug 6, 2014

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

@brycebaril
Copy link
Member

@brycebaril 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
Copy link

@maxogden maxogden commented Aug 6, 2014

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

@groundwater
Copy link
Author

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

@brycebaril
Copy link
Member

@brycebaril brycebaril commented Aug 6, 2014

Yes +1 on keeping it positive.

@nvcexploder
Copy link

@nvcexploder nvcexploder commented Aug 6, 2014

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

@groundwater
Copy link
Author

@groundwater groundwater commented Aug 6, 2014

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

@ceejbot
Copy link

@ceejbot 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
Copy link

@wraithan 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
Copy link

@maxogden 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
Copy link

@kamilogorek kamilogorek commented Aug 6, 2014

@voodootikigod
Copy link

@voodootikigod voodootikigod commented Aug 7, 2014

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

@aredridel
Copy link

@aredridel aredridel commented Aug 7, 2014

@jeffreykegler is all about nothing is sacred with parsers.

@junosuarez
Copy link

@junosuarez junosuarez commented Aug 7, 2014

ahhhhh all of this stuff makes me very excited!

@JacksonGariety
Copy link

@JacksonGariety JacksonGariety commented Aug 7, 2014

@groundwater
Copy link
Author

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

@brycebaril
Copy link
Member

@brycebaril 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
Copy link

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

@junosuarez
Copy link

@junosuarez junosuarez commented Aug 7, 2014

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

@ceejbot
Copy link

@ceejbot 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
Copy link

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

@ceejbot
Copy link

@ceejbot 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
Copy link

@shama 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
Copy link

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

@othiym23
Copy link

@othiym23 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
Copy link

@isaacs 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
Copy link

@isaacs 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
Copy link

@gggritso 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
Copy link

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

@maxogden
Copy link

@maxogden maxogden commented Aug 10, 2014

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

@nvcexploder
Copy link

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

@junosuarez
Copy link

@junosuarez junosuarez commented Aug 11, 2014

tacos. tacos are sacred.

@ungoldman
Copy link

@ungoldman ungoldman commented Aug 11, 2014

tacos++

@operatorjen
Copy link

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

@Maciek416
Copy link

@Maciek416 Maciek416 commented 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)?

@maxogden
Copy link

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

@isaacs
Copy link

@isaacs 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
Copy link

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

@junosuarez
Copy link

@junosuarez junosuarez commented Aug 12, 2014

request for talk: someone deconstruct the tacoid

@gggritso
Copy link

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

@ceejbot
Copy link

@ceejbot ceejbot commented Aug 12, 2014

@gggritso love that topic!

@iarna
Copy link

@iarna 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
Copy link

@mikeal 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
Copy link

@mikeal 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
Copy link

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

@btford
Copy link

@btford 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
Copy link

@rvagg rvagg commented Aug 16, 2014

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

@junosuarez
Copy link

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

@aredridel
Copy link

@aredridel aredridel commented Aug 16, 2014

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

@creationix
Copy link

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

@brycebaril
Copy link
Member

@brycebaril 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
Copy link

@jory jory commented Sep 5, 2014

Everyone is scared.

@kid-icarus
Copy link

@kid-icarus kid-icarus commented Sep 5, 2014

Rojy is scared.

@dominictarr
Copy link

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

@xantronix
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.