In general, language design requires a balance between first-class vs. second-class objects. First-class objects are important because they let you write the program you want. Second-class objects are also important because they let you write programs that can be reasoned about.<p>For instance, Haskell&#x27;s type language (without compiler-specific extensions) has no beta reduction, because only type constructors can appear not fully applied in type expressions anyway. This reduces its “raw expressive power” (w.r.t. System F-ω, whose type level is the simply typed lambda calculus), but it makes inference decidable, which helps machines help humans. It also helps humans in a more direct fashion: Haskellers often infer a lot about their programs just from their type signatures, that is, <i>without having to compute at all</i>. It&#x27;s no wonder that Haskellers love reasoning with types - it&#x27;s literally less work than reasoning with values.<p>So I agree with you that “first-class everything” isn&#x27;t a good approach to take. A language with first-class everything is a semantic minefield: Nothing is guaranteed, sometimes not even the runtime system&#x27;s stability. (I&#x27;m looking at you, Lisp!)<p>---<p>But, on the specific topic of first-class functions, you&#x27;ll pry them from my cold dead hands. Solving large problems by composing solutions to smaller, more tractable problems, is a style that&#x27;s greatly facilitated by first-class functions, and I&#x27;m not ready to give it up.