CSS-Only Clickjacking - <AUTHOR> http://jsfiddle.net/gcollazo/UMyEm/embedded/result/

<comment><USER2> "This seems like a real security threat and I haven't found a foolproof way of detecting it. Is there a way of protecting against this kind of attack?"

No. If you're going to provide clickable widgets that can be embedded in other people's sites, there is no technical method for preventing clickjacking.

Even if it was impossible to hide the element (pointer-events: none is one method, another is to place the Like button itself on a div with an opacity of 0.001) it could still be attacked by tricking people to click repeatedly in a certain area and then displaying the button. "Click here five times as fast as you can to win a prize" kind of thing.

The developers of the Facebook Like / Twitter Follow buttons know this, but they decided that the trade-off was worth the risk. There are also statistical counter-measures they can take behind the scenes (machine learning algorithms for identifying large numbers of potentially fraudulent Likes for example).

<comment><USER3> > there is no technical method for preventing clickjacking

I think there is. Most of these widgets are embedded using SCRIPTs which have access to the parent page's DOM structure. For Twitter/Facebook they can basically access anything on your page. This means, they can do a check for `pointer-event:none` (computed CSS value) on the element above the widget (get that using `document.elementFromPoint`).

EDIT: After some investigation: elementFromPoint doesn't work on elements with pointer-events:none, it seems. That sucks. It may still be possible to circumvent these attacks. For example, when the widget receives a mouseenter event, it could place itself at the end of the document tree in the parent page and ensure it has the highest possible z-index. I'm sure there are other viable options too...

<comment><USER4> I'm not following.

You suggest that these obnoxious buttons should start behaving even more annoying by peeking around the side and potentially rearranging/changing themselves?

First, I don't believe that an arm's race makes sense. There are too many ways to trick someone into clicking a thing. Second: Please... Like buttons are already as lovely as blink tags on a Geocities page. They don't need to be 'improved' like that.

</comment></comment></comment><comment><USER5> This again?

Ah. Good old noscript.

<http://i.imgur.com/Cb17T.png>

<comment><USER6> Hmm.

I don't know why `pointer-events:none` is being made a big deal of. In the past, it was easy enough just to put the Like button on top, and set its opacity to 0; all `pointer-events:none` does is make that easier.

