Ask HN: What language should I develop in? - <AUTHOR> I'm currently working on an idea for a community management app and as I'm not technical. I was wondering what the pros and cons are of developing in a certain language. Languages that have been recommended so far include; Ruby, PHP and Python.
Any advice would be greatly appreciated.
If you're interested, here's the app I'm developing: http://getnudge.co/ <comment><USER2> Great to hear you're rolling up your sleeves and going to give developing it yourself a go.

I taught myself to program using PHP, then moved to Rails, and now do mostly Javascript and Node work.

There are a few things to consider. Number one, you're absolutely going to need a front-end, which means you're going to need to learn javascript, and probably use a framework like backbone, angular, or ember. Personally, I think knockout may be the easiest of all of these to 'pick-up', but none of them (I don't think) are going to be easy as a beginner.

At first, I'd suggest your back-end can wait. You can use parse or firebase or one of the other back-end as a service providers to manage your data. Just make sure you're able to get it back later.

Now, if you're adamant about doing the server-side stuff, I'd say go with Ruby-on-Rails, which is a framework for making it easier to build and manage an application written in Ruby. The framework does a lot of stuff for you, and you can host it on heroku fairly easily.

A few good things about Rails (I haven't used other frameworks like Django (Python) or Larvel (PHP)), is that it forces you to have a program structured in such a way that if you bring in another developer at a later date, they should be able to find their way around your code base fairly easily. That's what got me to make the switch, I was doing a contract I knew I wouldn't be working on long-term, and new that a rails app would be easy for somebody else to step in on.

<comment><USER3> > probably use a framework like backbone, angular, or ember.

Absolutely, do not do this. Just use jQuery at first. Don't use a framework until you experience WHY you need a JS framework.

<comment><USER2> That's a good point jeopour. A framework can also make things more complicated, but they are good for learning how to structure your programs. What would you recommend for learning structure.

<comment><USER3> There are a lot of excellent resources online such as blog posts or open source projects on github, but the way I learnt was by reading a couple books people had recommended me. I also took patterns commonly found on the server side of things and implemented in a way relevant to my client side code.

Let me know if you need some recommendations!

</comment></comment></comment></comment><comment><USER4> One of my friends wants to learn how to code, and asks me where to start, and what language (PHP? ). I always tell them; well think of something you want to solve first, smaller problem the better. Then google how to work out that problem. If they can't do that; (i.e. they do not make any attempt! ) , I won't invest anymore of my time because they clearly lack the mentality to do it.

I started with PHP (3 back then) because I had built (copy paste amalgamation) a website, and I didn't want to maintain all these html files, so probably altavista'd something in the lines of "how to include other page into page html" . I know back then I was also messing with Newsdesk, which was CGI/Perl, and remember adding some fields to the whole thing so my buddy's could post their Warez uploads on there.

I actually ended up with one of the biggest Warez sites in the scene at that time. I actually had mostly no idea what I was doing. And there was no Google back then. Altavista ruled the market.

Anyway what I'm going to is: If you do not have this mindset, you will probably not make it as a programmer. And that's ok, because maybe you have different goals. Just make sure you understand what you want to do.

There are a huge amount of musicians who probably never imagined being great or a rockstar, they just liked playing music and figured out how.

Last note: if you're picking between for example "PHP" , "Python" , "Ruby" I would definitely start working with a framework, because it will help you start off the right way; using a design pattern and command line tools.

</comment><comment><USER5> If you want to be a developer, you should aim to learn one new programming language a year, at least to the point where you can understand the strengths and weaknesses of the language. High-level languages like Ruby, PHP and Python are all good. At some point dive into functional, and at another point go a bit lower: C, perhaps.

However if all you want to do is build this one product, then you need to evaluate which framework is easiest to get started in. So, choose a feature and build it in a few different frameworks and decide which one clicked for you.

My recommendation is to try Rails, Django and CakePHP. If you're feeling brave, Meteor (in Javascript) is worth a look. Figure out what worked for you, and what didn't and make the decision from there. You might like Ruby but hate Rails: try Sinatra. You might love Javascript but hate the conceptual building blocks of Meteor: try Node.js. And so on.

There is a lot of personal preference going on here, and I presume this is for now a side project so your focus should be on having fun. I think if you can get your head around it, Rails will be the one that gets you the fastest from "I have this idea" to being able to use it.

</comment><comment><USER6> The technology choice is a consequence of your needs. If it is a one page web app maybe node.js + JS-framework-at-your-choice, or Rails + Angular.js are good options; if it is a "classic" web app there's plenty of options: Rails, Django, Play (a Scala framework), PHP, Haskell, it's up to your tastes (I would seriously consider Yesod for example, an Haskell web framework); if it is a normal app Haskell, Java, Scala, C, Python/Pypy, Ruby, ...

I suggest you to choose some options, play with them for a short time (2 days - 1 week), and finally go for one of them.

</comment><comment><USER7> Don't go with PHP. It's obsolete and obscure programming language. Look at Python (Flask), Scala (Play Framework). Tool selection is important. Do not listen to those who say that it does not matter.

<comment><USER8> PHP might be a lot of things, but 'obscure' isn't one of them.

<comment><USER9> By obscure they must have meant, 'yet still ubiquitous'

</comment></comment></comment><comment><USER10> The language is not important. There is another factor that is way more important:

Do you know people using one of the languages? If yes, you could ask them about problems you have. Will be easier than going to stackoverflow.

</comment><comment><USER11> Real answer: depends how much you want to become technical.

Mostly real answer: Ruby, PHP and Python are fine choices. Avoid Java, C++, or C#.

Relevant answer: Assuming you want to get something done before "becoming technical" (if ever) Python, by a wide margin - but more than that, you have to pick a framework to work in: Django, Web2py are the two I'd recommend looking at.

Far out answer: Look at Tersus.com - If your app fits tersus (and many do, at least in their prototypical/MVP stage), you won't have to program anything, you'll just have to draw an annotated diagram.

<comment><USER12> >Avoid Java, C++, or C#.

Can I ask why? I'll fully admit to being a C# "fanboy", as they say, at this point in my career, but that's because it has so many features and syntactical constructs that are amazing and that I simply NEVER encountered elsewhere in my schooling, internships, or career. I simply feel more able to turn my actual ideas of what I want the computer to do into code with C# than anything else I've used, including Python (distant second) and Ruby.

<comment><USER11> Op said he is not technical. C# is a fine language, but not if this isn't your profession. Python is.

<comment><USER12> Fair enough.

</comment></comment></comment></comment><comment><USER13> It's a little bit like asking which color you should like. A lot of main stream programming languages are very similar in capabilities but differ in some of the details on how they express this, i.e. the syntax. The programming languages you end up choosing probably has a lot to do with how appealing the language and the ecosystem around it is to you.

You might want to try a few languages such as Python, Ruby, PHP, Javascript, etc. I would suggest to focus on the language first and then the frameworks.

</comment><comment><USER14> Start with anything that takes you to an MVP fast. You probably will be iterating months with this until your solution needs a re-thinking or pivot: you don't need to change your lang right now.

It happened to me 3 times the same way: we started with X in a year or 2 we ported to Y.

Personally, I would go Ruby or Python, they're pretty much solid, lots of devs around. Then, if you have the need to scale: i loved Erlang, but I like also Go a lot.

</comment><comment><USER3> It sounds like your are not so interested learning to programme but rather it is just a means to building this project you have in mind.

That being said you should just choose a popular web framework like Ruby on Rails or something like CakePHP. This means that any problem you run into will have been encountered and solved by someone already and you can pretty much just Google your way to a half decent prototype.

<comment><AUTHOR> Hello, thanks for your reply. You're correct, my main aim for this question was to understand which language may be best to get the app developed in.

I'd love to learn a language too, and eventually be able to develop/maintain apps myself. But for this project, I won't have time to learn.

Thanks for the feedback.

</comment></comment><comment><USER15> Real answer: it doesn't matter. Pick one and go.

It takes 3 months to get okay with something. 6 months to be decent. 9 months to be like, okay, I kind of get this, and then at the end of the year you'll probably change your mind and try something else.

I tried PHP, it was easy. Too easy. Hated it.

Tried Ruby, then Rails came on the scene and it became cool. Ended up hating it too.

Now I'm on Python. Learned Django. Tolerating it, but switched to Flask.

What I really want to master is JavaScript, closures, then node.js and AngularJS.

Just start. You can switch after. And to be real, making websites is actually really easy with any of the languages. Whatever you're thinking of doing there's probably already ten other projects on Github that has redone what you're thinking of that you will end up using.

It's the deploying, that perfect minute customization that you really, really, really want, scaling, and long term maintenance that's going to be tough.

<comment><USER16> I started off my Python adventure in Flask, and now pretty much use Django for everything - I found that when I used Flask, I'd essentially just start re- implementing Django.

Also, Django REST framework is utterly amazing for building APIs.

<comment><USER17> +1 for the Django REST Framework. However, I'm not a huge fan of Django's ORM.

<comment><USER18> +1 for not being a huge fan of Django's ORM. :)

</comment></comment></comment></comment><comment><USER19> C#. It's a modern multi-paradigm multi-type-system language.

Best choice if you can get Visual Studio (paid) along with ReSharper (paid).

Will let you target all mobile platforms via Xamarin (paid) (since you want to develop an app as opposed to a website).

If you want to get a prototype quickly rather than focus on code quality then one of the purely dynamic language options would also be OK.

<comment><USER20> Do you know of some open source project/application which can be useful in learning C#?

<comment><USER19> Depends on your objectives and situation.

1) gamedev => MonoGame 2) business (SQL DBs) => NHibernate 3) web => SignalR

