CSS Zen Garden - <AUTHOR> http://www.csszengarden.com/ <comment><USER2> I always thought this was funny. This was the embodiment of the original CSS philosophy, which was to "label your html elements semantically with what they ARE, and then worry about styling those in the CSS." The whole point was to get anything style related out of the HTML altogether, the HTML would just be semantic/content related.

But then Bootstrap and other CSS libraries came out, and completely inverted the philosophy back to what HTML originally looked like pre-CSS, which is that you had all of these rules you could place directly in the HTML that would directly control how the element was styled. In CSS Zen era you could look at my HTML and have no idea how I intended it to LOOK, whereas in the Bootstrap era you would look at my HTML and see "row" and "col-sm-3" and know exactly what I was going for visually.

Now people just make components and will maybe use style variables/tokens. Just funny how things change.

<comment><USER3> I've seen people seriously recommend marking up your document like this:

How in the nine fires of hell is that better than just using a table?

<comment><USER4> Because assistive technologies (like screen readers) won't interpret it as a table, but the browser will, giving you the ease of table-based layouts without the accessibility hang-ups.

<comment><USER5> The right way to fix that would have been to add a simple annotation that the purpose of the table was for styling, not semantics, something like:

<comment><USER6> Why do you consider that better? If I understand your suggestion "type=for- display-only" would semantically turn the
 into a
. Why not just use a div in the first place?

<comment><USER5> Because it's DRY. With the top-level annotation, the rest of the table spec remains unchanged, so if you change your mind and decide that you really want a display table to be a semantic one or vice-versa you only have to change on thing whereas if you used DIVs you now have to change not only the top level but also every row and cell.

<comment><USER6> You don't decide on a lark if you want some content to have table semantics or not! Tags are selected to indicate the semantics of the content. Content don't change semantics unless you rewrite it to actually be something different.

In any case, you might just as well decide the table was a list item or headline then, right? So you would need

...

<comment><USER5> So two things...

First, one of the reasons HTML has been as successful and widespread as it has been is that mere mortals are able to use it, not just trained software engineers and designers. Mere mortals may not make such decisions on a lark, but they might make the decision incorrectly and have to go back and change it for that reason. Why make more work for yourself than necessary?

Second, making changes is not the only reason to make code DRY. Re-using TR and TD tags is analogous to operator overloading. If you want to add two numbers you want to be able to write x+y and have the compiler figure out whether that means an integer add, a floating point add, etc. You don't want to have to write (say) x II+ y if you want to add two integers, x FF+ y to add two floats, x LL+ y to add two longs, etc. It's the same for table rows and cells. The mental distance between tables-for-layout and tables-for-structure is smaller than the mental distance between integers and floats. It's just annoying to have to keep telling the computer over and over and over again "this is for layout" or "this is for structure" particularly in a case where the number of repetitions can be very, very large. There is no value add in forcing someone to do substantially more typing when the thing being typed contains no additional information that the system does not already have.

<comment><USER6> > It's just annoying to have to keep telling the computer over and over and > over again "this is for layout" or "this is for structure" particularly in a > case where the number of repetitions can be very, very large.

I have a hard time understanding this scenario. What kind of content are you working with?

<comment><USER5> What difference does that make?

<comment><USER6> I'm trying to understand the scenario you describe in the context of HTML.

<comment><USER5> If I am inside the context of a
 tag and I want to create a new row then the only kind of row I can create is a
. It makes no sense to put a
 inside a
 so requiring the programmer to specify
 rather than just
 or
 is making her do a lot of extra typing for no value add. A
 inside a
 is necessarily a
 and a
 inside a
 is necessarily a
 just as a + operator operating on two integer values is an integer addition and a + operator operating on two floats is a floating point addition. There is no need to force the programmer to do extra typing to specify what is meant by + in a particular context. Likewise there is no need to force the programmer to do extra typing (or thinking) to specify what
 means inside a particular context.

<comment><USER6> But...you _do_ only need to type
. The problem you describe only becomes an issue if you use
s for layout in the first place, so just don't do that. If you want to display something (which isn't semantically a table) in a grid-like layout, you use display:table or display:grid in CSS, you don't change the markup. And vice-versa if you have
 which you _don 't_ want to display in rows and columns, you can override the default presentation in CSS without changing the markup.

The hypothetical
 element is just not needed in any scenario. It would have been useful back in the day before IE supported display:table, but that is at least a decade ago.

<comment><USER5> > The problem you describe only becomes an issue if you use
s for > layout in the first place, so just don't do that.

I could just as easily say that the "problem of overloaded operators" only becomes a problem if you try to use + to add anything other than two ints. So don't do that.

But OK, assuming I accept the premise, what should I do instead? The CSS community has been dithering about the answer for years. Only very recently has there been anything even remotely approaching an acceptable solution i.e. a solution that actually reproduces table layouts without having to pile on a ton of hacks. In the intervening years, a lot of legacy code was produced that used
 for layout because it was the only thing that actually worked.

There also the fact that <display-table>
 or something like that just looks a lot cleaner and is easier to read than

. When you make complex table layout you end up with a lot of TR and TD tags, so it makes sense to keep those short to avoid cluttering things up.

<comment><USER6> If you genuinely want a layout exactly like a html table you use display:table. You probably don't, but it is there if you want.

You don't really need repeated class=table-row-for-display etc, this can be achieved by CSS contextual selectors.

But in reality html tables was not designed as an all-round layout tool in the first place and the layout algorithm was never specified in detail. Flexbox and flexgrid are typically more appropriate and powerful as layout tools.

<comment><USER5> > display:table

I tried that once many years ago. It didn't work. It might work today but I no longer care.

> this can be achieved by CSS contextual selectors

That would be true if display:table worked, but it doesn't (or at least it didn't) and so it doesn't.

And you still need some markup for the contextual selectors to work on. The obvious choice is

, or, if it existed, <display-table>
. _Maybe_ <grid><gr><gd> but that's not going to happen.

<comment><USER6> > That would be true if display:table worked, but it doesn't (or at least it > didn't) and so it doesn't.

Can you describe the problem you are having?

<comment><USER5> No. That last time I tried it was many years ago. Maybe it works now. I neither know nor care.

<comment><USER6> So you are basically just trolling at this point.

<comment><USER5> No, I'm giving you honest answers to your questions. Just because I have not gone back to explore a broken feature to see if it is no longer broken doesn't make me a troll.

But my point stands even if display:table works nowadays. The problem is not _what_ you have to type in order to specify that some piece of markup should be displayed as a table even though it is not semantically a table. What matters is _how much_ you have to type, and whether you have to redundantly specify that a table is for display only on every row and cell. To use display:table you also have to specify display:table-row and display:table- cell, and you have to do it again and again and again and again even though all this information is redundant and only needs to be specified once at the top level. There is absolutely no rational justification for this. It would be as if you had to specify the type of a variable in C not just when it was declared, but again every single time you referenced it.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> This approach is extremely seductive because on the surface it sounds so "pure" and "clean" but the reality is that on large projects it leads to some of the most horrific, hard to maintain CSS you'll ever see, no matter how hard you try to keep things in good shape. CSS is just inherently more difficult to maintain than HTML, and choosing a workflow that encourages editing CSS instead of HTML just makes things harder and harder over time.

Choosing an approach where CSS is treated like a third-party dependency that is _consumed_ by your HTML ends up being much more practical, maintainable, and scalable because editing and maintaining HTML is _easy_ — every time you change a class on an HTML element your changes are local and predictable.

Always thought this article by Nicolas Gallagher did the best job arguing this point:

