The Functional Style (2018) - <AUTHOR> https://codurance.com/2018/08/09/the-functional-style-part-1/ <comment><USER2> Given the comment section is devoted to definitions, I'll add mine: the single most important characteristic of proper FP is _strictly segregated side effects_.

At a high level, many e.g. Clojure programs are indistinguishable from an OOP program. Functional composition and immutability are just superficial details - another 'skin' containing the same stuff.

Does it really matter if you expressed something as a `for` or as a `reduce`? Is local mutability distinguishable from immutability?

Worth noting, real OOP webapps do very little in-process mutability. They're 'functional': request in, response out. State actually lives in Redis/Postgres so the actual mutability story is the same for FP and OOP langs.

That's not to say this functional-ish style is wrong or wasteful. It's a nice step forward. But we really ought to appreciate "strictly segregated side effects", namely actually pure functions, without exceptions.

There's no such enforcement in a great deal of FP langs, and IMO there really should be (at least in the form of a lightweight linter) if we want FP to be genuinely superior.

<comment><USER3> > the single most important characteristic of proper FP is _strictly > segregated side effects_.

This is one of the best definitions I've come across.

<comment><USER4> If we have pure funtions, that is not "strictly segregated side effects"; pure functions do not have side effects, period.

We can segregate side effects very well in imperative code.

The segregation of side effects is clearer in a strictly evaluated imperative language than in a lazily evaluated functional language.

</comment></comment></comment><comment><USER5> I find the authors definition of functional programming really insufficient. FP should not be defined in terms of immutable state, but as mathematical functions as the basic form of abstraction, and that programs are composed as an evaluation of a single expression in spirit with the lambda calculus. Immutable state is just a correlary.

With that in mind, you really can't do FP without automatic currying and the function composition and application operators (. And $) in Haskell. Without these, you lack the key components needed to work with your only means of abstraction. Language author seem to think lambdas are enough, but if you can't compose functions to build new functions, partially apply them to get specific versions of behavior, then you aren't going to get very far.

<comment><USER6> This is a generic "no true Scotsman" argument. Not everybody shares the same definition of FP and while "My definition of FP is what Haskell gives me, and the author's definition is more akin to what Clojure and Elixir give them" is a correct statement, it's also not a very insightful point.

You can't deny that there are lots of languages and techniques that people call "functional" where the key ingredient isn't "programs composed as an evaluation of a single expression" but something else (such as "immutable state").

<comment><USER7> Elixir's got |> for composition and & for currying (as well as for lambdas); I'm not sure that's the best language example for differences (given the specific things grandparent listed of things languages are missing).

<comment><USER6> |> isn't proper partial function application. It can only apply a single parameter and you can't store a piped-into function in a variable the way you can a partially applied function in eg Haskell. Eg the following won't work:

        splitname = name |> String.split
        splitname.(" ")

Also, it's a stretch to call & currying. It's shorthand syntax for making an anonymous function. If & is currying, then the following JS code is also currying:

        const cube = a => Math.pow(a, 3)

Elixir doesn't have currying or partial function application any more than JS or C# do. If your definition of "functional" requires these features then Elixir isn't functional (and that's fine).

</comment></comment></comment></comment><comment><USER8> I definitely agree with the premise of this post. For me the sweet spot of functional programming is learning the most important principles—quarantining mutable state and side effects, declarative data transformations, higher order functions, etc.—and then bringing these patterns back into more 'practical' languages.

A good example is the immer.js library, which takes the pain out of immutability while retaining the most important benefits. Instead of bending over backwards to transform hierarchical data with lenses and the like, you just mutate a 'draft' copy imperatively within a bounded context. While it has its limits, it's often much quicker to write and easier to understand than the equivalent 'purely immutable' approach without any real downside.

</comment><comment><USER9> My natural inclination when I was younger was the functional style, but over time I've come to see it as sub-optimal for the problems of day-to-day business coding. Almost always there is state somewhere and I find the restructuring of the program flow unnatural at times where an imperative, OOP, or FP-inspired-but-not-FP-actually style would meet performance requirements while also maximizing legibility to a future programmer.

But I'm not a zealot. It's fun in the right domain.

<comment><USER10> I agree very much. Working professionally in Haskell across 3 jobs caused me to pretty much lose interest in it except for personal projects with very small scope where I can personally control all the reasons for refactoring or behavior changes.

When those things come from a stream of business problems, Haskell, I hate to say, is a poor tool, for just the reason you stated. You'll always come across situations where mutating state would make an incremental change very easy (despite being "bad practice" for long-term complexity) but where having rigorously designed a functional system, that mutation or change is now painfully hard and requires significant refactoring.

Because business pressures utterly do not care about engineering properties of the backend system, except for high level summaries of basic properties like overall cost or reliability (metrics that functional programming vs other paradigms doesn't have much impact on), you end up never being able to justify the upkeep and refactor-as-you-go workloads necessary for the functional implementation to not get bastardized into the exact same sort of spaghetti code mess you get with other languages.

In my experience, the types of errors, bugs and extensibility headaches in a business setting are not addressable with static typing, designs leveraging a type system, formal verification, or immutable design patterns. Those things are fine, not knocking them. It's just that they cannot help you for dealing with reactive business problems. They don't live up to the hype about it.

The problems are all about a sudden context change in which a previously valid set of behaviors, performance characteristics, whatever, is instantly rendered invalid because circumstances have suddenly changed, and you need to simply react to it and pray you're successful enough that the system even lives to some magical future time when you can refactor.

<comment> james-mcelwain Right, I can think of many situations where a new business requirement is like "oh, and for this client, when we do X, we also need to send them an email." OOP, for all its faults, makes this kind of extensibility trivial, where I can't imagine easily making such a change in the context of a statically typed effects system. "This function was pure and now it's not" almost certainly leads to a refactor.

That's not to say that statically typed FP _can 't_ be written in such a way to allow this kind of arbitrary modification, but then you get into the realm of finding the perfect abstraction in the type system, which is exactly the same kind of maintenance problem that OO architecture astronauts bring to a code base.

This is all to say -- we should be writing Clojure, which allows a tight focus on actual business requirements while still being flexible enough to allow you to bail out of FP patterns when necessary. :)

<comment><USER11> I'm super confused by this.

In the Haskell systems I write, this change would be trivial. It's a single line change. Maybe it's just a benefit of the particular pattern I'm using (standard Yesod handler, which if I remember correctly is just the ReaderT IO pattern), but still, it seems completely wild in my view to trash an entire language and indeed an entire paradigm because you can't imagine making the change in your example.

<comment> james-mcelwain Business logic is pure and stateless. Lifting to IO is a breaking change that may or may not require non-trivial refactoring. You shouldn't be putting business logic in your HTTP handlers.

Regardless, the point is not that it's impossible to make such a change in a Haskell code base, just that it may or may not require non-trivial breaking changes, while such a change in an OO enterprise code base will always be trivial.

There's lots and lots wrong with OO patterns, but being able to respond to changing and arbitrary whacky business requirements is a clear strength.

<comment><USER11> > Business logic is pure and stateless.

Why? From where did you invent this completely arbitrary constraint?

> You shouldn't be putting business logic in your HTTP handlers.

Why not? How else could this work? The user has to interface with the business logic _somehow_.

There's nothing at all wrong with a HTTP handler that takes in a request, delegates to a few different business logic things, and then sends a response.

Not only are you moving the goalposts with your argument, you're also coming up with things that are completely false.

There's nothing about OOP that inherently makes extending some code to send an email easy. Likewise, there's nothing about FP that inherently makes the same task hard.

</comment></comment></comment></comment></comment></comment><comment><USER12> Sort of surprised how restrictive some of ideas in this article and comment section are to say if you are writing functional code or not.

If you are writing pure functions and total functions, it's functional code. The rest is syntax.

And pure functions are probably best tagged with an asterisk because most of the time you have state to manage somewhere, you're just going to jump through some syntactic hoop (monad) to mask it

<comment><USER13> while I agree with your overall argument, i think this is wrong:

> And pure functions are probably best tagged with an asterisk because most of > the time you have state to manage somewhere

purity does not mean there is no state! This is exactly what the monad (and similiar structures) in haskell is for, which you correctly mentioned. But they don't violeate the purity.

<comment><USER12> i think it devolves into semantics at that point. when each line is doing some DB query or remote HTTP call it rarely matters if it's in a monad or not

<comment><AUTHOR> Exactly, whether you use a monad or not is an implementation detail. The high level idea is that you decouple the code that does IO from the code that's responsible for the business logic.

</comment></comment></comment></comment><comment><USER14> Functional programming as defined in its purest form would be ( as some others defined here ), akin to "mathematical functions as the form of abstraction". In the context of computer programming, Haskell would be the epitome of this. That being said, elements of functional programming are already available and making more head-way into imperative languages creating a hybrid imperative/functional style which I think is great. Some elements of functional programming that provide huge benefits are hard to argue against:

1\. high-order functions ( as inputs or outputs ) e.g. map, reduce, filter, etc. Direct benefit is a significant reduction of code and the ability to chain operations together and compose them.

2\. immutability. Direct benefit here would obviously be minimizing shared state thus reducing bugs

3\. side effects: minimizing and pushing side-effects to "edges" of an application. and/or designing programs such that side effects can be mocked out. e.g. building up a Http request that can later on be executed, thus facilitating unit-testing.

4\. type checking: Converting runtime errors into compile time errors ( to some degree ). again, by offloading work to the compiler, you can catch errors much earlier on.

The biggest problem w/ FP ( as I have evidenced ) is that while these things are great, when taken too far for the sake of pure FP itself, can create complex code. so there has to be a balancing act involved.

</comment><comment><USER15> It seems that FP zealots have a hard time appreciating that there's both a value and a cost to FP adherence. I find that FP forces too many contortions in the name of some ethereal value without a consideration of cost.

<comment><USER16> I think I know what you mean. I wouldn't use the word zealot as much as astronaut.

FP Astronaut -- Super focused on hypothetical, academic, mathematical concerns and random performance optimizations (e.g. tail recursion) over clarity. I think scala's Slick library is an example of this.

FP Pragmatist -- Concerned about clarity, debugging, logging, correctness, readability by all skill levels, modifiability, documentation, the common cases first and the extreme cases last

I think you can be a big FP advocate without being an off-putting incomprehensible blowhard

<comment><USER17> I've never heard of tail recursion being used as a performance optimization. Generally it's required to prevent a recursive function from blowing the stack.

Iteration is usually more performant than recursion, but doesn't mix well with immutability.

<comment><USER18> Tail calls _are_ iteration, just expressed as a function.

</comment></comment></comment></comment><comment><USER19> Discussions about functional programming really need to include R as an example. Highly popular with data scientists, it regularly makes top 10 lists and is much more mainstream than, say Haskell or F#.

</comment><comment> zupa-hu Great work, thanks for sharing!

I was looking for that comment to upvote it but it didn't exist. Everyone is expaining their pet feature of FP.

Maybe we should put aside our differences and lean towards cheering the people who put lots of effort into opening this world up for as many people as possible. Those who are not FP experts need exactly this kind of explanation, not mathematical mumbo jumbo.

I'll save the URL for sharing with anyone interested.

So here it is again: Great work, thanks for sharing!

</comment><comment><USER20> Personally, I like the idea of using immutability. In Swift, I declare as much as possible with let instead of var

        let pi = 3.141592
        let label = UILabel()
        let names = ["Java", "Perl", "Swift"]

These won't accidentally be changed and they'll never be null.

The editor/tools can now make additional checks before I try to run the code.

A small step towards correctness and readability.

</comment><comment><USER21> My main problem with functional programming (mostly based on some experience with Haskell) is that I find it _really_ hard to estimate the performance (in terms of runtime and memory consumption) of programs.

It's really nice to structure your program around types and build your program via function composition - but getting it performant (let's say similar to C, Rust or Java) is far from simple. In particular performant Haskell does not look like idiomatic Haskell, whereas performant C, Rust or Java does.