I personally never learned by participating in OSS but times change.

</comment></comment></comment><comment><USER21> All three can get the job done, have tons of resources and extensions available, very active communities, proven reliability and infrastructure available, with a similar learning curve.

If you have a friend that can help you when you're stuck in any of these languages it would be a good reason to choose one over the others.

</comment><comment><USER22> For me it's about the community. Every language has a different mindset / way of approaching a problem. Read some groups, have a look at the various packages on github and see which community fits best with what you're personally doing.

Having contacts / friends who could help is also an advantage.

</comment><comment><USER23> Use whatever you're most comfortable with.

</comment><comment><USER24> Cool site, rendered well on my iPhone except the top logo which was a bit blurry on a retina screen.

Keep it up

<comment><AUTHOR> Thanks so much :) I'll take a look at the logo and see if there's anything I can do with it.

Appreciate the feedback. Is it something you'd personally use?

</comment></comment><comment><USER25> Which ever you are the quickest programming in. Lets face it time is money.

</comment><comment><USER26> You cant go wrong either with Rails(Ruby) or Python (Django),they will help you develop your app quickly and both solutions are fun to use. I personally prefer Ruby while Python is easier to deploy on a server. But you'll attract more data scientists with Python when your prototype is mature.

PHP : while easy to learn, i would not recommend it.It's an old badly designed language that has little future outside cmses.I only use it to customize CMSes today,i would not develop any app from scratch with it, furthermore writing PHP is awfull compared to Ruby and Python.

