Final pass of roadmap (#686)

website/content/roadmap.md

@@ -19,16 +19,13 @@ url: roadmap
 
 ## Language
 
-Already since becoming public, the language has improved dramatically, thanks to
-the feedback of dozens of contributors. The current state of the basics is now
-stable and while we'll hit corner-cases, I expect we'll only make small changes
-to the existing features — even as we continue adding features.
+The language is now fairly stable. While we'll hit corner-cases, we expect we'll
+only make small changes to the existing features, even as we continue adding
+features.
 
 On this foundation we are planning to build advanced features like type checking,
 function currying, pivot/melt/wide_to_long/long_to_wide operations, operator overloading and
 [a few more](https://github.com/prql/prql/issues?q=is%3Aissue+is%3Aopen+label%3Alanguage-design).
-This will take time, because we want to build a consistent language that feels like it is
-made to last.
 
 ## Friendliness
 
@@ -40,13 +37,13 @@ Both bug reports of unfriendliness, and code contributions to improve them are w
 
 ## Standard library
 
-Currently, the standard library is [quite limited](https://github.com/prql/prql/blob/main/prql-compiler/src/sql/stdlib.prql).
-It contains only basic arithmetic functions (`AVERAGE`, `SUM`) and lacks functions for string manipulation,
-date handling and many math functions.
-One challenge here is the variety of functionalities and syntax of target DBMSs; e.g. there's no standard
-regex function. Improving our testing framework to include integration tests will help give us confidence
-here.
-of different dialects.
+Currently, the standard library is [quite
+limited](https://github.com/prql/prql/blob/main/prql-compiler/src/sql/stdlib.prql).
+It contains only basic arithmetic functions (`AVERAGE`, `SUM`) and lacks
+functions for string manipulation, date handling and many math functions. One
+challenge here is the variety of functionalities and syntax of target DBMSs;
+e.g. there's no standard regex function. Improving our testing framework to
+include integration tests will help give us confidence here.
 
 <--->
 
@@ -57,16 +54,20 @@ if we develop a data-frame-handling-library backend. To be more precise, we woul
 AST to a in-memory dataframe of a performance-optimized library (such as [Polars](https://www.pola.rs/)).
 
 This would allow data scientists, analysts and general Python developers to transform DataFrames with
-PRQL queries. One language for all data transformations.
+PRQL queries. One language for all data transformations!
 
 ## PRQL as a tool
 
-PyPrql is a step into direction of a general data handling program. But we want to build a tool that
-can read many data sources, offers syntax highlighting, auto-complete and type-inference using
-information from database's schema.
+PyPrql is a step into direction of a general data handling program. Building on
+this, we want to build a tool that can read many data sources, offers syntax
+highlighting, auto-complete and type-inference using information from database's
+schema.
 
-If done right, it could replace many uses of classical spreadsheet software while producing reproducible
-data transformations and intuitive, interactive experience with fast feedback.
+We'll likely continue pursuing this through integrations with other tools;
+combining the potential of PRQL with its openness and ecosystem.
+
+If successful, we can have reproducible data transformations with an intuitive,
+interactive experience with fast feedback.
 
 ## Integrations