How not to use a switch statement
-
That's just retarded.
-
exit();
-
Bonus question straight from the ZCE: is there a difference between
dieandexitand if so what?
-
-
-
die()sounds more deadly?
-
keel_over();
real_keel_over();
-
At this point, this meme is so pervasive we should add it to the wiki.
Or fork php and change nothing besides making the opening tag
<?real_php
-
Err, when was PHP ever functional? I'm not just being snarky.
I guess PHP 5.4 or something has closures. And it has first class functions, apparently. What about purity? Referential transparency?
As much as I like Haskell and even as much as I dislike PHP:
- You can write pure functions in PHP
- You can write referentially transparent code in PHP
There aren't "functional languages" so much as "languages that do a good job of supporting functional programming".
-
No. Most languages have "procedures". Not many have a separate type for functions
You can still write functions in those languages. Those languages just don't have those concepts inherent in them.
-
My point was that functional languages have first class functions, and can distinguish between functions and procedures, so you don't have to.
In particular, this means that you never have to read pure code if you have a bug in impure code (and vice versa). This is different from "procedural" languages, where you cannot know a priori if a statement is a "function" or a "procedure" (just like the compiler can't know, etc).
-
Would you say Clojure has first-class functions? They can be defined anonymously, can be passed around as values, etc.
But the language doesn't statically distinguish between pure functions and impure procedures.
"Statically" is probably the key word here.
-
Yes, you are right on both counts. And Clojure appears to be as functional as C-lisp (i.e., it emphasizes the functional paradigms but is multi-paradigm).
It could be that I've been thinking about functionalism in terms of how Haskell handles it, for too long. I used to be in the "Duh, lisp is functional" camp. But now I see it as multi-paradigm, and see Scheme as just functional.
-
Scheme isn't functional. At least, not in the sense you're suggesting. R7RS puts it quite well:
Scheme is a statically scoped and properly tail recursive dialect of the Lisp programming language invented by Guy Lewis Steele Jr. and Gerald Jay Sussman. It was designed to have exceptionally clear and simple semantics and few different ways to form expressions. A wide variety of programming paradigms, including imperative, functional, and object-oriented styles, find convenient expression in Scheme.
-
I have never quite understood the need for pedantry over classification of languages.
If it does the job, and doesn't get overly in your face in doing it, surely that's the plan?
-
I assumed he was going for one of the pedant badges.
-
Probably. I've resigned myself to never attaining one and I figured most people here had too.
-
I have never quite understood the need for pedantry over classification of languages.
If it does the job, and doesn't get overly in your face in doing it, surely that's the plan?
I think it relates to how the people who like using deeply functional languages (such as Haskell) don't want other less strictly pure languages (according to their definition) cluttering up their thought processes. They've got to distinguish themselves from (the users of) the languages of the plebeian throng. Yet some algorithms are better suited to procedural expression and some to functional expression; the good programmer should know both. (OO is formally independent of the procedural/functional split.)
Ultimately, you've just got programming and the paradigms are really just lazy shortcut thinking… and code is just another kind of data. The reverse of that is that virtually all data could be code too, which is where things become awesome/awful.
-
It might just be "short cut thinking", but laziness has nothing to do with it. The distinction between sequential, imperative code, and pure, stateless code has legs. It certainly has nothing to do with the plebian throng.
In particular, think "command/query separation." If you have a bug in a query, you do not need to read command code to find it. If you have a bug in command code, you do not need to read query code to find it.
Languages that explicitly distinguish between the two lower the amount of mental state you need to maintain to get the job done.
Pure code is easier to write. It's easier to maintain.
And if you really and truly need to write sequential code (because it's easier to express that way), you can. So you win by using the right too for the job, instead of using a single tool for all jobs.
-
Pure code is easier to write. It's easier to maintain.
Provided what you're doing is pure. If the majority of what you're doing is really an impure mess (or the manipulation of the state is the whole raison d'être) the cost of recasting it in terms of pure operations can be quite high. Lots of code does that sort of thing, and a lot more uses stateful operations because that enables more asynchronous processing.
The other big difference is on how strictly things are typed. There, I'll merely point out that the fundamental code/data duality means that you'll never get a perfect type system that allows a program if and only if it is correct; there are necessarily always higher levels of failure (even with complex constructive type ziggurats) as a consequence of Gödelian Incompleteness.
-
If it's an "impure mess" you should be writing it impurely, and tagging it as such, so that you get the actual practical benefit. (Like I said in my last post...)
First, we must purify our program, and we can always factor out impure parts from any code by using free monads. Free monads let you decompose any impure program into a pure representation of its behavior and a minimal impure interpreter:
But it takes a language with the distinction to even do that much. Languages that don't make the distinction require you to understand every line of code, because they all might have a
goto, or reference a global variable, that breaks every reasonable (or otherwise provable) assumption you can make about code, even if it is "pure in spirit" -- i.e., pure code written in an impure language.TBH, I was looking for a two-headed hammer. But the point remains. You can get by in a project by hammering nails in with the side. But the project is easier with both a driving head and a claw.
-
If it's an "impure mess" you should be writing it impurely, and tagging it as such … But it takes a language with the distinction to even do that much.
Quite.a lot [code] more uses stateful operations because that enables more asynchronous processing.
It's perfectly possible to write pure, stateful code; it's usually a lot easier to read and maintain than the imperative, impure alternative.
-
In hindsight, most of this topic is why I feel like TRWTF some of the time. I mean, I'm someone probably legitimately qualified to be called a veteran of good PHP. I wouldn't quite go to 'expert' but you get my drift - and yet I feel rather seriously outclassed in this topic. I know my limits and PHP is mostly where that is
-
This seems like something I'd write while drunk.
-
"It's good to call yourself a beginner, because no one ever started out as an expert."
-
Yes, but that's only any good if you ever move beyond being a beginner. I'm a beginner with lots of experience
-
Oh, you might be up to apprentice or journeyman now. You're aware of the deep nature of suck that can abound, and so you're definitely above noob.
-
"Adventurer"
Just avoid taking any arrows to the knee.
-
Oh, you might be up to apprentice or journeyman now. You're aware of the deep nature of suck that can abound, and so you're definitely above noob.
I levelled up
-
More relevantly, I actually did include this.. just to annoy my boss/see if he noticed :p
You can hammer in nails with the side, sorta.
