First Look: Ubuntu 11.04 (Natty Narwhal) Beta 1 - <AUTHOR> http://www.zdnet.com/blog/hardware/first-look-ubuntu-1104-natty-narwhal-beta-1/12155

<comment><USER2> I've been using the combo OpenBox and Tint2 for a long time now, just because Gnome2.x feels bloated and I could do anything I want by editing a simple shortcut file in my config. So yea I like lightweight systems, fast and blabla.

But the other day, after having bought a new computer, I did give a go to this beta Unity.

It's definitively not my taste, BUT I can see why this was made. It's clearly simpler than anything I've tried before on Linux. The "start key" open a sort of menu, type to search apps, all in the bar make sense, I'm not fond of the global menu, but well, people seems to like it.

We have to keep in mind that it's just the first release, and it'll evolve in the future, but after having tried it I went from a complete hater to a "well ok, it has it's place".

After 2 days I moved back to my simple and light openbox/tint2 combo, but well, this is only because I'm not the target market for Unity. Unity is for people not for hackers.

</comment><comment><USER3> Actual review here: [http://www.theregister.co.uk/2011/04/01/ubuntu1004_beta_revi...](http://www.theregister.co.uk/2011/04/01/ubuntu1004_beta_review/)

</comment><comment><USER4> Two things annoy me about Unity:

1\. The menu bar at the top is now wasted space. 2\. The task bar is on the side.

Shortcuts to spreadsheet, worth authoring, etc, should be hidden away in the menu. Honestly how many new spreadsheets do you create every day? Not many. What you might do is double-click on a spreadsheet and have it open, but that doesn't require a big shiny shortcut being in the taskbar.

These are just defaults and can be changed, but still, I feel as if they are poorly considered defaults.

<comment><USER5> While I agree with your second point (although I put my taskbar/dock on the side, I have it autohide) and following paragraph, I'm not sure about the first one.

The topbar in Unity contains the menu for the currently focused window (and, in the future, hopefully the currently focused _application_ ). This vertical space had to be used anyways - the clock and some sort of notification area are essentially mandatory.

As a person who primarily uses Mac OS X, I think that the menus are the best use for the vertical space that those items provide. I can use Cmd+tab or Exposé for switching applications, so a list of the currently open windows isn't particularly relevant. By moving the menubar to a single spot, if anything we save space.

That sidebar is truly awful though.

</comment></comment><comment><USER6> Unity looks promising. Maybe I'll switch back to default Ubuntu desktop again :-)

I didn't know about Unity before this, even though I've been using Ubuntu for the last 7 years.

I used Tint2 on Openbox to get a vertical taskbar. Combined with Tree Style Tabs for Firefox it creates a consistent UI hierarchy going from left to right.

</comment><comment><USER7> Maybe Unity will finally drive me to start using a tiling window manager, like XMonad.

</comment><comment><USER8> No System Monitor applet; the current System Monitor Indicator just doesn't cut it. On my dev machine, I like watching the little graph of cpu%/ram/network/disk etc.

My netbook IS running unity w/o the System Monitor, but I rarely do heavy work there. If the thought is to switch over to Unity for more casual users, then it probably works out well.

<comment><USER9> There's an indicator available for this already, although it lacks the fancy graphs.

[http://www.omgubuntu.co.uk/2011/03/indicator-sysmonitor- simp...](http://www.omgubuntu.co.uk/2011/03/indicator-sysmonitor-simple- system-stats-app-for-ubuntu/) (seems to be down atm) <https://launchpad.net/indicator-sysmonitor/+download>

</comment></comment><comment><USER10> Does this beta contain anything of Wayland? I know they said a year is probably more realistic, but I'm just curious if the Unity in this release is running on X11 or Wayland. <http://www.markshuttleworth.com/archives/551>

<comment><USER11> X11. Wayland is supposed to be there for 11.10 at the earliest. Wayland is available in a PPA right now, though.

</comment></comment><comment><USER12> I tried unity in 10.10 and found it to be cumbersome. I was shocked when they announced they were moving to it for 11.04.

But, it looks like it's undergone a few improvements.

(Strangely, I know,) I trust the people working on Ubuntu to make rational decisions. It looks like unity pulled through.

<comment><USER13> I have to say that both Unit and Windows 7's desktop bar look absolutely horrendous to me. I haven't used either, so I can't tell if this leads to some surprising productivity boost but there's something about the space-consuming giant-kiddy-icons that make me think it will only work against me.

I don't have any problem right now with the size of the icons, but screen estate is always an issue. Window organisation, as it has been for the last 15 years, seems like it has much better room for optimisation.

Other choice have also seemed a bit arbitrary - like moving the power options to the status bar, whilst also moving the window controls away from the status bar. Mouse movement has increased in my experience.

<comment><USER14> The key thing with any system is to make sure you move the bar to the left/right of the screen. Almost every screen has stacks of horizontal real estate but never enough vertical.

And by doing that -- the win7 icons don't bother me in the slightest.

<comment><USER13> That is certainly true, and it does seem to be on the side by default. I have a netbook-like Vaio with Wubi install that will provide quite a good test before upgrading my main PC - always lacking on the vertical. For me it doesn't take away from the ugliness: Ubuntu was starting to look really slick and "pro" with its black bars and smart new font. Those garish icons always screaming at me bring to mind a laptop covered in stickers and a keyboard so riddled with extra rubber Interweb buttons that you're scared to touch it. Of course, everything should have it's chance. I just wonder whether the switch to default status is warranted.

Glad to see the downvote-disagree is becoming ever more prevalent! Obviously an opinion on the aesthetics is totally unproductive. Here we go again... k--;

</comment></comment></comment></comment><comment><USER15> Forget the UI. That can be tweaked and altered to just about anything you like. I'm really keen to see whether 11.xx has major performance improvements that I've been hearing about.

<comment><USER16> Good defaults are key to adoption. Alot of computer users don't know how to completely customize.

</comment></comment><comment><USER17> Dash, with its shortcuts, is useful. Now, you can search for new applications without opening Software Center.

</comment><comment><USER18> Unity!

<http://www.youtube.com/watch?v=toAEQTsidvg>

I guess I'll try out Unity, but I may have an itchy trigger finger ready for a switch back to something more familiar.

</comment><comment><USER19> I have been playing with it since alpha 3.

When it is properly released I will do a reinstall, and I will be using gnome with it. Unity is crap.</comment>


Pagoda goes in private beta - Heroku for PHP - <AUTHOR> http://www.pagodabox.com/

<comment><USER2> Their website is ridiculously well designed -- possibly on par with Heroku. Doesn't say much about their solutions and infrastructure, but it does signal great care.

</comment><comment><USER3> Pulling only from github seems very restrictive to me. So, basically if I want to put a private project on PagodaBox, I have to also purchase a github account.

<comment><USER4> What's wrong with a github account? Give them some love. Their private option is cheap. Over all once you start using github it's hard to go any other route anyway.

<comment><USER5> Other people may use their own git server or a different git host.

Anyways, since git is decentralized, why go through github? What about pulling/pushing between the user (or any arbitrary git client) and pagoda box directly?

Edit: I watched the screencast, your deployment process is a bit different than I expected so I guess using github is probably a good idea.

<comment><USER4> Yeah good points. Anyway looks like here's a more straight forward reason: <http://guides.pagodabox.com/getting-started/git-github> "...the feature-set available in the Admin Panel and the Pagoda Terminal Client are directly tied to Github's API"

</comment></comment></comment></comment><comment><USER6> The PHP Fog web designer could learn a few things from the Pagoda site. I found Pagoda much more informative and has better usability than Fog. The graphics and images on Pagoda aid the user in understanding how Pagoda works and why it's better than traditional hosting, instead of hitting you over the head with over-the-top beautiful graphics that ultimately don't say or mean much as on Fog. The typography also makes the copy easier to read. The video demo is very slick.

<comment><USER7> It's funny, I _almost_ down-voted you thinking this was a sarcastic post since my first impression of Pagoda's homepage was "wtf?" - but, their site caught my attention and encouraged me to progress through the process to find out more.

I'm not sure whether the designers of Pogoda's site are flat out geniuses or skating on thin ice.

</comment></comment><comment><USER8> I like it how the screencast didn't use a terminal; not even once. This is very different from the other _Heroku for x_ initiatives.

That, bundled with their absolutely gorgeous design is a huge differentiator from the alternatives.

</comment><comment><USER9> I like the idea of Pagoda pulling from the github repository, but what happens if github is for any reason inaccessible and you need to make an update to your site? Is there a backup method?

</comment><comment><USER10> From the video:

"Select which framework your using"

"your" should be "you're"

</comment><comment><USER11> PHPCloud isn't built in PHP. Anyone know if Pagoda is built in PHP? I'm more partial to supporting a php PAAS that is intimately familiar (on a day to day operational basis) with my language.

<comment><USER12> Same group that runs this Magento (PHP) extension shop: <http://www.tinybrick.com/>

Also recalled a tweet awhile back, here it is: <http://twitter.com/#!/PagodaBox/status/60133469107388416>

</comment></comment><comment><USER13> sounds a lot like <https://www.phpfog.com/>

<comment><USER14> if we're naming competitors, here's another: <http://cloudcontrol.com/>

<comment><USER5> And here's a big list: [http://blog.huchunhao.com/current-and-upcoming-cloud- platfor...](http://blog.huchunhao.com/current-and-upcoming-cloud-platforms)

Thread complete.

</comment></comment></comment><comment><USER7> Does anyone know who their hosting provider(s) are? I'm curious to know if they rolled their own infrastructure or if they are cloud based.

Also, does anyone know about their funding and the team?

On the surface it looks promising, but I'd like to hear more about the team behind the effort and further details on the back-end behind the black box.

<comment><USER15> Judging from WHOIS they seem use Softlayer.

</comment></comment><comment><USER16> Yay! More PHP PaaS services with a real cloud architecture. Very nice.

Please add PostgreSQL and I'll start using it!

</comment><comment><USER17> This is gorgeous: <http://www.pagodabox.com/architecture>

Almost making me want to write PHP

</comment><comment><USER18> Site alone makes me wanna give them a try :)

<comment><USER19> right? I was about to post some snarky comment about "php is the heroku for php" but then I went through their site and was actually impressed. It would be rad if they had a free tier which turned into a "paid" account if it hit a certain threshold.

<comment><USER20> They do have a free tier: <http://www.pagodabox.com/pricing>

<comment><USER19> hah I totally misunderstood that. Once you log into the dashboard it's really clear because you see the slider w/ $per 30 days. It would be cool to stick that on the pricing page directly.

From what I can see per 30 days: 1 clone($0.00) .. 25 clones($864.00)

</comment></comment></comment></comment><comment><USER21> Wow, this is seriously awesome. Gorgeous design and the admin panel is incredibly easy to use.

</comment><comment><USER22> Request invite if you're interested, I got it pretty quickly. Great design indeed.

</comment><comment><USER23> I have 10 invites...</comment>


Debugging in the Time of JITs - <AUTHOR> http://rfrn.org/~shu/2014/05/14/debugging-in-the-time-of-jits.html

<comment><USER2> Interesting article. I'm writing a toy trace compiler at the moment and implementing side exits brings up many of the same, rather irritating problems.

</comment><comment><USER3> Would be fun to try to compare this with a decent GC and see what the difference is likely to be. The reason why I say this is because Javas default GC pre-allocates a heap (a Java allocation is mostly just bumping a pointer), and since it "frees" memory by copying survivors to a new space you also avoid fragmentation.

If it turns out that what you mostly pay for, when using a GC, is that collection happens at one point in time instead of incrementally, then Go's plan for the evolution of their GC just became a lot more interesting.

<comment><USER3> Ahh, commented on the wrong article... Was wondering why I was downvoted :P

</comment></comment><comment><USER4> It seems to me that we should not make the problem more complicated than necessary. If you're debugging code written in Javascript, you may assume that the JIT optimizer is correct. If you need special features enabled (such as stack traces, etc.), then just pepper the code that _enters_ the JIT with logging instructions, etc.

There should never be a need to completely disable the JIT optimizer, except perhaps to debug the JIT itself.

<comment><USER5> The issue with debugging JITed code is not that the optimizer may be incorrect, but rather that optimization wreaks havoc on the correspondence between source code and what actually executes – things happen in a different order or not at all, stack frames don't correspond to function calls, etc. This makes the debugging experience pretty confusing. To get a sense of this, try using gdb/lldb on code compiled at -O3 with -g turned on so that you still have debugging symbols. Things are weird. When debugging AOT compiled code, one avoids this confusing experience by recompiling the entire program in debug mode with optimizations off. In a JIT environment, what do you do? This article describes a clever approach: dynamically deoptimize the stack and transfer control from optimized code to non-optimized code, then debug the simple, non-optimized version of your program where what's executed lines up nicely with the source code.

<comment><USER4> Things happening out of order should never be observable. So this should not be an issue.

<comment><USER2> The only reason things happening out of order is invisible is because implementors jump through the kinds of hoops described in the article.

One way to understand the requirement for deoptimization is to to think about where the programmer can observe the difference between an optimized construct and the naive version. In regular execution there are relatively few places where the state of the program is observable, allowing freedom to aggressively optimize - under the debugger there are _no_ places where the state of the program is unobservable.</comment></comment></comment></comment>


Benjamin Franklin's Essay on Daylight Saving   - <AUTHOR> http://www.webexhibits.org/daylightsaving/franklin3.html

<comment><AUTHOR> Is it just me or does anyone else feel there's more than a hint of satire in this essay? Did Benjamin Franklin propose DST as a joke to save resources? I'm a bit confused here.

<comment><USER2> I don't think he considered the actual idea a joke. The "tongue in cheek" tone comes from the absurdity of suggesting something so simple as using actual free daylight to do your work, whilst the rest of Paris seems to be stuck solving optimal candle efficiency.

<comment><AUTHOR>
        The "tongue in cheek" tone comes from the absurdity of
        suggesting something so simple as using actual free
        daylight to do your work, whilst the rest of Paris seems
        to be stuck solving optimal candle efficiency.

Didn't he make the same mistake himself? I'm not sure if that was satirical but

        Fourth. Every morning, as soon as the sun rises, let all
        the bells in every church be set ringing; and if that is
        not sufficient?, let cannon be fired in every street, to
        wake the sluggards effectually, and make them open their
        eyes to see their true interest.

was a much complex solution than the simple one adopted decades later - altering the clocks of the city towers. That said, I'm not quite sure if such clocks existed back then. I guess it would bode well for Benjamin Franklin if they didn't!

</comment></comment></comment><comment><USER3> I've seen this before, but it's always seemed curious to me. Does anyone know the circumstances of this letter?

Was there really a journal _of_ Paris? Was it some kind of English language paper for ex-pats, which would explain why Franklin was writing an letter in English to it? Or was he writing a letter in English to a "Journal de Paris", assuming that anybody educated enough to read was educated enough to read English? Or is the whole "journal" thing just a joke, and it's just a pamphlet for general publication making fun of the Parisians (which would also explain the English language)?

On a broader note, Franklin and Jefferson spent an awful lot of time in Paris, but I never run across any letters or writings of theirs in French. Do these things exist but just don't show up often, was there some kind of social faux pas that explains this, or was their French just kind of sucky?

<comment><USER4> I think this was from Le Journal de Paris. "Journal" in this case actually means "newspaper" -- it was a daily that ran from the 1770's to the 1840's. I have a copy, but sadly it has no Benjamin Franklin essays in it.

<comment><USER3> If it was actually published in Journal de Paris, why the weird "Journal of Paris" thing? And did the actual _Journal de Paris_ really publish letters in English sometimes? I've always heard Franklin was a big celebrity in Paris(that definitely might be propaganda in American schoolbooks), but English wasn't all that popular of a language at the time.

I can believe that Franklin was making a joking reference to Le Journal de Paris, but it seems hard to believe this actually got published there.

<comment><USER5> I found a scan of the article in french:

[http://upload.wikimedia.org/wikipedia/commons/b/b0/Franklin-...](http://upload.wikimedia.org/wikipedia/commons/b/b0/Franklin- Benjamin-Journal-de-Paris-1784.jpg)

The article starts in the "E C O N O M I E" section.

(note: the shape of the printed lowercase s looks like an f)

Don't be surprised that the he was able to write in French, as educated people of that time knew French, much as educated people today know English. Moreover he was ambassador to France during 1776–1785.

<comment><USER3> Thank you very much!! I stand corrected. And with this to search with, I found the complete original on Google Books (along with what seems to be a complete set of Journal de Paris from the 18th century; I'm going to waste the whole day reading bits of these.)

I'm not surprised at all that Jefferson and Franklin spoke French -- I always assumed they did -- what surprises me is that we (at least in the US) see so little evidence of it and that translations are presented as originals so often.

This letter is a good example. Is the English translation even Franklin's? And yet it's everywhere, while this French original doesn't even show up on the Library of Congress Franklin site. That's what I find bizarre.

<comment><USER5> Don't worry, I suspected it was a recent prank too the first time I read it. Wonder why we are so suspicious these days ...

</comment></comment></comment></comment></comment></comment><comment><USER6> Wait a second.. is Ben Franklin claiming that he has discovered that the sun shines as soon as it rises?

<comment><USER7> I'd be interested to know a little more about the historical context surrounding this piece - was Franklin responding to some well known problem of the time like a rise in the price of candle wax or lamp oil? The essay seems like an attempt to encourage people to conserve resources using the vehicles of sarcasm and humor. I wonder how common it was at the time to wake up around noon though?

Edit: tantalor sums it up better. :-)

<comment><USER8> > I wonder how common it was at the time to wake up around noon though?

Despite all his quotes about "early to rise", Franklin was known, during his time in Paris, as a party animal. This provides a lot of context to those jokes about waking up around noon.

</comment></comment></comment><comment><USER9> Here's some context behind the essay:

<http://www.webexhibits.org/daylightsaving/franklin.html>

</comment><comment><USER9> I thought this was an interesting point: According to Wikipedia[1],

> Franklin did not propose DST; like ancient Rome, 18th-century Europe did not > keep precise schedules.

[1] <http://en.wikipedia.org/wiki/Daylight_saving_time>

</comment><comment><USER10> Daylight savings has to only exist today for political reasons right?

Because it makes little scientific reason.

So what is the political logic then? I'm a little mystified.

Will people rise up and say "omg stop changing things, we're had DST for 200 years, let it be?"

Because they keep messing with the start date and end date, so it's not like it's sacrilege.

I've always found it humorous that it always ended just before Halloween, just in time for little kids to be put in danger in the early dark, they recently moved it to early November though, so someone wised up.

<comment><USER11> Daylight savings exists for an entirely practical reason: so that we can enjoy daylight hours after we get home from work.

<comment><USER12> Which, depending on where you live, is absolute nonsense.

Russia just abandoned DST and the rest of the world should too.

<comment><USER13> This needs updating then.

<http://en.wikipedia.org/wiki/Daylight_saving_time>

</comment></comment></comment></comment><comment><USER14> I think the whole DST is just useless.

</comment><comment><USER15> Interesting how Ben Franklin's solution was a prohibitive tax on window shades and post-sunset transit, a quota on candles, and a citywide alarm clock. After all those regulations that would be near impossible to enforce, maybe simply changing the clocks was a far more elegant solution.

</comment><comment><USER16> What about wintertime, Mr Franklin?

Btw, "Early to bed, early to rise, makes a man healthy wealthy and wise" now has a citation:

<http://news.vanderbilt.edu/2013/02/circadian-clock-obesity/>

</comment><comment><USER17> When I hear the reasons people dislike DST, they basically list reason that unbeknownst to them is the reason we have DST.

</comment><comment><USER18> Posting guards at candle shops? That doesn't sound like someone that believes in freedom.

<comment><USER19> Do you also think Jonathan Swift had a taste for Irish children?</comment></comment>


Tool Can Hack Your Accounts Even with Two-Factor Authentication – ExtremeTe - <AUTHOR> https://www.extremetech.com/extreme/269121-this-tool-can-hack-your-accounts-even-with-two-factor-authentication <comment><USER2> This is too 2018</comment>


ØMQ: Mission Accomplished - <AUTHOR> http://www.250bpm.com/blog:1 <comment><USER2> I think 0MQ is brilliant. If this is your first time looking at 0MQ, I'd suggest the following:

<http://www.zeromq.org/intro:read-the-manual>

Watch the first video by Ian Barber. He's an excellent presenter.

The guide ( <http://zguide.zeromq.org/page:all> ) is very lengthy and comprehensive, but the "hello world" example and the "Divide and Conquer" example (fan out jobs, work, fan in results) will get you up and running and start showing you a sliver of the amazing power of 0MQ.

They've even got a lot of their examples in many languages:

C++ | C# | Clojure | CL | Erlang | F# | Haskell | Haxe | Java | Lua | Node.js | Perl | PHP | Python | Ruby | Scala | Ada | Basic | Go | Objective-C | ooc

<comment><USER3> Yes, these are good as well...

ZeroMQ: Modern & Fast Networking Stack, by Ilya Grigorik [http://www.igvita.com/2010/09/03/zeromq-modern-fast- networki...](http://www.igvita.com/2010/09/03/zeromq-modern-fast-networking- stack/)

ZeroMQ an Introduction, by Nicholas Piël <http://nichol.as/zeromq-an- introduction>

Advanced Network Architectures with ZeroMQ, by Zed Shaw [http://blip.tv/pycon- us-videos-2009-2010-2011/pycon-2011-adv...](http://blip.tv/pycon-us- videos-2009-2010-2011/pycon-2011-advanced-network-architectures-with- zeromq-4896861)

</comment></comment><comment><USER4> 0MQ looks very interesting, but most of the information available seems to be "how to use it". I can't find detailed specifications of its behavior, nor a detailed description of the implementation that I could use to figure that out myself. (Short of wading through the source code.) So it's hard to understand exactly how load balancing works, exactly what happens to in-flight messages on a server crash, exactly what guarantees are provided for message ordering (e.g. in a complex multi-participant scenario), at-least-once vs. at-most-once message delivery, etc.

Does anyone know of a good, detailed explanation of how 0MQ is implemented?

<comment><USER5> As for in-flight messages and server crashes, some explanation is given in the zguide in the part about durable sockets.

And you're right that some explanation of implementation is needed. I spent a few hours digging through the code today and it's not easy to read.

<comment><USER6> <http://www.zeromq.org/whitepapers:architecture>

</comment></comment></comment><comment><USER3> ZeroMQ is amazing. The last few months I have been using it for all kinds of things -- from creating multiprocessing Python apps to replacing an HTTP REST backend with a high-performance ZeroMQ server.

<comment><USER7> How does this compare to XMPP? Are there any benefits to learning ZeroMQ for web notifications over using, say Strophe.js?

<comment><USER8> ZeroMQ is very low level, compared to XMPP. ZeroMQ considers itself as part of the networking stack: tcp/udp/0mq (or perhaps just above tcp and udp).

ZeroMQ and XMPP are not really competitors.

</comment></comment></comment><comment><USER9> Last time I looked into zmq, it was not recommended for use in public internet services -- not resilient enough against a potential DoS attack or buggy client implementation. Has this changed?

<comment><USER6> It have got much better. The latest stable version should be pretty much resilient.

<comment><USER10> I don't think it's supposed to be exposed in this way, rather it's very good for internal wiring between trusted systems.

<comment><USER11> If I recall, the issue with a public 0mq socket was that anyone driving by sending something 0mq didn't like would cause an assertion to fail, so your process would crash. It wasn't so much a "supposed to be exposed" as "expose it and crash".

<comment><USER10> Yes you are right. I guess what I wanted to say, is that 0MQ relies on trusted code and network. It's okay for code to assert, as soon as there is someone to fix it, and it's probably expected. (Crash early, fix early).

</comment></comment></comment></comment></comment><comment><USER12> Wow, programming can really be romantic.

<comment><USER13> My favorite - "I recall the hot summer in remote Bulgarian village, almost on the Turkish border, with car broken and no way to get home, where I devised the first version of ØMQ wire protocol. Thanks to the guy who fixed the car! Without him I would have been herding donkeys today. There would be no ØMQ."

</comment></comment><comment><USER14> What HPC products use 0mq?

Would it be applicable to large-scale optimization problems, e.g. in context of machine learning?

<comment><USER6> [http://engineering.twitter.com/2011/08/storm-is-coming- more-...](http://engineering.twitter.com/2011/08/storm-is-coming-more-details- and-plans.html)

<comment><USER15> Looks very interesting! I cannot find any details about its release though, even though the article talks about September 19. Will it be open source? proprietary?

<comment><USER16> Github repo: <https://github.com/nathanmarz/storm> Strange Loop presentation: <http://www.infoq.com/presentations/Storm>

</comment></comment></comment></comment><comment><USER17> He's talking about 3.1, while publicly 3.0 is still in beta. Does anyone know when 3.1 will come out?

<comment><USER6> Community vote taken last weeks was to continue 3.x series of releases by 3.1.x versions.

</comment></comment><comment><USER18> Congratz! I've been using 0MQ for few years on distributed db, now it's hard not to architect distributed/threaded apps without 'message passing' design which 0mq is pushing for. Plus the mailing list is pretty helpful and friendly.

</comment><comment><USER19> Anyone know of a good and recent ØMQ/AMPQ/STOMP comparison, specifically with attention paid to the implementations available?

<comment><USER6> 0MQ is a product, AMQP and STOMP are protocols. In addition to that both AMQP and STOMP assume classic star topology with a messaging server in the middle, whereas 0MQ allows you to connect your applications directly and create arbitrary topologies.

<comment><USER20> Not saying you're wrong, but I wouldn't phrase it this way.

I've only been using 0MQ as a library and AMQP in the form of RabbitMQ - so it can be quite the opposite.

</comment></comment></comment><comment><USER21> Are there any hosting services out there that currently support using ZeroMQ?

<comment><USER22> Any VPS host, or EC2, will let you run ZeroMQ in whatever way is appropriate to your problem.

edit: and same for if you run your own server or rent a server, obviously

<comment><USER23> However, many services won't let you make full use of it; e.g. last year when I tried to get multicast between my EC2 nodes, it discovered it was unsupported.

If you're only using ZeroMQ in tcp or inproc mode, it is nice, but in a pub/sub scenario you are wasting a lot of bandwidth and CPU time.

<comment><USER24> Can you explain why you're wasting a lot of bandwidth/CPU time in pub/sub?

<comment><USER25> if you're not using multicast in pub sub, you're establishing individual tcp connections between nodes, it's not any different than doing N point to point communications, whereas with multicast, the data is only copied when needed, your data will fan out if that makes sense with your network topology I think if you look at the picture it'll be clear

<http://en.wikipedia.org/wiki/Multicast></comment></comment></comment></comment></comment>


Not using your pool every day? Rent it on Swimply, the Airbnb for pools - <AUTHOR> https://www.bendbulletin.com/business/not-using-your-pool-every-day-rent-it-on-swimply-the-airbnb-for-pools/article_25ec76ba-d2bc-11ea-9c8b-bb777a17de15.html <comment><USER2> 2020 has certainly introduced us to a more-than-usual quota of horribleness and stupidity, but this is right up there in the top N.

Yeah, I'm likely to _love_ the notion of half-naked wet people traipsing through my house/garden to and from my swimming pool.

Someone with a health issue (gods-forbid, a virus) swims in my pool. Another person swimming there the next day gets ill...

Someone drown in my pool. The family sues me because "You didn't have a life- guard."

"I paid to use this pool but the water's green..."

Potential for liability is endless. I won't even _start_ on the perennial peeing in the pool problems...

</comment><comment><AUTHOR> If interested, there was also a New Yorker piece last year explaining the rationale: [https://www.newyorker.com/magazine/2019/09/09/at-last-an- air...](https://www.newyorker.com/magazine/2019/09/09/at-last-an-airbnb-for- pools)</comment>


Is Newmogul dead? - <AUTHOR>

Anyone know what happened to newmogul? I'd be willing to take over the site if I knew who to contact/get a site backup from. <comment><USER2> <http://news.ycombinator.com/item?id=870575></comment>


Visualising the Go garbage collector - <AUTHOR> http://dave.cheney.net/2014/07/11/visualising-the-go-garbage-collector <comment><USER2> The vaguely sawtooth-looking waves are pretty characteristic of all GC operation. If you look at typical GC graphs of the JVM or CLR, they look very similar - but this one has a difference I'll try to explain below:

In this case the workload doesn't look particularly suited to GC - notice the scvg.inuse line (light blue) spends more time at its lowest value than climbing or at the top, meaning that more time is spent holding onto memory that is not in use than actually using it... the difference between scvg.consumed and scvg.inuse essentially represents wasted memory. Estimating roughly, the process appears to be using 100% more memory than it needs to for 66% of the time, and 20% more for the other 33% for an average of ~70% (you can use an integral to get the exact average.)

Most of the JVM GC graphs I've seen are much "pointier" at the bottom, indicating that immediately after a GC cycle the allocations resume again so there is far less time where memory is allocated but not in use. The average between used and allocated memory is closer to 50% in that case.

<comment><USER3> It looks like the sample benchmark is of the "godoc" tool in http server mode. In this mode, godoc serves a local website that is a near-clone of [http://golang.org/](http://golang.org/) , which is particularly useful because the local "Packages" tab will contain not just the standard library, but all local packages, including the ones you've downloaded and the ones you are writing [1]. Consequently, the program is, on average, doing nothing. To get those graphs at all, I assume he was clicking around in the served web site, because otherwise I'd expect nothing at all to happen.

So we're not looking at a big website serving dozens of requests per second... we're looking at a program with a relatively expensive startup (and in this case I mean "relatively" literally; in absolute terms it's quite fast in my experience, I've never been able to start the program and ALT-TAB to my web browser and load a page before it's ready), which then twiddles its thumbs.

To compare it against an active Java server program, you'd basically collapse the whole graph into about 2 or 3 seconds worth of activity, if that.

[1]: Incidentally, another example of "something simple Go does that intuitively _feels_ like it shouldn't be a special thing because it _feels_ like every language ought to already have such a thing, except that when you go looking for it, you can't find it". It doesn't _sound_ like an all-in-one API documentation of everything you've got locally would necessarily be that especially useful, but it really is.

<comment><USER4> Note: an idle godoc does almost nothing, this is godoc started with the _indexing_ option.

</comment></comment></comment><comment><USER5> An interesting GC-related find earlier this week: it can help a lot to allocate in large chunks when you can:

[https://plus.google.com/+ChandraSekarS0/posts/MNMWAXr63qz](https://plus.google.com/+ChandraSekarS0/posts/MNMWAXr63qz)

Note that the entire chunk stays "alive" while any element in it is reachable, so this only works when arena allocation would in a non-GC'd language, i.e., when you're going to free the entire chunk at once (or in those rare cases you never need it reclaimed, e.g., 'cause it's a big fixed-size pool that you'll recycle forever).

To my surprise, allocating big chunks performed better than a Pool or manual recycling in this case. My best guess, and the author's, is that fewer allocations meant less space on memory-allocator bookkeeping (so fewer GCs) and less time spent sweeping in each GC.

If anyone's more aware of the guts of the runtime than I am and can confirm or disconfirm or elaborate, I'm curious.

</comment><comment><USER6> Nice! and in 325 LOC :-)

This tool (or something like it) has been asked for a few times on Stack Overflow. I can see that many people will find this useful.

<comment><USER7> I just opened up a PR[1] for live updating of the graphs (with a delay from the setTimeout from javascript side). It's not amazingly coded, but works for me atm.

[1] [https://github.com/davecheney/gcvis/pull/3](https://github.com/davecheney/gcvis/pull/3)

</comment></comment><comment><USER8> great tool and and excellent code read. Thanks for sharing.</comment>


Deconstructing Functional Programming [video] - <AUTHOR> http://www.infoq.com/presentations/functional-pros-cons?utm_source=infoq&utm_medium=QCon_EarlyAccessVideos&utm_campaign=QConSanFrancisco2013 <comment><USER2> Gilad Bracha sounds like he hasn't used a typed language long enough to stop struggling with basic type errors.

As such, it is of a position of extreme ignorance that he speaks of the uselessness of type checking and inference.

Claiming Smalltalk has the best closure syntax shows he doesn't understand call by need. Haskell defines easier to use control structures than Smalltalk.

Claiming patterns don't give exhaustiveness, ignoring their extra safety shows Gilad doesn't understand patterns.

Claiming monads are about particular instances having the two monad methods, when they are about abstracting over the interface, shows Gilad doesn't understand monads.

Claiming single argument functions have the inflexibility of identical Lego bricks shows he doesn't understand the richness of function types and combinators.

In short, Gilad sounds to me very much like a charlatan who'd benefit greatly from going through lyah.

</comment><comment><USER3> I found Bracha's talk poor. That guy really has a chip on his shoulder vis-a- vis functional programming. A lot of things he said were not well though out. Here are some examples.

\- He claimed that tail recursion could be seen as the essence of functional programming. How so?

\- He complained that tail recursion has problems with debugging. Well, tail recursion throws away stack information, so it should not be a surprise. You don't get better debug information in while loops either. And you can use a 'debug' flag to get the compiler to retain the debug information (at the cost of slower execution).

\- His remarks about Hindley-Milner being bad are bizarre. Exactly what is his argument?

\- His claims about pattern-matching are equally poor. Yes, pattern matching does some dynamic checks, and in some sense are similar to reflection. But the types constrain what you can do, removing large classes of error possibilities. Moreover, typing of patterns can give you compile-time exhaustiveness checks. Pattern matching has various other advantages, such as locally scoped names for subcomponents of the thing you are matching against, and compile-time optimisation of matching strategies.

\- He also repeatedly made fun of Milner's "well-typed programs do not go wrong", implying that Milner's statement is obviously non-sense. Had he studied Milner's "A Theory of Type Polymorphism in Programming" where the statement originated, Bracha would have learned that Milner uses a particular understanding of going wrong which does _not_ mean complete absence of any errors whatsoever. Milner uses a peculiar meaning, and in Milner's sense, well-typed programs do indeed not go wrong.

\- He also criticises patterns for not being first-class citizens. Of course first-class patterns are nice, and some languages have them, but there are performance implications of having them.

\- His critique of monads was focussed on something superficial, how they are named in Haskell. But the interesting question is: are monads a good abstraction to provide in a programming language? Most languages provide special cases: C has the state monad, Java has the state and exception monad etc. There are good reasons for that.

\- And yes, normal programmers could have invented monads. But they didn't. Maybe there's a message in this failure?

<comment><USER4> Indeed, I found his talk pretty poor as well. A lot of it comes down to not wanting to learn new terminology, and forgetting that a lot of "common sense" terminology from, say, Java, is also learned. I don't get more insight from "FlatMappable" than from "Monad"; in both cases I must learn about them first, and neither is intuitive without prior knowledge.

It is instructive to read Bracha's blog too, mostly for the comments where readers refute a lot of what he claims.

His argument against Hindley-Milner seems to be that "he hates it", and that type errors are sometimes hard to understand. It is true IMO that they are hard to understand (even though, like everything in programming, you get better with practice), but what is the alternative? Debugging runtime errors while on production?

He also presents Scala as a successful marriage between OOP and FP, but in reality this is a controversial issue. Some of the resistance to Scala (witnessed here in Hacker News, for example) is due to it trying to be a jack of all trades and master of none. Scala's syntax is arguably _harder to read_ than that of other FP languages.

Some of his "funny" remarks sounded mean-spirited to me. Nobody in his right mind claims that FP invented map or reduce, for example.

The only point of his talk I somewhat agree with is that language evangelists are annoying. Oh, and that "return" is poorly named.

<comment><AUTHOR> > His argument against Hindley-Milner seems to be that "he hates it", and that > type errors are sometimes hard to understand. It is true IMO that they are > hard to understand (even though, like everything in programming, you get > better with practice), but what is the alternative? Debugging runtime errors > while on production?

He pointed out that a more nominal type system is a solution. Because when you give meaningful names to your types the error messages will become clearer and not full of long, inferred types that reveal potentially confusing or unimportant implementation details.

<comment><USER3> Most programming languages with Damas-Hindley-Milner do not prevent you from using explicit type annotation, and inventing semantically meaningful type names.

More importantly, I think the reason why error messages are sparse and not meaningful in languages with Damas-Hindley-Milner is that nobody bothered to improve the situation. And the reason why nobody botheres is that it's simply not a problem in practise. Any even moderately experienced programmer can easily detect and fix typing errors as they are given in Haskell, Ocaml, F#, Scala etc.

</comment></comment></comment></comment><comment><USER5> First, thanks for all involved in getting this posted!

I'm somewhat curious on why the industry has such an aversion to simulating things in our mind. Especially when this seems to be one of the arguments employed against monads in this speech. That it basically couches something known in an odd name that is not known. Isn't this just stating that it is bad _because_ it confuses the simulator that is the reader?

That said, the live coding aspect is something that I am just now learning from lisp with emacs. Being able to evaluate a function inline is rather nice. It is somewhat sad, as I still wish I could get a better vote in for literate programming. (Betraying my appeal to the human factor moreso than the mechanical one.)

<comment><USER6> Monads have nothing to do with simulating anything. They are just a commonly recurring pattern of computational contexts (more precisely, functors) that also provide two basic operations:

1\. entering the context (pure :: a -> m a) 2\. collapsing nested contexts into one (join :: m (m a) -> m a)

Together with some coherence laws that ensure that these operations do exactly, no more or less, than entering the context and collapsing nested instances of it.

<comment><USER5> Did you watch the video? I'm not referring to monads simulating something. I'm referring to the observation that when reading code you are simulating its execution. My understanding of the video's complaint against monads is that the signature of monads is actually quite simple and well understood in different contexts _by different names._

The video goes on to display an environment where you do not have to simulate the code in your head.

This progression seems somewhat interesting to me. As does the desire to not have to simulate code in your head.

<comment><USER7> >This progression seems somewhat interesting to me. As does the desire to not have to simulate code in your head.

But none of that has anything to do with monads.

<comment><USER5> Ok... I think I'm getting trolled at this point.

I am taking issue with the video's critique of monads. Wherein it is claimed that monads manage to take a common and understandable behavior and make it laughably impossible to explain to people by giving it a weird name. Essentially, the problem with monads is one of it being difficult to "simulate" under the name "monad" for many individuals.

This part, I actually feel makes sense and resonates well. Simply follow the progression in the video and see how "FlatMappable" becomes less and less intuitive as it is given worse and worse names.

The part that is interesting to me, is how this then progresses into a point on how programmers should not have to simulate the code in their head. Now, I realize there is a big difference between "should not have to" and "is difficult to intuitively do so". Still seems an odd progression, though.

<comment><USER7> >Ok... I think I'm getting trolled at this point.

If you don't want to discuss something, then don't post. You are not making any sense, and calling people trolls does not help at all.

<comment><USER5> I should have put a smiley on that, then. While feeling trolled, I highly suspect this is just a rather amusing case of poor communication.

At no point was I trying to describe or discuss monads. That is something a response to me thought I was trying to do. When referring to "simulating" a system, I was referring to where the video refers to the process of reading "dead code" in a text editor. There is a large rant on monads _in the video_ where the argument appears to be that the problem is strictly with the name. The reason given that it takes something understood, and hides it behind non- obvious names. I extrapolated this to be that it makes the program and the idea "hard to simulate" for the coder reading the code.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> Great talk. Particularly the bit on the value of naming things - I rather wish he'd flogged that a bit harder.

As time goes on I'm finding it more and more frustrating to try and maintain code that relies entirely on anonymous and structural constructs without any nominal component. Yes, I do feel super-powerful when I can bang out a bunch of code really quickly by just stacking a bunch of more-or-less purely mathematical constructs on top of each other. . . but as the story of the Mars Climate Orbiter should teach us rather poignantly, when you're trying to engineer larger, more complex systems it turns out that meta-information is actually really useful stuff.

<comment><USER4> I'd say static typing and purity as advocated by FP are some of the tools one wants when trying to engineer larger, more complex systems.

I wasn't familiar with the Mars Climate Orbiter case, but a cursory reading suggests one of the causes was a type error (confusing newtons with pound- force).

<comment><USER8> As advocated widely in the FP blogosphere. . . not necessarily as commonly practiced in FP programming culture, or supported by many FP languages.

For example, I strongly prefer F# to its cousin OCaml largely because F# uses nominal typing and OCaml uses structural typing. I've also got some misgivings about being overly reliant on type inference. Both structural typing and advanced type inference are admittedly incredibly convenient. What worries me is that they also seem to be incredibly convenient as ways to obfuscate the programmer's intent w/r/t types and their semantics.

<comment><USER4> I'd say not so much as advocated by the blogosphere (which can be annoying, as fans of almost anything often are), but by the people actually designing and using FP languages.

In any case, there is certainly valid criticism of FP, but Bracha's just isn't it. My impression is that the guy -- as clever as he may be in other areas -- barely understands FP, and makes disparaging remarks about things he isn't familiar with. Read his blog; every assertion he makes is shown to be incorrect or misleading by people who do understand FP, like Tony Morris or (very politely) Philip Wadler himself.

</comment></comment></comment></comment><comment><USER9> I'm just learning functional programming with Haskell, and it was great to hear him explain that learning Haskell is really hard because of the terminology. I feel a little (just a little) less stupid.

That said, he's a terrible presenter. His smarmy style was really off-putting, and his motives a little sketchy. He spends a good portion of the talk slamming just about every language in existence except for the two he works on (Dart and Newspeak). It seemed very disingenuous and I don't need another ranting nerd spouting venom about why something's not very good in that holier-than-thou tone. I would have rather had a straightforward talk showing the strengths and weaknesses than the bitter tone this had.

</comment><comment><USER10> This is a brilliant talk. It's getting far too easy to annoy the FP cult(ure).

As an aside, Scala is not unique in marrying a FP approach with an OO system. CL has had CLOS, IMO one of the better implementations of "OO" outside of Smalltalk, for much longer than Scala.

Definitely watch this!

<comment><USER6> Scala and Common Lisp are not particularly functional languages. Functional programming in Scala is doable, although it takes a nontrivial amount of effort (see: scalaz), and it is outright impractical in Common Lisp.

As an aside, CLOS multimethods resemble Haskell's multiparameter type classes (except CLOS is dumber: you cannot provide any guarantee that the same types will provide two or more common operations) more than they resemble anything else also called "object-oriented".

<comment><USER10> It is a common mistake I've heard from many CL newbies that believe CL is a "FP" language.

The best descriptor I can find to date (of CL) is, "programmable programming language," which allows it to encompass almost every desired feature one may need; including many that fall under the FP umbrella which may be where the confusion stems from.

However one of the opening points of the talk was that, "FP," is not a rigorously defined term and is subject to interpretation. Which leads to bikeshedding over language features and a lot of hype.

I believe it also leads to a lot of misplaced faith in the purity and completeness of mathematics (it's almost as if the popular notion of FP is being reborn as a modern _Principia Mathematica_ ).

CL obviously cannot be called an, "FP," language since its inception seems to predate the popular notion of the term. Scala may suffer in the same way due to its reliance on the JVM and the expression semantics it has carried over from Java. However many of the features one tends to associate with modern FP languages (though not all) are present in both languages.

As for your aside, how so? Perhaps a discussion we can have over email if you're interested. You sound smart. However I don't understand your statement and would like to know more.

<comment><USER6> > As for your aside, how so?

CLOS multimethods do not "belong" to an object or even to a class declaration. Particular implementations of generic methods are declared globally, just like Haskell type class instances. Although, as Peaker noted, type classes can dispatch on any part of the type signature. It is impossible to make a CLOS multimethod with signature:

        (SomeClass a b) => String -> (a, b)

> Perhaps a discussion we can have over email if you're interested.

Sorry, I never check email. But I am almost always on Freenode. My nick is pyon.

> You sound smart.

Not really. The regulars in #haskell - now _they_ are frigging smart.

<comment><USER10> I think the comparison to type classes is specious and ends there. They look similar but they tackle very different problems. You've actually explained why rather well.

> Not really. The regulars in #haskell - now they are frigging smart.

Don't sell yourself short.

<comment><USER2> It seems to me type classes have a superset of the features of CL multimethods. Why not compare them?

</comment></comment></comment></comment></comment></comment><comment><USER11> Interesting talk! Bracha has some good arguments against features that I generally enjoy in programming languages, like Damas–Hindley–Milner type inference and pattern matching.

Regarding Haskell: The points he makes against obtuse names based in category theory are valid, but then again, Haskell has its roots in research programming languages. Math-based terminology makes more sense for an academic audience.

<comment><USER7> >The points he makes against obtuse names based in category theory are valid

No, they aren't. When you have a class of "things" that doesn't have a name most people are familiar with, you are left with two options. Either choose a name people are familiar with, but which is wrong and misleading. Or choose the correct name and people have to learn a name. Are we seriously so pathetic as an industry that learning 3 new technical terms is a problem?

<comment><USER12> To an extent, I think it's a valid criticism. There are two main problems with the mathy names that many concepts in Haskell have.

The first is that they hide the meaning. For example, "Monoid" is a really scary term, and explaining it further as "something with an identity and an associative operation" really doesn't help much either. Calling it instead "Addable" or "Joinable", and explaining it instead as "things with a default 'zero' version, and which have a way to add two of them together", while perhaps not a perfect definition, would be much more intuitive for the majority of people.

That brings me to the second problem I see, which is that the esoteric terminology in Haskell creates a barrier between those who understand it, and those who don't, and contribute to a sense of Haskell culture being exclusionary and cult-like, which discourages cross-talk.

Criticizing Hindley-Milner, on the other hand, I'm confused by. It's such a useful and powerful system. I suppose it can make compiler errors more obscure at times, but you get used to reading them and they aren't so bad. Hindley- Milner isn't just a type inferrence system; it's a typing system which allows for the most general typing to always be used, so that the functions one writes are as general as possible, encouraging modularity and code reuse.

<comment><USER2> "Addable" will not actually be more informative than "Monoid", to someone who doesn't know "Monoid".

"Monoid" will be very informative to anyone who learned it from mathematics.

A "Monoid" is a type which supports an associative operation (`m -> m -> m`) and a neutral element (`m`) which forms its identity element.

"Addable" suggests it is an "addition". Does this mean it is commutative? For the sake of preciseness, I'd hope so! (Monoids aren't commutative). Does this mean it has a negation? No. So it is not "addition", why use a misleading name for the sake of some false sense of "intuition"?

The actual explanation of what a Monoid is _precisely_ is so short and simple, it makes no sense to try to appeal to inaccurate intuitions.

<comment><USER12> That's a completely valid point of view. You're not wrong at all. I'm guessing, though, that you had learned it before from mathematics. My point is one of pragmatic, not theoretical, distinction. To those without a mathematical background (most people are not going to learn monoid unless they've studied abstract algebra), or who are less interested in mathematics in general, an obscure term like that is discouraging. I know that the Haskell community is heavily mathematical, and have little interest in "dumbing down" the language for the sake of those who are put off by theory, but it is a real tradeoff and one of the things that is likely to impede the introduction of Haskell into the mainstream.

<comment><USER2> I've learned Monoid in Haskell, not maths. It's just so simple and easy that there's really no dumbing down necessary.

Monad is simple and hard, but Monoid is simple and easy.

<comment><USER12> With respect to monoid, you're right. It's really quite simple when you get down to it. I don't have any arguments there. In fact, the fact that monoids are really so simple is kind of my point. In almost any other language, were such a thing to exist, monoids would not be called monoids but by some descriptive term which conveyed an intuitive sense of their meaning and use; it would be the purview of the mathematically inclined to write articles explaining how "actually, what we call the Joinable type class is known in abstract algebra as a Monoid, and its use extends beyond just joining things; for example..."

My point isn't really specifically about monoids; they're just an example of what often goes on in Haskell, which is that people put theory before practicality and mathematical (and hence often esoteric) definitions before practical, real-world definitions. Like I've said a few times, this isn't incorrect at all. Nor is it surprising given Haskell's origins, nor is it without purpose since it deepens your understanding of what's going on in the language. It's just a simple fact that the mathematical jargon is a turn-off to newcomers and those who don't feel they want to be forced to learn math while they're programming, or might think they're incapable of doing so.

As it turns out, I'm not one of those people; I love the mathematical side of Haskell and I love that I've learned what a Monoid is and developed an interest in type theory, category theory and all kinds of other things. But not everyone is like that, and that's the point I'm making.

<comment><USER13> Well, yeah, but... the term "monoid" already exists, and has a definite meaning. A different name might give people an intuition for it--but it will be a wrong one that they'll have to unlearn later, like the infamous burrito (not that you or anyone has suggested that monads be renamed burritos, I am happy to say!).

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> In his talk on currying, he mentioned replying on type system to not be a good thing. Does anyone know the reasons behind his view?

<comment><USER15> Currying can obfuscate what is applied to what. Consider in any ML language "a b c d" – we can see that "a" is a function, but we have no idea of its arity. Uncurried, it could be: "a(b, c, d)", "a(b, c)(d)", "a(b)(c, d)", "a(b)(c)(d)" (oh, that's the curried form again). Especially when function definitions are implied through pattern matching, it is hard to understand the contract of a function at a glance.

As a reader of that code cannot easily understand whether the number and type of arguments is correct, one has to rely on the type checker that everything will work out.

However, this is more of a criticism of ML syntax than of currying – all things are good in moderation.

<comment><USER12> It's actually simpler in some ways, because we know that "a" must have arity 1. What we know is that "a" should be a function which takes a "b", that "a b" should be a function which takes a "c", and "a b c" should take a "d".

As a practical consideration, this rarely if ever becomes an issue, and if it does, the type checker will tell you straight away.

Type annotations can make clear what isn't intuitively clear with a function's signature, and since the correctness of the type checker is rigorously proven, I don't see anything particularly wrong with "relying" on the type checker.

<comment><USER15> The argument that every function has arity 1 is technically true (this is the whole point of currying) but is not useful when definitions like "let a b c = ..." suggest other semantics. It's possible you've had a difference experience with this, but I tend to get confused when the semantic argument list isn't delimited.

There is nothing wrong with relying on the type checker, except that it tends to add cognitive overhead.

<comment><USER12> In my experience, the more you use currying, the more intuitive it becomes (surprise, surprise). In any case, you very quickly develop an understanding that `let foo bar baz = qux` is just syntactic sugar for `let foo = \bar -> \baz -> qux`. Of course, if you want to simulate higher-arity functions, you could just use tuples. It's perfectly acceptable to write `let foo(bar, baz) = qux`.

</comment></comment></comment></comment></comment><comment><USER16> Can we get an [audio] indicator?

</comment><comment><USER17> YES, I've been waiting for this! Thanks so much! :)

</comment><comment><USER18> TL;DR FP hater talks about FP.

</comment><comment><USER19> I'm going to save these HN comments for 5 years time when the hype on functional programming has died down a bit. Will be very humorous to read this again then.

<comment><USER20> No chance. The hype will recurse forever. Even on stackoverflow.

<comment><USER21> Deploy the canaries!</comment></comment></comment>


Seth Godin: Trapped by tl;dr - <AUTHOR> http://sethgodin.typepad.com/seths_blog/2014/01/the-fatal-arrogance-of-tldr.html

<comment><USER2> It all depends on the writer. If the content is useless, the summary would be too.

I often use tl;drs (or do a content scan first, in case tl;dr isn't present) to see if the content is useful and will add value, before reading in full.</comment>


Complete Discord API Wrapper Library for Clojure - <AUTHOR> https://github.com/IGJoshua/discljord <comment><AUTHOR> I've written a Discord API wrapper library in Clojure. There've been quite a few of these, but so far this one is the most complete, having full support for sharding, rate-limit handling, and the entire HTTP API (except the webhook endpoints for slack and github compliant webhooks).

Let me know what you think, feel free to contribute, and most of all, have fun building bots!</comment>


What happened to Google+? - <AUTHOR> http://www.businessinsider.com/what-happened-to-google-plus-2015-4 <comment><USER2> As author of the G+ user study mentioned in this article, I very strongly recommend the follow-up performed by Eric Enge of Stone Temple Consulting based on a larger random sample of 500,000 profiles from multiple Google+ sitemaps.

[https://www.stonetemple.com/real-numbers-for-the-activity- on...](https://www.stonetemple.com/real-numbers-for-the-activity-on-google- plus/)

Enge largely substantiates my earlier findings, though with greater precision:

Users with 50 or more posts _ever_ who have _also_ posted publicly within the past 30 days: 6.6 million.

Total profiles with _any_ public posts: 112 million.

Ten or more posts ever: 21.8 million.

Enge also extended the analysis I'd performed based on Google+'s "Followers" and "Views" profile data, again substantiating my findings that publicly- active profiles have much higher follower and views activity. Assertions by Google+ boosters that there's some vast quantity of non-public activity seem unsubstantiated.

It's also worth noting that both Enge and I are quite active on G+.

<comment><USER3> > Assertions by Google+ boosters that there's some vast quantity of non-public > activity seem unsubstantiated.

This has of course been around the beginning (when both you and I were also around). The "readers of the gaps" argument, "you can't PROVE there aren't a zillion users there! Oh, you did prove they're not there _in particular_. But you can't prove they're also not in _this other place_! Ha!"

Has anyone condemned you as a Facebook shill yet?

<comment><USER2> _Has anyone condemned you as a Facebook shill yet?_

Yes, repeatedly. It's sort of pathetically amusing by now.</comment></comment></comment>


Applied Category Theory (2019) [video] - <AUTHOR> https://www.youtube.com/watch?v=iwvl0tBJhoM <comment><USER2> Unfortunately in mathematics "application" is often a synonym for "prove a lemma or theorem."

David Spivak told me Peter Freyd once said, "Perhaps the purpose of categorical algebra is to show that which is trivial is trivially trivial."

This will only work for those who already find category theory trivial (a hard thing, as it is so general) and the target domain novel (so they are not yet confident what is trivial and non-trivial in that domain). If done wrong it can look like the art of making the easy hard.

One good use of category theory is: admitting there are composition patterns other than function composition. For example: in scikit learn the fit_transform interface has composition. When you wire up compatible classes in a pipeline they lash together the fit, transform, and fit_tranform methods in a simultaneously useful and consistent manner. With category theory you can say this is a nice form of composition, even though it is not mere composition of functions.

Another idea that can be made clearer is: separating a function's identity from its action. This lets us claim code optimizations are correct. That is f1 := x -> 2.0 x can be thought of as doubling every real number. Now for real numbers (unfortunately not for mere floating point numbers!) we have an inverse f2 := x -> x/2.0. Under a very narrow view of composition we might force f1(f2(x)) to be realized by code such as 2.0(x/2.0). If we think of composition as different than action, we might say f1(f2(x)) is just x (though again, this is true over the real numbers- not over the floating point numbers).

</comment><comment><USER3> The concepts are intuitive enough, and make sense. But I don't see what non- trivial insights this gives us.

I found the talk frustratingly vague. After all the hard work of setting up categories/operads in an example, the talk moved on without using them to do anything interesting.

<comment><USER4> Here is one non-trivial insight: Every formal logic corresponds to a category.

When we do logical deduction, we have facts and rules. We can apply rules to facts to get more facts. More specifically, formal logic is built from situations where we have some fact P, some rule P => Q, and some conclusion Q.

In a category, we have objects and arrows. We can imagine arrows as mapping one object to another, or sending one object to another. We might have objects P and Q, and an arrow f : P -> Q relating them.

The connection continues. We can take multiple rules in logic and apply them sequentially, building a proof tree; we can take multiple arrows in a category and compose them sequentially, building a _path_. In some logics, there is an idea of ex falso quodlibet, or from the false fact, anything can be proven; similarly, in some categories, there are _initial objects_ , which come with arrows from the initial object to every other object.

Just like how logical formalism eventually removed the possibility that logic is non-mathematical, category theory removes the possibility that logic is unstructured. Logic is actually incredibly highly structured, and those structures happen to coincide with structures in other parts of maths and physics.

<comment><USER5> Again though, how do I _use_ this to solve everyday problems?

I've seen some vaguely cool stuff done with Category theory in Haskell, e.g.: composable tree parsing and traversal, but I've never seen anyone actually use any of this stuff to make a deliverable piece of software that is notably better than what developers can readily produce using traditional procedural languages.

I mean sure, I suppose it would be nice if the C# team added some sort of category theoretically "pure" tree processing sub-language akin to some bastard child of LINQ and XSLT, but... meh. I don't think it would see a lot of use in practice.

<comment><USER4> A few months ago, while employed at a shop, I wrote about a hundred lines of Python which performed a basic katamorphism on some XML, outputting a PNG. Nobody else on my team could conceive of this, and were mystified by the fact that I could just sit down and do this. It wasn't too hard, though, because I could imagine the entire katamorphism in my mind.

The traditional approaches weren't just stymied by this problem, BTW; the other developers wanted to go shopping for off-the-shelf components which transform XML to PNG, as if that would get us the specific katamorphism we desired.

The nature of your everyday work will inform what you can do with category theory. I personally use category theory to design programming languages; it's something for which category theory gives a turn-the-key recipe:

* Pick some objects of interest

* Define a relatively free Cartesian closed category whose objects include your objects of interest

* Enrich the category with interesting arrows

* Extract a combinator basis

The MarshallB programming language [0] is a good example of this recipe in action.

[0] [https://dl.acm.org/doi/10.1145/3341703](https://dl.acm.org/doi/10.1145/3341703)

<comment><USER6> But the real interesting part here is the use of exact real arithmetic, not the category theoretic part. Category theory is just used as scaffolding. I would also say it is dangerous to see things only through the category- theoretic lens, because no doubt, as with any generalisation, there will be plenty of situations where it does not provide the right generalisation.

<comment><USER4> Better scaffolding leads to bigger, better buildings. Don't knock the auxiliary and ancillary techniques; they're still necessary for this sort of work to be understandable.

Also, from my perspective, the exact real arithmetic isn't super-interesting because it's not new; Turing was doing this sort of thing when he first got access to computers. Legend has that one of Turing's first recreational programs was computation of zeros of the Riemann zeta function, and ever since, there's been a tradition of exploring exact real arithmetic with computers and programming languages. MarshallB is one more incremental step forward in a big research programme of overcoming the inconvenient fact that we can't test real numbers for interesting properties with computers alone.

At no point have I advocated _only_ category theory. Categories are always composed of some collection of arrows (and objects, but I prefer object-free presentations!), and those arrows are always homogeneous, if not homoousios, composed of a single substance. We can study that substance on its own. Perhaps an analogy to materials science would be appropriate. We ought to study both each building material, be it sets, vector spaces, relations, graphs, or type theories; but also the architectural principles used to make buildings, like abstract algebra and category theory.

<comment><USER6> Yes, nothing against better scaffolding, as long as you recognise it for what it is. Arguably exact real arithmetic is older than inexact real arithmetic ;-) But that's not the point, I think the point is that it becomes interesting now to actually do computations with it. It helped me program solid modelling operations for triangle meshes, when I was despairing doing it with normal floats. Switching to exact real arithmetic allowed me to see things clearer, and once I had what I wanted running with exact real arithmetic, I could switch back to floats to make it faster.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> Url changed from [http://lambda-the-ultimate.org/node/5581](http://lambda-the- ultimate.org/node/5581), which points to this.

<comment><AUTHOR> I initially decided against posting the video because the thread has a small amount of discussion.

Mainly the link to related work: Seven Sketches in Compositionality, [https://arxiv.org/abs/1803.05316](https://arxiv.org/abs/1803.05316)

Edit: previously on HN: [https://news.ycombinator.com/item?id=20376325](https://news.ycombinator.com/item?id=20376325)</comment></comment>


TLS performance overhead and cost on GNU/Linux - <AUTHOR> http://david-grs.github.io/tls_performance_overhead_cost_linux/ <comment><USER2> Title should be renamed to start with 'Thread Local Storage...', to make it clear it's not Transport Layer Security...

</comment><comment><USER3> TLS here is referring to Thread Local Storage, not Transport Layer Security.

<comment><USER4> Thanks because I kept reading it and even though I read about thread local storage, I kept reading to see how this sped up TLS sockets :)

</comment></comment><comment><USER5> Really want to know who in the hell thought it was necessary to do lazy allocation - we don't do lazy allocation for .bss, why would it be necessary for .tbss? Especially since kernel is already doing lazy allocation (when pages are first touched)?

AFAICT there's no good reason why TLS access couldn't be just a normal segmented access and nothing more, dynamic loading or no... same as it is in the kernel.

Edit: And it's not like these are big in practice, at least in anything I have installed:

      find /lib /usr/lib -type f|grep '\.so$'|xargs -n1 size -A|&grep -E '^.(tdata|tbss)'|awk '{print $2}

says that the absolute biggest is 152 bytes, and most are a lot smaller.

<comment><USER6> Only sane implementation of TLS without aditional indirection in presence of dynamic linking would involve having per-thread pagetables, which on at least x86 mostly negates any performance benefits of threads vs. processes. Kernel code does not have this problem as kernel modules are not demand paged and there is nothing they can be shared with, so kernel can do whatever fixups it wishes to do.

x86-style segmentation has essentially nothing to do with TLS apart from the fact that it can be abused to implement it without having to reserve additional useful global registers (as it is implemented on typical RISC platforms).

TLS areas are in general very small because very often only thing that is stored there is pointer to some internally managed per-thread heap allocated struct that is then accessed directly (reasons for this are twofold: it is faster in tight loops and there are platforms that do not support linker- visible TLS).

<comment><USER5> I think you're confusing a couple different issues...

At the core, percpu variables/sections in the kernel are done exactly the same way as the TLS is implemented in userspace, except with gs instead of fs.

The thing that I'm complaining about is that on top of that, glibc is doing lazy allocation for no apparent (sane) reason.

</comment></comment></comment><comment><USER7> Please expand "TLS" to "Thread-local Storage" in the misleading title.

<comment><USER7> Why a downvote for this? I don't understand. Others have pointed this out, too.

</comment></comment><comment><USER8> Acronym soup</comment>


Researchers develop acoustic based data transfer system for phones - <AUTHOR> http://www.computerworld.com.au/article/523718/researchers_develop_acoustic_based_data_transfer_system_phones/

<comment><USER2> Title: "Researchers develop acoustic based data transfer system for phones"

When I first saw the title, I thought it was an Onion parody -- acoustic modems are hardly a technological breakthrough.

"Technology employs 'self-jamming' for security and could be an alternative to NFC. No word on whether it sounds like the squeal of a 56k modem."

Also not a new feature -- my acoustic modems were perfectly self-jamming, most of the time.

All kidding aside, as described the project could piggyback a secure, low- data-rate connection on top of a cellular voice connection.</comment>


Ask HN: How to Learn AWS? - <AUTHOR> How can I learn how to deploy modern software on a public cloud safely, securely and in a cost efficient manner?
I'm asking because i'm trying to get a semi complicated software stack out of docker-compose and into the world via AWS. I am trying and failing due to the overwhelming amount of options out there to deploy anything.
Maybe it's helpful to give the stack I have created. I have a react front end, postgres DB for user login and session management, mongodb for a document store, and redis for handling a job queue. This was all running in a docker-compose file with a single network.
When I tried to get this running on AWS I read a lot about Kubernetes and came away with the impression that it's too complicated for most people, and in fact most people don't even need it. But I wanted to stay with Docker so I could deploy updates simply.
So using ECS Fargate I was able to get my front-end and back-end running but when it came to getting redis and postgres running I wanted to use the fully-managed versions on AWS, but then I started reading about VPC's and started to realise I don't know enough about the fundamentals to make informed decisions on how these bits should all talk to each other - hence me asking here.
Are there good websites, tutorial series or books out there I could read to understand the complexity of all this? <comment><USER2> I recently took and passed the AWS Certified Cloud Professional exam, based on the training material from [https://acloud.guru/](https://acloud.guru/) and my personal experience (30+ years as a SysAdmin/DevOps Engineer, overlapping with 7+ years as a cloud consultant, including working extensively with AWS). I'm now going through the acloud.guru training material for the AWS Certifies Solutions Architect. And I've got several more AWS certifications planned.

The acloud.guru site is not the only training facility out there — I think there may be better material from certain teachers on Udemy.com, but acloud.guru is free for us thanks to an arrangement with my employer, so that's the primary service I'm using.

In the years since I graduated from university and went into the professional field in 1989, I haven't seen very many certificates that I felt had a lot of value. Netware certificates actually meant something. As did Cisco certs. But I've found very few other certificates that do. So far, I have been pleasantly surprised by the amount of stuff I've learned in pursuit of my AWS certificates. Sure, there's lots of stuff I already knew, but then there were also a surprising amount of gaps in my knowledge that I would have never known about, had I not gone through this training.

That said, just going for the certificates is not useful. You have to get your hands dirty. You have to actually build stuff with the material you're learning. You can use a free account, or the "sandbox" type systems that are provided through acloud.guru, or other training facilities.

If you want to learn AWS, I recommend you actually do stuff with AWS. You'll learn it as you build and break various things. And doing the certifications as you go may help you learn more than you could have learned on your own.

</comment><comment><USER3> [https://www.aws.training/](https://www.aws.training/) should help you out :)

<comment><AUTHOR> I saw links to this and thought it would be bullshit-y enterprise training, but now I actually look at it looks actually useful - so, thank you!</comment></comment>


Show HN: A brainstorming tool to help you predict the next 10 years in tech - <AUTHOR> https://perchance.org/tech-prediction-prompts?v=3 <comment><AUTHOR> It's really simple! Perhaps not worthy of Show HN. I've just been working on it throughout the day, tweaking the word lists to try and make it produce interesting ideas. Still 90%+ nonsense, but if you click for a while, some interesting ideas come up, I think.</comment>


Breaking Chains with Pipelines in Modern JavaScript - <AUTHOR> https://www.wix.engineering/post/breaking-chains-with-pipelines-in-modern-javascript <comment><USER3> Maybe it's just me, but I don't see the purpose of a pipeline operator - <USER2> least in JS.

From a cognitive perspective, it doesn't make code more readable or easier to understand.

From a practical perspective, why? What can't we do with it that isn't aesthetic?

Edit: Okay, after reading through the article again, I get it. I've had issues with eager loading in Node AND I will say the pipeline is easier to understand than simply using generators. Good article.

<comment> crooked-v A simple example would be mixing map/reduce stuff on arrays with other non- built-in utility functions that take arrays without having to break the logical flow.

For a very simple example, manipulating and summing an array of values:

        import { range, sum } from 'ramda';

        range(0, 6)
          |> x => x.map(i => i * i)
          |> sum

Compare to:

        import { range, sum } from 'ramda';

        sum(
          range(0, 6)
            .map(i => i * i)
        )

...and then add three or four other non-builtin methods in between map steps and consider the resulting readability.

<comment><USER4> I mean, I think one of the big arguments against a pipeline operator is that you can easily roll your own with

      const pipe = (...fxs) => x => fxs.reduce((v, f) => f(v), x);

If you're going to pull in ramda for example, they have their own pipe, and a map function that takes (predicate, array) as curried arguments, to aid with composition import { map, pipe, range, sum } from 'ramda';

        pipe(
          range,
          map(i => i * i),
          sum
        )(0, 6)

I haven't messed with HN formatting before, so I hope that turns out right. My team uses Ramda and pipes regularly in our Node code, and its absolutely wonderful

</comment></comment></comment><comment> crooked-v I really wish we could just get a pipeline operator past stage 1. It seems like such a simple idea philosophically but apparently the big players can't agree on any of the exact details.

</comment><comment><USER5> > Fortunately, a much better syntax for this type of expressions is being > introduced by ECMAScript, known as the pipeline operator.

This is "Stage 1: Strawman Proposal." It's not exactly accurate to say the operator is being introduced " _by_ ECMAScript", more like "it's being proposed for addition _to_ the ECMAScript specification."

</comment><comment><USER6> I would have preferred .pipe, .partial and .partialRight functions in the std library instead of adding more syntax sugar.

</comment><comment><USER7> Since when does "modern" mean not-yet-standardized?

<comment><USER5> [https://sequoia.makes.software/what-is-javascript- part-1-the...](https://sequoia.makes.software/what-is-javascript-part-1-the- problem/) agree

</comment></comment><comment><USER8> Huh, I'd never seen a pipe method with the # as the placeholder before. That seems like a pretty nice way to make it flexible.

<comment><USER5> Clojure has a similar thing, where % is used as a placeholder in threading, which is similar [https://clojure.org/guides/threading_macros](https://clojure.org/guides/threading_macros)

</comment></comment><comment><USER9> RamdaJS may interest you if you like pipes

<comment><USER4> For anyone looking at picking up Ramda, the docs at ramdajs.com are great API docs, but don't tell you a thing about how to actually use lenses, transducers, and point free data last functions with pipes. Randy Coulman has a great list of guides on how to actually use Ramda on his blog[1]. Start at the bottom with the introduction and work your way up.

[https://randycoulman.com/blog/categories/thinking-in- ramda/](https://randycoulman.com/blog/categories/thinking-in-ramda/)</comment></comment>


PostgreSQL Foreign Data Wrappers - <AUTHOR> What are the examples of usage of PostgreSQL Foreign Data Wrappers? <comment><USER2> We have PG on a powerful box (256GB RAM, SSDs, 5000 core GPU), and use FDWs to import data from other databases for analysis. For example, our main data warehouse is on MS SQL Server, but not super fast, so we use a FDW to grab data from there and analyze it quickly in PG. We also have an Oracle DB, and there's an FDW for that too.

<comment><USER3> > our main data warehouse is on MS SQL Server, but not super fast

MSSQL on similar capacity hardware as PostgreSQL? Is the data restructured once in PG for specific queries?

Curious as to why MSSQL is slower given it has some advantages for data warehouse workloads such as query parallelism?

<comment><USER2> The MS SQL Server is on a different, older, cheaper machine. The PostgreSQL one is faster because it's newer and we had budget for it.

We also have two different database teams (actually more, it's a large company): IT controls the data warehouse (MS SQL) and BI controls the analysis server (PG)

As juliangoldsmith anticipated, we use PGStrom (also a FDW) so we can use our GPU for super fast scans.

</comment></comment></comment><comment><USER3> Easy, direct access to different external data formats: [https://wiki.postgresql.org/wiki/Foreign_data_wrappers](https://wiki.postgresql.org/wiki/Foreign_data_wrappers)

Alternate storage types: [https://github.com/citusdata/cstore_fdw](https://github.com/citusdata/cstore_fdw)

</comment><comment><USER4> file_fdw.

I have a file that keeps changing constantly. What was a file read/write at app level has been replaced. Less code, direct access to data and readily "ETL-able".</comment>


Ask HN: Which self-hosted, enterprise-ready Slack alternative do you use? - <AUTHOR> There's HipChat Server. However, since Atlassian launched Stride, I fear HipChat will fall behind.
My company does not want to use yet another free Slack alternative on GitHub. We'd love to pay and have a phone number to call if things go south.
End-to-end-encryption (as in: DB admin cannot read anything) would be a plus, of course. <comment><USER2> Were using Zulip. Before that we used Mattermost but we migrated to Zulip because of its (in our opinion) superior conversation threading model and never looked back.

Mattermost, Slack, etc. all work fine when you work on a project basis but when you work on a lot of short lived operational issues (for example "Issue with invoice XYZ" Slacks conversational threading model breaks down quite fast. At least it did for us.

iirc there is also a paid hosted version of Zulip but I don't know that for sure.

<comment><USER3> The hosted version is free for FLOSS projects and has a premium option: [https://zulipchat.com/plans/](https://zulipchat.com/plans/).

</comment></comment><comment> maze-le Mattermost, works quite good. It is also pretty simple to set up and deploy.

[0]: [https://github.com/mattermost/mattermost- server](https://github.com/mattermost/mattermost-server)

EDIT: just read your post entireley.

>> 'My company does not want to use yet another free Slack alternative on GitHub'

So that one is not what you are looking for. But I keep the post in case anyone is interested in it...

<comment><USER4> Nobody runs a SaaS for Mattermost?

</comment></comment><comment><USER5> Along the same lines as the question, does anyone consider keybase.io teams feature a viable alternative for small to medium sized teams?

<comment><AUTHOR> We currently do use Keybase teams. We love the concept. Unfortunately, we do not consider Keybase production-ready, yet.

Especially the mobile apps are pretty buggy atm, which is one consideration why we're looking for an alternative.

</comment></comment><comment><USER6> IRC?

</comment><comment><USER7> "End-to-end-encryption" has flailed us.

</comment><comment><USER8> microsoft teams

<comment><USER9> I'll second this. While it's not self-hosted, it is the only SAAS option that's actually usable in regulated industries. The main consideration is that the api is slightly different and some integrations aren't as nice (Looking at you PagerDuty)</comment></comment>


The Long Path to Artisan Independence - <AUTHOR> http://helloanou.wordpress.com/2014/04/20/the-long-path-to-artisan-independence/

<comment><USER2> From the site: "Anou means a well of water in Tashelheet, the language spoken in the Ait Bouguemez valley of Morocco."

It's also a play on words w/ French (widely-spoken in Morocco) -- "À nous" (pronounced the same) means "to us".

</comment><comment><USER3> I'm proud to be working on an early-stage startup that hopes to expand on this model and its successes, incorporating artisan materials and stories into affordable-luxury fashion products while opening dialogues between artisans and end-users (they're more than just consumers!).

This article raises some interesting points. Seemingly unlikely occurrences like accidents or geopolitical/remote events disrupting the only internet access point for an artisan collective become important risk factors for a startup to account for in their timelines, especially when they rely on artisan partners for dependencies early on in the Gantt chart for a product cycle! As if we didn't have enough uncertainty just by virtue of being a startup... :) Good planning, redundant communications channels, and relationships with multiple people on the ground at various distances (and therefore in multiple internet connectivity zones!) can mitigate this... to a point.

Something that startups like us do need to think about is resistance within artisans' communities. As the article mentions, "men's resistance was rooted in the fact that their control as resellers of the rugs would decline as the women learned how to do it on their own." Only regular on-the-ground presence can have a chance of detecting these scenarios and mediating them, and that's tough for a startup to prioritize - but it often has to be done.

Finally, when the authors cite youth who avoid training for artisan skills because they fear that "in the best-case scenario, you live a life as an organization's beneficiary," this scenario is something that even the article's success story needs to mitigate. While the successful Imelghaus cooperative is in many ways independent, it's still the case that Imelghaus' revenue stream largely depends on the continued appeal of a foreign-operated brand, as well that brand's continued commitment to Imelghaus even as they onboard other artisan collectives. This is especially true for artisan products being incorporated into the fashion industry, where seasonality and freshness of products is considered highly desirable (to say the least). Our team's hypothesis is that at scale with multiple product lines incorporating different artisans' products, we can continue to drive sales to artisan groups that were highlighted in previous seasons, by promoting them in the same way any data-driven company would promote related products to new and existing customers; to put it mathematically, we'd add regressors for the success of our artisan partners into the optimization algorithm for recommendations, rather than recommending simply by user preferences alone, and leverage the strength of our brand to make this strategy viable. We're still at the product development stage, so only time will tell if this bears out. But it's an intriguing and fulfilling space to dive into!

(If you're interested in discussing more, feel free to contact me in my profile!)</comment>


Should CS depts. reject creative applicants? - <AUTHOR> http://www.quora.com/Should-CS-depts-reject-creative-applicants

<comment><USER2> So you posted this question here as "Ask HN:" and it got no traction; now you posted it no Quora and have posted that link here -- is there some ulterior motive you have?

<comment><AUTHOR> I've had quite a bad experience with CS. It focuses on all the wrong things.

<comment><USER3> Can you elaborate what you mean by it focuses on the wrong things? I'm confused because Computer Science is a tool that is supposed to enable you to focus on what you want.

<comment><AUTHOR> CS makes sense as a major if you want to work as a highly paid software engineer building someone else's products.

That's not the creativity I care about.

<comment><USER3> What about all of the entrepreneurs who come up with their own products and code them? Also CS is a major about how to think about problems and solve them. Any creative person needs that skill set eventually. Whether they get that from Computer Science is up to them but CS makes sense as a major for a variety of people.

<comment><AUTHOR> Much of the programming entrepreneurs do is not difficult -- especially with the availability of all sorts of libraries for more difficult things.

CS would be more useful for those people building difficult libraries that require specialized domain knowledge.</comment></comment></comment></comment></comment></comment>


Show HN: Animated bubble charts (bubblecharts.js) - <AUTHOR> http://randomexperiment.com/experiments/javascript/bubblecharts/timeplot.html

<comment><USER2> I like the animation, it's an interesting way to show time series. If I were you, I would explore opportunities to build animated charts of all types (there's a challenge in the axis animation, to keep it smooth so viewers can make comparison between past and present without effort).

<comment><AUTHOR> Thanks - that's actually a pretty good idea. With the base structure already needed for the bubble charts - animations, drawing axes, etc., it is not gonna be too difficult to extend this to other chart types.

May be when I get some spare time - I will put it into this.

</comment></comment><comment><AUTHOR> The idea came from here - [http://www.ted.com/talks/hans_rosling_shows_the_best_stats_y...](http://www.ted.com/talks/hans_rosling_shows_the_best_stats_you_ve_ever_seen?language=en)

This was my first major project on javascript... I am not a developer by profession. What do you guys think?</comment>


Abercrombie & Fitch's Fierce scent contains 11 harmful (unlisted) chemicals - <AUTHOR> http://consumerist.com/2010/10/teens-unite-in-protest-of-abercrombie-fitchs-fierce-stench.html And here is the study<p>http://safecosmetics.org/downloads/NotSoSexy_report_May2010.pdf <comment><AUTHOR> Link to actual study:

[PDF] [http://safecosmetics.org/downloads/NotSoSexy_report_May2010....](http://safecosmetics.org/downloads/NotSoSexy_report_May2010.pdf)</comment>