prosto
monorepo
Our great sponsors
prosto | monorepo | |
---|---|---|
9 | 56 | |
89 | 945 | |
- | 7.1% | |
3.6 | 10.0 | |
over 2 years ago | 7 days ago | |
Python | JavaScript | |
MIT License | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
prosto
-
Show HN: PRQL 0.2 – Releasing a better SQL
> Joins are what makes relational modeling interesting!
It is the central part of RM which is difficult to model using other methods and which requires high expertise in non-trivial use cases. One alternative to how multiple tables can be analyzed without joins is proposed in the concept-oriented model [1] which relies on two equal modeling constructs: sets (like RM) and functions. In particular, it is implemented in the Prosto data processing toolkit [2] and its Column-SQL language. The idea is that links between tables are used instead of joins. A link is formally a function from one set to another set.
[1] Joins vs. Links or Relational Join Considered Harmful https://www.researchgate.net/publication/301764816_Joins_vs_...
[2] https://github.com/asavinov/prosto data processing toolkit radically changing how data is processed by heavily relying on functions and operations with functions - an alternative to map-reduce and join-groupby
-
Excel 2.0 – Is there a better visual data model than a grid of cells?
One idea is to use columns instead of cells. Each column has a definition in terms of other columns which might also be defined in terms of other columns. If you change value(s) in some source column then these changes will propagate through the graph of these column definitions. Some fragments of this general idea were implemented in different systems, for example, Power BI or Airtable.
This approach was formalized in the concept-oriented model of data which relies on two basic elements: mathematical functions and mathematical sets. In contrast, most traditional data models rely on only sets. Functions are implemented as columns. The main difficulty in any formalization is how to deal with columns in multiple tables.
This approach was implemented in the Prosto data processing toolkit: https://github.com/asavinov/prosto
-
Show HN: Query any kind of data with SQL powered by Python
Having Python expressions within a declarative language is a really good idea because we can combine low level logic of computations of values with high level logic of set processing.
A similar approach is implemented in the Prosto data processing toolkit:
https://github.com/asavinov/prosto
Although Prosto is viewed as an alternative to Map-Reduce by relying on functions, it also supports Python User-Defined Functions in its Column-SQL:
-
No-Code Self-Service BI/Data Analytics Tool
Most of the self-service or no-code BI, ETL, data wrangling tools are am aware of (like airtable, fieldbook, rowshare, Power BI etc.) were thought of as a replacement for Excel: working with tables should be as easily as working with spreadsheets. This problem can be solved when defining columns within one table: ``ColumnA=ColumnB+ColumnC, ColumnD=ColumnAColumnE`` we get a graph of column computations* similar to the graph of cell dependencies in spreadsheets.
Yet, the main problem is in working multiple tables: how can we define a column in one table in terms of columns in other tables? For example: ``Table1::ColumnA=FUNCTION(Table2::ColumnB, Table3::ColumnC)`` Different systems provided different answers to this question but all of them are highly specific and rather limited.
Why it is difficult to define new columns in terms of other columns in other tables? Short answer is that working with columns is not the relational approach. The relational model is working with sets (rows of tables) and not with columns.
One generic approach to working with columns in multiple tables is provided in the concept-oriented model of data which treats mathematical functions as first-class elements of the model. Previously it was implemented in a data wrangling tool called Data Commander. But them I decided to implement this model in the *Prosto* data processing toolkit which is an alternative to map-reduce and SQL:
https://github.com/asavinov/prosto
It defines data transformations as operations with columns in multiple tables. Since we use mathematical functions, no joins and no groupby operations are needed and this significantly simplifies and makes more natural the task of data transformations.
Moreover, now it provides *Column-SQL* which makes it even easier to define new columns in terms of other columns:
https://github.com/asavinov/prosto/blob/master/notebooks/col...
-
Show HN: Hamilton, a Microframework for Creating Dataframes
Hamilton is more similar to the Prosto data processing toolkit which also relies on column operations defined via Python functions:
https://github.com/asavinov/prosto
However, Prosto allows for data processing via column operations in many tables (implemented as pandas data frames) by providing a column-oriented equivalents for joins and groupby (hence it has no joins and no groupbys which are known to be quite difficult and require high expertise).
Prosto also provides Column-SQL which might be simpler and more natural in many use cases.
The whole approach is based on the concept-oriented model of data which makes functions first-class elements of the model as opposed to having only sets in the relational model.
-
Against SQL
One alternative to SQL (type of thinking) is Column-SQL [1] which is based on a new data model. This model is relies on two equal constructs: sets (tables) and functions (columns). It is opposed to the relational algebra which is based on only sets and set operations. One benefit of Column-SQL is that it does not use joins and group-by for connectivity and aggregation, respectively, which are known to be quite difficult to understand and error prone in use. Instead, many typical data processing patterns are implemented by defining new columns: link columns instead of join, and aggregate columns instead of group-by.
More details about "Why functions and column-orientation" (as opposed to sets) can be found in [2]. Shortly, problems with set-orientation and SQL are because producing sets is not what we frequently need - we need new columns and not new table. And hence applying set operations is a kind of workaround due the absence of column operations.
This approach is implemented in the Prosto data processing toolkit [0] and Column-SQL[1] is a syntactic way to define its operations.
[0] https://github.com/asavinov/prosto Prosto is a data processing toolkit - an alternative to map-reduce and join-groupby
[1] https://prosto.readthedocs.io/en/latest/text/column-sql.html Column-SQL (work in progress)
[2] https://prosto.readthedocs.io/en/latest/text/why.html Why functions and column-orientation?
- Functions matter – an alternative to SQL and map-reduce for data processing
-
NoSQL Data Modeling Techniques
> This is closer to the way that humans perceive the world — mapping between whatever aspect of external reality you are interested in and the data model is an order of magnitude easier than with relational databases.
One approach to modeling data based on mappings (mathematical functions) is the concept-oriented model [1] implemented in [2]. Its main feature is that it gets rid of joins, groupby and map-reduce by manipulating data using operations with functions (mappings).
> Everything is pre-joined — you don’t have to disassemble objects into normalised tables and reassemble them with joins.
One old related general idea is to assume the existence of universal relation. Such an approach is referred to as the universal relation model (URM) [3, 4].
[1] A. Savinov, Concept-oriented model: Modeling and processing data using functions, Eprint: arXiv:1911.07225 [cs.DB], 2019 https://www.researchgate.net/publication/337336089_Concept-o...
[2] https://github.com/asavinov/prosto Prosto Data Processing Toolkit: No join-groupby, No map-reduce
[3] https://en.wikipedia.org/wiki/Universal_relation_assumption
[4] R. Fagin, A.O. Mendelzon and J.D. Ullman, A Simplified Universal Relation Assumption and Its Properties. ACM Trans. Database Syst., 7(3), 343-360 (1982).
-
Feature Processing in Go
(Currently, it is not actively developed and the focus is moved to a similar project - https://github.com/asavinov/prosto - also focused on data preprocessing and feature engineering)
monorepo
- Writing a document with version control feauters
-
Ask HN: What happened to startups, why is everything so polished?
fixed the capitalization https://github.com/opral/monorepo/commit/6127c6899290b35442c...
-
I build a free tool for software localization due to my pain, and now I need the community feedback. Please, try and let me know what you think 🙏️
Hey there! Have you ever heard about inlang (inlang.com)? Your approach goes in our direction. Great to see so many people fixing the i18n pain! :)
-
Supercharging Your App Development: Unleashing the Full Potential of React Native
If you want to take a look, here is the website featuring our products: https://inlang.com/
-
I got a job by posting here
Last time I posted on this Subreddit I was announcing my typesafe i18n library. As luck would have it some people at Inlang saw that post and my project and contacted me to work on ParaglideJS.
-
Best approach for CSR and SSR Localization/Translation
I'm from inlang and we have a fully configurable JavaScript i18n library with paraglide-js that might help you. There will be a dedicated adapter of the library for NextJS that is more integrated into the framework. Until then you can look at our NextJS example and set the library up this way.
-
Internationalization best practices for front-end developers
i am on a 2 year long rabbit hole to solve many i18n problems that devs face https://github.com/inlang/inlang
we are in our third (major) refactor because the problem is so complex and new requirements emerge regularly :/
-
Suggest Best Svelte Libraries
inlang: localization infrastructure for software and the next git (made by the inlang team and same author of the amazing typesafe-i18n library)
-
Using ChatGPT to auto generate config files: Wasted effort for us
https://www.loom.com/share/85d77004aa4c4bea9752d959c229e577
The irony is that this is not needed anymore. The plugin API simplified the config interface so much that initializing configs only differs by the used plugins and their respective configs.
The only useful thing that chatgpt provides is deriving what files in a filesystem are translation files. But a hardcoded version might be faster and more resilient.
Learning: The GPT hype is ... well hype. The amount of work that went into this feature is insane. The work boils down to software engineering. Sure, tools will emerge that make prompt engineering easier but so does the previous ML hypetrain led to endless nocode machine learning tools. Yet, there is no "disruptive everyone builds ML models" (for GPT "everyone will become a developer") nocode machine learning tool in sight. Maybe signaling that the premise of ML NoCode/GPT of "this works for everything" is not true. Deriving what files are translation files, yep. Deriving an entire config file, maybe not.
[0] https://github.com/inlang/inlang/discussions/408#discussion-4914727
-
I created a vscode extension that can automatically add translation keys to your html
We faced the same issue and build a viscose extension too! https://github.com/inlang/inlang/tree/main/source-code/ide-extension
What are some alternatives?
Preql - An interpreted relational query language that compiles to SQL.
typesafe-i18n - A fully type-safe and lightweight internationalization library for all your TypeScript and JavaScript projects.
mito - The mitosheet package, trymito.io, and other public Mito code.
nextjs-monorepo-example - Collection of monorepo tips & tricks
rel8 - Hey! Hey! Can u rel8?
firefly - The official IOTA and Shimmer wallet
opaleye
jsLingui - 🌍 📖 A readable, automated, and optimized (3 kb) internationalization for JavaScript
hamilton - A scalable general purpose micro-framework for defining dataflows. THIS REPOSITORY HAS BEEN MOVED TO www.github.com/dagworks-inc/hamilton
surveys - YAML config files for the Devographics surveys
Optimus - :truck: Agile Data Preparation Workflows made easy with Pandas, Dask, cuDF, Dask-cuDF, Vaex and PySpark
tolgee-platform - Developer & translator friendly web-based localization platform