697 Matching Annotations
  1. Last 7 days
    1. The changes we needed to make to main to reassign post mean that this implementation doesn’t quite follow the object-oriented state pattern anymore: the transformations between the states are no longer encapsulated entirely within the Post implementation. However, our gain is that invalid states are now impossible because of the type system and the type checking that happens at compile time! This ensures that certain bugs, such as display of the content of an unpublished post, will be discovered before they make it to production.

      This is really an amazing chapter for comparing (some aspects) of object oriented and functional programming, and I have to admit I still prefer the functional approach as a default.

    1. overflow-wrap: break-word; makes sure the long string will wrap and not bust out of the container. You might as well use word-wrap as well because as the spec says, they are literally just alternate names for each other. Some browsers support one and not the other.
  2. Jan 2021
    1. ensure the relevance, accuracy and effective communication of its interpretation and education programs (see above for A.O.D.A. requirements) by: establishing clearly defined and measurable learning objectives and outcomes, and undertaking a process of program evaluation using appropriate expertise – including staff, volunteers, community groups, or consultants carrying out research ensure all staff involved in the development and delivery of interpretation and education programs, have the appropriate skills and training

      (2) Volunteer opportunities (programming).

    2. have a volunteer program to encourage community participation in its activities, which should include: identification and development of volunteer opportunities procedures for recruitment of volunteers matching the needs and interests of volunteers to those of the museum provision of appropriate training and supervision for volunteers provision of a safe and secure working environment for volunteers volunteer evaluation public and private recognition of volunteers' contributions

      (3) Volunteer program (adding on to).

    3. ensure the relevance, accuracy and effective communication of each exhibit by: establishing clearly defined objectives and evaluating exhibits against their objectives using appropriate expertise, including staff, volunteers, community groups, or consultants carrying out sufficient research ensure that all staff (including volunteers) involved in the planning, preparation and installation of exhibits have the necessary skills and training

      (1) Volunteer opportunities (programming).

    4. formulating written policy governing operations and defining programs securing funding necessary to carry out the museum's programs preparing or approving an annual budget and monitoring it to ensure public accountability ensuring that the purposes for which the museum exists are being fulfilled

      Program development, grant writing accountability and documentation.

    1. stored instructions a program and the act of writing these instructions down and getting the instructions to be correct programming.

      What is a program? What is programming?

    1. { item1: "hello", item2: "world" }

      Valida in automatico l'oggetto passato con l'interfaccia?

      Non necessità di un'istanza o di specificare l'interfaccia dell'istanza?

      Interessante..

  3. Dec 2020
    1. pic (a drawing language)

      Text really is kind of versatile in this manner... Is the current text-dominance in programming part of UNIX "heritage"?

    1. Note: The examples in Listings 10-17, 10-18, and 10-24 declare variables without giving them an initial value, so the variable name exists in the outer scope. At first glance, this might appear to be in conflict with Rust’s having no null values. However, if we try to use a variable before giving it a value, we’ll get a compile-time error, which shows that Rust indeed does not allow null values.
    1. To the brain, reading computer code is not the same as reading language Neuroscientists find that interpreting code activates a general-purpose brain network, but not language-processing centers.

      Summary of the article:

      • Understanding code is neither done by language centers, nor by mathematical centers of the brain — it’s a whole different ball game.
      • This comes from a researcher who’s studying how different cognitive functions relate to language processing parts of the brain.
      • The study involved young programmers who analysed code while their brains were scanned.
      • People either say that great coders are great at language, or great at maths - neither seems to be true, and there is no single specialized area that lights up from coding.
      • The test activated the multiple demand network in participants’ brains, a wide network for performing mentally challenging tasks.
    1. Original objects are never modified, but transparently wrapped by observable proxies.
    2. Proxy = observable(object) Creates and returns a proxied observable object, which behaves just like the originally passed object. The original object is not modified.
    1. Svelte is its own language, not plain HTML+CSS+JS

      its own _

    2. My frustration is mainly from Svelte's choices that are very un-JavaScript-like. It doesn't have to be "like React/Vue". React is React because it doesn't restrict what you can do with JavaScript for the most part. It's just common FP practice to fold/map.
    1. Review your own code first Write a clear changelist description Automate the easy stuff Answer questions with the code itself Narrowly scope changes Separate functional and non-functional changes Break up large changelists Respond graciously to critiques Be patient when your reviewer is wrong Communicate your responses explicitly Artfully solicit missing information Award all ties to your reviewer Minimize lag between rounds of review

      13 best practices for participating in a code review when you're the author

    1. It was great for three things: motivation (people used what I built!)feedback (they sent me the bugs they encountered)accountability (from the moment I tweeted about this publicly, I really felt like that I’d have to finish this project… otherwise, it would be embarrassing)

      Three positive things that might come after publishing your beta software: motivation, feedback and accountability

    2. Turning my Jupyter-compatible Python code into Flask-compatible Python code took dozens of hours. I ran into small bugs and errors

      That's how I always expected Python notebook development to be

    3. I had a proof-of-concept. It was great, because when you do a project, there’s always that small uncertainty that your idea is stupid and it can’t be done at all. But when you have a working prototype, all that insecurity is gone and it becomes much easier to go on.

      So true

    4. The point is: the initial idea should be simple—because even that will turn out to be pretty complex.

      Main point to consider when starting a new project

    5. The problem with hobby projects is that they don’t pay very well. At least, compared to real-life projects. But hobby projects have a lot of cool advantages that we tend to forget.

      With hobby projects:

      • you can learn what you want
      • you've a full control over the tech stack
      • you can add the project to your CV
    6. The user has a starting stack: 10,000 units of play money.In each round, she gets a deal. Something like “You have an x% probability to win y amount of money.”She can decide how much of her play money she wants to risk.And the goal is to win as much as she can in 50 rounds.

      Great idea for a 1st game dev project

  4. Nov 2020
    1. The Ideology of Hacking

      [..]

      The hacker movement is a political project. Like the activity of many 'alternative' subcultures that are not directly defined by their political engagement, "the struggles are at once economic, political, and cultural - and hence they are biopolitical struggles, struggles over the form of life. They are constituent struggles, creating new public spaces and new forms of community" [46]. The chief uniting and mobilising force for the hacker underground is the common enemy of Microsoft (Bezroukov, 1999a). Opposition to Microsoft draws both from socialist anarchistic principles, and from high-tech libertarianism. The rightwing drift, dubbed as the Californian Ideology, is a recent transition, and not surprising given the hegemonic dominance of the corporate sector in the United States and the greater stakes in free software for business. However, it runs counter to the roots of hacking, which essentially is a reaction against Taylorism (Hannemyr, 1999). Basic motivations to engage in free programming are the rush of technological empowerment (Sterling, 1994), the joy of un-alienated creativity (Moglen, 1999), and the sense of belonging to a community (commonly recognised by hackers themselves as 'ego', but reputation only viable within a group of peers, i.e. a community). Those values may not seem political at first sight, but they are on collision course with the commercial agenda of turning the Internet into a marketplace. The rising tension within the hacker community are illuminated by the words of Manuel Castells: "The struggle between diverse capitalists and miscellaneous working class is subsumed into the more fundamental opposition between the bare logic of capital flows and the cultural values of human experience"

      [..]

    1. Svelte's advantage here is that it indicates the need for an update at the place where the associated data is updated, instead of at each place the data is used. Then each template expression of reactive statement is able to check very quickly if it needs to rerender or not.
    1. Frontend frameworks are a positive sum game! Svelte has no monopoly on the compiler paradigm either. Just like I think React is worth learning for the mental model it imparts, where UI is a (pure) function of state, I think the frontend framework-as-compiler paradigm is worth understanding. We're going to see a lot more of it because the tradeoffs are fantastic, to where it'll be a boring talking point before we know it.
    1. This conflicts in very basic ways with what other engineering disciplines expect. Toyota's stylists might be able to sell their renderings in art galleries, but you can't drive to work in one. In software, you can.

      I don't really understand the sentence. Does it mean that you can't really use a project's design until it's built, in classical engineering, while instead with software all that detailed design is actually the product?

    1. {...{ foo: null }} was getting serialized as foo="null" because spread() was checking for strict equality with undefined. It's now checking for loose equality with null.
    1. When you’re implementing a bad plan yourself, instead of having a mentor bail you out by fixing it, a few really useful things happen:You learn many more details about why it was a bad idea. If someone else tells you your plan is bad, they’ll probably list the top two or three reasons. By actually following through, you’ll also get to learn reasons 4–1,217.You spend about 100x more time thinking about how you’ll avoid ever making that type of mistake again, i.e., digesting what you’ve learned and integrating it into your overall decision-making.By watching my mistakes and successes play out well or badly over the course of months, I was able to build much more detailed, precise models about what does and doesn’t matter for long-term codebase health. Eventually, that let me make architectural decisions with much more conviction.

      There's a benefit to embarking on a challenge without a more experienced authority to bail you out.

      • You learn many more details about why it's a bad idea.
      • The lessons you learn in terms of how to avoid the mistakes you made stick with you longer

      (I would add that the experience is more visceral, it activates more modalities in your brain, and you remember it much more clearly.)

      These types of experiences result in what the author calls more "detailed, precise models". For me they result in a sort of intuition.

    1. Mistakes programmers need to look out for

      • Programming is more about practicising than passive knowledge gain.
      • Understand the solutions solved/suggest by your peers, introspect on why he could solve it better and why you couldn't.
      • Be a perpetual learner.
      • Don't just reuse, reuse and add value.
      • Re-affirm and reconfirm your learning.
    2. being a programmer you should always make sure that you learn by yourself and create things by yourself
    1. Thanks for posting this helpful, well written article. Learning programming, or any other thing one takes up, requires you to sit at one place have a plan of action for your study.

      I was going through my Firefox bookmarks and I found article. I had read this article two years back and had commented that I found it to be useful. I read it back in May 2018. As of now, November 2020, my programming skills are still novice-level. I haven't implemented the ideas or followed suggestions given here.

      It has been 2 years and 5 months since I found this article to be relevant and it baffles me that I haven't taken action by making use of the knowledge given in this article. Two long years flew by. I guess reviewing my bookmarks is something that I will do more often.

      The article was posted on May 23, 2018 and I had stumbled on it the next day itself, i.e., May 24, 2018. This gets me thinking that we could finds solutions for problems(latest ones in this case) once we identify it, articulate it, hit the search button and just read stuff. I could presume that what happened next was that I misunderstood "finding a solution" to "realizing the solution", and perhaps became complacent or maybe there were more problems that didn't come to my awareness to identify and further find solutions. I'm not quite sure. Should I have identified my problems and googled more so that I could have learned C and C++ sooner?

      I wonder what held me back from taking action to accomplish and master something that usually takes not more that 5-6 months maximum.

    2. On learning programming

      • Master one first programming language first, before moving to the next.
      • Learn at a slow for the first two programming languages. This is important for beginners
      • Practising coding is more important than watching tutorials or reading books. You learn more by practising than by reading or watching videos.
      • Apart from tutorials, immitating open source projects is very important
      • Read others code and immitate it. You'll be surprised at how fast you're learning.
      • Make use of StackOverflow, Quora and programming subreddits.Ask questions there. Interact more.
      • Practice more. Write code from time to time. Debugging skills imporove with more coding practice.
      • Test your skills with quizzes, challenges and competitive programming
    1. The challenges are very difficult and require great thinking ability to complete. If you are a beginner then it’s gonna be really tough for you.

      Practice programming challenges with HackerEarth and then move to TopCoder.

    2. Project Euler

      Project Euler emphasises on programming challenges that involve problem solving and critical thinking skills.

    3. It’s powered by a large set of problems to work with, and you can also gain access to the source codes that others used to solve the given coding challenges.

      You'll learn more when you read others' code and immitate it. CodeChef provides you access to learn from others' code.

    1. Conclusions Draw your own. No? Fine. Good Enough: JSON? Protobuf Cap’n Proto Flatbuffers CBOR msgpack Avoid: YAML XML Thrift? BSON

      Alternatives to JSON which are well readable by humans. In short, JSON is still fine and seems like it will be for a long time

    1. There’s a story about an art teacher that split their class in half. They told one half of the students that they’d be graded based on a single piece of work, and the other half that they would be graded on the quantity of work produced. The half that was being graded on quantity ended up producing higher quality pieces. By iterating and learning from their mistakes they actually ended up producing better work than the students that only had to produce one piece. Quantity leads to quality. Share your work Sharing work helps you to think and develop. The feedback you get feeds into the next iteration.

      Share your work as often as you can as quantity leads to quality

  5. Oct 2020
    1. All containers without a --network specified, are attached to the default bridge network. This can be a risk, as unrelated stacks/services/containers are then able to communicate.
    2. In terms of Docker, a bridge network uses a software bridge which allows containers connected to the same bridge network to communicate, while providing isolation from containers which are not connected to that bridge network. The Docker bridge driver automatically installs rules in the host machine so that containers on different bridge networks cannot communicate directly with each other.
    1. In practice, functional programming is all about hiding for loops, which are abstracted away by the mapper functions that automate the iteration.
    1. Declarative programming is an enabler of abstraction. Imperative programming is an inhibitor of abstraction. Declarative programming allows you to say “I want this and I don’t care how I get it” while imperative programming requires you to define each and every step.

      Declarative programming, i.e. "build me a house, I don't care how", is an enabler of abstraction.

      Imperative programming, i.e. "build walls, windows, a roof.", is an inhibitor of abstraction.

    1. Your weekly reminder that1. You should not have your development process on a centralized platform, at least not if you're doing anything that smells of copyright issues2. If you do host on a centralized platform, have regular, decentralized backups of code and issue tracking.3. Also, avoid US-centric hosting for this kind of thing. But really, refer to 1.

      3 things to keep in mind while hosting your code

    1. Informative data about objects that are considered prototypes for the role. Base concept is similar to type, but without inheritance of limitations and properties. Base concepts are designed as a substitute for inheritance for external concepts. A base concept is like a related concept except that the base concept is almost identical to the role definition.
    1. Longstanding controversy surrounds the meaning of the term "hacker". In this controversy, computer programmers reclaim the term hacker, arguing that it refers simply to someone with an advanced understanding of computers and computer networks[5] and that cracker is the more appropriate term for those who break into computers, whether computer criminals (black hats) or computer security experts (white hats).
    1. The lodash/fp module promotes a more functional programming (FP) friendly style by exporting an instance of lodash with its methods wrapped to produce immutable auto-curried iteratee-first data-last methods.
    1. If you define a variable outside of your form, you can then set the value of that variable to the handleSubmit function that 🏁 React Final Form gives you, and then you can call that function from outside of the form.
    1. JavaScript is, of course, a dynamic language that allows you to add and remove objects and their members at any point in time. For many, this is precisely why they enjoy the language: there are very few constraints imposed by the language.
    2. We rarely, if ever, start with a completely blank file and start writing code. More often that not we start by copying an existing file and then modifying it to get our result.
    1. All validators can be used independently. Inspried by functional programming paradigm, all built in validators are just functions.

      I'm glad you can use it independently like:

      FormValidation.validators.creditCard().validate({
      

      because sometimes you don't have a formElement available like in their "main" (?) API examples:

      FormValidation.formValidation(formElement
      
    1. One of the primary tasks of engineers is to minimize complexity. JSX changes such a fundamental part (syntax and semantics of the language) that the complexity bubbles up to everything it touches. Pretty much every pipeline tool I've had to work with has become far more complex than necessary because of JSX. It affects AST parsers, it affects linters, it affects code coverage, it affects build systems. That tons and tons of additional code that I now need to wade through and mentally parse and ignore whenever I need to debug or want to contribute to a library that adds JSX support.
    2. Furthermore, JSX encourages bad non-dry code. Having seen a lot of JSX over the past few months, its encourages copypasta coding.
    3. However, as a developer that uses JSX, I find it too useful/concise to give up in the name of syntax purity, especially when I know that what it translates to is still very isolated and computationally pure.

      What does "isolated" mean in this case? Is it a different sense than how isolated is usually used in programming context?

      What does "computationally pure" mean? Sounds like a bit of a vague weasel word, but this is an honest question of curiosity and wanting to understand/learn.

    1. An onevent event handler property serves as a placeholder of sorts, to which a single event handler can be assigned. In order to allow multiple handlers to be installed for the same event on a given object, you can call its addEventListener() method, which manages a list of handlers for the given event on the object.
    1. Interface specifications can be reused through inheritance but implementation need not be.
    2. The existing interface is closed to modifications and new implementations must, at a minimum, implement that interface.
    1. that does not mean that I am advocating the other extreme–i.e., a templating language that allows a lot of logic. I find such templating languages, especially those that allow the host programming languages to be used inside the template, to be hard to read, hard to maintain, and simply a bad choice.
    1. An alternative (maybe not good) would be to restrict {@const} to certain blocks like {#each} and {#if}. In both cases, it significantly reduces the "multiple ways to do the same thing" problem and avoids ergonomic and performance overhead of our current situation.
    2. it also allows for more divergence in how people write there code and where they put their logic, making different svelte codebases potentially even more different due to fewer constraints. This last point is actually something I really value, I read a lot of Svelte code by a lot of different people and broadly speaking things look the same and are in the same places.
    1. use code to parameterize calls:

      You can write Python code to parametrize calls:

      python -c "
      from mymodule import set_dragon_feeding_schedule, Creatures, Date
      set_dragon_feeding_schedule(
          feeding_times=['10:00', '14:00', '18:00'],
          dishes={Creatures.Tiger: 2, Creatures.Human: 1},
          start_day=Date('1020-03-01'),
      )
      "
      

      instead of:

      python -m mymodule \
          set_dragon_feeding_schedule \
          --feeding-times ['10:00','14:00','18:00'] # hopefully this way it gets recognized \
          # how will you define parsing a dict with enum to integer mapping? 
          --dishes=Creatures.Tiger:2 \
          --dishes=Creatures.Human:1 \
          --start-day=1020-03-21 # BTW bash allows no comments in multiline calls
      
    2. That’s it. Types are parsed, checked and converted. Defaults and description are picked from function itself. Even provides bash completions you can install. You wrote no code for that!

      Good example of writing CLI interfaces in Python with typer:

      import typer
      from pathlib import Path
      
      app = typer.Typer()
      
      @app.command()
      def find_dragon(name: str, path: Path, min_age_years: int = 200):
          <implementation goes here>
      
      @app.command()
      def feed_dragon(dragon_name: str, n_humans: int = 3):
          <implementation goes here>
      
      if __name__ == "__main__":
          app()
      

      later we can call it that way:

      python example.py find_dragon 'Drake' --path /on/my/planet
      
    1. NestedText is a file format for holding data that is to be entered, edited, or viewed by people. It allows data to be organized into a nested collection of dictionaries, lists, and strings. In this way it is similar to JSON, YAML and TOML, but without the complexity and risk of YAML and without the syntactic clutter of JSON and TOML.

      NestedText - new format similar to JSON, YAML and TOML

    1. I saw object proxies being the solution to doing diffing so that this approach could compete in any scenario that a VDOM could
    1. So how do we declare the variable y to be the value of x plus 5? That's where reactive programming comes in. Reactive programming is a way of programming that makes it possible solve this problem
    1. Today we begin the Early Access Program for Code With Me, a tool for remote collaborative development and pair programming that you have long been waiting for.

      Code With Me - new feature from JetBrains for collaborative programming. Unfortunately, soon it won't be free.

      >GIF explaining its work<

    1. Indeed, this simple contract is very close to that of an ob­serv­able, such as those provided by Rxjs. set is basically equiv­a­lent to next in the ob­serv­able world.
    2. The $ contract for auto-sub­scrib­ing is lovely in its sim­plic­ity and flex­i­bil­ity. You can adapt your own preferred state-man­age­ment pattern or library, with or without Svelte stores as helpers. Svelte does not fuss about how you want to manage your state.
  6. Sep 2020
    1. detach, as an api, should be declarative (ensure the node is detached) instead of imperative (detach the node), allowing it to be called multiple times by performing a noop if the node is already detached. This way, it won't matter if the node is removed from the DOM from outside of svelte.
    1. Spending more time looking for a solution rather than thinking about it.

      Stack Overflow Antipattern:

      1. Encounter a problem you can’t immediately solve
      2. Google the problem
      3. Find a seemingly-satisfying solution (usually on Stack Overflow)
      4. Copy-paste the solution and test it out
      5. If it works, move on; otherwise, go back to step 2.
    1. Then, the projects that use these libraries get to process these import statements how they like when they are bundled. For the ones that wish to load jQuery from a global, we again mark 'jquery' as an external—since we still don't want Rollup to bundle jQuery—and as a global.
    1. The idea of a web browser being something we can comprehend, of a web page being something that more people can make, feels exciting to me.

      my personal hope is that we can build a more sensible coherent web, that exudes the machines inside of it, by better harkening towards custom elements ("webcomponents"). move the page from being a bunch of machines in javascript, to a bunch of machines in hypertext.

      and then build pages that start to expose & let the user play with the dom. start to build experiences that bridge the gap into the machine/page.

      and keep going. keep going. build wilder web experiences. build more machines. and keep building battlesuits for the user, out of more componenets, out of more web, to let them wrestle & tangle with & manipulate & experiment & hack on & see & observe & learn about the truthful, honest, direct hypertext that we all navigate.

    1. There is a good amount of properties that should mostly be applied from a parent's point of view. We're talking stuff like grid-area in grid layouts, margin and flex in flex layouts. Even properties like position and and the top/right/left/bottom following it in some cases.
    2. The main reason using classes isn't a great solution is that it completely breaks encapsulation in a confusing way, the paren't shouldn't be dictating anything, the component itself should. The parent can pass things and the child can choose to use them or not but that is different: control is still in the hands of the component itself, not an arbitrary parent.
    3. The RFC is more appropriate because it does not allow a parent to abritrarily control anything below it, that responsibility still relies on the component itself. Just because people have been passing classes round and overriding child styles for years doesn't mean it is a good choice and isn't something we wnat to encourage.
    4. For my point of view, and I've been annoyingly consistent in this for as long as people have been asking for this feature or something like it, style encapsulation is one of the core principles of Svelte's component model and this feature fundamentally breaks that. It would be too easy for people to use this feature and it would definitely get abused removing the style safety that Svelte previously provided.
    5. Ideally: Only let a parent control those specific CSS properties, and never let a child use them on the root element.
    6. margin, flex, position, left, right, top, bottom, width, height, align-self, justify-self among other is CSS properties that should never be modified by the child itself. The parent should always have control of those properties, which is the whole reason I'm asking for this.
    1. I think Svelte's approach where it replaces component instances with the component markup is vastly superior to Angular and the other frameworks. It gives the developer more control over what the DOM structure looks like at runtime—which means better performance and fewer CSS headaches, and also allows the developer to create very powerful recursive components.
    1. Often, allowing the parents to compose elements to be passed into components can offer the flexibility needed to solve this problem. If a component wants to have direct control over every aspect of a component, then it should probably own the markup as well, not just the styles. Svelte's slot API makes this possible. You can still get the benefits of abstracting certain logic, markup, and styles into a component, but, the parent can take responsibility for some of that markup, including the styling, and pass it through. This is possible today.
    2. As you can see, this would mean that a change in a component is potentially no longer isolated to that component, and the entire codebase should be checked to see if anybody has been overriding the default styles.
    3. One of the main reasons to work with components is re-usability and portability, but also a delegation of responsibilities. Adding a component should be as easy as simply adding the component without having to know the inner workings (or markup) of this component. A consumer should only be aware of the properties, methods and events of a component. In order to style a child component one has to be aware of the markup as well, which violates this 'delegation of responsibility'-principle.
    1. Your styles are scoped to the component. No more leakage, no more unpredictable cascade.
    2. It's fashionable to dislike CSS. There are lots of reasons why that's the case, but it boils down to this: CSS is unpredictable. If you've never had the experience of tweaking a style rule and accidentally breaking some layout that you thought was completely unrelated — usually when you're trying to ship — then you're either new at this or you're a much better programmer than the rest of us.
    1. It turns out that even the length of time an element has been mounted is an important piece of state that determines what pixels the user sees. And some of this state can’t simply be lifted into our application state.

      What this means is that our desire to express UI using pure functions is in direct conflict with the very nature of the DOM. It’s a great way to describe a state => pixels transformation — perfect for game rendering or generative art — but when we’re building apps on the web, the idea chafes against the reality of a stateful medium.

    2. Functions have lots of interesting and useful properties. You can isolate them. You can compose them. You can memoize them. In other words, functional UI feels correct, and powerful, in a way that wasn’t true of whatever came before it. I think this is why people get quasi-religious about React. It’s not that it’s Just JavaScript. It’s that it’s Just Functions. It’s profound.

    1. A paradigm is a model or pattern. In JavaScript, there are a number of popular paradigms including object-oriented programming (OOP) and functional programming (FP). Paradigms are more important than is sometimes recognized. They help form mental models for solving problems. Becoming well-versed in the principles of a given paradigm can help accelerate development by providing mental shortcuts for solving the challenges that arise while building applications. They can also help produce higher quality software.
    1. we need to step back and make a closer look at the DRY principle. As I mentioned earlier, it stands for "Don’t Repeat Yourself" and requires that any piece of domain knowledge has a single representation in your code base. The words domain knowledge are key here. DRY is not about duplicating code. It is specifically about duplicating domain knowledge

      This is actually a good point – to have a single representation of specific piece of domain knowledge in the code.

      DRY is not about duplicating code.

    1. We wanted a library designed specifically for a functional programming style, one that makes it easy to create functional pipelines, one that never mutates user data.