eggsby

Article did not load on my tablet :sweat_smile:

I learned about this reading Ishtar Rising by Robert Anton Wilson

Seems to be enforcing ‘ubiquitous language’ at the machine level - not some kind of mathematical dual where one is invertible to the other - but enforcing soft skills as hard skills.

  ‘protobuf specs dont have enough information for us to codegen iceberg tables so we will write a new codegen spec language’

what makes a duck a duck? when we know which tables we can find it in

Sorry if my language was unclear, I meant to highlight this line from the wiki article:

"There is no proposed mechanism of action by which the positions and motions of stars and planets could affect people and events on Earth in the way astrologers say they do that does not contradict well-understood, basic aspects of biology and physics."

Relevant here because it essentially says "there is no empirical basis for spooky action at a distance" which has been grounds for dismissal of such action-at-a-distance claims like 'the relative positions of celestial bodies influence events on the earth'.

This kind of empiricism has been used as grounds to not critically evaluate these claims. Everyone is certainly free to have their own reasons around why they do not want to evaluate such claims. For example some people only want to consider things that are easily falsifiable and subject to particular scientific practices. The wiki article goes on to mention how Carl Sagan refused to disavow astrology on these grounds (i.e. gravity is weak so stellar influence writ large ought to weak) while still leaving room for a disavowal if it were on firmer grounds. I do think your point about simplicity is salient here.

One reason I often hear astrology is not taken seriously by the scientific community, as in findings like 'athletes often have aries rising on their birth chart' are ignored and not evaluated further, is because there is no empirical foundation for the communication of the effects.

https://en.wikipedia.org/wiki/Astrology_and_science

There is a cut and dry relationship between bitrate and audio fidelity. You simply cannot encode higher frequency audio in lower bitrate samples.

https://en.wikipedia.org/wiki/Nyquist%E2%80%93Shannon_sampli...

At the same time, the city government is adding explicit surveillance feeds for law enforcement.

https://www.sandiegouniontribune.com/communities/east-county...

I really doubt there was any human review of the targeting settings, likely just automated verification.

If I'm writing a tool that allows users to enter their own n-grams is there an expectation that I also need to write a tool that detects if they are inputting pernicious n-grams?

"You Cannot Have Exactly-Once Delivery" is not the same as "Exactly-Once Delivery is expensive".

Which is it?

I made oroboros for working with large collections of app and server configuration that need to be shared across many systems.

Previously I had been using an automation tool to template my configuration variables and found myself frustrated that I couldn't access their processed values outside of the tool.

Oroboros exposes all configuration as JSON over HTTP by recursively templating & assembling configuration files under some directory. This makes it simple to track & release changes through version control.

This project solves a particular need of mine, hopefully someone else find will find useful it as well.

Happy Hacking,

Thomas

Nice read, I had to think about a few of these.

In particular (a == 0) && (a == 1) && (a == 2).

Here's a fun value for a:

    var a = {
      called: -1,
      valueOf: function() {
        this.called += 1;
        return this.called;
      }
    };

React inlines event handlers since it manages them through it's virtual event system.

For more information on why react breaks preconceived notions of best practices I recommend checking out http://2013.jsconf.eu/speakers/pete-hunt-react-rethinking-be...

I just started playing with docker and it is very cool, but I am not sold on complete isolation of every service in a stack.

I've taken to building my containers using packer & ansible, with docker acting as something between git and an lxc client.

If you run your tests against live instances do you deploy the exact same container? How do you control environmental or configuration drift?

I'd be interested in seeing a CI tool on top of docker :)

To paraphase Rich -- "promises are the one-night stand of asynchronous programming, core.async is aiming for a longer term relationship."

The big win isn't that you have the ability to await and fulfill messages, but rather that you have first class entities that can be used to send and receive discrete and coordinated messages.

What's better than simply having these communication channels (think event emitters) is having the ability through clear syntax to synchronize not only the receipt of these messages, but also to coordinate message sending through the same uniform style.

To me, this seems just about as related to promises as promises are related to callbacks, in that they are all patterns for asynchronous programming.

To drive the point home: "I grant that promises are a superset of callbacks kind of functionality, but to me they are definitely part of the same family. And you can definitely implement promises in terms of them."

To be fair, a lot of the syntax magic of core.async happens in its macros -- in js that is supported by the cljs compiler. As I understand it, because of this it'd be impossible for core.async to be used as a js "library" (a global namespace with a public interface).

Your criticism seems to be framed against where we are at today.

As programmers we have a fragmented feedback cycle regardless of whether we are writing our software in Erlang or Lisp or C++.

While it is true that realistic matters like 'integration' and 'development velocity' are important enough in modern-day programming to determine what path we must take we shouldn't let it change our destination.

If you were to envision programming nirvana would it be mostly test coverage and scrum boards?

Pedestal is still very alpha and I'm not sure that I would use it for any of my projects... yet.

For instance, using the example apps provided I couldn't get the chat application to work properly -- if I opened up two windows to the app, only one of them would work at any given moment.

I wonder at the real use case for this style of application, the included hello world app was almost 2 megs of javascript resources (this was without minification or advanced google closure compilation) it seems excessive for a small 'your page updates when server sent changes happen', and certainly more expensive than the approach taken by projects like meteor for similar functionality.

I think some of the features it offers are a glimpse into the future, tracking the state changes from one moment to a next rather than firing off and forgetting about events, almost like version control for your clientside state. This sounds incredibly useful, but for what I'm not quite sure. What sort of apps need that sort of functionality to the point where the extra ceremony required becomes justified?

Another interesting concept is that it is theoretically possible to shift the generation of the app tree deltas to the server and turn the clientside into nothing but a dumb renderer. The thinner the renderer the easier it becomes to target alternate graphical environments.

I know the guys at relevance have hinted about the above, it'd certainly be interesting to see.

Definitely a project to watch :)

For getting around linux I've found no better helpers than manpages and the cheatsheets by Peteris Krumins[1]. I notice this isn't offered as a pdf or image, is the idea that someone will come and visit the site when their server is in trouble? That said, I didn't know about some stuff here like scriptreplay -- thanks!

[1]: http://www.catonmat.net/projects/cheat-sheets/

How is it that referential transparency (the ability to swap a reference with it's value: no hidden inputs) and homoiconicity (both the source and the resulting syntax tree sharing the same structure) are mutually exclusive?

What homoiconicity offers is the macro system, the ability to operate on the syntax tree as a regular language data structure.

The difference is a language like Haskell enforces referential transparency where in a lisp it is up to the developer whether or not a function will be referentially transparent.

The comic references clojure in multiple sections (multicore, lazy), I think you'll find the tutorial and documentation guilds still alive and well there.

Thanks, I'll work on elucidating the metaphor and being explicit about what I mean when I say things like 'duplicates input' (uses the parameter more than once in it's body, this is a term from Smullyan), as well as clarifying some of the language.

I want to make the idea simple to parse by breaking it down into it's pieces, if it's noticeably hard to swallow (or as you said the commentary actually detracts from my code examples) then I did it wrong!

Edit: I changed some terminology and clarified the points you mentioned, hope this helps anyone who reads this in the future, thanks again for taking the time to leave feedback :)

Thanks! I actually got the bug to write this post from reading your wonderful js combinator book[1] over the holiday, which reminded me that I also had a copy of To Mock a Mockingbird in my to read pile.

When I got to the bit where Smullyan describes the first sage bird (He explains: "This is quite simple ... for any bird x, Θx = M(Lx). Since x is fond of M(Lx) and M(Lx) = Θx, then x is fond of Θx, which means that Θ is a sage bird."), I felt like I had been hit by a brick wall as it was anything but simple for me, having previously grasped at understanding the y combinator.

Only by understanding the discrete moving parts was I able to finally wrap my head around what was going on. Like many others when I had my a-ha! moment I wanted to share.

Thank you for making content like this digestible!

1: https://leanpub.com/javascript-allonge

Nice, I enjoyed Jim's talk where he derived the combinator using clojure[1]. In it he referenced another talk that he cites as an influence, "Programming With Nothing"[2] by Tom Stuart where he writes fizzbuzz in ruby using only lambda application.

Finding the SKI calculus was a similar revelation to me, that such simple combinators could represent any lambda term is such a huge idea!

1: http://www.infoq.com/presentations/Y-Combinator

2: http://rubymanor.org/3/videos/programming_with_nothing/

While it's true that you need to turn things like a NodeList from js into a clj seq you don't need to write these utilities yourself; clj->js and js->clj can both be found in cljs core: https://github.com/clojure/clojurescript/blob/master/src/clj...

