The Elements of UI Engineering - <AUTHOR> https://overreacted.io/the-elements-of-ui-engineering/ <comment><USER3> I've been building consumer apps professionally since 2013 on iOS, Android, Windows Phone and the web. I also spent a few years designing and implementing UI frameworks. I've had to deal with all of the problems listed in Dan's article (with and without frameworks).

Over the years, I have grown convinced that designing and implementing UI by hand simply doesn't scale. There are too many things to consider, too many different users, too many preferences, too many possible states. Responsive design isn't just about screen sizes anymore, it's also about the user's language, culture, disabilities, input, context, preferences, connectivity, knowledge, focus, etc.

We can't expect every restaurant, bank, festival and airlines to implement their own apps, and consider all of the above. You won't find a dark theme in the Domino's app. Why do we tolerate these compromises in the name of branding? Why should UIs be tightly coupled with the services and data? Why don't we have general purpose clients?

I think the job of service providers should be to semantically annotate their data, so that a general purpose client can dynamically render it. All of these UI concerns would only have to be dealt with once, and we all would be able to sleep at night. Just let business people do business, and let UI/UX people do design.

<comment><USER4> A related issue is that the means of making web UIs are too low-level. There's no standard ready-made widget kit like on desktops.

HTML and CSS started as a solution for publishing text-based content, like the olde magazines but on the web. For that they are splendid: text rendering and basic input handling are taken care of, and wide variety of output devices were supported since day one (HTML 2.0 without tables works excellent on phones).

Then web 2.0 and web apps happened, web idioms began to change, all of people's activity with computers started moving to the web. And it turned out that to create complex UIs for all of that you have to fiddle with rather low- level primitives and handle interactions between them, because outside of text layout HTML primarily knows about divs and a handful of input widgets.

This may be good because high-level widgets will be developed independently and will evolve faster (and maybe better) than if they were built into browsers. But in the meantime we have to live with the chaos that we have.

<comment><USER5> >This may be good because high-level widgets will be developed independently and will evolve faster (and maybe better) than if they were built into browsers. But in the meantime we have to live with the chaos that we have.

I don't think that having some good built-in widgets (like a better dropdown, menus, DataGrid) would prevent third parties creating their own custom versions but it would help 99% of users that need the basic stuff (like a dropdown that can have icons)

</comment></comment></comment><comment><USER6> I've been building UI for years now and all these points highlighted by Dan are spot on. Great post!

I've been thinking lately about the "design system" trend that is becoming more and more popular where companies want more control over styling and behaviour to make their UX unique to their brand as well as consistent across all their products. Ready-made 3rd party components like the excellent react- select don't really fit into this world as general purpose components like this naturally have to make some choices regarding styling and behaviour. No matter how customisable they are, in the end they rarely integrate well into a UI based on a design system.

This makes me feel like the abstraction is all wrong. Rather than aiming for fully-functional, out-of-the-box components that cater for all manner of general purpose requirements, how about a library/framework that focuses on a set of primitive components that deal with the lower level concerns like layout, scrolling, positioning, etc. Maybe the abstraction could be more like "composable shapes" than "ready-made components" or something along those lines.

With this approach, you wouldn't ever start out with something like a ready- made Autocomplete component, for example. Instead, you would always build a custom Autocomplete and have complete control over styling and behaviour, but it would be built from solid foundations using some form of the "shape" abstraction. That way, you can focus on making the component's styling and behaviour consistent with the design system without having to worry so much about layout, accessibility, scrolling, positioning, etc - as all of these are taken care of by the framework.

<comment><AUTHOR> That's exactly how some of the newer libraries in React ecosystem work btw. For example, Downshift is that "DYI Autocomplete" — it handles a11y and mechanics but you can compose any kind of behavior and styling out of its primitives.

