Phoenix 1.0

I don't find it particularly subjective, it's just what it means. According to what you're saying any language that can be parsed and manipulated by the language is homoiconic, since the AST can be represented by types available in the language, no?

Literal datatype.

And please, prove it to me that "Erlang isn't that". My examples above indicate quite clearly that yes, it is.

> I don't find it particularly subjective,

I was referring to the word "similar" which appeared in the definition of homoiconicity given by flackjap.

> since the AST can be represented by types available in the language, no?

Yes, if the datatypes used in AST representation have literal forms in the language. No otherwise.

Then you must create the login page.

Then the controller for authenticating. And then you need to ensure that the flow works with a test.

Then you need the email that actually activates the account, with the activation hash. So now you're setting up a mailer system, which Phoenix does not have by default.

Then people will want to recover passwords. So you need to write the logic for that. Oh, and the controllers and views. And routes.

And of course, you need to hash the password using some kind of encryption. Excrypt, comeonin, what have you. Choices choices choices.

You'll need a plug to act as the bouncer for your routes too, so nobody gets in where they shouldn't. So you'll have to write that.

You have to end-to-end test this, of course. And probably, if your business depends on it, get a couple other people to review the security of your system.

Simple. And takes a long time.

HTTP is pretty simple, but we use frameworks. SQL is pretty simple too, but we use Ecto now.

It's simple in its pieces, but I really don't wanna do all that work on every app. I'm lazy.

> In computer programming, homoiconicity [...] is a property of some programming languages in which the program structure is similar to its syntax, and therefore the program's internal representation can be inferred by reading the text's layout. If a language is homoiconic, it means that the language text has the same structure as its abstract syntax tree (i.e. the AST and the syntax are isomorphic). This allows all code in the language to be accessed and transformed as data, using the same representation.

As I noted, a similarity is subjective, but I never claimed that it's not needed as a criterion. So, what I claim is that homoiconicity happens when the AST representation consists of only literal datatypes of the language AND the AST structure is "similar" to the original code.

That's it. And also:

> I can represent an AST in array literals in essentially any language

I doubt it, but that's irrelevant. Had you done it you'd essentially reimplement the language of your choice and then we're not talking about that language in general anymore, but about your implementation. What you say here is that "every language can be made homoiconic given appropriate AST implementation". And that's probably true, although I suspect it gets too hard to do in practice for more complex syntaxes.

May I ask where are you getting your strong convictions about homoiconicity from? If you read the Wiki page you'll notice the use of less than precise words, like "similar" or "Languages which are considered homoiconic include" and so on. The concept itself is not as clear-cut as you seem to believe and it's mostly defined by examples.

Also, you still didn't provide a convincing argument that Erlang is not homoiconic; you only claimed that "it isn't" and moved on.

EDIT: as an example of how subjective homoiconicity is take a look at Julia. Listed on the wikipedia as homoiconic, here are the details: http://docs.julialang.org/en/latest/manual/metaprogramming/ - if Julia is homoiconic, then Erlang and Elixir are too. And Haxe, and Dylan. Are they? I don't know, I'm not going to argue about this. As I said, homoiconicity is only interesting as a way of simplifying macro creation; any more discussion is honestly useless to me.