Opening discussion #1
Comments
|
we shall! |
|
I would suggest we keep this process open, because that seems like the "nothing is sacred" approach |
|
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. |
|
lets start a grassroots campaign to implement 64 bit integers in javascripts |
|
+1 on leveldb, databases are very "sacred" 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. |
|
Yes +1 on keeping it positive. |
|
Are there specific environments that can help foster these types of ideas/projects? |
|
I would obviously like to talk about nodeos/runtime and why writing a kernel with javascript is tons of fun. |
|
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. |
|
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. |
|
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 |
|
+1 @maxogden |
|
@maxogden there isnt enough <3z I can give to this. |
|
@jeffreykegler is all about nothing is sacred with parsers. |
|
ahhhhh all of this stuff makes me very excited! |
|
<3 @maxogden |
|
@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. |
|
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. |
|
@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). |
|
I'm struck by a phrase from @jxson's cascadiajs talk - "ask for help, not for permission" |
|
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? |
|
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. |
|
Build systems: 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? |
|
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. |
|
+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. |
|
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? |
|
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. |
|
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.) |
|
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:
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 👍 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. |
|
cooking shows are not sacred. why can they not be staffed entirely by javascript programmers and filmed in my kitchen? |
|
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:
|
|
tacos. tacos are sacred. |
|
tacos++ |
|
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. 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. |
|
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)? |
|
@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'. |
|
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. |
|
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. |
|
request for talk: someone deconstruct the tacoid |
|
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. |
|
@gggritso love that topic! |
|
@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. |
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 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 |
|
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. |
|
Non-mac & Linux environments for dev (sacred++ for many web-related developer communities): @creationix for ChromeOS & @domenic for Windows |
|
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. |
|
Even more: Multiple environments show you assumptions you make. Portability is a win! |
|
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. |
|
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! |
|
Everyone is scared. |
|
Rojy is scared. |
|
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. |
|
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, |
and others
Shall we discuss our ideas?
The text was updated successfully, but these errors were encountered: