PHP.CodeCompared.To/Elm

That is the deepest difference on the page and it is visible in the first row. PHP's whole model is that code executes and pushes bytes at a response; an Elm program describes what should be on screen and hands that description to a runtime. Nothing in the Elm column performs an action, which is why there is no semicolon, no statement, and nowhere for a side effect to hide. The msg in Html msg is a type variable meaning "this markup produces no messages" — it is inert, which is exactly right for a page with no interaction.

So every number reaching the screen goes through String.fromInt or String.fromFloat, and mixing an Int with a Float needs toFloat first — there is no numeric tower quietly promoting one to the other. That is more typing, and it is the same discipline that makes "1" == 1 impossible: PHP's juggling is one mechanism, used for convenience here and producing surprises elsewhere. Note also that ++ is string concatenation, not +, precisely so that adding numbers and joining strings can never be confused.

Two conventions that look like rules and are: definitions at the top level are separated by two blank lines, and the body goes on its own line indented by four spaces. That is elm-format's output, and because virtually every Elm project runs it on save, the community has no style debates at all — there is one layout and a program produces it. Coming from PHP's many possible bracing styles, this takes about a day to stop noticing.

A PHP type declaration is a run-time assertion: the check happens at the call, on the request that made the call, in production if that is where the bad call happens. An Elm annotation is checked by the compiler, so the program containing a bad call cannot be built at all — the commented line above is not a caught error, it is a build failure. That difference compounds: because every call is checked, a change to double's signature immediately lists every place that no longer fits, which is refactoring with a checklist instead of grep. The annotation is also optional — Elm infers every type on its own, and people write signatures as documentation.

It is only a name for a shape — there is no class, no constructor and no methods, and any record with those exact fields is a Person. Two consequences a PHP developer should sit with. Passing a record with a missing field is a compile error naming the field, where $person['nam'] is a warning and null. And the alias doubles as a constructor function: Person "Ada" 36 builds one positionally, which is why you will see aliases used as if they were classes even though nothing was declared.

List a -> Maybe a says: give me a list of anything, and I hand back a Maybe of that same thing. The compiler enforces the connection, so firstItem [ "a" ] is a Maybe String and using it as a number is a build error. Compare the PHP version, whose declared return type has to be omitted entirely — you cannot write T|null in real PHP syntax, only in the comment — so the runtime knows nothing and the annotation is a promise nobody keeps. Note also the return type here: Maybe a rather than T|null, which is the next section.

That difference is not stylistic. ?string in PHP still hands you something you can pass to strtoupper, and the failure arrives later as a deprecation or a TypeError — a null-related error is still one of the commonest bugs in any PHP codebase. Maybe String is not a String, so no function taking a String will accept it and the compiler forces you to deal with the Nothing case before you can use the value at all. This is the single most-cited reason Elm advertises "no runtime exceptions", and it costs exactly what you see: one Maybe.withDefault.

PHP's nullsafe operator ?-> is the same idea for method calls, and it is worth naming the difference: ?-> works only on property and method access on objects, while Maybe.map takes any function at all. The habit worth building is to stay inside the Maybe for as long as possible and unwrap once, at the edge, with withDefault — the equivalent of doing your null check at the point of display rather than threading === null through five functions. Maybe.andThen is the version for a function that itself returns a Maybe, which is where a chain of ?? would otherwise appear.

The comparison worth making is with $ages["Alan"] without the ??. PHP emits a warning and evaluates to null, so the program keeps going with a value that means "there was a bug on the line above" — and in production, where warnings are usually not displayed, it keeps going silently. Dict.get hands back Nothing, which is not an Int, so nothing downstream can accidentally treat it as one. Note that a Dict is for keys you do not know at compile time; when the fields are fixed and known, use a record, which is the next section.

The immediate consequence is that a value never changes under you, so reading a function means reading it once rather than tracing what happened to a variable along the way. The second consequence is that loops disappear: a for needs a counter to increment, so repetition is List.map, List.filter and List.foldl instead. let … in is the local-binding expression, and note that it is an expression — the whole thing has a value, which is what lets it sit inside the text (…) call.

The rule that follows is the one to remember: an Elm if must have an else. There is no such thing as a half-finished conditional, because the expression has to produce a value on every path — and both branches must produce the same type. That closes the hole where a PHP if chain with no else leaves $advice undefined, which is a warning and a null rather than an error. There is no elseif keyword; it is else if, two words, which is just a nested if in the else branch.

That is why there is no return: a function is its expression, so there is nothing to return from and nowhere to return early to. Bindings in a let are not steps; they are names for parts of one expression, and the compiler is free to evaluate them in any order, or not at all if unused. If you find yourself wanting an early return for a validation check, the answer is Maybe or Result and the functions that chain them, which is the Errors section below.

Two adjustments for a PHP eye. The parentheses come back the moment an argument is itself a call — String.fromInt (double 21) needs them, because String.fromInt double 21 would mean passing two arguments to String.fromInt. And the argument order is reversed from what you might expect: the greeting comes first because the data usually comes last, which is the convention that makes currying and the pipe operator work — the next two rows.

