"We have things like protected properties. We have abstract methods. We have all this stuff that your computer science teacher told you you should be using. I don't care about this crap at all."
I kinda agree with that sentiment. There's a lot of unnecessary stuff going on in CS. We had extreme OOP and I fear extreme FP will spread into the mainstream. The mission of programming language designers should be to help programmers do their jobs better, not design something elegant/interesting/powerful/expressive/[buzzword]. Those things are all good, but only in the service of programs with fewer bugs and shorter time-to-market.
> The mission of programming language designers should be to help programmers do their jobs better, not design something elegant/interesting/powerful/expressive/[buzzword]. Those things are all good, but only in the service of programs with fewer bugs and shorter time-to-market.
That may be true for programming language designers, but I'm afraid you misunderstand what CS is all about. Hint: it's not about time-to-market. The job of CS is to explore the theory -- precisely how to do something in interesting/elegant/expressive ways. Its job is to explore the theoretical and practical underpinnings of computing; to provide proofs; to explore the abstract and formal systems behind software. CS is not necessarily directly applicable to enterprise software (though of course CS research does have practical applications; and of course there is overlap between theoretical and practical computing).
A lot of cognitive dissonance comes from people who look at CS thinking it's what they need in order to write software.
This is ridiculous. I think you are seriously missing the point of PL research. Furthermore, I can not even imagine what your definition of "helpful" is when you say not ".../powerful/expressive/...". I honestly can't even argue with you if you do not think power or expressivity is beneficial.
PL is not a buzzword-oriented culture. No (serious?) language designer creates a language with the intent of making it harder for programmers to do their jobs. (Brainfuck and other Turing traps excluded.) That said, being "helpful" can be interpreted in many different ways. And of course, every PL designer does interpret it differently!
OOP took off because it was a revolutionary way of structuring your code so it could be easily used, reused, and maintained. The point was to help teams be more efficient!
Functional Programming is so worthwhile first off due to immutable types. This allows highly parallelizable code. You don't have to worry about race conditions because your objects are read-only! The emphasis on types also allows better ability to prove correctness of a program before run-time. Finally, all FP languages (that I can think of) are highly expressive. This means that you can write the same program in (OCaml, Haskell, CL, Clojure) in a shorter amount of time than you could in Java/C#/Obj-C.
If you still think there is "a lot of unnecessary stuff going on in CS", I'd really like to hear what you think is necessary and we'll go from there. I already discussed your "fewer bugs and shorter time-to-market" points.
> I kinda agree with that sentiment. There's a lot of unnecessary stuff going on in CS. We had extreme OOP and I fear extreme FP will spread into the mainstream. The mission of programming language designers should be to help programmers do their jobs better, not design something elegant/interesting/powerful/expressive/[buzzword]. Those things are all good, but only in the service of programs with fewer bugs and shorter time-to-market.
I'm not sure where you're going with that. I have stared at enough medium- to large-sized codebases to realize that an excellent way to "fewer bugs" is to protect programmers against themselves and restrict their proven ability to shoot themselves in the foot (especially in the absence of code review and/or competent technical leads). Shorter time-to-market is actually a different property. PHP or Rails got popular because they make it easy to crank out a web application in a relatively small amount of code. However, this often doesn't translate into "fewer bugs" when the codebase gets big.
I don't know what "extreme FP" mean, but there is a night and day difference working with referential transparency and immutable data structures in terms of cognitive load and ability to change parts of the system with confidence (for the record, I'm also mystified about "extreme OOP").
I kinda agree with that sentiment. There's a lot of unnecessary stuff going on in CS. We had extreme OOP and I fear extreme FP will spread into the mainstream. The mission of programming language designers should be to help programmers do their jobs better, not design something elegant/interesting/powerful/expressive/[buzzword]. Those things are all good, but only in the service of programs with fewer bugs and shorter time-to-market.