Comments (14)
gvwilson
commented on June 8, 2024
1
Hi @noelrivasc - thanks for your interest in this topic. The first part definitely aligns; I'll defer to @rtfeldman but my preference based on experience with earlier books is to stick to one language: as soon as we require Node, Python, Go, or anything else, we make the book inaccessible (or less accessible) to a large number of readers. The only place I broke this rule in the JS and Python books was a little bit of Unix shell to launch jobs, but even then I thought long and hard. Thoughts @rtfeldman ?
from book-of-examples.
gvwilson
commented on June 8, 2024
1
doing the second one on the webserver platform would be a great opportunity to compare & contrast to show how the platform influences design
from book-of-examples.
Anton-4
commented on June 8, 2024
We decided to include testing in the language with expect to make testing easy and light-weight.
So using a unit testing framework in Roc is not something (I believe) we would recommend.
For mocking we plan to introduce "effect interpreters", @rtfeldman may have a google doc that talks about that proposal.
from book-of-examples.
gvwilson
commented on June 8, 2024
Thanks for the background - even if Roc-the-project uses expect, is it possible to built a small xUnit-style testing framework to show people things like "how to discover test functions automatically" and "how to capture errors for reporting"? (By analogy, I don't expect anyone will use the text editor that's built for this book in real life, but it's worth having to explain ideas.)
from book-of-examples.
Anton-4
commented on June 8, 2024
"how to discover test functions automatically"
I believe the only way that could be done is by relying on the platform in e.g. Rust. I would expect the Rust code for that to be very hacky.
"how to capture errors for reporting"
Roc does not capture errors like for example try/except in python. A function that can error would typically return a Result like Ok "<html>...</html>" or Err UrlNotFound. It could also return a Taskwhich can be converted to aResult` to perform error handling. We do this to force the user to handle their errors, in python it's easy to forget about them.
from book-of-examples.
gvwilson
commented on June 8, 2024
OK, this is great: "here's why and how testing in Roc is different from testing in other languages you may already know, illustrated by working code" would be a great chapter.
from book-of-examples.
Anton-4
commented on June 8, 2024
It is interesting to learn about for sure, although I have trouble imagining how it could be long enough. We included testing in the language because it makes for the best user experience and that's about it 😄
"Error handling in Roc" on the other hand could definitely be a chapter. It is not focused on making a tool but I noticed the python book also has some chapters that are not about tools.
from book-of-examples.
gvwilson
commented on June 8, 2024
What about a logging library? I think this is another place where OOP does well: loggers all implement the same interface but have different back ends, etc., so seeing how to achieve the same thing in Roc would help people coming from imperative/OOP translate their mental models.
from book-of-examples.
Anton-4
commented on June 8, 2024
Ergonomic logging is currently a pain point in Roc, although I think we're nearly done with the module parameters implementation, which would make this easier. What do you think about a chapter on a logging library @rtfeldman?
from book-of-examples.
rtfeldman
commented on June 8, 2024
It's a tricky question given the goals of the book to showcase idiomatic Roc designs without relying on unusual Roc-specific language features.
The way I expect most people will want to do logging in Roc is to have platforms to provide logging Tasks (and potentially involve dbg in logging too, since platforms are in charge of what that does), and then expose ways for applications to set the log level at runtime (or based on a config file, env var, etc.)
Implementing a log library in that way would mostly involve doing platform-specific things, and platforms are a language feature unique to Roc. That means anyone reading a chapter about how to implement that logging design wouldn't be able to translate it to other languages.
Someone could intentionally implement a different logging design, that was more geared toward being language-agnostic (even if it made less sense in Roc), but that would have some friction with the goal of showcasing idiomatic ways to do things in Roc.
from book-of-examples.
gvwilson
commented on June 8, 2024
On the other hand, this could be a place to deliberately show Roc's dependence on platforms: is it possible to implement two logging libraries, each on a different platform, and then compare and contrast the way those dependencies shape their designs? By analogy, there's a chapter in the JavaScript book that shows how promises actually work, and another showing how to implement classes and objects in Python using dictionaries; both are very language-specific, but both show how the way a language is implemented shapes what is easy and hard to do with it.
from book-of-examples.
rtfeldman
commented on June 8, 2024
That would certainly work, yeah!
from book-of-examples.
noelrivasc
commented on June 8, 2024
I would like to take this topic. Roughly, the approach I'm thinking is:
— Implement a logging library in Roc that writes to a file and uses only the features of the basic-cli platform. This allows us to demonstrate, at a basic level, the interaction between platform and Roc.
— Integrate a simple, open source logging framework with a NodeJS-based platform. This allows us to demonstrate using from Roc tools that exist in the platform language, and could be a good context to discuss why one would want to use Roc at all —considering that whatever the Roc part of the example is, could be written in NodeJS too.
Does this align with your vision for the chapter, @gvwilson @rtfeldman ?
from book-of-examples.
noelrivasc
commented on June 8, 2024
@gvwilson I understand your concern. Another downside of the approach I proposed for the second part is that the JS (or whatever other language) could be lengthy. This is why I thought of just writing a wrapper for an existing library, but I'm not sure how thin the wrapper would be.
Let's see what @rtfeldman 's opinion is, but another approach would be to write the second logging library for the webserver platform, using SQLite.
from book-of-examples.
Related Issues (20)
- infrastructure proposal: create a blog for this book HOT 4
- topic proposal: discrete event simulator HOT 5
- topic: continuous integration HOT 2
- topic proposal: machine learning from first principles HOT 2
- topic proposal: property-based testing framework HOT 3
- topic proposal: a parser with useful error messages
- topic proposal: pseudorandom number generators HOT 1
- topic: regex pattern matching HOT 1
- topic proposal: Redis-like key value store with write-ahead log HOT 7
- topic: JSON ADT and codecs HOT 5
- topic proposal: Parser combinator library HOT 5
- proposal: Prohibit external packages HOT 9
- topic: compression
- proposal: use Jekyll/GitHub Pages _temporarily_ to build a website for this material HOT 2
- Topic proposal: A transpiler to JavaScript HOT 3
- meeting 2024-04-10 HOT 1
- discuss: how to manage inter-chapter dependencies? HOT 1
- topic: package manager
- topic: pretty-printing library HOT 2
- add link to rendered site
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from book-of-examples.