So greet "Hello" is a complete, valid expression with type String -> String, and giving a function fewer arguments than it looks like it wants is normal rather than an error. That is what makes sayHello a definition with no parameters at all. PHP's nearest equivalent is the arrow function shown beside it, and the difference is that PHP needs you to write the wrapper while Elm gets it for free from the shape of every function. The practical payoff is in List.map (greet "Hi") names, where the partially applied function is exactly what map wants.

That is the opposite of every other pipe on this site, and it follows directly from currying. List.map String.trim is a partially applied function still waiting for its list, so piping a list into it completes the call — which only works because the list is the last parameter. The whole standard library is ordered that way: List.map f list, String.join separator list, Dict.get key dict. Coming from PHP the practical rule is: put the data last in your own functions too, or your pipelines will not compose.

The update syntax has a property worth noticing: it cannot add a field. { person | nickname = "A" } is a compile error, because the type of person has no such field and a record's field set is fixed by its type. PHP's $older["nickname"] = "A" silently creates one, which is convenient when you meant it and a typo-shaped bug when you did not. The field access person.name is also just a function: .name on its own is a perfectly good function of type { a | name : b } -> b, so List.map .name people works.

This is the same trade every functional language makes, and the concrete effects are worth listing. There is no $this, so a function's inputs are exactly its parameters and nothing is reachable that is not written down. There is no inheritance, so behavior cannot be changed by something further up a hierarchy. And there is no constructor, so there is nowhere to validate on construction — the Elm answer is a function returning Result, in the Errors section, which is more honest than a constructor that can only fail by throwing. What you lose is the convenience of $shape->area() discovering itself in an IDE from the value.

That single restriction is what makes List.sum, List.map and the rest safe with no run-time checks — List.sum takes a List number, so there is no possibility of a string turning up halfway through. When you genuinely need a mixture, the Elm answer is a custom type naming the alternatives, which is the next section, and it forces you to handle each case rather than discovering the mixture at run time. When you need integer keys, you want a List; when you need string keys, a Dict; when you need fixed named fields, a record. PHP's one array covers all three, which is why it never asks you to choose.

Three PHP annoyances vanish on the way. array_map takes the callback first while array_filter takes it second, an inconsistency every PHP developer has looked up; Elm's are uniform. array_values is needed because PHP's filter preserves keys, so removing element 0 leaves an array starting at key 1 that then serializes as a JSON object instead of an array — an Elm List has no keys to preserve. And List.foldl (+) 0 shows an operator used as a function by wrapping it in parentheses, which PHP has no equivalent for at all. Note modBy 2 number rather than %: the argument order is deliberate, so modBy 2 partially applies to "is even".

This is genuinely more awkward than $friends[2] and it is worth saying so rather than presenting it as a feature. What it is, is honest: $friends[9] in PHP is a warning and a null that travels, while the Elm version cannot produce a value that is not there. If you find yourself reaching by index often, that usually means the data wanted to be a record with named fields or a Dict, and reaching for Array from elm/array — which does have Array.get : Int -> Array a -> Maybe a — is the answer when you truly need random access.

That is the same when-not-whether difference as the types section, and it matters most during a change: add a fourth Status and Elm lists every case in the codebase that no longer covers it, before the build finishes. PHP tells you when a request happens to hit one. The larger difference is in the next row — a PHP enum case is a bare label (a backed enum can carry one scalar), while an Elm constructor can carry any data, which is what makes custom types the replacement for a class hierarchy rather than just for constants.

The word doing the work is closed. Nothing outside this file can add a Shape, so case can be checked for completeness and the compiler guarantees area handles every shape that will ever exist. A PHP hierarchy is open by design — anyone can extend Shape, which is the point of inheritance and also why match (true) above needs a default branch it does not have, and will throw when it meets a shape added later. Pick the model to fit: a closed set of variants known in advance is a custom type's home ground, and an open set of implementations is where interfaces belong.

Look at what the PHP version has to do: match on $result[0], then index $result[1] inside each arm, with nothing checking that a "ok" row really carries an integer or that an "error" row carries a string. The Elm version binds value as an Int and reason as a String because the constructor said so. This is also the shape that replaces returning a two-element array to signal success or failure — and Elm has a built-in type for exactly that, which is the next section.

So failure has to be part of the return type, and Result error value is the built-in shape for it: Ok carrying the success or Err carrying the reason. The advantage over an exception is that it cannot be ignored by accident and cannot travel: a PHP InvalidArgumentException unwinds until something catches it, possibly several frames from anywhere with the context to handle it, and nothing in the signature said it might. Result is in the signature, so every caller sees it. Note String.toInt returning a Maybe rather than 0 — PHP's (int) "abc" is 0, which is a valid-looking age.

