We Don't Hate PHP - <AUTHOR> https://www.hologram.io/blog/why-we-dont-hate-php <comment><USER2> This is such a surface-level article. Most of the things listed as advantages exist in other languages as well.

Here are some actual reasons to like PHP:

1\. Java-like interfaces and classes and strict argument (and soon parameter) typing enforced at runtime

2\. Autoloading and "lazy loading" of classes means defining bi-directional relationships between classes/types is painless (this can of course also make you shoot yourself in the foot, but I prefer that to dealing with circular imports in Python for example)

3\. The deployment model is dead simple on a VM (with drawbacks, but by the time you need things like atomic deployments you've probably moved to containers anyway)

4\. Statelessness

5\. Performance (despite the statelessness!)

6\. A very healthy package ecosystem, with several cross-framework interoperability projects

It has lots of bad parts as well, of course, but so does every language. And you may disagree with some of the things I listed if you don't like the particular feature or design, but that doesn't make them not advantages.

<comment><USER3> Hey, really good list, better than the article.

I don't really like PHP, because of inconsistency (it tends to break to flow for me) (but maybe it changed since 2014), but php with strict typing is a big plus for me and php7 is already more than fast enough. I might try it again.

The real issue i have with PHP is frameworks :/

Too much choice is a productivity killer for me.

<comment><USER4> I'd really love if we could just start over with the PHP base library design. There's just a lot of cruft that could be neatly packed into classes.

For instance, the arguments for array_map and array_reduce are reversed, one takes the function as first argument, one the array.

<comment><USER5> AFAIK, PHP 8 will support named arguments. I think that will make it easier to call built-in function without knowing the correct order of its arguments.

</comment></comment></comment></comment><comment><USER6> Those all seem like features any modern programming language has. Nothing here particularly distinguishes PHP from the rest of the crowd. I don't think anyone is surprised by the fact that PHP has classes and some niche methods integrated in most standard libraries.

I would like to go one further and say most other more modern programming languages do each of these better. It's always a good idea to look what is beyond the horizon.

<comment><USER7> Furthermore, many of these things were present in PHP 4 or 5 (the 'bad" PHP that many of us remember). PHP 4 already had classes [1]. PHP 5 had PDO.

[1][http://www.nusphere.com/kb/phpmanual/language.oop.htm](http://www.nusphere.com/kb/phpmanual/language.oop.htm)

<comment><USER8> Exactly. I'd argue what makes modern PHP less awful is almost entirely in what it _lacks_. Checking a bunch of random OOP boxes is not going to make it a good language. People love plenty of programming languages that don't check those boxes. (Lua, C, Go are all languages that lack many of those OOP features, for example.)

And to be sure, modern PHP _is_ better. The beginnings of typing, the fixing of horrible standard library behaviors, and an ecosystem with package management are game changers. But to me, all of that means nothing if the ecosystem is primarily running legacy apps. There are clearly proponents of modern PHP that embrace the new PHP, but what really gives it any modern relevance is old school apps like Mediawiki, phpBB, etc. and I feel like they all underscore what I dislike about PHP: not a single problem but a mindset that is incompatible with modern internet. There is no assumption of shared nothing; most apps assume the disk can be used for persistence. And it's tricky to dockerize a PHP app effectively since you typically need multiple processes; I know there's work on an app server in PHP itself but last I checked it was for development, and rather I ended up using uWSGIs embedded PHP support as the only solution I could even find that could do this in a way that wasn't horrifically ugly or intensive.

It still has its issues. For me the prime issue with PHP is the execution model. I am not in for my document root being my source dir. This weird behavior comes from the CGI era and to this day it doesn't really feel like there is intent to move away from it. Rather, the age old front controller pattern is poised as a "solution," entangling web server, PHP and application configuration together in some unholy mess, versus the modern pattern of having an app server.

<comment><USER9> > And it's tricky to dockerize a PHP app effectively since you typically need > multiple processes;

Absolutely. I handle a lot of the devops work at my job and PHP containers are just all around more annoying to build, configure and run than most other languages. Even on modern frameworks like Laravel still have a lot of default assumptions of being hosted on a server all by themselves.

It's weird how a language that gained so much traction for being the easy language to host has become one of the harder ones to deploy in the modern era.

<comment><USER10> It is fairly simple to host, as long as you run on a single machine. (Host volume mount in Docker for eg).

</comment></comment></comment></comment></comment><comment><USER11> I don't hate PHP either. I just want to be able to get another job doing something interesting after I spend 18 months at your company.

Otherwise I'll be stuck in the public sector maintaining broken Deloitte unemployment portals, making 1/3rd of what junior coding academy developers make.

Easy calculus.

<comment><USER12> This comment is so true it hurts to read. Same can almost be said for other languages I actually _do_ like (perl, clojure.. sure there's _some_ jobs but the market just isn't the same as many others)

Source: left php about a decade ago and I'm not looking back

</comment></comment><comment><USER13> PHP to me is a bit like the new Perl. Sometimes you just need a small script that does one thing well. Took me 10-15 minutes to implement an interface for customer support so they can look up a clients last order based on incoming phone number (via Aircall) or name and surname. FTP'd it to an already existing company server and it just works. And saves them weeks of time over a year probably. Nobody cares that I debugged it via die("error");

With Python I'd be stuck reading the latest tutorial on how to deploy virtualenv properly. Java/Spring I'd die of boredom before I figure out where WebMvcAutoConfigurationAdapter wants me to put Bootstrap css this year. Sometimes you just want a quick solution to an easy problem and move on to other things than coding, and I find PHP fits that use case perfectly.

<comment><USER14> something about just getting the job done, i remember working at a place like that. i think we romanticize it a little bit though. we didn't have any version control, and deploys were literally paste the file on var/www and refresh. onboarding a new engineer, spend a month before they are actually productive.

i'm glad those times happened, they were fun - but i wouldn't want to work like that today.

</comment></comment><comment><USER15> After reading the PDO section, I started to wonder if the author has used a language other than PHP. How can PHP have the best database integration if the best example you can show are simple prepared statements?

<comment><USER16> "Best" is subjective, though, isn't it? What do you regard as being better? Personally I hate frameworks like Zend which abstract database operations into multi-parameter functions. It serves very little purpose when you can just write actual SQL, in my opinion.

<comment><USER15> I'm sure that a lot of other people have great experiences with other database interfaces such as C#'s Linq or Ruby's ActiveRecord, but that really isn't the point of my comment. The PHP snippet in the article is pretty much the bare minimum for SQL integration in other languages. As another reply to my comment points out, the PHP snippet posted is nearly identical to Perl's DBI (which I believe PDO is based on), which came out 1995!

For an article that purports "PHP is good now", I wouldn't expect one of the selling points to be something that could be done in (and is routinely done), in Python/Perl/Ruby for over 25 years now.

</comment></comment></comment><comment><USER17> I recently had to work on a PHP codebase. It wasn't a very old one in terms of churn, but it had been around for a while. It was surprisingly clean and well- built from what I could tell, it just got lost in a transition to a new server in a new language. Symfony itself still has some warts in terms of boilerplate but it wasn't difficult to poke around the code. In fact, the most painful bit was setting up on a Mac because the extensions for IMAP and other things weren't easy to add in. That's more of an issue with Homebrew and their decision to reduce what they were willing to support.

Language wise, it's catching up a lot and the additions seem to be sensible enough. I'm not sure I would start a fresh project in it but it's great to see how it's matured over the years, and just like Typescript is to JS, I hope it provides a good introduction to things like static typing to novice programmers who are starting out with PHP for pure ease of use.

Beyond that, what's the point in hating a language? I've found real joy and enthusiasm in playing with different ones just to get a feel for how you would approach certain problems with them.

<comment><USER18> There's no point in hating a language. A former boss of mine had a saying (which I'm sure he didn't invent, but he definitely lived up to it and I admired him a lot) which was "love the problem, not the tech". He took pride in engaging with any problem to the best of his abilities, regardless of the language. He thought it was pointless to complain about the tech itself; if the tech wasn't suitable maybe it was part of a problem to be tackled rationally, not with hatred.

That said, I'm uncomfortable working with languages which I feel are outdated and get in the way, such as COBOL. You could say I do hate COBOL. I really, really disliked javascript in its infancy; you fought the (lack of) tools and suffered a lot just to achieve something that would have taken you 5 minutes with other languages. This is not the javascript of today, mind you.

One last thing: one should always be wary of the Blub Paradox (one of the best essays by PG in my opinion; I don't particularly like the rest, mind you). People who ignore advances in programming languages tend to look at "their" language, maybe praise its late-coming improvements, and wonder why other people think it's not enough. But it's often not enough indeed, once you learn those other languages...

I've no opinion of PHP because I've never used it.

</comment></comment><comment><USER19> One advantage of PHP over Node or Java is that it is stateless, so no worrying about memory leaks. And most disadvantages of this disappear when scaling out.

<comment><USER20> I mean, you generally want node to be stateless too. the DB should be your state.

<comment><USER21> "Stateless" here meaning that a given process only lives as long as it takes to receive and respond to a single request, as in the classic CGI model (where PHP originated), or like how an AWS Lambda works.

In practice it mainly means that, in exchange for process startup overhead added to your response times, you get to get away with being sloppy about how you initialize and dispose of resources. It's not something I have ever really regarded as a virtue, and it's one reason why PHP devs can have real trouble transitioning to platforms where the same assumption no longer holds.

<comment><USER19> Yes, transitioning elsewhere can be an issue for sure!

But dealing with small leaks that build over time can be a time sink to track down, particularly if in libs you didn't author.

</comment></comment></comment></comment><comment><USER22> I'm rewriting a personal project from Go into PHP.

Some folks might call that backward. I call it solving a problem with the right tool.

<comment><USER23> Go may not be the best language for your project, but what makes PHP better than the entire set of languages that aren't Go?

<comment><USER22> The two best reasons are these:

1\. The Laravel ecosystem.

2\. I have over ten years of PHP experience.

<comment><USER23> Using PHP sounds like a perfectly sensible choice, given your circumstances. Your argument falls short of convincing that PHP is the best tool for _everyone_, though.

1\. I'm not aware of any non-trivial feature in Laravel that isn't matched by e.g. Rails, Django, Elixir, or indeed any sufficiently modern web framework.

2\. This speaks more to where your comfort zone resides than any intrinsic merit of the language/ecosystem.

To be clear: there's nothing wrong with your using PHP. I'm just left wondering what your initial point was... that PHP is your favorite language?

<comment><USER24> I'm also wondering about the initial point, but ...

Is there ever a best tool for _everyone_?

I have only ever been convinced that something is the best tool for a job, when taking into a account a lot of context, exact requirements, available resources, etc. Otherwise you are almost always left with quite a large number of options that are equal for the information available and you can basically choose from by rolling dice.

Regarding 2) I think it goes beyond comfort zone. I have seen plenty of completely chaotic, unmaintainable code bases due to the initial developer(s) starting the project without any prior experience of the technology. Of course many paths lead to chaos, but I would wary to start anything time critical in something too different to what I'm already quite comfortable in

</comment></comment></comment></comment></comment><comment><USER24> Is PHP still hated on a lot these days?

Isn't it just not that popular an option anymore to start new projects with? Most people are aware of the language having changed a lot since its heydays.

And honestly, from the article I'm not quite sure why I should consider using PHP. Sure, it has a lot of modern bells and whistles now that it didn't when I last used it 2005-ish, but what makes it stand out? I know a number of people that are super happy and productive with modern PHP, but those are all people that have been using it continuously since forever so it makes a lot of sense for them. But why switch to it from another stack?

E.g. the supposed best database integration of any language with "PHP Database Objects". At least the examples given are the absolute bare minimum I'd expect to get from such an integration. What makes it the best?

<comment><USER25> The more experience I get, the more I think that most languages are just fine. Coding is increasingly the easiest part of my job. I'd work in PHP if needed. But I'm still not touching MUMPS.

<comment><USER26> > The more experience I get, the more I think that most languages are just > fine.

Quite. Just give me a boring language with a stable ecosystem, mature and extensive tooling and fully understood quirks. That means all the time and effort can be spent building the actual product instead of burning time monkeying around with the shiny-new language.

This means that things like Java and PHP (and C in some domains) are nearly universally the correct answer if your goal is to build a product instead of building a resume.

</comment></comment></comment><comment><USER27> People who hate PHP-- or even worse, hate other people for writing PHP-- generally don't have anything of value to add to the criticisms of PHP. They just dismiss the language entirely, link to 2012-era blog posts about its imperfections, and never bother to see if anything was fixed in PHP 7 (or, as of the end of this year, PHP 8).

This kind of toxic mentality doesn't produce better code, and it sure doesn't produce better coders. It's just free-floating hostility and gatekeeping.

Here's a few parts of PHP that improved in the past 6 years:

* Static type declarations (and return types, and strict typing, ...)

* Composer has become the de facto package manager for the PHP ecosystem

* Better cryptography (bye mcrypt, hello sodium)

* High quality open source libraries (i.e. Guzzle)

And I haven't even reviewed all of the changes coming in 8.0.

<comment><USER28> I think it's fair to say that PHP was okay, historically, but with hindsight, I wish I would have moved on sooner.

I made a lot of money on PHP code. But then realized there were other languages that I could also make money on, that worked better for what I needed. But would I go back? No..

<comment><USER29> What did you switch to out of curiosity?

</comment></comment></comment><comment><USER30> Incoming PHP hate train. Just like every other article that even mentions PHP in any form of positivity.

</comment><comment><USER31> I've been using PHP for years and am a believer. It's just as good, if not better in many cases, as other languages used for similar purpose. Especially with the features PHP 7 brings; I particularly like the more robust type hinting. Just gotta write good code!

</comment><comment><USER32> The part on database access is not a plus for php. Writing sql like that is horrible, especially when it's simple. I'm in a huge refactor right now, where i'm utilizing postgres schemas and doing it with php, like in the article would be absolutely horrible.

<comment><USER33> What part? Prepared statements or migrations? Both pretty standard stuff in all languages so I would like to understand what your alternative is.

</comment></comment><comment><USER34> PHP has been on-par with Ruby and Python for a long time now. There's no reason to hate it, but also not a lot of reason to use it (or Ruby), since I think Python really has the mindshare now.

</comment><comment><USER35> The autoloader feature sounds interesting. I've always wondered why there is so much ceremony around importing modules when it seems like the compiler could figure it out in many cases (e.g. when you follow the Go-like style of having module names at the call site).

For example every Java file seems to start with entire screenfuls of imports.

I've never seen that in any other language. Though I'm sure there are a lot of pitfalls, because module systems tend to grow complex over time.

<comment><USER36> I don't see the appeal in omitting that ceremony. Modern IDEs do it for you. On the other hand, a reader of the code must not replicate the work the autoloader does. If there is a class named Database from the backend module. The concrete class referenced there is highly dependent on the environment, the autoloader has at runtime. For me, this seems to be a source of many non reproducable bugs.

</comment></comment><comment><USER37> > PHP isn't the outdated, clunky language you may think it is.

 _Proceeds to give a long list of outdated and clunky examples that look like a joke next to any modern framework._

<comment><USER38> Which modern framework? The most common alternative: python. A 30 year old language with two completely different syntactical versions 2 & 3\. Packed with all the great shit fest, eg: urllib, urllib2, urllib3.

<comment><USER7> Python isn't a framework, but in contrast to Pythom, PHP made some bad decisions that are hard to roll back, the biggest being cramming hundreds of inconsistently named standard library functions into the default namespace. PHP can be very productive but I think it's fair to day it was designed a lot less intentionally than many languages.

<comment><USER37> PHP is very guilty of cramming hundreds of inconsistently named standard library functions into the default namespace, but I wasn't aware of Python doing this?

<comment><USER7> Wrote the opposite of what I meant. Thanks for pointing it out while I can still edit :)

</comment></comment></comment></comment></comment><comment><USER33> Laravel is the only reason I'm using PHP but it's a good one. Hands down the best framework I've ever used in any language.

<comment><USER39> What makes Laravel so good and why can't we clone to a framework in say Python?

<comment><USER40> I'd say Laravel is a younger, clumsier Rails, based on personal experience of Laravel and having casually watched Rails evolve from the sidelines.

I don't think any Python folks would bother to clone it as most of what it does already has better answers in the Python world.

For example, SQLAlchemy is amazing, and I'd never willingly swap it for Laravel's ActiveRecord implementation.

To be clear, I definitely prefer Python to PHP, having worked professionally in both languages (PHP much more often, and currently).

<comment><USER10> Laravel has had features before Rails ActiveQueue(?) for eg was adopted in Rails core a few years after Laravel had a stable Queuing system. Rails delegated to Sideqik for long and that caused issues for the ecosystem.

</comment></comment></comment></comment><comment><USER5> Many comments here complaint that this article doesn't convince them to use PHP. Well, I think that is not the purpose of this article either. In my opinion, it only lists some feature of PHP to show that actually PHP as a language an ecosystem also has the feature other considered modern languages have.

</comment><comment><USER41> I think a lot of people are confused at the lack of comparative statements here. As far as I can tell, every single benefit listed in this article also comes with, say, a Python/Django stack.

</comment><comment><USER42> I still prefer using PHP than Java or something else when it comes to write proof of concepts.

Nothing can beat features like hot reloading, fast debugging, get things done in a matter of few hours.

<comment><USER43> As I understand you have probably never used python or ruby ;) ?

<comment><USER42> yes indeed, but you can find cheap PHP hosting, while for python or ruby it requires more steps

</comment></comment></comment><comment><USER44> > PHP has the best database integration of any language I've used

Entity Framework in .NET is lightyears ahead of PDO.

I'm a fan of PHP but the DB connectivity is definitely not one of the strong points.

</comment><comment><USER45> Whatever irritations I may have with current PHP-the-language (my biggest one is it's too easy to make string handling mistakes) are dwarfed by my irritations with that decrepit but incredibly popular PHP behemoth, WordPress.

The spirit of early-days security-ignorant PHP lives on in WordPress, where proper security is basically impossible. You'll never be confident that you've found all the back doors after an incident.

</comment><comment><USER46> One of the not so obvious reasons to like PHP is how quickly it brings business value to the table.

</comment><comment><USER47> Really appreciate all the good feedback and discussion here! Maybe some topics for a follow-up

</comment><comment><USER43> Sorry guys,PHP is the outdated! (From someone who start PHP in 2000 with PHP 2.0 and is still reading lastest Laravel code source). To young people: choose your language wisely, you don't need to know PHP to be successful in Web dev

<comment><USER48> The top open-source ecommerce platforms (magento, woocommerce, etc) and content management systems (wordpress) are all in PHP, and yes they were written before 2000. You don't need to know PHP to be a successful web dev if you are working at a silicon valley tech / social media company, but e-com and content management are still what most companies are trying to do on the internet, and if you are interested in a tech career outside of silicon valley, being handy with PHP is great.

<comment><USER49> That's certainly true, but we're living in a funny time, everything has evolved so quickly that there are 15yr old PHP apps rubbing shoulders with 7yr old Rails apps next to 4yr old Node apps and now React etc. Some of that represents actual progress, some fashion, but for all those legacy apps, someone has to keep the lights on (until the plug gets pulled). That said, I don't really miss PHP too much, it was much nicer than Perl for adding a little magic to html, but building anything big was not fun (I gather Laravel makes that better these days, but there are a lot of other choices if you're starting fresh).</comment></comment></comment>


The Price We Pay for Sitting Too Much - <AUTHOR> http://www.wsj.com/articles/the-price-we-pay-for-sitting-too-much-1443462015?mod=e2fb <comment><USER2> About the actual article though (thanks for the tips that allowed me to view it even though it was jumping through hoops): These sit/stand articles are starting to drive me crazy. I bit the bullet and spent $500 on a convertible sit/stand rig for my desk. I try to split the difference sitting in the mornings and standing after lunch. This article, however, suggests that I sit for 20 minutes, stand for 8, and do something for 2, every 30 minutes?! How the heck am I supposed to get any actual concentration done in a day?!

</comment><comment><USER3> Can we stop posting WSJ until the paywall comes down? I know there are work arounds but it's useless to me to click this article and realize I need to do the ol' "Come From Google" trick.

<comment><USER4> This is answered here: [https://news.ycombinator.com/item?id=10178989](https://news.ycombinator.com/item?id=10178989). If the paywall has a standard workaround, then it's ok for HN. It's not a great situation but it's better than the alternative.

Subthreads like this one, which are always the same, are off topic.

Flagging WSJ, NYT, etc. articles merely for being behind paywalls is an abuse of flagging.

</comment></comment><comment><USER5> Link without login needed: [http://www.wsj.com/articles/the-price-we-pay-for- sitting-too...](http://www.wsj.com/articles/the-price-we-pay-for-sitting-too- much-1443462015)

<comment><USER6> Or click the "web" link under the title.

<comment><USER7> Never noticed that. Brilliant addition!</comment></comment></comment>


The Eureka Hunt: Why do good ideas come to us when they do? - <AUTHOR> http://web.mit.edu/ekmiller/Public/www/miller/News_Articles/Lehrer_Insight_New_Yorker.pdf <comment><USER2> The part about thinking hard then stepping away from a problem before the eureka moment reminds me of "A Technique for Producing Ideas".

[http://books.google.com/books?id=a8EqjMJXXEMC&dq=a%2Btec...](http://books.google.com/books?id=a8EqjMJXXEMC&dq=a%2Btechnique%2Bfor%2Bproducing%2Bideas)

</comment><comment><USER3> Adding a pdf warning might be nice.</comment>


Stuxnet: Zero Victims - <AUTHOR> http://securelist.com/analysis/publications/67483/stuxnet-zero-victims/ <comment><USER2> The title should read something like "Initial victims". The article isn't claiming there weren't any victims; it's just the opposite, that there were multiple (5) primary sites affected by the attack, which they attempt to pinpoint and analyze.

I guess the chose the title by analogy with the term "patient zero", since "patients zero" wouldn't have quite made sense.

<comment><USER3> Perhaps "victim zero" then?

</comment></comment><comment><USER4> In reading this, I'm astonished at how primitive Stuxnet was. If I were writing a worm that saved information on infected systems, I would have:

       created a public/private key pair
       included the public key in the worm
       encrypted interesting stuff with the public key

That way nobody would be able to decrypt any of the information saved by the worm if they didn't know the private key.

Does that make sense or am I missing something obvious? Why did Stuxnet keep a cleartext embedded trail of systems it traversed? I can't grok that at all.

<comment><USER5> It is possible they chose not to encrypt things with public/private keys (asymmetric crypto) because generally that is slow and computationally intensive, as compared to using symmetric crypto. If the goal was to be as stealthy as possible then creating asymmetrically encrypted blobs on the victims machines may have been too obvious. They couldn't have used symmetric crypto because the key would need to have been kept on the machine performing the crypto, thereby rendering it useless.

My guess is they figured stealth would provide the protection they needed and the possibility that errors/corruption during encryption, storage, and transmission was an unacceptable risk at the time. Another possibility is that large blobs of encrypted data on the victim machines would be obvious and possibly flagged, thereby compromising the stealth of the operation. Or the devs simply didn't have time.

</comment></comment><comment><USER6> Please change the submission to a secure URL: [https://securelist.com/analysis/publications/67483/stuxnet-z...](https://securelist.com/analysis/publications/67483/stuxnet- zero-victims/)

</comment><comment><USER7> > The name could mean that the initial infection affected some server named > after our anti-malware solution installed on it.

Unlikely to be a server given that OS version number on the "KASPERSKY ISIE" line is 5.1, which corresponds to that of Windows XP [+].

> KALASERVER, ANTIVIRUSPC, NAMADSERVER: judging by the names, there were at > least two servers involved in this case too.

..also judging by the "5.2" on each line, which corresponds to the OS version of Windows Server 2003 (including R2). "5.2" also could indicate Windows XP 64-bit Edition, but that seems much less likely to be the case.

[+] [http://msdn.microsoft.com/en- us/library/windows/desktop/ms72...](http://msdn.microsoft.com/en- us/library/windows/desktop/ms724832%28v=vs.85%29.aspx)</comment>


Pakistan Man Has Been Eating Fresh Wood and Leaves for 25 Years - <AUTHOR> http://amp.indiatimes.com/news/world/pakistan-man-has-been-eating-fresh-wood-and-leaves-for-25-years-has-never-fallen-sick-276255.html <comment><AUTHOR> So has his gut bacteria changed to process leaves and wood.</comment>


Atom Shell framework - <AUTHOR> https://github.com/atom/atom-shell

<comment><AUTHOR> The Atom Shell framework lets you write cross-platform desktop applications using JavaScript, HTML and CSS. It is based on node.js and Chromium and is used in the Atom editor.</comment>


To build a social network. would you use off the shelves (like joomla) or build from scratch?   - <AUTHOR>

<comment><USER2> Build your own. The thing to keep in mind with social networking is that it should not be the only draw of your website, but should be an added feature that makes the draw of your website more interactive. Also, I just completed a site that includes social networking, and it was so much easier to integrate with the focus of the website, because I built it from scratch.

</comment><comment><USER3> build from scratch. There are too many headaches with open source software...people making buggy modules that you have to wait for them to fix, finding hacks or ways around you getting things done add up to slow, clumsy websites :(

</comment><comment><USER4> I've worked with Joomla's social networking features in the past. Avoid.

</comment><comment><AUTHOR> Thank you all</comment>


Text Editor: Data Structures - <AUTHOR> http://www.averylaird.com/programming/editor/2017/09/30/the-piece-table/ <comment><USER3> I use ropes in xi editor. I did not find the argument against ropes convincing. Yes, they're not trivial to implement, but in a proper programming language you're not dealing with the data structure directly, you're always going through the interface, so you get the logic right once in the rope library implementation and then forget about it.

In a low-level design, your editing operations would be poking at the data structure directly. There, the simplicity of a gap buffer is a pretty big win. I agree in this environment ropes are too complicated. However, I don't see any good reason to architect a text editor in this way. Use abstractions.

The linked article contains a factual error, the referenced Crowley paper does not consider ropes. Thus it cannot be used in support of the argument that piece tables outperform ropes.

There's one other important concern with piece tables I didn't see addressed. It depends on the file contents on disk not changing. If your file system supported locking or the ability to get a read-only snapshot, this would be fine, but in practice most don't. It's very common, say, to checkout a different git branch while the file is open in the editor. Thus, the editor _must_ store its own copy to avoid corruption. In the long term, I would like to see this solved by offering read-only access to files, but that's a deeper change that can be made piecewise.

<comment><USER4> _"I agree in this environment ropes are too complicated. However, I don 't see any good reason to architect a text editor in this way. Use abstractions."_

Abstractions can cost you dearly. If your abstraction for indexing into your buffer moves from O(1) with a small constant to O(log(n)) with a larger one, that global replace using regular expressions can get a lot slower. Even a simple page down may get noticeably slow when at the end of a large file with long lines.

<comment><USER5> Then you've chosen the wrong abstraction.

<comment><USER6> Maybe I've misinterpreted the discussion, but there's not always a perfect abstraction [1].

1\. [https://www.joelonsoftware.com/2002/11/11/the-law-of- leaky-a...](https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky- abstractions/)

</comment></comment></comment></comment><comment><USER7> _The worst way to store and manipulate text is to use an array. Firstly, the entire file must be loaded into the array first, which raises issues with time and memory. Even worse still, every insertion and deletion requires each element in the array to be moved. There are more downsides, but already this method is clearly not practical. The array can be dismissed as an option rather quickly._

The authors of the dozens of tiny editors using this "structure", which were quite popular on the PC in the late 80s through early 90s, would disagree. A memcpy/memove() runs at many GB/s on a typical machine today, so you would have to be editing absolutely _huge_ files to notice. Even back then, memory bandwidth was a few MB/s --- still plenty fast, considering that the typical files of the time were also much smaller.

I can remember a time when I was attempting to write my own editor and at first spending a lot of time obsessing over the data structures (it was harder to find such information at the time) --- only to realise that a lot of the editors I'd tried, including the one I was using the most at the time --- were working perfectly well with just one big buffer.

I've opened files of a few hundred MB in Windows' Notepad, which also belongs to this family of editors; and on a machine a few years old, opening the file takes the longest because it has to be read into memory --- once it's opened, moving around and editing lines doesn't show much lag at all. "Worse is better", indeed.

<comment><USER8> Emphatically: Yes! KISS.

Moby Dick, at its slender 752 pages, is 1.2MB of text. You can save the entire text to disk on every keystroke on just about any system today and keep up with typing just fine.

Assuming you are actually dealing with text in a _text editor_ , you should be fine.

If you have 100MB+ files, chances are they aren't actually text.

<comment><USER9> Log files..

<comment><USER8> Fair point, but do you actually _edit_ log files in a text editor?

Because if you're just viewing, the "array of characters" representation is going to beat just about any other hands down, especially if you just mmap() the whole thing.

<comment><USER9> True. Generally no, but sometimes I will insert several empty lines around a particular line of interest..

</comment></comment></comment></comment></comment><comment><USER10> Y'all should have a look at ewig which uses Immer - really fast persistent data structures for c++. Ewig is just a proof of concept, but the code is really nice. I have thought about taking that and building something bigger.

The upsides are the same as for a piece table (really simple undo/redo) but with the downside of not being able to just mmap a file. You also get basically zero memory usage when you do cut and paste (you can paste a file into itself until it is bigger than RAM without problems, since you are actually not copying the contents, just the pointer)

Look at the YouTube video as well. It is all very cool, at least if you are not already spoiled by using clojure :)

[https://github.com/arximboldi/immer/blob/master/README.rst](https://github.com/arximboldi/immer/blob/master/README.rst)

Edit: Forgot to mention: Ewig can be found among Immer's author Arximboldi's repos. On my phone right now on GPRS connection, so maybe another friendly soul can provide the link.

<comment><USER11> Thanks a lot for mentioning it! :-)

Ewig uses RRB-Trees (Relaxed Radix Balanced Trees) which like ropes, is confluent (supports fast concatenation) but has very stable bounds otherwise, similar to a vector-like type.

EDIT: The parent mentions a video, I gues it is the CppNow talk: [https://www.youtube.com/watch?v=ZsryQp0UAC8](https://www.youtube.com/watch?v=ZsryQp0UAC8) Last week I did another version of that talk at CppCon (with slightly deeper coverage of Ewig) but I don't think it is in Youtube yet.

<comment><USER10> I think immer is brilliant. I just saw that you have guile bindings, which makes it even more exciting!

I like that they are lgpl as well. I am a believer in that kind of freedom definition, and I hope you can dual-license it successfully.

</comment></comment></comment><comment><USER12> Atom uses a piece-table-inspired data structure to represent text[0]. We store the file's original contents in a single contiguous buffer. All of the user's unsaved edits are then stored in a separate mutable structure called a Patch, which we represent as a splay tree. When we need to read from the buffer in a background thread, we can 'freeze' the patch, and store any subsequent writes in a new patch which is layered on top of the previous one.

Even though we do load the entire file into memory (as opposed to mmap-ing the file), the piece table design is still very useful. It makes it very cheap to compute the buffer's current unsaved change set, which is a value that we periodically serialize for crash recovery purposes (similar to vim's `.swp` files).

It's also just a very compact way to store a large chunk of text, which is good from a cache-locality and memory usage perspective.

[0] [https://github.com/atom/superstring/blob/master/src/core/tex...](https://github.com/atom/superstring/blob/master/src/core/text- buffer.h)

</comment><comment><USER13> I've been doing the same thing (implementing a text editor for fun) and settled on a data structure which is a hybrid rope+2-3 tree+B+tree+gap buffer. I don't know what to call it but maybe someone here has seen it before.

Basically the idea is, the inner nodes are a 2-3 tree which track the size of each child like a rope does. The leaves are gap buffers of a fixed size (a few cache lines), which, when full, split into two like leaves of a B+tree. So you get the dense-ish packing of a gap buffer with the O(log n) performance guarantee of a 2-3 tree, while avoiding the potential linear copies associated with ropes and gap buffers.

(I know this is overkill for a toy text editor but it wouldn't be a side project if it weren't!)

<comment><USER14> I did something like this recently too. A b+tree w/ linked leaves containing piecetables in the leaf nodes. To avoid the memmove() costs it uses the right- edge of the leaf to keep a sorting queue so the operations are still O(1) inside the leaf.

I still need to finish up deletions, but early performance numbers are showing similar/better than the RBTree approach while being much more cacheline/allocation friendly.

Ultimately, I want to use this in a replacement for GtkTextBuffer/GtkTextView in gtk 4.x.

[https://github.com/chergert/pieceplustree](https://github.com/chergert/pieceplustree)

</comment></comment><comment><USER15> Beyond just loading, editing and saving text, how do these data structures compare when it comes to implementing other "tricky" features, such as:

1\. Multi-line regular expressions. Typically the regex library is given an array of text to search in ( _). We have no such buffer to give.

2\. Line wrap. Adding or removing a single character near the top of the file might require the entire file to be re-wrapped. You need to complete the wrapping process before you know how many lines are in the buffer and therefore can update the size and position of the vertical scroll bar's handle.

3\. Column mode editing of text containing tabs.

Beyond those features, these data structures (gap buffer and piece table) don't seem well suited to operations that effect the entire buffer, such as convert-tabs-to-spaces.

_ At least when I used PCRE, it seemed to require this.

<comment><USER16> 1\. All of them could probably easily create a bi-directional or markable stream of characters, which should be enough for the regex engine to work with.

2\. That's a display issue. I would suspect that line-wrapping would want its own data structure within the display system.

3\. I think this would fall under the same note as (2).

Basically, a layered approach like (display + editing mode) / (buffer) / (array or ropes or pieces or whatever). Because the editing mode would effect the edits being made to the buffer, which would then be translated into whatever underlying data structure is actually storing the file.

<comment><USER15> Reasonable points. As for (1), I couldn't find how to get PCRE to work with a stream like that. But that's either my fault or PCRE, not the text editor data structure.

As for 2, I'd just say that I think these are much harder than the problem that the linked article discusses. There have been other articles on the same topic on Hacker News recently. They all seem to focus on solving the trivial problem and ignoring the difficult ones. I mean, a std::list<std::string> is fine for the main data structure if you just want to load, edit and save and don't require (2) or (3).

<comment><USER16> I've also never seen a PCRE that _actually_ works with such a stream, though it would be _possible_ to construct one.

For your remaining points, sure. I don't know enough about text processing to know where the hard problems are. I do think that engineers sometimes overlook the possibility of having multiple data structures for multiple use cases for a single set of data, because it doesn't seem as elegant as one magical data structure that does it all.

</comment></comment></comment></comment><comment><USER17> Had an assignment in functional programming which was to implement a text editor, an interesting data structure was provided.

Buffer of X is a BackwardsList of X, Cursor X, ForwardsList of X

So if you make Line a Buffer of char and your document a Buffer of Line you can easily insert and remove characters on a line or lines in the document.

If you wanted to move the cursor forwards you could just place the cursor onto the head of the backwards list behind you and take the head off the forwards list in front of you to be your cursor.

<comment><USER18> Such a structure is called a Zipper, for anyone wanting to look into it further.

<comment><USER19> In this case it's a Zipper for a list. You can write zippers for other data structures as well (and in fact you can mechanically derive them, even).

</comment></comment></comment><comment><USER20> > They should! Why aren't they!?!?! Somebody needs to make that a markdown > extension. Every time you want to insert an indexed footnote, you type [^#]

Probably because there's no elegant way to support all the potential edge cases of that default behavior. For instance, if you introduced a reference with that format, you can't refer to it later - if you use the static number and it changes, you're now pointing to the wrong reference. So it reduces to using names, and the hassle of coming up with a name for each new link or footnote reduces to just using numbers - so the only thing that needs to be supported is manually named or numbered items.

The author correctly describes the ideal solution - a plugin that replaces unnamed links before saving or such - but likely fails to understand why that (as opposed to adding behavioral cruft to a markup language) is the correct level of abstraction for such a solution. Imagine if a project like wikipedia was riddled with the ambiguity of dozens of people's various attempts to wrangle the autonumbering to their writing.

<comment><USER21> Interestingly (and IMHO unsurprisingly) org-mode does this correctly[0]. Footnotes are identified by 'fn:' and a unique token (of course, numbers are unique tokens); they can be easily inserted with C-c C-x f, and can also be renumbered — including normalisation.

I reminded of this discussion from a week and a half ago: [https://news.ycombinator.com/item?id=15321850](https://news.ycombinator.com/item?id=15321850)

IMHO org-mode is, as the original author puts it, 'one of the most reasonable markup languages to use for text.' I suggest that rather than trying to improve Markdown, folks just use org-mode instead.

[0] [http://orgmode.org/manual/Footnotes.html](http://orgmode.org/manual/Footnotes.html)

<comment><USER22> I still think that org-mode and Markdown have quite different targets.

org-mode seeks to be organized and manipulable, whereas Markdown seeks to be readable, and parsable.

</comment></comment></comment><comment><USER23> I had a technical interview once where the interviewer asked me to create a data structure for a text editor written for a 1980s computer with extremely slow and expensive I/O and almost no ram. I ended up with a variant of the piece table and afterwards he told me that's how Word worked (he used to work at Microsoft).

<comment><USER24> That reminds me of this tutorial for writing a text editor (in win32 land): [http://www.catch22.net/tuts/piece-chains](http://www.catch22.net/tuts/piece- chains)

</comment></comment><comment><USER25> I know the conventional wisdom is that you can't use an array, because O(n). How big of a file can you insert a character into with an O(1) algorithm before it takes more than one refresh time (16 mS)? From the following test program, the file can be 150 MB of text (MBP 2015). I've never had a source file, even a generated one, this long. So I claim that this wisdom is obsolete.

      #include <stdlib.h>
      #include <string>
      using namespace std;

      int main(int argc, char **argv)
      {
        size_t size = (size_t)atol(argv[1]);
        string editor_buffer(size, 'x');

        for (int iter=0; iter<100; iter++) {
          editor_buffer.insert(5, "foo");
        }
      }

</comment><comment><USER26> More abstractly, I enjoyed a description of a text editor in a Categories for Computer Science class I took waay back.

It's two stacks head to head. Moving the cursor is popping on one and and pushing on the other. All the other operations were given too. There were the category diagrams and everything -- the meat of which I've forgotten but I might be able to find if anyone is interested.

<comment><USER27> I'd be interested. Using two stacks is a nifty technique.

<comment><USER28> That technique sounds analogous to using a zipper to traverse a list (I've found a decent looking link for the technique if you're interested - [https://ferd.ca/yet-another-article-on-zippers.html](https://ferd.ca/yet- another-article-on-zippers.html))

</comment></comment></comment><comment><USER29> One thing I think about a lot in these situations is how constraints that come in at the high level can end up influencing your low level design. I've spent the last couple months writing a codemirror replacement for an in-house DSL IDE (in Javascript).

My particular use case required that I parse whatever was written in the editor in a few ways: a lexer pass for syntax highlighting and a full parse for semantic feedback (much of which is provided somewhat unpredictably from AJAX calls, for various reasons). And I knew that touching the DOM (which I'd have to do to keep the syntax highlighting/semantic feedback up to date) is typically going to be a lot slower than doing a few thousand loop comparisons in JS.

I looked into structures like ropes and whatnot that would enable fast edits, but I realized that in the end I wasn't going to do better than linear in the worst case, for a few reasons, e.g.: 1\. Suppose the user enters an open quote at the first character: every other character just flipped from outside a quote to inside or vice versa and I'm going to have to re-parse the whole document to update my semantic analysis (and syntax highlighting, though that would only require a partial re-parse). 2\. Edits that change the line number associated with errors are going to require me to update that display and you can make a document with a number of errors that grow linearly, so entering a newline at the first character was potentially linear...

So I ended up just using a doubly linked list of tokens (as returned by the lexer) and re-lexing tiny sections around a cursor when the user enters text. Collectively the whole thing turns out linear and but it saves a ton of work by re-using the same structure when I'm doing parsing and semantic analysis. Doing it this way let me do my own DOM reconciliation and update the absolute minimum number of DOM nodes for every edit, which ultimately has a huge effect on performance because touching the DOM is expensive. And one can set this up so that (at least from the lexer's perspective) undo involves just snipping the old middle segments of the list back into place.

So it turned out that higher level requirements (eventually having to actually parse the text and update the display in various ways) made it so I wouldn't really save any work optimizing at the low level.

</comment><comment><USER30> The most costly operation is usually showing the text on the screen, so you want to optimize the data structure for that. Although it depends on what level you are programming on. Updating arrays is _not slow_ (unless the file is huge) and can be done in parallel.

</comment><comment><USER22> The other day, I was implementing a Piece Table in Haskell, and realized a "Piece" is a "Monoid", and a "Piece Table" (which I call a "Buffer") is just a list of "Pieces".

        -- A Piece is a String, start, and end.
        data Piece a = Piece { list :: [a] -- 'a' will be 'Char' later, but we can support any type here.
                             , start :: Int
                             , size :: Int
                             } deriving (Show)

        -- Pieces are Monoids, like Lists, Trees, etc.
        --  note that the type declarations here are not allowed (Monoid defines them already). I put them there for your leisure.
        instance Monoid (Piece a) where
            -- mempty is an empty Piece.
            mempty :: Piece
            mempty = Piece mempty 0 0
            -- mconcat takes a list of Pieces, and condenses them into one Piece.
            mconcat :: [Piece] -> Piece
            mconcat = foldl mappend mempty
            -- mappend takes two Pieces, and puts them together, resulting in one Piece.
            mappend :: Piece -> Piece -> Piece
            mappend (Piece firstList firstStart firstSize)
                    (Piece nextList nextStart nextSize) =
                        let start = fst $ splitAt nextStart firstList
                            middle = nextList
                            end = snd $ splitAt nextSize firstList
                        in Piece (concat [start, middle, end]) firstStart firstSize

        type Buffer = [Piece Char]

Now we can implement some pure manipulations:

        -- replace creates a new Piece, and appends it to the Buffer.
        replace :: String -> Int -> Int -> Buffer -> Buffer
        replace text from to buffer = buffer ++ [(Piece text from to)]

        insert :: String -> Int -> Buffer -> Buffer
        insert text at = replace text at 0

        delete :: Int -> Int -> Buffer -> Buffer
        delete from to = replace "" from to

...and all that is left is to get the text from the buffer

        bufferText :: Buffer -> String
        -- mconcat folds our Pieces together, resulting in one Piece
        -- list gets the Piece's "list" (String = [Char] in Haskell)
        bufferText = list . mconcat

Now to use it, all we need to do is string our manipulations together:

        >>> buffer = replace "Hello" 0 7
                   $ insert ", world!" 7
                   $ insert "Goodbye" 0
                   $ mempty

        >>> bufferText buffer
        "Hello, world!"

<comment><USER22> One advantage that is obvious now is that "Char" isn't specified until we define "Buffer", meaning a "Piece" can deal with _any_ datatype, so you can easily get your Piece Table to deal with _any_ character format from ASCII, UTF-8, UTF-16, etc. to raw bytes, Hex values, etc. It's even fairly obvious how to merge buffers that use different character formats.

The strongest point I see regarding Piece Tables is that Pieces are so discrete. You can define a Piece to be whatever you want it to be, as long as you implement "mappend" for it, or you can put the Piece in a box with other data, and make your buffer a list of boxes, and define "mappend" for the rest of the "box"'s data.

Another fairly obvious implementation is an undo/redo tree (like Vim has): Instead of Buffer being a List of Pieces, it can be a Tree of Pieces. The buffer is merged by merging the leftmost leaves of the tree, and "undo" is done by swapping the last left Leaf with an empty Leaf. Redo is done by rotating the last left node's leaves.

A final note regarding the above implementation: This simple mappend can only merge Pieces in order. If a Piece tries to edit part of another Piece that doesn't exist (out of bounds), it will be appended, or prepended without any filler, because that is how "splitAt" handles edge cases (rather than being implemented with Maybe). It wouldn't be too difficult to implement "mappend" for these edge cases, but you would need to decide on a filler character like space, or you would have to implement some kind of lazy merge that just keeps the second Piece around until it can be merged.

<comment><USER19> If you use persistent data structures in your implementation (like would be the default in Haskell), your data structures themselves don't need to know about undo/redo. Just keep references to the old state around (in an undo tree or a linear structure for simplicity), and just switch back to them if necessary. Don't explicitly manipulate your data structures. Sharing will take care of keeping the overheads low.

<comment><USER22> > Don't explicitly manipulate your data structures. Sharing will take care of > keeping the overheads low.

Immutability is one of the strong points of Piece Tables.

Don't forget that this is the most _simple_ implementation of a Piece Table. If you are in any way concerned about performance, you can quite easily implement caching, sharing, etc.

<comment><USER19> I suspect we are in violent agreement. I was just taking aim at

> [...] "undo" is done by swapping the last left Leaf with an empty Leaf. Redo > is done by rotating the last left node's leaves.

Which is more complicated than you need to be in an immutable setting to implement undo/redo.

</comment></comment></comment></comment></comment><comment><USER31> Back in the mid 90s I created a shareware text editor that ran on Windows 3.1 (on a 80386 machine) and was written in C++ using pure Win16.

At that time I used a _double link list_ like structure with a _line cursor_ to help with list traversal.

While this was not one of the _formal text editor_ design patterns, I found that pattern very worked well.

<comment><USER32> Maybe it only worked well because you never encountered a file consisting of one very long line? Back then most somewhat human-readable data formats where line-based. Lines also where the de-facto standard work unit for stream processing so that there was an implicit understanding that a large file without newlines would not be processable as text even if all parts of that line were human readable. This only changed once XML went big which made most newlines a convenience that is frequently omitted in machine to machine communication, a paradigm shift that almost all younger formats followed. Now those m2m versions of optionally linebroken data occasionally hit our editors and make the limitations of lines as the basic unit of text editors painfully noticeable.

That being said, I have often seen otherwise reliable editors choke on very long lines, so your former self would still be in good company, even two decades later.

<comment><USER31> > Maybe it only worked well because you never encountered a file consisting of > one very long line?

You correct when you say very long lines are hard to handle, but I'm not sure this is because of the internal data structure used.

In this case the internal data structure allocated a line buffer at every node of the double linked list and even on that Win16 environment that allowed for a line size of up to 64 kBytes (i.e. 2^16) in length.

However, to handle tabs correctly the editor is forced to recalculate the column position on every user event and since that calculation has to consider the entire line, the time needed to do this _column calculation_ grows with line length.

So the editor could handled long lines but as the line lengths around 500 characters the speed became noticeably slow.

<comment><USER19> You could guess the tab handling with some fast method at first, and asynchronously run the proper handling to catch up with a pause in user input a few seconds later.

</comment></comment></comment></comment><comment><USER33> Interesting comment on lobste.rs to explain why the piece table is rarely superior to the gap buffer: [https://lobste.rs/s/xpab69/text_editor_data_structures](https://lobste.rs/s/xpab69/text_editor_data_structures)

</comment><comment><USER34> If you're interested in this kind of structure it's worth taking a look at 'transclusion' devised by Ted Nelson in the mid 60's [https://en.wikipedia.org/wiki/Transclusion](https://en.wikipedia.org/wiki/Transclusion)

</comment><comment><USER35> I'm always amazed that people are still working on new text editors. When I have an idea for an app and I see there's even only one alternative I usually loose all motivation for coding this app (until I realize the alternative doesn't fulfill my need).

<comment><USER36> I use emacs, but it has lots of problems; I'm still waiting for an editor that combines its good qualities while resolving the problems. (And I'm tempted to try to write one.)

<comment><USER37> What do you think are the problems of emacs?

<comment><USER38> 30 years of cruft + mix/matching of semi-incompatible semi-backwards- compatible systems if you use 3rd-party elisp and/or maintain a config for a long time.

I love emacs, use it daily, and think that it's positives far outweigh it's negatives, but hooo boy sometimes you need to wade through decades of muck to make it do a thing, and it's often not clear what the best way to go about trying to do a thing is, particularly to people who haven't been using emacs for a decade+.

</comment></comment></comment></comment><comment><USER39> Incredibly thorough, are there any plans to implement this into a text editor?

<comment><USER10> It is already in use in a bunch of smaller editors like Vis (iirc)

<comment><USER40> Yeah, the vis implementation is here: [https://github.com/martanne/vis/blob/master/text.c](https://github.com/martanne/vis/blob/master/text.c)

<comment><USER41> That was a great read, and really shows the benefits of writing good comments.

</comment></comment></comment></comment><comment><USER42> I'm more interested in what he will use for the UI. The popular option nowadays seems to embed WebKit, but that has obvious drawbacks. On the other hand, having scouted the grounds myself a year ago, it is one of the easiest option to set up, and it looks the best.

</comment><comment><USER43> The first thing that came to my mind was mmap.

I'm sure there is something very wrong with using mmap and I can probably find the answer with just a google search but it would have been great if it was covered by the article.

</comment><comment><USER44> Well if I ever wanted to ask do I really need to know advanced data structures this answers that question. Really interesting article.

</comment><comment><USER45> Figure out whatever VSCode is doing and use that.

</comment><comment><USER46> Are some types of binary trees favored for making ropes? I heard 2,3 - <USER2> trees are good as a backing data structure for rope.

<comment><USER47> I'd think a relaxed radix tree would be ideal.</comment></comment>


Overview of projects working on next-generation secure email - <AUTHOR> https://github.com/OpenTechFund/secure-email

<comment><USER2> "in an age where we better understand the power of social network analysis and the sensitivity of the social graph, the exposure of metadata by a "Web of Trust" is no longer acceptable from a security standpoint."

That depends on your security goal. Your goal might be to check to see if a message was sent by the person listed in the "From" field, in which case WoT can work very well.

"Nearly every project here uses Trust On First Use (TOFU) in one way or another"

This is not perfect either. In the scenario I described above, TOFU may be less useful than WoT. There are also scenarios in which TOFU makes no sense at all -- maybe I want to anonymously send an encrypted message to someone, and I have no point of reference for their key.

"This is not possible with the traditional protocol for email transport, although it will probably be possible to piggyback additional (non-backward compatible) protocols on top of traditional email transport in order to achieve metadata protection."

Ahem:

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

<comment> mike-cardwell The trouble with the web of trust is that it's basically analogous to publishing your contact list. It may solve some problems, but it creates entirely new ones at the same time.

</comment></comment><comment><USER3> Tangential: anyone know of an overview of projects working on next-gen IRC? I know the standard HipChat, Campfire and Flowdock, and recently discovered Slack and [http://kato.im](http://kato.im). Would love a full list.

<comment><USER4> [https://news.ycombinator.com/item?id=7267226](https://news.ycombinator.com/item?id=7267226). Telegram seems most important in the context of security.

<comment><USER5> Cryptocat and Text Secure are most important in terms of security. Telegram still looks like security theater.

<comment><USER4> Ack, you're right. Subliminal marketing takes hold again :/

My intention was to push back on the references to hipchat, campfire and so on.

</comment></comment></comment></comment><comment><USER6> Looking great,Looking forward for shortcut keys like gmail. Yes i know i am hoping more :) but if i will get chance i will implement it.

</comment><comment><USER7> It's a bit ironic that freedombox is using an expired certificate</comment>


The Biggest Legal Mistakes that Startups Make - <AUTHOR> http://walkercorporatelaw.com/ask-the-attorney/%e2%80%9cask-the-business-attorney%e2%80%9d-what-are-the-biggest-legal-mistakes-that-startups-make/ <comment><USER2> This is a nice summary of many of the legal issues affecting early-stage startups.

Any entrepreneur or startup lawyer can take issue with any given issue but this does not detract from the overall value of this piece.

Points of difference and/or clarification:

1\. LLCs often work fine for early-stage startups, offering an easy and inexpensive way for founders to get started in many cases (caution here: if there is an "always" to be said in these situations, _always_ do an initial consultation with a knowledgeable startup lawyer to at least understand what trade-offs and compromises are involved in doing this sort of "simple" setup because it is not without risks - such a consultation is very inexpensive and well worth it for the knowledge gained - for a start on the main pluses and minuses of an LLC, see my comment here: <http://news.ycombinator.com/item?id=1276805>).

2\. High on the list should be to make sure that IP assignments are done in connection with any equity grant made to founders for work performed before the company is formed. If you don't do this, all such IP will normally belong separately to the founders who did the work and not to the company, even if they do get a fat stock grant at the start. A formality, but a very important one.

3\. I am not dogmatic about Delaware and, indeed, have pointed out that Delaware is more VC-friendly than it is founder-friendly (<http://grellas.com/faq_business_startup_002.html>) - therefore, think very carefully before making this decision. Delaware can be a good pick and may be the best - it just should not be automatic in my view.

4\. Vesting for founders is not always required. It normally is when you have a founding team of relatively equal founders (for the reasons stated in this piece - you don't want someone casually walking away with a big piece of the company). If one founder is dominant in relation to others being brought in for more secondary roles (and for comparatively small equity pieces), there is no need necessarily for the primary founder to make his shares subject to vesting at inception. Of course, if the company gets funding, investors likely will insist that vesting apply but not all startups look to fund in this manner. At the start, (1) all founders can have their stock subject 100% to pro rata vesting; (2) none of them need do so; (3) some may be subject to vesting while others are not; (4) any given founder can have his equity grant partly vested immediately while the balance is subject to vesting; (5) such vesting as is used may vary widely, from one to four years or more, with or without cliff (usually not for founders); or (6) any of all sorts of variations on the foregoing. Hence, there is no dogmatic rule here. It all depends on what the founders needs are and how much value they have built up before starting the company (this is relevant because vesting necessarily raises the risk of forfeiture and no one wants to forfeit that which has already been made valuable prior to the start). Collateral issues: accelerated vesting on certain events, such as termination without cause and acquisition - each of these has a variety of issues associated with it and investors in particular will often object to any liberal forms of acceleration.

5\. Tax is often a _huge_ issue at the start if the company formation is mangled - that is, if founders take their "cheap" stock at or about the same time as investors pay large dollars for theirs, there may be a serious risk of service income being attributed to the founders on which they must pay tax.

6\. Concerning 83(b), this is also _huge_ but irrelevant if there is no vesting and no risk of forfeiture connected with the grants made to founders (it is virtually mandatory if stock is granted as restricted stock, with its attendant risk of forfeiture, but not otherwise). It also is not needed for stock options unless there is an early exercise provision which is exercised at the start.

A nice checklist for going through legal issues at the start, with related HN commentary, may be found here: <http://news.ycombinator.com/item?id=1198968>.

</comment><comment><USER3> I'll insert my ad in here, because this topic is so close to my heart: Before incorporating, _if you have co-founders_ , protect yourself with <http://fairsoftware.net>.

I know many people who didn't use us (or a similar co-founder agreement, except we are the only game in town if you are looking for a reputable, lawyer-approved, silicon-valley, tech-friendly one).

They regretted it dearly, later. In general, first time founders are pretty clueless about IP assignment (if my co-founder dumps me, what happens to his 10,000 lines of beautiful Python), vesting (if my co-founder doesn't work out, why does he keep 50% of my company), etc...

You know better than start coding without some kind of code repository. Don't start cofounding without an agreement. You've been warned :-)

</comment><comment><USER4> A couple gripes:

\- You will find a number of angel investors happy to invest in LLC's (depending on the stage and complexity of the funding round). While it's true that some investors require a more complex structure, the blanket statement that it's "required" is just wrong. It can also be destructive. There are REAL benefits to an LLC for a pre-revenue startup.

\- Place of incorporation. I've never had an investor care about the state we've incorporated in. There are obvious tax implications, but it's often easier and cheaper to just do the paperwork in your state. It really just depends.

Points of emphasis:

83b election: This is SUPREMELY important, and applies to anyone attempting to invest equity (under any legal structure). Without properly handling the 83b you run into incredibly onerous tax issues. Learn about it and do it when you incorporate.

<comment><USER5> I disagree re LLC's: not only won't VC's invest in LLC's, but conversion to a C corp can be extremely complex and expensive. Indeed, it cost one of my clients about $15K to address tax issues relative to such conversion. In addition, issuing "stock options" is a nightmare with LLC's - not to mention the extraordinary complexity of operating agreements, with their complicated layer of partnership tax provisions.

</comment></comment><comment><USER6> All good points--I don't completely agree on the LegalZoom issue. Our company incorporated in Illinois through LegalZoom and it worked out great. I've done LLC/partnerships on my own and the paperwork is easy. It's good to think of LegalZoom as a paralegal service and not as a lawyer. We had an actual corporate lawyer draft contracts and other important documents but I'm not paying someone $300/hour to fill out forms.

<comment><USER7> You incorporated in Illinois?

I don't know Illinois law well, but there are good reasons why most corporations are Delaware (with a few in Nevada and a couple other states), including tax and governance issues. Did you ask an attorney if Illinois was the right state for you?

<comment><USER8> > I don't know Illinois law well, but there are good reasons why most > corporations are Delaware (with a few in Nevada and a couple other states), > including tax and governance issues.

CA works really hard to ensure that there are no tax advantages to incorporating elsewhere. If you do biz in CA, you pay CA taxes on that biz (and possibly some other biz - CA wants money).

In fact, CA even has a minimum fee ($5-800 IIRC) for doing biz here even if you don't make money.

</comment></comment></comment><comment><USER9> You don't need a lawyer of LegalZoom to incorporate. Do it yourself, it's even cheaper. Just make sure to do due diligence in your operating agreement. DocStoc has a lot of template that you can reference. However, you should find a lawyer for legal matters when doing agreements for other companies.

If you don't plan on seeking investment, it the short-term you should go with an LLC for simplicity and tax reasons.

</comment><comment><USER10> That post read like a job security pitch for his field. I think as a general rule you want to avoid and delay using lawyers as much as possible: too much complexity, paperwork and cost, too early. Get to a sellable (and selling) product/service first, otherwise you're wasting your money and time.

<comment><USER7> On the flip side of that, a few hours of lawyer time in the first year of Facebook might have saved the IP ownership dispute that has now cost about $100 million dollars in settlements, and might still go higher.

There are a lot of stories of startups that went under because the 50/50 owners couldn't decide on a plan of action, or turned out to not own any of the IP that they thought they owned.

<comment><USER11> So pay us (lawyers) lots now or pay us more lots later.

Last time I heard an offer like that it was some italian americans commenting on how flammable a restaurant was

<comment><USER7> Pay us (doctors) for vaccinations or pay us more later for treatment?

Pay us (construction workers) for high quality materials now, or pay us later for repairs?

Pay us (clothing manufacturers) for high quality clothes now, or pay us again later when yours wear out?</comment></comment></comment></comment>


New Year Offer: 45% OFF on Resumonk Premium Subscription - <AUTHOR> http://www.resumonk.com/buy

<comment><AUTHOR> Resumonk Premium Plan is now just $12 (45% OFF) for a limited time. Use code HNY2014 on Checkout page to redeem this discount.

As a premium user, you get

\- Resumes with no Resumonk branding in the footer

\- Access to our premium templates

\- Unlimited personal resumes

\- .DOC (MS Word) download

\- Custom colors & 10 additional fonts

\- Custom URL

\- Analytics</comment>


No fluff {jobs} - <AUTHOR> https://nofluffjobs.com/

<comment><USER2> Your long descriptions could be in an about page and tell us what it does in 4 words as a subtitle. Right now I went to the page and had no idea what to do. So I typed in "python" and it gave me Scala jobs. It's a good idea. What about a "what is this?" button or something? Your description is more of a testimonial and it was tl so I dr.</comment>


Open Source Analytics: Visualization & Predictive Modeling with R - <AUTHOR> http://assets.en.oreilly.com/1/event/27/Open%20Source%20Analytics_%20Visualization%20and%20Predictive%20Modeling%20of%20Big%20Data%20with%20the%20R%20Programming%20Language%20Presentation%201.ppt OSCON presentation file (PPT) <comment><USER2> Note: Link is to PowerPoint file.</comment>


Show HN: Pros/cons analysis of stocks, ETFs and mutual funds - <AUTHOR> https://www.askfinny.com/analysis <comment><AUTHOR> Trading securities (like stocks) is at an all-time high, and so is the number of new investors. I made this tool to help new investors--it nets out the pluses and minuses of each individual stock, ETF and mutual fund, making it easier for investors to do their due diligence before putting their money to work. You'll be asked to sign in after you use the tool 10 times.</comment>


One more reason it's crap to be a waiter in America - <AUTHOR> http://www.theguardian.com/commentisfree/2013/sep/08/irs-tax-waiter-tips-automatic-gratuities

<comment><USER2> As noted, this doesn't change the substantive tax treatment of tips. It just moves automatic tips into automatic reporting and up-front witholding instead of individual reporting and payment-on-filing (potentially with penalties for underpayment in advance.)

 _Unless_ you are planning on cheating on your taxes, this doesn't do any harm.

> Restaurants are already threatening to end automatic gratuities because it > would be an administrative nightmare to do what the IRS now wants.

This is a thin excuse; if they are charging automatic tips in the first place, they are probably already tracking the information and would have minimal difficulty reporting it as wages and doing withholding from it (since they are already reporting and withholding from base wages.)

More likely, its being used as an _excuse_ to present to tipped staff (who bear the cost of the change of restaurant policy) to justify stopping including gratuities for large parties, when the real reason is to increase the appeal of the restaurant to such parties, but where without an external party to redirect blame for the policy on, management feels that the staff morale drain and resulting reduction in performance/retention/etc. would hurt more than the removal of the policy would help.

</comment><comment><USER3> This restauranteur thinks that tipping makes it harder to reward staff fairly, and that this is a direct cause of acrimony in the kitchen. Some of his arguments are dependent on CA state law, though:

(part 1) [http://jayporter.com/dispatches/observations-from-a- tipless-...](http://jayporter.com/dispatches/observations-from-a-tipless- restaurant-part-1-overview/)

(part 2) [http://jayporter.com/dispatches/observations-from-a- tipless-...](http://jayporter.com/dispatches/observations-from-a-tipless- restaurant-part-2-money-and-the-law/)

<comment> jack-r-abbit Great info (although I've not made it all the way through the first one yet). Interesting to learn that, due to laws, tip sharing is not via a restaurant policy but something that only happens organically among the staff.

</comment></comment><comment> jack-r-abbit > _Restaurants are already threatening to end automatic gratuities_

Please... do it. I don't mind tipping. In fact, I generally tip pretty well (only shorting when service truly deserves less). But it really irritates me when places add the tip in automatically.

Having said that, I don't think it is such a tragedy that some of the server's tips are included in their paycheck. Not many jobs let you take home part of you money everyday. I have to wait 2 weeks to get _any_ of my money.

</comment><comment><USER4> This is why I just say pay people a livable wage and forget about all of this bullshit - the only people this helps are the business owners. And lets face it they are already getting way too many tax breaks. The waiters will get screwed and the customers always feel as though they should give more. If you paid people a decent salary, they wouldn't have to depend on the crumbs you leave them.

<comment><USER5> Given that most restaurants fail rather quickly you would be hard pressed to make the claim that the owners are stealing all the money.

<comment><USER6> If the restaurant is doing poorly isn't more of an incentive for the owner to pocket whatever he can from the business?

</comment></comment></comment><comment><USER7> The IRS is just interpreting the law as they see it. At some point they have to draw the line between a tip and a wage, and they draw the line so that an "automatic tip" is a wage.

All the rest of the article is irrational garbage. The fair comparison is not between how the IRS treats waiters and how they treat billionaires, but rather how the IRS treats waiters of a certain yearly income, and how they treat other workers of the same income.

<comment><USER8> "He don't tip? Whaddaya mean you don't tip?"

</comment></comment><comment><USER9> 1\. Even with any impending crackdown, waiting tables is still a really good paying job if work anywhere but the cheapest greasy spoons (small tabs = small tips).

2\. It's articles like this (squeeze the little guy instead of the millionaires/billionaires) that make me scratch my head as to why the Republicans continue to hate Obama so much. He's been great for the rich, and bad for the poor--just like W, but W was expected to be that way.</comment>


Artificial Intelligence has written a beatles-style pop hit - <AUTHOR> http://www.electronicbeats.net/feed/artificial-intelligence-has-written-a-beatles-style-pop-hit/ <comment><USER2> If you got to the youtube video [1], you'll see that the song was produced and arranged by a human.

[1] [https://www.youtube.com/watch?v=LSHZ_b05W7o](https://www.youtube.com/watch?v=LSHZ_b05W7o)

</comment><comment><USER3> Is this song actually popular, because if not, I'm pretty sure you don't get to call it a "hit". I think when AI starts actually consistently generating _popular_ songs (since that means it's generating stuff people want to keep listening to) is when things will get a bit more interesting.

<comment><USER4> Over 50,000 views and ~500 subscribers! Move over Bieber!

</comment></comment><comment><USER5> Oddly, been mentioning this to students today - most of those I teach are completely unaware of such technology, or how it will impact them in the future. I think that in a few years time it'll be possible to generate a wide range of music at the touch of a button, and it'll be convincing.

This is clearly pastiche, but I think that's the first step towards convincing compositions and then onwards to being original and interesting. I know there have been software methods to compose (and symphonies written by such), but I think the current AI/machine learning trend will allow the technology to move far faster than teaching it explicitly all the music and composition theory that you can.

</comment><comment><USER6> I can say without question that this AI has done waaaaaayyyy to much LSD...

But given that, it is still surprisingly coherent, melodic and generally enjoyable!

<comment><USER4> Yeah, it's coherent because the lyrics were written by a human.

</comment></comment><comment><USER7> This sounds a lot more to me like a Beach Boys style song, rather than something the Beatles would have written.

<comment><USER8> It does sound like late Beatles to me, e.g. "Glass Onion", "I'm the Walrus". But it has a bit of a paint-by-numbers quality to it. More of a "rare songs the artist wisely did not release" than "greatest hits" feel.</comment></comment>


Do startups hire from overseas for their, say, first 5 hires? - <AUTHOR> Are startups open to this or is the visa troubles not worth the upside of finding a good match?<p>For context: I am from India, and have co-founded 2 companies and worked in one as employee#1. <comment><USER2> Unanswerable.

Sure, some might.

Most will look for local hires, for a variety of reasons (can't afford relo etc.) or hire remote (which has its own set of problems, but I suspect you know that).

</comment><comment><USER3> I imagine it would depend on if differential in skills, expertise out weigh hassles of visa's etc.</comment>


Ask HN: Do you have dead domains for sale? - <AUTHOR>

I am curious if there is a need for this;  I personally have 20 or so domains I have purchased for random things over the years, but I probably will never use them.   Selling them is a pain generally, and I know none of them are worth too much.  Would there be demand for a site:
1. setup a landing page listing your domains 2. verify all the domains with a text record 3. point all your domains to the landing page 4. someone can purchase the domain
Would you pay 7.99/mo for this service?  Would you pay nothing, and allow adwords? <comment><USER2> Not at all for a monthly fee.

Sedo has the equivalent service, point your DNS at them and they serve a "This domain is for sale" landing page with ads, and they get a commission on the sale if it happens.

</comment><comment><USER3> Someone else had a similar idea - <http://www.nametagup.com/> \- <https://news.ycombinator.com/item?id=5238130>

I like the concept but it has to be easy for the user and rather than a monthly fee - focus on a 1 or 5% commission on sales. This way you capture people uploading 100+ domains and trying to get a sale.

Another concept in this space that I like is <http://stylate.com/> who finds domains -creates logos and then offers them up for $250 flat. So rather than waste time with name generate - u can do that for $250 and always find something better later.

<comment><USER3> Thinking more about this - why not create just that.

Add Domains - Signup (email/pass) Create landing page with simple text Use gumroad or stripe to setup initial payment.

Or better yet - create a few example pages (with your current domains) and see if anyone clicks, then just say - sorry it's manual now and ask for email.

Look how buffer did it - [http://blog.bufferapp.com/idea-to-paying-customers- in-7-week...](http://blog.bufferapp.com/idea-to-paying-customers-in-7-weeks- how-we-did-it)

</comment></comment><comment><USER4> I would be unlikely to pay $8 per month, but I would pay commission for selling it or sharing advertising revenue. Using a TXT record to indicate a domain is for sale seems interesting too.

(edit: yes, I do have a handful of "unused" side-project domains)

</comment><comment><USER5> $7.99/mo + cost to purchase a domain with minimum (if any) value? Why not just take X% off of each domain sale?

<comment><AUTHOR> You already own the domain (ie it was for an old side project you never proceeded with), the 7.99 would be to host the landing page, facilitate the payment, and help getting eyeballs on your list of domains.

<comment><USER5> Ok, I misunderstood the fee. I assumed that it was to have the ability to purchase domains. That makes more sense, and that model I like a lot more. I don't think I'd pay $7.99/mo for it though. At that rate I'd have to be kicking off a handful of dead domains a month to not lose money (time spent plus the fee), and therefore would rather just leave them be.

<comment><AUTHOR> It wouldn't be per site fwiw, you could list an unlimited amount of domains for 7.99$/mo; consensus seems to be that a percentage is the better way to go though.</comment></comment></comment></comment>


Frederick Douglass' 200th Birthday: Great American Abolitionist - <AUTHOR> https://www.smithsonianmag.com/smithsonian-institution/frederick-douglass-200th-birthday-invites-remembrance-and-reflection-180968100/?no-ist <comment><USER2> I hear he's doing great things</comment>


What if Microsoft had invented Android? - <AUTHOR> https://www.zdnet.com/article/what-if-microsoft-had-invented-android/ <comment><USER2> They probably wouldn't have won the lawsuits with Oracle, but maybe they could have used .NET and not have to rip off Java.

<comment><USER3> "rip off Java" \- you do know where C# came from, right? Microsoft mated Java with something during the dark of the moon, and C# was the unholy offspring. Seriously, C# was a near close of Java, because Sun sued Microsoft over compatibility: [https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...](https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish) . - See the Examples section.</comment></comment>


Show HN: Presentable for Mac - create presentations from websites (free app) - <AUTHOR> https://itunes.apple.com/us/app/presentable/id636279585

<comment><AUTHOR> Presentable is a side project of mine on which I've spent way too much time. Now that it's done, I find that I'm unable to spend any more time on figuring out how I might actually make some money from it... So I decided to release it for free.

This app scratches a personal itch. When giving presentations, there's often stuff on the web that I'd like to show, but integrating it into a traditional Keynote or PowerPoint slide show is too difficult.

Presentable includes a complete web browser that supports full frame rate video (including Flash). You can scroll and click within the webpage, and there are Crop and Highlight tools for emphasizing elements and removing distracting elements like YouTube comments.

There's also a dual-screen mode, so you have access to your notes and webpage controls while the projector screen shows the pristine web site with no extra browser chrome.

The app also includes Leap Motion gesture controls. It's available for download on the Leap Motion Airspace store as well: [https://airspace.leapmotion.com/apps/presentable/osx](https://airspace.leapmotion.com/apps/presentable/osx)

Maybe you have an idea for how to turn this technology into something profitable? Because I can't keep working on it, I decided to sell it on SideProjectors.com -- check it out:

[https://www.sideprojectors.com/project/project/360/presentab...](https://www.sideprojectors.com/project/project/360/presentable)

</comment><comment><USER2> This reminded me of an app I'd seen a few years ago, with an ice-cream sundae as its logo. Eventually I remembered it was Plainview ([http://barbariangroup.com/2012/07/plainview/](http://barbariangroup.com/2012/07/plainview/)).

Being able to import slides, as well as showing web-pages, is a nice improvement.</comment>


Apple Watch vs. Android Wear: Why all other smartwatches suck for women - <AUTHOR> https://m.imore.com/apple-gets-it-right-why-android-wear-sucks-for-women <comment><USER2> One more reason to be sad about the demise of Pebble :'(

</comment><comment><USER3> This feels like an apple PR piece.

<comment><USER4> Given the URL, I'd expect some bias. It seems to be more about fashion than about function. I have small wrists but like a larger watch face.</comment></comment>