DNT is pretty laughably ill conceived. Vague definitions of what is able to be tracked, what constitutes a first party and third party (Is a browser vendor first party or third party?). Some of the major proponents are companies like Google and Microsoft, both with their respective gigantic ad platforms DART and Atlas. Would they be able to collect data directly from the browser and dominate the ad world? It's certain that if this were legislated that it would destroy the business model for many large companies. (Yahoo, ValueClick, AOL).

The existing legislation requires an opt-out policy from tracking. Advertisers must respect the user's choice with regards to targeted advertising. Does Microsoft turning on DNT by default represent the users choice or does it represent Microsoft's interests? What about third party identification for things like disqus? Sure we have ways to handle CORS today but what if there was a law (that only effected the USA) saying you were not allowed to "track" if you were a third party? If it's just about advancing web technologies why isn't this just a w3c proposal or RFC? What's wrong with the existing opt-out methods?

From what I see DNT is just a political tactic to gain power in the ad-world, not a way to protect the privacy of users.

I'd argue that the problems in large projects are primarily architecture problems, that backbone's philosophy of 'bring your own architecture' means how well an app is structured is entirely up to its authors rather than defined by library choice. Something like your plastronjs or emberjs are saying 'Here, do it like this'. Which is good. Sometimes.

I've certainly run into many issues using backbone for moderately sized applications (form workflows, several different types of records, etc) but every time I get myself out of them I gain general javascript knowledge rather than domain specific knowledge about framework xyz. I'd much rather know how to effectively manage memory in javascript than how to use a particular framework.

Why would I want to use or contribute to this over something like http://codemirror.net/ or the various tools powered by codemirror? (light table, jsbin, etc)

edit: I see that this is also powered by codemirror, the editor itself, so what does this offer on top of it?

I can't even find a feature list on this page, and after signing up for the adobe ~cloud~ I haven't been able to make my way to a working demo of the application...

I wasn't aware of $scope.$apply, should help simplify some of my angular stuff. Thank you :)

I recommend checking out http://blog.stevensanderson.com/2012/08/01/rich-javascript-a... for a more in depth exploration of the trade-offs between the popular client-side architecture tools.

I can only speak of my personal experience with these tools, and I've only tinkered with knockout (though we do use it for one of our tools internally, and the developer of that project gave it glowing reviews). I would recommend using the tool that is the closest to your development style.

If you like opinionated frameworks that make it as easy as possible to do the most common tasks (like rails), maybe you'd enjoy something like ember.js (or knockout). For me the style closest to home is the ability to plug in My Favorite Solution to each particular problem as it arises.

A primary offering from backbone then is a simple structure for plugging all these previously disparate tools together, the serverside corollary to this is something like python's Flask or ruby's Sinatra where it comes with only a simple routing base and ways to plug your own components in.

Want to use your own templating library? Easy. Want to use your custom persistence style? No problem. Backbone isn't going to make these choices for you, you will need to make them yourself.

This may or may not be the right choice for you, just investigate and make the choice that makes the most sense for you !

I've built moderately sized applications in both angular.js and backbone, backbone is much more pleasant to work with if only for the fact that everything is obvious, even if that requires you to do more development legwork and thinking about your application structure. (this is a feature, not a bug)

Angular.js data bindings are great and things like ng-repeat are neat until you start to step outside of the bounds of the angular garden.

Want to fetch data yourself and not use the angular resource plugin? (The resource plugin restricts the shape of data you can return from your server, i.e. every resource.get() request must only return a single object, if you want to receive an array you need to use .query() ). If you want to use jQuery for ajax, for instance, you lose all data bindings because vanilla javascript doesn't have the angular secret sauce! edit: angular provides utilities to alleviate this issue, addressed in comment below.

Well that's fine maybe there's an event somewhere you can hook into and trigger off of, right? Try to find this in the docs, I dare you! If this doesn't demonstrate the incidental complexity caused by using a tool like angular, consider the documentation for backbone and angular, or either projects source for that matter. You can read backbone's source in an afternoon, I couldn't say the same for angular (or ember, or knockout). Because of this I can be confident backbone is largely bug free, I absolutely can't say the same about larger projects like angular.

Angular.js is meant to have a low barrier of entry, but because of this the developer interface is a thin facade on top of astonishingly complex internals. Contrast this to backbone which provides a simple and solid base for your application, providing freedom and foundation rather than a cookie cutter solution.

When I consider the trade-offs between client-side tools for structuring applications backbone consistently comes out on top.