51–60 of 89 posts
Clojure seems to have replaced the "p"[0] suffix in predicates with "?", the former being an old Lisp convention. Interesting choice, I'm mildly miffed they didn't go with the old convention. [0] http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec...
Earlier quoted context omitted.
It's not just an assemblyism, the near equivalence between 0 and false, and 1 and true is the thing that Boole wrote about for which Boolean values are named. I would argue that it's a math thing, not an assembly thing.
That’s true enough, but in programming languages it’s usually zero=false and any non-zero=true, at least in argument position. That’s more difficult to justify mathematically.
false = 0
true = [1] (i.e. the equivalence class of all n > 0)
&& = +
|| = *
|| / + (or):
0+0 = 0
0+[1] = [1]+0 = [1]
[1]+[1] = [1]
&& / * (and):
0*0 = 0
0*[1] = [1]*0 = 0
[1]*[1] = [1]
so natural numbers (quotiented by an equivalence relation) seem to work as a model for boolean arithmetic. and idk if we need more mathematical justification than "it works fine"
EDIT: changed "integers" to "natural numbers", because
5 + -5 = 0
> if does not have a return value in a language like Java. In other words, it is not an expression, but a statement. Because everything in Clojure is an expression, there is no equivalent construct to Java’s if in it. Anyone know the language design rationale behind the way Java does it? It seems much easier to make everything an expression. Ive always disliked that part of Javascript and being forced to use ternary…
I remember the first time I saw 'constexpr' in C++ I was excited, until I realized it's really conststatement.
The elaborate syntactical decorations of most languages drive away from this, unfortunately.
I’m used to 0 and [] being falsy. Upsides and downsides to Clojure’s choice here?
I'm not sure 0 being falsy is ever a good idea, it's just an assembly-ism that became a C-ism and spread from there. Zero is not a "special enough" value in the ring of integers. In general, these days I prefer as few implicit coercions as possible. In many Lisps, nil is the empty list literal, but interestingly not in Clojure, where it just maps to JVM null, and vectors are the most commonly used data type anyway. H…
> if does not have a return value in a language like Java. In other words, it is not an expression, but a statement. Because everything in Clojure is an expression, there is no equivalent construct to Java’s if in it. Anyone know the language design rationale behind the way Java does it? It seems much easier to make everything an expression. Ive always disliked that part of Javascript and being forced to use ternary…
> Anyone know the language design rationale behind the way Java does it? Because C did it, because Algol did it, because Fortran did it, because that is how assembly code works. Expressions require code to be compiled to something that uses a temporary value stack (or equivalent, like what some continuation-passing style compilers do by allocating values from garbage-collected memory), which, along with subroutines,…
I’m used to 0 and [] being falsy. Upsides and downsides to Clojure’s choice here?
0 does not indicate absence of value. Think of temperature - 0 is a valid temperature and is actually not equal to 0 when converted to Fahrenheit. It becomes incorrect to check presence of temperature by just relying on Boolean coercion, you have to check for not-None(in python) explicitly. Generally the more special values, that are treated as false, you have in a language - the more complex and confusing your progr…
Earlier quoted context omitted.
That’s true enough, but in programming languages it’s usually zero=false and any non-zero=true, at least in argument position. That’s more difficult to justify mathematically.
i haven't checked it thoroughly, but it looks like all the desired properties of boolean arithmetic are preserved when false = 0 true = [1] (i.e. the equivalence class of all n > 0) && = + || = * spelling it out: || / + (or): 0+0 = 0 0+[1] = [1]+0 = [1] [1]+[1] = [1] && / * (and): 0*0 = 0 0*[1] = [1]*0 = 0 [1]*[1] = [1] where [1] stands for "any nonzero number". (please let me know if i missed anything!) so natural n…
Neither does the multiplication `[1]*[1] = [1]`
> if does not have a return value in a language like Java. In other words, it is not an expression, but a statement. Because everything in Clojure is an expression, there is no equivalent construct to Java’s if in it. Anyone know the language design rationale behind the way Java does it? It seems much easier to make everything an expression. Ive always disliked that part of Javascript and being forced to use ternary…
Earlier quoted context omitted.
0 does not indicate absence of value. Think of temperature - 0 is a valid temperature and is actually not equal to 0 when converted to Fahrenheit. It becomes incorrect to check presence of temperature by just relying on Boolean coercion, you have to check for not-None(in python) explicitly. Generally the more special values, that are treated as false, you have in a language - the more complex and confusing your progr…
Nitpick: a actual zero (ie, in Kelvin or Rankine) is not a valid temperature but a lower bound that temperature can't actually reach (like -infinity for real numbers).
Earlier quoted context omitted.
"p" makes sense if you know that it stands for "predicate". It's not nearly as arcane as car and cdr. Also can we finally settle on a name for these things now? If car and cdr are too arcane we can do away with them (though I like being able to do caddadadr) but why do we need "first" and "rest" rather than the already established "head" and "tail"? I particularly dislike "rest" since it's a relative term, i.e. in no…
In Clojure, first and rest apply to sequences, which are a logical list abstraction. They apply to lists, but they can also be used on sequential views of indexed vectors, maps, sets, database result sets, files in a dir, lines in a file, and an open world of "things that can be seen in some order". head and tail I suspect are much more tied to linked lists and data structure than the more plain first and rest.
This allows for unified abstract views on things normally distinguished from each other by words, syntax, conventions and mind. This allows stuff like pattern matching generic functional code like the mighty monad with it's transformer.
Learning functional programming incl. higher kinded types (dependent types and such) isn't easy for someone used to e.g. Java,C,C++,Python,Go, and others I can't judge of the top of my head.
If you ask yourself why said functional is beneficial, remember the popularity and typical confusion of the Monad posts/articles. You might not quite understand / "get" it, but they keep coming up and the authors seem intelligent. So you (might) just have a case of the Blub Paradox[0]. You need to understand it to grok it's usefulness/desirability.