10 ways Twitter could make money quickly - <AUTHOR> http://www.thestandard.com/news/2008/07/14/10-ways-twitter-could-make-money-quickly

<comment><USER2> These suggestions are really laughable. Sure, the advertising model makes sense, but that isn't exactly rocket science, and that's only one suggestion.

Charging for ad-free service never works -- advertisers want to target the very people that would pay for to such a service. If you're an advertiser, you want to target people who are willing to pay extra for a convenience -- the exact people who would opt out.

My favorite example of the author's ignorance: #9. Can you imagine what would happen if Twitter sold its email list? Many of the Twitter users that I know are skeptical about the service, and it looks like the users in general are technically savvy -- all it would take is a really bad PR piece to start a mass exodus.

</comment><comment><USER3> While other commenters are right, nothing here really is groundbreaking, it's good to be reminded that Twitter IS indeed monetizable, they just choose to not be making money at this time.

And that might not be a bad idea. They're best option is to get bought quickly by a social network: They can keep their current service relatively unchanged and bring value to the network through more eyeballs eyeballing more often, thereby raising the owner's ad revenue while not driving away the user base.

If they do something to decrease the userbase in an effort to drive a short term profit, their viability as an acquisition target goes right down the drain.

</comment><comment><USER4> I find it akward she believes they are not familiar with the ways she is suggesting. I was expecting something more impressive but then again who would share information like that?

<comment><USER5> She mentioned a couple of nice ways to monetize, but most of them can't really be taken seriously. I was expecting more as well.

<comment><USER6> Why don't we make this thread more valuable than the original article then. Any community suggestions on ways to monetize?

My suggestion: terms of service that permit free individual use, but require some form of subscription for corporate use.</comment></comment></comment>


Adobe Makes Flash Searchable - <AUTHOR> http://www.readwriteweb.com/archives/adobe_makes_flash_searchable.php

<comment><USER2> I'm sure many folks will be happy to hear this news..

Up until now, Flash sites could not been crawled/indexed by search engines because there was no way for the search engines to extract the keyword content from the site. For this reason, many SEOs have recommended their clients either totally abandon flash, or making a non-flash site that could be crawled by search engines.</comment>


A Calculus Analogy: Integrals as Multiplication - <AUTHOR> http://betterexplained.com/articles/a-calculus-analogy-integrals-as-multiplication/

<comment><USER2> Also check out _Elementary Calculus: An Infinitesimal Approach_ for a mathematically rigorous course in infinitesimal calculus. I think it is much more intuitive than typical limit calculus.

<http://www.math.wisc.edu/~keisler/calc.html>

<comment><USER3> If you already understand limit proofs of calculus go ahead and read the first chapter and the epilogue to get a pretty complete picture on infinitesimal calculus.

</comment></comment><comment><USER4> The "multiplying changing numbers" analogy made me think of "integrating really is just calculating the average", ie integrating f(x)dx is like taking the average of f(x) and multiplying by the size of the interval.

<comment><USER5> I believe that the integral symbol with a dash through it is equivalent to an integral divided by the interval...

Couldn't find any confirmation online, though.

Even if it isn't, it is a nice notation.

Maybe someone could confirm

</comment></comment><comment><USER6> I don't get the "revelation" he's claiming that this is. When you're finding work or distance, two examples he gave, you're still finding the area under a curve. Sure, the axes will be representing time and velocity when calculating distance, or force and distance while calculating work, but that is the exact same thing as calculating area when the axes are used to represent distances of width and height.

He's right that's it's akin to multiplication. In fact, you can find the areas under trapezoids using very simple integrations, but he did nothing to discount the fact that definite integrals are all about areas under the curve.

<comment><USER7> Seems to be helpful for physicists, not so much for mathematicians. A physicist will look at an integral and say "oh, yeah, charge is field times area, that makes sense!", while a mathematician isn't going to say the same about measures. I think that's the "revelation" he was going for.

BTW, I always thought of convolution as multiplication. Anyone else feel cheated by this guy for that reason?

<comment><USER8> I feel that integration is more about addition than multiplication, and differentiation is more about subtraction than division. Is it just me?

<comment><USER9> Not just you. I seems much more natural to me to think of an integral as "continuous sum."

You can often describe the exact same thing using a discrete sum or an integral, e.g., in a classical mechanics class you first consider a system of N connected springs, and a number of properties (like, say lagrangian, energy etc.) of the system will be expressed as sums with N terms. Then you take the continuous limit, the connected springs become one string and voila, all sums become integrals.

In quantum mechanics for some systems the set of all energy levels is discrete (e.g., the harmonic oscillator), for some it's continuous (e.g., a free particle), and often it is part-discrete part-continuous (a hydrogen atom.) Many formulas will require you to take a sum for the discrete part and an integral for the continuous part. Some quantum mechanics textbooks introduce a special symbol, a capital sigma overlaying an integral symbol, which means "integrate or add, whichever appropriate."

</comment></comment></comment></comment><comment><USER10> Maybe it's just me, but I found Integrals more intuitive as a continuous "sum" of probabilities in a distribution. So, if you want to marginalize a discrete distribution, you just add all its components over the conditional variable. If you want to marginalize a continuous distribution, you integrate.

I guess you could say that you're simply enumerating infinitesimal densities?</comment>


Search federal hospital inspection reports - <AUTHOR> http://www.hospitalinspections.org/#map

<comment><USER2> Just a quick remark about the submitted title: the reports are done by the government but the database was compiled by the Association of Health Care Journalists, who had been filing records requests and eventually worked out a system with CMS to get the electronic files, though after some examination, some types of records were just not released by CMS

<comment><AUTHOR> Thanks for the clarification. I'd be lying if I said I didn't deliberately use government in the title--rather than AHCJ or CMS--to garner more attention. For those unaware, CMS administers Medicare and for all intents and purposes sets the rules in US healthcare. Them enabling the publishing of these reports online is a strong show of support for the push for quality outcomes ("value over volume").</comment></comment>


Hacking a $30 Xiaomi camera to do more than it's worth - <AUTHOR> https://hackernoon.com/hacking-a-25-iot-camera-to-do-more-than-its-worth-41a8d4dc805c <comment><USER2> I did all. It works well on VLC (rtsp://IP/unicast), also well in Tinycam pro.</comment>


Python, Go or Haskell? - <AUTHOR> I'm in the interesting position of setting up a team from scratch: hiring the first software developers in a well-funded company. There is a team of data scientists who have been creating models in Python (which end up as docker images). I have no legacy code of any importance for all the surrounding code (UI, data fetching, data storage, etc.) that I need to support or maintain.
The guidance I'm getting from the CEO is that he wants to build a cutting-edge, next-generation company. There's budget to hire 10-20 tech staff.
I'm comfortable enough in all three languages (and others besides).
I don't want this to turn into a flamewar: the main criteria I care about are:
1. Long-term supportability
2. Bugginess of typical code generated in the language.
3. Availability of developers
What are your thoughts? <comment><USER4> We've been using Go at work for 2.5 years now and it has become my primary language of use at this point in time. I hate it. I hate it like hell. It's like they decided to take all the things that make other languages good - <USER2> as safety, brevity, intuitiveness, versioning and proper project structuring - and threw them out the window. As far as I'm concerned the good things about Go (large community, fairly efficient generated executables) do not outweigh the bad.

We've spent so much time fixing obscure bugs and behaviors that betray everything we've learned in the languages we used previously in our careers that it was really not worth it. And we still do. Finding developers is also an issue, as most developers do not really want to learn a new language, and Go is still not that common in enterprises (I used to be like that myself, but I've learned long ago that this shouldn't be such a big factor when thinking about a new job).

You can make the case that we're simply not good enough developers or Go is just not a good fit for the type of developers we are. Maybe. But the choices made in designing this language, and its popularity, absolutely baffle me.

<comment><USER5> Well, somehow this sounds to me like you are doing it wrong. Yes, you probably heard that before, but when you say things like 'proper project structuring' I think that you probably try to do something in a way that it is not meant to be used.

But at the same time you probably have good reason to try that, as that was the way you did it in the past (with other languages). So while Go allows you to quickly learn to write code, it is a much harder challenge to learn how to structure you code in simple small packages. In the end that brings a lot of benefits (testing is easier), but if you try to create a project with very few packages you will go through lot of pain due to the lack of structure.

Its very similar with interfaces. Programmers coming from other languages mostly ignore them in the beginning and it takes a while until they understand that exporting types from a package is a failure and that interfaces would have been a much better choice.

In my opinion, the key to successful Go development is building many small, well tested library packages while using interfaces a lot.

<comment><USER4> Appreciate the comment. I was largely referring to very large projects. When it comes to smaller projects, but really any Go project, we've moved to the structural recommendations in the Go documentation a long time ago, which did improve things a bit, but really there are almost no good examples out there for _really_ large projects.

Your point about interfaces is mostly correct though, and we're progressively learning to utilize them better.

</comment></comment></comment><comment><USER6> I can't speak to Haskell because I've never used it in a work context. I have extensively used Python and Go in both small and large codebases, however.

1\. Long-term supportability: I'd definitely favor Go here because of the type system. I work(ed) in large Python codebases that deteriorate because ensuring correctness requires enormous amounts of test coverage, and refactors are absolute nightmares. People tend to rewrite code instead of refactoring because it's too difficult to figure out what on earth is going on. Deployment and cross-compilation is also a breeze with Go binaries, which has been another historical painpoint with Python.