Compare the two shapes. In PHP each check is an early exit, and reading the function means tracking which exits are still ahead of you. In Elm the pipeline lists the steps in order and the failure path is handled once, at the end, by whoever cares. Result.fromMaybe is the adapter that turns "there was nothing" into "there was nothing, and here is why", which is the everyday job of adding a reason to a Maybe. Result.map is the version for a step that cannot itself fail — the same relationship Maybe.map has to Maybe.andThen.

It means the compiler has eliminated the categories PHP calls TypeError, Error and undefined-anything: no null dereference, no missing method, no wrong argument type, no unhandled case. It does not mean every operation succeeds — it means every operation returns a value of its declared type, and so operations that could fail return Maybe or Result instead of exploding. The odd corner is integer division: 1 // 0 is 0 rather than an error, which is a deliberate choice to keep Int -> Int -> Int total and is the one place where the answer is arguably worse than PHP's DivisionByZeroError. Elm does have Debug.todo, which crashes on purpose; it is a development tool and cannot appear in an optimized build.

Two things follow that a PHP developer will feel immediately. There is no escaping to remember: text produces a text node, so a string containing <script> becomes those characters on screen and cannot become markup — the XSS class that htmlspecialchars and Blade's {{ }} exist to prevent has no way to occur, because a string is never parsed as HTML. And an unclosed tag is not a thing: you are calling functions and building lists, so the structure is well-formed by construction rather than by care. What you give up is the ability to hand a designer a template file.

That is the whole templating story, and it is why Elm has no template syntax to learn. Every tool that works on lists works on markup: List.filter to hide items, List.sortBy to order them, ++ to append a footer row, and a function returning Html msg to factor out a partial. Compare what a Blade partial is — a separate file, included by name, with variables passed through an array and no checking that they are the ones it uses. An Elm "partial" is a function with a type signature, and calling it wrongly does not build.

The cost is real: a decoder is more code than json_decode, and for a three-field record it feels like ceremony. What it buys is that the boundary is the only place a shape can surprise you. In PHP, a server that renames age to years produces null that flows onward and fails somewhere unrelated, at some later request, with a message about the wrong thing. Here the decode fails immediately with Expecting an OBJECT with a field named `age`, and Ok/Err forces you to say what should happen. Once past that boundary, every field is guaranteed present and of the right type for the rest of the program's life.

That is the difference between "this field happened to be missing this time" and "this field is optional". PHP's ?? is written at the point of use, so the same field can be treated as required in one place and optional in another with nothing noticing — and a field that is required but absent looks identical to one that is genuinely optional. Here the type carries the fact everywhere the value goes, so every use has to acknowledge it. Decode.oneOf handles a field that arrives in more than one shape, and Decode.map3 through map8 extend this to bigger records; past that, the community reaches for NoRedInk/elm-json-decode-pipeline.

Read it as the request cycle you already know, with the loop moved into the browser. Msg is the set of possible requests, and it is a closed custom type, so there is no route that does not exist. update is the handler, and its signature Msg -> Model -> Model says it cannot do anything except compute the next state — no database call hidden inside, no session write, nothing. view is the template, and it takes the state as an argument rather than reaching for a global. The $_SESSION superglobal in the PHP column is the honest contrast: it is reachable from anywhere, writable by anything, and its shape is whatever the last handler left in it.

== in Elm only compares two values of the same type, so "1" == 1 is not false — it is a compile error saying the two sides do not match. That removes the entire question. One genuine restriction worth knowing: Elm's == refuses to compare functions, and comparing them is a run-time error rather than a compile one, which is the narrow exception to the no-runtime-exceptions rule. Note also that ++ is the only concatenation operator, so the PHP habit of using + for one thing and . for the other simply has no counterpart to confuse.

Effects still happen, of course — they are expressed as Cmd values that update returns and the runtime performs, so an HTTP request is a value describing a request rather than a call that makes one. The practical consequence for someone maintaining code is large: a function of type Int -> Int cannot have surprised you, so reviewing it means reading it, and testing it needs no mocks, no fixtures and no database. The cost is that a quick error_log inserted to debug something is not available — Debug.log exists for exactly that and is stripped from optimized builds.

When you publish an Elm package, the tooling compares the new public API against the previous release and computes the version bump itself — add a function and it must be a minor release, change a type signature or remove anything and it must be major. You cannot publish 1.0.1 containing a breaking change, because the tool will not let the number be that. Composer, npm and every other registry take the maintainer's word for it, which is why "patch release broke the build" is an ordinary sentence in PHP and an impossible one in Elm. The cost of this and of the purity rules together is a much smaller ecosystem: there are thousands of Elm packages, not hundreds of thousands, and no package can contain arbitrary JavaScript.

This is the restriction most likely to decide whether Elm fits a project, so it is worth stating plainly rather than defending. Using a JavaScript charting library, a payment widget or an analytics SDK means writing the JavaScript side yourself and passing values across, and there is no shortcut. What the restriction buys is the guarantee everything else on this page rests on: because no Elm code can call arbitrary JavaScript, no Elm code can throw, and the compiler's promises hold for the whole program rather than up to the first library. PHP's escape hatches are unlimited and the trade runs exactly the other way.