[https://github.com/paypal/downshift](https://github.com/paypal/downshift)

I'm glad to see this trend.

<comment><USER7> > a11y

I had to look that one up. I find it amusingly ironic that an accessibility initiative uses an abbreviation that renders the name incomprehensible.

<comment><USER8> It's certainly ironic, but most places I've been to pronounces it like the word "ally". At least it's easier than the even more obscure "i18n" and "l10n" for "internationalization" and "localization".

</comment></comment></comment></comment><comment><USER3> Navigation

Whenever we can't fit everything on the screen at once, we use some of the patterns below:

\- scroll view

\- virtualized list

\- tabs

\- drawer

\- master-detail

\- page navigation

\- modal navigation

\- alert

\- tooltip

\- combo box

\- collapsible

\- carousel

\- gallery

It wouldn't make sense to use any of these patterns if we had ∞ sized displays.

Would you call all of the above patterns "navigation"? Why not? Isn't navigation just a way to reach content that isn't immediately accessible? Why don't you think of scrolling through a list as some sort of navigation? I think you should.

It really helps to re-frame all of the above patterns as simple layout strategies. Layouting is about putting content where it belongs. Whether that content is visible or not (covered, collapsed, out of bounds) doesn't really matter.

Let's consider the classic master-detail example that so many people struggle with:

      Tablet (stacked on X axis)

      +-----+</comment><comment>---+
      |     |         |
      |  M  |    D    |
      |     |         |
      +-----+</comment><comment>---+

      </comment><comment>--X</comment><comment>--

      Phone (stacked on Z axis)

           +-----+
      +-----+    |      /
      |     | M  |     /
      |  D  |    |    Z
      |     |----+   /
      +-----+       /

The only difference between these two examples is the stacking axis. That's it. It's the only thing that should change when resizing a window. You don't need to recreate a completely new layout using frames and pages and what not. Re-framing the problem just makes everything much easier. Navigation is just layouting.

<comment><AUTHOR> What do you make of route transition animations?

<comment><USER3> There's no reason for route transition to be a special case of state transition.

Here are some examples of state transitions that can be augmented with animations:

\- reorder items in a lost

\- add/remove an item from a list

\- expand/collapse an element

\- hover/press/disable a button

\- show a popup

\- show an inline error message

\- open a drop down menu

\- open/close a burger menu

\- change the burger menu button to a back button

\- change the scroll offset to a new item/anchor

\- increase the height of a text field

\- show/hide the top menu/navigation bar

\- add an item to the cart (and the count badge appears/increases)

\- increase the value of a progress bar

\- image goes from loading/placeholder to loaded

As you can imagine, most of these state changes benefit from transition animations (scale, translate, opacity). We just add linear interpolation to a discrete change.

Can you think of a good reason to use different techniques and APIs to implement route transition animations and button state transitions? I can't.

Once you think about using gestures for continuous transitions (swipe to go back on iOS), it makes even more sense to think of these components as physical overlapping sheets of material, with their own weight, inertia, grip/transition/friction, rails, anchors, springs.

Consider these interactions:

\- swiping from the edge to reveal a side burger menu

\- swiping from the edge to reveal the previous page

\- swiping down to dismiss a bottom sheet

\- scrolling down to reveal additional list items

\- swiping horizontally to reveal actions under a list item

\- dragging horizontally to move the thumb of a slider around

\- pinching to zoom-in on a picture

These are all types of continuous navigations. They don't require animations because you're continuously animating them using touch. These interactions should be easy to implent. Programmatic discrete state changes should automatically infer transitions based on physical characteristics of these materials.

What's a route? Should the currently selected tab be part of the route? Should the expanded/collapsed state of a widget be part of the route? Should the visibility of a popup be part of the route? Should the vertical scroll offset be part of the route? Should the zoom level of a map be part of the route? Should the open/close state of a burger menu be part of the route? I think the concept of a route doesn't make a lot of sense if it doesn't capture the entire state and history of a person's interaction with an app. I see no reason why the browser history/backstack should discriminate against different navigation patterns, and only store pages. Adding all state changes to the history makes it easy to use the back button to dismiss a popup, close a burger menu, close the keyboard, etc. Heck, all apps should have universal undo/redo functionality.

Another specific type of transition people are struggling with are shared element transitions. For example, you tap on a thumbnail and it seamlessly animates into a detail page with a larger version of that image. This is easier to do as a layout transition than as a route transition.

A last thing to keep in mind is that layouts don't need to immediately create and render all of their elements. We can use virtualization, to only materialize what is currently visible. For example, a list of 1000 items will only materialize the 10 or so items it can display at once, and will dynamically create/recycle items as the user scrolls. The exact same strategy can be used if we're stacking items on a Z axis. For example, we could create and render the top 2 items (so that the previous item is immediately visible in a swipe back to reveal scneario), and only create and render other items as they get closer to the top of the stack.

<comment><USER9> Interesting! Are there any resources or books that you might share that delve into this kind of reasoning towards UI engineering?

<comment><USER3> I would be interested as well.

For now, it's just a bunch of things I figured out along the way.

</comment></comment></comment></comment></comment><comment><USER10> Much thanks to Dan for taking the time to write this up. UI dev is a deep and highly technical field, but we're often inundated with juniorish programmers because it's often the entry point for folks coming out of school or boot camps. We need folks writing more about these kinds of principles and less about a new way to reinvent the wheel

<comment><USER11> Absolutely. [https://en.wikipedia.org/wiki/Invented_here](https://en.wikipedia.org/wiki/Invented_here)

The name of the game is failure aversion. Frameworks and NPM packages for everything. When I interview JavaScript or UI developers this is my first discriminator. Why write original code or reinvent the wheel when somebody else has your simple solution behind 50mb of external code that you didn't write? If you are that fearful coward who believes in not writing original code I don't want to work with you. Have a nice life and go work somewhere else. I would rather work with somebody willing to take a chance on problem solving.

If you are going to down vote please mention why. Don't be a troll. Hacker News tries very hard to not be an echo chamber.

<comment><USER12> You're being toxic by calling people "cowards" for simply using a package instead of writing it themselves which reduces the amount of code they need to directly maintain. Displays a complete misunderstanding of the tradeoffs involved as well as being rude.

And what's funny is that if you hadn't been a jerk the original point of Frameworks and NPM Packages for _everything_ is a good point and probably would have been well received. Because, the fact is that, sometimes it IS better to do it yourself instead of using the package and most wouldn't. Sometimes.

</comment></comment></comment><comment><USER13> From the part on accessibility:

> But we also need to make it easy for product developers to do the right > thing. What can we do to make accessibility a default rather than an > afterthought?

Yes! We accessibility advocates have been wishing for this for decades. In the context of web development, application developers should rarely, if ever, have to reach for the ARIA role attribute, because they should be able to re- use existing rich widgets rather than implementing custom ones. I'm hoping that Web Components-based toolkits like the new Ionic 4 will help here. Then project boilerplates should include some kind of accessibility testing by default, so developers will have to go out of their way to ignore it.

<comment><AUTHOR> For React, [https://ui.reach.tech/](https://ui.reach.tech/) is a project that attempts to help that.

<comment><USER14> React Native for Web also aims to raise the bar.

</comment></comment></comment><comment><USER15> The Entropy section is great. I've been experimenting with ways of leveling down entropy in React by using this little helper to express decision trees in your render function. Not totally happy with it yet though. [https://github.com/scottyantipa/photonic](https://github.com/scottyantipa/photonic)

<comment><USER16> Your approach seems to create an abstraction on top of react where the next step could only be a DSL. This is a first indicator for me that the developer will loose those programming capabilities that react carefully tries to retain and I'm not sure if this is a good approach. I think this doesn't solve the problems of entropy that Dan mentioned in his post and please let me explain a bit further...

I think of JSX as a declarative way to redefine HTML and to make it fit to the desired design. Sometimes it's quite possible to find a common behavior of a component and it can become part of a library, but that's not always the case. I like to use react components as a slim layer and prefer to do the work (side-effects, data processing etc.) somewhere else (purely functional modules, redux-saga etc.). My goto-rule to create components became the following: "if I start naming my component with something else than with layout-related terms, then I'm using react as the wrong tool for the job". React is just the view layer, a data processor that puts the view-data into the DOM. And as such a view layer it's sole responsibility is to render conditionally, the responsibility that your linked library tries to extract. I personally prefer to read through early returns in the render method of a component as opposed to following the order of an array.

There are behavioral UI problems in an SPA that are not related to the DOM itself. React can't do much about that and I think the problem of entropy stems from there: In the app at work one of the biggest struggles was to keep a global lock for a modal. This modal can pop-up to the user and show a notification, confirmation, form etc. Modals should never overlap with each other, give the user all the time she needs, but should also follow priorities (i.e. a push-notification to cancel the session being one of the highest). The difficulty in managing this lock was that actions from everywhere can pop-up that modal, be it a push notification over websockets, functions called from the native side, failed/succeeded API calls or behavioral inputs that should work differently all over the app (i.e. barcode scanning a product will search for a product in one view, will add it to the cart in another, or will prompt for a follow-up action if no product could be found). Thanks to redux-saga, we can make use of actions not solely to update the store state, but can additionally (if ignored by the reducers) use them like a message bus in a concurrent system. So with redux-saga (and inspired by elixir) I could make use of the actor-pattern and build a supervisor saga that keeps this behavior maintainable, but there is way to much complexity in this.

Point being, react and redux do a great job at managing entropy as long as it's used in the correct way. I think each component that doesn't take props can in fact be the starting point into it's own (micro-)application. But I think the biggest difficulties are external influences for an SPA - <USER2> interconnected influences that make the web so attractive for an application.

EDIT: typo

</comment></comment><comment><USER17> Wow, this page made my top icon tray in Android turn pink. What is the CSS property responsible for this? (My guess would be: background-color)

<comment><USER18> This would be the "theme-color" meta tag[1] which I think only works in Chrome on Android, at the moment.

[1]: [https://html.spec.whatwg.org/multipage/semantics.html#meta-t...](https://html.spec.whatwg.org/multipage/semantics.html#meta- theme-color)

</comment></comment><comment><USER19> On the principle that you can solve every problem in computer science by adding a layer of indirection, we solved all the problems listed in that Dan Abramov article by adding a few layers of indirection.

You didn't write a fetch ever, you subscribed to a data feed from the data feed repository.

To prevent redundant fetches, the data feed was served by a cache, which then filled cache entries by doing the fetch.

Doing a POST invalidated the whole cache.

Which triggered fetches of everything, but only once/API. The fetch return pushed out to all the subscribers. The subscription was driven by the JSX, so only visible items had active subscriptions. Essentially, you wrapped your UI with the fetcher component, during your JSX display tree into a data dependency tree.

Optimizing the cache invalidation was a problem we ignored for later, because the fetch overhead wasn't too bad, and we went from doing 40 fetches/page without the cache layer to 10, so the back end never noticed.

</comment><comment><USER17> I wonder how the author would approach the "infinite scroll" problem.

<comment><AUTHOR> That's the fun one because it's at the intersection of several of these problems.

<comment> 2Pacalypse- Would love to hear your thoughts as well on this! Especially with regards to remembering scroll position between route navigations in an infinite scroll component that fetches its content asynchronously.

<comment><USER20> i've thought about this some.. seems to me the url/hash route needs to tell us both the app state and UI state, but most routers dont do this

<comment><USER21> You can save arbitrary data when you push a new state with the HTML history API. This data is restored when you go back, and it does not affect the URL. Both React Router and Reach Router allow you to programmatically navigate and use this capability. I've used it on multiple occasions to restore both app state and UI state when navigating back. It's a little more work, of course. You can't just link to a simple URL. You need an event listener that creates the state object and tells the router to navigate manually. You may also need to ensure that any back buttons in your UI actually go back into the history instead of adding a new entry. It would be nice if it were easier, but once you get it working, the level of polish compared to most web apps makes it feel worth the effort.

</comment></comment></comment></comment></comment><comment><USER22> Entropy. Good point. I don't think many brought up that issue, it's either ignored (we know what we're doing) or coped with when it's too late (we knew what we're doing).

Entropy handling should be the goal for 2019 UI/Frontend engineering.

<comment><USER23> I think the reduction of the cognitive load of entropy was what propelled React (and specifically its innovation of the Virtual DOM) to be the most widely-used front-end framework. Being able to write a function transforming state to a description of the view, without having to worry about getting from whatever the view currently looks like to what you want it to look like, is a huge advantage.

It can certainly still be greatly improved, but I think we've already made great strides in entropy handling on the front-end in recent years.

<comment> c-smile > innovation of the Virtual DOM

Virtual DOM is rather a desperate move - to support components life time constructor/destructor events componentWill/DidMount / Unmount.

What if you will be able to define in standard HTML/CSS something like this (as it is supported natively in Sciter)

       // css
       div.mycomponent {
         behavior: MyComponent url(components.js);
       }
       // script in components.js
       class MyComponent : Element {
         function attached() { /*constructor*/ }
         function detached() { /*destructor*/ }
         … other custom component specific methods …
       }

With that simple mechanism you don't need virtual DOM and its overhead at all. Component binding requires only inclusion of that CSS.

<comment><USER24> If I am not mistaken, Houdini will allow similar features.

But it is still far away from standardization.

<comment> c-smile > still far away from standardization.

Sciter uses this feature almost 10 years.

All these 10 years we have libraries of reusable components and so no need for React.

Same is about flexbox and grid: [https://terrainformatica.com/2018/12/11/10-years-of- flexboxi...](https://terrainformatica.com/2018/12/11/10-years-of-flexboxing/)

<comment><USER24> Well, native has it even longer (WPF behaviors and grid), but I have to put up with Web for most of my projects.

<comment> c-smile Sciter was used in production 1 year before WPF appearance: [https://sciter.com/sciter/sciter-vs-wpf/](https://sciter.com/sciter/sciter- vs-wpf/)

</comment></comment></comment></comment></comment></comment></comment><comment><USER25> My experience with this type of intricate UI engineering is that often agencies and UI/UX consultants sell this romantic idea and fail miserably to execute on it. It is either that the agency way over extends itself on the theory that they leave no room in the budget for proper execution or the front end devs do not have the experience to do it right.

</comment><comment><USER26> One example of hard problem in UI Engineering: Accessibility. In github markdown editor, we can format code by wrapping with ``` . But after that, what happens if we press Tab ? Should the code indent, or the focus move outside of the editor ? It's confusing and annoying currently to move the focus outside of editor.

</comment><comment><USER27> Is there any book that actually cover those problems from a technical view point? Not from a UX/designer perspective

</comment><comment><USER28> The points are nice, it would be amazing if the 90% of the web wasn't dumpster fire of inconsistent slow and hard to use sites.

</comment><comment><USER29> Re: Entropy I was looking at a responsive thermostat component with an on/off control with a 4-state on/off button for a web miner. It had a ticker which displayed two metrics updating at time and framerate intervals intervals with time-based device status interstitials in multiple languages. XState is great for testing these situations.

</comment><comment><USER30> UI enginerring is what is to be taught in universities</comment>


Why I left Pivotal - <AUTHOR> http://jeremiahshackelford.com/post/89785894621/pivotallabsrip <comment><USER2> If you get fired, that's not really the same as leaving. I can see if his post was about how he became disillusioned with the company and decided to leave but the reality is that he got let go so this comes off as a "I got fired so here's my rant about how bad this company is." Regardless of what happened, I think companies would be hard pressed to hire someone that does things like this.

<comment><USER3> he was being creative on how we titled his article you know.. He knew he was fired.

</comment></comment><comment><USER4> Well, as recent as today, Pivotal has been pretty great to startups (ours included).

jshack, I'm sure you don't remember me, but we started running into each other at the same events starting 5 years ago while you were at Sun. I would attempt to socialize with you for the first few events until it became crystal clear that you saw no value in talking with me. You were never interested in helping startups outside of a direct benefit to you- the opposite view shared by most of the SF startup community.

You went on to work at mt for awhile where again I would see you at events, only interested in helping the latest series a/b company and ignoring everyone else.

I'm somehow not surprised by this "news".

In any case, this blog post should probably come down. Nothing good can come of it and in a weeks time you'll surely regret posting it.

Best of luck and I hope you come away learning something from all of this.

</comment><comment><USER5> I don't understand why anyone would post something like this. It cannot help you, it can only hurt you. It may be cathartic, but venting to a friend is probably much more productive.

<comment><USER6> Seriously, be professional and don't burn any bridges. It's something you learn the hard way I guess.

<comment><USER7> I'm willing to bet that jshack just lost his job today and isn't thinking quite clearly.

I can't think of a reason why a company would let you go without an exit interview though, that's rather unprofessional.

</comment></comment></comment><comment><USER8> This type story would make me hesitant to hire him after throwing his last employer under the bus (the usual response to this type of article). But with only one side of the story...you can't draw too many conclusions.

I checked his linkedin and it looks like he was at Pivotal from March to sometime recently. Lots of details are brushed over in this post so...maybe a more extensive post-mortem would be helpful.

<comment><USER5> Most employment or termination agreements I've seen have non-disparagement clauses that specifically prohibit this kind of post as well. (Although who knows if it would be enforced or could be enforced).

<comment><USER9> usually those kinds of contracts are presented with guaranty of a severence package or at least a single big check, which is supposed to ameliorate/attenuate any hard feelings. nobody can coerce you to sign something like that, and besides, the enforceability of those contracts is dubious (outside of normal libel/slander laws) so they want you to take the money and happily leave.

there's also supposed to be an exit interview in which you are told why you are being let go and the details of the above. this is also designed to prevent anger. people, even when losing their jobs, respond well to truth and money.

and in my experience it usually works fine, but in this case, it doesn't sound like either happened. or maybe he refused the contract and hence, refused the money. that's certainly possible.

</comment></comment></comment><comment><USER10> Explain "stirred the pot." Most companies hire new employees to perform certain tasks, not "stir the pot."

Unless you have something specific to share as to how or why Pivotal wronged you, this blog post comes off as vindictive and, frankly, not very well thought out. I suspect that pretty much everyone reading it is a bit confused as to your point.

</comment><comment><USER11> I'm sorry you were fired without any hint that your performance was an issue - that's poor management. But the rest of the post confused me (the metaphors didn't help) - are you concluding from your termination that the old Pivotal is dead and has been replaced by an evil enterprise hell-bent on sucking money from "legacy" software companies? Seems like a bit of a stretch.

For my part I use Pivotal Tracker daily and have got a lot of value out of it. I'm not completely sold on the new design (although the multiple project view is great) but I've really seen nothing to indicate that Pivotal has gone bad or sold their soul somehow.

<comment><USER5> Bear in mind that Pivotal Tracker is a very tiny part of what Pivotal Labs does. It's simply their internal tool released to the public. I imagine most of what OP is referring to is related to their software development consulting services.

</comment></comment><comment><USER12> I've hired a lot of people in the past. One of the most important questions I ask is "why did you leave your company X?"

I don't really care about the reason, I care about how they handled it. Whether they leave voluntarily or are forced out, there's always a telling tale there.

People rarely ever feel they've been fired "justly". Some people get on with their lives and some people set fire to the building on the way out the door. The only thing for certain is that everyone leaves eventually...

</comment><comment><USER13> I'd be interested in hearing more about the practices you engaged in that 'blurred the lines between startup and corporate marketing'. I personally have always found that after something like this waiting a few weeks and giving yourself an honest postmortem evaluation can go miles in helping you improve and strive for greater things in the future.

</comment><comment><USER14> > _I came into Pivotal Labs a few months ago excited and passionate, and I am > now leaving Pivotal bewildered and dumbfounded. (...) The Pivotal Labs I > knew, I respected, I admired is no longer. This would not have happened > there. It was not how they conducted business._

Sorry, but you came into the company "a few months ago" as you say.

It's not like you were in IBM in the nineties, and now IBM is all different etc. Or like you were in Google in 2000 and now you're dissapointed with how they turned.

What was this mythical "Pivotal Labs" you "knew, respected and admired", and when did you have time to get to know it before it changed? In "a few months"?

Mind you, I'm not saying Pivotal is good, or your story is not accurate. Just that the narrative of "the company I knew and admired is no more", when you just had a very short time to get acquainted with the company. Perhaps the company was that bad all along.

</comment><comment><USER15> Can someone summarize this using less grandiose/mystical language? It seems like he has a point but I just don't feel like wading through the analogies. That said I am sympathetic to his position as I know multiple people involved in different startups who say that the Pivotal consultants they see today can't hold a candle to the Pivots they worked with five years ago.

</comment><comment><USER16> I just left Pivotal Labs myself, albeit a bit more voluntarily (after seven years), and Jeremiah isn't completely wrong, but he seems to think he's seen a huge change over his three months working there in a role that is hardly one of Pivotal's core competencies.

From a former Labs perspective, Pivotal can really be thought of as several distinct groups working within the same office spaces. There is the one that the audience here is most likely to know; Pivotal Tracker. Then there is the consultancy, Pivotal Labs. Finally, there is the overall Pivotal organization (including elements of VMWare, EMC, Greenplum, and other EMC properties) focused on creating CloudFoundry.

Pivotal Tracker was, for a long time, written by consulting Pivots during time unallocated to any specific client. More recently, Pivotal Labs realized the value of the product, and divided off an entire office (as well as some support from other offices) to work solely on Tracker. For the closest thing to a startup experience within Pivotal (as opposed to consulting), working for Tracker is where to be.

The consulting practice has always been the core of the Labs business. Every office (save the Tracker HQ) has some amount of consulting Pivots, and any new office is established with 66%+ consulting personnel with the intent to gain traction within the startup market of the new city. Pivotal has _always_ consulted for both startups and enterprise level clients, and I take issue with Jeremiah's assertion that Pivotal has lost its way with regard to types of client engagement. He simply has no idea. As recently as Dec-Feb I was leading a team of a brand new startup through a Rails+Backbone rewrite of their existing PHP/Codeigniter app that they had decided they had outgrown; my engagements directly before and after that were both for established companies (enterprise, even) that needed specific software expertise and/or assistance with process within their corporate structure.

The final group is those devoted to CloudFoundry. The interesting thing here is that the developers and project managers (and to some extent the designers, though CloudFoundry needs very little visual design relative to its backend complexity - think Heroku) come as a mix of dedicated employees OF CloudFoundry, as well as support from consulting Pivots who are between projects or have a specific skill that can contribute to progress of CF. Consulting Pivots are told that they always have the option to rotate back out to non-CF projects, though there can be up to a couple of months of waiting while a suitable project or suitable replacement can be found. Let's be honest, EMC has given the directive from the top that CF must be delivered sooner rather than later, and that it is more important to EMC and Pivotal (not Labs, just Pivotal) that CF is delivered than that Labs engage yet another client.

So let's talk about Jeremiah:

Jeremiah was in marketing, which means he was almost certainly part of the CloudFoundry section of the company (the other branches barely know what marketing is), which has always been interested in delivering their service for use with startups, but in my opinion, is still at least 6-9 months from having enough stability and enough service integrations to be useful for anything more than a demo environment. I haven't tried deploying to CF in at least 4 months, so YMMV, and it's likely a lot more stable and well-rounded than I remember. Jeremiah talks about how he "stirred the pot on the distinction between corporate and startup marketing", which sounds to me like he was really much more interested in the consulting branch of the company and the startups involved therein, not the cloud services part. Consulting pivots probably make up 70% of each Pivotal Labs office, on the average, though there are many offices for EMC and Pivotal that contain no consultants from Labs at all. I remember being at a CloudFoundry all-hands meeting over a year ago wherein the number two director of CF specifically said that startups and the community at large around CF is secondary (or worse) to delivering an enterprise-ready solution for some rather large, well-known interested parties. Pivotal is exactly the three-letter acronym that Jeremiah "[does] not trust", but it has never not been. Pivotal Labs may share a space and employees with Pivotal, but it remains a noticeably distinct entity. With EMC's purchase of Labs and subsequent spinoff of Pivotal, things became increasingly more corporate, but that has been true since March of 2012, a good two years before the glory days that Jeremiah so fondly remembers.

Now for me, why did I leave Pivotal? I was getting tired of working on the same early-stage startup code every other project, punctuated by rescue missions for larger (Fortune500) companies who had no interest in the process and discipline practices that Pivotal can teach (pairing, tdd, stable/reasonable hours, tracker stories) and really just wanted us to shut up and fix their damn code. Pivotal Labs has been taking more clients with mobile development needs as well, and my disinterest in coding for iOS or Android made it feel as good a time as any to walk away and take my chances on building something that I actually want to use in the technology that I like to use. Will I ever be back at Pivotal Labs? Probably, though I'll be making sure I choose an office on the frontier, working with companies in a new market, as far away from a CloudFoundry-focused office as I can get.

EDIT: A note about management in Labs: The communication within Labs itself has always been great; very little bullshit, very little waiting to find out something that is important to you, if someone can help you find it out. The managers for the devs at Labs are all either current or former Labs developers (some are now full-time management, some are devs for CF, and the majority still consult 36 hours a week). They understand their developers very well, and to a person would not let such an incident happen under their watch. That said, CloudFoundry and the Pivotal top level organization have entirely unrelated (and unknown to me) management structures, the bulk of which was likely inherited from EMC (as were the PR/Marketing/HR/ and some other departments.)

<comment><USER17> Thanks for a thoughtful comment that provided way more information and classiness then the OP's

</comment></comment><comment><USER18> I always recommend this book to people that feel they're about to be canned, or who were canned but can't figure out why. It seems you know the cause when you wrote:

"I stirred the pot on the distinction between corporate and startup marketing to be sure."

Here's the book: [http://www.amazon.com/How-To-Survive-In- Organization/dp/1933...](http://www.amazon.com/How-To-Survive-In- Organization/dp/1933909196)

It's one of those books everybody reads but nobody says they are reading.

</comment><comment><USER19> "After all, patches are themselves a sign of the legacy that will be surpassed"

I think there are plenty of cases that refute this - just a sampling of nonsense.

</comment><comment><USER20> I think he is talking about Pivotal's PAAS product targeted towards enterprises based on cloud foundry and how it won't be able to compete (since cloud foundry came out before all the coreos/fleet/etcd/docker buzz and it doesn't really have those nice primitives to work with and instead has it's own hairy java solutions to those problems).

<comment><USER21> There is only one smallish Java component (an OAuth implementation). Everything else in CloudFoundry is Ruby and (increasingly) Go.

</comment></comment><comment><USER22> It is usually not in anyones interest to open a discussion about why someone is being let go. "Then just tell me why, so I know" you might say. Well, the problem with that is it is just human nature to argue it and it is no good for anyone.

The post is terrible though and serves no purpose other than to try to make your previous company look bad.

</comment><comment><USER23> What a perplexing combination of emotions. Sorry you got laid off, but it sounds like you're upset at losing your job and therefore have concluded that your job is not what you thought it was.

Much like the author, I am left asking "why?" with no good explanation being given.

</comment><comment><USER24> This sounds like sour grapes. I have no insight into Pivotal Labs except that we have used Pivotal Tracker for quite some time for our startup. Unless there's some major pricing change is coming, I don't see what about them is considered unfriendly to startups?

<comment><USER25> Tracker is one thing that Labs offers, but our bread and butter is actually consulting and co-development. Tracker is the tool that was developed in-house and then opened up for outside developers.

I didn't really _get_ Tracker until I started at Pivotal Labs. Now I wish everything else was more like it.

<comment><USER24> Ah, interesting. Our team came from using more traditional tracking systems and Pivotal Tracker got us re-thinking our strategy. We're not big enough to do full-blown SCRUM but Tracker been a huge help with managing our release cycle. It's a great product!

</comment></comment></comment><comment><USER26> Pretty common for companies to have a 90 day probation period for new hires where they can fire you for any reason or no reason at all. Would be great if employees could just walk away after 90 days with absolutely no stigma, kinda a no fault separation.

</comment><comment><USER27> I hope that jshack takes this blog post down. Even if everything in it is true, he comes out looking worse than Pivotal Labs. I understand the urge to vent, but blog posts like this make someone close to unemployable.

<comment><USER28> In case he does take it down, here's an archived copy: [https://archive.today/7u3t4](https://archive.today/7u3t4)

<comment><USER14> Why exactly would we need the "archived copy"?

Is a personal rant from someone, that might be harmful to him, that important to the internet, that we need to preserve it and keep harming the guy if he decides to take it down?

This is how internet bullying sometimes leads to suicides.

<comment><USER29> _This is how internet bullying sometimes leads to suicides._

No it isn't.

<comment><USER14> Really?

Was refering to "if he takes it down, here's a copy". Implicit in "he takes it down" would be his having regret posting it, and wish for it to be forgotten.

This kind of thing -- personal stuff a person wishes to take back that are multiplied and made available for no reason by gossipy eavesdropers is part of cyber bullying too. "Hey, I can hurt this guys with a simple copy/paste. Why not do it?". In high profile cases, they'll even cite the Streisand effect, as if that justifies what they do.

<comment><USER27> I like the way that you think. Thanks for these comments!

</comment></comment></comment></comment></comment></comment><comment><USER30> [Review Quiz] Jeremiah Shackelford _left_ Pivotal Labs because: (a) He was told to leave (b) He was terminated (c) Security would have forced him to had he attempted to remain (d) All of the above.

</comment><comment><USER31> Hmmm. I get on with the software, it's better than almost every other piece of software I've used along these lines. I've yet to use it in a big team but I imagine it's fantastic.

</comment><comment><USER32> What's wrong with selling to enterprises vs. startups? The former tend to have "money".

</comment><comment><USER33> Pivotal works fine for this startup. _shrug_

</comment><comment><USER34> A few years ago I interviewed at a startup that was operating out of Pivotal Labs in San Francisco and during the process I was interviewed by the management at Pivotal. They were really nice folks, as was the team I was interviewing with. I didn't end up working there, but I did learn something from asking questions and seeing how they operate. Their philosophy, or core operating principle has to do with the value they perceive in "pair programming". This is fine if it's what floats their boat but I was left with the distinct impression that within such a paradigm the "social compatibility issues" are raised to a level of importance that becomes a nuisance in an environment where technical proficiency is in high demand.

When reviewing a team member in an open source project or a remote team working on a startup you only have to worry about "is this person technically competent and professional+expressive in his 'on the record' interactions ?" This is all that matters because there is very little "off the record" communication since it almost all occurs in hipchat, basecamp, git, etc. Contrast this to a pair-programming paradigm where there's so many more human factors that come into play because the programmers are expected to "hang out" and engage in lots of friendly "off the record" banter and social stuff. All of these extra social expectations can introduce friction, drama, and political wrangling into the team, so the management at these pair-programming shops have to go to great lengths to try to reduce these potentials.

For example during the interview process at Pivotal, after I had hung out for most of the morning I was encouraged take a walk outside of the office with some of the Pivotal team, to grab coffee, which is fine, but apparently this is a strategic part of the interview process where they go ahead and try to bait the candidate into discussing political 'hot button' issues as part of a fishing expedition. I don't think they cared one way or another what my political opinions were but rather they wanted to measure how "sensitive" I was in relation to various subjects areas and get a feel for how easy or difficult it would be to provoke me into a rant. By subtly putting their own opinions out there unnecessarily in a more casual coffee shop environment they were trying to lure me into opening up to them in a way that wouldn't be appropriate over say hipchat or some other "on the record" medium, and I suspected that if I had expressed too much of an opinion of my own that would have been a huge red flag to them.

I understand why this particular factor would be so important to management at a pair-programming shop. It would be a disaster if a programmer started pairing with a team, made major contributions, became a significant factor in the success of the project, and then for whatever reason during the "forced cohabitation" ended up making some quasi-political or religious statement which led to animosity and disrupted the harmony of the team. This is the double edged sword that comes with trying to setup an environment that feels half like a business and half like a hip afterhours lounge. Which is it ? Are you trying to be friends or coworkers ? Friends open up to eachother when nudged to do so but is it secretly a trap where a jealous coworker is trying to lure you into making unprofessional statements to be used against you later in a conversation with the rest of the stakeholders or are you just being paranoid ? This is how the drama starts. It's risky to not "try to become friends" but it's also risky to "try to become friends" because it means opening up to your actual opinions about how you see the world which could _gasp_ turn out to be controversial.

All of this precipitates what I like to refer to as "bullshit emotional drama" that just isn't a factor when you work in remote teams. Why ? Because when you work remotely all of your conversation is logged right there in hipchat so you can't be baited into saying controversial things without there being evidence of the baiting. So either the baiting is there on the record, or there was no baiting and you were being unprofessional by putting controversial opinions out there for no reason. Either way you're being judged solely based on an accurate record of the conversation so there's no ambiguity, no people misquoting you, no need for interview processes that consist of dishonest baiting. There's less "he said she said" drama.

I don't buy the idea that you need pair-programming in order to break down knowledge silos because it's clearly not the case in a ton of open source projects where everyone is remote. Imho it's not difficult to get all of the goodness about pair programming without being physically next to someone simply by having a continuous conversation going in hipchat, constantly sharing gists, and reviewing each other's commits. The rest is just sociological posturing for the sake of having a "hip" co-working space to show off to your friends. As for the idea that members of remote teams have no social life, that's nonsense because you can go hang out in a co-working space just to make friends while keeping any friendship-exploration-drama-potentials well away from your business and economic bottom line.

tldr; Remote teams have an edge :) It's only a matter of time before remote accelerators come online and start dominating if they're not already secretly doing so.

<comment><USER25> I think you're imagining things that don't happen based on a single day's exposure.

I've never seen personal drama at Pivotal Labs. Sure, I find that everyone has a different tempo, persona and so on. That means each pairing takes time to establish a workable rhythm. But I've never seen it come to animosity, either with myself and another pivot or anywhere in the offices I've worked in or visited.

<comment><USER34> yeah I can't say much about Pivotal labs aside from the unusual interview that I was a part of and the conclusions that I drew from that experience. It's certainly possible that I was imagining things but I strongly suspect they were poking and prodding to gauge my level of "reactivity" to various political statements. I understand why they felt the need to make me jump through those hoops. They felt the need to try to filter out ahead of time those individuals who are likely to express strong or controversial opinions during the course of their total engagement with the company. This makes sense because to run a pair-programming shop you have to try to build a community of relatively like-minded people who "get along" sort of like you're running a college fraternity. Polarizing issues/debates can lead to friction within these tight-knit fraternal organizations so it does make sense to try to weed out individuals who don't already have an understanding about that, and how else could you do it if not by testing them ?

I'm not saying they did something untoward in their interviewing process I'm merely pointing out that this whole hidden layer of social filtering must out of necessity exist in pair-programming organizations in order to nip drama- potentials in the bud before they have a chance to come to fruition. This is something that remote work shops simply don't have to worry about which is a major strategic advantage currently misunderstood in the popular tech media space but extremely well understood by those who are actually running successful remote teams.

In other words because their core programming methodology (pair-programming) involves forcing individuals to share more casual interaction than what would normally occur in a traditional office environment organizations like Pivotal are forced to be proactive about filtering for "casual social behavior traits" in their never-ending struggle to to maintain a harmonious drama-free zone. This puts pair-programming shops at a distinct disadvantage when it comes to sourcing talent because

A. they're drawing from a smaller talent pool, and

B. they have to care more about how the candidate behaves socially in casual 'off the record' situations.

It's my opinion that the added advantages which supposedly spring from working at the same desk with another skilled individual are more than offset by these hidden constraints which the whole business is subjecting itself to.

I didn't mean to imply that there's "emotional drama" within Pivotal labs in particular, but I did mean to imply that remote shops don't have to worry about that issue nearly as much as pair-programming shops because of the "always on the record" nature of modern group collaboration infrastructure.

I would also like to point out that the true 10x developers out there are statistically more often the personality types who are likely to express controversial opinions or touch on polarizing issues. This has been a truism throughout recorded human history when it comes to extremely brilliant individuals.

[http://37signals.com/remote](http://37signals.com/remote) < recommended reading even for pair-programming die-hards

(I'm not connected with the author of that book in any way)

<comment><USER25> > _It 's certainly possible that I was imagining things but I strongly suspect > they were poking and prodding to gauge my level of "reactivity" to various > political statements._

I'm happy to clear this up.

You were imagining things.</comment></comment></comment></comment>


How not to do a password manager - <AUTHOR> https://bughardy.me/at-this-rate-it-will-hit-the-launch-codes-in-5-3-minutes/ <comment><USER2> That is more badly done than it could have been.

However the articles primary complaints (that the pin is retrievable, and that the password database is recoverable) is always true no matter how well implemented it was. The entire concept of the application depends on Android's file permissions to stop other apps looking at the database. Once apps bypass that security, recovering the passwords is an eventual inevitability.

The pin is likely just there to stop friends & family from accessing it. The same way Android's pins and patterns aren't really "security features" as much as to stop friends and family (and casual thieves).

So overall the article isn't wrong, but even if the author fixes all of their complaints (and replaces DES with something actually secure), the app wouldn't actually be much better because the same concepts are the backbone of the security.

This all boils down to the author's decision to use a pin. If a four digit pin is the entire basis for security then it can never be made secure, even if it is hashed, even if it is encrypted, and so on. There's no number of BCrypt factors you can set to make a four digit combination secure.

So for the author to make the app more secure they would have to require the user enters a long password, but I get the sense that isn't their USP looking at their app page. Their USP is the fact it only requires a four digit pin, so therefore that is that.

The author could store the pin in a decent hash, and then encrypt the password database using e.g. AES256 but ultimately a four digit pin is a four digit pin. You cannot really fix that unless there is an actual hardware interlock (e.g. chip that checks the number and burns out after too many bad tries).

<comment><USER3> I do not completely agree with you.

Yes, the problem is still there even with scrypt or any strong hashing function. But the (s/the/one) problem here is the use of a simple PIN code ( from 4 to 8 digits ), to store securely your passwords! Why can't we set up a passphrase instead? And then use scrypt. Morover, I think that PBKDF with 10'000 iterations, as advised by OWASP ([https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet](https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet)), is better than clear-text; also if you consider just an 8 digits PIN code. Just my opinion.</comment></comment>


Managing passwords across groups with KeePass and Dropbox - <AUTHOR> http://www.htmlist.com/cool-stuff/better-group-password-management-with-keepass-dropbox/

<comment><USER2> I used keypass for about a year (on a windows machine). I now use 1password: <http://agilewebsolutions.com/products/1Password>

Not as buggy and works with chrome.

<comment><AUTHOR> I've heard good things about 1password, but we'd have to buy a license for everyone in the office (all 9 of us!), so that $30 adds up a bit. Definitely worth looking into though.</comment></comment>


TorchServe: Model Serving Library for PyTorch - <AUTHOR> https://github.com/pytorch/serve <comment><USER2> This looks like it uses multimodel server [https://github.com/awslabs/multi- model-server](https://github.com/awslabs/multi-model-server) as a base/copy pasted.

What are the differences between TorchServe and MMS? I wonder if this means AWS will not support MMS as much.</comment>


Classp: a "classier" way to parse - <AUTHOR> http://google-opensource.blogspot.com/2015/03/classp-classier-way-to-parse.html?m=0 <comment><USER2> > Parser generators are a great help in writing parsers, but they all have one > major drawback--they are based on grammars. So what's wrong with grammars? > Well ... nothing as an expository tool. When you want to diagram a complex > rule for deriving tree-like structures within a string of symbols, nothing > beats a good old-fashioned grammar. But when you want to write a computer > program to convert a string into the logical structure that it represents > and then use that logical structure for further processing, then grammars > are not ideal.

Not sure what they mean by "logical structure". But I've used Parsec to convert a string into AST. Then did a second pass with Parsec to turn that AST into VM representations of what the program is talking about. Which worked really well for me. :)

<comment><USER3> And if that's not a "logical" enough of a structure then you can skip the AST step if you really like and parse directly into the final effect.

<comment> david-gudeman By "logical structure" I mean the AST. I make this clear in the rest of the document. The point is, with Classp you don't have to write a grammar to create a parse tree and then convert to an AST; you write a specification that produces the AST directly.

</comment></comment></comment><comment><USER4> Cannot see how it's shorter and more readable than a formal grammar + AST production rules. Given that the class syntax is very bloated (unlike, say, ML ADT constructors), there is no chance a language grammar will be compact and comprehensible at a single glance.

Disclaimer: of course I'm biased, I'd oppose anything with the word "class" in it.

<comment><USER5> The cool part is, its not only a specification but an implementation.

</comment></comment><comment><USER6> Is there any formalization of how to invert a formatter, or is this just something they're figuring out in code as they go along?

<comment><USER7> I looked at the code and the manual a little bit, and it almost looks like they're just writing an object oriented style wrapper syntax around Bison and Flex. At a quick glance, I'm not sure they're really inverting a formatter as much as they're adding a "syntax(...)" attribute that tells the tool how to format the parse tree elements generated from that grammar rule.

<comment><USER8> Ha, spinning it as inversion... not very classy.

<comment><USER9> Maybe that's why "classier" is in quotes in the title.

</comment></comment></comment></comment><comment><USER10> I'll leave other commenters with more parser-writing experience to critique this... but the general concept of "Write code in the simplest-to-reason-about direction, and the system magically inverts it into a much-harder-to-reason- about algorithm" is one of my favorite patterns in computer science.

For instance, there's probabilistic programming [1], where you write a procedural program that says "if we were to fix a bunch of properties/states of the natural world and provide them as input, here's the output/reading you'd hypothetically get," and then from that, a system creates a function that, given a large number of outputs/readings, provides a posterior probability distribution over those hidden properties/states of the world. It's still far from the level of performance you'd get from hand-rolled machine learning algorithms that take advantage of all sorts of insights you have into your data... but then again, in general programming, there was a time when compiler optimizations were so naive that you had to hand-roll assembly code for almost anything. I see probabilistic programming in a similar level of infancy, and I'm excited to see where it goes, especially with the backing of a large DARPA initiative [2] to do some really exciting fundamental research.

But there's so much more to the "invertible" paradigm. SQL itself is exactly along these lines - your WHERE clause is just a filter function that works on a single-record level, but it's interpreted as highly optimized instructions to iterate along data structures, to collect all the data that satisfies that filter function. Facebook's Relay [3] is the beginning, I think, of a large push towards declaratively specifying data dependencies for web applications, and having a system that does all the heavy lifting of figuring out when to fetch data, when to push it back to the server, how to handle requests on the server, and how to handle mutations with optimistic client-side updates. All you need to think about is the easy question of "what data might I need, and if it were to exist at any given moment, how would I display it to the end user?"

Humans think generatively, whether it's about data or formatting or GUIs or the physical world. We have all these ideas in our mind, and we can visualize how we would expect them to appear. When our computer systems can let us focus on those high-value thoughts, that's what the future looks like.

So let's cut the out-of-the-box parser thinkers some slack!

[1] [http://www.pl-enthusiast.net/2014/09/08/probabilistic- progra...](http://www.pl-enthusiast.net/2014/09/08/probabilistic-programming/)

[2] [http://www.darpa.mil/our_work/i2o/programs/probabilistic_pro...](http://www.darpa.mil/our_work/i2o/programs/probabilistic_programming_for_advanced_machine_learning_%28ppaml%29.aspx)

[3] [https://gist.github.com/wincent/598fa75e22bdfa44cf47](https://gist.github.com/wincent/598fa75e22bdfa44cf47)

<comment> david-gudeman An interesting take. I've always been something of a programming-language junkie motivated by the feeling that there must be clearer, better ways to express things. Classp was motivated in large part by my dissatisfaction with having to write a recognizer and warp it into a parser and then turn the parse tree into an AST. Why can't I just express directly how the AST is represented in the target language?

</comment></comment><comment><USER11> I loved [http://llvm.org/docs/tutorial/index.html](http://llvm.org/docs/tutorial/index.html), where a parser is just build by hand. Looks surprisingly easy!</comment>


Ask HN: Who's heading to PyCon? - <AUTHOR>

Are you heading to PyCon next week? What are you most looking forward to? <comment><AUTHOR> I teach high school math and science, and I teach an intro to programming class sometimes. I'm also working on building some open tools that address long-standing inefficiencies in education. I'm looking forward to:

\- the Education Summit, which happens on Thursday; [0]

\- meeting up with the Center for Open Science team, to find out if what they're building can make high school science classes run more like teams of professional scientists; [1]

\- learning more about Docker, and figuring out whether I should be using it to deploy the apps I build;

\- Networking - it's always interesting to hear what other people are up to in the community.

[0] [https://us.pycon.org/2015/events/edusummit/](https://us.pycon.org/2015/events/edusummit/)

[1] [https://osf.io/](https://osf.io/)</comment>


Facebook are 'morally bankrupt, pathological liars' – NZ Privacy Commissioner - <AUTHOR> https://www.nzherald.co.nz/business/news/article.cfm?c_id=3&objectid=12220247 <comment><USER2> If one were to judge by the title, the commissioner and I are in excellent agreement over the gist of Facebook's character. The reasons may be different though. As much as I enjoy seeing people actually reacting to the atrocity rather than buying the vacuous spin about mistakes for what seems like the thousandth time, not censoring the communications they're parasitizing harshly enough is actually not a thing I'm willing to hold against FB.

</comment><comment><USER3> It's funny. When they were investigated they claimed they didn't engineer fb to feed off dopamine feedback systems. It's like - how bold of a lie are you able to get away with?

</comment><comment><USER4> I agree with the sentiment but for very different reasons.

I've been pursuing a reddit lookalike called tildes recently and a number of NZ and Oz people are on there. I was absolutely floored, as an American, with how okay they are with government sanctioned censorship. So in light of my recent realizations this reasoning makes a bit more sense to me, though I still can't agree with it.

</comment><comment><USER5> So I agree... but the thing is, my grandmother is going to be mad if I don't like her posts. I don't think we can fix anything about how skeezy Facebook is, but I don't think we can get anyone to mass unplug them either. Where's that leave us?

</comment><comment><USER6> Is #DontGiveAZuck an original? Because I love it!

</comment><comment><USER7> Gotta sympathise with Facebook on this one.

 _> "Facebook cannot be trusted. They are morally bankrupt pathological liars..."_

Sure.

 _> "...who enable genocide (Myanmar), facilitate foreign undermining of democratic institutions, .... [They] allow the live streaming of suicides, rapes, and murders, continue to host and publish the mosque attack video, allow advertisers to target 'Jew haters' and other hateful market segments, and refuse to accept any responsibility for any content or harm."_

I feel this is making making moral statements with great symbolic value, rather than suggesting anything with any serious practical understanding.

The article features paragraphs complaining that the obscene video is still up, but doesn't seem to understand the internet allows anti-censorship behaviour. I'd guess that FB already disallows uploading the video, but the ones which get through what the NZ Privacy Commissioner calls "the AI" must have been modified in some way.

I don't necessarily mind mainstream media (who are so influenced by FB's control over distribution) having a go at Facebook. But, a politician complaining that FB isn't doing a good enough job at censoring what's already illegal for people in NZ to consume raises flags for me.

</comment><comment><USER8> They #DontGiveAZuck. Nice one!

</comment><comment><USER9> I agree, they are morally bankrupt pathalogical liars, but as a platform, they should bear absolutely no responsibility for what their users post. Nor they should comply with any governments' request to turn over information on who shared what.

Facebook is an evil, yes, but governments are a bigger one. I trust facebook more than I trust my government, and I don't trust facebook to the extent that I've deleted my account and ublocked all their cookies and integrations.</comment>


Kubernetes v1.3 Preview – Auth, Scale, and Improved Install - <AUTHOR> https://coreos.com/blog/kubernetes-v1.3-preview.html <comment><AUTHOR> If you weren't at KubeCon in March I outlined that we were going to try and do most of the things on this list. Very nice to get them done! Really looking forward to Kubernetes v1.3, it will be a solid release.

[https://www.youtube.com/watch?v=A49xXiKZNTQ](https://www.youtube.com/watch?v=A49xXiKZNTQ)</comment>


Microsoft Azure East US experiencing a partial outage - <AUTHOR> https://azure.microsoft.com/en-us/status/ <comment><USER2> Wow.. their 'history' page reveals quite a lot of incidents

[https://azure.microsoft.com/en- us/status/#history](https://azure.microsoft.com/en-us/status/#history)

<comment><USER3> IMO, it's both more incidents and more honesty. AWS can be flaky without getting a status update.

<comment><USER2> Possible. AWS isn't exactly quick to update their systems but since that last outage in us-east that took out Netflix I don't recall anything since that has any impact in my systems and that was over a year ago.

We use S3, EC2, DynamoDB, RDS, SNS, SES, Route53, Elastic Beanstalk, Kinesis, Lambda, Elasticache, and probably even some of the others.</comment></comment></comment>


No, This Is Not the Best iPhone Ever - <AUTHOR> http://www.slate.com/articles/technology/technology/2012/09/iphone_5_dock_connector_the_one_incredibly_irksome_feature_that_will_leave_you_cursing_apple_.single.html

<comment><USER2> > What's more, this year Apple decided to go all out and aim for the "best > iPhone we've ever made," according to the parade of executives who took the > stage Wednesday. Yes, the same executive said the same thing about last > year's iPhone 4S, 2010's iPhone 4, and every other iPhone ever released. > This time they said it quite passionately, though, so I think they really > meant it.

Yes, I'm sure the creators of the product, which is faster, has a larger screen, a more high-quality screen, a better camera, an updated operating system, which is the thinnest iPhone yet, lighter than previous models...

Yes, I'm sure they were all lying to all of our faces about whether they believe this is the best iteration of the iPhone.

And then to follow that up with this?

> In truth, the iPhone 5 is a very impressive device. If you're in the market > for a new phone, you should certainly consider this one. [...] Despite its > bigger screen, the iPhone 5 is the thinnest and lightest iPhone ever made, > and the difference is palpable. I played with the device for a few minutes > after Apple's press event, and I was floored by how svelte it was compared > to older versions of the iPhone. I also love the back of the new phone, > which is made out of aluminum rather than the glass found on the back of the > 4S. The iPhone 5 feels more substantial than past versions, and it's > probably less fragile as well. This, maybe, is a phone that you might not > need to stuff into a case in order to use—if that's true, then thin and > light might really mean thin and light. [...] I've got only one major > problem with the new iPhone.

So yes, basically, your point is that the phone is better.

But apparently all of this is invalidated by the fucking plug. The plug makes Apple executives liars. It makes iPhone enthusiasts chumps. It ruins the entire device, and certainly undoes the innovation/not-innovation (?) the author is so passionate about.

This whole article is, frankly, fucking garbage. The first few paragraphs are basically trolling, and the rest of it is overdramatic. I'm an iPhone user, and yes, if I decide to upgrade, the change in plugs is probably going to be annoying. Then again, I mostly use one plug for my current phone. So maybe not that annoying after all.

This is the best iPhone ever, with an annoying plug. That's essentially what this article says, but it's awful, worthless linkbait, so that's not what the article actually SAYS.

Truly terrible.

<comment><USER3> _Truly terrible._

Naw, just truly obligatory. Remember when we were all reading a whole bunch of similarly insipid diatribes about how yes admittedly this new iPhone has X, Y, Z new things that are really pretty cool but it's still a total disappointment and doomed to be a failure because they didn't _name it_ the right thing?

I think maybe there's just something in every tech columnist's contract mandating them to go a bit silly for a week every time Apple releases a new handset.

</comment></comment><comment><USER4> The 30-pin connector is one of the longest-surviving connectors on the mobile market, but its clearly past its prime. Apple didn't change the connector just to get $30 extra out of its customers. It was an item on the phones that seriously needed changing if the size and design of the item were to be improved.

He also mentions that in the future Apple will change its dock connector again, throwing accessory makers "under the bus." I highly doubt this will happen. I highly doubt there will even be a "next" connector at all. Given the rate at which technology has progressed, In 11 years (the lifespan of the 30-pin connector) inductive charging will be omnipresent, and AirPlay-esque protocols will be the defacto way to send music between an iDevice and a dock. AirPlay is a software standard and thus can be supported indefinitely, so I imagine any phone that comes out in the future will be backwards compatible with current AirPlay docks.

<comment><USER5> They should have gone with USB though.

I'm looking forward to the day wireless just works, but I'm not sure we're any where near close yet. I still have a problem with my WiFi dropping because next door is using theirs, and that's after I picked the least congested channel.

<comment><USER6> The old dock connector, and the new "lightning" connector do a lot more that is supported by a USB connector. The dock can carry audio, video, act as a USB slave, and connect other slave devices.

Arguably, Apple could have included both ports, but that increases cost and complexity and flies in the face of the Apple aesthetic.

</comment></comment></comment><comment><USER7> That headline is serious linkbait. The main point is that the dock connector changing will be a bit inconvenient for existing owners. How does that not make it the best ever? There are so many improvements that it would be stupid to argue that the 4S is better.

</comment><comment><USER8> There's a feature of the old connector that I suspect the new skinny model is going to have trouble competing with; it was large enough to physically support the iphone vertically. I'm looking at my logitech sound dock and the only thing supporting the iphone is the connector. Maybe the thinner and lighter iphone5 will require less support but designs relying on what was probably an accidental feature will likely have to change to accommodate this. If that is the case it's a bit of a shame as there was something rather elegant about the way it could stand free. It allowed a minimalist appearance which resonated with apple's design values.

<comment><USER9> This is actually the first valid criticism of the new connector i've read all day. That was indeed a useful feature of the ild one which the new one won't likely have.

</comment></comment><comment><USER10> USB is insufficient for a dock connector. It doesn't do audio or play/volume/track buttons. You could use a USB audio device, but that would add cost to every iPhone accessory made everywhere, and there's no need because the iPhone has its own audio chip inches away.

To save costs, gadget manufacturers would just use the headphone port instead, and then you'd have to plug TWO things into your iPhone to hook it up. And it wouldn't have pause or volume controls because they don't want to spend the $1 on the USB chip for that functionality.

<comment><USER11> As they said in the Apple announcement, audio and video are generally transferred wirelessly now (via AirPlay or Bluetooth). However, if the Lightning to 30-pin adapter is fully functional, and Lightning is truly all digital, that little adapter must be doing the DAC, which might explain the high cost.

</comment></comment><comment><USER12> One thing I really liked about the original 30-pin connector is that you can dangle the phone upside down, without the phone coming out of the connector.

This is the thing that turned me off of micro-USB chargers, and it's a shame if Apple abandoned this feature.

<comment><USER13> You can dangle my HTC phone perfectly well from its microUSB cable. It's something I instinctively wouldn't do, but it doesn't feel like there's any chance of it falling out.

<comment><USER5> It's the only way I can find my phone when I'm half asleep in the morning; grab the wire and prod the hanging thing.

</comment></comment></comment><comment><USER14> > No, This Is Not the Best iPhone Ever

Yes, it is.

Apple generally doesn't bother to release a new version of a product until they've managed to make it significantly better than the last version, hence nearly _every_ Apple product is "the best ever" version of that product. That earlier iPhones were "the best ever" when they were released in no way suggests that this one isn't _also_ "the best ever".

And the fact that they finally replaced the dock connector is one of the things that makes it better. They've removed that constant tiny annoyance of putting it in the wrong way, they've made a key part slightly more reliable than it was, and they've freed up more room to make products smaller or fit more stuff (including battery) in the existing space.

</comment><comment><USER15> Boo, you clickwhore.

USB-PTP is already implemented on iOS. What's the win for going to Micro-USB beyond letting you reuse your Blackberry charger?

USB-MTP is a user experience disaster. USB-MSC is a user experience disaster in the context of a sealed filesystem. And moving to Micro-USB means you can't dynamically reprogram pins to support any of your old 30-pin shit via an adapter.

So we can either have no old shit at all, or have all the old shit via a $30 adapter, or put two ports on a phone, or stick with the old shitty port that's approaching the size of the products it's used in.

<comment><USER16> > What's the win for going to Micro-USB beyond letting you reuse your > Blackberry charger?

Complying with european regulations.

<comment><USER15> True. But they already ship an adapter in every box and all regulators agree this is acceptable.

</comment></comment></comment><comment><USER11> This author awkwardly combines two distinct and incompatible arguments (that requiring a $30 adapter to use old accessories is unreasonable, and that the iPhone should use Micro-USB) and seems to think there was a synthesis of the arguments. I don't understand why the two arguments were concatenated together with the pretense that the latter somehow related to the former. Switching to Micro-USB would cause all the same incompatibilities with old accessories, and wouldn't solve any problems other than letting you borrow your friend's Android charge cable if you're caught with a low battery.

</comment><comment><USER17> Every time I see a super-cranky tech. article from Slate, it is written by Farhad Manjoo. I'm all for the contrarian viewpoint, but after a while, it just seems like trolling--or an advertisement for antidepressants.

</comment><comment><USER18> The change in screen size reminds me of some blogs and discussions here on HN, where people claimed that 3.5" was an ergonomic display limit for one-handed use of a smartphone for an average adult; so it was a perfect size after a lot of research made by Apple.

Does anybody who played with the 5 know whether Apple took any measures for one hand use to encounter the display growth to 4" in the OS or bezel, thickness or elsewhere?

<comment><USER19> I think you'll figure out what 100% of people with larger screen phones already have:

If you hold it slightly differently in your palm, your thumb can reach all of a 4" screen just as well as a 3.5" screen, and with less strain.

</comment></comment><comment><USER20> There is a mild bit of self-negation in these iPhone5 gripes: on the one hand, it's knocked for not having enough that's truly new rather than incremental; on the other the one completely novel break-with-the-past, the 'lightning' connector, gets singled out as a negative.

When you go with Apple, you're along for the ride on their obsolescence decisions. There is never a great time for such discontinuities: you have to take the hit sometime, and putting it off would just mean an even larger ecosystem on the original connector.

Yes, Apple has gone their own way here... but matching the commodity/common- denominator practice has _never_ been Apple's emphasis. I know that controlling/taxing the aftermarket is one part of their choice... but the size, durability, and reversibility of the connector will be offsetting benefits. (And an off-brand micro-USB-to-lightning adapter will probably be even smaller and cheaper than the 30-pin-to-lightning adapter.)

<comment><USER21> It's still not USB, when it really should have been.

There's no excuse for having a proprietary connector, now not even for Apple.

<comment><USER20> Could it have been as thin with USB? Could it have never required fumbling with mismatched-side-rotation in the dark?

You might not like the excuses but they exist beyond "no excuse". And the required micro-USB adapter will likely be tiny and cheap: just affix it to the end of your micro-USB cord.

<comment><USER3> USB is my least favorite connector, aside from the old iPhone connector. In all its form factors it's universally difficult to get hooked up without physically looking at the plug and the socket, and it seems to break too often. Worse yet, most people I know can barely even tell the different versions apart, and often figure out if a USB cord is compatible with a device by just trying to jam it in and see if it fits.

The new lightning connector looks like it offers much better ergonomics and better durability than any of the existing USB plugs. So I'm happy to see connectors going in this direction. Let's see the USB standard copy the idea.

</comment></comment></comment></comment><comment><USER22> But a perfect opportunity to make some cash off 30pin to 8pin connector converters ...</comment>


Show HN: Pairjam – pair programming in your browser - <AUTHOR> http://pairjam.com

<comment><USER2> Very nice and seamless UI! I hope to use this sometime soon. Like other mention, closer repo access would be awesome (I suppose you'll have to authenticate with GitHub for that?). Support for BitBucket would be nice, as well.

</comment><comment><USER3> Nice project! How about an option to text chat? Or did I miss it? Shared it: [http://tuxdiary.com/2014/09/23/pairjam/](http://tuxdiary.com/2014/09/23/pairjam/)

<comment><AUTHOR> Thanks for sharing. No text chat at the moment

</comment></comment><comment><AUTHOR> Developer here. Would love to hear your feedback, especially on what could be improved.

Tweet @neerajwahi if you'd like someone to try it out with.

<comment><USER4> Very nice! I would love to see something like this that compiles and gives the output in realtime, even if it is only done on the client. Would be very handy for tech-screens.

<comment><AUTHOR> Thanks! That's a great suggestion, I've been looking into using docker containers to create an isolated runtime environment.

</comment></comment></comment><comment><USER5> This is really cool. Are you planning to support closed repos?

<comment><AUTHOR> Thanks! No immediate plans for closed repos, but that's definitely something on the radar</comment></comment>


Clojure is Imperative - momo-reina http://www.lispcast.com/clojure-is-imperative <comment><AUTHOR> "imperative" does not seem like a good/valuable characterization. Yes, the "do" form is imperative. That's why you're not supposed to use it much, perhaps only for the top-level structure of your program, the part that acts as an interpreter to connect the pure program to the outside world. _When you express business logic in a language like clojure_ , that expression of the business logic is not usually "a sequence of commands executed in order". It usually looks more like "an expression tree and rules for how nodes are evaluated".

The downside of a simple, transparent language like lisp is that it exposes you to the dangerous parts of the underlying. An opaque abstraction (e.g. expressing database operations as a tree of operations some of which define transaction boundaries, rather than as a series of SQL commands some of which open or close transactions) is vital for transforming dangerous things into safe things. Ultimately a program looks like an expression of business-level logic and then an opaque layer that pretends the computer is actually a machine that understands your business. Lisp forces you to provide more of that opacity yourself, whereas a language that already has a vocabulary for drawing distinctions between different kinds of thing provides you some of the scaffolding you need (the tradeoff being of course that it will be less specialized to your particular circumstances).

</comment><comment><USER2> Just because Clojure has the DO form (or that Common Lisp has the PROG form) doesn't mean that the language _is_ imperative. It means that it _allows_ imperative programming.

This is like saying that a language with casts doesn't have a type system. No, it has a type system, it just also has an escape hatch that lets you break out from the type system when you need to. Lisps' functional-ness is generally the same sort of thing: They are designed primarily around function-oriented programming, but provide straightforward escape hatches into imperative programming. Common Lisp tends more towards being multi-paradigm than Clojure (i.e. provides more imperative accommodations), but both have strict evaluation, which the author seems to equate with imperative-ness.

The author spends more time talking about a small core and non-leaky abstractions than about imperative-ness. On these points, I totally agree and think it's a well-written article. I don't exactly see the connection with being imperative, and I think it's a shame that the title will draw attention away from those points. The thing that I really like about working in Clojure is how the abstractions are built with care: I feel like whenever I just use the base building blocks, they fit together seamlessly and edge cases usually don't come up.

<comment><USER3> Are you saying that languages aren't imperative or declarative but programs are?

<comment><USER2> Eh... somewhat.

I do think that it's meaningful to describe a _program_ as being imperative or declarative or object-oriented or functional or strongly-typed or whatever, and that determination can be separate from the language that the program was written in (up to a point). See also, "writing COBOL in any language."

But just because those descriptions apply to programs, that doesn't mean that they are inapplicable to languages. At the least, those languages can be described in terms what types of programs they _allow_ and what types they _encourage_ , and how strongly. What programs they allow is a question mostly of features, but what they encourage is more complicated question that often involves the culture and ecosystem as much as the syntax or standard library.

E.g., Haskell encourages functional, strongly-typed programs. It's possible to write an imperative, weakly-typed program by using a lot of monads and passing data between modules as serialized strings. But that program is massively cutting against the grain, so to speak, so it's still meaningful to describe Haskell as functional and strongly-typed. Common Lisp functions naturally fit together into a functional program, but it's nowhere near as difficult or counter-intuitive to write an imperative program, so Common Lisp can lay better claim to being multi-paradigm.

I do think that programs are the primary things that are described as imperative or whatever. Languages are better-described by the programs they encourage rather than the features they have. For example, JavaScript and Ruby have all the features common to (dynamically-typed) functional languages (closures, lambdas, functions-as-values, etc), but that's not the type of program that is easiest to write in either language. That's why most people don't describe JavaScript as a functional language, even though there are certainly functional programs written in it.

</comment></comment></comment><comment><USER4> From what I've read, the exact definitions of imperative and declarative vary a lot. The most useful rule of thumb I've come across is to consider imperative to be concerned with HOW something is to be done, while declarative concerns primarily WHAT is supposed to be done.

SQL is usually classified as declarative in that you're not telling the database how to retrieve the top ten entries from a table - you're merely informing it that you are interested in those entries.

It struck me at some point that this definition must be relative to the level of abstraction you're operating at. For example, when using (go …) blocks, I'm declaring that I want the code contained within the block to be processed asynchronously, but I'm not describing how that is to be done. Perhaps a callback might be described as being "more imperative" since it contains more implementation details?

So, am I correct in thinking that this discussion would hinge on what you consider to be "concrete" and not? That something executes in sequence is hardly enough to decide whether it is to be considered declarative or imperative in nature.

<comment><USER5> Declarative is what we'd like programming to be in the future. At the highest level we could say "Computer, make me a first person shooter set in WW2" and receive a ready to play game from that.

<comment><USER6> "Make me a..." is clearly imperative.

</comment></comment></comment><comment><USER7> _You would only want to execute an expression and throw away its value for its side effects._

Useful for IO as there's normally nothing I want to pass the value of a println expression to, evaluating already prints it to stdout. Also useful for mutation, but doing this in Clojure feels wrong since the immutable data structures are among the language's greatest strengths.

<comment><USER8> Do you not care if your output succeeded ?

<comment><USER7> It honestly hadn't occurred to me that printing to stdout could fail, or that I'd need to check its return value to ensure it was successful. Can you think of an situation where that might happen? And if so, why doesn't println throw an exception?

On the other hand, a side effect like writing to a file or inserting to a database can easily fail, but those of course throw exceptions.

<comment><USER9> Output redirected to a file and file being already closed, for one. Or anyway, stdout being closed midway due to many other possible reasons: this is (probably) why printf returns a number of bytes written or -1, for example: [http://www.cplusplus.com/reference/cstdio/printf/](http://www.cplusplus.com/reference/cstdio/printf/)

</comment></comment></comment></comment><comment><USER6> "Imperative" isn't really a binary feature of programming languages, the imperative-declarative axes is more a continuous axes of variation describing code (which can be applied to languages, as well, as a general characterization of code written in the language.)

And, while its certainly possible to write very imperative code in clojure (or even Haskell!), idiomatic clojure is more declarative and less imperative than most popular languages, so, I think, on balance, "is imperative" is not a useful description.

That being said, in most "declarative" languages, there still remains the risk of being bitten by issues related to order of operations and structure of the code that aren't apparent if you view the code as _purely_ declarative statements of intent rather than as to some degree imperative instructions. And if you call anything that presents that issue as "imperative", virtually _all_ programming languages are "imperative".

<comment><USER10> _' That being said, in most "declarative" languages, there still remains the risk of being bitten by issues related to order of operations and structure of the code that aren't apparent if you view the code as purely declarative statements of intent rather than as to some degree imperative instructions. And if you call anything that presents that issue as "imperative", virtually all programming languages are "imperative".'_

Yeah, particularly painful is massaging something purportedly "declarative" in order to get particular operational semantics out of it.

I sometimes dream of a future language that will have a denotational layer separated from an operational one, with each playing off the other. In the limit, you can implement things entirely in the denotational and the compiler will fill in the operational details - but when that breaks down you have the option to specify _how_ it works in a way that's _built for_ specifying how it works (and, ideally, then _checked against_ your declarative specification). Ideally here, you can express arbitrarily strong or weak _constraints_ upon both and the compiler will say "done", or "I don't see how", or "I can prove that's impossible."

</comment></comment><comment><USER11> I just started learning Clojure, so I don't really understand this article very well. Is Clojure significantly different from other LISPs (e.g. Racket)?

<comment><USER12> The author of this article is straining logic to argue that Clojure is not a functional language. It's true that Clojure is not a _purely_ functional language, but most people should already know that. Unlike Haskell, Clojure allows side affects in code. It exposes the underlying Java platform 'transparently' which is definitely imperative. In that respect it's not too much different from other Lisps which allow side affects and generally have an FFI of some sort for working with imperative code written in other languages.

Unlike other Lisps, though, Clojure's core semantics are very strongly functional. All of Clojure's core data structures and types are immutable and to have mutable state you need to resort to reference types with special semantics to have mutable state. It would be uncomfortable to write Clojure code in a primarily imperative fashion. Common Lisp by contrast has no problem with imperative code or mutable state.

<comment><USER11> Ah, thanks. It does look pretty functional from my limited experience so far, plus I think these debates are very academic. You can write purely functional Python if you want, it's just going to be neither easy nor practical.

</comment></comment></comment><comment><USER13> Which language is not imperative then? The only program writtten in non- imperative language I can think of would return random values (of random type, also not known to mankind, including total destruction and creation of life) and crashed avery second function call.

<comment><USER14> prolog, for one.

<comment><USER13> Prolog functions are a little more advanced 'if' statements. Flow of the execution is always the same. Data may be processed in a different order, but the rest is purely imperative. Logic never changes.

<comment><USER7> You're implying that the opposite of "imperative" is "nondeterministic." That's incorrect.

Prolog is _declarative_ as opposed to imperative. User source code declares rules/constraints, and the Prolog compiler performs a search algorithm to arrive at a solution that satisfies the constraints.

<comment><USER13> I exaggerated a little with this randomness.

Let me explain:

Given the same input Prolog program and imperative (Pascal?) one will give the same results. Because Prolog is imperative.

Non-imparative languages give estimated results (actually I don't know any of these). Why? Because for example data is too large to do simple things like counting all elements. Thats non-imperative. Result is no longer based on what is in the data space, but based on its characteristics. For example, you may calculate a number of helium atoms in a cubic inch, but you will never do such thing like counting them one by one (imperative way).

<comment><USER14> aminit I am not sure if you know what imperative means.

Imperative programs have a state or virtual machine that is manipulated by the program. All programs, at heart, are imperative, but higher level constructs allow for procedural or declarative programming which abstracts away the lower-level imperative bits.

        // Imperative
        if(foo == 'Tuesday') {
            print 'Taco Tuesday';
        }

        // Procedural
        if(isTacoTuesday(foo)) {
            writeTacoTuesday();
        }

        // Functional (but not monadic)
        (if (eq foo 'Tuesday') (print 'Taco Tuesday'))

        // Declarative
        taco_tuesday : foo == 'Tuesday'
        run : ( taco_tuesday -> write('Taco Tuesday') ; true )
        run;

No I have not had lunch yet.

<comment><USER7> Nice.

I like this more for a functional idiom:

        case foo of
            TUESDAY => "Taco Tuesday"
            | _ => "Not Taco Tuesday"

Or this:

        (cond (= foo TUESDAY)
            ("Taco Tuesday")
            ("Not Taco Tuesday"))

_All programs, at heart, are imperative_

Yes, but only because the underlying machine architecture is imperative, right? If you had a chip that could evaluate pure functions with no mutable state (like a Lisp Machine that used a purely functional dialect of Lisp) then you could have programs with no underlying imperativeness.

But in a perhaps more relevant sense, in languages like Haskell or Prolog it is possible to write a program with no imperative state manipulation happening at the programmer's working level of abstraction.

Still, this really has nothing to do with determinism.

Also, I like SQL as an example of declarative programming.

        SELECT * FROM USERS
        WHERE JOIN_DATE = "20150106"

That is a declarative program; the SQL engine it's run on decides the underlying imperative implementation of the solution at runtime. It is also deterministic in that when it's run on the same database containing the same data multiple times it will return the same result.

From what I know about Prolog, I understand it's similar in this regard.

<comment><USER15> Look at your case statement. In most languages, if you swapped the order of TUESDAY and _, you'd get different results.

An actual declarative language would choose TUESDAY over _ because it's the most specific match, and not because it matched it first.

<comment><USER7> Yes, good point, but this was not meant to be an example of declarative paradigm, just functional paradigm. It's SML, which is not a particularly declarative language. Haskell is a little bit more declarative but AFAIK its pattern matching works the same way as SML.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER16> He explain his intention was another thing, and this post make it more clear, I think:

[http://www.lispcast.com/two-kinds-of- bootstrapping](http://www.lispcast.com/two-kinds-of-bootstrapping)

</comment><comment><USER17> He talks about how lisps are bootstrapped on a small core, and that is nice. Reminded me that this is the approach that Perl 6 is trying to take (NQP is the core) although on a larger and more complicated language</comment>


AVG acquires Privax, provider of HideMyAss VPN service, for $60M - <AUTHOR> http://www.zdnet.com/article/avg-acquires-desktop-mobile-privacy-firm-privax/

<comment><USER2> I just hope they don't change the branding. Well done, particularly the names of their service level packages on the pricing page.</comment>