NodeJS: While Javascript everywhere seems like a good idea(you'll have to learn Javascript to script the browser anyway), NodeJS use async programming , and async programming is hard,no matter what people say, furthermore Node is not mature yet, especially its libraries.

Java(JVM):If you have time try it(Spring/Play/...). It will feel hard and verbose but You'll learn a lot of interesting concepts. If you want to code a prototype quickly forget about it. And Java has a lot of very good and mature librairies.

So if you want to develop an app quickly and you care about how your code look like, go with Python or Ruby. If you have more time go with the JVM.

Also check basic informations on these topics :HTTP,Rest,OAUTH you'll need them pretty quickly if you want to interact with Twitter.

<comment> h-go While I agree that PHP is a badly designed language, I disagree that writing PHP is awful. You can make PHP beautiful. OO PHP and using MVC makes things way more easy to handle.</comment></comment>


YouTube stars: 'The most fun job imaginable became deeply bleak' - <AUTHOR> https://www.theguardian.com/technology/2018/sep/08/youtube-stars-burnout-fun-bleak-stressed <comment><USER2> This is a dupe [https://news.ycombinator.com/item?id=17947157](https://news.ycombinator.com/item?id=17947157)

<comment><USER3> Thanks. Also, so many guardian stories all of a sudden.

<comment><USER4> No more than usual, I think? [https://news.ycombinator.com/from?site=theguardian.com](https://news.ycombinator.com/from?site=theguardian.com).

</comment></comment></comment><comment><USER5> They should be grateful that it works like that. If they keep having to work hard to stay on top, it means that the algorithm is working. It would be be great if the rest of the world worked like this instead of the rich-get-richer situation that we have now.</comment>


24 Times Less Memory, 11 Times Faster than ElasticSearch/Solr - <AUTHOR> http://www.sirendb.com/blog/comparing-siren-v1-2-and-lucenes-blockjoin-performance-a-uspo-granted-patent-search-scenario/ This is a detailed description of the benchmark tests that we conducted to compare SIREn's performance relative to BlockJoin with respect to search on nested documents. The BlockJoin approach is used in both Solr and ElasticSearch to support nested document search <comment><USER2> Just tried. Very fast and easy to use! Strongly suggested.</comment>


Ask HN: Review my video startup, mixy.tv - <AUTHOR>

Hey guys,<p>Me and a couple of buddies started a video aggregation site a few months ago called mixy.tv.  We are actively looking for beta users and just recently opened it up out of private beta.  We would love any feedback specifically in relation to user flow and UI.  Do you guys find our layout appealing and an enjoyable way to find new interesting videos?  We also would love any feedback on how useful you think it is to log the videos you watch in order to share those with your friends and followers on mixy.  Really appreciate any time and advice in advance!<p>-Andrew <comment><USER2> Critical feedback up front:

Before signing up, please note that the demo video (which looked pretty, and I should have paid more attention to) when played in Chrome never successfully exited for me, i.e. the sign up elements continued to be hidden (yea, made sure it wasn't full-screen). I tried zooming in and out, pausing and playing the video. I did not investigate the DOM. A refresh restored the initial state and after signing-up I haven't revisited to play with it more.

Signing up felt a little like "hunt for the link that leads to the behavior I want". After clicking "Sign up with Facebook" at the bottom left and then telling Facebook I didn't want to give your app all of the requested permissions it aborted, but when I initiated Sign Up from the Login link at the top right, chose to use Facebook, and denied the app requested permissions, it rolled along.

I went through several of the videos and didn't see any with comments yet. I noticed that you're not linking back to the comments on the original site, and can understand there being several reasons for that, but I do wonder if there will be any integration with Twitter, Facebook, and Google+ for the comments that originate in mixy.tv? Do they get re-posted to those other services, with hashtags for Twitter, so that followers from those services are tempted to join mixy.tv and become part of the fun?

Besides crowd-sourced tagging and filtering, are there any plans to create recommendations?

Since I am not following anyone else that is using mixy.tv yet, is the "People I Follow" link supposed to show people I follow on other social networks, and will I also be able to follow people just through mixy.tv in case we're coming from different walled gardens?

One feature request would be to enable bookmarks within videos, with their own urls, so users can comment on specific points in the video, and link directly to the frame they're talking about.

Finally answering your questions:

Overall the site looks clean, the layout after signing in makes sense.

I'd like to thank your service for revealing this video to me: [http://mixy.tv/posts/ea5c3e/this-dude-loves-his-job-best- cot...](http://mixy.tv/posts/ea5c3e/this-dude-loves-his-job-best-cotton-candy- maker-ever)

However, I need some help seeing the added value in general over my current means of finding videos. It appears the primary means to find videos is either manually searching or from the people I already follow.

By the way, is the List functionality enabled? The dialog says I created one, but then I can't find the list I created.

<comment><USER2> Sorry, quick p.s. after playing with it a little more. I found my new list under my user profile page. So, I need to create a new list with the link up top, then figure out that RePost at the bottom right really means Add To A List. Then, if I go to my own profile I can see my list, and can remove videos within it, but I haven't figured out how to remove the list itself yet. Now that I know all of this I can remember it, but I mostly figured it out by clicking random buttons. The user should be able to grok it from the labels and relative positions.

<comment><AUTHOR> Really appreciate all the comments here. We have been focusing on making the service more intuitive so a lot of your feedback reaffirms our need to to that. We are connected to open graph but have not fully built out the Twitter or Google+ share yet but that is a great idea. Thanks again for signing up and look out for some changes in the near future. Until then any additional comments are more than welcomed!

-Andrew

</comment></comment></comment><comment><USER3> I work for a competitor to you but I don't mind helping you out a bit.

A - Your install flow is bad, just let people use the app if they've given you a facebook auth. You want to remove steps to the funnel.

B - Do not ask for the publish_stream permission, ask for publish_actions instead. The advantage of publish_actions is that it appears on the first auth page, and not the extended permissions page. You can do almost everything that you need to do using publish_actions that you can with publish_stream. Do not ask for both though, or else they will both be on the extended permissions page.

C - You must get Open Graph going ASAP.

I can describe some wrinkles to publish_actions v. publish_stream, just ping me.

<comment><AUTHOR> Hey idoh!

We are looking into the Facebook sign up user flow right now but thank you for bringing that to our attention and for the recommendation to go the publish_actions route.

In relation to Open Graph we actually do have that built out and there is Facebook timeline on and off feature in the top right. Was it not working properly for you?

Thanks, Andrew

<comment><USER3> That confuses me a little bit. When I think of Open Graph, I think of making a custom action verb, or using a built in one like "watch". As far as I know you can't post open graph actions without getting the publish_actions permission. So I'm guessing that by open graph you mean publishing stories on the user's timeline using publish_stream, which is the graph api but not open graph.

I can see how you could publish events as stories using publish_stream, but Facebook wants you to use Open Graph / Actions for that and gives benefits for using open graph actions instead of publishing stories.

<comment><USER4> Hey idoh,

I'm one of the developers at mixy.tv -- we are indeed asking for publish_actions and using open graph to publish video watches and likes. However, we use publish_stream for adding a video because we found that it shows up more often in the news feed as opposed to being shown in the ticker on the right of the FB home page.

I think you have a good point though about publish_stream being in the extended permission screen, however. I know you mentioned working for a competitor, so you don't have to answer this if you don't want to, but -- have you guys seen better conversion rates for signups or better share rates by using Open Graph actions explicitly as opposed to a combination of publish_stream and publish_actions?

<comment><USER3> Here's a couple observations:

I've tried the app with a couple test users, I don't see the publish_actions permission come up. I'll assume you are correct though, but you might want to make sure that this is the case. For answering I'll assume that you are correct. Asking for only publish_actions is the way to go, I have metrics on it, but I can prove it mathematically / logically, so I don't have to use stats for it....

\- publish_stream always gets asked on the extended permissions page

\- publish_actions will get asked on the first page, except if you ask for publish_stream too, in which case both show up in extended permissions

\- when you make a story post, you don't get to decide under which permission to do it, Facebook just check to make sure that you've the proper permissions.

\- if a user has given publish_stream, then the stories are visible to the posting user in their newsfeed.

\- if a user has publish_actions, then that story is NOT visible to the posting user in their newsfeed, but their friends can see it, and they can see it on their timeline.

\- if you have both perms for a user, then when you make a post on behalf of that user, Facebook will make it in the style of a publish_action story, so the posting user won't see it. So to a practical effect, it is not really useful to have publish_stream if you already have publish_actions.

So, given the above observations about Facebook and applying it to your case, because you are asking for both perms then they both are on the extended permissions page. Because you have both perms, when you post a story it is going out in the publish_actions style.

If you look at the funnel, it is:

Current: sign in with FB > regular perms > extended perms > signed in.

Proposed: sign in with FB > regular perms > signed in.

The proposed solution is better because:

\- it removes a step in the funnel. You probably have double digit drop off from one step to the next, so that helps dramatically with virality.

\- publish_actions moves from extended to regular permissions, so you get that earlier

\- you don't lose anything by not having publish_stream, because if you have publish_actions then your story posts are done like publish_actions and not publish_stream, so it is a perm that you aren't really using or need.

The con of the proposal is that publish actions requires a token, and the token expires after 60 days if the user doesn't come back. Internally I've found that stale users like that aren't that useful as a viral channel anyway. So it isn't really much of a con.

<comment><USER4> To clarify, publish_stream is a superset permission that includes publish_actions. That's why you're not seeing it.

While I agree with you that it removes a step in the funnel, we still need read_stream to provide our advertised service, that is pulling videos that your friends post on Facebook. read_stream is also an extended permission so we can't get around that additional screen anyway.

However, I've read that less permissions means a higher conversion rate so we may experiment with removing publish_stream and only asking for read_stream + publish_actions and we'll see what happens.

Thanks for all your input!

</comment></comment></comment></comment></comment></comment><comment><USER5> So, I like the idea! I share a lot of videos on facebook but their present UI makes it super hard to only check out videos. You seem to kind of address that.

I do think you can improve your messaging. I _kind of_ knew what you offer but not really until I signed up. One way you could pitch this is show a screenshot of a facebook newsfeed on the left and a screenshot of Mixy on the right going through that feed and picking out all the videos. Of course, make those sample videos in the screenshot seem very compelling and bait-ish.

Edit: Dude, put a huge link that just shows all the videos _I've_ shared on facebook. That itself would be extremely useful to me.

<comment><AUTHOR> Hey Zaidf,

Yea we are working thru the site being more intuitive and making it simpler to explain how to use the site in general. I love the videos I've shared on Facebook idea. We'll put it in the que!

-Andrew

<comment><USER5> Awesome! Jenny told me about your site some time ago :) Good to see it on HN.

Another thing - when I click play, it's not apparent that it's a modal and there is an 'X' on top left. I thought you were taking me to a new page. May be reduce the opacity of the background or put a larger 'close' button at bottom center?</comment></comment></comment>


Tech recruitment: how not to do it - <AUTHOR> http://seldo.tumblr.com/post/10140794798/tech-recruitment-how-not-to-do-it

<comment><USER2> There's a great way to beat them. Apply for the job. If you don't get it, sue them saying they didn't hire you because of your sexuality. Use this email from the recuiter to show that they are clearly not an equal opertunities employer. Hopefully the recruiter will now no longer be employed (by anyone).

Or alternatively go into the job interview, and make lots of homophobic/sexist/racist jokes there (e.g. "Good to see you keep the fags out and the skirts in the typing pool! My kind of company!"). If they act a bit suprised/embarrassed, point out the recruiters email, and tell them that recruiter will attract that kind of applicant.

<comment><USER3> Actually in the US it is not illegal to discriminate based on sexual orientation. There may be laws in New York state prohibiting it, I don't know. But in most of the US it is totally legal to post a job listing saying "Programmers wanted. No fags allowed."

It is pretty despicable.

<comment><USER4> There is, and ought to be, a difference between 'wrong' and 'illegal.'

<comment><USER5> This, this, a thousand times this!

The only thing the government can do to effect change in the actions of the people in the world is by the threat of jail if you do (e.g. steal) or do not do (e.g. pay taxes) something. That's all they can do.

For every problem the government "fixes", someone is losing a freedom or liberty that they once had.

For almost all of the problems in the world caused by the behaviors of humans, more laws are almost never the solution.

</comment></comment></comment></comment><comment><USER6> Beau has been around a long time. I remember him posting jobs to the jobs.perl.org site and perl jobs list years ago (back in 2001). We had to ban him for similarly bad behavior.

I'm amazed he's still around.

<comment><USER7> hum, just last week he was trying to create a page on job4dev to post "listings" with no information whatsoever about any of the actual companies that were hiring. Usually our moderation system is enough to stop recruiters to add vacuous pages to the wiki. But he went ahead and start spamming the comment pages anyway.

Sometimes I wonder if it would be possible to add to job4dev a service that would turn recruiters into a value-add into the recruiting space. But that kind of thing just goes to show that they just want to work as middlemen and really need to be cut out.

<comment><USER8> Did you ever consider the possibility that "Beau" is not actually a recruiter, but rather a mid-level troll with a creative cover story?

<comment><USER9> What, like Jon Harrop?

</comment></comment></comment></comment><comment><USER10> Sketchy in a lot of ways.

His LinkedIn profile has stars around the name <http://www.linkedin.com/in/opensourcestaffing>

He also has every state in the nation listed twice (postal code + full state name). SEO bait I guess.

It seems surprising to me that some of the fairly big companies listed on their website (eBay, Disney Internet Group, Rapleaf, Shopzilla) would engage with someone so visibly awful. <http://open-source-staffing.com/clients.html>

<comment><USER11> Fairly big companies often have surprisingly minimal filters for "visibly awful." Passing due diligence is easy when the process does not include common sense, and individual managers are likely to have misaligned incentives.

</comment></comment><comment><USER12> The moral here has way less to do with tech recruiting than it does with just being a civil human being.

</comment><comment><USER13> My guess is that someone has already taken matters into his/her own hands, check out his blog (redirected to from Beau's domain mentioned in the post):

<http://opensourcestaffing.wordpress.com/>

The latest post is (probably) not of his own doing I would say.

<comment><USER14> His blog is now marked as private and requires a login

<comment><USER15> Here's the Google webcache

[http://webcache.googleusercontent.com/search?q=cache:TQGS39z...](http://webcache.googleusercontent.com/search?q=cache:TQGS39zMlekJ:opensourcestaffing.wordpress.com/+http://opensourcestaffing.wordpress.com/&cd=1&hl=en&ct=clnk&client=ubuntu)

</comment></comment></comment><comment><USER16> Sometimes I wonder if I'm wasting my time. Idiots like this will never be entirely eradicated from the industry.

Maybe my next blog post should be a direct attack on recruiters, calling them out on there bullshit attitudes and illegal tactics.

</comment><comment><USER17> Just because sexual orientation is not a "protected class" on a federal level, employment laws in nearly every state are very clear that in addition to the protected classes, you can not discriminate arbitrarily.

But it doesn't matter, in New York (SONDA) and just about every blue state has very clear anti-discrimination laws when it comes to sexual orientation.

And of course, regardless of the laws, nobody would allow this person to represent them or work for them.

This guy needs to be terminated immediately, his behavior is totally disgusting and reprehensible.

</comment><comment><USER18> I do hope that whoever knows him personally points out just how unprofessional those emails were.

<comment><USER19> "whoever knows him personally" = "their boss"

"points out just how unprofessional those emails were" = "fires them"

?

<comment><USER18> I'm more hoping a good friend would tell him, "Beau, stop it. You're being a dick." Firing him will not stop his behavior.

<comment><USER20> People like that tend not to surround themselves with friends like that.

</comment></comment></comment></comment><comment><USER21> I'm glad Gould got called out on this; he probably just lost himself a lot of future business by being so cocky.

<comment><USER22> Called out on Hacker News and similarly hacker-y circles... that's not exactly the "$50K in NYC" demographic.

<comment><USER21> well if anyone googles his name, this will probably come up, right? I hope most people would be smart enough to do that before buying his services.

</comment></comment></comment><comment><USER23> The Xbox-Live approach does not strike me as the prudent course of action for trying to recruit others for your cause. Even when actually on Xbox Live.

I've questioned how some recruiters that I've dealt with had jobs, but never had one remotely reached this kind of level of fire-him-now-ness.

</comment><comment><USER24> Nice, website now 404ing and blog is private.

[http://webcache.googleusercontent.com/search?q=cache:JqLMFQ-...](http://webcache.googleusercontent.com/search?q=cache:JqLMFQ- Gwn4J:open-source-staffing.com/clients.html+http://open-source- staffing.com/clients.html&cd=1&hl=en&ct=clnk&gl=uk)

:)

<comment><USER25> Huh. I'm curious why. The splash page still loads, but none of his links (contact, about, jobs...) work. All 404

</comment></comment><comment><USER26> This is also our problem in our local python users group [http://groups.google.com/group/pinoy-python- users/browse_thr...](http://groups.google.com/group/pinoy-python- users/browse_thread/thread/beabfa95f98e6624) , situation is like this:we have a conversations to help someone with their errors and the next thread reply/post is all about job posts! So I built them a simple job portal.

</comment><comment><USER27> This guy is all over the NYC tech recruiting scene. I have some 20 emails from him over various tech mailing lists. Funny thing is, even though I see 4 or 5 emails a day from recruiters, his name is so unique I actually remembered him! I don't think people should be crucified for single outbursts, but it's safe to say that this guy is on a tear and needs taking down.

</comment><comment><USER28> Yeah, not all that surprising. He frequently adds posts to the NYPHP email list as well, and they just come off as.. less than legit. Even still, this is rather poor form.

</comment><comment><USER29> <https://twitter.com/ossjobs> what a jerk</comment>


The IPO Market Fails to Die - <AUTHOR> http://techcrunch.com/2015/11/19/the-ipo-market-fails-to-die/ <comment><USER2> Stock investing and raising capital as spectator sport. Complete with peculiar spectator sport journalism. I imagine the set of people who care about "perceptions" of how a stock does on the day of the IPO will be extremely narrow. The effect on the business fundamentals is going to be nonexistent. And in a few years' time, the share price will have taken on a life of its own, independent of the IPOs fading memory -- do _you_ remember 18 May 2012?</comment>


Fable.Remoting – Automated, stateless, typechecked JSON APIs in F# - <AUTHOR> https://github.com/Zaid-Ajaj/Fable.Remoting/blob/master/README.md <comment><AUTHOR> WebSharper does also something similar -> [https://developers.websharper.com/docs/v4.x/fs/remoting](https://developers.websharper.com/docs/v4.x/fs/remoting)

Are there similar ideas/libraries implemented in JS/TS as well?

I am quite drawn by these ideas, as they remove some overhead in making a fronted+backed application and somewhat bridge the productivity gap between a SSR solution such as Django or Rails, and a traditional server API + front end by allowing a fully integrated development and automatic but safe API generation</comment>


Team reveals genomic history of ancient civilizations in the Andes - <AUTHOR> https://news.ucsc.edu/2020/05/fehrenschmitz-andes.html <comment><USER2> I'm an undergrad research ~intern for one of the professors on this paper! :)

Edit: I've been corresponding with Professor Fehren-Schmitz of the Human Paleogenomics lab at UCSC for the past few months and will likely be focusing on improving computational workflows at the lab in the next few months. One recurring theme I've noticed in paleogenomics research is that the people who do the actual paleogenomics aren't always the same people who develop the computational genomics/bioinformatics tools [1], meaning there might be a bit of a disconnect between those two fields. My understanding of computational paleogenomics is still pretty rough, but it seems to me like a lot of the tools still have a ton of room for improvement.

[1] Patterson et al., 2012 (Ancient Admixture in Human History)

<comment><USER3> [1] That paper brings back memories! Back in 2011, I was chatting with Nick about admixture and graph theory when it dawned on me that he was effectively trying to solve the Steiner tree problem. Knowing that his formulation of the problem was intractable provided a little nudge in the right direction.

It's also worth mentioning that (long) before joining David Reich's lab, Nick Patterson worked at GCHQ where he was famously mentor to Clifford Cocks. The story goes that Nick threw an unsolved asymmetric cryptography problem at Cocks and he came back in the morning having invented RSA.

<comment><USER2> Oh wow! Super interesting to see how all these fields weave together like that. There's a joke to be made somewhere here about graph theory too.

</comment></comment></comment><comment><USER4> [https://giphy.com/gifs/brick- mansions-c2X9dXyMh6Pug](https://giphy.com/gifs/brick-mansions-c2X9dXyMh6Pug)

<comment><USER5> Not here please.</comment></comment>


IBM releases Elm-powered app - <AUTHOR> https://discourse.elm-lang.org/t/ibm-releases-elm-powered-app/2364 <comment><USER2> In a comment below the main post they say that the app they wrote is approximately 45,000 lines of code over 170 Elm files.

That's one of the largest (and apparently most useful) Elm apps in the wild that I've heard of, and the fact that it exists and they had an overall good experience with it inspires me even more to try to learn and use Elm.

<comment><USER3> > In a comment below the main post they say that the app they wrote is > approximately 45,000 lines of code over 170 Elm files.

One thing I've found a bit weird about the Elm community is how common it is to highlight or even brag about the size of the codebases.

One of the reasons I have come to particularly enjoy Clojurescript on the front-end is because of how much code I _don 't_ have to write. I once ported an Elm app to Clojurescript and it was only one-third the line count for the same functionality, and generally a smoother experience.

I think some developers just love building up these huge, complex worlds and living inside them, and then telling others how big those worlds are.

<comment><USER4> I think you should read this as being an otherwise 150kloc project in Java.

Seriously, at this point IBM should fork a couple hundred thousand dollars just to know how anyone on their staff can recreate this in idiomatic java (or whatever OO language they want) and have you do it in idiomatic clojure/script. I'd be surprised if you managed less than 30k and very surprised if the OO implementation managed less than 100k.

Hard data on this kind of debate being hard to come by, we'd learn something from the experiment.

<comment><USER5> In this comparison of a minimal "real world" app comparison, Elm version has around 3 times as much code as ClojureScript.

[https://medium.freecodecamp.org/a-real-world-comparison- of-f...](https://medium.freecodecamp.org/a-real-world-comparison-of-front-end- frameworks-with-benchmarks-2018-update-e5760fb4a962)

<comment><USER6> An apples and oranges comparison. Any difference would surely be made up by all the tests one would have to write to be sure the clojure code was free of basic errors.

<comment><USER5> That's a completely baseless assumption. I have not found the need to write any more tests in Clojure than I have in statically typed languages. The only tests my team ends up writing tend to be end-to-end specification tests, and you would want to have those in any serious project regardless of type discipline.

<comment><USER6> Tests prove the presence of bugs not their absence. You _should_ be writing more tests if you have no static type system, in order to find the bugs that you would otherwise prove don't exist.

<comment><USER7> A static type system like Elm doesn't fix logical bugs like wrong indexing, wrong predicate etc, it just finds issues with types. Types do not contain the real logic of your program. Types are somewhat useful for verifying data is passed around in the correct shape in a program, but to say it prevents most obvious errors is naive. Not to mention in Elm you will waste tons of time doing useless tasks like writing encoders/decoders and code that could be moved to macros in a more powerful language.

<comment><USER6> > A static type system like Elm doesn't fix logical bugs

Static type systems _can_ absolutely catch logical bugs! Proof that a list is non-empty or that a reference is never null are simple examples.

> Types do not contain the real logic of your program.

Types can completely determine the logic of many parts of your program. In Haskell, I often don't have to write custom traversal code, it's selected for me based on the types.

> Types are somewhat useful for verifying data is passed around in the correct > shape in a program

This is only the start of what types can do, try learning Haskell.

> but to say it prevents most obvious errors is naive.

No, naive is dismissing static type systems to the point that not even extra testing is done to compensate.

> Elm you will waste tons of time doing useless tasks like writing > encoders/decoders and code that could be moved to macros in a more powerful > language.

Elm's aim is to be a basic easy-to-learn language (no operator overloading etc). Personally, generic (polytopic) programming feels like a more elegant approach than macros. Haskell offers both.

<comment><USER5> Haskell was my first FP language, I used it for about a year, and worked with Scala briefly after. My experience is that you're really trading one set of problems for another in practice. Static typing can guarantee that you avoid a certain class of errors, but it often results in code that's longer and more difficult to understand opening opportunities for different kinds of errors. There is absolutely no empirical evidence to suggest that the trade off is strictly superior in practice.

Static typing can catch inconsistencies at the cost of structuring your code in a way that the type checker can understand. This is often at odds with making it readable for the human. A proof only has value as long as the human reader can understand it. Here's a concrete example of what I'm talking about: [https://github.com/davidfstr/idris-insertion- sort/blob/maste...](https://github.com/davidfstr/idris-insertion- sort/blob/master/InsertionSort.idr)

An insertion sort written in Idris has over 250 lines of code that you have to understand to know that it's implemented correctly. A python version would have about 10 lines or less. I'd have much easier time guaranteeing that the 10 lines do exactly what was intended than the 250 lines of type specifications. Of course, you could relax the type guarantees in Idris as well, but at that point you accept that working around the static checker has benefit and it's just a matter of degrees of comfort.

In general, the more constraints you specify via types the more of your program logic moves into type specifications. What this really means is that you're writing a metaprogram that emits your logic. However, there's no automated checker for that metaprogram that you wrote using the types. You still have to understand it to be correct in order to know that it's doing what you want it to. At this point you're basically living in a programmer version of the Plato's Cave.

The real question is not whether you can do something using a static type system or not. The discussion has to center around how that compares to alternative approaches such as testing, gradual typing, and runtime contracts.

<comment><USER6> Sorting (TimSort) was broken for many years in Python. It was good old- fashioned logic and theorem proving, not tests or runtime assertions, that got it fixed. There is merit in proving properties of any critical implementation, no matter how difficult. However the gist you referenced looks to be someone's learning effort, so hardly a model example.

Your view on the role of types is unfortunate if you think term logic is simply mirrored at the type level (Plato's Cave). The Curry-Howard correspondence tells us to think of types as logical propositions with terms as their proofs.

<comment><USER5> Sure, you can use formal methods to prove properties that are hard to test. The point you seem to have missed is that it takes a lot of effort to do that.

The reality is that in most cases there's a cost benefit analysis regarding how much time you can spend on a particular feature and the strength of the guarantees.

>The Curry-Howard correspondence tells us to think of types as logical propositions with terms as their proofs.

Hence my point that you end up writing a metaprogram that emits the logic. Ensuring that the metaprogram is correct is a manual process. The more complex the proof, the harder it becomes to understand.

Consider Fermat's conjecture. It's trivial to state it, it's trivial to test it to be correct for a given set of inputs. However, proving it for the general case is quite difficult, and only a handful of people in the world can follow that proof.

<comment><USER8> > onsider Fermat's conjecture. It's trivial to state it, it's trivial to test > it to be correct for a given set of inputs. However, proving it for the > general case is quite difficult, and only a handful of people in the world > can follow that proof.

This is a strawman, conventional static type system can't prove all general cases either and no body is saying that they do that. Yet, they being a superset of dynamic typing, they allow to have the same expesiveness as such by providing a bypass like 'Object' or 'any'.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER3> Now that we have ReasonML, which has a more predictable and sustainable release cycle, and large support, as well as functional programming from OCaml and smoother JS interop when that's desired, what does Elm still bring to the table? When Elm was originally developed, there wasn't a viable alternative for those who wanted good statically-typed FP in the browser, but it would seem now that new apps in this style of development have far more choices with generally fewer pain points.

<comment><USER9> I would take F# + Fable over Reason since Reason doesn't have computation expressions or do-notation

<comment> a-saleh I think you could replicate some of these with ocaml_ppx system (looks like macros over ast?)

I.e. [https://github.com/janestreet/ppx_let](https://github.com/janestreet/ppx_let) kinda looks like let! bindings in F#

</comment></comment></comment><comment><USER10> Shameless plug - I'm trying to improve upon Elm and React's programming model with my Concur UI framework. Its programming model is a bit unusual, it uses Monads to sequence widgets in time, but it is designed to be extremely simple to use, and you don't need to actually understand Monads to use it. An advantage is that it's not artificially restricted like Elm, and allows you to use advanced Functional Programming tricks when you can and want to.

It is available for [Haskell]([https://github.com/ajnsit/concur](https://github.com/ajnsit/concur)), [Purescript]([https://github.com/ajnsit/purescript- concur](https://github.com/ajnsit/purescript-concur)), and [Javascript]([https://github.com/ajnsit/concur- js](https://github.com/ajnsit/concur-js)) (so no need to learn a new language), and also allows using external React components. The Javascript version uses Async Generators as a substitute for Monads.

With Concur, you can implement the entirety of Elm architecture with a few lines of idiomatic code.

Purescript or Haskell -

        elm render update = go
          where go st = do
              action <- render st
              go (update st action)

Or in JS -

        function elm(render, update){
          var go = async function*(st) {
            action = yield* render(st);
            yield* go(update(st, action));
          };
          return go;
        }

<comment><USER11> I've always thought that Elm was like Purescript in the way that it was just another way to bring the good parts of Haskell (a good type system) into JS.

I didn't consider elm's architecture as the main value proposition -- if you squint it looks just like every other data management model for component- based approaches these days -- flux, redux, etc all work in a similar way, +/\- immutability.

Hopefully people aren't out there thinking that Elm has done something to magically make it much harder to write runtime errors -- they added a powerful ergonomic-where-possible type system.

If developers out there are still thinking types are "bad for JS" or that using types in code is weird/unnecessary, they might be suffering from Blub[0], and need to go out and see what other languages are doing maybe widen their perspectives. Not every language with a good type system looks like Java/Dart/Typescript/etc (some people can even argue that Java _doesn 't_ have a good type system) and I often meet engineers who think adding/checking types basically means making javascript into java.

[0]: [http://wiki.c2.com/?BlubParadox](http://wiki.c2.com/?BlubParadox)

<comment><USER12> Elm isn't a general purpose programming language. You can only write web-apps with it you can only use TEA (the elm architecture). In that way, the TEA really is it's main value proposition.

<comment><AUTHOR> You can do more than that using ports, but it doesn't sit very naturally.

</comment></comment></comment></comment><comment><USER13> This inspired me to look up the Elm docs, and came across this gem:

      view model =
        div []
          [ button [ onClick Decrement ] [ text "-" ]
          , div [] [ text (String.fromInt model) ]
          , button [ onClick Increment ] [ text "+" ]
          ]

The html elements themselves are Elm functions. Code looks like data. Nice. Now considering Elm to be potentially useful tool to know.

<comment><USER14> That's how literally every VDOM-based framework looks, including React. Elm isn't special in this regard. It is special in many other regards, however, and I appreciate it for that. It's also interesting as one of the few languages that have parametric polymorphism but no ad-hoc polymorphism, which leads to some interesting designs. I don't like how only the BDFL is allowed to do certain things, like create new operators in external libraries, but overall, it's a very pleasant experience.

<comment><USER15> "I don't like how only the BDFL is allowed to do certain things, like create new operators in external libraries"

Isn't this true for like, 95% of languages? Yes, Elm breaks from it's Haskell heritage in this regard, but this is a very common lack of feature.

<comment><USER14> Fair enough, but my main problem with it was that it existed, and then they removed it, which was very sad.

</comment></comment></comment></comment><comment><USER16> Elm is fascinating since it shows that with the right architecture functional programming for GUI is possible without hatches like monads or hiding state in closures or green thread stacks.

Another things is that in Elm the state of the whole application is very visible. Typically just by looking at data structures and message types one gets how things work. The code just fills details.

<comment><USER10> I understand what you are saying, but - the whole point of abstractions is to "hide state". For example, what is nicer to write/read? Pseudocode -

        // Stateful
        state = {buttonClicked: false}
        render() {
          if(!state.buttonClicked) {
            return button({text: "Click Me", onClick: {state.buttonClicked=true}})
          } else {
            return text("Thanks!")
          }
        }

vs.

        // Implicit state
        render() {
          yield button({text: "Click Me", onClick})
          yield text("Thanks!")
        }

<comment><USER16> What is nicer to test and maintain?

To test render() in the clicked state with the explicit state I can call it with the corresponding state. With the implicit state at the very least I have to write a driver to run render() into the clicked state and then test the next state transition.

To understand the effects of the code on other parts of the application with the explicit state it is sufficient to look at the definition of the state. The implementation of render is only relevant if one wants to look at details. With the implicit state I have not only understand what render() is doing, but also understand how to properly call it from other parts of application. I.e. what happens when the render is called the third time?

<comment><USER10> Testing could be _much_ easier for the implicit state version. I've not defined it, but you are assuming things about how the render function or the implicit state behaves.

In my hypothetical implicit state framework - A _widget_ is composed of a sequence of steps, each of which is an independent widget. So it's easy to write invariant properties for _each step_ -

For (text "String") it's guaranteed that the widget never returns a value or raises an event. i.e. the type is

        forall a. Widget a.

So the issue of calling render a third time never arises.

<comment><USER17> The explicit version we can understand how it works just by looking at it. The implicit version we need knowledge about how your hypothetical framework works.

<comment><USER10> Of course you need to understand how the framework works. But that's a fixed cost vs. having to understand a program from scratch everytime when your framework is not clear or powerful enough.

Would you also say using "goto" is easier because it's a simple jump, vs. having to understand how while/for loops work?

</comment></comment></comment></comment></comment></comment><comment><USER18> > Ports == lots of boilerplate and "loose" typing

This is a common criticism of Elm, and I've never understood it.

The criticism seems to be that "Elm is bad because I still need some JavaScript, and JavaScript is dangerous."

Like, what's the alternative? _More_ JavaScript?

<comment><USER19> Have you seen ReasonML?

      [@bs.val] external pi : float = "Math.PI";
      let tau = pi *. 2.0;
      [@bs.val] external alert : string => unit = "alert";
      alert("hello");

Elm was trying to make it very hard to use JS in Elm which is always a bad idea when you are a transpiled language. Clojure is so popular because you have access to most of Java and the libraries written in Java. ReasonML makes super easy to use JS (or other languages, same FFI interface) while being an ML family language just like Elm. For me ReasonML is clearly the winner of type safe JS for these reasons.

<comment><USER18> I do not agree that it is "always a bad idea".

That is why I use Elm, and not some other compile-to-JS language that allows me more freedom.

I don't want freedom. I want constraints.

Freedom is the rope with which I can hang myself.

Constraints keep my bug tracker silent.

<comment><USER20> I was(am? will be again?) a fan of Elm. Constraints can be helpful and even liberating(in some sense). But that's something that should be balanced carefully with other things, like rules\laws that are clear, universal and follow the common sense. Unfortunately, during my Elm journey, I've found that's not the case for Elm.

> Freedom is the rope with which I can hang myself.

If you'd like to, why not? It's up to you. You're not forced to do, though.

On the other side, being a hostage of some secret plans in "people in power" minds, you might be forced to do any kind of staff. New constraints are here and they're enforced on anyone. That's a catch with constraints, you can be OK with existing, but you'll never know what comes tomorrow.

<comment><USER18> > If you'd like to, why not? It's up to you. You're not forced to do, though.

Well, yeah. If I'd like to hang myself, I'd pick a technology with fewer correctness guarantees. As it turns out, that's not what I want. This is self- evident.

It's also not a valid criticism for you to say that you've found Elm doesn't "follow the common sense". This is too vague to be any kind of constructive criticism.

<comment><USER20> > Well, yeah. If I'd like to hang myself, I'd pick a technology with fewer > correctness guarantees. As it turns out, that's not what I want. This is > self-evident.

That's exactly what I'm talking about. I'd also like to pick up some "silver bullet", like Elm(if I got you right), for any new project.

Unfortunately, real world is usually a little bit more complicated than "I'm free to pick up any technology that I want. All browsers are the same, their behavior is consistent, mobile web is pure joy and all of our users know their plugins might cause an issue to our app, therefore they're disabling them when they launch our app".

Anybody who does webdev knows that. Different projects, different requirements(sometimes very, very strange), brand new requirements right before the release, deadlines, etc. There're lots of things you have to deal with to end up with a good website\app. Picking a language with nice "correctness guarantees", is not going to help you much.

There were times, long time before 0.19, when there were at least discussions on effect managers, extending the type system, native modules were a nice escape hatch to fix your problem at hand with nasty browser bug or even Elm runtime issue. Those were times when I was so excited to use Elm, did some tiny (sub)projects in it, did a workshop at the office.

Since then, many things have changed to the worse, imho. Some features were removed, not even deprecated. No public discussions, no roadmap, no bugfix releases, no escape hatches for special cases. But who cares what some random guy on the internets thinks :)

Don't get me wrong, I think Elm is a _great_ experiment in the land of static languages, lots of great stuff is getting into mainstream languages(like Elm architecture, error msgs). I still hope we'll see the 1.0 version and things might get better in terms of feature stability, feedback and building things a little bit more complex than counter apps without hitting even more pain points than we have with modern JS\TS.

<comment><USER18> > I'd also like to pick up some "silver bullet", like Elm(if I got you right)

Nothing is a silver bullet. Never claimed it was.

> Anybody who does webdev knows that.

I am a web developer, and I disagree with you.

> Picking a language with nice "correctness guarantees", is not going to help > you much.

That hasn't been my experience.

> Since then, many things have changed to the worse, imho

Exactly — it's _your_ opinion. Removing surface area for runtime areas is a change for the better, in _my_ opinion.

> building things a little bit more complex than counter apps

My businesses are more complex than counter apps.

</comment></comment></comment></comment></comment></comment></comment><comment><USER21> Is there no way to try this without signing up? I even finally decided I'd sign up and then was greeted with a form that required a phone number.

<comment><USER22> > The app is live here (requires registration)

Doesn't look like it.

</comment></comment><comment><USER23> What I find most interesting about Elm as a designer who also "codes", is that because of its bottom up frontend philosophy (types first instead of components first) it somehow assumes that the UI designer and coder is the same person, that there is no clear designer to developer handoff where you hand over a thought out design to implement. It's more the other way round, where you'd hand over what you've come up with in Elm to a designer (which might be another problem because it reduces the designers job to just make things pretty).

So the best use would be for designers who code, basically unifying frontend design and engineering.

<comment><USER24> So, something like react's storyboard would be useful to you in Elm?

<comment><USER23> isn't Storyboard based on components (parts) first (atomic design)?

Elm is the opposite, it's focused on the whole which you then use as the basis for parts at actual design time (thinking about layout and hierarchy).

So in a way Elm is about form following function (creating visuals from existing functionality), while most of the other environments are focused on function following form instead (creating functionality based on existing visuals).

<comment><USER24> You can perfectly do the design-first process with Elm, I thought you were maybe accustomed to Storyboard or something like that.

IMHO you can do design-first process with Elm just like with React. There is no Storyboard equivalent that I'm aware of, but I never found it useful enough but maybe it is, for toolkit/library designers.

I have found that I work differently depending on environment. I do model/types/functionality first if working on my own, but in a corporate environment I typically get designs handed together with some kind of specification, so there I often do "design-first".

<comment><USER25> I'm don't mean to nitpick, but did you mean storybook instead of storyboard? That's the only project that I've found which sounds like what you're talking about

[https://github.com/storybooks/storybook](https://github.com/storybooks/storybook)

<comment><USER24> Yes, totally. I must have it confused with iOS' storyboards.

</comment></comment></comment></comment></comment></comment><comment><USER26> Completely OT but I'm curious about his use of space before exclamation and question marks. Is it a cultural thing?

<comment><USER27> In French, there is a space before exclamation and question marks. Based on the author's name, I'd also guess that they are French.

</comment></comment><comment><USER28> Anybody who liked elm is highly recommended to check out Scala.js. With scalatags, it looks close to what elm does AND you have the entire power of jvm libs.

And you get code sharing across client and server as its just plain old scala. I believe elm is not big server side.

<comment><USER29> Scalatags is not a VDOM implementation, though, and the Elm architecture (one giant state machine) is very different to what you'd typically see in a Scala.js application. A closer analog, in my opinion, would be ClojureScript + Reagent, but even that doesn't feature Elm's focus around immutability.

<comment><USER30> ScalaTags is indeed not relevant here, but Scala.js has its fair share of reactive UI libraries such as my own Laminar [https://github.com/raquo/Laminar](https://github.com/raquo/Laminar)

<comment><USER31> Your DOM builder library is also great for lower-level DOM manipulation. Thanks for your work, by the way.

[https://github.com/raquo/scala-dom-builder/](https://github.com/raquo/scala- dom-builder/)

</comment></comment></comment></comment><comment><USER32> Is anyone doing business logic with a visual tool like this one?

And if so: In production? Does it work? Do you trust non-programmers with it?

</comment><comment><USER33> Any HNer using Opa ? Is that alive and well. If someone has used elm and opa would love to know about their experiences.

</comment><comment><USER34> hmm interesting ... on the other hand some people are trying to get away from ELM [https://discourse.elm-lang.org/t/elm-to-bucklescript- compile...](https://discourse.elm-lang.org/t/elm-to-bucklescript- compiler/2871/4)

</comment><comment><USER35> * Obligatory Pine joke here *

(I know the Elm people don't like jokes about the email client. Tough; they should have picked a name that wasn't already used.)

<comment><USER36> > _Obligatory Pine joke here_

But Pine Is Not Elm.

I wonder how many of today's Linux users don't get why the editor is named _nano_. The fact that you can trace the name back to "electronic mail" is my favorite command-name joke in an environment full of them.

(If you missed the chain, it was

1\. "electronic mail" = "elm"

2\. "pine" as a joke on "elm" \-- though I believe they deny the "PINE Is Not Elm" derivation, it's still pretty clearly a reference to elm

3\. "pico" the editor as "PIne COmposer"

4\. "nano" as a joke on "pico".)

<comment><USER37> I didn't realize there was that much of a backstory behind nano's name! Thanks for sharing!

</comment></comment></comment><comment><USER38> I don't understand why this is noteworthy.

I think maybe this is when you decide 'maybe our language has failed'. Or at least admit it's a toy language that hasn't been properly engineered to be effectively used commercially. When it's a 'worth mentioning' when a single app has been written in it by some dying company.

I mean, imagine if we had a headline on the frontpage of HN for every app written in C or C++ or Java or Python (or Objective-C or Swift or C# or even Visual Basic or Rust)

Steve Yegge said it best almost 10 years ago: [https://steve- yegge.blogspot.com/2010/12/haskell-researchers...](https://steve- yegge.blogspot.com/2010/12/haskell-researchers-announce-discovery.html)

Functional languages are great toys but nobody uses them to get work done, almost without exception.

<comment><USER18> > Functional languages are great toys but nobody uses them to get work done, > almost without exception.

I run my own businesses on functional programming languages (Haskell and Elm) almost exclusively.

100% of my income comes from the three software products I own, all primarily written in Haskell.

You're displaying a pretty amazing level of ignorance here.

<comment><USER39> That sounds really interesting! What's the market/domain of your software product?

<comment><USER18> I'd say the products themselves are fairly uninteresting :)

NewBusinessMonitor[0] is a tool for marketing your products/services to businesses in the UK. This company is a bootstrapped SaaS, built and run by just me. It's been taking money for over a year.

Comparestack[1] is a price comparison platform. Our first product is Moneygains[2] — a way for residents of Northern Ireland to switch to a better deal on their home electricity. I'm building this with a partner — he's taking care of all the business stuff.

I have a third in the reinsurance space, and it has taken funding. I'm not going to talk about this one so much for the time being — it's still in stealth mode.

[0]: [https://newbusinessmonitor.co.uk/](https://newbusinessmonitor.co.uk/)

[1]: [https://comparestack.com/](https://comparestack.com/)

[2]: [https://moneygains.co.uk/](https://moneygains.co.uk/)</comment></comment></comment></comment>


How Netflix Could Suffer Blockbuster's Fate - <AUTHOR> http://www.marketwatch.com/story/how-netflix-could-suffer-blockbusters-fate-2013-05-01

<comment><USER2> Netflix's vulnerability is content offerings: it _must_ have the biggest selection of movies possible. Much of its audience relies on it being the near-sole source of content, being unwilling to fiddle with more than 2-3 content providers (ex.: I'm content with Netflix for bulk/old content, iTunes for premium, and Redbox for latest & cheap...if it's not there, I'm not watching it). A headline today notes Netflix is about to lose >1700 titles soon for want of licensing; I wonder how much of my 100+ item queue is going to evaporate as a result, and how annoyed I'll be (there's no hint as to what's going away).

Word now is Netflix is starting to focus on "exclusive content". That's fine, so long as it is _not_ to the _exclusion_ of other content. I'm not interested in House Of Cards or other particular shows to the point of giving up anything else I want to see on a moment's notice. Be sure there's enough available that there's far more I want to see than I possibly can at any given time. When users go to Netflix and decide "there's nothing I want to watch", it dies.

Losing prolific titles in favor for a handful of high-profile exclusive offerings? Doom awaits.

</comment><comment><USER3> Horrible article, poorly written plug for "plateaus". Somebody should tell the authors of this article about "House of Cards", apparently they missed the fact that Netflix is trying to become a content provider.</comment>


The USSR was better prepared for collapse than the US is today - <AUTHOR> http://www.energybulletin.net/23259.html

<comment><USER2> From the article: The population of the United States is almost entirely car- dependent, and relies on markets that control oil import, refining, and distribution. They also rely on continuous public investment in road construction and repair. The cars themselves require a steady stream of imported parts, and are not designed to last very long. When these intricately interconnected systems stop functioning, much of the population will find itself stranded.

I've seen this sentiment before, referenced indirectly from this forum:

Potholes may well be the singular measure of the calamity we are in or about to face. -- <http://www.kunstler.com/Grunt_SouthAfrica.html>

</comment><comment><USER3> An interesting hypothesis, but the article is sadly lacking even the most minimal data necessary to validate the comparisons.

</comment><comment><USER4> interesting but off topic.</comment>


Raspberry Pi microSD card performance comparison - <AUTHOR> https://www.jeffgeerling.com/blog/2019/raspberry-pi-microsd-card-performance-comparison-2019 <comment><USER2> I wouldn't buy an sd card on amazon because of the risk of getting a fake. There are tons of fake sd cards out there and amazon refuses to take responsibility for their supply chain.

<comment><USER3> I'm sure there's a name for this effect, but I am always fascinated by the complaints about fake products on Amazon. I have _never_ received one and I spend several thousand on Amazon every year.

I _know_ it must be happening, I just can't understand if I'm lucky, if it's an effect of my location, or somehow related to the way in which I shop on Amazon.

<comment><AUTHOR> Many of the major product listings seem to be okay—for example I've ordered a number of the Samsung Evo+ cards I link to in the blog post, and tested each one and never found one that didn't perform as the first I bought—but I have gotten fakes here and there.

Almost every time, though, it's because the Amazon official supplier/warehouse was out of stock and I accidentally ordered from one of the secondary suppliers. The problem is, unless you know what to look for in the interface, it's hard to determine if you're buying from Amazon or the manufacturer, or some 3rd party.

Even then, there are many reputable 3rd parties. But there are many who are not.

The worst cases in my experience are ordering 'Apple OEM' type products. I will not buy a charger or any other Apple accessory on Amazon because more than 50% of the time I've gotten a non-Apple-manufactured product.

<comment><USER4> > The problem is, unless you know what to look for in the interface, it's hard > to determine if you're buying from Amazon or the manufacturer, or some 3rd > party.

Also, Amazon sometimes commingles their own stock with that of 3rd-party vendors, so "Ships and Sold by Amazon" doesn't mean what it used to.

EDIT: fixed numerous typos >:(

</comment></comment></comment></comment><comment><USER5> I wonder if Pi 4 supports UASP (USB Attached SCSI Protocol). This may need everything from the VLI VL805-06 USB controller to the firmware to the driver to support it. A preliminary DDG search suggests that the controller probably supports it.

My understanding is that, if UASP is supported, you can squeeze even more performance out of a SSD, and it will even properly support the TRIM command because then the SSD is no longer just a dumb USB mass storage device.

<comment><USER6> TRIM is supported by USB mass storage devices since those are _also_ SCSI. It is the bridges that may not support it, and the same is true for USB-attached SCSI.

For USB-attached SCSI, what makes a difference in performance is support for USB 3.0 streams, which allow multiple transfers to occur concurrently ([https://www.kernel.org/doc/html/latest/driver- api/usb/bulk-s...](https://www.kernel.org/doc/html/latest/driver-api/usb/bulk- streams.html)).

<comment><USER5> Ah. I didn't know that USB mass storage is also SCSI. Is TRIM/UNMAP part of the SCSI Transparent Command Set, which depends on the SCSI Peripheral Device Type reported (by the USB-SATA bridge?) in response to INQUIRY?

What exactly is the "SCSI Transparent Command Set" anyway? I haven't been able to find an answer from DuckDuckGo search. The Wikipedia article on USB Mass Storage [1] mentions it, but doesn't really define it. Neither does the article on the SCSI command [2] itself.

Another post [3] touches upon SCSI Transparent Command Set, but also says in passing that the SCSI specifications at t10.org don't mention the "SCSI Transparent Command Set".

[1] [https://en.wikipedia.org/wiki/USB_mass_storage_device_class#...](https://en.wikipedia.org/wiki/USB_mass_storage_device_class#Device_access)

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

[3] [http://janaxelson.com/mass_storage_faq.htm](http://janaxelson.com/mass_storage_faq.htm)

</comment></comment></comment><comment> gjsman-1000 Note to readers: The USB chip does run hot. This is getting fixed in a firmware update that you can test in the RPF Forum which reduces temps.

<comment><USER7> I wonder if that's the reason for somewhat patchy USB performance. when copying data between two USB HDDs the data goes at 40-50MB/s for a minute or two then drops down to like 500kb/s and then ramps up again after a while. When copying data the USB chip and the ports themselves get stupidly hot.

<comment><AUTHOR> Yeah... it surprised me that the VLI USB chip was much hotter than the processor even during CPU stress testing. Between that and the little power controller chip by the USB-C power supply port, the Pi 4 pretty much demands active cooling for any but the most mundane tasks.

</comment></comment></comment><comment><USER8> Once upon a time, Linaro produced flashbench, a tool for learning more information about how managed NAND devices (mmc, sdcard, etc) actually manage their flash. LWN did a story on some of their conclusions [1]. One of the standouts for me was that some erase blocks are managed completely differently from others, such that random i/o performance can vary based on the location on the device. Traditional filesystem benchmarks aren't set up to observe this behavior.

IIUC, F2FS incorporated some of that information, and not much else has. But in principle, you should manage your device with short extents and inode tables in the small-block-friendly area, and larger extents elsewhere whenever possible.

[0]: [https://github.com/bradfa/flashbench](https://github.com/bradfa/flashbench) [1]: [https://lwn.net/Articles/428584/](https://lwn.net/Articles/428584/)

</comment><comment><USER9> I now only use "Endurance" microSD cards, which I think are supposed to be for dashcams, in my Pi's, because I've never not had a normal microSD card ultimately be killed by the Pi through what I assume is write endurance exhaustion.

<comment><USER10> Did they die pretty early on? Do you use USB port on a hub/PC/etc for power?

If answers to both of those questions are YES, over the years in reading forums/comments/etc a common thread between them has been that rPi kills microSD cards, and the commonality between _most_ of those posts has been the use of (low/unstable) power strictly off of a USB port of another device (instead of a wall adapter)

Edit: I now see that geerlingguy addresses this elsewhere in the thread too, so he can add at least some anecedotal experience that drawing too much power from a poorly-powered rPi is a recipe for failed SD cards

(Sorry if this is completely irrelevant- it may just be that if you write to your cards a lot they're dying from that due to endurance, like you said)

<comment><USER9> I generally use a dedicated USB power supply so that should not be the problem. And I haven't yet had an "endurance" card die.

</comment></comment></comment><comment><USER11> Not Pi, but related - I gave up on using a 64GB Kingston SDXC in a Lexar reader to play MP3s in my truck. After just a few days it would develop corruption at the end of songs and by a few weeks it was just too annoying to continue using.

I looked at some of the files and it appeared to be a bit flip type problem. Went to a dedicated usb thumbdrive (as has been in my car's glovebox for 7 years) and no issues. Really makes me question using these sdxc cards at all.

</comment><comment><USER12> I know embedded systems were not the original purpose of the Raspberry Pi, but so many people are trying to use the pi for just that. I've wanted to use Rpi for that _but_ the SD card failure rates are high. I know the high-end ones are a lot lower, but is it reliable enough? I am not sure. I was hopping for a SD card alternative for the Rpi 4, maybe it's booting from USB 3.0 when that ships?

<comment><USER13> You can get "industrial" SD cards that are rated for more severe environmental conditions and more write cycles. They are more expensive though, but probably worth it for commercial applications.

<comment><USER14> The 'industrial' microSD cards based on MLC or pSLC with controlled or frozen BoM only make sense if you are going to use a device in extreme settings[1]. In most instances, a card in rPi will serve as a boot device, unless someone reappropriates it into a Dashcam or something similar, which has heavy duty write cycles or continuously reads/writes to and from the card; it will be wise to choose something that strikes a balance.

At a guess, the Samsung EVO family of consumer based cards, probably ranges between using TLC (older) to 2D or 3D V-NAND (newer). The more robust Pro series, which commands a premium, probably uses MLC or superior.[2]

[1] [https://www.swissbit.com/products/nand-flash- products/micros...](https://www.swissbit.com/products/nand-flash- products/microsd-memory-cards/)

[2] [https://www.cactus-tech.com/resources/blog/details/slc- pslc-...](https://www.cactus-tech.com/resources/blog/details/slc-pslc-mlc-and- tlc-differences-does-your-flash-storage-ssd-make-the-grade/)

<comment><USER15> That's blatantly not true, as I've run into controller issues from verified authentic name brand cards. A 80kbyte/sec write with a specific pattern for about six hours would absolutely hose the card (and yes the card was write leveling).

There's so much nice about the industrial cards that have nothing to do with it's ability to endure extreme environments, that I would basically never ship a non consumer product without them at this point.

<comment><USER16> > A 80kbyte/sec write with a specific pattern for about six hours would > absolutely hose the card (and yes the card was write leveling).

80kB/s sounds a bit low for a card that is doing full "global" wear leveling; memory cards and SSDs that don't have DRAM often cut corners on the wear leveling, so they aren't as effective as proper mainstream SSDs. Your workload was probably issuing the writes in chunks smaller than the flash memory's page size (typically 16kB these days), so you probably had serious write amplification from the read-modify-write cycles even if that 80kB/s was sequential writes. SSDs with decent-sized write buffers and power loss protection capacitors can do more write combining than a memory card that has to be prepared for sudden power loss at any moment.

<comment><USER15> Yeah, it is very low, which is why I bring it up. It was a controller bug, where the FTL completely lost track of some sectors. Write amplification has nothing to do with it.

</comment></comment></comment></comment></comment></comment><comment><USER17> My first time creating s pihole I had everything setup with a nice sd card then proceeded to put this plastic case over it. Seemed a little tough to put on like it was a little pressure fit so I clicked it into place then tried starting it back up. Well it never came up then I started looking at the pi and realized that the case didn't have a cutout where the sd card protrudes and it cracked the damn card at the tip! Ended up using a cheaper one I had lying around but wow, lesson learned the hard way.

</comment><comment><USER18> I'm a big fan of the RPI, and use them in various home projects, but I'm going to continue to wait out the RPI updates until I can get a proper m.2 slot for a "real" hard drive. Working with SD -- especially when continually developing, is just too slow and painful. Not to mention questions about lifetime and lifecycle.

The price of m.2 drives have come down so significantly that I think SD should be slowly phased out, or added as a secondary option.

<comment><USER19> There are a few ways to do this now:

m.2 add-on boards, such as [https://amzn.com/B01NH2W8NL](https://amzn.com/B01NH2W8NL)

boot directly from a good usb flash drive (I like the sandisk cz80, though they seem scarce now)

</comment></comment><comment><USER20> Is there really a need for random 4K writes on the SD card in the Pi? Couldn't the card use a log-structured filesystem and batch writes in RAM, turning those writes into streaming writes? The new Pi certainly has enough RAM that it could dedicate some to serving as a write cache.

<comment><USER21> This is the choice that lots of system designers have to make, "low apparent write latency" vs "maximum data at risk of power loss". If there's a database on the Pi you're going to be upset if you call fsync() and it doesn't actually do the writes.

<comment><USER22> This is a false dichotomy. Most (all?) contemporary high-reliability (and, arguably, high performance) filesystems are long structured.

(I am excluding things such as ext4 that are missing data block checksumming, and recovery from disk failure using parity stripes)

<comment><USER23> >high-reliability (and, arguably, high performance) filesystems are long structured.

That prevents the filesystem from being in a inconsistent state, but doesn't address the issue of data loss. eg. what happens if there's 5M outstanding writes and you get a fysnc? If you wait for everything to be flushed, that's going to produce latency. If you lie and return immediately, and there's a power outage, you now lost those oustanding writes.

<comment><USER22> A decent FS will make sure there are never 5M outstanding writes that an unrelated fsync depends on.

</comment></comment></comment></comment></comment><comment><AUTHOR> tl;dr: the Pi 4 has a much more rosy outlook when it comes to IO both for the microSD card and external drives. The Samsung Evo+ is still the best value for your money.

<comment><USER24> I'm surprised by the lack of mention of the A1/A2 "Application Performance Class"[1]. These classes specify minimum performance numbers for random reads and random writes: 1500/500 read/write for A1, 4000/2000 read/write for A2.

Notably, the Amazon link for the Sandisk Extreme points to an A1 version, not the A2 version[2]

      1. https://www.sdcard.org/developers/overview/application/index.html
      2. https://smile.amazon.com/gp/product/B07FCMBLV6

<comment><USER25> My understanding is that A2 cards are generally slower than A1 cards IF you don't have host-side support for managing the volatile-RAM caching that A2 requires.

So if the Pi 4 only allows you to run in A1 mode anyway, you're better off buying the A1 card and both saving money and getting a faster card. I don't know if that lack of support is true of the Pi 4, but it does seem to be true of most other SBCs according to [https://github.com/ThomasKaiser/Knowledge/blob/master/articl...](https://github.com/ThomasKaiser/Knowledge/blob/master/articles/A1_and_A2_rated_SD_cards.md)

<comment><USER24> Ah, interesting, I did not realize there was a difference in protocol. I thought A1/A2 were just spec requirements.

I wonder if A2 support is something that could be added in newer kernels, or whether it requires hardware support.</comment></comment></comment></comment>