[HN Gopher] OCaml is 25
___________________________________________________________________
OCaml is 25
Author : fortran77
Score : 189 points
Date : 2021-05-09 13:57 UTC (9 hours ago)
(HTM) web link (discuss.ocaml.org)
(TXT) w3m dump (discuss.ocaml.org)
| adenozine wrote:
| Biggest thing impeding Ocaml for the average developer is the
| situation with the Stdlib, and multicore.
|
| It's not exactly a struggle to get Base or Core working, but it's
| way less streamlined than it really ought to be. I see things
| like F# picking up some popularity and it strikes me as a bit of
| a tragedy on Ocaml's part. .NET is pretty bad to work with, imo.
| I know C# people will hate that, and indeed if I was meaning C#
| then they'd be right to feel that way. The fact is, there are few
| FP languages with a deep platform (like JVM, .NET, js/browser)
| already, and even fewer pleasant enough to work with on a daily
| basis.
|
| I've been blessed to use Ocaml for some of my statistics work,
| and I'm watching very close the OWL project (ocaml.xyz), and
| hopefully it will come together nicely.
|
| Still, I see the quickstart process of F#, Scala, Clojure,
| Elixir, even Haskell, and it's just much less headache than Ocaml
| for the first 10-15 minutes.
|
| Ultimately, I don't know. I use Python a LOT, and I REALLY enjoy
| it. A lot of what people don't like about Python just doesn't get
| in my way that much. Really the only thing that I could see
| myself yearning for in the language is pattern-matching (which
| we're getting soon) and some form of piping with better lambda
| support. I really miss |>, <| in the way I build my tools, but in
| the end I get along just fine.
|
| I'm glad that SO many languages have taken inspiration from
| Ocaml, and I'm sure that as time goes on, many more still will
| draw water from the plentiful well of its beautiful type
| inference, compiler architecture, domain modeling capabilities
| without annotations, et al.
|
| Finally, I think it remiss to sorta colloquialize projects by a
| sum of their most recent decisions. It's not difficult to look
| around and go "Man, ReScript is sort of a shit-show, ReasonML
| doesn't really offer _anything_ except different syntax at this
| point, and there 's typescript anyhow, which has a vastly
| superior dev experience in just about every modern code editor."
| But that doesn't do justice to how incredibly epic it is that a
| project is still alive and competitive at a deep, academic level,
| across continents, for 25 years. I could munge around my emails
| and find projects starting near me that are using things like Coq
| (now called something else, I think), it's very much still alive
| for important technical work even throughout the Numpy-pocalypse.
|
| Anyhow, this comment is a mess. Congratulations Ocaml team. Keep
| on truckin'. <3
| adsharma wrote:
| Python's pattern matching is not the same as Ocaml's. It's a
| statement, not an expression. But I like your line of thinking.
| Create a variant of python with ML like features without
| sacrificing compatibility too much.
|
| An effort in this direction is a transpiler I'm working on. So
| far it sticks to a strict subset of python3. But I'm open to
| incorporating ML like features in an incompatible way if there
| is a compelling argument.
|
| By sticking to a statically typed subset we've already given up
| some compatibility.
| adenozine wrote:
| I mean, obviously you're right. I guess I just meant that
| it's good enough for what I'm doing in Python. People don't
| write verified provers for deep numerical projects in Python,
| they'd use Ocaml. For digging through a little sqlite
| collection, parsing through csv files and correlating a few
| simple features in dataframes, python works fine and the
| pattern matching that we'll be getting will make it easier to
| write THAT sort of code.
|
| I don't see Python growing very much more functionally.
| There's two decades of resisting FP with much vigor, and I
| expect another two decades of fighting about what little FP
| has grown into Python thus far.
|
| I'd love to see your transpiler work! It sounds pretty cool.
|
| I keep an eye on mys-lang (@github/mys-lang/mys) and mypyc,
| to see what's going on in that realm of Python.
|
| Compatibility is a double-edged sword, as I'm sure you
| realize.
| nickmain wrote:
| If you want to use OCaml-like GADTs and pattern matching in
| Python then there is the Haxe -> Python route.
|
| The Haxe compiler is actually written in OCaml and its type
| system is influenced by it.
| baby wrote:
| As a newcomer it's a fantastic language but the tooling and the
| ecosystem story is really lacking. I really think the language
| needs more hype in order to get more people to do things for
| it. The versioning story of dependencies is almost inexistant,
| the interaction between the package manager (opam) and buil
| tool (dune) is filled with issues, there are no conventions in
| the way you set up a project (you can put your files in any
| folder), stdlib vs base? Poor documentation, poor compiler
| errors, poor managements for patches (opam pin) and different
| versions of the compiler (opam switch creates a local repo in
| all your projects), etc.
|
| Coincidentally I've been writing up an OCamlbyexample page that
| hopefully I can post here at some point to motivate people to
| learn the language:)
| rwmj wrote:
| I'm an actual OCaml programmer, almost daily, and I don't
| understand this objection. We use autotools and make as the
| build tool (but you could use ninja/meson, cmake or
| whatever), and don't bother with opam/dune. We properly
| package over 100 OCaml packages in Fedora. For anything else
| not covered by a package we mostly call into C libraries,
| which is very easy to do from OCaml.
|
| I guess it depends on exactly what you're trying to do, but
| we've developed a large amount of complex software in OCaml
| this way.
| jolux wrote:
| You roll your own build system instead of using the built-
| in tools and you don't understand why people wouldn't want
| to do that? This isn't a typical situation in Rust or even
| Haskell these days. Come on.
|
| Rarely are people arguing that a situation like this makes
| writing software _impossible_. The question is whether it
| adds friction, and in adding friction impedes adoption. I
| think it clearly does, and that tooling is one of the
| highest-impact features a language can prioritize to
| improve adoption. If the story for building and packaging
| OCaml software is "go make yourself proficient in the C
| build tooling ecosystem first," of course that makes it
| harder to adopt (and you're not the first person in the
| community to give this answer, either). This hostility to
| beginners is one of the major things that irks me about the
| OCaml community, and OCaml is probably my favorite
| language.
| rixed wrote:
| Is it "being hostile to beginners" to encourage them to
| learn simple universal tools to build any software in any
| environment?
|
| When i was a beginner, trying a new language was actually
| easier: you just installed a compiler. Now you need a
| "platform", for some even a special dedicated machine.
|
| I wonder who is benefiting this sillo-ing, but I doubt
| that's the beginners.
| jolux wrote:
| I'm not talking about beginning programmers, I'm talking
| about people who are new to your language community. You
| can still just install and use ocamlc/ocamlopt, or rustc,
| or ghc, but the bar has been raised. People picking up a
| new language today for production use expect it to have a
| cohesive story for builds, packaging, tooling, and
| testing out of the box.
|
| >I wonder who is benefiting this sillo-ing, but I doubt
| that's the beginners.
|
| Everyone benefits from the better tooling we have now.
| The siloing is a problem that still has not seen a
| satisfactory solution. Regression in user experience is
| not acceptable.
| rwmj wrote:
| These language-specific toolchains are often not better.
| They're complex, opaque, stuff things in places in my
| home directory, don't work together, and don't work with
| system packages -- golang is actively hostile to being
| properly packaged, making it difficult to keep track of
| what's installed and security updates.
| rwmj wrote:
| We have 6 lines of code that we copy and paste around
| projects:
|
| https://github.com/libguestfs/libguestfs/blob/d01ce082180
| c41...
|
| Now if you're saying that the autotools/make/cmake/meson
| tooling is hard, I sort of agree, but many people are
| familiar with C build tools already. I don't see how it's
| easier or harder than learning language-specific tools.
| jolux wrote:
| >Now if you're saying that the autotools/make/cmake/meson
| tooling is hard, I sort of agree
|
| That's not really the main problem to me but it is a
| problem.
|
| >many people are familiar with C build tools already
|
| Maybe if they're C++ programmers. I don't know anyone
| outside of the C++ community who has ever used anything
| aside from Makefiles and language-specific tooling.
|
| >I don't see how it's easier or harder than learning
| language-specific tools.
|
| The language-specific tools are typically very well
| integrated with the default testing, packaging, and
| editor tools ecosystem. The C build tools are not going
| to be, at least not for OCaml. Language-specific tools
| show users the best experience a language can offer. More
| advanced users can always choose to use something else,
| but the advantages of the whole community using the same
| tool are hard to beat as well.
| rwmj wrote:
| I guess we know different developers. I work with Linux /
| C programmers, and everyone is familiar with the basic C
| build tools. C tools also deal with testing, and there's
| a very clear and well-travelled path from ./configure &&
| make && make check && make DESTDIR=.. install to RPMs and
| Debian packaging.
| jolux wrote:
| That's the process for building and installing packages
| though. I'm talking about writing new ones, on a system
| with nothing else installed.
|
| I'm omnivorous but I get paid for web development and
| that's what most people I know are most interested in.
| And like I said, they understand Makefiles and make, but
| autotools and Meson are not "basic C build tools,"
| they're both extremely complex and relatively niche. I'm
| not saying you shouldn't use the tools you use, but you
| should understand that they are not popular or well-
| understood outside of your niche of Linux programming
| with C. I'm sure these programmers could learn how to use
| them, but most are going to choose not to if it's the
| easiest way to use the language. They will pick something
| else.
| dhconnelly wrote:
| I've done a few small projects in OCaml. It's a brilliant
| language that I deeply enjoy using. But the situation for
| newcomers and those who don't have established patterns is
| bad. It's hard to do anything nontrivial from scratch, and
| the community doesn't seem to have any consensus around
| dependency management, builds, project structure, and so
| on. Make and autotools may work for you, but it's not like
| your setup is on the ocaml.org homepage, reproducible by an
| application developer in five lines of shell commands.
|
| It's common now in some language ecosystems for the default
| tooling to just generate all this stuff for you, and you
| move on to writing code. So if you're e.g. a JavaScript
| developer who is interested in functional programming, and
| you're used to npm or whatever, it's a difficult start.
| yawaramin wrote:
| > the community doesn't seem to have any consensus around
| dependency management, builds, project structure, and so
| on.
|
| Yes, it does.
|
| - Dependency management: opam
|
| - Builds: dune
|
| - Project structure: dictated by dune
|
| - and so on: more details at https://ocaml.org/platform/
| dhconnelly wrote:
| The commenter I'm replying to uses an entirely different
| toolchain, and the frequently-recommended Cornell book (h
| ttps://www.cs.cornell.edu/courses/cs3110/2021sp/textbook/
| ) uses ocamlbuild and utop and makes no mention of Dune.
| If you (understandably) happen to land in the official
| OCaml manual at https://ocaml.org/manual/index.html
| instead of the page you linked to (which I can't find
| from ocaml.org, by the way, but you're right that the
| ocaml.org tutorials do mention Dune and opam), then you
| don't see Dune or opam mentioned at all. I get what
| you're saying, but I don't think you could disagree with
| the premise that there are parts of the OCaml ecosystem
| that a newbie would land in and be confused or misled by
| here.
| yawaramin wrote:
| That's fine, but if you go to https://ocaml.org/ and
| click the big 'Install OCaml' CTA at the top of the page,
| it takes you through installing opam, dune, and ocaml-
| lsp-server. And as per the latest OCaml Survey, it looks
| like the majority of the community are using opam and
| dune: https://docs.google.com/forms/d/1OZV7WCprDnouU-
| rIEuw-1lDTeXr...
|
| Do some of the doc pages need to be updated? Yes. Do some
| universities take a long time to update their course
| materials? Yes. Does this mean there's no conensus? No.
| jolux wrote:
| There appears to be a rough consensus but it seems to
| have emerged relatively recently. I learned OCaml about
| two or three years ago and at the time the best tooling
| was Tuareg and Merlin in Emacs. Fortunately for me I love
| Emacs, but I found the Dune documentation poor and
| overall I got the sense that the OCaml production
| ecosystem (vs academic) is largely dictated by Jane
| Street these days, but the community is kind of quiet
| about the extent to which Core is the "real" standard
| library and the default stdlib is an academic curiosity.
| For one thing, the community seemed to be in a transition
| period between ocamlbuild and Dune, as the official
| resources recommended ocamlbuild and the community said
| everyone uses dune.
|
| Good to hear this is changing, though.
| yawaramin wrote:
| Yes, this is changing, and these changes have been
| ongoing since about 2013 when opam was created. But it's
| true that they're accelerating. I think it's reaching
| critical mass. so yes a few years ago I would say your
| points would be valid, but today they are less so.
| dhconnelly wrote:
| Okay, so there is consensus. I guess I was confused.
| Seems like quite a few people here are confused, though.
| Seems worth considering!
| octachron wrote:
| Dune itself is only few years old. And there has been
| quite a lot of work on consolidating ocaml.org as a clear
| entry point for newcomers. But that is still an on-going
| work.
| nicoburns wrote:
| The C-ecosystem build tools you refer to are pretty far
| behind those of pretty much every other langauge. And most
| developers don't want to wait for their OS to package it to
| start using the new version of a library (not to mention
| this style of packaging isn't typically available on
| windows/macos).
| yawaramin wrote:
| In case you don't know, OCaml Platform recommended
| tooling is on par with or better than that of many other
| languages. Check out
| https://news.ycombinator.com/item?id=27099050
| yawaramin wrote:
| > there are no conventions in the way you set up a project
| (you can put your files in any folder)
|
| Dune enforces fairly strong conventions in project layout.
|
| Agree with a lot of your comment though.
| baby wrote:
| Really? You can put your opam package files and dune files
| wherever you want and it'll automagically work. Submodules
| can be defined far away from the library and it's fine. If
| your opam packages are empty it's fine, dune doesn't care
| about versions of packages anyway. If you want to
| vendor/patch a library, just drop it anywhere in your
| project. Yet dune seems to be unaware or executables and
| libraries when you want to run or build something (you need
| to pass paths).
| yawaramin wrote:
| That's mostly because dune is 'composeable' so it accepts
| project components anywhere in the tree. But the
| components themselves are laid out in a certain way:
|
| - A dune file in a specific directory makes that
| directory a component
|
| - An .ml file in the directory with the same name as the
| component (in the dune file) becomes the main module of
| the component
|
| - Any submodules aliased inside the main module are
| properly wrapped and namespaced.
| baby wrote:
| Sure, but Cargo and go modules/vendors are composable too
| but there's still a forced convention that doesn't allow
| you to place your files wherever you want.
| fishmaster wrote:
| There's also the issue with the non-existent unicode support.
| octachron wrote:
| OCaml's decision is more to leave unicode support to
| libraries rather than let compiler writers handle unicode
| support as a side dish.
| rwmj wrote:
| Compared to my experience with Python 3 and Ruby, OCaml is so
| much better. On the rare occasions I need to do something
| Unicode-y, I'll reach for Camomile, and the rest of the time
| I'm passing around strings/bytes unimpeded by silly language
| decisions.
| yawaramin wrote:
| IMHO, OCaml's decision to not encode strings in a Unicode
| encoding by default is the correct one. OCaml treats strings
| as just bytestrings, leaving the programmer to take care of
| the specific encoding, with the help of sophisticated and
| powerful libraries like Camomile.
|
| For an example of what happens when language implementations
| try to shoehorn in Unicode into their strings, look at
| JavaScript's UTF-16 strings or this Python example: https://w
| ww.reddit.com/r/programming/comments/asi2qo/go_is_a...
| legobmw99 wrote:
| The history of programming languages is one of my personal
| interest fields, and I find it fascinating how, 25 years on, many
| of the most popular languages are still slowly encorporating core
| features of functional languages like OCaml: records, enumerated
| (sum or variant) types, pattern matching and destructuring, true
| tail calls, type inference.
|
| To be clear, I'm in favor of these changes, and I don't denigrate
| any existing language for not having them, I just still marvel
| seeing HN headlines like "Python to get match statement", "Record
| Types in Java", "Tail Call support in Rust" and appreciate all
| the more the things OCaml (and before it, ML) have gotten right
| for so long.
| okareaman wrote:
| I'm not trying to be oppositional or take anything away from
| what you said about OCaml, but I'm interested in the evolution
| of programming languages and watching how the best ideas are
| borrowed or stolen and incorporated into new languages,
| sometimes with additions that improve upon the original. That's
| why I always check out new languages that are posted on HN. I
| like to see if the author has a new idea and then which
| language picks up on it. It's interesting to ponder such things
| as what will be the C++ response to Rust?
| O_H_E wrote:
| The only consistent resource I know about this is wikipedia's
| "influenced [by]" section and the references in there.
| sprobertson wrote:
| Any favorites you've picked out from some of the new or
| lesser known languages?
| okareaman wrote:
| While not a lesser know language, the evolution of
| await/async from Haskell to C# to Dart by Meijer is a good
| example that comes to mind. I'm a working programmer
| without a college degree, so I can't vouch that I have the
| correct interpretation of the computer science. See
| "Confessions of a Used Programming Language Salesman -
| Getting the Masses Hooked on Haskell' by Erik Meijer
|
| http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.72
| ....
| pjmlp wrote:
| A couple of examples,
|
| https://devblogs.microsoft.com/cppblog/finding-bugs-with-
| add...
|
| https://devblogs.microsoft.com/cppblog/static-analysis-
| fixes...
|
| https://devblogs.microsoft.com/cppblog/address-sanitizer-
| for...
|
| https://docs.microsoft.com/en-us/cpp/c-runtime-
| library/sal-a...
|
| https://developers.redhat.com/blog/2021/01/28/static-
| analysi...
|
| https://vcpkg.io/en/index.html
|
| https://conan.io/
| simias wrote:
| Keep in mind that a language like Rust would've been
| effectively unusable in its current form 25 years ago due to
| the RAM and CPU requirements by the compiler.
|
| As CPU and RAM increases you can make smarter compilers and
| generalize things like type inference, bigger compilation units
| and higher level constructs that rely heavily on compiler
| optimization for good performance.
|
| Many people think that Rust and C++ are too slow to compile
| _today_ , imagine what it would've looked like on a Pentium II
| CPU with 128MiB of RAM!
| fortran77 wrote:
| I was using C++ 25 years ago! Worked fine.
| est31 wrote:
| 25 years ago it wasn't C++11, but C with classes. Less TMP
| noise, small compilation units instead of the source code
| of entire libraries being #include'd.
| pjmlp wrote:
| I guess you never used ATL, OWL, VCL, CSet++.
| est31 wrote:
| No. I was born in the 90s. in the 2000s I was mostly
| doing .Net and Java, started doing C++ seriously in 2010s
| until I discovered Rust. Have I got the C++ history
| wrong?
| jolux wrote:
| Templates have been in C++ for a very long time, like 30
| years iirc. I am not a big C++ gal but I'm pretty sure
| TMP long predates C++11.
| est31 wrote:
| TMP is older than C++11 yes, but the trend to use it so
| extremely is new I think. Or maybe I got that wrong, idk.
| galangalalgol wrote:
| I was using both templates and the stl heavily in 2002. I
| started learning c++ in 94 or 95 can't remember. Turbo
| c++ did not have templates, before the 98 standard it
| mostly was c with classes. And lots of unnecessary
| inheritance and overloading.
|
| Edit, should include that the experience in 2002 was on a
| corporate project which ultimately had many millions of
| lines of code, so not just some crazy guy in a basement.
| Lots of crazy people were in the basement with me.
| est31 wrote:
| Alright, thanks for that anecdote. I was wrong about that
| then.
| pjmlp wrote:
| Here for you,
|
| https://docs.microsoft.com/en-us/cpp/atl/active-template-
| lib...
|
| In 2000 it was version 3.0 alongside Visual C++ 6.0.
| [deleted]
| fortran77 wrote:
| Leave the hard stuff to us C++ old-timers!
| est31 wrote:
| > Stick to Rust and leave the hard stuff to us C++ old-
| timers!
|
| Excuse me?
| mousepilot wrote:
| lol or MFC, I checked that out and subsequently pulled
| the power plug on my pc. Granted I'm probably not a very
| good programmer. heck my comment is probably not even on
| topic in this thread.
| fortran77 wrote:
| This is completely, 100% wrong.
|
| 25 years ago on was on the Adobe Photoshop team, happily
| programming in C++. We had templates, smart pointers, and
| the STL.
|
| And the people at Taligent were all about C++, around the
| same timeframe.
| simias wrote:
| Sure, but the language was smaller back then (not small,
| mind you, but smaller). Boost was only created in 1999
| after all!
|
| Also, people have been complaining about C++ compile time
| for as long as I can remember, so I don't think it
| necessarily invalidates my point.
| rwmj wrote:
| C++ 25 years ago (1996) was terrible. I used to have to
| keep a large C++ application going on GCC, Sun's compiler
| and Microsoft's compiler and it was a nightmare. Using
| templates with classes would invariably cause one or other
| of the compilers to crash, so we had to concentrate on the
| simplest subset of the language that worked. STL was very
| new and not supported on all platforms so we ended up
| reimplementing a lot of that in our own classes. Build
| times were glacial and the resulting binaries were
| enormous. Multiple string types. And horrific things like
| CORBA's C++ bindings ...
| nestorD wrote:
| > I find it fascinating how, 25 years on, many of the most
| popular languages are still slowly encorporating core features
| of functional languages like OCaml
|
| Yes! Ocaml was my first programming language and I have been
| baffled at how languages I learned subsequently tended to miss
| what I considered basic utilities like proper pattern matching
| and tail calls (happily those ideas are now finally entering
| the mainstream).
| 8fGTBjZxBcHq wrote:
| > Ocaml was my first programming language
|
| lmao what. how. like what course of events....
|
| I had several years professional experience, including
| functional programming, and still found it pretty rough going
| for a while. And even other professionals have often not even
| heard of it.
| Leherenn wrote:
| Perhaps unsurprisingly given its origin, but it's often the
| case in France.
| jhnct wrote:
| Exactly, started university in Paris in 2004 and OCaml
| was used to teach data structures for instance. First
| year was Scheme and C, second year had Java, OCaml, more
| C, some C++ if you wanted and Mips. Third year added Ada
| and .Net if I remember correctly.
| tnecio wrote:
| One reason might be that it's used as a programming
| language for 1st-year courses in Computer Science at some
| European universities.
| nestorD wrote:
| I discovered computer science in preparatory classes (a
| French thing that comes before engineering school, you can
| think of it as the first years of college) in France where
| it was the default programming language (I believe they now
| start with Python and include Ocaml only if you take some
| options).
|
| Interestingly, it was the students with previous
| programming experience who had the most difficulties
| learning the language. I have not found the reverse to be
| true, the Ocaml compiler is very strict, but it makes you
| attentive to details and types in a way that transfers well
| to other languages.
| fiddlerwoaroof wrote:
| My observation (and, I believe the authors of How to Design
| Programs have some data about this) is that FP is only
| "hard to learn" if you already know how to program: you
| have to unlearn things like "for loops" and various
| techniques that rely on mutation and learn to think in
| terms of the abstractions FP provides you.
| 8fGTBjZxBcHq wrote:
| So the biggest barrier that I found when learning ocaml
| was there were just not a lot of resources or organic
| examples around.
|
| What there is is usually for a specific course, or is
| published by like Jane Street or some shit and highly
| domain-specific as well. I just found it hard to dig
| myself out when I ran into trouble.
|
| I definitely agree about the FP concepts being no more
| difficult or even simpler to learn. I used to teach
| introductory programming to adults and at first we taught
| loops then map/filter etc and told students to use their
| preference.
|
| Almost universally they used map, including complete
| synthesis of the entire concept of iteration without
| loops. Like when presented with a loop, I once saw a
| student skim the internal logic, see that it was doing an
| array push inside an if, and call it "a filter loop." To
| him the filter was the concept and the loop the tool,
| which is I think backwards from a lot of us.
| bosswipe wrote:
| But the question is why didn't any of the functional languages
| with these desirable features ever reach mainstream popularity.
| legobmw99 wrote:
| I'll add an alternative answer to the variety you've gotten:
| functional programming is often given a bad name for not
| really corresponding to the way computers actually work. When
| you're writing C, it can feel like the code you're writing
| corresponds directly to the actual physical processes and
| components of the machine. The more higher level you get, the
| less you feel that (no Malloc in Java, for example), and
| functional languages are fully based on a model of
| computation that isn't the one we physically have in the real
| world. This can also lead to speed and memory problems,
| though I think at this point the compilers for these
| languages are good enough that this is less of a concern than
| it may have been.
|
| It's an interesting example of the Blub paradox [0] as well
| (Paul Graham's answer to a similar question, "why doesn't
| everyone use Lisp")
|
| [0] https://wiki.c2.com/?BlubParadox
| jtwebman wrote:
| because they didn't have millions of dollars for marketing
| budgets or the one thing they did that could make startups
| make millions off their work.
| goatinaboat wrote:
| _because they didn 't have millions of dollars for
| marketing budgets or the one thing they did that could make
| startups make millions off their work._
|
| If the French government had realised what they had in
| OCaml and made it the standard programming language in all
| of France they would be a software powerhouse by now.
| phtrivier wrote:
| Back when I was a student (circa 2000), caml was one of
| the "official" language to teach computer science in the
| first few years leading to engineering school ; and in my
| case, it also happened to be the first language taught to
| everyone in my eng school. So I guess the acamedic world
| was trying it's best. I remember joking with a TA that no
| one would ever write a line a caml professionally ; I
| can't wait to be writing reason or caramel at a gig :)
|
| Happy birthday !
| agumonkey wrote:
| I'd bet that if ocaml had been made the official proglang
| for all of France it would have died a slow death like
| ADA. French public sector is a swamp.
| zopa wrote:
| That's really not the question. Any language that we've all
| heard of is pretty much by definition a wild success,
| comparatively. Most languages stay very small.
|
| There are very large first-mover advantages and network
| effects to programming languages. Programmers want to learn
| languages existing code is written in; companies want to use
| languages that lots of programmers already know. Languages
| that get big for historical reasons tend to stay that way.
|
| Mainstream adoption wasn't the main goal for a lot of
| functional languages when they were created: the aim was to
| develop ideas of how programming could be better. The
| surprising thing, really, is that people write real
| production in some of these languages, despite how different
| they are from what most programmers already know. We
| shouldn't be treating not getting as big as Java as some sort
| of failure.
| chubot wrote:
| Programmers generally pick platforms and not languages. C
| became popular because of Unix and then Windows. JavaScript
| came with the browser. PHP came with shared hosting. Go sort
| of came with the "cloud". Java was made by an OS company, and
| it got new life with Android. So did Kotlin. Swift is for
| iOS, etc.
|
| There are exceptions like Python and Ruby, but I think the
| "default" is that a given language is not popular, and there
| have been almost no platforms written in functional
| languages. (anticipating the objection: Lisp isn't functional
| :) )
| jolux wrote:
| Ruby got big because of Rails specifically.
| fortran77 wrote:
| F#? That's very popular.
| jolux wrote:
| It's not really all that popular. Certainly not compared to
| C#.
| pyrale wrote:
| Along other things, there was a heavy investment in marketing
| the languages that came at the same time as the likes of
| ocaml [1]. In more recent years, we've also seen that backing
| by a major company that can help building the ecosystem is a
| major factor, as happened with Go. Finally, some languages
| flourished because they offer access to a platform that would
| otherwise be inaccessible, as JS does.
|
| Overall, though, functional languages see progression today,
| they may not have an exponential growth, but neither did
| Python, and look where it is now.
|
| [1] https://www.theregister.com/2003/06/09/sun_preps_500m_jav
| a_b...
| cercatrova wrote:
| Functional languages are harder to learn than imperative
| languages, a big factor that I didn't see in this comment
| thread.
|
| With imperative code, you can just spell out a for loop which
| makes intuitive sense. With functional code, you need to do
| so recursively, so you need at least some understanding of
| recursion, and perhaps even category theory for more complex
| examples or languages like Haskell.
|
| Just that kind of complexity over an imperative language
| alone is why I surmise that functional languages haven't
| reached as much popularity.
| agumonkey wrote:
| Some easy factors:
|
| - crowd maturity (zero dev cared about safety in the web 2
| era, cue wordpress cheese, people flocked to php or ruby
| because it was fun and easy, only later people started to
| make solid specs for their languages)
|
| - business-less ethos (I'd bet $10 FP dudes have zero desire
| nor skills to promote and sell their work)
|
| - culture shock (fp is somehow very rooted in math culture,
| how many times in the last 20 years did someone at a meeting
| or an OO class said "explictVerboseVariableNamePlease" ?
| compare that to fold f z [] = z
| fold f z [h:t] = fold f (f z h) t
|
| )
|
| add various degrees of second degree effects like the fact
| that complex and hard to sell things don't attract funding,
| unlike wordpress you get less exposure. Maybe for the best
| because mainstream business interest would surely distort the
| original paradigm quest to fit whatever money-heavy
| requirement lands on someone's desk that day
| tooltower wrote:
| Ecosystem. It's not always about the language features, it's
| about how quickly I can get something working. Having a
| large, thriving ecosystem is a big part of that.
| dudul wrote:
| What mainstream languages are you thinking about? Java is
| obviously the one that comes to mind when talking about
| market dominance, but it was created/supported by extremely
| wealthy corporations who invested hundreds of millions to
| push for its adoption.
|
| Do you have others in mind? I'm sure we can find fairly
| similar circumstances for most of them.
| blacktriangle wrote:
| Much as people credit Sun's marketing for Java's success, I
| think it would have succeeded even without them. Java
| successfully brought garbage collection to the majority of
| working developers at the time who were all C and C++
| developers. This was a huge step forward that solved a
| massive pain point. Today this is far less of a compelling
| argument since most languages are GC'd and C++ is far less
| dominant, but Java was the right language for the time.
| macintux wrote:
| I recall a quote from an anonymous industry heavyweight
| when Java came out (paraphrased now because I can't
| remember exactly where I saw it): "Thank goodness, now I
| don't have to learn C++."
| pjmlp wrote:
| There was another big factor, remember that ISO C++
| initial release is from 1998 and while C was standardised
| in 1990, many compilers in the mid-90's were still
| catching up to it.
|
| Then POSIX still left too room for each UNIX flavour to
| decide how to actually implement certain features, e.g.
| signal.
|
| So Java, despite being initially interpreted felt like
| how portable code should be, coupled with a rich library.
| solmag wrote:
| Applies to ML family of programming languages in general.
| lukego wrote:
| Congratulations!
|
| I remember trying it out 22 years ago and in retrospect I did not
| appreciate what a young language it must have been :)
| haxiomic wrote:
| Can anyone recommend a good primer to learn OCaml? (ideally aimed
| at so someone familiar with traditions C-style languages)
|
| The material I've found has been quite dense where I'm just
| looking to learn enough to be dangerous
| baby wrote:
| Real World Ocaml is for free: https://dev.realworldocaml.org/
| yawaramin wrote:
| The OCaml Manual has a good tutorial:
| https://ocaml.org/releases/4.12/htmlman/coreexamples.html
|
| Note that ;; is only required in the REPL (i.e. the
| 'toplevel'), not in source code.
| zbaylin wrote:
| As an initial primer I would recommend Cornell's Functional
| Programming class that teaches OCaml:
| https://www.cs.cornell.edu/courses/cs3110/2019sp/textbook/in...
|
| After that, I would recommend the new (beta) version of Real
| World OCaml -- it gets a lot more in depth about more advanced
| language features: https://dev.realworldocaml.org/toc.html
| haxiomic wrote:
| Thank you :)
| dhconnelly wrote:
| The Cornell textbook is great. I worked through most of it
| last year and learned a ton.
| xiaolingxiao wrote:
| I recall being exposed to OCaml in an intro to programming
| language class in college. Learning recursion was pretty mind
| blowing but ironically, it puts everyone in the class on the same
| footing: many who have programmed in OOP were just as baffled as
| those who have never programmed. Looking back, it was a good
| gateway into discrete math in general.
___________________________________________________________________
(page generated 2021-05-09 23:01 UTC)