Now don't get me wrong - I absolutely love the idea of functional programming and λ-calculus is a beautiful system to express computation, but in practice it's still hard to make performant while keeping a readable style. Maybe Idris 2 can close the gap?

<comment> Ono-Sendai I think this is more of a problem with Haskell than functional programming in general.

</comment></comment><comment><USER22> Everyone talks about functional programming as if its this great new thing. I'm coming from a strong C# background, and to me this reads exactly like OOP.

> the output value of a function depends only on the arguments that are passed > to the function, so calling a function f twice with the same value for an > argument x produces the same result f(x) each time.

OK, that's basically a static method in C#. Is that wrong?

The piece goes on to say

> Functional programming, therefore, is programming so as to avoid these side > effects wherever possible.

So functional programming should never handle state? Do you just move that logic into another framework (Angular, React, etc)?

Maybe there's some obvious stuff I am missing. Why should I use a functional language (like F#) over an existing OOP language?

<comment><USER23> Non-functional languages seem to pay lip service to FP, confusing people into thinking they're already using it.

Example: It is well known that "Java Strings are immutable", which is a _good idea_. Yet you can absolutely write: > String str = "hello,"; > str += "world!"; So it's "immutable" for some lawyerish definition which does me no good. If I write a method that depends on s, it will produce different results each time.

> So functional programming should never handle state Not at all. You should > know (and be able to enforce) when your code does mutations.

<comment><USER24> > Yet you can absolutely write: > String str = "hello,"; > str += "world!"; So > it's "immutable" for some lawyerish definition which does me no good.

`str` is a mutable reference to an immutable object. You can make the reference point to something else, but the object being pointed to is immutable, so eg if you pass it to a function, that function cannot change it under you. If you want to make the reference immutable, declare it as final. I don't think understanding the difference between a pointer and the value it points to is lawyerish.

<comment><USER23> Thank you. ^ that's the lawyerish definition I was referring to ^</comment></comment></comment></comment>


How side projects saved our startup - <AUTHOR> https://blog.crew.co/how-side-projects-saved-our-startup <comment><USER2> Interesting to note that while Unsplash's launch on HN led to it becoming a staple and a huge success, the comments from the HN community were overwhelmingly negative: [https://news.ycombinator.com/item?id=5794083](https://news.ycombinator.com/item?id=5794083)

As a happy subscriber to Unsplash since it first launched here, I'm glad that the team ignored the comments and kept making this.

<comment><USER3> The first comment in the linked thread says:

>>> It's amazing how much the title submission can influence comments.

>>> Original title: "Hated expensive, crappy stock photos so I made this."

>>> Current title: "Free hi-resolution photos for your website. 10 new photos every 10 days"

So that explains a lot, and puts a good emphasis on how important is the title. These type of titles work out pretty well in other areas but it is a gray area here in HN. It also makes me appreciate the original title rule which we have here in HN.

</comment></comment><comment><USER4> One issue I have with posts like this, however awesome/uplifting/well- intentioned they may be, is that they attempt to generalize mostly anecdotal evidence to general advice.

Is this an engaging and inspiring story? Yes, and it's great that people feel free to share their stories (successes and otherwise) here.

Having read it, do I have a better idea how likely this strategy is to work for any given person/company? No, and I don't know that anything short of an exhaustive longitudinal study would help there. (There's some mention of studies on creative hobbies, but it's a bit of a leap from there to repeatable ROI.)

<comment><USER5> Bingo. And assuming somebody did actually have a really amazing and effective marketing strategy, they would be heavily disincentivized from sharing it. By its nature, marketing is about outcompeting other companies for attention and sales, so the less competition, the better.

So just based on bayesian probabilities, if you are reading marketing advice from somebody, it probably is bad (or wont apply to you). If you are reading a story about an effective marketing strategy somebody used in the past, it probably doesn't work as well anymore.

As you state, this doesn't take anything away from the entertainment value of the story, but it is just entertainment and marketing, not advice.

<comment><USER6> What If "the marketing advice" you're reading is the actual marketing?

<comment><USER7> no ifs involved: blog was specifically listed as one of their marketing platform and HN as their target audience.

