cgi vs php vs js

which one is the best?

css

Haskell.

one of these things is not like the other

Rails.

node.js, cgi otherwise

http://www.coboloncogs.org/HOME.HTM

>>3
Haskell
- Just like C++, Haskell is very hard to learn, and takes years to master. Things like Monads, Functors, Monoids, Higher-Order Types and a myriad of morphisms are hard to understand, especially without mathematical background. So most programmers probably don't have the ability or will to learn Haskell. Learning Haskell's syntax, libraries, functional programming techniques won't bring you closer to understanding: the true path to understand Haskell lies through Monoid-Functor-Applicative-Arrow-Monad. And even if you mange to learn Haskell, programming it still hogs a lot of brain resources, which could have been put to something more useful than just showing off about how clever you can be. "Haskell for Kids" even proposes exposing children to Haskell from yearly age, meaning Haskell, similar to mathematics and natural language, will be much harder to grasp at older age. "Zygohistomorphic prepromorphism: Zygo implements semi-mutual recursion like a zygomorphism. Para gives you access to your result à la paramorphism." -- HaskellWiki
- Poor backward compatibility: haskellers "don't want to replicate Java, which is outright flawed in order to avoid even the most unlikely of broken code". Meaning, they don't care if new version of GHC will break your code. Haskell projects are struggling under the weight of "DLL hell": typical Haskell package consist of just a few lines of code, thus many other projects depend on dozens of different packages, either directly or indirectly. It's near-impossible to embark on a serious Haskell project without spending time fighting dependency version issues.
- Haskell is slow and leaks memory. GHC's inefficient stop-the-world GC does not scale. A good understanding of evaluation order is very important for writing practical programs. People using Haskell often have no idea how evaluation affects the efficiency. It is no coincidence that Haskell programmers end up floundering around with space leaks that they do not understand. "The next Haskell will be strict." -- Simon Peyton-Jones
- Haskell's API lacks higher levels of abstraction, due to absence of variadic functions, optional arguments and keywords. Macros aren't possible either, due to overly complex syntax of Haskell. API documentation is very lacking: if you want to use regexes, you start at Text.Regex.Posix, seeing that =~ and =~~ are the high level API, and the hyperlinks for those functions go to Text.Regex.Posix.Wrap, where the main functions are not actually documented at all, so you look at the type signatures, trying to understand them and they are rather intimidating (class RegexOptions regex compOpt execOpt => RegexMaker regex compOpt execOpt source | regex -> compOpt execOpt, compOpt -> regex execOpt, execOpt -> regex compOpt where). They are using multi-parameter type classes and functional dependencies. The signature really wont give you any clue to how to actually use this API, which is a science in itself. Haskell is a language where memoization is a PhD-level topic.
- Haskell programming relies on mathematical modelling with type system (a version of mathematical Set Theory). If one does not use the type system for anything useful, it obviously will be nothing but a burden. Programs are limited by the expressiveness of the type system of the language - e.g. heterogeneous data structures aren't possible w/o reinventing explicit tagging. All that makes Haskell bad for prototyping or anything new, due to need of having design document with all types beforehand, which changes often during prototyping. Any complex project have to reinvent dynamic typing. For instance, Grempa uses dynamic typing because the semantic action functions are put in an array indexing rule and production numbers (Ints) to functions, and they all have different types and so can not be put in an ordinary array expecting the same type for each element.
- The IDE options cannot be as good as those of dynamic programming languages, due to absence of run-time information and access to running program's state. Haskell's necrophilia forces you to work with "dead" code. Like other static languages, Haskell isn't well-known for its "reload on the fly" productivity. No eval or self-modifying code. Haskell code can't be changed without recompiling half of application and restarting the process. GHCI - is the best Haskell's interactivity can get, and still wont allow you to change types during runtime, while the single assignment semantics prevents redefinition of functions. As said Simon Peyton-Jones, "In the end, any program must manipulate state. A program that has no side effects whatsoever is a kind of black box. All you can tell is that the box gets hotter."
- Type system produced compile-time and link-time errors are distracting and make it harder to run and test your code, while type-checking isn't a substitute for testing, it is about correspondence to mathematical model, which has nothing to do with correctness - i.e. two numbers can be integers, but their quotient can still result into division by zero. Even though you may hear strong static-typing advocates say, "When your program type-checks, you'll often find that it just works", this is simply not true for large, intricate programs. Although type-checking may help you find model-related errors, it is not the same as testing.
- Absence of dynamic scope, implicit open recursion, late binding, and duck typing severely limits Haskell, since there are things that can't be done easily without these features: you can't implement dynamic scope in general (and be type-safe) without converting your entire program to use tagged values. So in this respect, Haskell is inferior to dynamic typing languages.
- Haskell makes it easy to write cryptic programs that no-one understands, not even yourself a few days later. Rich, baroque syntax, lazy evaluation and a tradition defining an operator for every function - all help obfuscation a lot. As a general rule, Haskell syntax is incredibly impenetrable: who in their right mind thought up the operators named .&., <|> and >>=?

