Problem: "a meta language toolchain to build systems rapidly" incites lots of questions. We'd like to change it something "better"
Let's try to decide this quickly =).
"A friendly syntax and toolchain for OCaml, targeting native & web"
^ I like this. Might go with it.
A modern toolchain for building native and web application.
I also wouldn't mind 'delightful' in place of modern - I imagine language
like that helps guide the ethos and efforts of the community as it grows.
On Thu, Sep 8, 2016 at 1:49 PM, Cheng Lou [email protected] wrote:
^ I like this. Might go with it.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/facebook/reason/issues/750#issuecomment-245735996,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AACJ4EKiB-wGYeCJ7Q11daq8LP4Zz5qKks5qoHTrgaJpZM4J4bWy
.
"Approachable" is a little more specific than friendly. Let's still be friendly though :D
Make Ocaml Great Again 😸
I've previously said that Reason is a new approachable frontend to a language that was Already Great! :D
Why not say that Reason is a "language" instead of saying it's a toolchain + ecosystem?
how is approachable more specific? If we're talking about a syntax + toolchain, can friendly mean anything else?
@bsansouci b/c language also includes runtime/type system?
@jaredly It is part of Reason though. It might not be what we're currently building but it's part of the package that's promised isn't it?
I agree with @bsansouci. Reason should be called a language. I feel it leads to less confusion. Reason is a language in the same way CoffeeScript is.
I do not think it should be called a language, because the word "language" is very much misunderstood. To many people, syntax and very lightweight transformations are a language. To them, yeah totally - Reason is a new language. But languages are much more than that - specifically, IMHO the type system and runtime make the language (yes, and community, packaging, build systems, docs, culture etc). But since Reason uses the underlying OCaml type system/runtime most of the time, it doesn't make sense to call Reason a language (is Elixer a language? Genuinely asking). Any work we do on the compiler internals, we'd like to upstream to OCaml if possible (if it's not as simple as lexical ppx transform pipelines).
To make matters more confusing, OCaml itself as a language and compiler is becoming unbundled (compiler-libs) and it's easier than ever to substitute various parts of the compiler pipeline (like BuckleScript backend, or Reason's syntax for the front end). So yeah, to some people Reason is what they think of as a language. To others it's not. Because the term is so misunderstood, using the word "language" would match some people's expectations, and contradict other peoples' expectations in a way that makes it appear that Reason is somehow claiming credit for the excellent type system underneath. It's not, so let's try not to risk that. We want to be good citizens of the compiler platform we're building on. OCaml is downright amazing - especially for its time, so we've got the tricky job of paying all the right homage while also letting people know how we've taken huge strides to create a better dev experience for the great stuff underneath that had been covered up by a terrible syntax. It would be _totally_ accurate to say that Reason _feels_ like an entirely new language.
I had thought the term "front-end" to the compiler was a good way to describe it (and even some people said _that_ had potential to be misinterpreted. I think if we convey our intentions correctly, we could call it a "front end").
(My thoughts here are based on real conversations I've had with people in the OCaml and JavaScript community, fwiw)
I think I am in your target audience? An intermediate but ambitious programmer frustrated by the trouble I get into with JavaScript/Python, excited by my limited functional programming experience.
I like the "build systems rapidly" slogan a lot, as it has a value proposition in it that speaks to me, whereas the tool chain ones are just descriptive. I'm like "why do I give a sh&$" about a tool chain? Now that I've explored reason I do think it is cool, but for me the main thing is to have a way to build stuff where I'm able to make changes without tripping up and chasing errors through the program for days.
And "language" does make sense to me as well. The interaction between reason/buckle script/ocaml/Core etc is still confusing to me, but I'm not sure the slogan really has to answer this for me, and language is meaningful. For someone not in the ocaml world, it also is the most semantically correct, as reason=ocaml for them, so it is a new language.
Just read @jordwalke's comments, and see that the language term is indeed tricky, and that the ocaml community is a big part of your target audience, so _shrug_
Elixir is a dynamic, functional language designed for building scalable and maintainable applications.
Elixir leverages the Erlang VM, known for running low-latency, distributed and fault-tolerant systems, while also being successfully used in web development and the embedded software domain.
:D guess that answers it. so reason is a language?
I think we'll keep the main "Build Systems Rapidly" slogan because that's really what it's all about. The other description we're discussing is more like the answer to "okay, summarize how Reason can help me do that". We still need that second description though.
I'm going to go off on a tangent - feel free to skip reading it :D
More on why Build Systems Rapidly is important to me: Even though software development has never been better, like you I am frustrated by the state of programming and I recognize that languages are the biggest technical leverage to improving the state of the programming world. I want to iterate rapidly, which JavaScript lets me do to some extent. But then it's very difficult to maintain and evolve that software (from my own experience) once many people begin to depend on that software and when the ecosystem doesn't have a canonical type system engrained in it. Furthermore, while JS lets me create libraries rapidly, it doesn't give us the rapid _performance_ of systems languages - startup time suffers, and we have to rely on JITs to (hopefully) optimize our apps.
I don't want to have to choose between building Systems (that perform well and start up instantly), and rapidly developing that software. I want both! And I want to be able to take that thing I built and run it anywhere, in a way that doesn't force me to rewrite the whole world. That means I want to be able to compile my library into JavaScript and have it interop (without leaking memory or reimplementing malloc like Emscripten does). I also want to run that software in the most performant way possible for the environment I'm running it in. That means when I compile natively, I want better performance without a VM. When compiling to JS, it should generate efficient JS, better than I could write by hand.
I think that "Build Systems Rapidly" captures that goal nicely.
We're not gonna bite the hands that fed us. We diminished the importance of syntax (ironically by raising it) so that the OCaml language can shine through. We can change the slogan again in the future just like we're doing it now.
that sounds like the seed of a good blurb for the reasonml front page
We've decided on "Friendly Syntax & Toolchain Powered by OCaml".
Thanks for the discussion everyone! That was pretty quick. We've now got a slogan that confuses less people.
Onward to becoming a real metalanguage!
Awesome. Incorporates most of the feedback here, is strictly better than the old tagline, and pays tribute. We'll change it later once we're more proud of the build system.
Thanks for making it more understandable!
Most helpful comment
I think we'll keep the main "Build Systems Rapidly" slogan because that's really what it's all about. The other description we're discussing is more like the answer to "okay, summarize how Reason can help me do that". We still need that second description though.
I'm going to go off on a tangent - feel free to skip reading it :D
More on why Build Systems Rapidly is important to me: Even though software development has never been better, like you I am frustrated by the state of programming and I recognize that languages are the biggest technical leverage to improving the state of the programming world. I want to iterate rapidly, which JavaScript lets me do to some extent. But then it's very difficult to maintain and evolve that software (from my own experience) once many people begin to depend on that software and when the ecosystem doesn't have a canonical type system engrained in it. Furthermore, while JS lets me create libraries rapidly, it doesn't give us the rapid _performance_ of systems languages - startup time suffers, and we have to rely on JITs to (hopefully) optimize our apps.
I don't want to have to choose between building Systems (that perform well and start up instantly), and rapidly developing that software. I want both! And I want to be able to take that thing I built and run it anywhere, in a way that doesn't force me to rewrite the whole world. That means I want to be able to compile my library into JavaScript and have it interop (without leaking memory or reimplementing malloc like Emscripten does). I also want to run that software in the most performant way possible for the environment I'm running it in. That means when I compile natively, I want better performance without a VM. When compiling to JS, it should generate efficient JS, better than I could write by hand.
I think that "Build Systems Rapidly" captures that goal nicely.