[http://nicolasgallagher.com/about-html-semantics-front- end-a...](http://nicolasgallagher.com/about-html-semantics-front-end- architecture/)

<comment> andre-lima But can you do what CSS Zen Garden does only by changing HTML? If you can't, it means you failed at separating concerns.

Additionally, applications that you need to customize/theme usually makes it hard for us to edit the HTML. The only option is to edit the CSS. In this case, you whole argument breaks down.

p.s.: In your case, I believe Tailwind should be pushing more for the use of @apply, instead of making those god-awful markups :(

<comment><USER7> > But can you do what CSS Zen Garden does only by changing HTML?

Yes of course you can, if you can change the HTML you can build an entirely different website, and you don't have to change the CSS at all because with something like Tailwind it's a "universal stylesheet".

<comment> andre-lima You'd still need to write some custom CSS depending on the design you want to achieve, though. So, you're finally not only changing just the HTML.

<comment><USER7> Not true at all. You can build two sites that look completely different without changing the CSS at all if the API of the CSS framework is low level enough, like Tailwind, Tachyons, etc.

</comment></comment></comment></comment></comment><comment><USER8> I recently brought this up with my team. As an "old-school" web developer, I buy in to the whole CSS as design thing, while the front-end engineers @ work switched to using styled react components. As we look to make substantive design changes, now we have multiple places to make the CSS changes, only now it's the SASS project and all of the React components / projects. I must be missing something about how hip and cool styled components are, but they'll never be as cool as the CSS Zen Garden :)

<comment><USER9> I also started coding when CSS Zen Garden was the best thing ever but sorry, CSS in JS is better.

With classes and a separate stylesheets, there are no statically analyzable connections between them. You typo a class name? Too bad. You're no longer using that class anywhere? No compiler will tell you it's dead code. You want to increase the padding in this one place? There's no way to be confident what else it will affect.

And all the "benefits" that stylesheets tout are also offered by components. No one is adding  tags on all on all of their headings. With components, you just set the font once on the heading component.

<comment><USER10> > No one is adding  tags on all on all of their headings.

Ok? I'm not sure the official documentation is encouraging factoring out things like font styles to a central place, so you for example easily change the look from serif to sans, or adopt a signature font?

Am I missing something?

[https://reactnative.dev/docs/text](https://reactnative.dev/docs/text)

<comment><USER9> The original argument for CSS from 20 years ago was:

Instead of saying: `<font size="20"><b>Some heading</b></font>` 100 times, CSS proponents would tell you to just write `<h2>Some heading</h2>` 100 times with styles defined separately as `h2 { font-size: 20pt; font-weight: bold; }` so if you need to change it to 22pt, you can make one change instead of 100.

Components give the same benefit. Just write `<Heading>Some Heading</Heading>` 100 times with the definition `function Heading(props) { return <h2 style={{fontSize: 20pt; fontWeight: bold}}>{props.children}</h2>; }`. If you need to update it to 22pt, it's still just one change; not 100.

* replace `style=` syntax with your CSS-in-JS framework of choice for better performance.

<comment><USER10> Right, but in the example linked from the official docs, the css/style is in the component. So you need to change all your comp, rather than the body font style?

(obviously you can mix and match, it just seems that the official documentation/sentiment is towards self contained components that don't support page/application level theming/styling)

<comment><USER9> You're subscribing to the notion that it's _good_ to put all your styles for all components in one file. Since the invention of variables, that is wrong.

Theming is no longer a valid argument for centralized style sheets. If you declare one central set of variables for, eg., colours or fonts, then you can still do "application level theming" (changing those colours/fonts in one place), without having to mash all the styles for every element in the entire app together in one file.

The advantage of using JS variables to represent this is you can easily ask your IDE to "find all references" to that variable. It's much easier for humans than reasoning about CSS inheritance and the cascade.

</comment></comment></comment></comment></comment></comment><comment><USER11> CSS Zen Garden was a treasure back in the day, one of the most inspirational CSS sites showing the power and flexibility that can be achieved with CSS over semantic HTML.

I still remember the original design from Dave Shea fondly:

[http://www.csszengarden.com/001/](http://www.csszengarden.com/001/)

<comment><USER12> One of my quixotic personal projects was reproducing this design for my Myspace profile.

Ha, I found the blog I was keeping:

[http://myspacecivilized.blogspot.com/2006/09/css-moshi- garde...](http://myspacecivilized.blogspot.com/2006/09/css-moshi-garden.html)

It includes a small screenshot.

</comment></comment><comment><USER13> I remember this blowing my
-addled brain in 2003. This site was what convinced me to really dig into CSS, and not just use a few inline styles as hacks. This also opened my mind to JavaScript at the same time (as I looked into "DHTML"). It was a pretty different web back then!

<comment><USER14> I'm amused at how I glanced at your comment and my mind sort of yelled "hey, that opening tag never gets closed! that's going to invalidate everyone else's comments below by making them part of that element!".

Maybe I'll say
 here just in case. :-)

</comment></comment><comment><USER15> I cannot believe it's been 15 years, literally half my life, since I got my design accepted at CSSZenGarden: [http://www.csszengarden.com/185/](http://www.csszengarden.com/185/)

Incredible, I had never thought of how long it's been...

<comment><USER16> I remember seeing your design back around 2009 when I was taking my first web "publishing" courses! What a trip down memory lane

</comment></comment><comment><USER17> [http://mailmarkup.org/zen/](http://mailmarkup.org/zen/)

This is my Zen Garden attempt. According to the HTTP headers it is from 20 October 2008.

You can see how font rendering has changed over the years. When I wrote this all columns were the same height and alignment cross browser.

<comment><USER18> It looks great. Nice job. I miss the web from this era. Sites looked so much more unique. People posted to their own sites and syndicated content. Feed readers were useful. Sigh.

</comment></comment><comment><USER19> Wow, what a blast from the past!! This was a great source of inspiration back in the day.

If you're not familiar with the project, I suggest checking out the Wikipedia article:

[https://en.wikipedia.org/wiki/CSS_Zen_Garden](https://en.wikipedia.org/wiki/CSS_Zen_Garden)

</comment><comment><USER20> Ah so many memories. This was my favorite:

[http://www.csszengarden.com/099/](http://www.csszengarden.com/099/)

Dave Shea mentioned that it was no longer relevant back in 2013.

[https://www.awwwards.com/why-the-web-doesn-t-need-another- cs...](https://www.awwwards.com/why-the-web-doesn-t-need-another-css-zen- garden.html)

<comment><USER21> "This video is unavailable."

</comment></comment><comment><USER22> Some time ago I made [https://github.com/fiatjaf/classless](https://github.com/fiatjaf/classless), a framework for making themes for simple websites (like blogs) using the same basic HTML structure.

The idea is: you write HTML that conforms to the structure, then you can reuse any of the themes by just including a CSS file (and sometimes a JS file) in your .

Turns out I wasn't the best person indicated to push this, as my design skills weren't marvelous, but I still think it was a good idea. There are 17 themes available, mostly ported from other places. A playground where you can see the themes (and test your own, if you are feeling like building one) is available at [https://classless.alhur.es/](https://classless.alhur.es/)

</comment><comment><USER23> I wrote my blog's HTML[0] semantically, and I'm glad I did. I have a different style when someone fires up a new instance. I was already going for a retro "vaporwave" aesthetic there, and that recent Windows 93 post[2] pushed me over the edge. I apply those styles to my main site as an Easter egg when you view it in the Japanese locale.[1]

[0] [https://theandrewbailey.com/](https://theandrewbailey.com/)

[1] [https://theandrewbailey.com/?lang=ja](https://theandrewbailey.com/?lang=ja)

[2] [https://news.ycombinator.com/item?id=22463415](https://news.ycombinator.com/item?id=22463415)

<comment><USER24> Semantic HTML also happens to work quite well on even the most anemic browsers! I am somewhat proud that a non-HTTPS version of my website (which is designed for modern browsers) is navigable and fairly usable on the original WorldWideWeb, aside from some of the  content poking through.

</comment></comment><comment><USER25> Dave Shea (CSS Zen Garden), Eric Meyer, Jeffrey Zeldman (A List Apart), Jeremy Keith (DOM Scripting), and others who escape me provided the foundation for the CS classes I taught 15 years ago. Thanks guys!

</comment><comment><USER26> Honestly, these designs are so refreshing. There is no place for ads. No popups asking to subscribe to their newsletter. No breaking because I have Javascript disabled.

Looking through some of the designs made me happy... and a bit nostalgic. :)

</comment><comment><USER27> Good memories from 10 years ago (the site looks practically unchanged since then). Incredibly how the frontend nonsense of recent years allowed us to go backward. Same result but slower and more complex without any good reason.

</comment><comment> andre-lima I truly believe this is still the way to go if you want to have any hopes of keeping your HTML/CSS maintainable and easily customizable.

</comment><comment><USER28> Seeing this page brings back memories: [http://www.csszengarden.com/001/](http://www.csszengarden.com/001/)

I'm happy that this is still online.

</comment><comment><USER29> Separation of html and css can still be a useful paradigm and does not have to be incompatible with separating your code into components.

For medium-sized projects, I have found it useful to have general (or "base" and "cosmetic" a la MCSS) styling in a central place with all my variables. For my components, I strive to balance the "structure-" and "container-" -like (similar to OOCS) styling they need while not trying to make them so general that they are over-engineered. To that end, I am comfortable enough using the central variables within my components and even some central classes, recognizing that when I do want to re-use my components across projects there is occasionally ad-hoc refactoring/customization.

Also, Css in JS is only one way of building components. You can keep your component-specific css separate from the rest without using JS.

</comment><comment><USER30> Cool. XML, by way of HTML was always designed to be layered. As in, a layer for a different use case. At the lowest layer, is the data. Each layer used to decorate the layer below it enables using it for different use cases. CSS is just another decoration to create another layer used for another use case (styling the data for the rendering in a browser use case). While keeping the underlying data still usable for a totally different use case. CSS Zen Garden is such a fantastic showcase of that layering architecture of HTML.

Regarding Javascript applications, I consider it just another case where we're using the design of the web for something it's inventors could never foresee. Well, they did foresee "apps", but I'm just not sure React, Angular, Ember, etc. apps was what they were imagining.

</comment><comment><USER31> I see a lot of people bickering here in the comments about what's better and why, but does it really matter? I mean I don't care if you like to wear rain boots when it's sunny or flip flops when it's raining, as long as you have some footwear on.

There's many ways a webpage could be programmed/designed/developed/styled but the only thing that really matters is that it's usable and visible to the end- user. No programmer likes every other programmers code when they have to work with it and we all know there's ten different ways to solve the same problem so just let people do it the way they know how as long as you can use/view it with no major issues who cares.

</comment><comment><USER32> I use to own this physical book!!! .. years and years ago (I think around 2008 or 2009). I cite it as my inspiration for a lot of my early designs:

[https://battlepenguin.com/tech/a-history-of-personal-and- pro...](https://battlepenguin.com/tech/a-history-of-personal-and-professional- websites/)

It might seem dated, but the ideas of using images and flowing layout shaped that era, and the simplicity can still be applied today (although we can make it look a lot better and cleaner thanks to CSS grid, flexboxes and other new tech that's now available in most browsers).

There's a lot of good nostalgia here if you go through their older designs.

</comment><comment><USER33> I really like CSS Zen Garden and it had a profound impact of how I think about front-end work. I see a lot of back-end developers trying to force the markup and their styling to conform to what they want.

If you understand how the document flows, separate your CSS from your markup, write clean and valid markup and keep everything as minimal as possible. There is really a "zen" like element to it which I think is kinda lost today.

However when it comes to code I am a minimalist and tend to do as much as possible with Vanilla JS.

</comment><comment><USER34> Encoding page layout in text is a bad idea, and CSS is a bad implementation of that idea.

What could be better, you ask? Open up Google Slides. You can make a slide that looks the way you want it. The learning curve is nonexistent. Then you can share it online and it will look okay to anyone on any size screen. There's no reason why building websites should be a hundred times harder than that.

<comment><USER35> This does not come close to the Web's design goals.

</comment></comment><comment><USER36> I was a huge fan of the CSS Zen Garden, and was so excited to have my submission accepted back in 2006 (#106!) when I was first starting out.

Generally, it was a great demonstration of CSS at a time when CSS was rather novel, and the "separation of content and presentation" sticks with me today, and forms a good foundation for things like built-once responsive web design.

For me personally, I met a lot of interesting people through CSSZG, including Bill Zeller (RIP[1]) and others.

[1] [https://news.ycombinator.com/item?id=2074109](https://news.ycombinator.com/item?id=2074109)

</comment><comment><USER37> Still love the retro theater design - so fun: [http://www.csszengarden.com/202/](http://www.csszengarden.com/202/)

</comment><comment><USER38> Would be nice if the designs would display the date when they were created.

Digging around in the source code and on the sites of the designers, it seems they have stopped adding entries around 2013.

I wonder why.

</comment><comment><USER39> Related from 2013: [https://news.ycombinator.com/item?id=6076163](https://news.ycombinator.com/item?id=6076163)

[https://news.ycombinator.com/item?id=5669601](https://news.ycombinator.com/item?id=5669601)

A bit from 2009: [https://news.ycombinator.com/item?id=811468](https://news.ycombinator.com/item?id=811468)

</comment><comment><USER40> From Dave's current site:

[http://daveshea.com/projects/zen/](http://daveshea.com/projects/zen/)

</comment><comment><USER41> Hehe, I remember impressing my Web Development Professor 11-12 years ago by using CSS designs based off this website.

I am still impressed by the beauty of some of the designs.

</comment><comment><USER42> My immediate response, as someone who does not know css that well and is trying to learn, is to open developer tools, choose responsive design mode and then iPhone 6. Only looking at the top four, none of these are that great. Where is a way to navigate? They don't seem to be using vw which I expected. Are there good examples that work well with responsive, provide navigation and don't use horizontal scrolling.

<comment><USER43> The site predates smartphones by maybe five years. Mobile friendly wasn't a thing yet.

</comment></comment><comment><USER44> I enjoyed browsing CSS Zen Garden and read Eric Meyer's CSS articles when I was still in school 15 years ago. Time flies and so as Front-end stack.

</comment><comment><USER45> oh nice to see this on the web again! i recently remade this with modern web technologies - Svelte, Monaco, and serverless functions to pull things from GitHub Gists: [https://github.com/sw-yx/svelte-zen- garden](https://github.com/sw-yx/svelte-zen-garden)

</comment><comment><USER46> I love this site. I used this site back then to learn all about HTML and CSS and the fact that it still works with those age-old designs is a testament to the original CSS philosophy.

</comment><comment><USER47> I love this site and visit from time to time. It reminds me of a time when you thought of web design as art. Now it feels like playing with building blocks.

</comment><comment><USER48> I've always enjoyed this site. I see that they post updates here fairly regularly.

</comment><comment><USER49> All those who repainted their pages in dark mode should take lessons from "Steel".

Not all fonts are readable when displayed white-on-black, and some seem to forget about that.

Also this is something that's being slowly undone by ideas like Styled Components and Tailwind. My take is that those two are a step back.

</comment><comment><USER50> The zenist of css designs for this web page is:

body { max-width: 800px; }

Done. Now go do nothing.

</comment><comment><USER51> this era broke me as a web designer. Dom walking etc. i need to get back into current trends so this discussion is useful.

</comment><comment><USER52> A story like this being at the top of HN is how we know covid-19 is serious.

</comment><comment><USER53> aaaahhh good old and amazing CSS Zen Garden!!!

</comment><comment><USER54> Why is this the top post of the front page? Is there a front-end dev that didn't see this when they were 15? Sure it's a nice demonstration of CSS but...

<comment><USER55> This gets posted every few months and the HN crowd loves it. Somehow all the technical geniuses here are still mesmerized by CSS from 20 years ago. Learning all the nuances of the Rust borrow checker doesn't leave any room for much else, except for HTML tables, that stuff got embedded too deep. Set a reminder, it's an easy way to reap the sweet karma.

<comment><USER54> Well said. I just wish the Zen Garden would put a big banner at the top that says "the cascade turned out to be a terrible idea, now all CSS is JS, and it's scoped to the component using exclusively single-class-selectors with non-deterministic names."

I see quaint selectors like `#main aside .wrapper .design-selection` and just hope jr devs aren't trying to emulate them.</comment></comment></comment>


Beware, iPhone Users: Fake Retail Apps Are Surging Before Holidays - <AUTHOR> http://www.nytimes.com/2016/11/07/technology/more-iphone-fake-retail-apps-before-holidays.html <comment><USER2> Funny, Apple made a fuss earlier this year that they were cracking down on "My First App" type applications, but they let shoddy, fraudulent, poorly translated applications through no problem...

<comment><USER3> There are entire classes of applications that solve real problems that people have. They are aimed at adults, which means they might show a bit of nudity. Those applications are absolutely disallowed by the Apple nanny.

It pisses me off to no end that you can't build those applications, but this stuff isn't caught by their filter.

<comment><USER4> Please, how much legit productivity software comes bundled with "a bit of nudity"

<comment><USER5> There are a whole class of applications that solve REAL problems that require "a bit of nudity" that Apple disallows.

<comment><USER6> Mind giving us examples?

<comment><USER7> Medical related apps for one.

<comment><USER4> Thought they existed in the App Store. Either way, I'm still perplexed at what "real problems" would be solved.

<comment><USER7> Anatomy-learning apps. Medical diagnosis apps. Just because _you_ can't think of a legit reason to use something doesn't mean it doesn't exist.

<comment><USER4> My point is these apps exist already, in the App Store...

<comment><USER7> Do they? Apparently I need iTunes to browse the app-store, so I can't check. If so, then how do they get around the ban?

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><AUTHOR> Having dealt with the iOS approval process several times, it is interesting to see that the system has this weak spot. The approval process is known for its stringency (especially compared to the Play Store), but clearly there are some vulnerabilities lurking.

<comment><USER8> Well, there is an element of confirmation bias. We don't know whether the successful apps represent one-hundredth or two-thirds of the submitted apps. But earlier this year Apple did say it was trying to decrease approval times,[1] maybe quality control took a hit.

[1] [https://www.bloomberg.com/news/articles/2016-05-12/apple- sho...](https://www.bloomberg.com/news/articles/2016-05-12/apple-shortens-app- review-times-in-push-to-boost-service-sales)

</comment></comment><comment><USER9> Pretty extraordinary that Apple is letting these through.

And some are blatantly flouting the rules e.g. putting Nike.com as their support website.

<comment><USER10> Common situation for any closed app store — Google Play has the same fraud apps and most of Chrome App Store extensions are malware.

<comment><USER11> Neither of those has a review process, though. You just pay a few dollars and can upload whatever you want. Apple's stores do, which is why seeing this many fraud apps is surprising.

<comment><USER12> Not true, every app on Google Play goes through review. I'm not sure about Chrome store, but I presume it may also likely see review for every app.

<comment><USER13> Google play does not review each app unless it's done after the fact. You pay a fee and upload your binary and then it's available. My understanding is that they have a permissive model that relies on users flagging the bad stuff and then they pull it from the store after the fact.

</comment></comment></comment></comment></comment><comment><USER14> What possible utility do people get by using a "retail app" rather than the web? Wouldn't the store's website and/or normal shopping websites (Amazon, etc.) have everything that the Foot Locker app has?

Have people been trained or deluded to "always get the app" when it's not necessary?

<comment><USER15> When I'm around my house rather than at my desk and I realise I need to buy something I get my phone out and order it using the Amazon app.

For example I could be in the garage, out of engine oil, phone out, scan the barcode on the old one using the camera, oil turns up on my doorstep first thing the next morning, sometimes only ten hours later if I do it in time. Takes literally ten seconds tops.

Not so strange is it? See how it saves time and hassle compared to the laptop?

Also some people use phones and iPads as their primary or only computer. I would guess especially less wealthy or technically literate people. And the apps are often much more accessible than the websites on those devices.

<comment><USER14> I noticed in your example about engine oil that you didn't download and install the Pennzoil app or the Castrol app :-).

I get your point about the Amazon app if you use it all the time, you're signed up for it, and the workflow in the app is seamless. But the Foot Locker app? For a once a year purchase of tennis shoes?

I'm still thinking that people install these niche apps because they've been indoctrinated into it. Like the way people type "ebay.com" into Google rather than typing ebay.com into the address bar.

</comment></comment></comment><comment><USER16> For example do a search for 1010!, generally you will find dozens of identical (maybe a slight different icon) apps all with a person's name as the company. I think they are all the same codebase and run by some kind of white label company. I have no idea how anyone makes money off of so many dupes.

</comment><comment><USER17> Link only shows "Log in - New York Times" and a login form, flagged.

<comment><USER18> shows up fine for me.

I use ublock origin and privacy badger, which is probably why

</comment></comment><comment><USER10> > or even lock the phone until the user pays a ransom

How is it possible?

<comment><USER19> Yeah, I'm disappointed that they dropped that line in there with zero explanation.

My understanding is that this should be impossible, as it could likely only be accomplished by calling private APIs. Calling a private API gets an app submission rejected automatically (it's caught by a computer, not a human).

<comment><USER20> >Calling a private API gets an app submission rejected automatically (it's caught by a computer, not a human).

Its rather arbitrary. In a lot of cases it doesn't because the checker is poorly coded. For e.g. if a selector name inside your OWN code clashes with that of a private API (which is not published or even something you should know) it causes the submission to fail. And then people just resubmit and it gets magically approved. People have also reported that it is possible to bypass the checker either using some dynamic runtime trick or figuring out a way to silence private API calls when the app detects its being looked at. (Usual cat and mouse game)

[http://openradar.appspot.com/28252227](http://openradar.appspot.com/28252227)

<comment><USER19> Thanks, I didn't realize that it was relatively easy to bypass. I did know it primarily relied on string matching, but always thought the solution was to rename your methods when you hit a conflict with Apple's private APIs

</comment></comment></comment></comment><comment><USER21> Wouldn't this be incredibly easy to discover? If number of published apps divided by account age is greater than threshold, raise review red flag when user attempts to publish new app.

<comment><USER20> Well you could just cheaply purchase tiny companies who wrote like one app in 2010 and never made any money on it.</comment></comment>


Seeking Feedback for Zapier to PowerPoint App - <AUTHOR> https://getpowerspot.com/ <comment><AUTHOR> Currently, Zapier doesn't connect to PowerPoint. We built an app that connects your Zapier Zaps to PowerPoint. Looking for early feedback, testers etc.</comment>


Tell HN: Add a section where we can see what changes have been made to HN - <AUTHOR> I noticed at lot of changes lately to HN. Such as adding flag | hide | past | web etc.
Also, what I find interesting was: Unlike before, I wasn't able to add in a comment to the post I have made. Trying to find out what is the cause. I have discovered something weird.
On MY new section, my post was showing as if it was a new post and was shown to others. On a new browser that I wasn't logged in, my post was missing. On my devices not connected with the same IP, my post was also missing.
Is there a new rule or algorithm regarding posting?
Can we add a section regarding changes made to HN? It can be a milestone or a documentation on how to understand or use the new features.
I've checked 'dang's timeline' and there are no new announcement regarding these new features being added lately. Thanks. <comment><USER2> The "feature" you mention - having a post visible to you when logged in, but apparently not visible to others - is a long-standing feature. Posts from some sites are "dead on arrival", the mods having determined that posts from those sites are usually poor, and the better ones will be reported by other sites which are not proscribed.

I agree that it would be nice to have, somewhere, a complete list of features, but this is not a new one.

<comment><AUTHOR> Oh, I didn't know that wasn't a new feature. Thanks for clarifying that.

</comment></comment><comment><USER3> I think, but don't know, that URL shorteners are likely to be dead on posting.

Your submission below uses an URL shortener, and I think that's what's caused it to be dead.

[https://news.ycombinator.com/item?id=13210435](https://news.ycombinator.com/item?id=13210435)

</comment><comment><USER4> A changelog for HN would be awesome to have.

</comment><comment><USER5> Check the post from a new account, with "show dead" enabled in the options. Likely it was auto classified as spam. Quite a few people browse with show dead, so it's possible someone will vouch for your link and un-dead it.

<comment><AUTHOR> So are you suggesting that I create a new account, enabled "show dead" option on that account, in order for me to see it? Thanks :)

To HN Mods, I suggest instead of just auto classifying it as spam. Maybe add a warning to that submission that it was classified as spam and if the user still wants to post it considering it is mark as spam, then it's upto them? Thank you.

<comment><USER6> Generally, if you want to suggest things to the mods, e-mail them. They don't see all threads.

<comment><AUTHOR> Noted. I'll send them an email. Thanks.</comment></comment></comment></comment>


AskHN: How to earn $1000/mth as a self-employed programmer? - <AUTHOR> I've heard such an idea that to be happy one doesnt need to earn more than a few thousand bucks per month. Believe it or not I'd be OK with only $1000 per month. I have the skills and can cut all costs for things not required in order to survive. But thinking about  all the stress removed, no more thinking about competition, etc, that would be a positive gain. I think there are some YouTube videos or articles with guys who quitted development/corporate work just to have a regular job.
They say there are not enough IT workers but thats not what they mean. They mean there are not enough workers to do 5 in 1 jobs. So I'm left to work for myself. I started a first project but as I realised how long it would take to finish it and to maintain it as a one person I abandoned it. My second project is easier and almost done but having never launched a business before I have no guess if I will earn any money with it. We like to think that our ideas are so great and everybody will buy but reality is different.
My goal is not to spend lots of money to make and keep an idea alive but the goal here is to earn a small amount of money each month. So if my idea will fail I dont mind doing what everybody is doing. But I dont know what everybody is doing because I spend all my time coming up with new ideas. If people dislike copy-cats, I dislike the ideas being copied. Even successful ideas such as Uber or AirBnB are nothing new to me. If I knew that coppying an existing idea would bring me $1000 I could do that in a short time.
Last time when I had full time work for longer than 2 months was in 2010. Since than all my job attempts were failures. <comment><USER2> You'd get more of a response By listing what skills you have while keeping your failures private.

What country are you in? We hire contactors from time to time, i'm sure many companies do.</comment>


How Agile Failed – A Retrospective - <AUTHOR> https://medium.com/the-process-architect/how-agile-failed-a-retrospective-7a47176ae6a6 <comment><USER2> Agile works, but not for everyone and everywhere. It's like DevOps, you need buy-in from everyone or it won't work.</comment>


Open Container Project - <AUTHOR> http://opencontainers.org/

<comment><USER2> "Docker donating its container format and runtime, runC, to the OCP to serve as the cornerstone of this new effort."

This is a fantastic initiative, bringing everyone to one standard is to be applauded. Congratulations to all involved.

Wonderful also to see Docker pitching in what they started.</comment>


Thoughtworks April 2016 Technology Radar Is Out [pdf] - <AUTHOR> https://assets.thoughtworks.com/assets/technology-radar-apr-2016-en.pdf <comment> sean-kenny There is an interactive version here: [https://www.thoughtworks.com/radar](https://www.thoughtworks.com/radar)</comment>


First Impressions of Rust - <AUTHOR> https://john-millikin.com/first-impressions-of-rust <comment><USER2> > it doesn't even properly align the parenthesized expression after line- > breaking it:

Fair enough if that's not your _preference_ for how parenthesized expressions should be broken across lines, but this quote makes it seem like it's objectively wrong. In fact it's very much a matter of opinion, and personally I hate the style of line breaking that he describes as "properly" aligned because you end up with a distracting pattern of indentation, and parameters get all squished into a tall narrow column:

        x = long_function_name(first_param,
                               second_param,
                               another_fn(x
                                          + y
                                          + z))

Yuck! In Clang-format, you can avoid this with the "AlignAfterOpenBracket: AlwaysBreak" option, which also wraps the first parameter / operand to the next line if it can't all fit onto one line:

        x = long_function_name(
                first_param,
                second_param,
                another_fn(x + y + z))

Just to reiterate: I appreciate that many people would still prefer the first style, and of course that's a legitimate opinion. My point is just that it's also a legitimate opinion to prefer the second style, not something you can describe as "not properly aligned".

Of course this is a nitpick on an excellent article.

<comment><USER3> This was the key line: > I eventually gave up on trying to make the formatted rust-fuse code look pretty, and settled for "consistent".

It turns out that most aspects of coding style are subjective and are fine once you get used to them. The *-fmt tools that are now the fashion get everyone past that initial stage of formatting things as you personally would and get you used to a common style.

Maybe one person (the author of the style tool) is completely happy with the chosen style, but consistent is more important than personal preference on details.

<comment><USER4> One thing I've learned over the years using a lot of different languages is to pretty much ignore my _initial_ reaction to syntax or formatting conventions for any given language - there is a pain period and then you get used to things and move on...

Edit: I'm particularly thinking of PostScript, Lisp and Python - which on first impression seemed crazy but I actually learned to really like.

<comment><USER3> I have a similar thing when I work on a new codebase (or join a new company for that matter): make a note of all the pain points, but don't do anything with them for a few months.

It'll turn out that a lot of them were for a good reason, but some of them won't be and the existing team has just got used to them ('missing stair'). That's why the notes are important, because you probably have too!

<comment><USER4> Mind you - I have joined places that were genuinely crazy (no source control, no backups, deployment by RAID...) where some things needed fixed _immediately_.

That was a long time ago though.

<comment> benji-york > deployment by RAID

I'd like to hear that story.

<comment><USER4> The company supplied on-premise server 'appliances' for a particular market niche.

To create a new deployment, find an existing server (usually at an existing customer), take out a mirrored RAID disk and replace it with a blank one. When mirroring complete put old one back in and take your new copy and use it in a new server for the new customer....

Repeatable build process, repeatable deployment process - who needs that when you have the power of RAID-1! <sob>

Fortunately, it was a long time ago....

<comment><USER5> Wow. That's both amazing that somebody thought to do that and it worked, and terrifying that it became the official solution for production deployments.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> You should be able to get the size of c_ulong without any dependencies using std::mem::size_of::<std::os::raw::c_ulong>(). I usually use std::os::raw instead of the libc dependency in my own crates, even though some people consider it bad style to do so. (Working in graphics it's often the case that I don't need anything from libc except a few data types.)

Another note: The notion of a "compilation unit" in Rust is fuzzier than in C/C++, because of incremental compilation. The goal is to be able to point rustc at a crate and have rustc/cargo _internally_ decide which parts of it should be recompiled and which can be cached. A good chunk of this is already done today—for example, rustc will internally split up single crates into multiple LLVM compilation units to get better parallelism during the codegen phase—but more can definitely be done. Basically, Rust leans more on "compiler heroics" than C/C++ traditionally has, in that the compiler effectively splits up source files automatically instead of the programmer manually doing so.

<comment><AUTHOR>
      > You should be able to get the size of c_ulong without
      > any dependencies using
      > std::mem::size_of::<std::os::raw::c_ulong>().

That's very useful, thank you! I hadn't noticed `std::os::raw` before, but it's exactly what I wanted.

</comment></comment><comment><USER7> Author's opinion on rust:

"I really really enjoy using Rust. It is nearly everything I want in a systems programming language, and the few parts it's missing are due to legitimate technical difficulty. The amount of careful thought I've seen put into its design – crafting async/await to work in no_std environments, or the new inline assembly syntax – has produced a language that is not only better than what I could have designed, it's better among axes I was not even aware existed prior to reading the Rust RFCs."

</comment><comment><USER8> I went into this expecting yet another barrage of complaints about lifetimes, but was very pleasantly surprised. This is probably one of the most thoughtful experienced-programmed new-to-Rust reviews I've read in a long, long time. I frankly don't have much to add, except to say that, once you really _understand_ the language and start building complex projects, this article really does describe the real issues you run into.

<comment><USER9> I think I am familiar with Rust–I spent a week or so working with it–and I ran into many of these exact issues. I appreciate it very much when someone can give a viewpoint of of using a language beyond the superficial one ("arrays start at one in Lua"), or complains about something core to the language ("C pointers are confusing") and actually says something you will run into but is not obvious from having a basic knowledge of the thing ("while Python supports functional programming, it does not do so very well"). Rust's (intentionally) anemic standard library, strange dance around nightly ("we never break things…except in nightly, which we know you are using for your project because we gated all the features behind it") and a general sort of superiority towards npm when cargo/crates.io shares many of the same issues are the ones I ran into personally. And again, you don't have to be an expert to see these, but they're in this sweet spot between nonobvious and "something that'll go away if you use the language more".

<comment><USER10> > which we know you are using for your project because we gated all the > features behind it

I don't think that's really fair, or at least hasn't been true for a long time now. Use of the stable channel far exceeds use of nightly according to all the surveys. At my company we've always stuck to the stable channel, and even in my own personal projects where I have no need for stability, I don't remember the last time I used a nightly feature, simply because I haven't found the need to...

I don't believe there are many cases left where you're forced to use nightly: most of the cases where people are using it is because there's a "nice to have" feature, not because that feature is actually essential. Even rocket, which was famed for using a ton of nightly features, now works on stable Rust.

<comment><USER11> Anyone doing OS development is still on nightly last I checked but aside from that stable has the features most people need.

<comment><USER12> I'm curios which features OS development need from nightly. Maybe inline assembly?

I've been doing some bare metal embedded projects in Rust and didn't need nightly for quite some time.

<comment><USER13> I use the following in my kernel project: asm, const_fn, const_generics, exclusive_range_pattern, global_asm, panic_info_message, start, untagged_unions.

Of those, I could get away with just global_asm, start, and const_generics if I had to, but the others certainly make my life easier in a kernel space without an allocator.

I'll be the first to admit that some of those are "I'm just going to embrace nightly if I'm stuck on it anyway".

</comment></comment></comment></comment></comment></comment><comment><USER14> I find it absolutely frustrating that Rust packaging/crates.io doesn't support namespaces. The arguments I've read are always theoretical/what ifs, but I've yet to be convinced the current situation is better than the practical benefits of namespaces.

<comment><USER15> How do we decide which person/entity gets a namespace? What about namespace squatting? What if there's a dispute? What do we do about all the currently un-namespaced crates? How would Rust (the language) understand namespaces? How would cargo work with them?

<comment><USER16> > How do we decide which person/entity gets a namespace? What about namespace > squatting? What if there's a dispute?

My proposal is to give everyone a namespace corresponding to their crates.io username, so if I want to publish a JSON library, it would be "user/majewsky/json".

Everything not prefixed with "user/" is a shared namespace which is handled by a team of curators. If someone wants to publish into the shared namespace, they need to apply for a package name. So if I think my JSON library should be the standard, I could apply for having it aliased to "json" or "encoding/json" or whatever. The curators would be allowed to impose an overall structure in the shared namespace to aid those who browse it.

Crucially, the curators should have the right to revoke an existing lease. If someone publishes their JSON library into the shared namespace as "json" and then later down the line abandons the project, other community members should be allowed to apply to take over that name. Of course, existing releases would stay untouched, but if I stopped maintaining my JSON library at 1.3.7, someone else should be allowed to take that over and publish 1.3.8 or later.

I would also impose the limitation that 0.x versions are not allowed in the shared namespace. If you want a nice package name, you should be ready to commit to at least a somewhat stable interface.

> How would Rust (the language) understand namespaces?

It's not hard to imagine a Rust that works with namespaced crates. What _is_ hard is finding a solution that's backward- and forward-compatible.

<comment><USER17> > Everything not prefixed with "user/" is a shared namespace which is handled > by a team of curators.

The docker "hack" of using `_` is quite a smart hack here, and works well; for me at least. E.g. [https://hub.docker.com/_/postgres](https://hub.docker.com/_/postgres) its clear this is some "official" build.

<comment><USER16> But when you pull it, it's just `docker pull postgres:12`, not `docker pull _/postgres:12`.

</comment></comment></comment></comment></comment><comment><USER18> Hey hey, this post is great! A few small comments:

> It's not obvious to me why they do this – it's a documentation generator, > why does it care what version of the Rust compiler I'm using?

rustdoc, being a part of the Rust distribution, has the same stability guarantees that Rust does: once it gains a feature, it will never go away. We (well, not me I don't really work on rustdoc, to be clear) need the capacity to try out new features without committing to them, same as features in the language.

> PyPI launched in 2003, and CPAN has been running since 1995

Neither of these support namespacing though, right?

> Cargo's unit of distribution is the crate, which is a problem because Rust's > compilation unit is also the crate.

Cargo's unit of distribution is a _package_ , which is one or more crates. It is true that there can only be one library crate per package, however. This is one area where people don't use the correct words super often, honestly.

> Of course build times are slow if changing one line of a leaf file requires > rebuilding dozens of modules.

This shouldn't change based on if you're using Cargo or not; if it's re- building dependencies every time you touch a file, that is a bug.

<comment><AUTHOR>
      > rustdoc, being a part of the Rust distribution,
      > has the same stability guarantees that Rust does:
      > once it gains a feature, it will never go away. We
      > (well, not me I don't really work on rustdoc, to be
      > clear) need the capacity to try out new features
      > without committing to them, same as features in the
      > language.

I guess I expect rustdoc and rustc to be much less tightly coupled, so that I could use (for example) stable rustc and nightly rustdoc on the same code.

In the current model, I can't use nightly rustdoc features without also using nightly rustc, because the annotations are processed by both systems.

You could imagine an alternate model where rustc stabilizes `#[doc(...)]` and leaves everything in there up to rustdoc's interpretation, and nightly rustdoc might enable new parameters to the #[doc] annotation.

      > Neither of these support namespacing though, right?

That's correct. I meant that mostly in terms of "package registries are not a new and untested idea". It's like using strings for file paths: not obviously a bad idea, turns out to be unworkable for obscure reasons, and as a new language Rust got to avoid that particular mistake. It feels like crates.io didn't (/ doesn't) have a similar process of avoiding known mistakes.

      > This shouldn't change based on if you're using Cargo
      > or not; if it's re-building dependencies every time
      > you touch a file, that is a bug.

Given a crate with a hundred files, each one fairly independent of the other (i.e. a broad shallow build graph), changing one requires (if I understand rustc correctly) recompiling them all. Otherwise the `crate::` references can't be type-checked.

<comment><USER19> Would you be willing to expand on why using strings for file paths turns out to be unworkable? Very curious what the obscure reasons are!

<comment><USER20> If your String type must be valid Unicode (which is true for pretty much every language that isn't C++), it cannot represent all paths. On most unixy filesystems, filenames are arbitrary byte sequences which aren't valid UTF-8, and on windows, NTFS stores filenames as UTF-16, but it allows unpaired surrogates.

<comment><USER21> What languages require string types to be valid Unicode? Go for example let's you put anything in a string; it's only Unicode if you put Unicode into the string including via creating string literals.

<comment><USER3> Requiring strings to be valid unicode simplifies the internal workings of (and use of) a language greatly. Dealing with unknown input becomes a single operation at the boundary after which you can safely assume everything is validly printable or processable as text.

<comment><USER21> I think there is some convenience in being able to use the type system to denote input which has already been validated; however, I can't see how a language runtime benefits from this property with respect to unicode. Notable, printing and processing text aren't operations a runtime typically deals with. Libraries including the standard library might benefit from this property, but even then I wouldn't say the benefit is "great". It's a nice property, but I don't think it makes or breaks anything.

<comment><USER3> It's worth pointing out that Python 3 thought it important enough to make a backwards incompatible change to separate 'bytes' from 'strings' to effectively get the same result.

<comment><USER21> Probably, but I think that's more to do with the typing convenience (which is even more puzzling in Python's case since it isn't statically typed).

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER22> > I eventually gave up on trying to make the formatted rust-fuse code look > pretty, and settled for "consistent".

Even though it's a bit ugly, this is a big win.

As for why it does this, from my experience, rust-fmt will try to keep lines under a column limit but _not_ greedily. e.g. if a params list would extend past the limit, then all params get a newline. It seems to try to balance horizontal estate and vertical estate and I've become used to that (even though it is inconsistent at times).

Any formatting rule is going to fall over eventually. Rust-fmt seems to make sane choices the majority of the time.

<comment><USER23> Consistency > prettiness

<comment><USER24> Is it _just_ prettiness though?

When I worked in the defence industry (~15 years ago now), a lot of the coding standards for C/C++ (which was starting to be used more and more over ADA at the time) were very strict on the matching alignment of things like open / closing braces, so things like hanging braces were not allowed, both opening and closing braces had to be on their own lines.

The argument behind this was it made the code clearer, and more easy to match clauses / scoping - in a way arguing it was "safer" in terms of interpretation of the code.

<comment><USER25> Maybe, maybe not. Is the potential benefit even worth fighting over? Style is just full of so many subjective details that every discussion ends in. And everybody has their favorite it's _un-fucking-readable_. My oppinion converged on "Fight it out and tell me what options in $formatter I need to set. Don't even tell me reasonings, just the options. _leaves room_ ". I'd rather drink coffee than have the next horizontal real estate vs. parameter alignment debate.

The argument to match clauses/scoping for example is weird in a world where a formatter automatically applies indentation. It might make sense when you have to manually check them on print-outs without an Editor. I'd argue GNU style fulfills that role even better or Horstmann if you care about vertical real estate (or be daring and combine the two). And now everyone hates me.

<comment><USER17> I lean to the other side.

In a way that I tell the requester "you better have some really, really good reason for wasting my time on this".

Hell, I've even had a new hire prepare an entire presentation to convince us to change the line-length to something different than "The Language Standard".

"We follow the language standard" and if you don't like it, convince upstream (This was Rubocop/Ruby) is another one I've used in the past.

Naturally both people just gave up. There really is a better way to spend time than on tuning and tweaking a linter. Nearly all linters have some way to document and define very local exceptions for that case when some external__dependency_IsMxing_camel_case or whatever.

</comment></comment></comment></comment></comment><comment><USER26> > Closed-world ("sealed") traits. Rust's rules against private types in the > public API are good civilization but they make it difficult to define > pseudo-private traits like Mount that I want users to name but not implement > or call into.

Rust actually supports sealed traits by using public traits in private modules. See this for how to use it, and how it works:

[https://rust-lang.github.io/api-guidelines/future- proofing.h...](https://rust-lang.github.io/api-guidelines/future- proofing.html)

<comment><AUTHOR> I'm aware of that workaround and do use it in `rust-fuse`[0], but I'm not satisfied for two reasons:

* It's not understood by rustdoc, so I have to manually document that the trait is sealed.

* It technically violates Rust's rules against private symbols in the public API, so a future version of rustc might deprecate or remove that functionality.

[0] [https://github.com/jmillikin/rust- fuse/blob/a6ad16d1127d36f8...](https://github.com/jmillikin/rust- fuse/blob/a6ad16d1127d36f80e6d02f36e48da56920ca693/fuse/src/server.rs#L53-L57)

<comment><USER27> > * It technically violates Rust's rules against private symbols in the public > API, so a future version of rustc might deprecate or remove that > functionality.

It's public though, just not externally _reachable_ , the private module doesn't make the trait private.

For example, if you wanted to, you could reexport the trait in the parent module (and I guess the drawback with the "sealed" pattern is accidentally doing that when it would be unsound do because of how you relied on it being "sealed", in unsafe code).

I don't think I've heard anything about plans to restrict anything based on _reachability_ , and it would be massively backwards-incompatible so I doubt it would even be considered for an edition.

</comment></comment></comment><comment><USER28> After working on rust for almost 2 years, I finally reached a point where I can see (and wait for) a few improvements.

First is completing the `impl Trait` saga. I see a couple of areas where I'm obliged to box a trait to get the compiler to accept the code. Not the end of the world.

Second is allowing conversions of AsyncRead to Stream. currently you have to do a weird dance to get chunks of tokio::File as Stream of Bytes. I think something is missing. Something as straightforward should be easy even if it's not part of std.

Last, is adding support for Generators and their transformation into Stream. Then, getting a Stream of Val would be as simple as `yield val` in a function. I'm sure their current API on nightly will change before it's merged to stable rust, and I even hope they will get rid of the "return type" in gens (it complicates things a little bit).

After that last point, I can see Rust replacing python for most of the data prep work we have in data science/AI.

</comment><comment><USER29> Unix-stuff as a part of the standard library is a terrible idea. Making your own crate is simple enough. Same with OS-dependent functionality.

Re: crates namespaces, that is a crates decision, not necessarily Rust'. You can always publish your crate on github and include it with "package = { git = ... }" and you'll get the same thing as in go.

<comment><USER20> Why is that not true for the rest of the standard library? You don't _really_ need a HashMap in your standard library, or mutexes, just a memory allocator and atomics.

<comment><USER18> Historically, the criteria for inclusion in the standard library is, does it fall under one of these three categories:

* Used in the vast majority of Rust programs.

* Reasonably common things that require a lot of unsafe to implement.

* Traits for interoperation purposes.

HashMap and mutexes fall under #2. The idea is that they'll receive significantly more scrutiny, and this is a good thing for the ecosystem.

(These are guidelines, not hard and fast rules, so not literally everything fits here, but that's the framework that was used to think about what should be included or not, generally.)

<comment><USER15> To be honest I think #2 was applied a bit too broadly. Sure rustc gets scrutiny but the std isn't the easiest library to contribute to. Not only is it large (by rust crate standards) but it's also tied to the compiler which adds another barrier to contributions.

Mind you, increasingly parts of the std are more like wrappers around third party crates e.g. hashbrown and parking_lot.

<comment><USER18> Yes, I think this calculus changes over time. Back in the day, I think this reason was more important than it is now.

</comment></comment></comment></comment></comment><comment><USER30> Suggestion for page styling: replace "overflow: scroll" with "overflow: auto" to get rid of unnecessary scrollbars in code blocks. Unless you like them the way they are, of course.

<comment><AUTHOR> CSS and I have a strained relationship.

[https://mstdn.io/@jmillikin/103158451151123313](https://mstdn.io/@jmillikin/103158451151123313)

I'll put this on the list of things to fix next time I go digging at the stylesheet.

</comment></comment><comment><USER31> Yes thank you for not fauning over Cargo like many other reviews.

The simple fact is Cargo did not learn from prior art to the extent Rust did.

Things have gotten better, but Rust is still better designed. Hopefully Cargo can someday catch up.

<comment><USER32> If this is referring to namespacing, that's a crates.io concern, not a Cargo concern. Cargo is fully capable of using other registries, and there's nothing stopping those registries from using namespaces to organize and disambiguate crates.

<comment><USER31> I'm not referring to namespacing in particular, which indeed doesn't concern me so much for those reasons.

</comment></comment></comment><comment><USER33> > Closed-world ("sealed") traits. Rust's rules against private types in the > public API are good civilization but they make it difficult to define > pseudo-private traits like Mount that I want users to name but not implement > or call into.

What about a public type with no public fields nor public methods? Doesn't that accomplish exactly what the author is looking for?

</comment><comment><USER34> Once a Rustacean always a Rustacean - a first impression will inevitably lead you down a never ending road but luckily there is a great community to support you.

<comment><USER35> I gave Rust a good solid tryout.

It turned out to be insufficiently expressive to put into libraries the semantics I want to encapsulate. I went back to C++, and have been very happy. (It's also nice that lots of people want to pay to have it done.) As with Rust, I can write 2000 lines and, once it compiles, it works.

The hardest thing about going back to C++ from Rust was getting used to putting semicolons where Rust doesn't require them. Years later it still trips me.

<comment><USER36> isn't C++ more like "once it compiles, it works, but later you discover 10 places where it segfaults"?

<comment><USER35> That is how the propaganda goes. But in modern C++ style, memory errors just don't have many opportunities to happen. I.e., with the more powerful libraries C++14 and up enables, there is little temptation to drop to a risky level. And, anywhere you choose to, you can give it your full attention.

So, overwhelmingly the bugs you do get are specification bugs: the code does what was asked, but the ask was wrong. The only way to avoid those is to pay attention. Anything that steals attention generates them, in C++ as in Rust.

Old, pre-C++11 codebases (and codebases still written that way, or in C-with- classes style) suffer more. Mozilla and Google have a _lot_ of old code.

<comment><USER35> You can down-vote all you like, but it remains true all the same.

</comment></comment></comment></comment></comment><comment><USER37> > I've found Bazel and rules_rust provide a good alternative to Cargo, since > Bazel can twist your build into any DAG you want, but most Rust users are > unlikely to be excited about injecting 50MB of Java build system into the > middle of their workflow.

If anyone is interested in another alternative to Cargo that doesn't involve Java, there is build2[1] and it's libbuild2-rust[2] module. It's a general- purpose build system so you can have mixed-language projects, etc.

[1] [https://build2.org](https://build2.org)

[2] [https://github.com/build2/libbuild2-rust](https://github.com/build2/libbuild2-rust)

</comment><comment><USER38> > [In Haskell] I spent a lot of time debugging dangling pointers and race > conditions.

Uhm, ok, pointers in Haskell… must be really low-level programming, because ordinary Haskell doesn't deal with pointers.

<comment><AUTHOR> For a self-contained example, see [https://github.com/jmillikin/haskell- ncurses/blob/master/lib...](https://github.com/jmillikin/haskell- ncurses/blob/master/lib/UI/NCurses.chs)

My Haskell binding to CPython is larger but of about the same shape.

</comment></comment><comment><USER39> Seems a little unfair to cargo to give it a scathing review when your alternative ecosystem is C++ or Haskell.

The basic complaint boils down to "packages aren't namespaced" and "someone already took the 'fuse' package", which has been a long running controversy for exactly that name-squatting reason.

However, Cargo is great.

> Rust's default build system (Cargo) and package repository (crates.io) are > the opposite. They combine the worst parts of Cabal/Hackage and NPM, > resulting in a user experience that is somehow inferior to both.

No. They don't. That's your opinion, not a fact, and I completely disagree. Lots of people disagree. Your arbitrary assertion is unsubstantiated and I reject it. :) Perhaps you meant "resulting in a user experience that _I found_ somehow inferior to both".

If you don't like it, and you prefer to use bazel, then by all means be welcome to do so... but I think a little bit of acknowledgement is in order that ... frankly, that behavior should be discouraged.

We _want_ a unified good build system for rust, not a ridiculous mess of difference package managers and build systems like in some other language ecosystems. Sometimes, conformity is a better approach, and I would be deeply saddened to see rust go that way.

I'm very impressed with the efforts to bring wasm support to cargo, and the other initiatives.

Be nice. Lots of people work really hard on cargo. They're doing a great job.

<comment><USER40> > We want a unified good build system for rust, not a ridiculous mess of > difference package managers and build systems like in some other language > ecosystems. Sometimes, conformity is a better approach, and I would be > deeply saddened to see rust go that way.

I would like to disagree on this. I would prefer to see the Rust ecosystem play better with other build systems, instead of requiring all Rust to use Cargo. This becomes important when you are using Rust as part of a larger, multi-language code base. At my day job, we have Rust, Python and Typescript, and we use Bazel for much of the build, getting a bunch of advantages that Bazel brings to the table - remote caching, being able to query the dependency graph, selective testing and so on. These latter are not available in cargo, and would be significant work to re-implement infrastructure based on querying cargo instead of querying bazel.

I think there are 3 different things that Cargo tries to do, which would be better of with strong (and well documented) boundaries between them, so that users could mix and match each of these.

1\. Compiling a crate - This is usually one rustc call. I'd venture saying that build.rs files are another layer, but I haven't thought about it enough. It is pretty common in Bazel-land to have build.rs wrapped in a `rust_binary` that is a dependency for the crate itself (usually `rust_library`). This is the easiest to plug into other build systems. 2\. Compiling a set of crates/packages - Assuming a system where all the crates are on-disk, Cargo does the job of invoking rustc correctly with the dependencies passed and the right set of features selected. For Bazel, this is what rules_rust implements. The thing is, rules_rust has to figure this out by inspection of Cargo, instead of being able to rely on editions or compiler versions. (FYI, I've never used rules_rust. We have our own internal rules for Rust and we had to figure out things by inspection. Particularly Cargo specific environment variables that are not a part of the Rust language/stdlib, but are assumed to exist by libraries). 3\. Package management - i.e. how to get dependencies from the network/someplace else onto disk. I'd suspect this is one place most large orgs would prefer not to rely on Cargo, because it necessarily locks them into some kind of delivery mechanism that is specific to the ecosystem, instead of having a dumb file server. i.e. we would need one for npm/yarn, one for pypi and so on, where each of these frontends know how to go from the "language package name" to the file on disk. I much prefer Bazel here where external dependencies are specified just by HTTP URLs and a sha256 hash to verify contents.

I'm almost _not_ on board with each language building their own compiler driver and package manager, because they end up duplicating so much work - some kind of caching mechanism, some kind of toolchain mechanism, some kind of resolver mechanism and so on...

</comment></comment><comment><USER41> This guys website is weird.

I first noticed as scrolling doesnt work with the keyboard. Upon inspection of HTML hes using weird shadow dom stuff.

Why do people do stuff like this? Its a static site, modern HTML and CSS are huge and can handle nearly any situation.

<comment><USER42> Scrolling works with keyboard. There is nothing weird about shadow dom, it's part of the standard.

<comment><USER43> That's like saying "There's nothing wrong with using setjmp/longjmp. It's part of the standard."

I firmly believe that you shouldn't need client-side JavaScript for anything fancier than things like progressively enhancing a form field into a clickable star-rating widget unless you're writing an actual "web app"... definitely not for a blog. I'm just glad the text of his articles remains readable under the influence of my default uMatrix settings, even if none of the site-navigation boilerplate is.

Heck, if I thought it could be done without failing Lyndon Johnson's "the harm it would cause if improperly administered" test, I'd ask for laws that penalize people for pushing that sort of computating to the client where it can't be cached for more than just that one machine. They could be justified as a way to cut down on CO2 emissions.

As-is, if I can ever find the time, I want to see how much performance gain and "model has desynced from visible rendering" resilience I can get in my Firefox by ripping out Tree Style Tab and replacing it with something that uses the sidebar's DOM as the authoritative data model, built using <details>/<summary> expander/collapser nesting. (I've already prototyped the HTML for that as a simple transformation of what Markdown or ReStructuredText renderers output for nested <ul> outlines.)

<comment><USER44> This is one of the last sites that I would criticise for use of client-side JavaScript. It uses _one_ small script to implement a few simple web components. The power required to run that script is negligible compared to what the browser itself requires merely to render static HTML. You probably produced more CO2 just breathing while writing that comment than can be cumulatively attributed to this script across all visitors to this site to date.

The shadow-DOM thing svnpenn commented on is a red herring. It doesn't interfere with keyboard scrolling, which works perfectly well. The shadow DOM is merely used to isolate CSS styling rules so that they apply to an instance of a component rather than sharing a single global namespace. The elements are still rendered as part of the parent document.

</comment></comment></comment></comment><comment><USER45> I'm surprised they didn't mention the elephant in the room: the borrow checking, boxes, and other ways that the code forces you to do the work of making sure your code is bug free before it will compile.

<comment><USER46> Probably because that's the entire point of Rust and has already been blogged to death. There's nothing new to say about the borrow checker or boxing heap- allocated objects.

</comment></comment><comment><USER47> An insufficient auto-formatter is very frustrating ...

I think there are very smart older programmers who don't appreciate this fact properly. They sort of have a belief that there does not exist a "sufficiently good" good code formatter for all users -- and so therefore code formatter should have tons of configuration options to satisfy a range of style choices.

I think that opinion belongs in the past (with the discussion of tabs vs spaces). We have witnessed the existence of sufficiently high quality opinionated code formatters (java, gofmt, prettier, ...) -- and these code formatters without style choices produce a better world.

The way to get there is to find and prefer the non controversial formatting choices -- that means style preferences are abstracted away and consensus building grows from examples of code that everyone agrees is wrong and wants to fix.

The rust formatting issue he highlights makes me really annoyed -- the format chosen by the auto formatter for that sample code is not the best for that situation -- and I'm pretty sure it would be non-controversial for folks to agree on that ... am i right?

I'm doing some swift in xcode after awhile using an ide that lets me have "reformat on save" and the experience of "reformat on save" is good enough that I think it probably should be adopted as a first class goal of language designers -- there should be a language level "reformat on save" story that language designers assume will be used ... Baking in reformat on save as an assumed feature at language design time could allow creation or recovery from "write only" syntaxes -- (nice to write but ambiguous to read) -- either added on purpose or by mistake. Would also allow for really powerful Language evolution cleanup opportunities and the opportunity to introduce semantic changes where old functionality is preserved with complete compatibility until the source file is interactively edited from within an editor (eg the semantic change produces a code diff) ...

<comment><USER48> Whether reformat is called on save is up to your text editor and has nothing to do with the language.

<comment><USER47> Yes but there is no reason a language ecosystem can't assumes that this functionality is present, implemented in canonical form, and that it is a language use error not to enable.

If the language designers assume the capability exists and will be used -- they can specifically evolve the language based on this assumption. All thats needed is a super high quality, compiler-provided implementation of the functionality -- and to set the expectation -- "sorry you have to wire this functionality up -- otherwise your code is going to be more likely to break if you edit the source files over time while also upgrading your compiler over time."

I'm benoaning the fact that no languages I'm aware of have advertised such a position as part of their evolution plan ...

<comment><USER48> I think that you should have a second think about whether what you're saying makes sense.

To "save" some code means that an application writes it to hard drive. But writing to a hard drive is entirely orthogonal to the operation of a compiler. For example, a compiler should be able to compile code that is never written to hard drive -- exists only in memory. The hard drive is just one possible source of code to be compiled.

I do agree with you though that autoformatting code on save is a fantastic experience. It works beautifully with Rust, and so now I do it (less beautifully) with Python/black. I just think that although it's a great developer experience, it's several steps removed from anything that anyone would want tied to the compiler.</comment></comment></comment></comment>


Mini-server at home, any good hardware options other than Mac Mini? - <AUTHOR>

I'm looking to build a small server at home. Something physically small, yet powerful, like a Mac Mini. Is there any alternatives, probably cheaper? (depending on configuration, of course) <comment><USER2> Any mini-ITX motherboard will be that size; for PSU a pico-PSU or similar is good. Biggest advantage over a mac mini is not price, but options; you can get dual ethernet; you can add a ePCI or PCI card, etc.

Strangely enough I find the case to be the only part that is pricy. Finding an inexpensive ITX case can be hard.

I optimized for power consumption a bit more than performance, so I went with a Via SoC based board (18W at the wall). They have atom and Core based ones as well though.

<comment><USER3> <http://www.mini-box.com/M350-universal-mini-itx-enclosure>

</comment></comment><comment><USER4> I have a little Lenovo IdeaCenter as well as a few minis. The Lenovo is smaller and can be used as a media pc as well, but it's nowhere near the Mini specs. They're not horrible though, you can upgrade the ram (I didn't) and throw an SSD in (I did) but at the end of the day it's still an Atom.

[http://www.amazon.com/Lenovo-Ideacentre-Series-40814AU- Deskt...](http://www.amazon.com/Lenovo-Ideacentre-Series-40814AU- Desktop/dp/B003SCAYIA)

</comment><comment><USER5> I have a Jetway Mini-top: [http://www.newegg.com/Product/Product.aspx?Item=N82E16856107...](http://www.newegg.com/Product/Product.aspx?Item=N82E16856107081) that is very comparable to a mac mini, and fairly reliable.

1.8ghz atom, nvidia ion2 ddr3 memory.

Mine is my media server and desktop (I don't play games). It's a little slower running osx than other oses but if it's a server, you probably won't care enough to put osx on it.

</comment><comment><USER6> I've heard good things about the HP Proliant Microserver.

[http://h10010.www1.hp.com/wwpc/us/en/sm/WF05a/15351-15351-42...](http://h10010.www1.hp.com/wwpc/us/en/sm/WF05a/15351-15351-4237916-4237918-4237917-4248009.html?dnr=1)

</comment><comment><USER7> I think Apple may be updating the mini this fall, so I'd wait a month or two if possible. <http://buyersguide.macrumors.com/#Mac_Mini>

</comment><comment><USER8> A HP Microserver N40L is a pretty decent NAS. If you're willing to tinker a bit, you can also add some additional harddrives outside of the coldswappable drive-shafts.

<comment><USER9> i got one of these when there was £100 cashback, meaning the total cost was about £130. I paid another £40 for 4gb of ECC ram so I could use it like a real server.

It's an excellent case design - there's a huge fan at the back pulling air over the 4 drive bays and my TB drives never go over about 25C. It's in a cupboard and unless I open the door it's totally silent.

From what I've seen of other NAS-style devices, it's pretty much unbeatable for value since it does all the same stuff but is ultimately a real, if basic, server.

</comment></comment><comment><USER10> Asus EeeBox

<http://event.asus.com/eeepc/microsites/eeebox/en/index.html>

</comment><comment><USER11> TonidoPlug [http://www.amazon.com/TonidoPlug-Network-Attached-Storage- Pe...](http://www.amazon.com/TonidoPlug-Network-Attached-Storage- Personal/dp/B007JDL6CM)</comment>


Wolfram Alpha doesn't "get it" - <AUTHOR> http://blog.agiletortoise.com/post/3564424414/wolfram-alpha-doesnt-get-it Full URL: http://blog.agiletortoise.com/post/3564424414/wolfram-alpha-doesnt-get-it <comment><USER2> The problem with the Wolfram Alpha terms of service is that they forbid natural, common uses of the web site.

"The Wolfram|Alpha service may be used only by a human being using a conventional web browser to manually enter queries one at a time."

Think for a minute what that forbids. Generating links programmatically, yes. Tweeting links? Yes. Emailing a URL? yes. Bookmarks? Oh, yeah...

Enforceability of the ToS aside, I think the original author is correct: that phrase in the Terms of Use shows that Wolfram|Alpha doesn't "get" the way the web works. Or at least they give too much free reign to lawyers who don't get it.

<comment><USER3> Tweeting a link seems like a good example of a "common sense use of the website" that could bring it to its knees if some queries take 30+ seconds to complete.

<comment><USER4> Caching exists.

<comment><USER3> "But queries shouldn't ever take 30 seconds". Ok then.

</comment></comment></comment></comment><comment><USER5> He says they are "totally within their rights", but he is wrong. He's making links to their web pages. They are not "totally within their rights" to try to forbid that.

<comment><USER6> As I read this, he's not making links to their web pages. He's deep linking to their content and displaying it within what appears to be a custom browser. While there is plenty of debate about the propriety of deep linking and whether sites have the right to bar deep linking, displaying content within a custom browser is analogous to 'framing' content without permission, and framing content a no-no.

Creating deep links to their content would be launching Mobile Safari with their content in it.

Now, it could be that after he talks to them and they have a look at his app, they decide that yes, he's framing their content but he does so in a manner they feel is in their best interests and is compatible with their business model as they see it. In which case, they will give him written permission to do so.

<comment><USER7> What is the difference between "linking" and "deep linking"? Whatever else W|A is, it is a web server and it responds to my requests by sending me web pages. Why does Wolfram get to decide for me which web browser I should use to view those pages?

<comment><USER8> People that don't understand what the web is, why it's important, or how it works get mad when you link to

        http://www.something.com/ANYTHINGATALL

They think you should _only_ ever link to

        http://www.something.com/

If you couldn't tell by my first sentence, I find this idea repulsive.

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

<comment><USER9> On a slightly related note, what do you think about framing another site's contents? The original article is closer to framing in this respect, i.e. showing stuff in a UIWebView is more analogous to framing.

I am currently developing a content aggregator site, but haven't decided how to link/display original articles. Should I be putting a frame at the top (or display orignal content in an iframe?) so that users don't leave my site, or should I directly link to the original article? I have strong suspicion that doing the former would be unfair, but some sites like stumbleupon do it to improve user experience.

<comment><USER8> I strongly, strongly dislike stuff like the old Digg bar, or the Reddit bar. I'm assuming that's what you're talking about?

        http://www.reddit.com/tb/fp3vz

If I'm looking at a page, I want the URL to be the URL of the page I'm looking at. Feels quite scummy otherwise.

That said, feel free to do it, nobody can (or should) stop you.

<comment><USER10> On the desktop, I couldn't agree more. On a mobile device, its a handy shortcut to the pages I will most likely visit next anyway.

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> I think it's important to note that many queries on Wolfram Alpha are VERY heavyweight--I've had complex calculations and rendering take 30 seconds to a minute to finish. It's not like Google where a query get a result in a few milliseconds. So while Terminology is not likely to be querying it with lots of formulas, I think the policy exists so a badly thought out automated querier can't accidentally put a huge load on Wolfram's engine.

<comment><USER8> There's an easy technical solution to this: just block the freaking querier.

Also, if they didn't render a result as an image, maybe it wouldn't take so freaking long...

<comment><USER12> Now, I am probably wrong but am asking this due to curiosity. Could they conceivably use HTML5 to render dynamically thus reducing resource/load cost?

 _Edit_ : No to Now

<comment><USER8> I hope they don't try to sue me for this post.

        http://www.wolframalpha.com/input/?i=2+%2B+5

(oh noes!) gives an image containing '7'. They could just freaking put a 7.

Granted, not all of their queries could be done this way, and some of those could indeed be done with canvas, for example. Dunno if those would be faster. But all of the numbers and tables could stand to just be numbers and tables.

This is more of a gripe about copy/paste than performance, really: I'd imagine their calculations take a lot longer than making a .png

<comment><USER12> Makes sense.

What if they output in LaTeX for more complex things, and there was a LaTeX plugin for browsers?

<comment><USER13> I've seen Chrome plugins and I know there are Greasemonkey scripts for automatically LaTeXing plain text on web pages.

I don't think this is a viable solution for W|A, however.

</comment></comment></comment></comment></comment></comment><comment><USER14> A lot of people in this thread are concerned about the TOS and whether or not it is enforceable. But did anyone notice that he claims wolfram served apple a DCMA notice for the app? That law was supposed to be for copyrighted artwork. Aren't wolfram alpha, and other sort of dynamic procedural output from websites more of a service than an artwork (or a 'work' as it is probably termed in the DMCA? It seems a bit pretentious to refer to the output of something like wolfram, google, etc. as a 'work.' I could see a website in it's entirety as a 'work.' But the output of a service doesn't strike me as a 'work.')

</comment><comment><USER15> The EFF has been doing some good work on TOS abuse. <https://www.eff.org/issues/terms-of-abuse> I'm sure they would be interested because this linking policy is absurd. There is no way a practice like this would be 'illegal' anywhere but on Apple's app store where I imagine Wolfram Alpha holds at least a little sway.

</comment><comment><USER16> Please submit full URLs only. We like to know where we are going.

<comment><AUTHOR> Sorry. For the record: [http://blog.agiletortoise.com/post/3564424414/wolfram- alpha-...](http://blog.agiletortoise.com/post/3564424414/wolfram-alpha-doesnt- get-it)

</comment></comment><comment><USER17> I am sure with infinite money on both sides, if this were litigated, the OP would win. You have the right to write a computer program that sends an HTTP request to a site, even if the site's ToU say that you can't. After all, you can send a request without having ever read or seen the ToU.

The server should simply refuse to reply if the _user_ has not agreed to the terms of use.

Apple will do what Wolfram says, but that's because Apple is acting in its best financial interests (30% of $1.99 for WA's app), not because Apple is legally bound to not distribute an app that links to Wolfram Apple.

</comment><comment><USER18> These ToS clauses protect their paid iPhone app from being replicated in the browser, which is pretty much exactly what you did. So it is effectively _you_ who didn't get it :)

<comment><USER19> Which gets to the root of the Wolfram's real issue with it: If you go to wolframalpha.com on an iOS device, you are shown an ad for their $1.99 app (which you can ignore and continue to the mobile version of their site).

If you go straight to a query, it bypasses this.

The O.P.'s app bypasses their ad, and Wolfram doesn't like that.

<comment><USER17> The built-in web browser that Apple includes with the iPhone also violates this via its "bookmark" feature.

</comment></comment></comment><comment><USER20> Why doesn't Wolfram just block this? It would be a little bit of work, A naive solution is to use short-lived cookies. But there are more sophisticated means to ensure that users get to the result page via a query.

</comment><comment><AUTHOR> UPDATE: Wolfram listens and changes policy

[http://blog.agiletortoise.com/post/3587122629/wolfram- listen...](http://blog.agiletortoise.com/post/3587122629/wolfram-listens-and- changes-policy)

</comment><comment><USER21> It seems to me that agile tortoise doesn't "get it". Regardless of Wolfram Alpha's licence, it's Wolfram's decision as to what you can and can't do. That was made clear in the licence.

The bottom line is that Agile Tortoise didn't study the licence hard enough, if he had he would've seen that Wolfram Alpha wasn't the right fit for his tool. If he'd have looked further he'd have probably seen that <http://duckduckgo.com/> has an API that he may well have been able to use to get the same results.

Instead he may now have to modify his software and probably resubmit it to Apple for review.

Measure twice, cut once. This applies as much to software licensing as carpentry.

</comment><comment><USER22> The problem is twofold:

(1) semantics (fun for the whole family!) what does deep linking mean in this context? We all say deep linking is bad, but to some the pre-populated query isn't deep linking, but to others it is.

(2) one of the (entirely sensible) things the Wolfram Alpha guys seem to be saying is "please don't hook bots up to us". Now no doubt some will bluster and say that if it is there in public they have a _right_ to consume all the bandwidth and resources - after all if they didn't want people to do that they should just [insert complex but fragile technological solution that would quickly fail or be worked around]. As it happens, what this guy was doing falls into that category of automated client.

So on the basis of either one of those (if you squint real hard) I can see Wolfram Alpha's point of view.

</comment><comment><USER23> Not in defense of Wolfram Alpha, I'm just curious if W|A does this out of concern of possible degeneration effect on their search accuracy caused by programmed search queries? For a human user of W|A, he will construct the query with certain syntax, and further drill down the search query with W|A's recommendations. W|A may very well monitor the pattern of user search queries to optimize their search algorithm. It is possible that programmed search queries, especially coming from a third party application where users do not use the W|A like syntax, may "pollute" the usage pattern for W|A and affect their algorithm's efficiency. Just my 2 cents.

</comment><comment><USER24> They've always been pretty rent-seeking.

</comment><comment><USER7> I am not a Terminology user, and I do have the Alpha app on my iPhone. But I still think this is foolishness on the part of Wolfram. I am more likely to use W|A if I can click on a button and jump straight to the page I want, then if I need to switch apps myself and retype my query.

</comment><comment><USER25> Seems to me the author doesn't get it. Wolfram Alpha specifies terms of service, which the author didn't read and subsequently violated.

<comment><USER25> I find it amusing that people downvote my comment. I guess it is much more rewarding to upvote overinflated stories about how Evil Wolfram Alpha "Doesn't Get It" (often without reading the story, I suspect). Makes for better drama.

Frankly, I would much rather read about a 2-bit adder implemented using 36 555 timers.

</comment></comment><comment><USER26> this isn't surprising considering this is the same company that took over a year to release a free api: <http://news.ycombinator.com/item?id=2126037>

</comment><comment><USER27> You break the rules, you pay the consequences. Ignorance is NOT an excuse.

He's "in his situation" (edit) with Wolfram because he didn't do his due- diligence and contact them first before linking to them in his app.

EDIT: He seems to understand this, and admits that he "goofed", yes.

<comment><USER27> Lots of down-votes, but no replies. I can't figure out if the down votes are proving that I'm right or if I totally missed something.

<comment><USER28> Have you ever seen _The Big Lebowski_?

"You're not wrong, Walter. You're just an asshole."

<comment><USER29> Please don't call people on Hacker News assholes, even by analogy.

I think you might be attempting to say something quite relevant without intentionally calling the person an asshole, but if that's the case, you ought to have explained it in your post.

<comment><USER16> How about: there's a difference between _being right_ and _being polite_.

<comment><USER27> How about explaining either way what you don't find polite or right?

<comment><USER16> Note that I am not derleth.</comment></comment></comment></comment></comment></comment></comment>