This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-03-13
Channels
- # arachne (2)
- # architecture (23)
- # bangalore-clj (5)
- # beginners (35)
- # boot (79)
- # cider (6)
- # cljs-dev (34)
- # cljsrn (9)
- # clojure (164)
- # clojure-argentina (2)
- # clojure-austin (4)
- # clojure-italy (7)
- # clojure-russia (40)
- # clojure-serbia (1)
- # clojure-spec (76)
- # clojure-uk (36)
- # clojurescript (47)
- # cursive (14)
- # datascript (2)
- # datomic (8)
- # dirac (19)
- # emacs (29)
- # heroku (7)
- # hoplon (35)
- # jobs-rus (1)
- # juxt (2)
- # leiningen (1)
- # lumo (23)
- # mount (4)
- # off-topic (22)
- # om (16)
- # onyx (19)
- # parinfer (10)
- # pedestal (47)
- # proton (5)
- # re-frame (88)
- # rum (1)
- # spacemacs (33)
- # sql (29)
- # uncomplicate (1)
- # unrepl (131)
- # untangled (5)
- # yada (12)
@dpsutton @bozhidar I can't speak for the core team but Java 5 and 6 are still being run in large financial institutions (for example) and the cost of bumping versions and (often manually) retesting legacy systems while they are actively being enhanced with new features is so large they often just pay for extended support. I suspect the core team probably want to keep interoperability with these kinds of enterprises for a little while yet as a way in to large enterprises?
still, the upgrade path for Java is pretty smooth given it’s great track-record of backwards compatibility, so I often wonder why do enterprises operate in this manner
My painfully extensive experience of working with these organisations is a combination of lack of technical oversight of outsourced vendors, a misplaced sense of 'risk' and a complete lack of basic development disciplines such as testing and version control. It's almost unbelievable unless you've seen it yourself.
If an organisation cannot update their JVMs, how on Earth are they going to use Clojure?