The MicroPHP Manifesto - <AUTHOR> http://funkatron.com/posts/the-microphp-manifesto.html <comment><USER4> Real-world applications are complicated. There are three ways to handle this problem.

The first is to not handle the problem. Implement something "simple" that doesn't work in uncommon cases. This seems nice because there isn't much code and there isn't much complexity. But that's because your program doesn't actually work, which is usually considered a bad thing. (This program right here -> "" <\- is the easiest way to solve problem X. It only fails in 100% of the cases, that's all.)

The second way is to "refuse complicated frameworks" and write an application with a framework inside. This is what most people do, but believe that they aren't using a framework because they didn't download one. But, the same problems come up again and again: rendering data, handling AJAX requests, building database queries, managing users and passwords, the list goes on forever. When you do a half-assed job of handling this stuff right in your application code, you're using a framework. It's just a bad one. You had to write it from scratch, it's not well-tested, and you can't reuse it.

A third option is to use well-written libraries (or frameworks) to manage the implementation complexity, leaving your application as a concise shell around the core components. This means your application code only describes the problem that your application is trying to solve. The dirty work of dealing with the real world (HTML, JSON, SQL, etc.), is all handled in other code. (You can write this yourself, of course; you just have to understand that JSON parsing is not what your application _does_ , and when you want to write that code, you need to "switch gears" and implement it outside of your application du jour. And sometimes, "you" is not you, it's someone else on the Internet.)

This article suggests that you eschew option three in favor of option one or two, because the code is "less beautiful". I say that, beautiful or not, these two options are the best way to write unmaintainable code that doesn't ever work.

The third strategy may feel unclean because you did not get to fully control every aspect of the interface and implementation. But most of the time, that doesn't matter. Yes, you'll have to do some configuration. Configuration is easier to test and maintain than the logic that you're configuring, and that means your application is actually simpler. The world is complicated. Your software doesn't have to make it more complicated.

<comment><USER5> "I say that, beautiful or not, these two options are the best way to write unmaintainable code that doesn't ever work."

I agree that for big jobs, you can't prioritize pretty over featureful, but, respectfully, I think you are overstating your point here: "doesn't ever work." That's simply not true. Have you really never written a working program without a full featured framework?

I think one of the points that isn't clearly enough articulated in this article, but is very significant for me, is code understandability. Probably my biggest issue with CakePHP (what I use) is that when you step outside the standard use cases you fall down a rabbit hole of complexity and peculiar idioms. The result here is that one becomes a "Cake developer" rather than a "PHP developer"; there is a high degree of lock-in and switching the entire toolset becomes difficult and impractical. So the idea being suggested is allow people to switch out tools one by one rather than start over with a new, incompatible set if they need some lower level change.

What I see in this post that I agree with is the idea that PHP tools should be more modular and decoupled, so you can grab a full stack bundle if you want, but can use modules piecemeal if you don't. Currently, the latter option is lacking in PHP. I don't think anyone's saying "down with frameworks" as much as "hey, let's get some do-one-thing-well tools _as well_ , so the piecemeal/modular option is also there."

<comment><USER6> >Probably my biggest issue with CakePHP (what I use) is that when you step outside the standard use cases you fall down a rabbit hole of complexity and peculiar idioms. The result here is that one becomes a "Cake developer" rather than a "PHP developer"; there is a high degree of lock-in and switching the entire toolset becomes difficult and impractical.

Totally agree. But that's because of poor design in CakePHP (I used it too).

>What I see in this post that I agree with is the idea that PHP tools should be more modular and decoupled, so you can grab a full stack bundle if you want, but can use modules piecemeal if you don't. Currently, the latter option is lacking in PHP.

Actually, it's not. Take a look at Zend Framework and you'll see that you have a TON of modules for doing all kind of stuff and if you want you could use just the core ones and ignore the rest. It works so well that I even use components in non-Zend Framework projects.

<comment><USER7> Please explain reasoning behind CakePHP having a poor design. I'm curious as most people that say a framework or tool sucks actually are just using the framework/tool in an incorrect way, and there is frequently an elegant way to tackle their issues. This applies to more than just CakePHP, mind you.

<comment><USER8> Sure, but you don't always have the time to figure out what that elegant way is. This is the reason people complain about the complexity of frameworks.

</comment></comment></comment></comment></comment><comment><USER9> This post bothers me a lot, because it misrepresents a very large movement in American music while at the same time decrying the value of community- developed frameworks. Black Flag is a great band, but their "fast and simple" approach to playing music ran into a lot of the same problems that tech startups find when they, too, decide to take a "fast and simple" approach to web development -- those being high employee turnover, extremely low profitability, and a lot of in-fighting.

Black Flag made a lot of junk because they couldn't get the band to cooperate. They had to keep re-doing the same songs over and over because their lead singer kept changing. Talk about a good analogy for unnecessary rewrites! At one point, when the artistic direction and ego situation became especially dire, one side of an album was all spoken word, and the other side was all instrumental. In the end, they just ended up becoming another "metal" band with albums like "Slip it In" towards the end of their discography. Black Flag is a great band, but this post completely misrepresents what they did and what it means, if _anything_ for software development. If it's the story of anything, it's the story of an entrepreneur who kept paying for all the corners he cut.

Rush wanted to write complex albums that dealt with a lot of layered meaning. There was a lot more planning and attention paid to what got laid onto their tracks. In exchange for their hard work, attention to detail, and planning, they were well compensated. They played arenas and sold a ton of albums. Black Flag played VFW halls, and I'll be damned if most of their fans these days didn't just torrent their discography and be done with it. What would you want for your business? There will be no hipsters to fondly nostalgize your unsuccessful web application.

<comment><USER10> Great points. I would also contrast the Black Flag with Ian MacKaye's body of work: start off with fast and simple (Minor Threat), but move on when it becomes trite (Embrace, then Fugazi). Fugazi created some of the most interesting, complex music I've ever heard, but it was borne out of that initial minimalism.

<comment><USER9> Fugazi is also a good point because their goal as an organization is sustainability. This is exhibited in their $5-or-bust ticket price, among other things. Black Flag's goal, particularly during the Decline of Western Civilization years, was mostly to get drunk and fight cops. Just a bad analogy in general for software intended to make money.

</comment></comment></comment><comment><USER11> "The MicroPHP Manifesto" is actually "The Lone Programmer Manifesto".

Programming in today's world means working with other people's code. All a framework does is provide a set of design patterns and standards that a group of programmers can adhere to. This encourages code reuse and allows you as a programmer to create "black boxes" - components with a well defined programming interfaces that behave in a consistent & predictable manner.

Real-world example: I'm currently working with a custom-built CMS programmed in PHP. I'm the second man on a what began as a one-man project. The CMS author wrote a bunch of database functions (essentially wrappers for the deprecated mysql_* functions) and dumped them into a file. Now, the author wasn't aware that you can (and should) lazy-load database connections - <USER2> every time you need to talk to the database, you have to manually connected using `cms_db_connect()` AND select the database with `cms_db_select(CONST_DATABASE_NAME)`. As pretty much every page initiates a database connection this code is EVERYWHERE.

And this is only the tip of the iceberg. There's also a half-assed MVC implementation, ubiquitous usage of inline CSS, un-encapsulated code, and a butt-load of quirky behavior. Now if the original author had take a little bit of time at the beginning and researched a proper framework or used an existing CMS our project would not be behind schedule - and it would be far easier to add another developer into the mix. All this meaningless complexity because the original author took the "simple" route of not working with a framework authored by third parties.

<comment><USER12> This is a similar drawback I see to microframeworks. You end up having to either roll the bits you didn't get from the framework or build a more complete framework out of other components. This can create dependency hell if you're not careful/make the wrong choices as well.

Choosing simple tools for complex jobs can get you in just as bad of a place as choosing complex tools for simple jobs.

</comment></comment><comment><USER5> I am glad this is being discussed. Due at least in part to the to the fact PHP is constantly trashed (rightly or wrongly) in the "hip programmer" community, there is a lot of defensiveness in the PHP community. I understand why: one can only take so much trash talking especially when much of it is overblown or inaccurate, but it's caused many people to become so touchy that even valid, constructive criticism from community members is responded to with unnecessary vitriol.

I am glad Ed/Funkatron is forging ahead and voicing these concerns and suggestions nonetheless. As a PHP dev, I look over the fence at python & ruby examples and wonder why my application/framework is so complex and ugly (obv. examples and production applications are apples and oranges, but the contrast is stark). I hear "PHP is supposed to be ugly." Seriously? This is a selling point?

It's good to hear others call attention to these issues and suggest a path forward that keeps PHP competitive with other languages on the web.

<comment><USER13> Check out Symfony2. The developers adopt some of the best elements of RoR (gems/bundles) and Python (templates) among other things.

<comment><USER14>
        some of the best elements of RoR (gems/bundles)

I program in Ruby a lot, have done for a long time, and love it, but I've also lost weeks (months?) of my life to fighting gem interdependency problems and watching 'bundle install'. It's almost certainly my least favourite part of the job.

That's not to denigrate the efforts that go into RubyGems, Bundler, etc. - they're doing a good job, and they make life much easier than it would be without them, but in some ways they're playing with a lousy hand for historical reasons that are too late to change now.

I'm largely ignorant of Symfony2, but I hope it's learning from the flaws of the RubyGems ecosystem as well as its strengths.

<comment><USER15> We're considering a switch to RoR (from CakePHP oddly enough) at my job, but this gem dependency nightmare gives me pause. I ran across rvm in my research, and it's supposed to solve these concerns. I'm wondering if you have used rvm and whether or not rvm solves the problems you've run into in the past.

Thanks!

<comment><USER14> In short, no. I've used it, but I think that the problems that RVM solves are largely orthogonal to those.

I don't use (or need) RVM on servers, and I don't use it on a daily basis, but I find it useful for testing gems across multiple interpreters before I release them.

</comment></comment></comment></comment></comment><comment><USER16> To me the biggest advantage of frameworks is documentation. When you bring on a new developer who has never worked with, say, CakePHP, you can point them to the docs to answer most questions.

When you roll your own, you have to either document it yourself (ha!) or become the point man on all questions about how things work.

My last company underwent a painful conversion from roll-your-own to Zend Framework. It slowed us down in the short term, but there was a huge payoff in developer productivity in the long term.

<comment><USER17> Ha! Couldn't agree more with you!

At my current job we're working with our own framework. I think it has two main downsides for my employers: 1) Employees are difficult to replace - <USER3> invested a lot of time in me, to teach me their stack. 2) New employees are difficult to introduce - fresh developers keep asking questions, disrupting the workflow.

For me it's a mixed situation. In short term I know I'm safe - why should they sack me? But in the long run I'll end up with untransferable skillset.

</comment></comment><comment><USER18> Yeah, well, I can sympathize with the sentiment, but here's the problem:

> I want less code, not more

If been coding web apps since the mid-90's, and I've pretty much had it with either re-inventing the wheel or scouring the internet for bits and pieces of libraries. Big fat frameworks allow me to focus on the code I need to do something new.

I have no time to fuck about trying to compensate for all the bits and pieces those lightweight frameworks conveniently left out in order to be lightweight. The end result is inevitably just _more code_ to maintain instead of less.

I get my punk rock kicks from writing shell scripts and the odd quick & dirty hacks, not complex web applications.

</comment><comment><USER6> I think OP is entirely missing the point of these frameworks. Zend Framework is probably the most enterprise-y PHP framework out there (vast amount of OOP patterns used, things copied from Java, heavy using of interfaces, etc) and if you don't like writing that kind of applications you shouldn't use it.

It seems to me that what he is trying to do is something like setting up a simple contact form using Java, Spring and Hibernate, and by this I don't mean that he codes silly stuff at all, but that if he feels this way he's just picking the wrong tools for the job.

I don't know anything about music but I also think that the analogy he used is wrong. Black Flag may do great music with much less equipment, but I doubt that with that drum kit the drummer would be able to do the same sounds or have the same precision as the drummer with the huge kit would.

Does OP know why Neil Peart needs all that stuff? I assume Neil wouldn't be able to play the same things in a minimalistic set up.

If you don't know what all the framework's "boilerplate" is for and you just want to get your application running, why are you using a framework in the first place? A framework is supposed to do stuff for you that you would have to otherwise do manually. If you don't normally do the stuff the framework does for you, don't use it.

There are plenty of quotes in there that I strongly disagree with (the commitment stuff mostly), but I think I can sum it up with saying that just because you can do great things with less it doesn't mean that having more is bad. Just learn to pick the right tool for the job.

edit: jrockway is spot on regarding code quality.

<comment><USER12> If you've ever seen Rush live, Neil Peart actually plays every piece of kit he has. Its all basically necessary based on the music rush plays.

</comment></comment><comment><USER19> My resolution regarding php this year: no new php projects. I will continue to support existing projects/clients but from here forward I am done. I have studied other languages extensively and even worked on relatively interesting personal projects in them (racket/node js etc.) but now is the time to draw the line and start using them for new projects. My last argument for using php in which hosting is easier/cheaper w/ php is moot now. So I am left with the realization that I keep reaching for it like a kid who still watches pokemon instead of doing his chemistry homework.

</comment><comment><USER20> I think this is a great and thought-provoking post.

The movement toward smaller, decoupled and interoperable libraries in the PHP community is in general a good thing.

But without a widely adopted PHP package-management system using many micro libraries becomes more complex to manage than a big all-in-one framework. We need something like NPM for PHP. Maybe PEAR 2 can get us there.

<comment><USER21> You mean like composer <http://packagist.org/>?

<comment><USER20> Yes - like this! Now all it needs is the widely adopted part...

<comment><USER21> That's the part where everybody can contribute. Have an open source library you like, fork and add the composer part.

Indeed it will not always be that easy, because the project has to be structured in a way that the autoloader could work with.

Maybe even merely giving the heads up to library developers would be enough to get them to accept it; worth a shot, right?

</comment></comment></comment></comment><comment><USER22> Great post. I'd like to call attention to one point he makes:

"It doesn't mean that stuff is bad, in the grand scheme of things. It doesn't mean it has no value or is the wrong approach for many. But it's the wrong approach for me, for sure."

Let's face it, the differences among Zend Framework vs Symfony vs Limonade vs Rails vs Django aren't really that big of a deal for most of our projects. In fact, I don't know if I've ever worked on a project that any of those frameworks couldn't solve effectively. The fact is that for the simple database web apps that most of us are writing, these decisions are not very critical.

It seems to me that Ed recognizes something that no one talks about as much as they should. The important consideration is not "Which tool is right for the project?". Most of the time "Which tool is right for the developer?" is the question that the success of a project hangs on.

Ed and his coworkers at <http://gimmebar.com> recognize this. They have adopted Javascript as the lingua franca that allows their frontend and backend developers to work together harmoniously. Developers working in harmony can achieve great things. The 5 Days of Gimmebar are proof enough of that ([http://blog.gimmebar.com/post/12793742161/5-days-of-gimme- ba...](http://blog.gimmebar.com/post/12793742161/5-days-of-gimme-bar-day- one)).

Ed says that a simple framework with useful single-purpose third-party components is the right choice for him. Maybe it is for you too, maybe it isn't. I think the important takeaway from this post is that we should all strive for the self awareness that allows us to recognize what will let us work most effectively. I know I've been giving that question a lot of thought lately myself.

</comment><comment><USER23> For most projects, if you're using PHP, you probably can't eliminate your dependencies. If you really can afford on a project to go super clean and not need a bunch of other libraries, then maybe this is a really good time to be using something other than PHP. I'm honestly not bagging on PHP here. I really do think it has its place, and I was a PHP developer for many years myself. But just as there's a place and a time for PHP, there is a place and a time for other languages, too. When you have no dependencies on legacy PHP libraries, and the opportunity to go lean and clean and do what you want-- that's the project to not use PHP.

</comment><comment><USER24> The advancement of logical thought and rational development strategies in PHP has been slowed greatly by this intense shame we all feel to be using such an uncool tool. This article was indeed a breath of fresh air, as others have said. Keep it up.

</comment><comment><USER25> in all, as a fan of both php and small tools (the rarest of a rare breed), i agree with the author. but if i may play with the analogy...

i'd actually say the Rush vs Black Flag analogy does not do Neil Peart or micro concepts justice. ideally, small tools can be used together, much like a drum kit. each of Neil's drums performs a very specific function, and he uses them as he sees fit. if he only played one song a night, his kit would look very different. extending the analogy, if you give Neil Peart a 5 piece, he can still make great music.

<comment><USER26> That's an interesting look at things. I look at it from something Stephen King wrote in On Writing. Basically, the story was about his father/uncle/grand father who, when he needed to fix something, would bring out his entire tool box, with all his tools, despite only needing a hammer. Stephen would ask him why he didn't _just_ bring the hammer, and his reply was: "Because, I didn't know what else I might need one I got out here." Basically, the story tells us to bring our toolbox with us.

When you look at a large framework like Zend, it's a lot to swallow. There are a lot of parts, and just like the tools in a tool box, each plays a different part. You might _just_ need a hammer today, but tomorrow, you might need a screw driver, and then a saw, and then a sander.

So, I appreciate larger frameworks. Sure, SOAP or XML-RPC might not be fun, but when that's the way you connect to the bank, it being apart of the framework makes it so much easier.

Anyways, the point was I saw your post, and it reminded me of Stephen's story.

</comment></comment><comment><USER27> Amen! I've been railing against this as well for some time (with a minimalist project of my own - elefantcms.com), and wow is there ever resistance in certain parts of the PHP community to ideas like this.

Reading "quick" start tutorials like this ([http://packages.zendframework.com/docs/latest/manual/en/zend...](http://packages.zendframework.com/docs/latest/manual/en/zend.mvc.quick- start.html)) is just depressing, and it's a big reason why droves of developer continue the exodus to other languages. PHP libs and frameworks should not emulate Java.

Sometimes I think PHP needs a _why to add some whimsy to the community and encourage people to break the mould, but they'd probably be dismissed as someone who "doesn't understand design patterns" or some other BS...

Thank you for writing this.

<comment><USER28> PHP itself tries to emulate Java. Should have stopped at PHP4.

<comment><USER27> And badly at that.

</comment></comment></comment><comment><USER29> I've played only a four piece since 1990 or so and it will never run out of possibilities for me. A larger kit means things need to be farther away from you, and if things are too far away there's no point in having them, so in any studio I take that second tom off the rack and move the ride cymbal right in, and it feels great.

In that way I guess a four piece kit reminds me of lisp - just some parenthesis and a few other things, but endless possibilities nonetheless. But I've never used lisp for anything really and in software I always like to shoot for a happy medium of scale and pragmatism. Also Neal Peart's setup is part of the entertainment value. EJB or some overgrown PHP thing, on the other hand, not very entertaining.

</comment><comment><USER30> Agreed...this is a breath of fresh air that, imho, the community needs right now. Clear, concise, well-written code can do wonders for a project...don't jump to a framework just because it's the trend.

<comment><USER31> The assumption that "use a framework" and "clear, concise, well-written code" are incompatible is the problem.

His "punk movement" is more of a "I don't want to use things I have to learn" complaint. I defy any PHP developer to assert that the majority of development is made _faster_ by spending your days bolting together that which already exists.

</comment></comment><comment><USER32> I'm a hundred percent with the author on this—most PHP frameworks and libraries are a ridiculous mess. My requirement for using third-party libraries are that they do a single thing, that they do it well, and that they have little or no dependencies. There's no good reason why most third-party code can't be a single class / file.

Our third-party library stack for the (very complex) chartboost.com architecture is made up of simple, modular parts: Paraglide as micro-MVC (one class, and a handful of folder for the base structure), MongoModel (one class, as MongoDB ORM), etc. Most of our third-party libraries are very simple and manageable, the way all PHP should be.

As for code verbosity: everything is auto-loaded on the fly when needed. Our code has practically no `require` statements. We just follow a simple conventions of where to place files and how to name classes, and everything works smoothly and painlessly.

Most importantly in this setup, none of the libraries depend on the framework of choice or on anything architectural. The framework doesn't even require being run in a web environment. This lets us do powerful and flexible things like use Facebook's `phpsh` library to open up a shell that will have our entire environment available and loaded on the fly. We can also switch between dev, production or local environments on the fly.

</comment><comment><USER33> While some of this is spot on, there's seems to be two threads to this that make less sense to me.

First, "building small things" isn't what many of us do from day to day. I don't think many of us sit down and try to create bloated, overly complex systems, but oversimplification isn't helpful either. If you're wild-westing it or reinventing wheels for your next web project, I can't help but think you've only got serious pain in your (near) future.

I think there's an important difference between complex and complicated. I wonder if you asked Neil about his set if he'd describe it more as an organized toolset that's evolved over time or a sprawling mess of a ball-and- chain he's involuntarily tied to.

I'm no fan of the verbose, Java-like implementations (ZF and SF, I'm looking at you) you've highlighted, but there are more options out there.

Secondly, I take issue with the abrasive tenor a lot of these posts seem to take. All critique and no solutions, especially no code to show for great ideas. While a good F@$* that S@#% helps everyone see the problem, the lack of action or offering of concrete ideas for improvement leaves me with the feeling that it's just complaining.

I wish more of the leadership in this community was contributing in an open- source, here's-the-code sort of way. At least contributing as much as they critique.

</comment><comment><USER34> Why all the Rush hate? Cutesy metaphor, but c'mon!

<comment><USER35> Where's the hate? He's simply saying, if I can try to extend this analogy a little further, that if you want to get out there and start a band, it's a lot easier doing it as a punk band than as a Rush cover band, if only because you only need a single van for all of your instruments, instead of one bus per band member.

</comment></comment><comment><USER36> This is an excellent post. Ed has been able to put into words what I've been feeling for a while now.

=C=

</comment><comment><USER37> This is the nature of languages, particularly scripting languages. Fundamentally, the creators of PHP are not representative of the mainstream users of PHP. That's a problem.

Just look at perl6.

Use the parts of PHP that matter most to you.

</comment><comment><USER38> Micro-frameworks are awesome when you're doing that one quick pet-project you always wanted to try. Else you'll just fall into the loop of "okay, now I need to find and install/write from scratch this part that is present as core in x framework"

</comment><comment><USER39> I don't agree with the OP about frameworks at all. The code example shows about 10 lines of code that are "just to get the app started" but what it doesn't show is all of the places where there will be much, much less code.

Frameworks do require a bit of initialization code, but the whole point is that once initialized they save you tons of writing. They take care of boring stuff like authentication, basic code organization, certain security issues, etc.

There's nothing wrong with deciding not to use any frameworks, but to do so because it seems "cleaner" or "simpler" I think it misguided.

</comment><comment><USER40> What I needed in a framework was exactly what the author mentioned, something simple to start but could scale to complexity when needed. I tried a lot of other full stack frameworks and just couldn't get them to do really simple things without extensive customization. They were all very rigid in "how" you do things.

This is the reason I ended up writing my own micro-framework, Flight (<http://flightphp.com/>). The goal is to be as flexible and extensible as possible, while providing a tiny footprint.

</comment><comment><USER41> Overcomplicated code is simply poor programming. Not something that requires a clever name or manifesto. I would go as far to say you overcomplicated things by posting such a long drawn-out post about something that could be said in far less words... or maybe even a little satirical code:

Poor_programmer = 'Overcomplicated code'; If (You == programmer) { stop(); }

EDIT: I change die() to stop() because die felt a little too dramatic, even if thats the correct function in php. =)

</comment><comment><USER42> Using the right tool for the job comes to mind here, but half the time you can only see this with hindsight. And the other half the time, I'd guess, PHP is the only tool available. Unless cheap webhosts offer Python, Ruby and Node.js integration to complement the usual feature-set.

If you have more tools in the box, then you can start to consider whether to go full-stack with PHP (I'd no longer consider this route a viable option), or whether to modularise your project. Maybe for a lot of things that's too much and a PHP framework that does it all is totally fine. No point doing something just because you can, but you have the flexibility to think outside of the box when refactoring.

This is exactly what I did when it came to generating an image and manipulating the output. In PHP it was convoluted, buggy, impossible to understand the library it depended upon, and offered no flexibility. It took months of procrastination and avoidance before we had to get the feature working, so I ditched the lot and re-did it in Python, using Cyclone and a couple of lightweight libs. It took a day and a half to implement, with no knowledge beforehand, and it does absolutely everything we wanted (without any hacks).

It was at that point I realised that it was much more beneficial to look beyond the one-size-fits-all solution of a massive framework, which may be appropriate to some, but just as often isn't. And as has been said - very well indeed I must add - I don't want to be a [framework]-developer who knows not so much the language, but an individual or group's abstraction of it; I want to be a developer who knows what to do when that framework doesn't fit.

</comment><comment><USER43> I find it rather amusing that a manifesto that advertises simplicity starts by wandering off to unrelated topics, instead of getting straight to the point.

</comment><comment><USER44> Check out Nette Framework used as a micro framework for routing, templating (e.g. spliting layout and page template) and debugging/logging on microsite <http://davidgrudl.com>. See the source codes - just drag upper left corner ;)

</comment><comment><USER45> I agree with OP, although I think the code example is misleading (but still awful).

Why? Configuration/Bootstrapping is needed, with simple, small and loosely coupled components even more, because you don't want to tie a some configuration monster to it. But it would indeed turn out to be a simpler configuration, usually a nice little array with few keys bootstraps any simple component nicely. On framework level it can be more DRY. Downside, every "framework" solves bootstrapping and configuration on it's own. Which would me make always feel bad about running multiple frameworks side by side.

For components (objects) configuration we could solve a lot of problems if the php community could agree about an plain array configuration protocol to set them up. At least it would be interesting if it's doable.

</comment><comment><USER46> Brilliant! Applies equally to JavaScript, CSS and .NET frameworks, etc.

Most mega-frameworks pat themselves on the back with examples that declare "See, you can write an entire CMS in 10 lines of code!" That's impressive except you can't write anything else and extending the CMS requires that you read and understand 100 pages of framework API entangled with assumptions and design tradeoffs that expertly fit the author's needs and not necessarily yours.

The problem is that the ideal framework requires zero lines of code because it already solves your exact problem. The worse framework requires more lines of code than coding your application from scratch. So, the key is finding a framework that satisfies 80% of your needs easily and doesn't get in your way for solving the other 20%.

</comment><comment><USER47> Laravel is a new PHP framework which focus on clean and expressive syntax, worth a try. (<http://laravel.com>)

<comment><USER48> When I looked for a PHP framework for a demo I needed to put together quickly, I found Fat-Free Framework (<http://fatfree.sourceforge.net/>) did everything I needed without the bloat and complexity.

</comment></comment><comment><USER49> Have you tried CodeIgniter? I've been using it for a while, it's pretty lightweight in comparison with Zend, it's also much faster in speed.

<comment><USER50> I have been using CI for larger projects and I love it. CakePHP for me has too much that I don't need.

</comment></comment><comment><USER51> Thanks Ed, love the manifesto and, more importantly, adopting it. Paul

</comment><comment><USER52> > I like to make things that solve problems

Then you're probably using the wrong language. :-)</comment>


How Trump and Bannon Could Automate Populism - <AUTHOR> http://globalguerrillas.typepad.com/globalguerrillas/2017/03/bannons-secret-weapon.html <comment><USER2> This is the kind of thing that would require a basic understanding of technology that this administration lacks.</comment>


PlayStation 3 Owner Files Class Action Suit Against Sony For Dropping 'Other OS' - <AUTHOR> http://kotaku.com/5526847/playstation-3-owner-files-class-action-suit-against-sony-for-dropping-other-os

<comment><USER2> Sometimes I can't imagine who's worse the Apple fanboys who justify everything Apple does or the Sony fanboys who believe people don't have a right to their own hardware. It's one thing to believe the lawsuit is frivolous, it's quite another to say "It's Sony's; like people didn't drop $600 on this thing and expect it to work as good as the day they bought it.

<comment><USER3> This raises all sorts of interesting questions about the implications of software updates on hardware platforms that are governed by consumer protection laws. And none of them I want called into question, since I dropped $600 (and then a $160 repair two years later, after the GPU burned out) on this stupid shiny Foreman grill, and am tired of Sony dicking around with it. I would like them to buy it back from me.

And it's not even a frivolous suit. It says right on the fucking box that I could install another OS on it. And now I can't. What the fuck? If I don't update, then my multiplayer games stop working, I can't watch Blu-Rays that access the internet, and I can't play new game releases or patch existing ones. That's not even borderline wrong, it's clearly wrong, and probably illegal (though I'm not a lawyer.) Otherwise, companies could advertise whatever features they wanted for some product, and then claim they were "disabled in a software update" later on when they don't have those features.

Which is what Sony did. Fuck you, Sony.

<comment><USER4> If you want to keep the features you could just stay with your current firmware. It is optional to upgrade, not a forced decision. Also it begs the question of why you want to keep the functionality. If you were going to use it for the cell computing power or just messing around you could always use the old firmware and upgrade when you want to use the playstation network functionality. If you want to keep both features there is a good chance the reason why you would want to do so is to pirate games. Could someone explain to me why there is any legitimacy in this suit?

<comment><USER5> No, it is not optional to upgrade — at least not in the usual sense of the word. If you upgrade, you lose the ability to run Linux. If you don't upgrade, you lose the ability to play games. That's more like an ultimatum than a traditional optional install.

<comment><USER6> You can still play games... Just not online, which is a free service anyways.

<comment><USER7> Several PSN games will not work without the PSN, even while playing single- player.

EDIT: Also new games will not work without upgrading.

</comment></comment></comment></comment></comment></comment><comment><USER8> I hope the lawsuit succeeds and Sony learns a lesson.

The justification for removal of the functionality is absolutely ludicrous. It's wrong on so many levels I don't know where to start...

<comment><USER9> _edit_

I thought that Sony never stated this was standard functionality. But it seems I was very wrong:

<http://www.playstation.com/ps3-openplatform/index.html>

So I must agree this is not fair...

<comment><AUTHOR> But choosing forces you to lose something that you may have originally bought the console because of. Don't upgrade and you can't play any new games. Do upgrade and you lose Linux. Not really fair is it?

<comment><USER3> Actually, you can't play many existing games now, either -- some rely on a PSN connection, which you can't make without an updated console. So the claim that the removal of the feature is optional is a lie; either way, features which have been used to advertise the console have been removed.

</comment></comment></comment></comment><comment><USER10> I am a little upset about this whole thing, on one hand I am very happy with my ps3 I bought it when it was cheaper than a blu ray player and the ability to play pretty games was a nice bonus. On the other hand even though I never used the Other OS functionality the fact that Sony removed it with the only option of keeping it being a limited and potentially broken system (when you take into account not being able to play new blu ray discs) makes me a bit angry.

Removing functionality seems so counterintuitive even if you want to stop your system from being exploited, but to be honest I upgraded as I was never going to use Other OS.

</comment><comment><USER11> What exactly is the legal basis for this?

The suit should be brought on behalf of all people that bought a PS3 between 2006 and 2010, BECAUSE they expected it to be able to run another OS.

</comment><comment><USER12> car analogy: you buy a car advertised with a spacious trunk. Then 2 years after the you get the car they announce a recall to replaca a faulty air bag. And when they return the car the trunk is welded shut.

<comment><USER6> The OtherOS is not nearly as useful to PS3 owners as a trunk is to a car owner.

<comment><USER7> People who express strong opinions about things they don't understand aren't useful to anyone.

OtherOS has many uses. Even excluding ps3 clusters for scientific research, several ps3 developers I know use their ps3s at home to try out code quickly. The linux environment is more convenient at times than even the official dev kit.

<comment><USER6> What percentage of users do you suppose that is?

PS3s used for scientific research don't have to upgrade, unless they're also secretly using them to play new games.</comment></comment></comment></comment>


At Last, a Zoomable World - <AUTHOR> http://www.loosewireblog.com/2007/06/at_last_a_zooma.html <comment><USER2> Posted in the wrong place...</comment>


Leaked RIAA Report: SOPA/PIPA "Ineffective Tool" Against Music Piracy - <AUTHOR> http://torrentfreak.com/leaked-riaa-report-sopapipa-ineffective-tool-against-music-piracy-120727/ <comment><USER2> Basically, instead of implementing a carrot for not pirating music, the RIAA wants a bigger stick.

It would be far easier for them to just implement a carrot. Make it fucking easy for me to pay for music that I can enjoy whenever I want to, on whatever device I like.

<comment><USER3> What's the problem with iTunes, or Amazon MP3? Instant downloads, DRM-free, reasonably high bitrate, standard formats. Seems to meet your requirements.

<comment><USER4> And, it's worth noting, it has largely worked. Used to be that just about everyone I knew pirated music. Now, in my circle of acquaintances, its only a couple techno-anarchists and some kids who couldn't afford it otherwise. I doubt they hurt the RIAA's bottom line much.

<comment><USER5> We'd do it anyway. I'd be bootlegging and sharing bootlegged music if it was the 80s. Why? Because I'm dirt poor and can't justify paying for such high level things. I still want it though. You can definitely make the argument that I'm stealing from them, I'll give you that, but I'd never buy it in the first place so I don't see how my copying something disrupts their bottom line so much.

<comment><USER6> You've raised an interesting issue.

If you never intend to buy said item in the first place because you can't afford it or whatever, how are you hurting the business in question? As long as you are not sharing the product and consuming it solely for yourself, then nothing in the world is changing, you are just using a product.

<comment><USER7> Hang on, this is not an interesting issue, is the core point of the whole debate. Have people missed it?

Its been the same since all the bleating went on about fake designer labels in the 80's. You are not likely to buy a fake Le Whatever t-shirt if you can afford the real thing. Who buys fake Rolexes? Its not the millionaires who buy the originals is it? If you are a rich person with fake designer labels, you look like a prat. There for, mostly, no loss. The whole thing is basically a lie. There is very little actual loss due to piracy.

Look, most people spend all their money each month. If not spend, then allocate. Which means they have a finite amount to spend. So, if they have to buy that which they down load for free, that means they don't buy something else. Maybe the would just do with out. Often with music it ends up not mattering. I mean, out of 100 CD's how many would you listen to regularly? How many never? What about those who have "illegal" downloads? Most of it you never listen too, right? I could go on.

So, the assumption that these industry Muppets make that all the recordings they see downloaded represents lost money is utterly ridiculous. And they must know that.

And here is why: Music faces massive competition for our finite funds. We spend less in percentage terms because now there is so much more to spend our money on than there was back in the 90's, 80', 70's, and so on. As the decades went by, the competition increased and the music industry got squeezed out, and that is a huge problem. They see there isn't really much they can really do about it, so what we have now is the final desperate tactic of blaming their former customers who chose to spend more of their money else where.

Ooooo, bit of a rant? Sorry... I think I stand by all that. Makes sense to me any way.

<comment><USER8> I guess part of the problem with fake rolexes is they affect the real brand. Much of the appeal of luxury items comes from their uniqueness & rarity.

The music industry's problem with itunes etc is that they're giving up a lot of control (pricing, customer info, etc) & aren't getting much money out of digital downloads. And Amazon could start signing artists tomorrow.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> If SOPA/PIPA would have been ineffective, why did they push it so hard?

I can think of a couple of things:

1\. They didn't really push it all that hard, the RIAA thought they could just slip it through with a little help from their "friends" in Congress. They were genuiely surprised by the upwelling of opposition.

2\. They've got some ulterior motive than just externalizing the costs of copyright enforcement. A "feint within a feint", maybe, or maybe the RIAA is a tool of some other, greater, force.

<comment><USER10> I'm not clear on why, but the *AAs seem intent on controlling distribution, not just making money from it. SOPA and PIPA would have given them a way to control things even if it wouldn't really make them more money.

<comment><USER9> Focusing on controlling distribution is interesting, and indeed, the *AAs do seem intent on control. But that just moves the question one level down: why focus on control? Isn't micro-control of stuff like distribution usually externalized by corporations? Why try to control something that any thought at all leads you to say "why bother?"

<comment><USER11> _Question: Who really gave that order?_

 _Answer: Control._

 _Question: If Control's control is absolute, why does Control need to control?_

 _Answer: Control… needs time._

 _Question: Is Control controlled by its need to control?_

 _Answer: Yes._

\- William Burroughs - Ah Pook is here

He may have been onto something with this one.

</comment></comment></comment></comment><comment><USER12> > "These illicit sites are among the culprits behind the music industry's more > than 50 percent decline in revenues during the last decade, resulting in > 15,000 layoffs and fewer resources to invest in new bands," wrote RIAA CEO > Cary Sherman in a New York Times piece last year.

If we assume that the average salary of the 15,000 laid off employees was $67k-100k, so that means they saved $1-1.5 billion a year with these lay-offs?

<comment><USER5> If it's true, it's still only a fraction of what they'e claiming they're losing in 'potential' revenue.

<comment><USER13> Which is apparently more wealth than the entire output of humanity.[0]

[0]: [http://www.pcworld.com/article/223431/riaa_thinks_limewire_o...](http://www.pcworld.com/article/223431/riaa_thinks_limewire_owes_75_trillion_in_damages.html)

<comment><USER14> Those are statutory damages, not actual damages.

<comment><USER13> Note that the grandparent used the word "Claiming".

</comment></comment></comment></comment></comment><comment><USER15> Is music piracy still a thing? I don't even know how to do it anymore...

</comment><comment><USER16> It's impressive how TorrentFreak can create such a long article out of a single sentence from a slide. Does anyone know _why_ the RIAA believes that SOPA wouldn't be effective for music?

<comment><USER7> "It's impressive how TorrentFreak can create such a long article out of a single sentence from a slide."

Not familiar with "journalism"?

Maybe a British trash tabloid thing, but here our "journalists" don't even need a whole sentence, let alone from "source" as "reliable" as a slide.</comment></comment>


Charted - <AUTHOR> http://www.charted.co/ <comment><USER2> This interface is solid. So many easy-to-use graphing tools have poor defaults. This is perfect for the use case of a quick visualization for queried data or (even better) live data you'd like to dashboard.

</comment><comment><USER3> an upload feature would be stellar.</comment>


What is the difference between a software solution and software service? - <AUTHOR> http://wiki.answers.com/Q/What_is_the_difference_between_a_software_solution_and_software_service

<comment><AUTHOR> My English teacher/blog editor does not like the term solution , so I am trying to find an authoritative answer to this question.

Other references:

\- [http://www.dotsign.com/internetmarketingideas/2011/06/23/ser...](http://www.dotsign.com/internetmarketingideas/2011/06/23/service- vs-solution/)

\- [http://johnbell.typepad.com/weblog/2010/10/do-you-sell- produ...](http://johnbell.typepad.com/weblog/2010/10/do-you-sell-products-and- services-or-solutions-social-media-can-help.html)</comment>


Introspected REST: An Alternative to REST and GraphQL - <AUTHOR> https://introspected.rest/ <comment><USER2> It looks like the meat starts at section 9.

\- Sections 1-8 are a summary of REST, HATEOS, their problems, and reflections on the problem that every endpoint is `application/json` and not something more specific to the intended use case.

\- Sections 9-11 discuss a variant of REST that doesn't use Media Type differentiation for capabilities, but rather composable nuggets of semantics called MicroTypes. The MicroType schemata is accessible through an introspection interface; one suggestion is to use (cacheable) OPTIONS. Clients would transmit their desired MicroTypes to an endpoint using the Accept-Type header.

If I'm reading this correctly, the author is suggesting the clients be allowed to specify the middleware chain used by the server to compose the response data (cf pagination, query, filter MicroTypes), and that these programmable chains are attached to every traditional REST endpoint collection. In one sense, this is an attempt to marry the resolver chain concept from GraphQL into the world of RESTish JSON APIs.

I think you could pull this off only with a dedicated server library because I don't see real world developers using this technique successfully on the current crop of HTTP webserver APIs. There's also the very real performance issues that come up when clients are allowed to control resolution; we see companies using GraphQL in production locking down the ability to do custom queries.

<comment><USER3> I think the best argument the author could have made is an example. If a proposal like this cannot be illustrated in an example (like it can be done for REST or GraphQL), it's likelihood of adoption is going to be low...

<comment><USER4> What I got out of it... REST as practiced now is bad. To find out how to make it good, read this 40 page manual. I prefer to use the system that doesn't require long form specification reading.

</comment></comment></comment><comment><USER5> There is some good stuff in here, but it misses the biggest pain point developers face when trying to make a robust hypermedia API: tooling. There is a lack of tooling on the server side and almost no tooling on the client side. The amount of effort required to serve a RESTful API requires a lot of upfront investment. Then convincing the client developers to take advantage of the hypermedia affordances requires a lot of time and energy. If one does manage to convince them, the client tooling requires even more upfront investment. The only attempt at client tooling I have seen is the work done by Mike Amundsen.

One thing GraphQL got right was focusing on the client tooling. If the client developers are bought in to the protocol/specification then the server developers will naturally come along. The reverse has not been true in my case.

This opinion is based on my experience building hypermedia APIs, consuming hypermedia APIs and helping with the HAL hypermedia spec.

<comment><USER6> This tooling-first approach is basically what we're going for with [http://www.hyperfiddle.net/](http://www.hyperfiddle.net/) – the requirements of the killer app are what drives the hypermedia API, the mechanics of which are extremely innovative and weird. One key difference is Hyperfiddle's I/O layer is decoupled from transport, it is not limited to http or client/server, which opens a whole spectrum of I/O configurations with different performance characteristics, including "ship the api definition over there so it can run near that secure database" like html/javascript layer apps are shipped over the wire. We think Hyperfiddle can emit Siren-compliant representations (or any other general purpose hypermedia mimetype), though Siren can not express the entire continuum of I/O and data ownership that Hyperfiddle's protocol can (and thus Hyperfiddle probably cannot be built directly on Siren – _the tools must come first_ ). We solve the caching problems with an immutable database (Datomic) which permits idealized caching of everything at every layer. If the constraint of an immutable database sounds like a dealbreaker today, it probably is; but it unlocks a whole new frontier of capabilities that apps ten and twenty years from now will require. Why are we designing new protocols for the requirements of yesterday?

<comment><USER5> This is definitely interesting and I will spend some more time checking this out. This tooling looks more advanced than pretty much anything else out there, but from what I can tell it is a server-side driven approach. I have been trying to imagine what tooling that is client-side first looks like. It should not matter _how_ a server implements something, such as Siren, only that it properly follows the semantics of the Siren protocol.

<comment><USER6> It can be server driven, but it doesn't have to be. It depends where the data is and what the permissible access patterns are and which process is responsible for enforcing them. These days the data that matters is in server- side databases with tightly controlled access patterns so it is pretty weird for the client to be in charge. Hyperfiddle's data protocols are sufficiently abstract to run anywhere in the continnuum of data ownership [1], but so far we've only bothered to implement the parts of it that matter to today-era businesses. Are we thinking about this the same way or have I missed the mark? [1] [http://www.dustingetz.com/:urbit-continuum-of-data- ownership...](http://www.dustingetz.com/:urbit-continuum-of-data-ownership/)

<comment><USER7> Wow, this is really interesting. Wish I worked on it!

What tech and languages do you guys use? And are you hiring?

</comment></comment></comment></comment></comment><comment><USER8> Also submitted a couple months ago. Only got a few comments back then: [https://news.ycombinator.com/item?id=15211604](https://news.ycombinator.com/item?id=15211604)

The first sentence of TFA captures one of the most annoying things about REST discussions: "In this manifesto, we will give a specific definition of what REST is, according to Roy, and see the majority of APIs and API specs (JSONAPI, HAL etc) fail to follow this model."

At this point I've read or heard dozens of claims like this, that almost everyone is doing REST wrong. It's well past time to stop blaming all the REST implementers in the world for being too dumb to understand Fielding's brilliant vision. If most software developers can't get REST right, then either proponents have consistently done a crappy job explaining the idea, or it's not as great an idea as they think.

Skimming the table of contents, it looks like the authors have thought deeply about the problems with REST and come up with some well-reasoned solutions. So they're answering the "REST vs Introspected REST" question. But much more relevant to me is the "Introspected REST vs GraphQL" question. What would make someone choose this over GraphQL? Introspected REST has a lot of catching up to do to match GraphQL's tooling and market share.

<comment><USER9> Author here: The problem with GraphQL is that it has to re-invent everything on top of HTTP. Introspected REST reuses HTTP properties and architecture by default, making more robust and compatible with existing clients. Also related: [https://news.ycombinator.com/item?id=18425581](https://news.ycombinator.com/item?id=18425581)

</comment></comment><comment><USER10> The developers that would hypothetically adopt and implement a new paradigm like this would probably love to just see some straight forward examples of client and server usage

</comment><comment><USER11> Can we just have back SOAP/WSDL and return to rational design and interoperability, or at least limit "REST" to a web facade? I think after 10-15 years of mucking around with "REST" (or what people think it is, as rightfully pointed out in TFA) it's very clear that there's not going to be a common understanding, let alone standard for it. As a freelancer having worked on maintaining many "REST" trainwrecks, I can tell you that naive REST spaghetti is absolutely much worse than any SOA design ever was. The technical debt and high maintenance might not be apparent while you happily code away your new "microservice"; but I can assure you you've just traded a tiny bit of upfront design for a long-term puzzle you're leaving behind.

Did you know WSDL has supported "REST"-like encoding of parameters in URLs and operations as HTTP verbs since 2001?

<comment><USER12> Even assuming we'd want XML as the message/schema format back (with all the security, performance and readability issues it entails), SOAP/WSDL/WS-* was any better than rest in standardization back in the day.

For instance, there were multiple different ways you could format your message (RPC/encoded, RPC/literal, Document/encoded, Document/literal, Document/literal wrapped) and different implementations supported different formats. There were all kinds of extra features that were never supported across board like multi-part messages etc.

Before WS-I there was practically zero guarantee that two SOAP implementations would ever be able to interoperate (and please remember, while REST has no standard in practice, it's dead simple to implement REST by hand - the same couldn't be say about SOAP!). WS-I only came out in 2004 or so, and by then it was already too late. I'd say the SOAP ecosystem is _the_ definitive case study for trainwrecks.

If you really want a standard method for RPC then you're much better off with a modern implementation like gRPC or Thrift or Cap'n proto. Please don't go back to the nightmare called SOAP.

<comment><USER13> I feel that the point is not about the transfer representations but about the interaction model. REST makes sense as long as you can sanely map your interactions onto simple modification of something that can be meaningfully described as "resource". For typical application that implements non-trivial bussines processes this means that you either expose low-level implementation details (ie. how you internally represent progress of some process) in your API or you implement "REST" API that is sufficiently far from what REST is supposed to mean that it stops to make sense to use that moniker.

On the other hand SOAP is good match for such applications because it is simply an RPC mechanism, albeit with unnecesarily complex marshalling and transport layers underneath.

</comment></comment></comment><comment><USER14> This looks a lot like OData - a REST-ful API standard with schema introspection, patterns for defining and traversing resource relationships, well-defined guidance around mechanics, tooling support. In particular, the "Microtypes" concept resembles how entities work in OData - rich query support for collections (eg. sorts, filters, order by), "expansions" on related resources, even inheritance semantics (ie. being able to request a derived entity as its parent type).

<comment><USER15> The fact that OData calls itself not only RESTful, but literally "the best way to REST", while using requests like this:

        GET serviceRoot/People('russellwhyte')/Microsoft.OData.SampleService.Models.TripPin.GetFavoriteAirline()

is an absolute _insult_ to REST and the target developer audience.

[https://www.odata.org/getting-started/basic- tutorial/#bounde...](https://www.odata.org/getting-started/basic- tutorial/#boundedFunction)

<comment><USER14> I think this is a bit cherrypicked. The example you're using is a fully qualified bound function. OData support for actions and functions explicitly exist to provide affordances for how to do RPC within OData. You can easily model this API in OData without requiring a function (eg. having a navigation property reference called "favoriteAirline"). Moreover, you can typically invoke functions without a fully qualified prefix (save cases where there is ambiguity).

For the most part, OData does a good job at letting folks opt into complexity, allowing integrators to make full use of APIs without needing to know anything about $metadata, inheritance mechanics, functions, etc.

</comment></comment></comment><comment><USER16> I never understood why people love REST. Just use some kind of JSON-RPC, or something like that. In my experience most of so-called "REST" interfaces are just poorly written RPC. Some people even think that REST means HTTP + JSON. It's extremely rare to encounter a true REST interface with e.g. HATEOAS, proper caching, etc. And if many developers can't utilize technology, probably technology is not good enough to be commonly used. Web Services with their WSDL were the best thing. They were too complex, they use XML which is apparently out of fashion today, but the idea was solid, we just need something simpler but with good enough tooling.

<comment><USER17> REST aligns _very_ well with CRUD. Most software is, basically, CRUD.

So by saying "we're going to go with REST", you can determine about 90% of your API design more or less instantly, and it rarely gets in the way.

You still have to get your domain modeling right, and sometimes you need to make some extra resources. But you have a design that, basically, works.

<comment><USER11> I disagree that most apps are CRUD. To the contrary, most apps starting out as naive CRUD have complex implicit constraints related to eg. in what state you can modify resources in a particular way.

Even for CRUD apps with simple master/detail data relationships it doesn't make sense to tie your domain design to network requests.

</comment></comment></comment><comment><USER18> Generally speaking, I think a lot of developers get into trouble by not really putting the effort into grasping the _ideology_ of architectural frameworks like REST, 12factor, and React.

For example, our API needed a way to serve a different view of an existing model. How do I get the API to know which view to serve? When I asked around, they said the best way was to do /cars/1/prices, which I didn't like because I feel it breaks REST. There's no price model to the car, prices are fields of cars, at least for now.

I had to think for a few seconds before coming up with just using a query parameter to set which view to serve, /cars/1?view=pricelist, preserving REST. But most coders just take the first thing that comes to mind, and then wonder why their applications are so messy after a few years.

Coders seem to not want to bother learning how existing solutions are _supposed_ to work before jumping to a half-baked newer solution just because it seems more intuitive. If you understand REST, then you can see how GraphQL can improve certain aspects of API interaction.

But it's not a panacea any more than React is. If you understood how HTML, CSS, and Javascript are supposed to work, then you can see how React improves on it. But if you can't then your React applications will be just as horrendous as your jQuery ones were.

</comment><comment><USER19> REST allows for clients and servers to evolve independently. If you can constrain that you can probably design something significantly simpler. That's not a shortcoming of REST, though. The channel between your mobile client and your backend would probably be better served with something more like RPC than academic REST.

<comment><USER9> That's our proposal/challenge here, come up with a model that tries to merry the best of both world (RPC and REST) but still adheres to HTTP semantics and allow clients/servers to evolve independently.

</comment></comment><comment><USER20> Kudos to the author for going the extra length of trying to maintain semantic interoperability and reuse by showing how to be backwards compatible with e.g. JSON-LD. This makes it possible to continue to build upon all the vocabularies already created.

<comment><USER9> Thanks! That was the real challenge!

</comment></comment><comment><USER9> Hi, author here. AMA. But I would like to make a couple of points.

For starters, a lot of people are looking for a TL;DR. There is no such thing. Same with tooling.

This is an open publication and should be considered as is. The intention was to come up with a better architectural design than REST, reusing existing Internet architecture. And that was the real challenge. Because REST and HTTP have been built almost by the same person. Bending existing Internet architecture to fit another architectural style for networked services is extremely difficult, but apparently not impossible.

GraphQL for instance, uses HTTP just for the transport layer. That's a big assumption to make there, anyone can build very flexible stuff if you are about to re-design everything HTTP gives on top of HTTP.

Another note is the reason that it takes so much time to get to the actual model (section 9) is to make sure the reader understands what is REST and where REST fails. And I haven't really seen any other document/publication explaining REST so extensively. So for those who are complaining that none gives a definition of REST, then go through section 1-6 and you should have it.

Last but not least, Introspected REST is compatible with existing REST architecture, it just makes it more robust and flexible. So for the tiny hello world example, it doesn't really make any difference other than exposing some meta data through the OPTIONS endpoint, like the (JSON) schema and the linking. But for complex APIs it should give huge advantages compared to REST.

And again: this is an open publication. From that to actual implementation there are many steps needed to be taken (for starters defining the necessary microtypes).

</comment><comment><USER21> TLDR?

<comment><USER10> Yeah seriously... +1 to this. Even just a handful of examples of client and server usage would be far more useful for determining if it's worth digging deeper

<comment><USER22> This is a formal proposition. If it catches on I expect others to explain it in various levels of complexity but this document is intended to be dense and deeply descriptive.

<comment><USER23> Sure, but couldn't it begin with an executive summary?

If you take RFCs as an example, many start with a simplified description or problem statement before then proceeding to get into the details.

</comment></comment></comment></comment><comment><USER24> ok I think I'm missing something here

</comment><comment><USER25> I wasn't able to read this entirely it's a very dense spec.

That said , even if the arguments in this spec are solid the entire industry are sold itself to GraphQL.

GraphQL has won and it won't change.

<comment><USER26> 2007: SOAP has won and it won't change

2012: REST has won and it won't change

2018: GraphQL has won and it won't change

2023: ...

<comment><USER27> Hahahahahaha.

Perfect.

Maybe 2023: gRPC has won and it won't change</comment></comment></comment>


Ask HN: Best way to start with functional programming? - <AUTHOR> Any ideas on the best way to get started with functional programming?
I'm thinking of Clojure/ClojureScript+React, Haskell, Scala, or Elixir. Especially in the context of web or mobile.
The FP I've done so far is however much FP you can do with JavaScript/Python (currying, higher order functions, map/filter/reduce, underscore), and about a third of SICP (Scheme). <comment><USER2> Most Haskellers will point you at _Learn You A Haskell For Great Good_.

[http://learnyouahaskell.com/chapters](http://learnyouahaskell.com/chapters)

If you go down this route: Once you start getting to chapters that don't have direct analogues in other languages, such as Functors, Applicative Functors, Monads, etc, _slow down_. A lot. I tried numerous times to just push through in the hopes that it would all come together, and I ended up giving up because I just dug myself further into a pit of nonunderstanding and frustration.

Give yourself time to let the strange concepts sink in. Use them several times until you truly understand them. Then move on.

</comment><comment><USER3> FP is going to feel like programming 101 at first before you get over that initial hump. That's the way it went for me at least. The trick is seeing it through and making it past that first frustration phase. Once it clicks, it will change the way you think about programming. I'd say pick up the defacto book in one of the langs you listed and get started! I went with Elixir, and I'm hooked. Dave Thomas' _Programming Elixir_ is an excellent place to begin.

</comment><comment><USER4> I think it all depends on what you're background is in. If you want to be able to work on the JVM, then Clojure an Scala are going to be your obvious betts. If you're coming from a dynamic language (python/ruby/javascript) then it may be easier to take on a lisp(or other dynamic-functional language) as your fist FP language.

Scala is a great choice for people familiar to Java, and don't wan to give up all the JVM knowledge they've gained over the years.

I personally prefer Clojure/Clojurescript and the direction that the community is heading.

I took a coursera course[1] on programming languages a while back that did an introduction to ML, Racket, and Ruby. It was great to through similar problems in three very different languages. It gives you the basic information you need to weigh the costs and benefits of using a particular language in a particular context.

[1] [https://class.coursera.org/proglang-2012-001/wiki/syllabus](https://class.coursera.org/proglang-2012-001/wiki/syllabus)

</comment><comment><USER5> I really liked The Little Schemer[0]. The language/syntax is a little different to Clojure but it's broadly transferable; really helped me think functionally.

I'm a total noob with this stuff but I've been really happy with Clojure (and more recently ClojureScript/Om) :)

[0] [http://www.amazon.co.uk/Little-Schemer-Daniel-P- Friedman/dp/...](http://www.amazon.co.uk/Little-Schemer-Daniel-P- Friedman/dp/0262560992)

</comment><comment><USER6> IMO Haskell is your best option if you want to learn functional programming (being a purely functional language) and this is the best guide to learning Haskell I've come across: [https://github.com/bitemyapp/learnhaskell](https://github.com/bitemyapp/learnhaskell)

It also has an irc channel that is fairly active (#haskell-beginners).

</comment><comment><USER7> First I'll second the other comments mentioning "learn you a haskell". I dont know haskell in the way an expert does, nor do I have very much exp writing it but, I can and enjoy when I do. "learn you a haskell" does a great job at speaking in clear english and is, honestly, an enjoyable book that is pretty fun to read.

But, if you are like me, you need to understand the motivations and intensions behind things before you can really feel that you have reached understanding. You know, the big picture type stuff.

So, in my opinion, to fully understand functional programming, you need to think about what it tries to do/solve. To get here I would recommend thinking about insanely complex systems and how you would build a flexible and efficient one. To start you may think about all the objects you would need to account for, which, eventually, causes insanity. Its not the objects in the system that causes the complexity, it's their interactions. So, you may start thinking about handling all of the interactions, which is where, I believe, the solution (really method is the better word) lies.

I believe then, that the key to understanding functional programming is to understand what its related concepts are able to solve. Thinking about how to make sense of and control this shitstorm of complexity will, hopefully, shed light on why the hell something called an "applicative functor" or, <insert other crazy/weird term> even exists.

I know, I know, I am being too general... the stuff comes from category theory though, so, uh, hard not to be... but seriously, if this is at all helpful and not totally incorrect, I'd be happy to expand in more detail

if, on the other hand, it is not helpful... forget it totally, learn a language, and hopefully the concepts follow else if, I am totally incorrect... why and where did it all go so wrong? else, nop

</comment><comment><USER8> I found Martin Odersky's Scala course on Coursera to be a great intro, and my background at that time was similar to yours. Scala itself isn't that great for learning FP since it's entirely possible to write in a Java-like style. However the Coursera class uses a functional style and the autograder ensures you do too.

</comment><comment><USER9> I found the Functional Programming Principles in Scala course on Coursera to be incredibly helpful

[https://www.coursera.org/course/progfun](https://www.coursera.org/course/progfun)

The course was very challenging and I learned a lot in a very short period of time. Highly recommend it.

</comment><comment><USER10> Also checkout the purescript book being created:

[https://github.com/paf31/purescript- book/blob/master/chapter...](https://github.com/paf31/purescript- book/blob/master/chapters/1%20-%20Introduction.md)

</comment><comment><USER11> Learning a more functional language is a good idea, but you can also do more within JavaScript itself. Well after I'd been using higher order functions and Underscore, I found Michael Fogus's Functional JavaScript to be quite good. There is also JavaScript Allongé by Reginald Braithwaite, which I want to read soon. For libraries, there's Lemonad, Bilby and Fantasy Land, all of which push the boundaries of functional programming past what you get from Underscore.

Regarding Haskell, I didn't love Learn You a Haskell, but did like Learn Haskell Fast and Hard.

</comment><comment> a-saleh To be honest, best way so start FP, is to have project where you are forced to do FP :) In my case it has been a quite an awesome small selenium test- framework written in clojure I needed to use, while working for RedHat :)

Just pick a project and a most aproppriate lenguage and roll with it. You probably can guess, what language would suit your needs best, and if you haven't made up your mind about that, I (or other HN user) will probably suggest good fit for your project of choice :)

</comment><comment><USER12> I started Clojure this week. It's really fun and it's syntax doesn't boggle my brain as much as Haskell's.

</comment><comment><USER10> If you want an introduction to functional programming, why not go all the way with a pure functional language such as Haskell:

[https://github.com/bitemyapp/learnhaskell](https://github.com/bitemyapp/learnhaskell)</comment>


A Raspberry Pi VAX Cluster (2012) - <AUTHOR> https://www.rs-online.com/designspark/a-raspberry-pi-vax-cluster <comment><USER2> Back when the Y2K thing was a thing all of these little VAXStation VLC's were being dumped on the market left and right. I had 15 of them at one time with an average acquisition price per unit of less than that of a Raspberry pi :-). Even built a 4 unit cluster for fun with a NetGear 4 port switch.

Easier to get RasPi's of course, and even easier to run multiple containers running simh to get the same experience. I can recommend playing around with a VAXCluster for while to get a feel for what a nice clustered computer command line felt like back in the 90's. There are still lessons to be learned for current developers of "cloud" systems.

<comment><USER3> > There are still lessons to be learned for current developers of "cloud" > systems.

Any notes of your own or links on such? I'm old school myself (e.g., my first computer was a Northstar Advantage), but I never had the pleasure of working on a VAX.

<comment><USER2> I kept some notes on my "House of VAX"[1] but really DEC's documentation was a wonder to behold, binder after orange binder on everything. A lot of that is online (scanned) on the bitsavers.org web site.

[1] [http://www.mcmanis.com/chuck/computers/vaxen/](http://www.mcmanis.com/chuck/computers/vaxen/)

<comment><USER3> Lots of cool stuff, but I'm curious for your elevator pitch of "VMS could do <awesomeness> but nobody does this today, if they did, they'd make cloud computing even more powerful".

Lessons for the lazy, as it were :-)

</comment></comment></comment></comment><comment><USER4> Ok.. The problem I've haven been trying to obtain a copy of VMS to try out this very setup. I have tons of old VMS programs I created in college back in '89 I would love to execute again..

In theory you can get a hobbyist free copy of VMS via this site, but no one has responded to me from it. The instructions on how to get the license and binaries are not very clear:

[http://www.openvmshobbyist.com/news.php](http://www.openvmshobbyist.com/news.php)

<comment><USER5> The page for getting a hobbyist license is really unclear. I finally found 2 links on the page which mentioned the hobbyist license. One link brings up a warning, and if I say go ahead anyway, I get a file not found message. The other link does bring up a signup page, but one of the things it asks for is the name of a "participating chapter" and a "membership number". Can anybody explain what this is? Do I have to sign up for a membership in some obscure organization to get a license?

<comment><USER5> Did some searching (should have done it before I posted). The "obscure organization" is actually an HP Enterprise User Community, and you can get a free membership by signing up here: [http://www.connect- community.org/](http://www.connect-community.org/)

</comment></comment></comment><comment><USER6> Given the emulation is for a 64MB VAX, would it not be viable to run several VAX emulators upon a single Rpi and play with clustering that way and removing the limit of needing two Rpi's with idle resources.

Had a quick search and whilst no clear cut examples jumped out, it seems that some emulations require multiple instances of SimH running (HP!), so would appear viable, just some hacking (original definition, not the tabloid definition).

<comment><USER7> Newer version of SIMH let you allocate up to 512MB to the VAX instances.

</comment></comment><comment><USER8> Neat writeup. I was always a fan of VMS; my university still had a VMS cluster that was used every quarter for class registration and completely ignored the rest of the year, but if you poked around you could still find relics of the old days, like ancient discussion forums software still containing posts from the 90s.

If I can put on my enormous pedant hat for a moment though, a VAX is a minicomputer, not a mainframe.

<comment><USER9> A MicroVAX was certainly a mini. But the range extended up to the VAX 9000 which was a >$1,000,000 mainframe.

<comment><USER10> Well, to be extra pedantic, the latter MicroVAXen used the same enclosure as the "desktop" VAXstations, except without the graphics and peripherals -- just serial ports for a VT terminal!

</comment></comment></comment><comment> bra-ket You might be interested in this job at Lockheed [https://news.ycombinator.com/item?id=20209869](https://news.ycombinator.com/item?id=20209869)

</comment><comment><USER11> Aha, I mentioned this yesterday in the 'oldies' thread. Be interesting to see if others have anything to say on it, or if the idea of a VAX Cluster has passed most people by.

<comment><USER12> After my initial computing forays with BigTrak, a ZX Spectrum and some time on a BBC Micro and Apple Mac, my first multi user computer use was on the VAX Cluster at uni. I hated UNIX when I tried that on a Sun workstation as it seemed so much less friendly than VMS with it's hierarchical HELP command. Ironically I went onto to a 25 years and counting *NIX/Linux based infra career :)

</comment></comment><comment><USER13> SimH is a beautiful thing. I use it to run Multics (and explore the features that Unix left out.)

Should also be possible to run SimH in a web browser to make a living computer history museum on the web.

<comment><USER14> Thanks for this. When the Multics source was released a few years ago, I really wanted to play around with that environment. It's nice to know there's something a mere mortal can install and use.

</comment></comment><comment><USER15> Don't tell Dave Cutler you're running OpenVMS on top of a *nix!

<comment><USER16> He is the turncoat that brought down the empire. He was full on correct about Unix though, except that we're not fighting over sub-MIPS resources anymore so the "waste" created by that architecture doesn't affect the bottom line as much (unless you're Google hah -donworrydeyreworkinonit).

</comment></comment><comment><USER17> This is really cool. Since reading about Masters of Deception, Legion of Doom And other legendary hacker groups with a thirst for VAXen in the late 80es, I have always wanted a VAX machine to hack on.

<comment><USER18> I don't think they were priced because they were a delight to use or hack but rather because they were nice targets due to the companies using it and what might be found on them.

</comment></comment><comment><USER19> lmfao, absolutely gosu!

+1 openvms

i remember the good old days of setting up vms clusters and good old dcl. we had easily 96 node clusters, alphas and vax hw, if my memory serves me correctly.</comment>


Ask HN: How can I remove my submissions? - <AUTHOR>

How can I remove my submissions or delete my account? <comment><USER2> If your submission/comment is older than 2 hours old, your ability to delete it expires. I'm also pretty sure you can't delete your account so that your comments that you don't delete within 2 hours or that admins don't delete remain on the record.

<comment><AUTHOR> Can I contact the admin to have my submissions deleted. I really need to.

<comment><USER2> I'm sure there's no harm in trying: <http://ycombinator.com/contact.html> \- whether or not they'll do anything about it is a different question since there are good reasons why they wouldn't want to let people 'revise history' or 'interrupt the conversation' which is more or less what the site seems to be about.</comment></comment></comment>


Booking bugs (for non-engineers) - <AUTHOR> https://docs.google.com/document/d/1bPtnmP9ACOqS2JOXFQZgKLfW2UwB-8oRgUoLIFkZQOM/edit#heading=h.b3v9mp4zdifd <comment><AUTHOR> Wrote this doc to help my support team better communicate UI bugs to our engineering team. Looking for feedback or any relevant (or better) resources.</comment>


A Costly Parade, by Why the Lucky Stiff, and that NodeBox pong game -- in Shoes - <AUTHOR> http://hackety.org/2008/11/21/aCostlyParade.html

<comment><USER2> You know, forget Rails, forget Mongrel. I'll keep using Ruby for a long time because _why is here, making wonderful, beautiful toys.

<comment><USER3> I often wonder how he supports himself. Either he lives on little and spends his time making cool stuff and helping kids program, or he's actually a Rockerfeller.

Alternatively, he holds down a day job, and is just so prolific that it seems like he just makes shoes and hpricot all the time.

<comment><USER4> Supporting yourself and still coding a lot of cool stuff to give away isn't really that hard. There are plenty of service, light tech support, or even desk jobs which only require a few hours a day worth of real concentration, and leave you alone with your thoughts the rest of the time.

Covering rent + groceries in some sleepy midwest town with decent broadband is do-able on minimum wage, if you don't mint having a small apartment and older computers.

The challenge is in living the kind of lifestyle that most HN readers have or aspire to: living in S.F., going out to nice restaurants + clubs with your hip, hacker friends, owning multiple nice computers + tech toys, and flying to conferences and vacations all over the world several times a year.

 _That_ stuff gets expensive, fast.

</comment></comment></comment><comment><USER5> What a creative way to diss.

<comment><USER6> Not being inside the Ruby community, I felt like I missed a lot. Was it really a dis?

<comment><USER7> Yes, it was. None of the things said or insinuated were without reason. It was primarily a _shame on you all_ type of commentary.

</comment></comment></comment><comment><USER8> I have no idea what that was... but I loved it.

<comment><USER9> You should read why's guide to ruby. Its fantastic.

</comment></comment><comment><USER10> "Ergo, Zed is Hannah Montana."

Hello? I thought "Zed is dead", but now really, all that needed was an overt HCE reference to boost such a fine diatribe into the literary flame sphere.

</comment><comment><USER11> Does this guy have a name? Or should I just call him.... "Y"</comment>


Monads Are Not Metaphors - <AUTHOR> http://www.codecommit.com/blog/ruby/monads-are-not-metaphors/print/

<comment><USER2> I've recently finished reading Learn You A Haskell For Great Good!, and I think the author's approach to monads works well. I'd read various metaphorical explanations that only served to further cloud the issue, but thanks to LYAH I finally got it.

In short, he has you using monads long before you understand them (Maybe and IO in particular), then slowly introduces monads by first explaining functors and applicative functors.

In retrospect, the mystique seems crazy. Monads are just not that confusing: they're simply values with added context, along with functions that let you interact with those values without losing the context. It's a shame that this powerful idea is so obscured by its supposed difficulty.

<comment><USER3> >Monads are just not that confusing: they're simply values with added context, along with functions that let you interact with those values without losing the context. It's a shame that this powerful idea is so obscured by its supposed difficulty.

This is a typical thing in mathematics.

<comment><USER4> This is why I don't like self-study for mathematics. A lot of the stuff is very simple once you understand what it's for, but finding out what it's for from the formal definition is an uphill battle.

And then, after you see the thing for what it is (months later), you start coming up with questions that lead to more formalism.

Studying from an encyclopaedia is hard, and even a good book will only get you as far as well-known results. Answers are much easier to learn from, so you want someone to provide you with the correct questions and avoid the difficult ones.

</comment></comment></comment><comment><USER5> > Here's the deal: Haskell doesn't allow side-effects. At all.

I disagree with this, and it was Eric Meijer's "Fundamentalist Functional Programming" lecture that really changed my mind. The point isn't that Haskell prevents side effects. It's that it requires you to be explicit about them. Indeed, some advocates say that Haskell is "the best imperative langauge". I don't know that I would go that far though.

<comment><USER6> Link to the talk: <http://www.youtube.com/watch?v=UuamC0T3hv8>

</comment></comment><comment><USER7> I have to say, I had no idea what monads were before reading that article, and after reading it, I still don't.

It sounds like something to get the benefits of object-oriented programming while using functional programming, but I'm really confused.

<comment><USER8> Do you understand the three-level distinction between type constructors (i.e. templates like C++, or generics in other languages), classes and instances? Do you understand first-class functions (lambdas)? If you've got those concepts down, you can understand monads.

Monads are the name for a particular member of a forth level on that three- level stack of abstractions (call them type classes, as that's what Haskell calls them (though I'm fudging a little here)); a type class is a particular shape for a generic type, in the same way that any given generic type is a particular shape for a class, and a class is a particular shape for an instance.

So when people talk about Option/Maybe being a monad, they mean Option/Maybe is a generic type (i.e. a type constructor) which has a certain shape - i.e. has a particular set of methods / functions defined on it.

That's the abstraction level of monads out of the way. The next thing to understand is the particular operations required. Monads are like containers for values, but rather than operating on the values directly (e.g. y = f(x)), you instead pass the monad the function you'd like _it_ to apply to the value (e.g. y = x.bind(f)), and it returns you a monad which is logically the wrapper that function applied to its contents.

Because the application of the function to the value inside the monad is delegated to the monad itself, it gets to decide what to do with it. In the case of Option/Maybe, it'll only apply the function if the contents aren't empty. In the case of IO, it'll logically buffer up a list of imperative I/O operations which will be logically returned as a result of the main function; and that list of imperative instructions will then be imperatively executed, after the nice and pure Haskell program has finished its unpolluted existence. (That's how it happens logically (assuming there are no cheats available in the language), but not necessarily actually.)

<comment><USER9> I really like the shapes explanation. It's a much more explicit version of what I was trying to say.

</comment></comment></comment><comment><USER10> When learning any new sufficiently abstract typeclass (whether it is Monad, Applicative, Functor, Monoid, Arrow, or whatever), the best way to learn it is in two phases: 1) What is the mathematical meaning of the typeclass? 2) How can the typeclass be applied (what are the instances) and how do they map to reality?

It is very tempting to try to jump quickly to 2 - but it helps to force yourself to avoid thinking about applications for a bit and understand the applications.

I think the article does achieve this.

<comment><USER11> You mean 'and understand the axioms', don't you?

</comment></comment><comment><USER12> I'd love to have the data to graph the ratio public_monad_tutorials/haskell_programmers over time.

<comment><USER13> First wave: don't think of monads as _monoids in the category of endofunctors._ No, Monads are burritos, programmable semicolons, design patterns etc.

2nd wave, _monad tutorial fallacy, red herring, don't read/write monad tutorials, they just sort of grow on you!_ e.g.

<http://www.haskell.org/haskellwiki/Monad_tutorials_timeline>

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

[http://byorgey.wordpress.com/2009/01/12/abstraction- intuitio...](http://byorgey.wordpress.com/2009/01/12/abstraction-intuition- and-the-monad-tutorial-fallacy/)

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

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

</comment></comment><comment><USER14> A monad is like a tiger in a cage. You don't want it running around mauling all your code, so you transport it in cage. If someone needs your tiger for something they need to have the key to his cage. Also it is polite to put the tiger back in the cage if anyone else needs him.

</comment><comment><USER15> I wish I knew Scala, I was too caught up trying to decipher the code to take in the author's point. I have a basic knowledge of monads but unfortunately wasn't able to glean anything further from this article.

<comment><USER16> I found a quick 15 page introduction to Scala and took me about an hour to digest it (of course I didn't dive in very deeply). It gave me a sufficient knowledge to understand the article about monads.

So here it is: <http://www.scala-lang.org/docu/files/ScalaTutorial.pdf>

<comment><USER15> Thanks, that was helpful.

</comment></comment></comment><comment><USER17> I'm trying to parse all of this, but my understanding of Scala is shaky. Could anyone explain this statement -- I think it'd help a lot:

      sealed trait Option[+A] {
        def bind[B](f: A => Option[B]): Option[B]

(My best guess: define a trait named `Option` ... something about an object of type A ... really not sure of the +. Then define a function `bind` that ... something about type `B` ... which takes an argument of type `f`? and returns the argument wrapped in an Option?)

<comment><USER18> define a trait named `Option` <parametrized with another type> A <(think of the List type that can be parametrized with another type, e.g. Booleans)>. The + is there to indicate covarience, i.e. that for a type B that extends A, Option[B] can also be thought of as a subtype of Option[A] (e.g. a list of integers is a subtype of a list of floats).

the Option type defines a method `bind` (I'll come back to the type B) which takes a function f that takes something of type A and returns something of type Option[B], no matter what B is (Scala makes you declare the type parameters you use in a function's arguments in the beginning (after its name)).

I found that explaining bind works best with a more familiar type like List.

if we have a type List of A's, and to simplify further, let's say that A is Int, so we have a List of Ints, then bind is a function that applies its argument, the latter being a function itself, on all its elements, and merging the resulting lists together. Suppose we pass the function `f` that for an Int returns the int itself and its double to the bind function of the following list: [1, 10, 100]

In the first step, the function f is applied to all the list elements: [[1, 2], [10, 20], [100, 200]] Than flattens it so we end up with: [1, 2, 10, 20, 100, 200].

</comment></comment><comment><USER19> It's ok that it takes some time for the idea of the necessity of Monads to spread. I bet it took at least the same time for the Haskell guys to understand the necessity of IO. ;-P

</comment><comment><USER20> Great article. One of the more lucid explanations of Monads... although I do wish a different language was used. As much as people don't like C++, it is probably the simplest language to explain simple OO concepts (at least of the set which are expressible in C++).

<comment><USER21> I strongly disagree. C++'s particularly clumsy static typing introduces a LOT of conceptual baggage. Smalltalk, Scheme, or Self would probably be better, depending on whether you consider prototype-based OO to be a novelty or just the bare essentials.

<comment><USER20> For simple examples, such as those from this article, I don't think you see C++'s type system at all -- except maybe the fact that it doesn't do duck typing (which you also see with Scala).

</comment></comment></comment><comment><USER22> I always liked MenTaLguY's explanation:

<http://bit.ly/fh1F2l>

<comment><USER23> You meant to say [http://moonbase.rydia.net/mental/writings/programming/monads...](http://moonbase.rydia.net/mental/writings/programming/monads- in-ruby/00introduction.html)

</comment></comment><comment><USER24> Historical correction: the monad idea originated with Eugenio Moggi not Philip Wadler.

<comment><USER25> I don't think a correction is necessary, the article just says Wadler 'took advantage of the monad pattern to solve this problem' (the problem of Haskell needing to side-effects eventually to be of any practical use). Implying the monad idea already existed.

<comment><USER24> Right, the monad concept was developed in the 60s. Moggi applied it to computation in the late 80s.

</comment></comment></comment><comment><USER26> A monad is not a metaphor, but a monad is like a simile.</comment>


How do well feel about this? - <AUTHOR> https://twitter.com/villispeaks/status/893330185830899714 <comment><AUTHOR> Villi Iltchev @ August Capital just posted on twitter:

"Over the past year I have had several seed investors tell me "I can't tell you to do this deal. I would not do it."

"They lost me as an investor, but the trust and goodwill they created enormous. You would do anything for people that care about you."</comment>