More relevantly, we used clickjacking back in the day to do things like have custom Upload buttons (since it wasn't possible to finely style an `<input type="file">`). Does NoScript warn against that? (and should it?)

</comment></comment><comment><USER7> This is possible in IE as well with this code:

      .clickjack_overlay {
         filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(src='white.png', sizingMethod='scale');
         background:none !important;
      }

</comment><comment><USER8> Well, for that (and similar facebook-like clickjacking) Facebook implemented some kind of "protection". If there are too many unlikes shortly after Like button is pressed, new users that click on Like button will be presented with confirmation, something like "Are you sure you want to like this page?"

</comment><comment><USER9> So, the news here is that's "CSS only". Well, I hope no one will ask for _pointer-events_ removal because of this. The feature is very useful exactly because it doesn't require JS (example: transparent tooltips). And for hijackers it makes almost no difference - to include "Like" kind of button they need a script anyway.

</comment><comment><USER10> Weird, had to look it up. Mozilla Developer Network entry on pointer-events: <https://developer.mozilla.org/en/CSS/pointer-events>

</comment><comment><USER11> "pointer-events: none;"

WTF? When did that get implemented?

<comment><USER12> The click-jacking ability has been known for over a year now: [http://robertnyman.com/2010/03/22/css-pointer-events-to- allo...](http://robertnyman.com/2010/03/22/css-pointer-events-to-allow-clicks- on-underlying-elements/)

</comment></comment><comment><USER13> NoScript catches them both. It needs to be recognized as much more than just a JavaScript-blocker.

<comment><USER14> And just to be clear, NoScript catches these even when it is set to allow JavaScript by default! Running NoScript in "Allow Scripts Globally" mode breaks almost no sites and _still_ protects you against lots of nasty attacks.

</comment></comment><comment><USER15> This is why I always use a Chrome incognito window for everything I don't completely trust. No big deal in this case because I'm not logged in to anything when browsing. If a site prompts me to log in to Facebook or twitter (as in this case), I know something is fishy. Is it a bit more of a hassle? Yes, but not as bad by an order of magnitude of getting an account hijacked. My biggest friend is right-click and "Open link in incognito window".

<comment><USER16> Command+Shift+N

<comment><USER15> \--incognito (add this to the command line after Chrome)

</comment></comment></comment><comment><USER17> How is that different from putting an "opacity: 0" like button above a link (in that case)?

</comment><comment><USER18> Theoretically, adding the following to your browser's user stylesheet should defeat this:

        a { pointer-events: auto !important; }

The !important keyword adds weight to the rule, which trumps origin, specificity and sort-order in the CSS cascade.

A quick test in Safari/Mac confirms that works for this particular case.

</comment><comment><USER19> Time to make a chrome extension that injects code to override this..

</comment><comment><USER20> There isn't a way of protecting against this attack, unless these buttons can't be embedded in web pages.

Well, that, or use Flash.

<comment><USER21> @taze There is a way. It's called noscript. Does a terrific job of staying on top of issues like this.

Also because of this example I went one step further and used AdBlock to block any iframe with a facebook url.

@general The facebook button (at least in firefox) doesn't change to the hand icon when hovering over the link. So, fail. I wouldn't click a link where the cursor didn't change. Mostly, because when it doesn't change I immediately become suspicious.

<comment><USER4> As someone who's lazy with AdBlock (subscribe, forget): Can you share that rule?

<comment><USER21> Hey. Sorry for a majorly delayed response. Looks like I have two rules for this. They might be able to be optimized into one, but - I'm lazy too.

      com##IFRAME[src^="http://www.facebook.com/]

      ##IFRAME[src*="facebook.com"]

edit: Note - you need the 'Element Hiding Helper' that goes with Adblock Plus to do this. Then you can just use that to select the iframe on a site and add the rule through a nicer interface.

</comment></comment></comment></comment><comment><USER22> So potential solutions:

1\. Use NoScript

2\. Logout of social sites when you leave them

3\. Use separate browsers for social sites

None of those is a particularly convenient solution.

<comment><USER13> If Firefox is your main browser, and you put NoScript in the "Allow Scripts Globally"-mode, it's not much of a hassle.

</comment></comment><comment><USER23> It sorta feels like we broke the web when it became the norm to stay logged-in everywhere all the time.

Oops!

</comment><comment><USER24> Could be only me but twitter tries to redirect for me despite me being logged in.

<comment><USER24> oh I'm running disconnect.me -- might be relevant..

</comment></comment><comment><USER25> i see a small portion of the button not hidden by the div (firefox 12)

</comment><comment><USER26> Wow.

</comment><comment><USER27> i can totally see one side of the button under the link on opera :D</comment>


Show HN: Using city permits to map Sonic.net fiber - <AUTHOR> https://github.com/ThatDan/sonic_fiber <comment><USER2> Link to the map itself: [https://thatdan.github.io/sonic_fiber/](https://thatdan.github.io/sonic_fiber/)

<comment><USER3> That's cool. Is there data for outside of San Francisco? For example, Brentwood? I am considering moving to Brentwood since Sonic offers fiber there. Would like to learn more about their coverage.

<comment><USER2> As someone who used to live in Brentwood, the Brentwood fiber rollout was very disappointing. Sonic used to have maps of their planned rollout that now point to dead links [0]. The house I used to live in was marked as planned to receive fiber by fall 2016, but when I put in the address Sonic says they currently don't service it.

For those who don't know, Brentwood was slated to be one of the first places in the Bay Area to get fiber, mostly because Brentwood required fiber conduit houses built for all developments after 2000, and because its city council was fairly generous to Sonic themselves. I don't strictly blame Sonic here... they took a risk doing this and likely were unable to drum up the support and enthusiasm in the community that would make a true city-wide rollout economically feasible. Seeing Sonic's experience in Brentwood makes me believe that the only way FTTH will be vastly deployed in the US anytime soon is through government subsidy.

[0]: [https://www.sonic.com/get-involved-brentwood- fiber](https://www.sonic.com/get-involved-brentwood-fiber)

<comment><USER4> San Francisco's population density, willingness to pay for faster internet, and displeasure with Comcast will hopefully mean more success than Brentwood.

</comment></comment></comment></comment><comment><USER5> Awesome. One of those blue lines is close by, so I looked up my address in Sonic's availability tool[1], and sure enough: "Gigabit Fiber is coming to your location Service is scheduled to be available Dec 2017"

[1] [https://www.sonic.com/availability](https://www.sonic.com/availability)

<comment><USER6> I'm half a block away from one of the blue lines, unfortunately the tool's only presenting me with DSL... I love Sonic, but I used to have their DSL service and it wasn't great. Not Sonic's fault, but San Francisco's copper is pretty horrible.

These days I have a Comcast business account, but I'd take any chance to switch back to Sonic.

<comment><USER7> Sonic installed my fiber service late last year. Last week AT&T was hanging fiber on my street. I chatted with the lineman and he was upfront (unsolicited, even!) that the only reason he was out there was because Sonic forced AT&T's hand. Previously AT&T was building out FTTN infrastructure in places like Mission Bay, but he said they've completely ditched that strategy and are switching to FTTH. However, Sonic appears to be methodically rolling out fiber street-by-street. The lineman said AT&T had him installing fiber in a more-or-less haphazard manner. I guess AT&T is literally freaking out, trying to catch up and perhaps head-off Sonic as best they can.

Anyhow, point being, while Sonic's methodical rollout might mean they are unlikely to reach you anytime soon if they've already passed you by, keep an eye on the AT&T trucks. They may decide to systematically install service to the areas Sonic misses, or inexplicably serve your street before another. AT&T is charging $90/month to Sonic's $40/month, with less guaranteed throughput, so it's particularly attractive for them to serve a block Sonic misses.

$90/month is still amazing, but I think AT&T's strategy is going to be much like Comcast's: $90/month for internet only, or $95/month for internet + network television. Either way you're going to be paying for the network television. But they want to induce you to be "officially" served so they have something to sell to the networks and advertisers.

<comment><USER8> > The lineman said AT&T had him installing fiber in a more-or-less haphazard > manner. I guess AT&T is literally freaking out, trying to catch up and > perhaps head-off Sonic as best they can.

When ATT did my street (in San Jose), they had cables labeled and made for each street with the right length drops to connect at each pole. It may seem haphazard, but there's enough planning in getting the cables made that there's probably some reason to the madness. Their FTTN was a mess of different speed tiers, many of which wouldn't be available for a given user, perhaps the precise cabling reduced costs enough for FTTH to be cost competitive enough to get installed instead.

</comment></comment></comment></comment><comment><USER9> Not an American, so could someone tldr me what makes Sonic.net interesting? Just better than Comcast/VZ/etc?

<comment><USER10> Sonic.net customer here. Why I give them my money:

1) [https://corp.sonic.net/ceo/](https://corp.sonic.net/ceo/) The company is politically outspoken and well aligned with the interests of its customers.

2) Their customer service is actually knowledgeable, empowered and downright pleasant to engage with. The only frustration I've had is whenever they've had to delegate work to AT&T.

<comment><USER11> I'll also note that, though the DSL service is obviously not very fast, it has had excellent uptime and consistency for me. I'm consistently able to stream HD video (1080p 30fps, 900p 60fps) without interruption. Contrast this to local cable where many people complain about poor streaming performance around peak times, despite much 'faster' service.

As much as 12-14Mbps is limiting, you genuinely get that performance nearly always.

</comment></comment></comment><comment><USER12> I was debating about getting it and curious if it really makes that world a difference? Does a gigbit connection make the internet substantially better?

It's almost double the cost of MonkeyBrains another provider that has a strong net neutrality position, custom service, and etc.

<comment><USER13> My friends with MonkeyBrains grumble about variable bandwidth availability and poor customer service. Sonic has been rock solid for me on both accounts.

Personally, I expect the gigabit connection to make a pretty modest difference for me vs my current ADSL. The main problem it'll solve for me is backups, which take too long to run. It'll also make it much easier to stream audio and video from my home server to other spots when I'm traveling.

<comment><USER12> I will admit, variable bandwidth availability has been painful sometimes. Sometimes I just want to watch a movie and it's like crawl.

Not sure if that's worth an extra $500/year though for gigabit.

<comment><USER13> If I'm reading things rightly, it's about $700/year for gigabit. [1] I'm paying something like the same for Sonic's ADSL, so it's a no-brainer for me.

[1] [http://hoodline.com/2017/05/sonic-now-offering-gigabit- fiber...](http://hoodline.com/2017/05/sonic-now-offering-gigabit-fiber- internet-in-new-san-francisco-neighborhoods)

<comment><USER14> Yes, Sonic's DSL offerings are quite expensive.

</comment></comment></comment></comment></comment><comment><AUTHOR> Happy to see this hit the front page.

I wanted to share this with the users at [https://forums.sonic.net](https://forums.sonic.net) who have been pining for maps but you need a Sonic.net account to post. If anyone is willing to share, I'd appreciate it.

<comment><USER15> I posted it to the Access forum there.

Thanks for the map, it is now clear to me that they will not get to many of the hills of the city for quite some time.

</comment></comment><comment><USER16> If you want this in your Bay Area town/region you should write your city council. There are a lot of older neighbors who oppose new poles / new right of ways so it's good for the City Council to hear voices that support fiber.

</comment><comment><USER17> [http://projects.timesfreepress.com/2014/05/epb/gig/gig.html](http://projects.timesfreepress.com/2014/05/epb/gig/gig.html)

</comment><comment><USER18> not worth a PR (cos it's opinion and a specific application), but if you have aria2c on your machine you can do something like:

aria2c -i permiturls.txt

to download file lists.

<comment><USER19> wget supports the same :)

<comment><USER18> ah, I had a feeling one of the more common methods did... i even checked the curl man page but not wget's :(

</comment></comment></comment><comment><USER20> Why doesn't Sonic have a map like this on their webpage? They could even add a second color for "coming soon" streets.

</comment><comment><USER21> Wow I'm 1/2 block away from a fiber line. How do I convince Sonic to do my street?

<comment><AUTHOR> There are examples of complaints about this on Sonic's forums[0] If you're not parallel to a line you might be out of luck.

[0] [https://forums.sonic.net/viewtopic.php?f=10&t=1085&start=131...](https://forums.sonic.net/viewtopic.php?f=10&t=1085&start=1310)

</comment></comment><comment><USER22> Looks like it's just san francisco? Might want to alter the title.

</comment><comment><USER23> Very cool... The map comes pretty close to my house so I put in my address and they allowed me to preorder for October.

Thanks!

</comment><comment><USER24> Neat stuff!

I'm pretty sure I saw them out there today stringing some up on my street, and it's reflected on the map.

</comment><comment><USER25> 2 blocks from where I live... dammit! So close, and yet so far...</comment>


The New York Times Redesign is Live - <AUTHOR> http://www.nytimes.com/?redesign=true <comment><USER2> If I may take a moment to whinge and whine a tad; Websites like this infuriate me because for all their "design", sites like Reddit and HN (which are basically just lists) are delivering news in a much more consumable fashion, better suited to the eating habits of the common or garden user.

Who's to blame? The designers with their need to make their own mark? The suits with their demands that the business needs be met regardless of the way the world actually works? Probably both.

Also, I think Digg deserves more credit for finding a successful mid point between lists and designed layouts.

That's not to say there's no room for design, but this new NYT layout is anything but design. It's the same wall of information with sporadic and indecipherable levels of emphasis made to look mildly palatable for another couple of years. If the NYT has anything interesting to say, I'll wait for it to appear on HN, Digg or Reddit.

<comment><USER3> My dad finds sites like Reddit/Digg/HN totally overwhelming, and I doubt he's alone. It's generational. Sites like NYT use standard design techniques to direct your attention (font size, etc) that work really well for people that are more-accustomed to traditional media. And, frankly, seeing a huge-headline is a much more-immediate way to indicate the importance of a topic than scanning down a list and looking for stories with lots of upvotes or comments.

<comment><USER4> The Drudge Report skews heavily for an older (50+) male demographic (going by Quantcast.) The design is text heavy, small fonts. A more static version of HN/Reddit, from one or two contributors rather than a community.

Design has not changed since 1997: [https://web.archive.org/web/19971210093544/http://www.drudge...](https://web.archive.org/web/19971210093544/http://www.drudgereport.com/)

19 million+ US uniques makes it a very important news site (NYTimes has about the same amount.)

</comment></comment></comment><comment><USER5> The design is overall asthetically pleasing. I just can't fucking take this trend of fixed bars molesting my vertical resolution and screwing with my habitual behavior of scanning from the top of the page down as I scroll. This site's top bar on single pages is so edgy that it's not even at the very top (a concept I've at least gotten acclimated to) and manages to blend into the actual article content due to low contrast.

Please just stop doing this, _everyone_! We do not need a bar following us everywhere by default. As long as it doesn't cause render lag, fixed elements are fine when they're small buttony icons that expand.

At least they've gotten the snap-back right. Some sites, when scrolled to the top, do this awkward infuriating stuttery clip-in nonsense where the scroll position changes as the menu fits back into the content. Just stop.

<comment><USER6> I agree totally. This trend is infuriating. When I have to read an article on the site with a top bar I often go into the developer tools and delete that node from the DOM. There are sites that make even that measure impossible, like gmail, which is even more infuriating.

I use a small screen most of the time, and it sometimes seems like the designers of these sites have never looked at their website on a monitor smaller than 30 inches.

If it's so important that I be easily able to reach some navigation, put a tiny, unobtrusive, go-to-the-top button in a fixed element off to the side which will pop me back up to the nav bar.

</comment></comment><comment><USER7> The changes on the homepage a minimal, howserver they have made some big changes to the artical pages ([http://www.nytimes.com/2014/01/08/business/international/asi...](http://www.nytimes.com/2014/01/08/business/international/asian- factories-see-sense-and-savings-in-environmental-certification.html)).

Note that you can now scroll through the entire article, no clicking next three times!

<comment><USER8> Looks very similar to the NPR blog articles now. I like this trend - long, clean single page articles.

</comment></comment><comment><USER9> I like the clean typography, and appreciate that they were content with subtle changes rather than something "radical." But why, oh why, did they add one of those horrible floating bars at the top of the screen? Those things almost always break page-down, yo!

<comment><USER10> Page down is working for me...

<comment><USER9> True, I can still hit the space bar, but it does something different and broken. Try paging down on HN, and you'll see that the bottom 1-2 lines are preserved at the top of the screen, so you don't lose your place. Now try it on NYT: at least for me, there is absolutely no context preserved. That's better than the all-too-frequent case where a line is missed entirely, but it still makes reading harder. Plus, I'm so used to lousy sites that skip a line on page-down that I don't trust the NYT's version not to do so.

EDIT: They seem to do the right thing on articles, but not on the front page.

<comment><USER11> The front page is working correctly for me in Firefox 26. When I hit page down or space the two lines that were at the very bottom of the screen move to just below the top bar.

</comment></comment></comment></comment><comment><USER12> How do you like the typography? I find e.g. the italic font for the headlines in the left column or the small all caps serif format of the bylines to be somewhat detrimental to readability.

<comment><USER13> I was just going to say the font sucks, there's a million free fonts on google fonts that look great... and they appear to have gone with times new roman for no particular reason.

<comment><USER14> They actually seem to be using Georgia for body, and the headlines are in the same setting of Cheltenham they use in the physical paper.

</comment></comment></comment><comment><USER15> I'm underwhelmed. They should have hired the firm that did [http://globe.com](http://globe.com) . I'm actually puzzled they didn't considering their ownership of the Globe at the time of that redesign.

</comment><comment><USER16> I like the new design, especially the more iPad-friendly article pages.

But what I am most happy about with the new design is that the NYT didn't break the backdoor into reading any article behind the paywall, if you're not a subscriber.

If you run into the paywall that blocks your reading an article, just fire up whatever Twitter app you use (I use Echofon), type the text of the article's _headline_ into the search, search for it, you'll find tons of results almost always, and just click on one of those links.

Presto, you're now reading the article free and clear.

TL;DR If you arrive at a NYT article via a shared social link, you can bypass the subscription paywall.

<comment><USER17> Use private browsing/incognito mode. Much easier.

<comment><USER18> Using Chrome, I configured nytimes.com cookies to "Clear on exit" from each browser session. Since I restart my browser at least once a day, and I only land on the New York Times as a result of links, I never hit the monthly limit of 10 free articles.

Open Settings, search for "content settings", click the Manage exceptions button, and add one for [*.]nytimes.com.

</comment></comment></comment><comment><USER19> I hope they find ways to speed things up. When I return to the main page from a story, I have to wait five seconds while items on the front page bounce around as things load. This is on a very fast connection and a mac pro.

<comment><USER20> They have some extremely poor performance optimizations err NO performance optimizations on the front page. TONS of individual unscaled images loading. Someone might want to introduce them to a product called "Pagespeed"...

<comment><USER21> It looks like they're running Varnish for caching the pages - is the main issue the images?

</comment></comment></comment><comment><USER22> Details about the redesign and technology overhaul: [http://source.opennews.org/en-US/articles/behind-scenes- nyt-...](http://source.opennews.org/en-US/articles/behind-scenes-nyt- redesign/)

i.e. "… using Github instead of SVN for version control, Vagrant environments, Puppet deployment, using requireJS so five different versions of jQuery don't get loaded, proper build/test frameworks, command-line tools for generating sprites, the use of LESS with a huge set of mixins, a custom grid framework, etc."

</comment><comment><USER23> Obligatory link to the the skimmer: [http://www.nytimes.com/skimmer/?pagewanted=all#/Top+News](http://www.nytimes.com/skimmer/?pagewanted=all#/Top+News)

<comment><USER24> Or, if you just want to see what's actually on the newsstand, there's [http://app.nytimes.com/](http://app.nytimes.com/)

</comment></comment><comment><USER25> The design is almost skeumorphic in its replication of an actual newspaper. I can understand wanting to do that for branding reasons, the same way Craigslist is successfully branded as anti-design. But the wall of information is just such a bad UX... if they want the site to look like the paper, they should redesign both to have a legible content hierarchy.

</comment><comment><USER26> looks like the FAZ [http://www.faz.net](http://www.faz.net)

<comment><USER27> FAZ is better, easier to go through the homepage.

</comment></comment><comment><USER28> And it's not even responsive.

<comment><USER29> they redirect to mobile.* though

<comment><USER30> So they still hold on to the old train of thought of desktop users and mobile users. Shame really.

<comment><USER31> As a person that currently maintains separate versions for desktop and mobile - it is not shameful. It is just good sense.

You are still constrained with a lot of low power devices on the mobile side and old versions of IE on the desktop side. So it is big PITA to reconcile all of this.

In 5 year they will converge but right now it is too early.

<comment><USER32> The needs of both are the same: simple, readable design. Every time I see a site with these two versions I've found that I preferred one to the other, on both devices - either the desktop version's better even on mobile, or (usually) the mobile version's better even on desktop.

</comment></comment></comment></comment></comment><comment><USER33> The homepage is too wide to fit on a MacBook Air 11" (1368 pixels wide). It's kind of annoying having to scroll a bit horizontally.

The article pages are great.

</comment><comment><USER34> The NYT redesign is a failure, on the public editor column's comments section 21 people liked the new design while over 700 people are complaining: Navigation. layout, fonts and accessibility are all hindering subscribers use of the site.

</comment><comment><USER35> The design for the page that they use to introduce the design seems vastly better than the actual redesign [http://www.nytimes.com/redesign/](http://www.nytimes.com/redesign/)

</comment><comment><USER36> Visiting the site not very often I think I wouldn't have recognized it as a "redesign". Feels more like "some tweaks". Was hoping for some whitespace, the elements are quite cramped together.

</comment><comment><USER37> They removed the Technology link from the main page...

<comment><USER38> Go to Sections -> News -> Technology. Quite a bit hidden.

</comment></comment><comment><USER39> Pretty underwhelming

</comment><comment><USER17> The best thing is having the entire article on a single page. No more clicking through to see the second (or third, or fourth...) part, yay.

</comment><comment><USER40> Seems like they increased the font size, at least slightly? Which would definitely be a positive thing in my opinion.

Anyone have side-by-side screenshots?

<comment><AUTHOR> This page shows older versions of the site in a carousel towards the bottom:

[http://www.nytimes.com/redesign/](http://www.nytimes.com/redesign/)

<comment><USER41> I prefered the 2012 version. The blue titles stood out more and made it easier to scan the articles of the front page in one go

</comment></comment></comment><comment><USER42> I like the new article pages generally, but I might need to write a userstyle to remove the position: fixed on the floating top bar.

<comment><USER43> With Stylish:

       @namespace url(http://www.w3.org/1999/xhtml);

       @-moz-document domain("www.nytimes.com") {
       #masthead {
         position: relative !important;
       }

       }

<comment><USER42> Thanks, saved me the trouble ;-)

</comment></comment></comment><comment><USER43> This is a really good redesign, and I don't want to be negative, but position: fixed should _never_ be used on articles.

</comment><comment><USER44> Why in the world would I want to add a web page to notification center, just by visiting the front page?

That's SUPER obnoxious.

</comment><comment><USER45> Not even attempting to be responsive?

</comment><comment><USER46> mmm... not sure if the redesign is not available in my country, or it's just hardly noticeable

</comment><comment><USER47> The mobile version is fantastic.

</comment><comment><USER48> Not responsive.... why even bother redesigning today with a separate mobile subdomain?

<comment><USER49> Responsive is not always the proper solution.

</comment></comment><comment><USER50> #000000 on all the text is quite aggressive isn't it?

</comment><comment><USER51> Thought I was on the Wall Street Jounal.. similar layouts.

</comment><comment><USER21> The italicized headlines on the homepage look odd.

</comment><comment><USER52> 10 ghostery items and 23 Ads. Nice.

</comment><comment><USER53> Still seems very busy to me.

<comment><USER54> Its a global newspaper. There is an extraordinary amount of information that needs to be shown.

<comment><USER53> Plenty of newspapers cope with this; however, I have to say the individual article pages look great.

</comment></comment></comment><comment><USER55> It's OK. Tech isn't on the home page. Still prefer Quartz.

</comment><comment><USER56> Looks great.</comment>


Sourceforge Attack: Full Report - <AUTHOR> http://sourceforge.net/blog/sourceforge-attack-full-report/

<comment><USER2> Can't you use the direct link <http://sourceforge.net/blog/sourceforge-attack- full-report/> ? Your link adds nothing, not even a slight analyze.

<comment><AUTHOR> It may surprise you, but I didn't know about the direct link. I googled for the sourceforge hack because I was curious about an update on the situation.

This lead me to this site: [http://packetstormsecurity.org/news/view/18549/Sourceforge-H...](http://packetstormsecurity.org/news/view/18549/Sourceforge- Hacked..-Again.html) in which I recognized the blog from the days before. Now looking again I see that it is an iframe hijacked blog by the packetstormsecurity thing, which I missed the first time around. From that blog I found the link I posted, which obviously also was still in the bloody iframe.

So it is just another case of Google not ranking the original content higher than some SEO-optimizer's repost. My apologies :-(</comment></comment>


Show HN: Quepid workbench for tuning Solr and Elasticsearch relevance - <AUTHOR> https://github.com/o19s/quepid <comment><AUTHOR> Original Quepid creator here:

Quepid has been really powerful for helping teams bootstsrap on relevance problems. Often we start with a dozen or so queries, get some ratings, create a bit of success criteria and tune in Quepid. You can do this in a 'sprint' like structure, where the next 'sprint' you tackle the next dozen or so queries, ensure the stuff you fixed before is still working, and make progress on the next set of use cases.

The sweet spot here is teams just getting started on the problem. When a team's maturity increases, they start to (rightly!) ask questions on whether the success criteria initially captured in Quepid is correct, needs to be measured even more scientifically (combining engagement, business rules, human judges, etc).

But the takeaway here is before getting a headache about how hard it is to measure relevance, get started on some intuition, and begin iterating and gaining confidence you CAN make progress. Teams ask us all the time how to start with the training wheels before getting to cosmic-brain level status, and Quepid has been a big part of that!

</comment><comment><USER2> Looking forward to an avalanche of PR's! It's hard to open source something that was internal for so many years, but hopefully we've done it successfully!</comment>


Elm changed my mind about unpopular languages - <AUTHOR> https://blog.realkinetic.com/elm-changed-my-mind-about-unpopular-languages-190a23f4a834 <comment><USER2> My question is, how will he feel about this three years from now? When he is trying to hire someone? Or when the folks behind Elm don't update it as often as they should?

The problem with unpopular languages is twofold:

* lack of talent that can step right in and be effective

* lack of resources to push the language forward

The first can be remediated by planning to bring new hires up to speed, and just making that investment in them. (It can also be a useful filter, making sure you are hiring someone who is really interested to the company and is willing to make the time investment to learn what is probaly not a very portable skill.)

The second is a bigger problem, if the main sponsor of the language moves on. If the main sponsor is committed, then you're probably fine. (I have no idea who pushes Elm forward, looks like there's a foundation from the wikipedia page.)

<comment><USER3> Worth noting that in our experience, hiring has gotten _way_ easier for us since we became an Elm shop. We really struggled to hire React engineers (who have a zillion positions to choose among - why would they pick ours?), whereas there seem to be a lot more great programmers who want to use Elm than there are companies hiring for Elm positions.

Here's a verbatim quote from a cover letter (one I happened to be reading this morning; we see a lot of similar stories):

> Despite my valiant evangelizing of Elm, my company has decided to embrace > React over Elm, so I am looking for opportunities to develop Elm > professionally.

Our Head of Talent said she'd never seen an inbound pipeline as strong as ours, and the #1 reason people cite for wanting to apply is Elm. The "Python Paradox"[0] is real!

[0] [http://www.paulgraham.com/pypar.html](http://www.paulgraham.com/pypar.html)

<comment><USER4> Don't you want people that care about your product instead of the technology behind it? I do. Because there may come a time when another technology is a better fit for your product and ultimately your customer's experiences. Then what? Now your not using elm and your team leaves or is disgruntled. I hire on passion for what we are trying to accomplish, not the technology stack.

<comment><USER5> > Don't you want people that care about your product instead of the technology > behind it? I do.

I would rather have people who care about their craftsmanship and are indifferent about the product than people who care about the product and are indifferent about the craftsmanship. The former ones do a good job regardless of what the product is about.

<comment><USER6> "caring about craftsmanship" != "caring about elm"

I care about craftsmanship even when I'm writing JavaScript.

And when JavaScript is enough of a burden, I go to TypeScript, not Elm.

<comment><USER7> But did you try Elm? Must say it's syntactically much sweeter than TS.

</comment></comment></comment></comment></comment></comment><comment><USER8> Haskell has enormous momentum now[1], and it's speed of development is accelerating. I came to it not because it was cool, but because my experience maintaining and refactoring a big Python program had become really painful. Haskell lets me keep the codebase smaller, it's easier to be pretty sure things are working, it's easier to refactor, and I'm sure the language will only keep getting better. Those are all understatements.

[1] [https://www.haskell.org/communities/05-2017/html/report.html](https://www.haskell.org/communities/05-2017/html/report.html)

<comment><USER9> How much of it was haskell, and how much of it was just working with a statically typed language?

<comment><USER8> I used Java, C and C++ before coming to Python. Unlike theirs, Haskell's type system is complete -- even a function of functions can specify exactly what kinds of functions it uses for inputs and outputs. That makes higher order programming much safer -- and higher-order programming might be the best way to move fast.

Haskell is also astoundingly terse. In Java and C my data type declarations were too long to fit on a page, full of redundancies and boilerplate. In Haskell if you want to make, say, a data type that is either an X or an O (suppose you're writing tic-tac-toe), you could do it in four words: 'data XO = X | O'. (Notice that there's not even a natural way to do that in Java or C, because they don't have sum types; you'd have to make a type that has a flag to indicate whether it is an X or an O. That gets really complicated if they're supposed to have different data associated with it -- but in Haskell, if the X is supposed to carry a float and the O is supposed to carry a string, you just add two more words.)

Pattern matching also helps with terseness. I don't have time even to write the last paragraph so I'll skip this one.

Purity keeps you from tripping up on IO-related errors. It lets you be much more certain that things are working. It also forces you to keep the IO in a thin top-level layer of your program, which might sound like a pain but once it feels natural you'll find yourself moving faster than you could before.

To be sure, Haskell has features that I don't use. But purity, sum types, pattern matching, and the unusually rigorous (it's complete!) type system are all critical to its value to me.

<comment><USER9> That complicated type system w/ type inference does come with it's own costs, usually bad compile speed issues. It's what I've noticed when looking at languages like swift, rust, scala & haskell.

I'm currently dealing with it in a large swift project, and I would much rather go back to the extra verbosity of objective-c than have type inference at this point.

But that was insightful, thank you!

<comment><USER8> Have you noticed slow compiling with Haskell specifically?

<comment><USER9> I've only used swift at that size, but I've heard stories with all of those languages once you have a large code base.

I remember vaguely reading about how at a haskell conference people were basically cornering compiler maintainers about compile speed, but that was several years ago.

<comment><USER8> When I have to recompile, it's usually because I've only modified a few files, and it's usually really fast. I particularly enjoy that if I refactor things without actually making any changes in the way it works, GHC won't blink; it knows there's nothing to do.

My codebase is only a few thousand lines, though.

<comment><USER9> Yeah the codebases I'm talking about are something around 1 million lines over several apps, libraries, all of the tests and codegened models, mocks and network services.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> I don't get it. The author didn't address his original concerns, he just said "Elm is awesome", which may be true, but isn't a rebuttal of his previous points, which are condensed here:

>You can go through the whole development lifecycle of the app and you'll rarely encounter a situation where you can't find a fix online in 5 seconds. Somebody else has already worked out the kinks. My strategy was flawless.

<comment><USER11> I suspect the missing connection is this: if you encounter a conceptual/technical bug with a popular language/framework, you can find a solution online quickly.

If you write buggy code (especially bugs that don't reveal themselves until live in production) it involves much, much more pain to fix those.

Elm helps significantly with the latter.

<comment><USER10> That's one of the points he raised, and I see the value now. However, the author also talks about the dangers that come from using lesser-known, using unstable languages (he mentions finding bugs in the compiler, segfaults, and so on), and he doesn't say how Elm solves them

<comment><USER12> The author does emphasise how complete and well-built the official Elm tools are, which kind of mitigates this concern. But I agree, the article doesn't really spell out its reasoning.

<comment><USER13> > does emphasise how complete and well-built the official Elm tools are

It's not a good point. It's just unrealistic to rely on standard libraries, even if you're writing Scala or Python. Community size _must_ be an important factor, even for Elm. It is highly unlikely that Elm is so perfect, that community size simply becomes irrelevant.

I think we can all agree that this article isn't finished at all.

</comment></comment></comment></comment></comment><comment><USER14> This is common reaction to Elm and especially to Elm.

I also use Elixir and it has great community and everything, but somehow Elm is even more.

All the concerns about 'unpopular' languages, lack of tooling, I feel it is quite the opposite. Elm formatter changed how I work and now I started using it in other languages, Elixir and JS are using it more, or maybe I just started paying more attention.

There are other smaller things that I noticed.

I wish I can work more in Elm, not less.

Also one more thing. Elm made me wish to be way better programmer. You are surrounded by smart people and you just need to show more if you want to keep up.

<comment><USER15> When you say smarter programmer I understand what you mean. But the way I look at it, Elm allows me to relax and be a dumber programmer. I commit my smarts up front to the type design and interfaces between types and then I can relax as the project grows from there because the compiler will enforce the invariants I've encoded into the types. Pure Bliss.

<comment><USER16> Big Design Up Front is back in style now? Agile is dead?

<comment><USER17> The beauty of strong static typing–you don't need to get the types right immediately. Just get an initial design out the door and iterate towards better designs as you go. The compiler helps you tremendously for refactoring, and managed deprecations let you change types gradually over time.

</comment></comment></comment></comment><comment><USER18> Elm is awesome. I just wish much more people and companies would adopt it (and ClojureScript) so it would gain popularity close to that of TypeScript. This could make the web (and the frontend job market) a better place.

<comment><USER19> I agree. I think TypeScript is a decent language, but after working with the DOM in a functional way, verses object-oriented and imperative paradigms, I don't think I'll ever go back. To paraphrase and hijack what the author stated, HTML feels like it was created for Elm (and functional programming in general). I'd add HTTP to that as well. The combination just feels right.

<comment><USER18> Indeed!

</comment></comment></comment><comment><USER20> I'm a Java dev with just some basic experience writing functional code, mostly in Java/Kotlin/Groovy/Ceylon (all of which are primarily imperative!). Can confirm: Elm is awesome, easy to pick up as long as you understand basic things like union types and immutability, and I found myself productive in it within a single day!

<comment><USER21> I notice Scala missing from your list - if you need the JVM or find Elm to not quite have what you need, it's a great language. It's basically the opposite end of the spectrum, design-wise - Elm is "let's create this highly opinionated, carefully curated language and try to make it perfect" and Scala is "let's throw every feature we can derive into our type system and let people work it out".

It's got it's issues (mostly that it's incredibly easy to abuse powerful features), but it also has a ton of stuff I really miss in other languages.

I have a web-based party game (CaH clone) I wrote in Scala for the back-end, Elm for the front-end. It's a bit old (I'm planning a rework and update when the next version of Elm comes out), and it's definitely not the best code ever as it's a hobby project, but you might be interested.

[https://github.com/lattyware/massivedecks](https://github.com/lattyware/massivedecks)

<comment><USER22> Scala's flaw - and Elm's strength - is it is a massive language that allows for a large amount of magic to happen. Elm is by comparison tiny and extremely explicit, and error messages thrown by the compiler are almost always super helpful. But Elm can't (really) be used on the server, so it doesn't hurt to look at Scala there, though be prepared to have a hard time finding experienced engineers to hire.

<comment><USER23> Id argue that while Scala has more powerful features, it has less "magic". Elm can't be used on the server because it has a magical create app function that you must feed the exact right functions into in order to make anything. AFAIK it's not a general purpose language.

<comment><USER22> Definitely not general purpose, but it has nothing asking the line of implicits and implicit type conversion and the such that makes reading Scala code impossible to read, if not write, without a tool like IntelliJ.

<comment><USER24> I find it best to use Scala's implicit stuff for things that would be completely invisible in another language (e.g. "this line might fail with an error" or "this line accesses the database"). That way if you're reading in a plain text editor you're no worse off than you were in, say, Python, but if you use a tool like IntelliJ (and you should!) then the GUI is enhancing your experience, telling you more about your code and reducing the need to click around library code to understand what the code you're reading is doing.

</comment></comment></comment></comment></comment></comment><comment><USER19> There is so much to love about Elm. It is a typed language, so it eliminates typing issues, like 1 + "1" = "11". Its compiler is great. The compiler catches almost everything and offers easy-to-read suggestions to fix your code when there is a problem. Elm's compiler virtually eliminates runtime errors; at least I've never had a runtime error with Elm.

I also like the debugger. It allows you to easily capture your steps as you click around your application, save those steps into a file, and send that file to other developers, which allows them to run through your steps on their own machine; seeing Elm's output at each stage. It works like a "steps to reproduce" bug report, only automated, which makes finding and fixing difficult bugs easy.

There is a lot of good documentation for Elm as well. Elm's documentation itself is good. Manning and Pragmatic Programmers both have good books on Elm (both are still early access versions though). Pragmatic Studio also has an excellent video course on Elm for about $60 ([https://pragmaticstudio.com/courses/elm](https://pragmaticstudio.com/courses/elm)), if you're interested in learning it.

<comment><USER25> > It is a typed language, so it eliminates typing issues, like 1 + "1" = "11".

I mostly agree with your point here, but in this specific example I actually think Perl did the right thing, where

        1 + "1"
        "1" + 1
        1 + 1
        "1" + "1"

are all 2, and

        1 . "1"
        "1" . 1
        "1" . "1"
        1 . 1

are all 11. Letting you specify the _result_ you want by the function you call basically solves that whole problem.

<comment> shaki-dora That's just a "type system by obscurity". Extending it to provide the same sort safety, you'd need specific function for all combinations of types: sum_two_integers(), sum_integer_and_float() etc... Which would be both extremely ugly and a terrible waste of memory.

<comment><USER25> You seem to have missed the whole point of my comment. sum_integer_and_float() is the opposite of what I'm talking about. If you wanted to extend this system within numeric operations, you'd have e.g. divide_and_return_integer() vs divide_and_return_float() (funnily enough, this is also a very popular distinction for languages to draw); sum_and_return_integer() vs sum_and_return_float(); etc.

This usually isn't done because integers and decimals are fundamentally very similar, so for addition there is a platonic correct result when you add an integer and a float (the floating point result), and the operation returns that. Then, if you wanted an int, you can cast your result.

That doesn't work if you want to consider string concatenation to be a form of numeric addition. It isn't. There is no ideal result when adding a string to a number, and if you do one when you meant to do the other, there is no way of producing the data you wanted ("11") from the data you have (2).

Perl doesn't have much of a type system. But it solves the common problem of manipulating strings when you meant to manipulate numbers, or vice versa, by not assigning the same operators to these radically different operations, and I think that was the correct choice, even for languages with stricter type systems.

<comment><USER25> > This usually isn't done because integers and decimals are fundamentally very > similar, so for addition there is a platonic correct result when you add an > integer and a float (the floating point result)

After further consideration, I believe this is incorrect. This usually isn't done because integers are closed under addition, subtraction, and multiplication, so the "promote according to argument type" C behavior doesn't lose accuracy in those cases. There obviously _is_ a platonic correct result when you divide two integers, but it is not in general an integer, so the C behavior introduces bugs (explaining the popularity of divide_and_return_float() -- I don't care what types the arguments were, as long as I get the result I'm looking for).

</comment></comment></comment></comment></comment><comment><USER26> My first thought: The author would probably be equally satisfied if they had used JavaScript with flowtype and react. It sounds like they're comparing JQuery + Bootstrap (and similar "old" frontend frameworks) to Elm.

I think the point still stands that unpopular frameworks/languages can still be stable and more effective than popular frameworks.

<comment><USER27> I can't speak for the author, but I made the transition from JS+React to TypeScript+React to Elm and it _" changed my mind"_ too.

When I started with React/Redux, I didn't know much about functional programming, but I developed a certain interest... A couple years later my React stack was full of tools and libraries that allowed me to write my React apps in a more functional manner. I used TypeScript for the type system, _ImmutbaleJS_ for immutable data structures, _Ramda_ as a FP utility library and _Recompose_ to call React itself in a functional manner. I also used pure stateless components exclusively... Then I switched to Elm and I realized, that the React stack I was working with was a crippled version of Elm. I'm currently writing my first app in Elm and it feels much smoother.

</comment></comment><comment><USER28> I built this in browser database app entirely in ELM. Since there is no existing rich component library available I had to write everything including a high performance grid implementation from scratch. The entire app took about a week and has zero runtime bugs since launch. I have to give credit to Elm for most of that.

[https://bellpluscat.com/](https://bellpluscat.com/)

<comment><USER29> This looks great. Btw why save to google drive instead of google sheets?

</comment></comment><comment><USER30> One of the main problems with unpopular languages (which this article completely ignores) is growing the team, and hiring in general. In other words: the future of your project.

It's not just that it's hard to find people to join you, it's that even engineers who might be considering joining might decide it's not a good career move since they are going to spend years learning a language or a platform that sees no adoption and will not serve their future career.

<comment><USER31> It would be a hiring point for me for someone that became quickly comfortable and productive in a language that was unfamiliar.

</comment></comment><comment><USER32> This piqued my interest in Elm which lead me to start reading the Elm introduction[0] and it's great! I don't know if I'll ever use it in production but these well-written docs sparked the programming interest in me once again. Will definitely write some side project in Elm.

0: [https://guide.elm-lang.org](https://guide.elm-lang.org)

</comment><comment><USER33> I agree with what the author is saying, but Clojure and Clojurescript are the unpopular languages I find valuable.

</comment><comment><USER34> We use(d) Elm at the company I work at. (A start-up.) Elm is great. All of the positive rumors about it are true.

The issue we've had with Elm isn't typically discussed in these conversations: My CTO doesn't seem to see the value of it+. So we recently replaced our Elm code with JavaScript.

I wonder if anyone else finds themselves in a similar situation.

+It's a bit more nuanced. We're in a very "MVP" stage; the line of thinking is to use something everyone's more familiar with so we can move fast.

<comment><USER35> I wouldn't write off an entire company on this abbreviated description, but damn, I'd be worried about this. It does not speak highly of your CTO.

I'm not saying Elm is objectively better than JavaScript (I don't do either). But, can't these things sit side by side. And, if so, how is rewriting code aligned with moving faster? At worst, keep what you have in Elm, and write new code in JS? Also, there's plenty of "ugghh" with JavaScript that I'm skeptical of anyone throwing away existing code in order to rewrite it in javascript.

This is all doubly true for a early-stage MVP, where I'd expect a CTO to be technically minded and enthusiastic. Sounds more like "I know JS so we'll do JS."

<comment><USER34> Perhaps my description of our CTO/situation left out too much detail. (I was trying to be succinct.)

> It does not speak highly of your CTO

Our CTO is the kind to speak highly about. Strong technical/software engineering skills. Willing to experiment with new/different tech. Business minded. He agreed whole-heartedly to move forward with Elm in the first place. This is actually our 2nd project with Elm now.

> Can't these things sit side by side? How is re-writing code aligned with > moving faster?

Yes; in fact, we'd always had a mix of Elm+JS.

Our product is not a Single Page App. (Very deliberate decision.) We're only using JS/Elm to make small parts interactive. So there was only a relatively small amount of Elm code that was replaced.

It allows us to move faster because our designer and a couple of junior devs on the team don't have to struggle through learning Elm.

<comment><USER36> > It allows us to move faster because our designer and a couple of junior devs > on the team don't have to struggle through learning Elm.

Elm-html is my biggest criticism of Elm. Why make the contemplating so difficult for the non-programmers to work with? It's holding back Elm adoption for sure.

</comment></comment></comment></comment><comment><USER37> If you're looking for a language for your own projects then, sure, Elm is a fine choice. When it comes to getting a job as a developer, however, it's a different story. The languages companies are willing to pay big bucks for tend to have been around for a long time. Tech, as a profession, is paradoxically very conservative. Even startups tend to go with Rails and that's been around for over a decade. Ecosystem maturity matters where money is at stake. Today I was offered a £460 per day contract to do Codeigniter for MBNA. Unfortunately it involved relocation. Not even Laravel, just plain old Codeigniter. Who's paying that to write Elm? Personally I love writing Clojure for my own projects but, again, Clojure jobs are thin on the ground even in London so I don't expect to make a career out of it.

</comment><comment><USER38> > First, Elm has the natural predictability of a pure functional language; > when you write Elm, the compiler forces you to consider every case.

I'm a beginner with functional languages, but isn't the type system completely orthogonal to the fact that Elm is a functional language?

<comment><USER26> > > First, Elm has the natural predictability of a pure functional language; > when you write Elm, the compiler forces you to consider every case.

> I'm a beginner with functional languages, but isn't the type system > completely orthogonal to the fact that Elm is a functional language?

Yes. The author probably would be equally satisfied with any robust typed solution (flowtype, typescript). They also say that Elm nicely interfaces with the DOM, which I believe is mitigated by JSX.

So in some sense the article is more about JQuery/Bootstrap/other legacy solutions being bad.

<comment><USER39> > Yes. The author probably would be equally satisfied with any robust typed > solution (flowtype, typescript).

Neither is even remotely as robust — let alone friendly — as Elm's type system.

<comment><USER40> It's not so black and white :)

Robustness, you're absolutely right, Elm cannot be beat. But it comes at a price: It's pretty limiting/underpowered. Typescript is very expressive these days and you can write some very neat libs that _feel_ dynamic but are actually fully typed, if you bother (to be fair, most people don't bother). On the other hand, Elm usually doesn't provide many ways to do something, and you may even have to cheat and offload some work to dirty-old-JS-land via a port to unblock yourself or simply deliver a functionality on time.

I'm still unsure whether the freedom is worth it or whether the robustness wins at the end of the day; it may depends on what kind of app you're writing and how strong the team is (e.g scala has the same "issue")

</comment></comment></comment></comment><comment><USER27> _> You probably can't use it (Elm) on the server side_

Some people mention this as a disadvantage. I think it would be cool to have a decent DSL dedicated to just frontends.

<comment><USER41> If one really wanted to... one could run a browser on the server to run a page powered by Elm, and then click on the page using Selenium style web driver. I'm guessing it wouldn't scale well :)

"What stack are you guys using for the backend?"

"SLEW: Selenium Webkit Elm LocalStoarge"

"Wat..."

</comment></comment><comment><USER42> I wonder how to become a good functional programmer. I think I'm already decent at procedural/OO.

Do I need to have a strong maths background? I didn't learn it very well at university and this worries me. Many functional language fans seem to have degrees in maths.

<comment><USER43> FP is mostly a state of mind - of course picking the language really helps about incentives, but you can do it even in Java/C# (in fact if you do C# there is the great LINQ library that helps).

How to approximate FP in a mostly OOP language:

\- use immutable data structures: there is no way around being able to fearlessly modify something. The naive way is to copy the object before touching it, the better way is to use efficient structures, e.g. Clojure data structures from Java.

\- you either have data classes (no methods, no private fields), or execution classes (no data fields, only static methods), no mixing

\- of you stick to the above, you will find that returning void from a method is very difficult.

Congrats, you're doing FP: the gist of it is that it's all about keeping state explicit; if you pass some A in a function, you will return a B at some point, and that's your result. No implicit state.

Of course, we're missing the whole part about side effects, so to add to the above: if you cannot write a unit test without mocking something in your method, you're doing side effects. They should be done only at the "border" of the application, to (maybe) get you the data you need, so you can bring it and process it in the pure core.

And this is where languages like Haskell help: to understand where the side effects are (because they are included in the types) and to prevent mixing them around (which only gets you an untestable mess in the end).

HTH

<comment><USER44> What a great explanation of the "state of mind" of FP!

</comment></comment></comment><comment><USER39> > But when I joined Real Kinetic, I found out we were writing web client code > in Elm. Elm? Really? The experimental language created for Haskell snobs who > can't handle stooping to the level of a regular blue-collar language like > Javascript?

'bit of an odd thinking considering Evan's aversion to high-minded abstractions.

</comment><comment><USER45> > "I don't want to be the guy that finds a bug in the compiler."

When I'm wearing by "be productive" hat, I don't, either, but how realistic is that? Unless you've memorized the bug database for your compiler, running into a known bug is just as frustrating as discovering a new one, and I'm pretty sure I've run into at least a few bugs in every compiler I've ever used. According to my comments, my current flagship program has workarounds for 5 (known) compiler bugs.

I'd love to use only stable bug-free compilers (maybe Forth?), but I'm not sure that's practical. A more reasonable solution is to only use the popular _parts_ of languages -- though apparently I'm not so great at discerning what those are, either!

<comment><USER9> At least you save a few hours when you look up the known bug

</comment></comment><comment><USER46> Elm is not unpopular: its just not yet common. its popular with people heading to strongly typed FP. GHC-JS

</comment><comment><USER47> > Elm requires that you think through all the edge cases. You must consider > and specify what will happen in every case.

Wouldn't that be the case with _every_ typed and compiled programming languages (or at least, every typed and compiled programming languages that support pattern matching)?

<comment><USER39> Not to the same extent, Elm:

* sum types and exhaustive pattern matching (incidentally, still not the default in GHC in 2018 because reasons[0])

* has only one escape hatch of "Debug.crash", which it strongly recommends not using and which it seems many Elm devs aren't even aware exists (in my avowedly shallow experience)

* and which you use as bottom by hand-rolling pattern matches

* at which point you might as well do it correctly

To the extent that you can require proper handling of everything, I would say that Elm is much stricter than Haskell or OCaml or Rust.

You can be very strict in them, but they don't enforce it to the extent Elm does. At least in my experience.

[0] [https://ghc.haskell.org/trac/ghc/wiki/PatternMatchCheck](https://ghc.haskell.org/trac/ghc/wiki/PatternMatchCheck)

<comment><USER48> GHC will coverage check any case equivalent to one you can write in Elm. You can just write more powerful types where GHC can't tell that your case is exhaustive so it warns about missing branches that won't ever actually be taken. I seem to remember that perfect exhaustive checking for some combination of Haskell extensions is undecidable.

<comment><USER49> Pattern matching on GADTs will get you there, I believe.

<comment><USER50> Its been improved a lot- [https://lirias.kuleuven.be/bitstream/123456789/512439/1/icfp...](https://lirias.kuleuven.be/bitstream/123456789/512439/1/icfp2015.pdf)

</comment></comment></comment></comment></comment><comment><USER13> > Even though Elm is a small language with a small community, that doesn't > affect the Elm experience in a noticeable way.

This conclusion was pulled out of thin air, with no justification from the rest of the article. The title is misleading, the article is really about why the author enjoys Elm over JavaScript...

The general rule of thumb that a larger active community leads to faster software development is more or less still true. There is no reason to suspect this is not the case with Elm.

It's all fun and games until you get hired to build a production-grade web stack in a dinky game-scripting language with no community, that you have written 0 lines of code in. Some people live and breath to reinvent wheels in 19 different languages. Not my cup of tea.

<comment><USER51> > The general rule of thumb that a larger active community leads to faster > software development is more or less still true. There is no reason to > suspect this is not the case with Elm.

Yes, and not only because the volume of copy-paste source code on StackOverflow. I suspect Elm is slower to get a feature out, but once it is out you spend less time fixing bugs in feature A caused by adding feature B silently changing some assumptions you made in code. And so later on in the same project ... you are faster.

> It's all fun and games until you get hired to build a production-grade web > stack in a dinky game-scripting language with no community, that you have > written 0 lines of code in. Some people live and breath to reinvent wheels > in 19 different languages. Not my cup of tea.

From what I have seen Elm is absolutely fit for production grade work. There is a community. The community tends to have smarter on average people in it. Simply because all the less smart people are put off. Sounds elitist? Maybe.

<comment><USER13> > There is a community. The community tends to have smarter on average people > in it. Simply because all the less smart people are put off.

A community shouldn't be judged based on how smart everyone is (quite a difficult measure), a more useful metric would be how many useful community libraries there are. For example, if I can choose between 50 carousels implemented in React vs. 2 in Elm, and I'm an average developer -- what will I choose?

Modern JavaScript undoubtedly towers over Elm in terms of go-to-market time for arbitrary apps.

> you spend less time fixing bugs in feature A caused by adding feature B > silently changing some assumptions you made in code.

This is a big problem with 2007 JavaScript and jQuery. React/Vue and other declarative VDOM frameworks bring the Elm philosophy to the masses.

<comment><USER52> > A community shouldn't be judged based on how smart everyone is (quite a > difficult measure), a more useful metric would be how many useful community > libraries there are

That seems more of a metric for an ecosystem than a community.

<comment><USER13> It's presumptuous to assume "community A is smarter than community B". It's just not even the right question to ask. Better questions to ask are "what are third party libs like?", "how active are people in this community?", "how active is the SO and other forums?". These are actionable questions.

"People who use Elm are smarter" is simply not actionable information. What does it even mean? It's meaningless.

<comment><USER52> > It's presumptuous to assume "community A is smarter than community B".

To assume with no basis, sure; to conclude it may or may not be.

> It's just not even the right question to ask.

It's not inherently operationalized, sure, though (as seen elsewhere in this thread), "advertising jobs for platform A results in us needing to filter out fewer candidates with no real programming ability than when we advertise jobs for platform B" I'd pretty much an operationalization of it, and quite (to address your later point) actionable.

<comment><USER13> You're saying the "simpler" route will attract newer devs and dilute the skill pool.

</comment></comment></comment></comment></comment></comment></comment><comment><USER53> I tried and failed to pick up Elm. I've tried and failed to pick up a few FP programming languages. They tend to become more and more cryptic as I progress with them. I feel dumb, but I'm happy to stick with C like languages, like PHP for web development.

<comment><USER54> You can adopt some practices from fp when writing PHP. For example often instead of iterating over an array and doing some imperative sequence of modifications you can do a sequence of maps, filters and reduce... you replace error prone mutable code with more a declarative approach that says what you are doing clearly.

</comment></comment><comment><USER55> I've played with Elm a while ago and it's been a very nice experience.

I wouldn't use it for any frontend work just because I believe that it's possible to avoid single page apps if possible, but if I had to write a SPA I'd reach for Elm.

The only thing that makes me worried is that Elm 0.18 has been out for quite a while now and most of the development has been carried on behind the scenes by Evan.

This is good because it gives the time to the language to evolve in a coherent way instead of being a collection of bolted on features, but it also means that for outsiders is a bit hard to track progress in the language

</comment><comment><USER56> > choose the one more people were using

After reading this article and reflecting on my own experiences and habits, my rule of thumb would be "choose the best of those with second-tier popularity." It's common that the most popular isn't the best, has advantages in numbers, but also disadvantages like low S/N ratio.

Many of the pitfalls of a scarcity are avoided, and can sometimes find a well- organized, curated, cultured pocket of enlightenment.

</comment><comment><USER57> Programmers who believe just one stack is the right way to do things aren't probably the best hires long term.

While Tech evolves, being able to work with what exists and the future remains incredibly valuable.

</comment><comment><USER58> I see that the current version is 0.18. Curious if the language has become more stable with fewer breaking changes than when I looked at it two years ago.

<comment><USER59> It actually has... due to not having any major release in 2 years.

<comment><USER16> So it's abandoned?

<comment><USER60> No. It is still being actively developed: [https://github.com/elm- lang/core/commits/master](https://github.com/elm-lang/core/commits/master) / [https://github.com/elm-lang/elm- compiler/commits/master](https://github.com/elm-lang/elm- compiler/commits/master)

But it's been 14 months since the latest full release.

</comment></comment></comment></comment><comment><USER61> Can rewrite the example from the post:

      uniqueAuthors =
                  books
                      |> List.map .authors
                      |> List.concat
                      |> Set.fromList
                      |> Set.size

as

      uniqueAuthors =
                  books
                      |> List.concatMap .authors
                      |> Set.fromList
                      |> Set.size

</comment><comment><USER17> Is it true that Elm is going to remove custom operators in the next release?

</comment><comment><USER62> Yep, we are on ELM

</comment><comment><USER63> I feel unpopular languages are best relegated for niche use cases the language is well suited for. If you are going to build something mundane like a CRUD App or a game, or an ERP, why wouldn't you just use some mundane blue-collar language like Javascript or its equivalent?

What you are doing isn't new or groundbreaking, so why bother bringing in extra drama and ceremony by using a language very few people use to achieve the same result? Just seems like added complexity for no reason, even if the code looks simple with the first pass.

<comment><USER64> I find this line of reasoning a bit strange. I've only dabbled a bit with some unpopular languages, but I don't think their limited popularity implies they're only suitable for niche use cases. In fact after using some languages (most recently Clojure) I find programming in other mundane languages like JS a huge step backwards.

People are probably the biggest determining factor in achieving a quality result. But I don't think that means we should forget about trying to improve our tools.

<comment><USER63> It's not just about the language itself.

You might think Japanese is an awesome language and decide to learn it, but then what use is speaking Japanese outside of Japan? Around the world people still just use boring ol' English, even though English is actually a pretty shitty language and full of hacks to make up for weird edge cases (read and read, goose and geese, mice and meese?, Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo)

Likewise, if you write something in Clojure, you have far less people and libraries and platforms that can help you accomplish whatever you are doing. If what you are doing is not something new or groundbreaking that could only be done well with Clojure, then the extra effort you have to spend to get up and running is not worth it.

<comment><USER65> I have thought about this problem some and currently see it as an issue of scaling thresholds.

If it's literally just you, there's a lot of benefit to leveraging existing work so that you can focus on the differentiating part of the project(which is probably not a language innovation). It's not just the libraries but the whole ecosystem - example code, troubleshooting help, IDE support.

If you have an engineering team of even modest size, the picture can change very swiftly towards ensuring your result is built on a solid foundation, even if it means a lot of pioneering infrastructure has to be built and a lot of late nights spent debugging core toolchain issues. Team efforts have the necessary momentum to break free and do that ground work as the overhead gets swiftly absorbed in "person-year" budgetary terms. Individuals can only really justify the same as their core direction of research, sole hobby, or speculative investment - e.g. being the "first to implement" some hot new standard could be a well incentivized career move.

</comment></comment></comment></comment><comment><USER66> >I made it a hard and fast rule: if I found two technologies that could solve a problem, I would choose the one more people were using. I didn't want to include an obscure graphics API and then discover that no one had ever called set_color() followed by resize_window() (resizing is hard) and somehow those two functions in sequence cause a segfault. I don't want to be the guy that finds a bug in the compiler. I just need to ship the product.

Then he links to issues for Qt and Go. They're certainly not obscure. What kind of weird argument is this? If anything, the argument there is that it doesn't matter how popular something is, as even extremely popular things like Qt and Go will still have bugs.

</comment><comment><USER67> Nowadays it's really easy enough to use real Haskell in the browser with GHCJS, and FRP libraries like Reflex provide a much more complete experience than Elm's restricted form.

</comment><comment><USER68> I used to use Elm, then I moved to Pine, then Mutt (which is still going strong)

I guess there's only so many names in the world, and they're bound to be reused.

<comment><USER69> This is why I'll never be a web developer. "Let's drop names! I made bridges out of Wood.io, then I used Steel (TM), now I use Stone.js. What's fun, now there's data in the kiddie pool!"

It feels like watching a cult of optimization function in a culture where _measurement_ is taboo. It's absurd beyond belief.

<comment><USER70> That's fine. I don't think the ecosystem needs any more people that get their blood pumping over some inconsequential name reuse.

To get Elm confused with the email client with this title, you'd have to not know the Elm language existed. So it seems like it's a moment to go "oh I see, that exists" than cursing the world because you thought "Elm changed my mind about unpopular languages" somehow referred to an email client.

But I get it. It's cathartic to be angry on the internet. The angry shadow boxing just gets pretty old for the rest of us no matter what kind of developer you are.

<comment><USER69> I'm talking about the _uselessness_ of saying "I used X, now I use Y." WHY does one change what one uses? For reasons supposedly. But of course nobody ever provides _reasons_. It is enough to simply drop names. Print out your resume. Because heaven forbid anybody provide some real data that shows why one platform is better than another.

I'm certainly not confused about what Elm _is_. That'd be easy enough to find out. But "why you stopped using it" sure as shit isn't something I can google.</comment></comment></comment></comment>


Improving Mental Healthcare WithAI - <AUTHOR> https://techbio.org/b-tracing-psych-signals-lit.php <comment><AUTHOR> Patterns to be discovered will become readily apparent, and hopefully help many of those less fortunate souls to become whole again.</comment>


iPhone storage can be dramatically increased by trying to rent an iTunes film - <AUTHOR> http://www.independent.co.uk/life-style/gadgets-and-tech/news/iphone-storage-space-increase-low-rent-film-trick-how-to-a6963856.html <comment><USER2> This works. Attempting to rent or purchase the largest movie you can find (from the itunes store) using a device that has less free space than the size of said movie will result in the freeing up of a significant amount of space without any noticeable negative issues. I have done this many times in the past. I am currently on a jailbroken ipad Air still running 8.4, but I dont think the jailbreak, nor the ios version affect this. Also, I had success when attempting to purchase as opposed to renting the movie. I have never been charged for the movie and I always see significant free space afterward. Several of the comments on the link page mention they were charged for the movie. I was not.

</comment><comment><USER3> Would it kill them to add a button in settings. This is very useful.

</comment><comment><USER4> Because the ability to clear their own caches would be just too much power and control for those poor innocent Appleheads to handle.

iOS has to be the most intentionally restrictive general-purpose OS in use today.</comment>


Android App Inventor Open Sourced, Code Released - <AUTHOR> http://www.hackeducation.com/2012/01/20/android-app-inventor-open-sourced-code-released/

<comment><USER2> Man, if I had the spare cycles to do it, I would love to build this as a browser based service that just calls a (cloud) back end compiler and produces output files. Ajax UI design plus templates would seem like an ideal basis to build trivial apps, and maybe a Chrome plugin or native code conduit to let you talk to the connected USB device and walk you through configuration thereof.

Configuring Android development on the desktop is not terribly complicated, but it's a high bar for new adoption as compared to "install and launch Dreamweaver".

I guess that's sort of the market for Titanium Appcelerator, but that's still a beast by comparison to "this should all be doable in a browser environment". But I don't delude myself that this would be a small project :)

</comment><comment><USER3> You will need to have Java, Ant and the App Engine SDK installed on your machine. :\</comment>


Glitch: Home Office tells man, 101, his parents must confirm ID - <AUTHOR> https://www.theguardian.com/uk-news/2020/feb/12/home-office-tells-man-101-his-parents-must-confirm-id <comment><USER2> TLDR: the system misinterpreted his birth year as 2019 instead of 1919

<comment><USER3> Unfortunately, the ICAO Machine Readable Travel Document standard requires a two-digit year in the Machine Readable Zone. (Not sure what the "biometric" chip's data contains though, for all I know that has the full four digits.)</comment></comment>