</comment></comment></comment></comment><comment><USER8> "side projects as marketing" has a rather unfortunate acronym (:

<comment><USER9> Not quite as bad as runc though [https://github.com/opencontainers/runc/issues/24](https://github.com/opencontainers/runc/issues/24) (admittedly not an acronym but entertaining nonetheless)

<comment><USER10> That's not even true. "Runka" means jerking off. No Swede would associate "runc" with that (c on its own is never pronounced like k), especially in this kind of context.

<comment><USER11> It works in Finnish though. My first thought when seeing "runc" was "that must be the comic book sound effect for jerking off"... :)

<comment><USER12> My teenage Norwegian mind (not body) did smirk at the runc name. Runk and runc are pronounced the same there and have the same meaning as in Swedish/Finnish...

Not offending someone in some language somewhere is hard. I remember Honda nearly launched the Jazz with a different name in Europe. [http://www.carscoops.com/2007/09/why-honda-didnt-call-fit- ja...](http://www.carscoops.com/2007/09/why-honda-didnt-call-fit-jazz-by- its.html)

</comment></comment></comment></comment></comment><comment><USER13> I think the "side project as marketing" might only work if your side project is a good vertical for your product. People coming to a site that helps give referrals to designers (i think that's what Crew is) is definitely the same people who would be interested in UnSplashed.

If i'm working on a business for pharmacists, i'm not sure my side project playing around with neural networks is going to get me the right eyeballs.

</comment><comment><USER14> This is too simple to be of interest. Only a few companies can have side projects like that, and with that amount of success.

Honestly, HN sometimes (but not always) feels like it is made up of a bunch of gold-diggers, clinging to the hope of one day making a big breakthrough, without proportional effort. It has a very shallow feel to it.

<comment><USER15> There are a few notable companies that were side projects. Twitter, Slack and Instagram are three I can remember offhand.

<comment><USER16> Instagram was more a pivot from Burbn than a side project.

</comment></comment></comment><comment><USER17> We do similar things for [http://www.staffsquared.com](http://www.staffsquared.com).

For example:

\- What type of manager quiz are you: [http://www.staffsquared.com/what-type- of-manager-are-you-qui...](http://www.staffsquared.com/what-type-of-manager- are-you-quiz/)

\- Timesheet calculator: [http://www.staffsquared.com/timesheet- calculator/](http://www.staffsquared.com/timesheet-calculator/)

\- Maternity calculator: [http://www.staffsquared.com/calculator/maternitycalulator/](http://www.staffsquared.com/calculator/maternitycalulator/)

...and much much more.

Generally these "side projects" take a few days to put together from concept through to launch. They're very minimal overhead, and they drive good numbers that convert to trials to the site.

The best side projects don't just link back to the website you're actually selling, but somehow draw users in. A good example of this is the [http://invoiceomatic.io/](http://invoiceomatic.io/) by Freeagent. They grab you by giving you the opportunity to create an invoice, next thing you know you're knee deep creating a Freeagent account...it works.

</comment><comment><USER18> It's very meta to realize that this blog post is marketing too. Great execution of the "useful marketing" idea.

</comment><comment><USER19> This is nice. I experienced something similar. I live in Algeria and the banking system is deplorable. I wanted to be able to buy things online and needed a debit card. It took forever to find a bank that proposed them (sometimes, the bank employees themselves didn't know their own bank proposed such a service).

Anyway, after all the fuss and after gathering all the necessary documents to open an account and get a card, I thought that a lot of people were in a similar situation.

I created a wordpress.com blog and listed all the necessary documents. I created a PDF the bank required but didn't even bother to ask for until you went there (so extra trip) with fillable fields and all and uploaded it there. The whole thing. It was so frustrating to me that I went overboard and listed other options like comparing other card providers to the specific context of the country, and how each one could be used differently.

After that, I got proper hosting and redirected the .wordpress there. There were about 300 people daily on the site. Not much, but that's 100k people who read a very long post. The post alone had more than 700 comments (I changed to Disqus) and I replied to 99.99% of them. The remaining was spam. Soon, other readers were answering questions of "new" readers. They also sent me different documents to attach to the article. The site was linked to from a whole bunch of geek sites in the country. Sites to buy cars linked to it, too (they were interested in buying car accessories).

Often times, people I knew would read the article and then read the author's name and laugh because they knew me personally. Another contacted me and said good things and asked if I was related to an author/Gynechology Professor (my uncle) and he said he avoided his wife a couple years of prison time (she was to be jailed for medical mistake and my uncle apparently made a report it wasn't, the investigation was reopened). Others said it would be cool to meet IRL for coffee, etc. Others said I should monetize it.

The site ranked 1 on Google for "MasterCard Algérie" (it's not anymore as I was too busy to renew hosting, etc. But the wordpress.com blog ranks 7th).

It all came because I was too frustrated by the paperwork and the 18th century style banks have to do business.

The point is: It might not seem like it's a big thing (I mean, it's only a darn card, right).. But you never know how bad the itch is for someone else. A good indication is how it is bad for you, though. It doesn't matter if it's not revolutionary, only that it needs violent scratching.

Good luck with your projects.

</comment><comment><USER20> This is a very interesting marketing (unmarketing?) strategy. I'm in a similar spot as Crew were when they posted that project, I even remember seeing it on hn at the time.

Andrew recently posted an interview [1] with the founder of betalist.com, which was also born out of desperation and as a side project. Marc talks about his betalist experiment and the impact it had [2].

I would love to see other examples and write-ups about this. Was it accidental or strategic? I'm the sole developer of our product right now, but we're also struggling with marketing at the moment. How much does it make sense for me to put the effort into such side projects?

[1] [http://mixergy.com/interviews/marc-kohlbrugge- betalist/](http://mixergy.com/interviews/marc-kohlbrugge-betalist/) [2] [https://medium.com/beta-list/how-i-tricked-techcrunch- into-w...](https://medium.com/beta-list/how-i-tricked-techcrunch-into-writing- about-my-startup-248083eb0c34)

</comment><comment><USER21> For Unsplash, could we get soft-links (i.e. [https://unsplash.com/photo/1](https://unsplash.com/photo/1) would always link to photo 1 of the set of 10 for that week)? Then I could set up a script to update my wallpaper weekly, because these are gorgeous! :)

</comment><comment><USER22> > The best marketing is when you don't know it's marketing

There's an entire industry that revolve around this idea.

We call the people that work in that industry "publicists".

<comment><USER23> The "you" in the sentence is the creator of the product, not the target

<comment><USER24> I don't know Mikael's intent, but even if it was meant that way, the statement applies just as well to the viewer/target. It's arguably a lot more generalizable.

</comment></comment></comment><comment><USER25> Thank you for this post: I've been feeling especially down on myself today since I've a lot of learning to do when it comes to marketing and managing side projects, but the ideas in the post were gold. Kudos!

</comment><comment><USER26> Very good insights about marketing material that is "useful".

The idea reminds me of Vaynerchuk's _Jab, jab, right hook_ strategy [http://www.forbes.com/sites/danschawbel/2013/10/11/13-memora...](http://www.forbes.com/sites/danschawbel/2013/10/11/13-memorable- quotes-from-jab-jab-jab-right-hook/) (sorry for the popups)

</comment><comment><USER27> I've been using unsplash for a while and I was amazed the first time I used it, and am still amazed today. Enjoyed learning a little more about how they started.

The content is some times a little repetitive (just how many shots of amazing, beautiful scenery could one need?), but it has become an absolute go-to for me.

Article is old, but still like hearing about Unsplash

<comment><USER28> What kind of images would make a change?

I think that still life images of old things might fit in with the motivation for the site (free images to use on Web sites &c).

<comment><USER27> I'm not sure -- there is a site that specializes in what you are talking about though:

[http://nos.twnsnd.co/](http://nos.twnsnd.co/)

</comment></comment></comment><comment><USER29> This is a very common seo tactic most often referred to as "tools". See quicksprout.com for a high profile example.

cueyoutube.com has been a good source of seo juice work workingsoftware.com.au but beware tools that have a maintenance overhead: youtube updated their api weeks ago and i haven't had time to fix it.

</comment><comment><USER30> Candu- excuses excuses, time to just get out there and do it. Try something, you might strike gold first time like Crew did, but probably not. Invest little and expect little back, that's the lesson here. If it works, then shine a light on it.

</comment><comment><USER31> This is some great advice, nice post!

Too bad the article only focuses on the success stories. I for one would be really interested to know how many failed/abandoned side projects they created and how they relate to the successful ones.

</comment><comment><USER32> Oh wow! This was you who created it. I had been looking around for nice stock images to use for a product and stumbled upon "Unsplash". I was like sweet! Awesome work and thank you again!

</comment><comment><USER33> Very interesting post and seems to be the best way forward for "marketing" and creating the right culture at a start-up.

</comment><comment><USER34> btw, Github was also a side project once.[0]

[0] - [https://news.ycombinator.com/item?id=1772357](https://news.ycombinator.com/item?id=1772357)

</comment><comment><USER35> This isn't clear on the page, but if you look at the metadata - this article is from October 2014

</comment><comment><USER36> Also love what Hubspot did w/ Sidekick.

</comment><comment><USER37> I'm sure this breaks some HN rule, but consider visiting this discussion:

The Nigerian Teenagers Who Built Crocodile Browser [https://news.ycombinator.com/item?id=9787010](https://news.ycombinator.com/item?id=9787010)

One of the teens found his/her way to HN, but all that's in the thread is nitpicking about their website. It would be great if he/she got some engagement and encouragement.</comment>


DARPA investigating self-destructing electronics - <AUTHOR> http://www.darpa.mil/NewsEvents/Releases/2013/01/28.aspx

<comment><AUTHOR> Wonder if this is a technological response to the lost stealth drone (RQ-170 Sentinel) in Iran in 2011 [1]?

[1] [http://en.wikipedia.org/wiki/Iran%E2%80%93U.S._RQ-170_incide...](http://en.wikipedia.org/wiki/Iran%E2%80%93U.S._RQ-170_incident)</comment>


Psychedelic Pioneer and Confidence Man - <AUTHOR> https://lareviewofbooks.org/article/psychedelic-pioneer-and-confidence-man/ <comment><USER2> Ram Dass once recalled the first time Hollingshead gave Leary LSD. Leary, Ram Dass (who was then still Richard Alpert), Ralph Metzner, and others from their group were staying at Millbrook and continuing their research with psylocybin that they'd started at Harvard when Hollingshead turned up and offered Leary LSD. Leary at first turned his nose up at LSD, but eventually tried it.

Then, Alpert reported, Leary did not speak for days. Everyone in the group was scared, and Alpert told everyone to stay away from the LSD while they waited for Leary to come back to them. After five days Leary finally spoke and the first word out of his mouth was "Wow". Then they all tried it.

I can't find it now, but I also remember hearing an episode of the Psychedelic Salon[1] podcast where Lorenzo Hagerty talks about how he came across an old letter of Myron Stolaroff's where the latter warned another psychedelic luminary about Hollingshead, calling him a consummate liar and saying that he shouldn't be trusted.

Incidentally, Stolaroff was deeply hurt by being conned by yet another psychedelic luminary, Al Hubbard, another legendary and mysterious Johnny Appleseed of LSD.

Psychedelics certainly do seem to attract tricksters (perhaps because they also attract naive idealists, who are irresistibly ripe pickings for the tricksters). Hollingshead, Leary, and Hubbard were all tricksters, as was Sasha Shulgin, who was very fond of practical jokes.

There was an interesting "psychedelic reunion" between Leary, Hubbard, Humphrey Osmond (who coined the term "psychedelic"), Sidney Cohen and others at Oscar Janiger's home in 1979.[2]

I found the video of this reunion fascinating because it seemed that all these larger than life psychedelic pioneers, who'd probably all done psychedelics hundreds if not thousands of times seemed quite ordinary, uncomfortable, unenlightened, and even gruff and sour to one another.

For instance, Leary seemed to desperately need to be the center of attention and Hubbard seemed extraordinarily uncomfortable and taciturn while Leary needled him. Later I learned that Hubbard absolutely detested Leary. That explained it, and provided evidence (if any more was needed) that psychedelics didn't inevitably turn people in to saints or enlightened beings who love everyone and who's feathers couldn't be ruffled by anything.

A couple other interesting recordings were the "Lone Pine Stories" with Myron Stolaroff [3], where he talks about being given LSD for the first time by Hubbard, and a Q&A session[4] by Stolaroff and Gary Fisher, who'd treated schizophrenic children with LSD.[5]

[1] - [https://psychedelicsalon.com/category/people/myron- stolaroff...](https://psychedelicsalon.com/category/people/myron-stolaroff/)

[2] - [https://www.youtube.com/watch?v=U-sfDEEcMQ8](https://www.youtube.com/watch?v=U-sfDEEcMQ8)

[3] - [https://www.youtube.com/watch?v=mMZ- oopMBog&list=PLCB4ED9E98...](https://www.youtube.com/watch?v=mMZ- oopMBog&list=PLCB4ED9E989E17EF6)

[4] - [https://www.youtube.com/watch?v=qMUO0dP77rI](https://www.youtube.com/watch?v=qMUO0dP77rI)

[5] - [http://www.maps.org/news- letters/v07n3/07318fis.html](http://www.maps.org/news- letters/v07n3/07318fis.html)

<comment><USER3> > inevitably turn people in to saints or enlightened beings who love everyone > and who's feathers couldn't be ruffled by anything.

I'm thinking that enlightened states are not inherently stable; they're sharp peaks with shallow troughs. It takes active work to stay in them, and that it's getting habitual at _becoming_ enlightened that we call enlightenment.

The main inspirations for this are the temporary experience of enlightenment present in many psychedelic experiences, and the number of koans about "suddenly, they were enlightened" that now make more sense; they're realizing they have a habit of maintaining the enlightened state.

<comment><USER2> In addition to this, I think people in general are really good at deluding themselves, and a lot of people have very underdeveloped critical faculties (especially in regards to themselves and the revelations they have), which lead them to believe they really are enlightened when they're not.

Paradoxically, ego inflation is a very common effect of psychedelics.

<comment><USER4> What's difficult to ascertain about all of this is meta-cognition in general.

Is this really measurable past fleeting binary states self-awareness about your own self-aware state?

Past that, I like your connection between naive idealist + self delusion, however I think you have described the human condition of curiosity, in which our conscience mind is able to imagine future states. Then, while we reverse engineer how to possibly do that, we create an ad hoc hypothesis (conscience or not) to end up in that future state. Therefore delusion is almost a necessity, as the mind has little way to tie this hypothesis causation to the ad hoc hypothesis.

If a conscience mind accepts the imaginary future state of enlightenment as being one that they ought experience. The following question is ... how? This moment is exactly how I see your point fitting in especially with psychedelics.</comment></comment></comment></comment>


These Are the Questions We Should Be Asking About Coronavirus - <AUTHOR> https://www.propublica.org/article/i-lived-through-sars-and-reported-on-ebola-these-are-the-questions-we-should-be-asking-about-coronavirus <comment><AUTHOR> It's meant as a how-to for journalists on how to ask better questions:

\- How many samples are you running per patient?

\- How many samples is your lab testing per day right now? How about at maximum capacity? How many hours does it take to get a result?

\- Scientists estimate the mortality rate is X%, based on the information they have.

\- What assumptions were used to calculate your prediction? What's the upper and lower range of your projection?</comment>


PredictionIO – open source machine learning for predictive features - <AUTHOR> https://hacks.mozilla.org/2014/04/introducing-predictionio/

<comment><USER2> I wish it didn't depend on MongoDB. Is there a good reason for not using a more general purpose database, like SQL or any of the billion key value stores out there?

<comment><USER3> We picked MongoDB a while ago because of its built in geospatial indexing support. Would be happy to add support of other databases. Any strong candidates on top of your head?

<comment><USER4> I know it's a pain to get data into it, but how about Big Query?

<comment><USER5> Ideally open-source. Surprised MongoDB 2.2+ is such an issue but thanks for the feedback and suggestions. We'll look into PostgreSQL, Riak and RethinkDB.

<comment><USER4> It is based on an open-sourced db called Dremel:

[https://code.google.com/p/dremel/](https://code.google.com/p/dremel/)

<comment><USER6> But dremel doesn't support incremental updates. Dremel is designed for read- only data. All its columns are indexed. The whole table needs to be re-built after update.

</comment></comment></comment></comment></comment></comment><comment><USER7> It also comes with a Vagrant box if you're looking to just try it out with your dev environment. I've tried it personally and had a good experience with it. I spot checked the recommendations and they felt really good.

[http://docs.prediction.io/current/installation/install- predi...](http://docs.prediction.io/current/installation/install-predictionio- with-virtualbox-vagrant.html)

</comment><comment><USER8> Sounds fantastic right up until I read requires MongoDb. Thankfully it's open source and we can fix that.

<comment><USER9> Why is mongo a problem?

<comment><USER10> For me it is a red flag in terms of scalability as lots of our data sets won't fit in mongo backed by a 1-2 TB disk even if they take up < 100 GB in the original format (usually binary/compressed genetic data).

It also uses a ton of ram and performance really suffers when the data won't fit in ram so it isn't a great choice if you are trying to push the limits of what your machines can do.

They are only using it to store models and whatever "behavioral data" is but models for things like random forests can be really big and you want to be able to write/read trees from separate machines etc.

I wonder why they chose to use mongo vs local disk or HDFS which they already require.

<comment><USER11> it's the real-time prediction query, e.g. geospatial search, that makes use of mongo's indices.

<comment><USER10> Thanks for the clarification, the write up isn't clear. Have you benchmarked against postGIS or stock mysql? And tried any larger-than-memory databases?

We were using mongo in a suit of web applications that display the results of ML and statistical analysis of cancer data and we've found its query performance lacking in a number of cases...I think the mongo geospatial index is a pretty simple geohash setup on top of their normal query engine and I would expect it to have the same issues.

I do think this project is very interesting, just providing my feedback based on doing similar work.

Memory overhead of both mongo and hadoop would actually be my biggest worry since, especially on desktop workstations it is quite common for machine learning tools in R or python to need most of the available memory when tackling even small problems.

</comment></comment></comment></comment></comment><comment><USER12> How did these guys get distribution on an official Mozilla blog despite being a third-party project?

<comment><AUTHOR> I'm Robert, the Editor of Mozilla Hacks. We publish articles about anything regarding to the Open Web and is open source that we believe developers can learn and get inspired from.

More information at [https://hacks.mozilla.org/about/](https://hacks.mozilla.org/about/)

</comment></comment><comment><USER13> One of the really nice things about PredictionIO is that it comes with a dozen different recommendation algorithms out of the box, and lets you simulate their results with your data. This makes it much easier to decide which is the right one to use.</comment>


Ask HN: Technical Screen for PM - <AUTHOR> Hey! I've got a technical screen for a PM role next week. Based on recruiter I will be asked about:
AWS CI/CD Previous applications/if any knowledge transfers.
The PM role is at a 2bil company building out internal tooling.
What should one know, read/watch to prepare?
My experience is previous saas founder. Wrote entire codebase (albeit, very sloppy because we needed to sell software) and sold first 100k. So in theory, I think I'd be a great fit for running a new product from the ground up. But would love some resources and advice from the smarter engineers here! Thanks. <comment><AUTHOR> We ran our entire infrastructure on AWS so I guess I'm familiar but know I've got blind spots.

We ran ECS w docker, ELBs, Route53, used RDS, SES, and probably some others I'm forgetting. I've played with Lambda but am not experienced with it.</comment>


Padding oracles and the decline of CBC-mode cipher suites - <AUTHOR> https://blog.cloudflare.com/padding-oracles-and-the-decline-of-cbc-mode-ciphersuites/ <comment><USER2> This is a good overview, worth reading. I have some nits.

* This isn't a legit criticism of the article, but: it drives me nuts when people suggest the big problem with ECB is that you can see penguins through it. The reason ECB penguins are see-through is that ECB isn't semantically secure. The bigger problem with this trait is that you can usually _decrypt ECB altogether without a key!_. A really thorough understanding of how ECB breaks down is hugely helpful to understanding the TLS flaws. Enough with the penguins!

[http://cryptopals.com/sets/2/challenges/12/](http://cryptopals.com/sets/2/challenges/12/)

* Timing-driven padding oracles predate Lucky 13; the person who more or less taught me crypto told me about them back in 2009. Again, not a super legit criticism of the article, but worth knowing.

* There are other error side channel attacks besides padding oracles, and some of them affect modes other than CBC.

* CBC mode is in decline, but the article is kind of incoherent about why, or whether that's a good thing. "CBC is OK for static content" is a recommendation that doesn't make any sense to me at all. CTR and derivatives will eat CBC entirely over the long run: CTR is simpler than CBC (it has minimal format constraints), only requires the encryption transform, and is marginally easier to implement faster.

* What's really in decline is generic composition cryptosystems, where encryption and authentication are specified independently. Most of the last 10 years of TLS bugs stem from TLS being specified before the industry understood the central role of authentication in secure cryptosystems. For a good example of this, look at POODLE, which is an attack made possible by an idiosyncratic CBC that uses nondeterministic padding that can't be reliably authenticated.

<comment><USER3> He said "the first padding oracle attack was demonstrated in 2002". Do you mean he's wrong about that?

</comment></comment><comment><USER4> How is this about CBC and not exclusively about MAC-then-encrypt? Wouldn't CBC be fine in a MAC'd ciphertext protocol?

<comment><USER2> You still need to ensure that the IV is unpredictable, even if the ciphertext is authenticated, but then you still need to make sure CTR (or GCM) nonces are unique, so that nets out.

</comment></comment><comment><USER5> This is a fantastic writeup covering a large amount of cryptography, both in and outside the context of the web. Reading about all of this summarized in a practical context including all of the real-world nasties like ARP spoofing is both great, and double-great for getting a feel about why utterances like "hm, this _should_ be okay given _this_ circumstance" should always put fear in your heart when talking about security.

Also, wow, I'd never seen that link to The Cryptographic Doom principle before, despite trying to elucidate that concept before myself (badly). That's a fantastic bookmark to keep for inclusion in explanations on tickets filed against dubious crypto.

Likewise, this link is going in my bookmarks for immediate deployment when I need a litany of padding oracles and timing attacks to explain why indistinguishability is essential to a friend. Thanks, author!

</comment><comment><USER6> I wonder who's still using browsers that only accept 3DES?

<comment><USER7> Companies. Unfortunately, there are still plenty of corporate environments with machines using XP, and 3DES is usually kept on to support those.</comment></comment>


You Can't Secure What You Cannot Update: Hardware Edition - <AUTHOR> http://resin.io/blog/you-cant-secure-what-you-cannot-update/ <comment><USER2> Don't buy hardware you can't run your own software on. Even embedded software.

There are tons of great routers, both consumer and business class that have Atheros CPU and WiFi chipsets that lack binary blob firmware, and support both Linux and BSD:

[http://wiki.openwrt.org/toh/start](http://wiki.openwrt.org/toh/start) [https://wiki.freebsd.org/FreeBSD/mips](https://wiki.freebsd.org/FreeBSD/mips)

Pick software first, then hardware that supports it. It's how we do everything else, and routers are no different.

<comment><USER3> Are you imagining people developing an open-source vehicle-motor microcontroller firmware, and then users choosing what _car_ to buy based on whether they can use that firmware? Because that's the kind of "hardware" we're talking about here.

<comment><USER4> Even cars that run on open source software (Tesla Model S runs Linux) don't release source for their GPL'd code.

So I wouldn't expect a project like this any time soon.

</comment></comment></comment><comment><USER5> I suspect this is going to cause a significant problem in the future with regaurds to all these embedded home routers that stopped receiving updates 6 months after release. Its essentially an unmonitored backdoor to 95% of networks on earth.

[http://www.devttys0.com/2013/10/reverse-engineering-a-d- link...](http://www.devttys0.com/2013/10/reverse-engineering-a-d-link- backdoor/)

[http://arstechnica.com/security/2014/02/bizarre-attack- infec...](http://arstechnica.com/security/2014/02/bizarre-attack-infects- linksys-routers-with-self-replicating-malware/)

Not to mention the similar situation with android phones.

What a spectacular mess.

<comment><USER6> Routers and switches are a concern, but I think the telsa example in the article is one of the best ones. Appliances that are relatively easy to replace is one thing, major purchases like a car, home automation, or similar items is much more concerning. We see how GM and Toyota reacted with their recalls. Are we going to see something similar from the future (less startup-y/more corporate) nests of the world?

What happens when my alarm/sprinkler system is tied to my intelligent door locks and a simple buffer overflow via bluetooth allows a cracker to flood my entire business with a simple drive by attack? The internet of things brings with it an unprecedented level of risk.

<comment><USER7> > Appliances that are relatively easy to replace is one thing

But if the hardware still works fine, replacing it because of software issues isn't really justified. It's far less wasteful to do software upgrades.

<comment><USER8> > But if the hardware still works fine, replacing it because of software > issues isn't really justified. It's far less wasteful to do software > upgrades.

Unless you're a hardware manufacturer who wants to sell new hardware.

</comment></comment></comment></comment><comment><USER9> But like, wouldn't disabling internet access altogether also count as a reasonable measure towards security?

What if you just didn't connect the device to any network at all?

What about that?

Are we trying to say that such a thing is unpossible?

<comment><USER10> It's not "unpossible" now, but eventually it will be. That is, we won't be able to rely on either configuration or physical arrangements to isolate networkable devices from networks. Of course you'll still be able to rip out e.g. radio modules, but why do you want to break your toaster? b^)

</comment></comment><comment><USER11> One of the many reasons why Android remains the bigger target for mobile malware.</comment>


Why I switched to Pylons after using Django for six months - <AUTHOR> http://www.mutualinformation.org/2010/03/why-i-switched-to-pylons-after-using-django-for-six-months/

<comment><USER2> It seems like a lot of people get frustrated with Django because it isn't the Framework for Copy & Paste Coders Who Like to be Spoonfed.

To some degree, this is a failure of the Django community's messaging. Django is highly modular and, if anything, disassembles gracefully as you start running into more complex scenarios (even more so in 1.2 than 1.1).

It's best to think of Django as a robust set of wheels you don't have to reinvent for each new site you build, and a toolkit for building new wheels you can not-reinvent next time around.

All of the above is painfully obvious to anybody who has spent a decent amount of time with Django, but might not be so clear to somebody just finding their way or using Django in a limited fashion. I'm sad to see that somebody had a poor experience with Django, but this post is basically a lot of whining about an inability to figure things out and use the framework as intended.

<comment><USER3> I think your sentiment here is pretty correct. We have been using Django to build SWIX ( <http://www.swixhq.com> ) and for the most part we find Django to be a blessing. It does much of the heavy lifting and helps us keep all our code modular and loosely coupled(at least when we are doing it right).

<comment><USER4> I concur.

I've built one very complex site using Django, and it's worked great.

For the authors specific complaints:

\- We found a nice reusable app. for recpatcha that basically just boils the whole thing down to a form field. It works flawlessly. \- I implemented twitter/facebook connect integration with no issues (all using the standard auth system, and two apps) \- We've done things like dynamic custom forms that work just beautifully.

It's a pretty long list of things that we've been able to accomplish with Django. We're really happy with it, particularly since the 1.1 release. It has a ton of flexibility, while still virtually automating most of the things we do often.

It's certainly not turn-key, but we've done this without modifying one line of django code.

In the near future I'm hoping to be able to take some time to open source some of this work.

</comment></comment></comment><comment><USER5> I've built a couple of reasonably complex Djamgo apps, and as much as I like Django, all the points author makes are very true. That said, by the time you have swapped out the template language and the ORM you are basically no longer using Django; I think it's fair to say that if find yourself needing to do those things, you're much better off with Pylons.It's a question of the right tool for the job.

I do agree heartily that Django apps are not an effective level of abstraction as on might hope. Personally I usually just stick to using various libraries and writing my own code to do the Django-specific parts.

<comment><USER6> I just switched the other way - from Pylons to Django - for a work project, for pretty much exactly the same reasons that he describes - inflexibility. In my case, lots of boilerplate for admin screens plus SQLAlchemy felt like too much magic. Particularly when trying to run functionality tests against my app, there were a few too many weird errors, with no obvious way to fix them (the solution was normally to move the database commit around), when the application worked fine. Django tests on the other hand, Just Work(tm).

So far I haven't run into any lack of flexibility on Django's part, and I've been using it for fairly serious stuff (mainly as a general-purpose CMS, heavy admin screen work). From the look of the original author's sites, the things that he's doing aren't too different, so I'm not sure what the problem is. Perhaps he just prefers the way Pylons does things?

<comment><USER7> It sounds like you had issues with SQLAlchemy, not Pylons.*

If you take care to understand SQLAlchemy well, it won't get in your way either.

*(I concede that Pylons doesn't have a good automated admin feature.)

<comment><USER6> I think it was more that the automated web testing part of Pylons wasn't particularly well integrated with SQLAlchemy. So (eg.) it's basically impossible (AFAICT) to populate the database with preexisting data and then directly call the controllers, since when you commit the data in your controller, you can't access the database afterwards when you get back to your controller. Instead, you get lots of odd tracebacks - things like "Instance <Foo at 0x103779f90> is not bound to a Session". It also means that you can't do rollback type testing - you have to stick different data in, or blow it all away and recreate it manually.

Django on the other hand, has fixtures, which you can create from your existing database, and use rollbacks, so they're really fast. Combine that with the test client, and I can just write my test cases and forget about setting stuff up. People often go on about Django's admin interface, but I find that the rest of the framework is written to the same sort of standard, so there are lots of hidden gems (like fixtures) just waiting for you to find them.

</comment></comment></comment></comment><comment><USER8> Wow. In summary, he switched from Django to Pylons because:

      - He couldn't figure out how to modify his Pinax project
      - He couldn't get django-openid to work
      - There's no debugger on Django exception pages
      - Something about magic imports?

You don't have to fork Pinax to add/remove apps to it. You don't have to fork django-openid to use it in your project, just override the templates. Recaptcha fits into the app model very easily: it's just another auth backend. You can get a debugger on your exception pages by installing django- extensions.

<comment><USER9> As a Django developer myself, I totally agree with some of his frustrations. For example one _very_ common problem I run into with Django is that a typo in a urls.py file will manifest itself as a URL reversal problem with the first attempt at URL reversal. The error always point to the same file and it's never the file with the problem, or even the same type of file. Not helpful.

While I agree that the problems could have been worked out with more knowledge of the framework, it doesn't help to gloss over the issues. For almost all of the problems he mentioned, Django's got a lot of room for improvement and especially those who love it should admit that.

<comment><USER10> It should be possible to add a pdb.set_trace() or ipdb.set_trace() to the part of Django that traverses the URL tree. Then it should be possible to watch every URL be evaluated until one matches your request.

Don't ask me where it is, but, if you find it, it's worthy of a blog post ;-)

</comment></comment></comment><comment><USER11> The debugger he's so fond of is actually the Paste debugger (paste.exceptions.errormiddleware.ErrorMiddleware). See <http://gist.github.com/326254> on how to use it with Django WSGI deployments.

Secondly, Django is nearly unparalleled when it comes to CMS-based work. It probably is the wrong choice if you're looking to build the next Google, but for anything involving a system where the administrators are computer illiterate, it's always a winner.

As for the entire reusable apps thing, I have to agree. It's good for namespacing, but other than that, it doesn't have many benefits.

<comment><USER12> So, how do I build the next Google?

</comment></comment><comment><USER13> Just spent a week refactoring our Django projects into apps. Nice timing.

The more I think about it, the less sure I am that the django-app is a good model for any organisation of code (not just third party reuse).

In my mind web apps consist of [parts of] pages / templates, menus, forms, and url structure and underlying models. Django forces me to separate these concerns. A Good Thing. Then it turns around and forces me to define a group (app) and lump a bunch of them together again.

<comment><USER14> I disagree. It certainly doesn't force you to do anything. I am working with a team on a legacy web app we are converting to Django. Because of the legacy nature we have had to extend and override some of the functionality provided by Django and have found it an easy and logical process.

And grouping models/forms/views/templates etc certainly has made sense for us considering the large amount of code we are dealing with. Finding the relevant section of code is a painless experience.

I do agree with the articles complaint about obscure import errors. My solution when dealing with that is to drop into the shell and do the import there to get a better error message. Not ideal but so far it has been the only pain point we've had to deal with.

<comment><USER10> > My solution when dealing with that is to drop into the shell and do the > import there to get a better error message.

What kind of software developer is afraid to (or don't know how to) do that?

</comment></comment></comment><comment><USER15> Good call on the apps. I think we can agree the idea of reusable apps hasn't really worked out. Still, I don't see how this tips anything in favor of Pylons. As for the debugger, I've been using pdb extensively. Errors thrown by templates are very annoying however, showing a huge stack trace through the template rendering scope and nothing to do with whatever caused the error. To solve this I've had this at the bottom of my urls.py (<http://dpaste.de/9Emp/>). It prints out exceptions straight to runserver. Also useful if you're letting project managers test your site and they come across a bug - you can just inspect it right away.

</comment><comment><USER16> Sounds to me that they are just lacking some kind of mountable application system al a rack?

<comment><USER17> In python world, rack is WSGI. Pylons is built around wsgi concept, thus has access to wsgi apps. I'm not sure how Django handles WSGI entry points. It's been a while since last time I worked on django app.

See: <http://wsgi.org/wsgi/Middleware_and_Utilities>

</comment></comment><comment><USER18> I agree with his complaints about reusable apps to an extent, but I feel a lot of the fault has to do with the design of the apps he referred to. I feel that the good apps are the ones that focus on a very narrow scope and try a singular problem (Paypal integration, Twitter integration, etc). Pinax tries to shove every social media idea at you. Other ones like Satchmo (shopping cart) even have their own templates and styles, sorta like a CRM where you're kinda meant to use the Admin to manage your shop. I think you can get decent flexibility with Django as long as you choose simple apps.

I've always liked the Django debugging information and haven't had too many problems. I agree that it's very possible for many to feel limited by the ORM and standard templating system.

<comment><USER19> "I agree that it's very possible for many to feel limited by the ORM and standard templating system."

For me Django 1.2 is smoothing both of those over. The raw_sql method lets you construct your own select statements and turns the results into python objects. Also the if tag is much better. If template tag creation got cleaned up, I would have almost no problems at all with the template system.

</comment></comment><comment><USER12> When I was deciding for Django, this...</comment>


Being shy about how much I make - <AUTHOR> http://littlemissmoneybags.blogspot.com/2011/03/being-shy-about-how-much-i-make.html "I went out for dinner last night with two friends in my field, and had the most bizarre realization that I make way more money than they do." <comment><USER2> The author seems to have a bit of a money fixation. She is obsessed with how much money she has -- her blog graphs her net worth publicly! -- and with the image of thriftiness. Saying that someone who orders an appetizer at a restaurant, considers dessert, or has more than one drink must "handle money differently" from her is just obnoxious. I bet she smiled knowingly to herself, and maybe shook her head a bit, when those appetizers were ordered -- some people don't know how to save money!

In this blog we are merely observing the firings of someone's ego who identifies as "thrifty" and a high earner. I'm sure any awkwardness with her friends is created by her!

</comment><comment><USER3> It is awkward, especially when you aren't sure how others are going to take it. Because American culture doesn't really condone talking about personal finances, you have a hard time gauging someone's reactions when the subject comes up, which causes a sort of opacity feedback loop.

I have a very good friend who just graduated law school and got his first job with some firm in Virginia. He helped me move cross country last summer, and got the job offer on the drive. On the drive, he mentioned his salary as a way of bragging (he likes to do that), and I casually mentioned that was a great salary for someone effectively right out of school. He asked what I made, and I told him it was in the ballpark of double his new offer, and that pissed him off. I had to remind him that I've been doing this professionally for five years, that I've got a strong track record of getting shit done and that I also have a grad degree in my field. It didn't really help, and it made things awkward for the remainder of the trip. I'm not sure why, though. We have another friend who makes far more than either of us ever will (he's some sort of associate director for a hedge fund), and although we don't know specifics it's fairly easy to come to grips with the fact that all of us make different amounts of money. I'm just not sure why the contrast between my attorney friend's salary and my own was such a shock, and it makes me very hesitant to discuss money with them in the future.

<comment><USER4> Brand new lawyers are really terrible in this regard. Out of the young lawyers I know, two are really in it because they love the law and justice. The other 95%+ are in it for money and prestige, not because they actually like doing the job.

If he's in the latter group, what he heard was "You've worked like a dog in school and now you're going to have to work 80+ hour weeks to make half as much as I do." In contrast, he's probably able to rationalize the hedge fund guy as a lottery-type combination of talent, ridiculously hard work, and luck.

</comment></comment><comment><USER5> $15K or $6K per year is a big deal in the first few years of your working life. It becomes much less important a metric later in life. Especially so when you look at all factors involved in a particular job: bureaucracy, a _^_ ole boss, jerky workmates, long hours, too much water cooler gossip, hurry-up and wait, short notice deadlines, etc. Many of my friends would gladly take a pay cut to "own their life" and work from home, for example.

</comment><comment><USER6> Bah, she lives in NYC, there is always someone making more.

<comment><USER7> Plus, the salaries of her two friends who she makes "way more" than? A difference of $15K and $6K.</comment></comment>


JavaScript with apples: var vs. let vs. const - <AUTHOR> https://twitter.com/kosamari/status/806941856777011200 <comment><USER2> I just stopped using `var` entirely, and now I almost exclusively use `const` everywhere unless I'm dealing with flags or counters in which case I use `let`.

<comment><USER3> Yep, there is no (good) reason to use var anymore.</comment></comment>


Cloudera Said to Raise at Least $200 Million in Funding - <AUTHOR> http://www.bloomberg.com/news/2014-03-18/cloudera-said-to-raise-at-least-200-million-in-funding.html <comment><USER2> I guess this means IPO isn't going to happen this year.</comment>


Markdown is the Future of Writing - <AUTHOR> http://nerdplusart.com/markdown-is-the-future/ <comment><USER3> Markdown is a mess. Gruber refuses to take care and now there are a ton of slightly different dialects because the original draft is clearly lacking in some respects.

Just last week wanted to use GFM, they introduced a new newline style. Or maybe not? In gollum it doesn't seem to be working and then there are breaking lines with two spaces. Or not? It's a desaster.

Some group should take over the markdown format definition.

<comment><USER4> Go for it. You could call it Topdown.

<comment><USER5> Or Markup. Oh wait.

<comment><USER3> ;-) But why not 'just steal' the markdown name? Afaik Gruber used the name for a software and not for a standard... A committee (codehorror, Github, marked, discount, Pandoc people etc.) could e.g. buy the markdown.org domain and start publishing new standards. I'd love to have a core which is the ~same what we have now and then extensions. The core could (very slightly) develop if necessary.

It's not nice to take over names but why not? It's a pity to see Markdown rotting along since years :-(

</comment></comment></comment></comment><comment><USER6> The easiest counterargument possible:

Good writing doesn't need syntax. Sinclair and Joyce and Fitzgerald and Twain didn't need italics or heading tags: just like structuring a post as a list is a sign of structural weakness, designating something with a header tag is admitting defeat, is admitting "Hey, look at this, this means something is happening over here."

(I love Markdown, and use it daily.)

<comment><USER7> Markdown is great for writing on the web, but it's not the future of writing. I love markdown, but all word processing is still so restrictive compared to earlier forms of composition, and HTML is still a horrible medium for poetry:

Hannah Weiner used to manipulate the page in her typewriter for great effects in the 70s and 80s ([http://www.ubu.com/ubu/pdf/weiner_indians.pdf](http://www.ubu.com/ubu/pdf/weiner_indians.pdf)). Charles Olson called the page an open field in 1950 ([http://www.poetryfoundation.org/learning/poetics- essay/23788...](http://www.poetryfoundation.org/learning/poetics- essay/237880)). Our linear text flow doesn't allow for the kind of poetry that Apollinaire was making in the early 20th century ([http://ubumexico.centro.org.mx/text/Apollinaire_Calligrams.p...](http://ubumexico.centro.org.mx/text/Apollinaire_Calligrams.pdf)). Heck, for that matter HTML can't even maintain line breaks or distinguish stanzas (should they be p tags?).

</comment></comment><comment><USER8> The key takeaway : "Markdown lets you think about what you're writing instead of how it looks"... which is arguably a bit difficult when you're manipulating raw HTML and a bit... detached on WISIWYG.

Markdown allows sophisticated ideas to fall into text with a very simple syntax. I don't know of any other system that allows this except just plain text.

Edit: Hmm... looks like agreeing with the article isn't popular for some reason.

<comment><USER9> The issue with Markdown is the syntax is pretty horrible. To create a link, it's [ title ] ( url ), which is incredibly unintuitive. I'm still never sure if italics are ____or * *. Heck, if I want a single newline, that 's not possible. I am all for using a markup syntax; I just wish we had a better option than Markdown specifically.

Additionally, Medium is specifically, heavily concerned with "how it looks" as that is one of the main selling points of the blog software.

<comment><USER10> A single newline is possible, and it's the most horrible thing in Markdown:

       When you do want to insert a
 break tag using Markdown,
       you end a line with two or more spaces, then type return.

[http://daringfireball.net/projects/markdown/syntax#p](http://daringfireball.net/projects/markdown/syntax#p)

<comment><USER11> Agreed. It's an appalling kludge, and I bet most of these ``distraction-free writing environments'' (vomit) don't highlight the extra trailing spaces in any way.

I have the following in my .vimrc which at least makes them visible:

      set listchars=tab:»\ ,eol:¬,trail:·

Of course, having them visible doesn't change the fact that they're an appalling kludge and I still tend to use
 instead.

</comment></comment></comment></comment><comment><USER12> Yet, somehow all the WYSIWIG editors beat out nroff and WordPerfect.

Personally, the trick to writing with a word processor is to not waste _too_ much time on the formatting, and just write. Also, learn to use the "sytles", just like you use CSS in an HTML file. I first learned to do significant writing in a WYSIWIG editor using Samna/Lotus Ami (accent on the i). Then Word, then Open/Libre Office. All of these have style lists. Use them! Don't waste time clicking on all the fonts, sizes, spacing, etc block after block.

The "Styles" menu seems to be one of the best kept secrets in Word and similar word processors.

</comment><comment><USER13> Markdown seems to be part of the retro/hipster trend, along with flat UIs, 8-bit video game music, fixie bikes, and Pabst beer. As someone who actually lived through the 1980s, it's amusing to watch you young cats reinvent my youth.

I'm not saying Markdown is a bad idea, but I'm perfectly happy using the rich UI provided by a word processor when I write. Next thing you know, someone will claim that 80 characters max per line was a great idea, and there will be a little iPhone app that rings a bell when you get to column 75 so you can hit the carriage return in time. Non-skeuomorphically, of course.

<comment><USER12> But, I _like_ 80 column lines. Er, I guess that doesn't make sense with proportional fonts :-)

Still, fill the page width, but use snaked columns if the page is wide or the font is small. I guess that's kind of like an 80 column rule.

</comment></comment><comment><USER14> The paucity of imagination in this post is depressing. Markdown isn't the future, it's the past. I mean that literally - markdown is a formalization of a set of kludges to approximate formatting when using the technology of 1970s dumb terminals. Is that really the best writing system we can come up with?

Clearly, it's not. One obvious improvement would be a system with the same semantics as markdown which presented these semantics using the standard typographical conventions everyone knows (italic for emphasis, larger text for headings, etc). A further improvement would be a more carefully thought through and richer semantics than the rather arbitrarily-chosen subset of HTML that markdown currently supports.

</comment><comment><USER15> "Markdown lets you think about what you're writing instead of how it looks."

Usually this is the [type of] phrase we use to describe LaTeX.

<comment><USER16> Really? That's not my experience with LaTeX at all: I (and others like me) am constantly looking up commands, special characters, parameters to commands, remembering to close braces, etc. And when things don't work as I or they expect, finding the problem is a nightmare. LaTeX is great for typesetting -- that is, when you _want_ to focus on how it looks.

<comment><USER15> The problems you describe are a sign that you still haven't learned LaTeX. I never claimed there isn't a steep learning curve. But these problems haven't to do with the appearance of your document.

Also you seem to miss the point of LaTeX. Of course you care how your documents look, this is one of the main reasons to use it. But you are smart enough to know that there are two parts in creating a document. The first is the content, this is your part, this is where your expertise lies. So you write and give some general instructions about the structure of your writings. The second part is the typesetting and this is LaTeX's work.

A common pitfall is trying to use LaTeX as MS Word.

</comment></comment></comment><comment><USER17> Which markdown is he talking about ? There are no standard and each editor has it's own rules. Bullet lists? How do you make sub bullet lists ? Use tabs ? No tab on iPad. Tables ? There is a Markdown dialect for that.

Markdown has limitations and needs to be standardized.

<comment><USER18> There is a reference syntax respected by all scrupulous editors [1]. It's a decentralized standard, sure, but it's compact and logical enough that it's unequivocally respected across the web.

[1] [http://daringfireball.net/projects/markdown/syntax](http://daringfireball.net/projects/markdown/syntax)

<comment><USER19> Gruber's Markdown syntax has a bunch of ambiguities in it.

<comment><USER17> Yes. Thank you to point it out. That is what I meant by standardization. An effort to identify and sort out these ambiguities or missing features like how to escape * *, etc.

I'm a fan user of Markdown, but I'm also frequently frustrated because it could be made so much more powerful and efficient while preserving the same initial spirit.

<comment><USER19> Not only that but the "reference" implementation on the website has bugs in it that Gruber has fixed but for some reason he hasn't updated the file. If you know what to search for in the Markdown mailing list you can find his latest version but it is insane that it's not on the page.

</comment></comment></comment></comment></comment><comment><USER20> Before markdown (for me), there was Perl's POD. [0]

Simple to pick up, does what it says on the tin, easy to hack in, "Do What I Want", for things missing.

The tools for it are a little all over the place, but, "Turn this into HTML" (pod2html) works, and works well for documentation.

Can you write whole books with it? People do - I believe many of the Perl books put out by O'Reilly are written in a POD dialect.

[0][http://perldoc.perl.org/perlpod.html](http://perldoc.perl.org/perlpod.html)

</comment><comment><USER21> As everyone has noted, good writing shouldn't be bogged down with syntax, yet the author proposes people ditch editors/bars and just write it directly? If you want that, just switch to source view and write. Otherwise, I'm quite content with working in a lightweight editor with keyboard shortcuts.

Frankly, I prefer to format my text with HTML anyhow. Markdown is easier on the eyes, but it has limited function and is just another level of separation between what I write and what you see.

</comment><comment><USER22> The premise here that "Markdown lets you think about what you're writing instead of how it looks" should be questioned.

Who says that the content of the writing is necessarily so much more important than how it looks? There's a reason that books are meant to look nice - <USER2> enjoy the look and feel of them. Likewise, I enjoy reading things on certain blogs - e.g., The Verge, Medium, Grantland - because they look really great and it's a great reading experience.

I'm almost tempted to think that it's the opposite - superpowerful WYSIWYG is the future of writing. End users will get to create amazing multimedia experiences. For better or worse, writing will be freed from being just about _words_.

<comment><USER23> One of the staples of aesthetic beauty in typography is coherency. Markdown allows to reach that easily.

This is also why so many Word products look so amateurish, or downright tiring to read: differences in spacing, font, color, all these make for an awful end result which is also annoying to maintain[1].

All in all this is akin to provisioning instead of scripting: you declare _what you want_ (a pull-out quote) instead of _how to do it_, letting the compiler take care of the rest.

The downside of markdown is that it is a two phase compose/preview system, which has been resolved with dual panes up to now. But it is not a showstopper, especially considering that professional copywriters already compose stories separate from presentation[2].

[1]: Yes, I know that Word has _styles_. Which are kind of similar in intent to markdown's #, >, *, even though they are not always semantically significant, and they also include presentation.

[2]: InDesign's story editor: [http://indesignsecrets.com/wp- content/uploads/2009/01/story-...](http://indesignsecrets.com/wp- content/uploads/2009/01/story-editor.png)

</comment></comment><comment><USER24> Markdown is like Vim -- sure, it might speed up your output, if that's your sole focus. And its not meant to be adopted en masse.

I'm a designer and relatively intelligent person by trade, and I have a difficult time with markdown. It requires me to have a guide open, to be able to write. No "normal folks" I know can decipher markdown.

The trick is to make styling easy -- not to make styling an afterthought. The writer, writing on Medium, should recognize this.

<comment><USER25> > relatively intelligent person by trade

Interesting trade. Your place doesn't need someone of mediocre intelligence do they?

</comment></comment><comment><USER26> The idea the author is illustrating reminds me of this even simpler, no- distractions, plain text editor [http://writer.bighugelabs.com/](http://writer.bighugelabs.com/)

It works really well for me when just trying to get thoughts out into words. Then it's just a case of pasting it into a 'proper' editor later to work on the finer editing, formatting, and suchlike.

</comment><comment><USER11> Telling me there's an 30-second overview of Markdown at the end of this post, but not providing an anchor link to get there, and another to get back, is really sloppy. It's probably as a result of Markdown's ``intentionally really simple'' syntax. I write in Markdown all the time and _I_ certainly don't know how to create an anchor link within it.

</comment><comment><USER27> The upcoming Ghost[1] blogging platform/tool has side by side post editor that supports Markdown on left and visual formatting on right. This should make it easier to learn Markdown syntax.

Also, I believe, Markdown is the best option for generating formatted content on touch based devices.

[1][http://tryghost.org/features.html](http://tryghost.org/features.html)

<comment><USER28> two-column layout is so last decade. Why hasn't anyone invented inline markdown editor yet?

Your current cursor line should be markdown source in plain text, other lines rendered HTML.

<comment><USER29> Prose.io has kind of a hybrid markdown editor (I think it's WYSIWYM?). It has markdown syntax highlighting that happens to look similar to the final output, though the markdown tags are still displayed. They also have a toolbar, which is used like a regular WYSIWYG toolbar, but generates mardown tags.

It's pretty neat.

</comment></comment></comment><comment><USER30> I think Markdown is mediocre. Putting too much meaning to white spaces is not exactly a bright idea for a markup language IMO.

</comment><comment><USER31> At Leanpub we bet the whole startup on Markdown, so we certainly agree! We love Markdown since it means that writers focus on writing, not on formatting...

</comment><comment><USER32> It baffles me that WordPress doesn't have Markdown by default.

<comment><USER8> I think WP has a lot of historical reasons for sticking with an HTML based WYSIWYG. Also, they've spent a lot of time and effort customizing TinyMCE.

If you like WordPress but want to keep things simple, you may like Habari : [http://habariproject.org](http://habariproject.org)

</comment></comment><comment><USER33> Suppose my writing includes tables, what do I do then?

<comment><USER34> Markdown has tables: [https://github.com/adam-p/markdown-here/wiki/Markdown- Here-C...](https://github.com/adam-p/markdown-here/wiki/Markdown-Here- Cheatsheet#wiki-tables)

<comment><USER33> first sentence there: "Tables aren't part of the core Markdown spec, ...." Anyway somehow, padding the columns with spaces to align the pipes isn't workable. If I change the width on 1 line, the whole table has to be modified.

Face it: in the current millennium, for serious writing, there's _still_ nothing better than Latex. (which is a bit sad)</comment></comment></comment>


Google's New Open Beacon Format Eddystone - <AUTHOR> http://kontakt.io/blog/what-is-eddystone/

<comment><USER2> kontakt.io seem to be spamming developers about this (presumably after purchasing a mailing list). Not the best way to market their service.</comment>