>>8
Haskell is very hard to learn, and takes years to master.
It took one afternoon for me to learn, one week to ``master''.
Stopped reading right there.

>>9
"Learning Haskell's syntax, libraries, functional programming techniques won't bring you closer to understanding"

>>10
My Haskell mastering included the what, how and whys of Prelude (the standard library) including functors, applicative functors, arrows, categories, monads and monoids, its type system and extensions such as higher-kinds, n-rank types and existential types. I did it in my spare time, too, it all just made sense, and was so simple it isn't even funny to say it's hard.

>>11
Also, I knew nothing of set theory, category theory, abstract algebra and type theory, and Haskell was my first purely functional programming language.

>>11>>12
http://en.wikipedia.org/wiki/Anecdotal_evidence

CGI with the JVM

>>12
>>11
>>10
your first reply was to a copy pasta. but i'm not interested in that

i am too learning haskell, would you mind post some meta-tutorial? (how to proceed to learn the language)

>>15
It's since the first time the ``in Lisp'' guy posted it that I wanted to reply to that kopipe. It's just like him, retarded and wrong.

They say learn you a haskell is a good starting point. I don't know many tutorials for Haskell, I learned mostly by doing and reading source code.
I can tell you what to not do: don't read monad tutorials. They are not boxes, pipelines, about IO, about state, about sequencing, ducks, burritos, spaceships. Monads are anything that has two operations, bind and return, that respect certain rules, just like a sequence is anything with a first, rest and cons operation and that, i.e., respect that cons(first(seq),rest(seq)) == seq.

>>15
i am too learning haskell, would you mind post some meta-tutorial? (how to proceed to learn the language)
It goes like that: you're studying "Real World Haskell", the chapter about some prepromorphisms, and then something in your head goes "click" and suddenly you realise how ridiculous this static typing is, and your last thoughts abruptly sink into pure laugh caused by a sheer idiocy of Haskell World.

>>16
Monads are...
monad is a monoid in the category of endofunctors.

>>16
I can tell you what to not do: don't read monad tutorials.
Good advice. I would read the relevant chapters in RWH (10, 14 and 15, I believe) and then look at the implementation of the State and [] monads. https://github.com/kosmikus/LambdaHack/blob/master/src/Action.hs is also good reading, but you should understand the basics of continuation passing style first.

>>18
A monoid is...
    * A set, S
    * An operation, • : S × S -> S
    * An element of S, e : 1 -> S

...satisfying these laws:
    * (a • b) • c = a • (b • c), for all a, b and c in S
    * e • a = a = a • e, for all a in S

A monad is...
    * An endofunctor, T : X -> X
    * A natural transformation, μ : T × T -> T, where × means functor composition
    * A natural transformation, η : I -> T, where I is the identity endofunctor on X

...satisfying these laws:
    * μ(μ(T × T) × T)) = μ(T × μ(T × T))
    * μ(η(T)) = T = μ(T(η))

>>20
the basic idea is that an element of S × T is a pair (s, t), where s ∈ S and t ∈ T.

>>20
"set" is some object in some category, and the operations are morphism not necessarily defined in terms of elements. And in this particular case it is the category of endofunctors where the product of two objects (where objects are functors) is instead of being the cartesian product it is the composition of the functors

Monad is just one of typeclasses. And a typeclass is some abstract entity, which allows concrete types to use some functions. And the nature of these functions depends on a typeclass of a concrete type, and how these functions implemented for a concrete type depends on the embodiment of the typeclass of that type. For example, monad Maybe is a type, computations, embedded into a monad of which, return either result, embedded into one of its data constructors, or a second data constructor - Nothing. Naturally, abstract types are often implemented in terms of type-class constrained polytypes and extraction functions from/to the abstract type families of polymorphic functions to/from some concrete type. However, the definitional structure of an abstract type uses interface operators and, therefore, is not affected by changes of representation. which may be logically hidden and, sometimes, even physically unavailable.

I found learning Haskell hard. Let me put it in perspective: I'm 39. I've been programming since I was 11. I've been writing recursive code since about 15 and I've been using whatever approximations to functional programming are avalable to me in any language I use for almost that long (including torturing myself with C++ template metaprogramming). I've even implemented a couple of declarative languages, Prolog and SASL, the latter being a functional lazy language a lot like Haskell that I thought I'd investigate before Haskell. And I still found Haskell tricky to learn.