2\. Bugginess of typical code generated in the language: Favor Go for the above reasons. When the code really has to work, I choose Go. If I had more Haskell experience (and if it were a nice language to deal with), I'd probably favor Haskell for its correctness, because I still run into annoying nil pointer exceptions and array out-of-bounds in Go relatively often. I use Elm (Haskell-influenced frontend language) and love it for its lack of runtime errors.

3\. Availability of developers: I'm sure there are more Python developers than Go developers. I work with data scientists, and I don't know many who are comfortable in a Go ecosystem, so if you're hiring lots of scientific computing folks, I'd go with Python. In terms of software engineers, when I've hired folks, a lot have expressed particular interest in working in Go even with no prior experience, which is a good signal. Easy for Java/C-style programmers to pick up.

Note that: You can do both/all three. We extensively use Go for systems building, and Python for data science.

<comment><USER7> As for 1), if you can use Python 3.5+, and the native type hins, you can use mypy to do type checking, and give hints to developers/ide's about acceptable inputs :

        def greeting(name: str) -> str:
            return 'Hello ' + name

[https://www.python.org/dev/peps/pep-0484/#non- goals](https://www.python.org/dev/peps/pep-0484/#non-goals)

<comment><USER8> AFAIK this doesn't imply static type checking though. The types are at best checked at runtime, aren't they? If so, it doesn't really help much.

<comment><USER7> It doesn't check runtime (AFAIK neither does Go, it checks compile time). In fact, Python fully ignores any type hints.

When coupled with mypy ([http://mypy-lang.org/](http://mypy-lang.org/)) they can be used to do type checking at "compile time", and with DropBox's pyannotate ([https://github.com/dropbox/pyannotate](https://github.com/dropbox/pyannotate)), they can even be auto generated for existing code.

I'm not saying Python with type hints is better than a statically typed language, merely suggesting a possible solution if Python ends up being the preferred language.

Personally i love Go for the things i've used it for, and i've written and maintained large code bases in Python, and hated every minute of it. The same can be said for large code bases i've written in C, or even Java.

I've written kernels for GSM mobile phones, software for sortation devices (airport baggage sorters, mail sorters, etc), banking software, and despite our teams best intentions, given enough time and customization to meet customer demands, there is always some remote corner of the code that ends up as a "steaming pile"

</comment></comment></comment></comment><comment><USER9> Ask your data scientists, who already use Python.

If they are opposed to Haskell or Go, then what are you going to do - <USER3> them? Are you budgeting time/money to retrain them?

Your customers don't care what you use, unless you are selling them the actual software. (But then you would know what your customers want, and wouldn't be asking this question.

If you use language X because of a perceived marketing advantage that your customers will see you as "a cutting-edge, next-generation company" then can you estimate how much that marketing is worth? And compare it to other marketing approaches?

My view, as a long-time Python user, is of course Python.

<comment><USER10> It's not unlikely that data scientists can continue using Python, while development in general uses Go, though.

</comment></comment><comment><USER11> I have experience using each of these languages professionally, working in a team. Each of them have their own foibles that you'll be constantly railing against:

 _Python:_

Large Python projects require discipline. To make it work, you'll need to adopt a rigid style, like DI, and use it religiously. It can be done; people do it, but if you think using Python will lower the barrier to entry to getting on the team, think again. Large projects in any language require talented people.

 _Go:_

I don't like Go, so I have the least experience in it out of the three. There are positives, like fast compile times, but lacking generics and exceptions just makes Go annoying to me.

 _Haskell:_

I have written a quite incredible amount of Haskell and before using it in a team, I was a huge proponent. Haskell is a well-designed language, but suffers a few major drawbacks. Large Haskell programs can take an age to compile; this is a productively killer. Universally agreed upon good styles for writing large Haskell programs don't exist. Library support is lacking. Space leaks will bite you. I would strongly advise against starting a large Haskell project.

To wrap up, in terms of your criteria, the language you use isn't going to change things very much.

* Each language has a good community for long term support,

* Complex code in any language is buggy; simple code in any language is less buggy,

* Good developers are hard to hire,

If performance is important, Python and Haskell perform similarly for code that people actually write. Go does better.

</comment><comment><USER12> What constraints do you have? How important is scalability for this project? Do you need lots of parallelism, fast single-core execution, low memory usage, etc?

You mention long-term support. I'd have to give Haskell high marks on that one. You can use Stack to get highly repeatable builds with LTS releases of Haskell and the packages you rely on. More so than any other language I'm familiar with, Haskell does a great job with long term support and builds that should be 100% reproducible in 5 years.

As far as bugginess, Haskell obviously wins here again. If you're getting runtime exceptions in Haskell then you're doing something wrong. If rock-solid stability is important to you (and you list it as #2 on your list, so I assume it is), then Haskell is hard to beat.

Availability of developers is a tough one. Python clearly has the advantage here, despite being markedly worse on the first two sections. I don't know many Haskell developers, but the Haskellers I've met have all been exceptional software developers in general.

I find it unlikely that you're going to be able to hire 20 people who already know Haskell, unless you're willing to hire remotely. However, if you're willing to teach, I think it could work out. For example, the Elm language would be a fantastic gateway to Haskell. Build your front end with Elm and make new developers work on the front end for a few weeks. Once they're comfortable with it, switch them to the back end.

<comment><USER13> > More so than any other language I'm familiar with, Haskell does a great job > with long term support and builds that should be 100% reproducible in 5 > years.

Really? I've never used Stack, but the experience of building dependencies from Hackage has always been awful in my experience. Even if Stack did change the game (I think it pins down the exact versions of package dependencies, I would figure using third party Haskell libraries is still a major pain:

The reason is that the types in the APIs are very elaborate (elaborate types of course is generally a Haskell thing), which means very often they are not super stable. So upgrading libraries will be no fun. And you will want to upgrade, whether you use Stack or not.

(Note, I haven't used Haskell seriously in a long time. Maybe someone with more up-to-date experience can validate these thoughts).

<comment><USER12> Stack has helped things a lot. I recommend giving it a try. I've been very impressed.

</comment></comment></comment><comment><USER10> Finding good developers is a struggle, almost regardless of where in the world you've set up shop. So finding 10-20 good developers, a significant portion of whom would have to be quite senior, probably means your "3\. Availability of developers" should be "0\. Availability of developers".

Basically, any language / ecosystem that should meet your most basic business and technological requirements should be heavily in contention if it is among the most widespread in the community where you're situated. And similarly, if a language is significantly less common than a language that meets the requirements, you probably shouldn't consider it.

Whether that is Python, Go, Haskell or something altogether different, only you know.

</comment><comment><USER14> One of the chief advantages Haskell (and, to a much lesser extent, Go) has over vanilla Python is that static typing vastly improves upon #1 and #2.

If you do end up going the Python route, I suggest you enforce using Python 3 type annotations, and use an external validator (such as mypy) to try and capture as much of that value as possible.

</comment><comment><USER5> As others have mentioned: It depends on what you are going to build, so pick the tools which fits the job best. In the end, you can build good products with all three of those languages, but not every product can be built well with any of them.

 _Long-term supportability:_ As long as you are not choosing a proprietary tech like Microsoft Access, you should be just fine. There are a lot more code bases which suffer from bad quality than from abandoned base technologies. So its much more important that you know exactly how you want to use a language and let your team create rules (bottom up) on what they want to allow themselves to do and what they don't want to (like a semantic style guide), than to pick the golden language in the first place.

My advise would be: Start by building a team. The technologies will be the result of what your team is able and likes to use. One condition: Only allow technologies they have positive personal experience with (no "I always wanted to try XYZ").

</comment><comment><USER15> Go for the largest community and biggest number of mature libraries, go for Python 3 (make sure it's 3!). It's the most mainstream in your list and for data scientists it's your only choice I would also say (when looking at Tensorflow, Numpy, Scipy, Pandas etc.)

<comment><USER16> I initially read this as, "Choose Go for..." rather than "Opt for..."

</comment></comment><comment><USER17> I know it's not in the options you listed, but why not Scala?

It has the nice things of the languages above, combined together:

\- a concise high-level programming language

\- a compiler that helps avoiding bugs

\- fast runtime

\- access to a great ecosystem of libraries

(In better words: [https://github.com/scala/scala- lang/pull/852#issuecomment-37...](https://github.com/scala/scala- lang/pull/852#issuecomment-371839520))

Moreover, if you work with Data Scientists you might find convenient working in Spark's native language.

A great thing about Scala is that you can either use as a better Java (availability of developers) or go fully functional-category theory like Haskell with libraries such as Cats.

</comment><comment><USER18> Another argument for Python is The Pilot System rule from The Mythical Man- Month ([https://en.wikipedia.org/wiki/The_Mythical_Man- Month#The_pil...](https://en.wikipedia.org/wiki/The_Mythical_Man- Month#The_pilot_system)), which my experience completely supports. You need to focus on developer speed rather than execution speed or even correctness -- you will learn a lot and change your assumptions, take edge-cases into account etc. Only when you have a stable system it makes sense to start to isolate performance bottlenecks and replace them with optimised, low-level code.

</comment><comment><USER19> A very high abstraction language for the glue (python, R, lua, ...) and a close to the iron compiled languange for the heavy lifting (C, C++, Fortran, Go, Rust, ...)

or you give julia a try.

<comment><USER20> This is exactly my approach to bioinformatics. Python for scripting. Go for speed. Find it fairly easy to switch between the two. Really hope Go catches on more in data science. Go equivalents of numpy and matplotlib, and it would me massive.

</comment></comment><comment><USER21> It really depends on what you are trying to do and whether this is well- supported by the language.

Data science stuff? Python of course. Haskell has things like repa but still very immature compared to Python. You will have to reinvent the wheel a lot if you choose Haskell.

But if your developers are going to do something very different from data science, say building a typical web app, Haskell can be a good choice. As usual refer to Gabriel Gonzalez's State of the Haskell Ecosystem: [https://github.com/Gabriel439/post- rfc/blob/master/sotu.md](https://github.com/Gabriel439/post- rfc/blob/master/sotu.md)

Haskell especially excels in (2): bugginess of typical code is pretty low even without extensive unit testing; Go probably fares pretty well but Python is terrible for a large code base. But on the other hand (3) could also potentially be an issue for Haskell, depending on the geographical location, whereas Python would likely not.

Having worked (and still working) in a Haskell startup, though I believe ultimately technology doesn't really matter that much. The business is more important than the technology.

If you do choose Haskell though, my advice is that don't use too many fancy type system features. A boring business app doesn't usually need them. Stick to basic language features and perhaps just a dozen most popular language extensions; use the rest very sparingly.

</comment><comment><USER22> You should at least mention what your business is actually aiming to achieve. Are you a web app, a data science startup, a service provider with a software stack, etc.

If you're a pure data science startup, most of your talent pool will be most proficient in Python, and the highest quality APIs will be in Python.

If you're a web app, going for Go makes more sense, as the language was built from the ground up with these things in mind.

If you're business tooling or service oriented.. I'd go for C#.. it has a huge talent pool, super high quality libraries and ecosystem, etc

</comment><comment><USER23> No need to settle on one language. There is in fact room for 2 main languages (prolly some will simple come along like JS and Bash).

Python you already have, I'd not ditch it, it can live. Main thing it lacks, imho, is a type system which relates to 1 & 2.

I'd personally not care for 3 too much. You find less Haskellers, but also less competition, and according to many they are better.

I'd say all 3 langs you named allow point 1 "well enough". Point 2, I'd say: Haskell > Go > Python, with significant margins in between.

</comment><comment><USER24> Didn't see anything for Haskell so I'll do that. Good link in general would be [https://www.linkedin.com/pulse/haskell-data-science-good- bad...](https://www.linkedin.com/pulse/haskell-data-science-good-bad-ugly-tom- hutchins)

\- Python is established for Data Science vs Haskell You could use Haskell for whatever models you need (although finding 10-20 people for that might be a challenge) and it would be really easy to refactor for any changes you might have but I dunno if data science is something you'd use Haskell for. Most data science applications I can think of are either scripts to inspect/clean data (Python works well) and the rest involve a lot of trial and error (Haskell errors aren't great).

\- Haskell libraries are awesome You could use Haskell for whatever important libraries you use on a regular basis - it's incredibly easy to write APIs for different languages in Haskell (which is great if you switch languages for some particular use) and it's easy to refactor (which is important in a new company that's likely to change a lot). Also, it's a lot harder to write shitty core libraries in Haskell.

I'd honestly recommend sticking to whatever language you already have code in. If you already have python models built, stick to them!

</comment><comment><USER25> Whatever you choose, definitely pick a statically typed language if long term maintainability is more important than getting something out of the door quickly. Maybe a good middle ground would be python using mypy (type annotations) and if you can get any benefit from using the ORM, and the admin +and thus you are using a relational database) and building some kind of mostly CRUD app.

Nowadays, I'm in love with Typescript. Been using it for about 3 years and with the stricter settings it can be pretty safe, makes it very easy to refactor, vscode provides an "intellij and Java" like experience in the tooling side of things. No need to deal with threads, etc is a plus. No callback hell given asynchronous/await. You can use it for the backend and the frontend. Works wonderfully with react.

And if you really need performance and want something more "serious" and stable than the Js ecosystem, I can't recommend enough Dropwizard. Modern Java is not bad at all, and always you can use kotlin if you don't want to use Java for any reason.

</comment><comment><USER26> I've been in a similar situation (choice between Scala / Python / Go), the first person I hired was a Go guy so that became the default. We ended up using Go for APIs / web stuff and Python for data science and modelling.

</comment><comment><USER27> With Python your will be more agile. Python have many tools for you teams

\- Data Science: Pandas, Scikit-learn, Numpy, ... \- Web (Django,..) \- APIs (Flask,..)

Also many Artificial Intelligence Tools and Apis of other services have support for Python.

The size the community is also very important. When There are a big community is more easy to find developers and events/meetups where the community talks about Python and use cases.

Haskell is also a good lenguaje and easy to learn but Python and Haskell are languages with differences [https://wiki.python.org/moin/PythonVsHaskell](https://wiki.python.org/moin/PythonVsHaskell)

</comment><comment><USER28> I apologize for going off topic here by saying go for language number 4. but hear me out.

I have been struggling with my business vs pleasure languages for some time now. I work 95% in C# but whenever I find willpower to do some hobby coding I go for Haskell.

Every time I go for a new hobby project after not coding in Haskell for a while I have to go through the hurdles of remembering how to set things up, downgrading from Visual Studio to Visual Studio Code with some broken Haskell language extension and last time before I started coding my new hobby project I asked myself: What would it take for me to make C# as lovable as Haskell.

I came up with these things which annoy me most (I know everyone has their own list): 1\. Lack of higher order types 2\. Lack of syntactic sugar for partial function application et al. 3\. Lack of GADTs 4\. Still waiting for those nullable reference types.

On the other hand I would get: 1\. Great language server with support for refactorings, formatting etc. 2\. Test tooling and frameworks and performance analysis tooling and frameworks. 3\. Way bigger ecosystem of open source libraries.

While I see a reason to go for either C# or Haskell, I really don't think it's worth going for Python or Go instead in most cases. I just need a better type system than what Go has to offer (and Python doesn't do any type checks without 3rd party support). Hell, I'd go for TypeScript or PureScript before these 2.

C# has grown a lot in the past few years. With C# 7 you have all those fancy things like local functions, pattern matching, deconstruction, async improvements etc. You have a stable language and ecosystem, open source compiler and language server (Rosyln), free editor support if you want to save (Visual Studio Code) or if you want enterprise tooling you can go up to Visual Studio Enterprise. With .Net Core going into 2.0 the coverage of .Net is really broad, and Entity Framework and Asp.Net are being rewritten from scratch for all platforms. It's easy to do foreign language interfacing if you want to use some highly performant lib like LAPAC or something and someone usually already wrapped around it.

Btw, if not Haskell, check out PureScript

<comment><USER29> I think haskell is rapidly improving in this area. It suffered from every editor having it's own home-grown backend. Haskell IDE-Engine [1] is becoming quite stable in my experience (using it myself) and while providing all the basic features, it's based on the Language-Server-Protocol and thus has various plugins for your favourite Editor (vscode, vim, atom, sublime etc. I personally use vscode).

The development is also quite active and not run by one person anymore.

I am quite pleased to be honest.

[1] [https://github.com/haskell/haskell-ide- engine](https://github.com/haskell/haskell-ide-engine)

</comment></comment><comment><USER30> It depends a lot on what you are building. I'd recommend Python in general as it has more support but don't limit yourself to it as there might be some parts of your project were Go or Haskell can be more powerful.

</comment><comment><USER31> Use the right tools for the job. If you are running your Python models in containers anyway, a suitable API will work with any backend language. Go and even the JVM (Java / Scala / Kotlin) ecosystem are great candidates. Our stack uses Python (models deployed as dockerized WSGI applications) for machine learning and web services written in Java for the backend. It is relatively easy to get developers who are comfortable in the JVM ecosystem and the tooling available makes it easier to build robust systems.

</comment><comment><USER32> Who/what company is using Haskell at work? I'm really interested how/why it would be used those days.

I guess there are domains where it's adequate, but what are those?

<comment><USER12> Haskell can be fantastically fast (rivaling C for some tasks), and nothing can beat it for writing parsers. Relying on lazy IO can be risky if you don't know what you're doing, but I've been able to write log parsers that can crunch multi-gigabyte files as fast as my SSD can read them, all without ever going over 4MB of RAM.

Plus it's incredibly stable. Once you learn to avoid a few sharp edges (head, !!, etc.) you should never encounter an exception at runtime. Literally never.

</comment></comment><comment><USER33> Python because that's what your team knows. If they aren't already they probably should use Jupyter, pandas, numpy, ...

Then sprinkle it with a bit of Haskell on the stable algorithms for speed and correctness reasons. Haskell has fantastic abstraction and testing capabilities.

Go is probably not going to sit well with data scientists due to the lack of generics. It's a good language for API and CLI but not so much for developing generic algorithms.

</comment><comment><USER34> Python is excellent for prototyping and small projects. When projects become older and bigger, the lack of strong typing makes maintenance very difficult. If you can keep your projects small, I recommend python. If your project needs to become big, why not using java? Even if I really do not like Oracle, the language (and tooling) works very well for big projects and java developers are as easy to find as python developers.

</comment><comment><USER18> Python for all of the above.

To be more specific: Python 3.6, with type annotations and unit tests, and good libraries (pandas and others for the data, Tornado for Web, SQLAlchemy for databases etc).

But it's much more important to get your architecture right, to know exactly what is the data flow and what is supposed to happen when and where. No single language will give you answers to that, while the architecture might decide the choice of language(s).

</comment><comment><USER35> My argument against Haskell is that you are likely to build the wrong thing righter. My experience watching those around me is that it takes longer to write, but 'if it compiles, it's correct.'

The problem is that you probably don't know what you're building, so you would want a more flexible language.

I would lean towards python for all things data science, and go for infrastructure.

<comment><USER36> That's interesting because my experience is the opposite. All code needs to change and grow, and Haskell's type system protects the functionality while allowing rapid iteration. I currently work in Python and I've worked in Haskell in the past. I certainly would prefer to still be using Haskell.

</comment></comment><comment><USER37> I'd choose Go. Has long-term support from Google. Generally easy to learn. Many less bugs in my experience than Python. Don't know enough about Haskell to comment.

</comment><comment><USER38> Haskell. You'll be in a niche but a good niche to be in.

</comment><comment><USER39> Python isn't strongly typed so when your codebase grows it tends to be less maintainable than strongly typed code, unless you have a lot of test coverage. But still "doesn't compile" is a very strong indicator your code isn't right.

I would expose the Python code using Flask microservices and do the rest in either Go or Haskell. But I have no idea what needs to be built outside of the data science part. If you have lots of small moving parts you can get away with using Python everywhere since you'll not end up with big balls of code.

<comment><USER40> Actually, Python is a strongly typed language. What you mean in your comment is a statically typed language, which it's not.

</comment></comment><comment><USER41> Why not Kotlin?

<comment><USER23> I really like Kotlin too. Not very well established in data science though (maybe through Java interop, but Java is also not know for that application)

</comment></comment><comment><USER42> My default position for most business tasks would be to do this with Haskell. You asked for the three criteria: 1\. Haskell as around for longer time than the other two options. It will enable new people to quickly grasp your code base, so even if some core members leave the team the system will support them actively.

2\. A true winner. Haskell allows for using very abstract and generic code. If this works then it can be used in many contexts. In Go and Python your devs will write more low-level code that is less reusable. Just think about writing a function that adds 10 to its argument. In Haskell: add10 = (+10)

You can easily call this to add 10 to a number. You can never make a type error with this. But now: what happens if you are reading numbers from some incoming bad data? You may have been able to read a number or not. In Python you may have a value `x = None` and in Haskell x would be `Nothing`. In Haskell you can make your `add10` into a very reusable component which we call f: `f = pure . add10` and you can use it like this:

x >>= f

And it will work fine. In Python you need to write a new function which first checks if its argument is None and if yes it will return None, otherwise it calls add10() on it.

Or you have a list of numbers and we call it again `x`. To add 10 to each element in Haskell you do:

x >>= f

In Python (and Go) you would have to write a function which will map over x and apply add10 to each element.

What if you now have a function which may either return a number or an error message? In Haskell such a value can be used like this:

x >>= f

In Go or Python you would have to write a function which first checks if x is an error message and if yes returns it or otherwise calls add10() on its argument.

What if you wrote a function `x` which reads a number from the keyboard and returns it? In Haskell you would use it like this:

x >>= f

In Python you will first have write a function which calls x and then makes use of the return value.

In Go and Python you would have to write several different implementations to handle different contexts (absense of values, error handling, IO, DB requests, non-deterministic values, etc) and every single time they would look different. In Haskell this function will always have this body:

x >>= f

And this is only the beginning. Haskell allows you to write less code than dynamically typed languages. But your code will run very fast and have way less errors. In Python every function call needs to be looked up at runtime first. In Haskell you go to the function definition and save much overhead.

From my experience in 2017 with our production system was that nearly every bigger problem was due to some type error. Nearly always! This is what we get from a dyanmically typed language. The initial development time may be a tiny bit shorter, but then you will pay this many times with more debugging time and with time to write more tests. Only tonight one colleague had to stay some extra hours in the office because there was some strange bug in the Python code.

To outperform the competition you need to write ultra stable code that runs fast. Neither Go and certainly not Python can give you this. For scripting this is of course different. Our data scientists use R and this works fine for them. But with Haskell you can write very generic code, but without magic involved. In every single case you will know _perfectly_ what situation you are in thanks to the type system.

Your point 3: If you've got such a nice budget go visit some headhunter and try to find out what they have to offer. I can only say that I know people who are willing to move to get a Haskell job. You may want to consider to have some remote positions. But you may also need fewer Haskell devs because they will be more productive.

One other thing: nowadays Python and Go are pretty common. People learn it because those are popular languages and because the market has a demand. The days when Python was considered an esoteric language are long over. Haskell is learned because people are deeply interested in programming and not out of some necessity to earn money. Those might be the guys you are after.

</comment><comment><USER43> For data science, python is the strongest language right now due to massive library support for anything you want to do. Its also the easiest to understand and find developers for (from your list of languages).

Go is also nice and will bring you support for types and high er runtime performance (but slower development speed and maintenance speed).

Haskell will be hard to find developers for, but the ones you find will be very good. But getting a team of 20 to use haskell will be a great challenge, and also the library support for data science is tiny.

<comment><USER12> It sounds like they already have a data science team, and they'll continue using Python. The OP seems to be talking about building a team of non-data- scientists to do UI, data fetching, and other user facing stuff. I don't think suitability for data science is a factor.</comment></comment>


Google Treasure Maps - <AUTHOR> http://maps.google.com/maps Correct, go to Google Maps and hover over the satellite option, you should see a treasure option appear. <comment><USER2> Anyone know where the treasure is? Make sure you check out street view too.

</comment><comment><USER3> WTF?

Google maps, for me and I think for vast numbers of users, has always been a zero-bullshit application to use when you need to quickly find specific location or directions, where _pertinent_ information is displayed and "frills" stay tucked behind menu selections.

Even a small amount of cruft degrades the user experience. I don't need stupid ass April Fool's day pranks from Google. It is not cute and I am not amused. Corporations suck at humor anyway.

Even more disturbing is that somebody at Google dreamed this up, and got together a team of engineers to crank this out. And at what cost in labour? 100's of thousands? Don't they have better things to do?

<comment><USER4> > Even more disturbing is that somebody at Google dreamed this up, and got > together a team of engineers to crank this out. And at what cost in labour? > 100's of thousands? Don't they have better things to do?

It's an advert to recruit staff. Google wants good staff; that costs money; a good way to attract some staff is to show fun neat projects.

<comment><USER3> I don't see how an unfunny internet-scale April Fool's prank recruits top- talent.

What does it recruit for? People who have a bad sense of humor?

... and yes, I am still bitter about google reader.

</comment></comment></comment><comment><USER5> Again...</comment>


Ask HN: Amazon flexible web payments? - <AUTHOR>

Have any of you used the new Amazon payment system? Any experiences and pros/cons you could relate to us?<p>Referring to the service here, of course: http://www.amazon.com/Flexible-Payments-Service-AWS/b?ie=UTF8&node=342430011 <comment><USER2> [http://www.gabrielweinberg.com/startupswiki/Ask_YC_Archive#t...](http://www.gabrielweinberg.com/startupswiki/Ask_YC_Archive#toc73)

<http://news.ycombinator.com/item?id=47958>

<http://searchyc.com/flexible+payment>

</comment><comment><USER3> we at tipjoy are designing a new payment system. If you have any ideas or design requirements for an API, especially for micropayments, let us know: <http://tipjoy.com/feedback>

I've used both PayPal & Amazon's FPS. I would accept both if only because enough people feel strongly about one.

<comment><USER4> Unfortunately you can't get paid through tipjoy... Thought about moving your country to a different country where you could actually process payments easier than in the US?

<comment><USER3> Actually, you can get paid through Tipjoy.

You can get an Amazon gift card, and we'll expand to other kinds of gifts cards. We'll move on to actual cash once we're licensing as a money transfer agent. This will happen soon because we're in the process of raising a round of funding.

</comment></comment></comment><comment><USER5> I would love to hear anyones thoughts as well.</comment>


SFO Plane Crash In Tweets - <AUTHOR> http://www.streamflip.com/streams/59/media

<comment><USER2> Towards the end is mention of BootstrapLabs Benjamin Levy getting a CT for internal bleeding.

Seems like he was just coming back from beLAUNCH 2013 and was on a panel about Asian Accelerators: [http://bootstraplabs.com/blog/2013/06/19/nextgen-asian- accel...](http://bootstraplabs.com/blog/2013/06/19/nextgen-asian-accelerators- with-benjamin-levy-at-belaunch-2013/)

</comment><comment><USER3> Can they really detain people and refuse to let people pick up their luggage? It seems pretty clear that it was the pilot's fault, and most likely an accident.

<comment><USER4> Need to control people coming off a plane and check they enter the country correctly no?

</comment></comment><comment><USER5>
        #plane #fire at #SFO #SanFran

Is this really how people communicate on Twitter?

<comment><USER6> If you think Twitter is bad, you clearly have never used Instagram.</comment></comment>


You Don't Need More Free Time - <AUTHOR> http://www.nytimes.com/2016/01/10/opinion/sunday/you-dont-need-more-free-time.html <comment><USER2> Having been self-employed for eight years now, with all the 24/7 life/work home/office work/play crossover it brings, it's been so long since I could relate to this perspective, or experience the joy of happy hour or TGIF. I often work weekends, while am prone to accomplish very little on a random Wednesday.

It's not that I'm always working or that I'm preternaturally time-efficient, organised or productive, it's just that there are no clear boundaries between work and non-work hours (for good or ill), nor between most friends and colleagues.

Maybe this doesn't apply to most people, but with the proportion of the economy accounted for by solitary freelancers expected to rise, I would think I'm not the only one who doesn't even remember what weekends or holidays are anymore. If so, it seems to me that a more enlightened and forward-thinking perspective would take into account the fluidity of work-life space for many Millennials (and beyond), rather than trying to shoehorn us back into mid 20th century big-corporate life rhythms.

EDIT: My personal investment in that viewpoint has been largely about finding better workplaces and better ways to work, e.g. [http://likewise.am/2015/12/18/why-i-love-industrious-and- abo...](http://likewise.am/2015/12/18/why-i-love-industrious-and-about- coworking-and-offices-more-generally/)

<comment><USER3> I feel you. I'm a non-24 so regular office hours are often problematic for me. When I was self-employed, I'd just work whenever I would feel like, be it regular hours or weekends, day or night. I'd accomplish a lot more because I would simply be in the right mood for work at that time.

I tried a 9-5 "flexible" job (remote foss work) for a year or so and was often extremely unproductive, sometimes for several weeks. It just clashes with the way I operate.

For most of the past year I've been trying to follow my github streak to maintain the idea of doing a little work every day, no matter how small ([https://github.com/jleclanche/](https://github.com/jleclanche/)). It's been an incredibly productive year and I've never felt unproductive like I did before. I haven't felt the need for holidays because my "work days" are not tiresome. I still take holidays sometimes, as long as I can get one small piece of work done during the day, even if it only takes 15 minutes.

I kinda miss freelancing, although closed-source work makes me itch nowadays.

<comment><USER4> You might checkout Redhat and Mozilla. I've heard nothing but good things from people working remotely at both orgs, and they have FOSS projects for people to work on.

</comment></comment></comment><comment><USER5> Being unemployed seems like a very different situation from having one more day off per week. If I had one more day off, my life would be the same in terms of social connection, except that I'd have more time to relax, recharge, and engage in solitary hobbies. The people I've worked with who have had Wednesdays off certainly weren't bored on their days off; they were giddy and triumphant on Tuesday afternoon and would spend the free day kayaking, fixing around the house, reading, etc.

<comment><USER6> This resonates. Especially since having a kid, the tension between solitary and family activities at the weekend has been a real struggle.

<comment><USER5> If I ever get married I'll put an alone day clause in the contract. I love you but I need to get away from _everyone_. It can be hard to say without seeming like you're saying "you're annoying me" but there's just something different about being _alone_. At least if I have a meditation bench, there's that.

<comment><USER7> The problem is that if you have kids, it's going to be almost impossible for both of you to get an alone day and still have time to do things together.

<comment><USER8> Yep, that's probably a big reason people just aren't having many or any kids these days.

Back in the "old days", people lived with multiple generations under one roof and with their extended families. So raising kids was easier because you had a lot of help: grandparents, uncles/aunts, etc. Then the "nuclear family" came along in the 50s and things started falling apart. It was OK for a while because women were relegated to near-slavery, but then things changed and we had two working parents, and then there wasn't enough time to parent properly.

</comment></comment></comment></comment></comment><comment><USER9> > _it's not just that we have a shortage of free time; it's also that our free > time, in order to be satisfying, often must align with that of our friends > and loved ones. We face a problem, in other words, of coordination._

Isn't it obvious that if we all get more free time, it will align with others much more easily? So, it's not that "you don't need more free time", it's "you all need more free time".

<comment><USER10> Assuming that the activities that you find satisfying involve interacting with other people.

I'm pretty psyched when I have more solitary free time that I can devote to reading, or working on my own coding projects, or going hiking with my dog. Or just being free to deal with appointments and errands outside of the tiny windows of time that intersect between the business hours of other entities and my pre/post work hours and lunch breaks.

<comment><USER9> > _Assuming that the activities that you find satisfying involve interacting > with other people._

I'd venture to say that for the majority of people, that is the case (the activities that they find satisfying involve interacting with other people). I mean, even introverts go on the internet and enjoy stuff involving interacting other people all the time, the just don't do them in close contact.

But even things that don't involve other people directly (present or remote), they do involve other people in making them. E.g. reading a blog or a webcomic or listing to music, still involves these other people (its creators) making those things.

Hence, when everybody gets more free time, then you get more free time to e.g. read, and others get more free time to write stuff that you'll eventually read.

</comment></comment></comment><comment><USER11> tl;dr - Free time is better when other people have the same time off as well.

This feels like a bit of a no-brainer to me, but that doesn't mean more time off wouldn't be useful. Saturday and Sunday are usually spent catching up on work, doing some laundry and dishes, and all the other errands we didn't have time for during the week (groceries, repairs, etc.). We have more leisure time as well, but a few hours here and there during the week are quite useful, even if nobody I know shares those hours, as they would let me shift the "boring" stuff to a time when nobody else is free.

Life is better if I can meet a few friends for brunch Sunday morning because I had time to get groceries on Tuesday and do laundry on Thursday.

<comment><USER12> Exactly! And just because free time is better when there are others around doesn't mean that extra days off aren't helpful. I'm a contractor and I regularly have a week or two off between jobs. Sure the weekend is still better than a Tuesday without work but I can take time on that Tuesday to go to a movie or a museum on my own and it feels great.

And another thing the study fails to account for is that unemployed people are less likely to enjoy their days off than employed people. Being unemployed and seeking a job is stressful, many unemployed people are concerned about how long it will take to find a new job or what kind of stress is being put on their finances. If you have stable work and get Wednesday off you can go to the spa and spend some time in the sauna to relax. If you are unemployed you are probably being frugal and know it's not wise to spend money that you may need later to pay your rent.

This article is narrow sighted rubbish trying to twist the author's research to have greater impact.

</comment></comment><comment><USER13> The study does not account for the fact that some people simply choose to spend their free time by themselves and do not indulge in 'social' activities. Including the average size of the participant's social circle and how they chose to spent their free time could have been useful.

I am sure a lot of people who travel around by themselves or spend the weekend(s) hiking/biking their favorite trail, etc. do not really rely on their free time coinciding with others'.

Thoughts?

<comment><USER14> Definitely so. For the half(?) of people who are like this, more time off from work would be valuable. It would mean more time for being alone and doing your own things. It's hard to take hours and hours of alone time if you're married with kids and you stick to the traditional work week schedule. You would basically need that "other weekend" for yourself, after having been with your family (and maybe friends) for the "first weekend".

</comment></comment><comment><USER15> "The intuitive finding was that people's feelings of well-being closely tracked the workweek. As measured by things such as anxiety, stress, laughter and enjoyment, our well-being is lowest Monday through Thursday. The workweek is a slog. Well-being edges up on Friday, and really peaks on Saturday and Sunday. We are, in a real sense, living for the weekend."

Great, another person admitting that American work culture is slowly killing people, even the people who aren't actively working. This is an impetus for change.

"This conclusion points to a key feature of the work-life problem: You cannot get more "weekend" simply by taking an extra day off work yourself. If we were to take more time off as individuals, we would be likely to spend that time, as the jobless do, waiting for other people to finish work. We are stuck "at work," in a sense, by the work schedules of our family and friends."

Yes, I found this to be true during my times of unemployment, but only if I assumed that my daytime hours had to be waiting... there are many ways to be useful during the day without a job, however that time period will not be relaxing. Sounds like "more free time" and less "time spent filling a seat" would lead to more general wellbeing in both employed and unemployed people because people would have more shared time together and less time in the stressful and mentally detrimental work environment.

My solution: make all weekends three day weekends and don't alter the amount that people are paid. Remove the outdated and harmful protestant work ethic and replace it with the German work ethic: do the work that is requested of you at maximum efficiency, then leave immediately afterward, and do not answer the phone or emails. Gutting the idiotic and nigh-suicidal affinity that people have for wasting time at work without actually doing anything would also help.

So yeah, we do need more free time, because time spent at work is typically wasted time as well as mentally unhealthy time. If everyone gets more free time on the same day, I assume better mental health would result. To be clear, we've reached the point in our technological development that this goal is eminently possible if there were political will or popular revolt.

</comment><comment><USER16> BS. I love the weekends because I can sit in my room alone coding, reading a book or watching some TV series. Lack of social interaction is the highlight.

</comment><comment><USER17> While the article's conceit that free time has more potential to make you happy when it's free time you can spend with your friends is not untrue, I think it's pretty obvious that people who are working fewer hours have more chances for their free time to intersect with their friends. If you and all your friends work 20 hours a week, but some of them have firm schedules where they're in the workplace 4h every weekday, while others are in the workplace for 8h two days and sporadic appearances the rest of the week, and whatever other configuration of that you can think of, you are all still going to have a generally higher chance of finding time to spend with each other than if you're all spending 60h working three part time jobs to make ends meet!

</comment><comment><USER18> Seems like an assumption to say that "time together" is the key difference. For example, at various times in my life when I've been jobless, I did experience similar peeks in my mood over the weekend. But I'm a solitary person and I was not necessarily spending that much more time with others. I would say that the difference was psychological. On the weekend, I felt okay relaxing because I knew everyone else was and the pressure was off of me to be looking for work. During the week, I couldn't escape thoughts about my joblessness. The article touches on this slightly when it characterizes the difference as being more in sync or out of sync with society.

</comment><comment><USER19> I'm retired and I still want more free time.

<comment><USER20> Please expand on this. Sincerely curious why/how.

<comment><USER19> Is it so hard to imagine? Like most here, I enjoy a wide variety of pursuits. I'm not sure the specific pursuits would matter; everyone can fill in their own blanks. A single pursuit could easily take dozens of hours per week or more to enjoy in their fullness. Add in physical fitness, sleep, cooking, and hygiene, and that's more time than I'm blessed with.

</comment></comment></comment><comment><USER21> "The solution might be found in a form of constraint: more standardization of the time for work and the time for life." And stuff gets even more crowded because everyone is free at the same time, yay.

<comment><USER6> Like a lot of sociological research, I don't think this was written with knowledge workers with hobbies and/or side projects in mind. Still, I found that statement deeply frustrating.

</comment></comment><comment><USER9> > _It seems obvious why working people cherish the weekend: It's a respite > from work. But why is the weekend also so important to the unemployed? The > key to answering this question is to recognize that not all time is equal. > Time is, in many ways, what sociologists call a "network good."_

Maybe, besides the "network good" thing, it's also the fact that the workdays painfully remind the unemployed that they are unemployed?

</comment><comment><USER22> Sounds like a solvable problem, in theory anyway. Some sort of super-smart fuzzy logic scheduling app where you can plan all the things you want to do, and everyone who you might need to collaborate/meet with at work, all your friends you might want to meet up with at the pub or go on a hike with, your family, and everyone else relevant is on the same app.

(ok in the perfect world it wouldn't be a proprietary app, but a standardized protocol so whatever app you happen to use negotiates with everyone else's apps)

Your work hours would change from day to day and week to week, and all things might shift around (with the exception of things that can't, obviously) but that's ok.

The longer ahead you plan things, the better, since you'd give it more flexibility, and the more flexible you are, the more you earn points you get to spend when you really need them.

It would know things like traffic patterns and when things are crowded, so instead of just arranging leisure time on the same two days of the week, it would mix them up.

And of course it should also take into account the weather. I'd like as much of my actual free time to coincide with sunshine.

</comment><comment><USER23> TL;DR: We _all_ need more free time.

</comment><comment><USER24> If this writer doesn't want their free time, can I have it?

Yes I know... probably not the point of the article, but I couldn't get past the clicky-baity headline.

</comment><comment><USER25> I am a remote worker. Our team averages 15-30hrs/wk each. Some of us never get above 15. I personally average 25-30 when I'm at home, and 15-25 when I travel. I travel for about 6 months out of the year.

If I am not in someone else's company and am able to open my laptop, I'm working. What I mean by that is when most people would be lounging on their couch with their laptop cruising reddit, or watching TV aimlessly, or reading, I end up thinking about work and then just clock in. I get my general goof-off online time via my phone when I'm getting from A to B or am otherwise not in a position to open my laptop.

This means I very often end up working 7 days a week. I think a few times this year I hit 38hrs in a week. I generally keep track of work via my phone when I'm unavailable or working less and if something pops up I clock in and take care of it.

This is just my nature and I'm happy I've found a job that gives me this type of flexibility. Filling work time into the bits of downtime that would otherwise be wasted allows me to match my free time to those that I love, like my father or partner (who is a schoolteacher and has frequent vacations).

Maybe this isn't for everyone, but if I had to back to a traditional work environment I'd probably lose my mind. The ability to travel, visit my father for a few weeks, take a 10 day vacation with my partner multiple times per year (plus summer/winter break), wake up whenever I want, work out for 3hrs 3x per week, followed by an hours at the pool - that's amazing. I wouldn't trade this for anything.

I think I am much, much productive in this type of work environment than any that I have ever had. It makes my work better, more focused, and keeps me happy & loyal. Flexibility is king.

</comment><comment><USER26> I think part of this is the cultural contemporary occidental focus on that some activities are inherently social. I think part of the decrease in happiness in unemployed people during weekdays is just the fact that they tend to not do anything they enjoy, because they think that they would not enjoy doing it alone.

[http://www.theatlantic.com/business/archive/2015/05/the- unex...](http://www.theatlantic.com/business/archive/2015/05/the-unexpected- pleasure-of-doing-things-alone/392486/)

</comment><comment><USER27> What works best for me: a loose 9-17 that can be freely adapted according my daily needs (8-16, 10-18, 12-20, etc). Like this it seems that I have always time for everything.

</comment><comment><USER28> This study is flawed in so many ways, my guess is a lot of things are affecting jobless people's emotional states besides just when their friends are also free.

</comment><comment><USER29> I'd love to start a trend replacing "work" with "spending time at the workplace".

</comment><comment><USER30> > _The weekend derives much of its importance from the fact that so many > people are off work together._

Oh, goodness no. The weekend is enjoyable in large part it because of those who work to keep businesses open.

</comment><comment><USER31> This logic in the article is so shaky. Because unemployed people also feel sad on M-Thursday is a reason why an employed person doesn't need more free time? It doesn't make sense.

</comment><comment><USER32> My first jobs were retail. Everyone had weekend off except me. I hated it. Ten years in retail, and I dreamed of the day I would have a "career" and good pay and weekends off to enjoy it all.

Then I got a career. Now everywhere I go is packed with people and lines.

A trip to the grocery used to be on Wednesday around 2pm. I could fill a cart with anything I needed and get in and out in minutes. Now I go after work and wait in the "express" lane with my under 20 items for upwards of half an hour.

I used to go out on a Tuesday night, because that was my weekend. Two for Tuesday everywhere! Happy hour, all the time. Fast service. Hot food. Now, I have to make reservations in advance to wait 20 minutes for a waiter, because the restaurant is short staffed. God help you if you forget the reservations, or the place doesn't take them. You'll easily wait an hour for a table on a Friday night.

I take a weekend trip to a theme park and I have to park a mile away from the tram which is a mile or more away from the gates, where there are lines to get tickets and more lines to ride the rides. Just getting to the parking spot requires slow traffic. Lines of cars all doing the same thing.

I've considered asking if I could work weekends at my career job. It would be quiet on Saturday and Sunday. I could get a lot of work done without tickets and support calls coming in all day long. But then, who would handle the tickets and support calls if I'm not there?

What a pipe dream... To have a middle of the week "weekend" again would be so grand!

<comment><USER33> > _Now I go after work and wait in the "express" lane with my under 20 items > for upwards of half an hour._

wow, sounds like there's some space for competition in your country's supermarkets!

<comment><USER34> The line for Trader Joe's in Union Square NY always amazes me—it often has lines just to get _inside_ the store. [https://www.google.com/search?q=trader+joe%27s+14th+st+line&...](https://www.google.com/search?q=trader+joe%27s+14th+st+line&num=20&source=&tbm=isch)

<comment><USER35> Are there no other decent supermarkets around? I certainly wouldn't stand in a line for the supermarket on a regular basis no matter how good they are.

<comment><USER36> Its in the middle of Manhattan, so there are grocery stores everywhere - Trader Joe's is just a chain with a particularly strong cult following, and there are fewer of their stores in Manhattan compared to a lot of their competitors.

(I like Trader Joes well enough, but even when I lived very near to that specific store I'd make a conscious effort to avoid it. Proximity to New York University's dorms seems to do it no favors on the already very busy 14th St corridor.)

</comment></comment></comment></comment></comment><comment><USER37> This so does not apply to people with small kids.

<comment><USER38> As the father of a 2yo... You are correct sir.</comment></comment>


iOS iBeacon Drawing App - <AUTHOR> http://kennethshawfriedman.com/welcome/2014/8/17/demo-two-handed-ios-drawing

<comment><AUTHOR> OP here. Working on this app to be released soon, but the more interesting part is the multi-device concept. Would love to get some feedback on it.</comment>


Pugpig - <AUTHOR> http://pugpig.com/ <comment><USER2> Thanks for posting this. If anyone out there is testing our brand new framework, I'd dearly love to know how it goes, and help you out if you hit any issues.</comment>


Hobbyist builds working quarter-scale V8 engine from scratch over two years - <AUTHOR> http://boingboing.net/2013/10/21/scratch-built-thoroughly-docu.html

<comment><AUTHOR> original forum thread: [http://www.homemodelenginemachinist.com/f31/1-4-scale-v8-fir...](http://www.homemodelenginemachinist.com/f31/1-4-scale-v8-first- project-13548/)

video: [http://www.youtube.com/watch?v=7EGXo5HwIHk](http://www.youtube.com/watch?v=7EGXo5HwIHk)</comment>


Linux from Scratch - <AUTHOR> http://www.linuxfromscratch.org/lfs/ <comment><USER2> I had a lot of fun doing this. You really get a feel for the evolution of build systems -- from older software that uses automake/make to newer programs that use meson/ninja/cmake etc. It was also cool to learn how to bootstrap a bespoke set of development tools tuned for your hardware.

It took me a solid weekend to get everything built. I was able to get a basic LFS system built on a Saturday, and on Sunday I did the "Beyond Linux From Scratch" edition. At one point I got stuck trying to debug a weird interaction between systemd and PAM that took me a while to unravel. That was humbling, I thought I knew just about everything about Linux, but turns out there are large areas where I just don't have a clue.

The docs are well written and maintained, so there wasn't a lot of frustration there. Even if you're not an old hand at Linux you can likely get pretty far by just diligently following the instructions.

I struggled a lot more trying to make a decent desktop environment than I did getting the OS setup. I spent so much time trying to get a nice-looking toolbar (polybar) and basic stuff (like how patched fonts work) took me an embarrasingly long time to sort out. I also didn't know what a compositor was, or why you might want one. I enjoyed figuring out the basics of compton, which allowed me to get cool transparent backgrounds on windows[0], although I never did quite figure out how to get rounded corners.

[0]: [https://muppetlabs.com/~mikeh/spudlyo.png](https://muppetlabs.com/~mikeh/spudlyo.png)

<comment><USER3> How do i get started too? Where should i begin with?

<comment><USER4> I don't know if you're referring to the Linux From Scratch part or the desktop customization part of the comment you're replying to, but if latter:

Visit here for inspiration: [https://www.reddit.com/r/unixporn/](https://www.reddit.com/r/unixporn/) (safe for work, despite the name).

Pick a window manager, learn how to use it, and go from there. Popular options are i3 (i3-gaps if you want some space between windows), sway (i3, but for Wayland), bspwm, awesome wm. Usually they're used in combination with polybar (highly customizable status bar) and rofi as an application launcher.

<comment><USER2> That's right, /r/unixporn influenced me quite a lot. I read a lot of folks' dotfiles that were posted there and was inspired by the screenshots. Because I had built a lot of software with LFS, I wasn't at all afraid of tackling building custom versions of i3 (i3-gaps) and compton (compton-tyrone) to get visual bling.

</comment></comment></comment></comment><comment><USER5> I tried to go through this a few years ago. The time commitment is huge, especially if you really want to understand all steps in detail. In the end I lost interest because it turned into a mindless command-copying exercise for me. My only real take away was a much greater appreciation of the complexity of an operating system.

Has anyone followed this from start to finish and can now comfortably compile their own linux kernel from scratch?

<comment><USER6> I did this 15 years ago, before I gave gentoo a spin. I compiled my kernel for many years (make menuconfig).

Bottom line: It's not worth it.

I use debian now.

<comment><USER7> I moved to Ubuntu for political reasons outside the fault of gentoo. I really miss the ability to easily patch core libs with custom patches, and portage (when it worked) was a lot easier to deal with than apt.

<comment><USER8> Care to elaborate on the "political reasons"? I've never heard of someone moving _to_ Ubuntu for political reasons.

<comment><USER7> If I get breached as a result of using gentoo, it looks bad. If I get breached using Ubuntu it's at least along the lines of 'well everyone else is using it anyway'. Semi safety in numbers, semi 'nobody got fired for buying an IBM'.

It wasn't my call, and it's a defense move rather than an opinion on the state of Gentoos security. I know they take things very seriously, but my assertions aren't enough to make my employer feel comfortable.

<comment><USER9> Amusing, in this context, that Google decided to base ChromeOS on Gentoo.

<comment><USER7> Sure, but I'm sure they leverage portage due to its sheer power and additional scrutiny over any ebuilds they source from upstream. Which, to be clear, the threat model assessed internally is intentionally malicious packages which are unintentionally merged into the portage tree by legitimate and well meaning developers. There's no immediate issue with the portage or gentoo developers and package maintainers themselves.

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> Related from a month ago: [https://news.ycombinator.com/item?id=23787526](https://news.ycombinator.com/item?id=23787526)

If curious see also

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

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

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

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

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

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

<comment><USER2> Thanks Dang!

It's interesting that in 2016 the top comment was about how out-of-date the documentation was, which made it very challenging for the novice to approach. When I did it in 2019, my experience was very different -- I marveled at the quality of the instructions and documentation, as well as how up-to-date it was.

In fact, just this week I was googling for some information about building GPG without having to deal with generating PDF documents, and I stumbled upon an LFS GPG page[0] that had been updated that day. There seems to be a fairly active community who is maintaining the guides.

[0]: [http://www.linuxfromscratch.org/blfs/view/svn/postlfs/gnupg....](http://www.linuxfromscratch.org/blfs/view/svn/postlfs/gnupg.html)

</comment></comment><comment><USER11> I think this is something every computer/tech/future programmer should have done at least once, even if you give up half way.

I did this when I was in early high school. I just got into Linux, and this was super fun to do, it really showed me how an operating system worked and all the moving pieces and how they all fit. I did it all on a 1ghz machine with 256mb of ram, and some slow DSL. It took me a 4-5 days back then, but it was a blast for me.

I haven't done it since. But today I am a senior devops engineer, and that knowledge was so valuable to me today. It is so much easier for me to reason about systems and linux in general.

Honestly, I am really tempted to go through this again as a weekend project in a VM or something

<comment><USER12> Maybe. I did it and while it's certainly educational, most of it feels like a waste of time. The bulk of the entire process is running 'make' on random things and waiting. It's fine as a teenager (when I did it lol) but as an adult with a job? There are better/more productive ways to spend your time if you want to learn more about Linux probably.

<comment><USER13> What would you suggest as an alternative? I've never done LFS. I'm intrigued by it.

We use Debian in an IoT product similar in footprint to a pi. I know Linux OK, but some areas are still pretty opaque to me (or evolved, once upon a time I knew unit pretty well, systemd, I can manipulate it, but I'm no guru).

So would LFS be a good fit for me? Or better some other educational adventure?

<comment><USER14> _IF_ your hardware is supported by NetBSD (to whichever necessary extent and use case) it offers the most advanced build system in my experience.

Think of it like the complete LFS, with integrated basic X11 (optional), automated. Either selfhosted from installation, _OR_ crosscompiled even from Microsoft Windows to whatever else is currently supported by it. _One_ single way to operate on diverse systems. Even more advanced than the build system of FreeBSD, by which Gentoos Portage has been inspired. Similar thing for its _PKGSRC_ , which is the package manager for anything not contained in that base system.

( [http://pkgsrc.org](http://pkgsrc.org) / [https://pkgsrc.se](https://pkgsrc.se) )

If you ever experienced that, you realize how big the mindfuck of _any_ Linux is, and wish for being in a parallel universe where something like this would be the basic standard to build upon.

Skim the [http://netbsd.org/docs/guide/en/](http://netbsd.org/docs/guide/en/)

edit: To be clear, this is not the normal mode of operation, you don't have to do this to use it, but it is integrated, so that you can generate install images from which to bootstrap other systems.

[http://netbsd.org/docs/guide/en/part- compile.html](http://netbsd.org/docs/guide/en/part-compile.html)

</comment></comment></comment></comment><comment><USER15> On [http://www.linuxfromscratch.org/lfs/view/stable/chapter06/pk...](http://www.linuxfromscratch.org/lfs/view/stable/chapter06/pkgmgt.html):

> Symlink Style Package Management

For this I highly recommend [https://zolk3ri.name/cgit/zpkg/](https://zolk3ri.name/cgit/zpkg/) which I have been using for years now. It works wonderfully.

Environment variables and their defaults:

        ZPKG_SRC = ~/.local/pkg
        ZPKG_DST = ~/.local
        ZPKG_DB = ~/.db

It means that if you install anything from scratch, you have to `make install` (or the like, depending on the build system) it to, say, `~/.local/pkg/foo-1.0` and then run `zpkg link foo:1.0` to install (i.e. link) the "package". After that you just have to make sure you have added `~/.local/bin` to your `PATH` environment variable, and `~/.local/man` to your `MANPATH` environment variable (in your `~/.bash_profile` file). Seems to do the job. It does lack a README file for which I may contact the author. In any case, `zpkg --help` should be of tremendous help.

By the way, I have noticed that someone created a package manager with the same name, but its initial commit was in 2019, while this one's was in 2017.

<comment><USER15> Oh and yeah, it is written in OCaml, so you do need to have the OCaml compiler installed. I recommend doing it via `opam`, but your Linux distribution's package manager will suffice (simply `ocaml` on Arch Linux, for example). With regarding to `zpkg`: if you run into any issues, bugs, or you miss a feature, contact the author or me. You will not be able to reply to this message after some days and I do not have contact details here, so you will have to contact the author then. :D

</comment></comment><comment><USER16> The first time I did this in 2001 it took me a week. It's still up there as one of the most educational things I've ever done. A perfect graduate level class would be "here's a box full of computer parts, at the end of the semester I'll give you the grade you display on a web page served by the computer you build and compile from scratch".

<comment><USER17> So... basically pass/fail? Who's gonna get that far but type 'F' instead of 'A' into the HTML they author?

<comment><USER16> Puts skin in the game. No kidding in 1987 I actually did convince a professor to agree to an independent study course for me and a friend to build a voice synthesizer on an IBM PC proto board using the TI chipset available at the time and the only terms of the class would be that he gave us the grade my computer verbally asked him for at the end of the semester. We actually built two of them, one for each of us. It was wire-wrapped. We had no backup plan whatsoever and it was a brave/stupid thing to do, but we both got A's and the prof told us his only regret was that he didn't have us make one for him too. Even more skin was that it went into my own IBM PC, so if I blew that up not only wouldn't I have had enough credits to graduate but PCs were very expensive at the time. These days you can blow up a Raspberry Pi and who cares.

</comment></comment></comment><comment><USER18> Be careful with this! It's a slippery slope from LFS to Gentoo. I made the mistake of trying LFS once in college, and then I spent the next 10 years compiling everything from source! Beware!!

<comment><USER19> Better use a purely functional build system, like in NixOS, where you can download binaries and have the guarantee that they are the same as when you had built them yourself.

<comment><USER20> It's much closer to that than any alternative I am aware of, but that's one guarantee you don't have. It's important to limit your substituters (binary caches) to trusted servers, because Nix does not and cannot verify that the binary it receives corresponds to the source, only that the remote server claims it does. Even if the binary does correspond to the source, the build process may have picked up small details about the build system, meaning a local build would produce a different binary. Even if the build process does not pick up any such details, many packages do not have deterministic builds, meaning they might produce different binaries even if you build them multiple times in succession on your own computer.

<comment><USER21> This is true. I am a NixOS fan, but when a piece of software asks me to use a Nix binary cache it can mask problems like a private git repo or other issues that would prevent a full build without me knowing. Worse yet, a Hydra box eating it's own dogfood ...

</comment></comment></comment></comment><comment><USER22> Been there, done that. Used LFS as my main system for a while... Now I can't be bothered to even compile the kernel or, for that matter any piece of open- source software. Not that I have nothing more to learn, or I abandoned coding or even being interested in this stuff. Problem is, software today is too complex and bloated, with too much of that complexity and bloat being accidental, and therefore it is not very interesting and worthy one's time spent learning it and tinkering with unless you are paid for it. In terms of learning, xv6 seems to be a much better proposition.

<comment><USER23> I think the two are a bit orthogonal--but do have some overlap. I recently had a job where I helped out with a bunch of sysadmin stuff. A bunch of the computers had local users and dns entries set locally. The rest of the network used NIS. They also periodically rented computers and didn't have a formal install process or OS image. I also moved while working there and had to do a lot of this remotely.

Knowing how all the pieces fit together from doing LFS and how to bootstrap them was really helpful even though we never compiled anything. It also helped when things get wedged (won't boot or a GUI freezes) and you can fix it without having to power cycle the machine, losing work.

I haven't taken an OS class or messed around with xv6 (I'd like to), but I think that would help with a different set of things.

</comment></comment><comment><USER24> LFS is great. Do it once, all the way through.

Then go back and automate it yourself. Make your own build process, scripts, auto download sources and automatically apply sets of patches. Make your own fakeroot system and assemble all three pieces into a working image file, auto tar the whole thing and make it easily deployable.

That... is how you come to fully understand everything that goes into a basic bare-bones yet fully functional, <50MB Linux Distribution.

Then do it again, but with a cross compilation toolchain (CLFS but using the build tooling you've just created).

I did this year's ago for the OG Raspberry Pi. I was frustrated by the lack of a minimal distro that just had the basics for serving websites and nothing else.

Fast forward 6 months, all the above completed, amazed by how far I'd come... only to realize CentOS had been released for the RPi in the meantime.

I'll never regret that time spent, though. It really does unlock a "next level" understanding of what a distro is. There is no magic, just a lot of hard work.

</comment><comment><USER25> I never got into LFS, when I finished my build I was probably exhausted by all the sed'in and patchin' and didn't have a single clue about where the piece fit.

I did end up with a flawed system with funny bugs. I couldn't access the network with the usual tools but elinks managed to bypass something and get a TCP stack somewhere. But it failed to render properly on tty. No surprise I had no clue what I did wrong but it made me realize how much plumbing there was.

</comment><comment><USER26> Wow, this brings back memories form the days LFS was just starting. I think I have my LFS home-made CDs with source and binary tarballs in '99 and 2000: I've got tired of building everything and chasing dependencies and packages by 2001 so I moved to, ahem, Slackware. I've only switched to a reasonable distribution when Ubuntu came out and it tracked GNOME which I contributed to.

But LFS was a wonderful learning opportunity for me: it allows you to build an understanding of the nitty-gritty bits of the system, but hurdles one has to overcome are very painful for a daily system. I think things have improved a lot in early 2000s when better build scripts were introduced and you actually had links to packages you needed: back before that, there was no way anyone would build a LFS system over a weekend, as I see people reporting here (not the least because most Internet access was dial-up).

So first up: have time and desire to learn. I would probably appreciate re- doing this with systemd to really internalize how things have changed from the inittab days.

</comment><comment><USER27> I recommend this project to everyone. The experience points are worth three Linux-fu levels, easily.

</comment><comment><USER28> Did this many years ago, it's fun.

Just checked it quick again, the basic steps remain the same.

It still requires a separate partition, I would add a chapter about: how to use loop device to mount a file as a device, then how to get LFS built on that loop-file and run it inside a virtualbox or kvm, to make it non-intrusive and safe to play with for beginners.

Many beginners will install their linux under one partition, and they probably do not have a second partition to try LFS, so a file-based approach, with virtual machine in mind, could be easier to attract users?

</comment><comment><USER29> I remember doing this all the way back in 2000 on an old Toshiba Tecra 500CDT with a 90Mhz Pentium. Not sure I ever got as far as being able to run startx, because every time I'd come up with more and more weird filesystem ideas (what if every package had its own separate hierarchy and we just linked things centrally? etc etc).

I do think this is a good education, although realistically I think you will learn as much (and probably more) on Arch these days, especially if you have to create your own AUR packages for some reason.

<comment><USER30> I remember running Slackware on a Toshiba Tecra 500CDT back in 1997. Man it was like heaven back then compared to Windows 95. I forget how think they were.

</comment></comment><comment><USER31> I built a basic X-Window Linux from Scratch many years ago. Then I tried to include one of the popular Desktops and I ran into circular dependency hell

Apart from the kudos of saying "I did it." and learning a bit about the construction of GNU-Linux, there is no benefit in Linux from Scratch except as something crossed-off your bucket-list.

These days I 'buy built' and download a distro that many experts have put lots of time into producing something that I, alone, could never compete with.

</comment><comment><USER32> Do people actually run LFS systems as a daily driver (desktop or server or whatever)? I always thought it was a great way to see what it takes to put together a functioning distribution, but the LFS book's take on updates is basically that it's on you to follow mailing lists for security advisories for literally everything on your system, and update as needed. That sounds like it would take up way too much time and effort to be practical.

</comment><comment><USER33> Some of my fondest computer memories are working through the LFS guide on a home-built computer in highschool. Wish I still had the time to do stuff like that!

</comment><comment><USER34> I'm surprised it's still alive. I did it 14 years ago and I used that system for a year. It was a great way to learn a lot about Linux fundamentals. If I would do that today, I would try to use some layered FS to capture changes on from install script and archive those changes into rpm package (or at least tar archive), so everything's under control. I don't feel good just running make install which could do anything.

</comment><comment><USER35> Nice! I know the project maintainer and he is really methodical about everything he does. Nice work Gerard.

</comment><comment><USER36> I worked through this in 2001(?); I printed it all out -- on paper! --into a huge binder. Back then, monitors were small.

Was a fantastic way to learn how to grow a system. Horrible gateway drug to Gentoo Linux, of course.

</comment><comment><USER37> I remember coming back from school 20 years ago to see if Linux or glibc finished compilation.

I think is mandatory if you really want to understand how Linux base os works.

</comment><comment><USER38> Something I've been wondering: what's the difference between this and buildroot?

<comment><USER39> buildroot is used to cross-compile Linux systems. It's a tool. Linux from scratch is a guide that users are supposed to follow to learn more about Linux. It's mostly an educational tool.

<comment> yjftsjthsd-h That doesn't sound like a very big blocker; don't you "just" need someone to "package" a compiler chain?

</comment></comment></comment><comment><USER40> Is this something that will allow you to create a new distro?

<comment><USER41> It can be a first step to creating a new distribution, but most people just do it as a learning experience.

Here's one example though of someone who went on to create a new distribution: [http://www.nutyx.org/en/](http://www.nutyx.org/en/)

To create a distribution, you need a package manager of some sort to manage software updates, and while LFS discusses some possible package managers that's not really its focus.</comment></comment>


Why Open Source Your Secrets - <AUTHOR> http://java.dzone.com/articles/why-open-source-your-secrets?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+javalobby%2Ffrontpage+%28Javalobby+%2F+Java+Zone%29 <comment><USER2> Regrettably, the video and audio quality are quite poor, and the slides contain few clues as to the content. A previously posted article by Martin Fowler: <http://martinfowler.com/articles/lmax.html>. Obviously it covers different ground from a talk about motivations for opening up the design, but does a good job of describing the LMAX architecture.</comment>