48 Matching Annotations
  1. Jan 2024
    1. You should take care, however, to make sure that your individual objects can stand alone as much as possible. Tightly coupled objects are objects that rely so heavily on each other that removing or changing one will mean that you have to completely change another one - a real bummer.

      Isn't there a conflict between this principle and code reusability?

  2. Jun 2023
  3. May 2023
    1. Web sites often design their APIs to optimize performance forcommon cases. Their main object-reading methods may return onlycertain “basic” properties of objects, with other methods availablefor fetching other properties. ShapirJS hides this performanceoptimization complexity from the user.

      In other words, it risks undermining the intent of the API design.

    1. Available as a monolithic file, by chapters, and in PDF — git repository.

      What a cool documentation design; I love the all-in-one layout.

      Very reminiscent of the old CoffeeScript docs, to me.

  4. Jan 2023
    1. Considerations

      What about chained dotted access? foo.bar.baz is probably okay as bar.baz @ (the Foo) (or even @the Foo), but probably not if it takes the form bar.baz from the Foo. (It just doesn't look reasonable to me.)

      Alternatively, what about @bar.baz for the Foo?

    1. In Lua you can write raw, multiline strings with [[]]: [[ Alice said "Bob said 'hi'". ]]

      This is indeed very good (for the reasons stated here).

    1. how important is the concrete syntax of their language in contrast to

      how important is the concrete syntax of their language in contrast to the abstract concepts behind them what I mean they say can someone somewhat awkward concrete syntax be an obstacle when it comes to the acceptance

  5. Nov 2022
    1. there is no single perfect universal programming language. Until I came to that point, I wasted a lot of time thinking that GW-BASIC QBASIC QB 4.5 VB4 Delphi Java C++ C# 1.0 was the only language I would ever need
  6. Sep 2022
    1. The LISP part, though, is not going well. Porting clever 1970s Stanford AI Lab macros written on the original SAIL machine to modern Common LISP is hard. Anybody with a knowledge of MACLISP want to help?
  7. Aug 2022
    1. Obnoxious.

      As someone recently pointed out on HN, it's very common nowadays to encounter the no-one-knows-else-what-they're-doing-here refrain as cover—I don't have to feel insecure about not understanding this because not only am I not alone, nobody else understands it either.

      Secondly, if your code is hard to understand regarding its use of this, then your code his hard to understand. this isn't super easy, but it's also not hard. Your code (or the code you're being made to wade into) probably just sucks. The this confusion is making you confront it, though, instead of letting it otherwise fly under the radar.* So fix it and stop going in for the low-effort, this-centric clapter.

      * Not claiming here that this is unique; there are allowed to be other things that work as the same sort of indicator.

  8. Jun 2022
  9. May 2022
    1. an acknowledgement of network effects: LP is unlikely to ever catch on enough to be the majority, so there needs to be a way for a random programmer using their preferred IDE/editor to edit a "literate" program

      This is part of the reason why I advocate for language skins for comparatively esoteric languages like Ada.

    1. memory usage and (lack of) parallelism are concerns

      Memory usage is a concern? wat

      It's a problem, sure, if you're programming the way NPMers do. So don't do that.

      This is a huge problem I've noticed when it comes to people programming in JS—even, bizarrely, people coming from other languages like Java or C# and where you'd expect them to at least try to continue to do things in JS just like they're comfortable doing in their own language. Just because it's there (i.e. possible in the language, e.g. dynamic language features) doesn't mean you have to use it...

      (Relevant: How (and why) developers use the dynamic features of programming languages https://users.dcc.uchile.cl/~rrobbes/p/EMSE-features.pdf)

      The really annoying thing is that the NPM style isn't even idiomatic for the language! So much of what the NodeJS camp does is so clearly done in frustration and the byproduct of a desire to work against the language. Case in point: the absolutely nonsensical attitude about always using triple equals (as if to ward off some evil spirits) and the undeniable contempt that so many have for this.

  10. www.mindprod.com www.mindprod.com
    1. local a (e.g. aPoint) param p (e.g. pPoint) member instance m (e.g. mPoint) static s (e.g. sPoint)

      This is really only a problem in languages that make the unfortunate mistake of allowing references to unqualified names that get fixed up as if the programmer had written this.mPoint or Foo.point. Even if you're writing in a language where that's possible, just don't write code like that! Just because you can doesn't mean you have to.

      The only real exception is distinguishing locals from parameters. Keep your procedures short and it's less of a problem.

    1. This can get much worse than the above example; the number of \’s required is exponential in the nesting depth. Rc fixes this by making the backquote a unary operator whose argument is a command, like this: size=‘{wc -l ‘{ls -t|sed 1q}}
  11. Apr 2022
    1. comparing the event and window.event isn't enough to know if event is a variable in scope in the function or if it's being looked up in the window object

      Sounds like a good use case for an expansion to the jsmirrors API.

  12. Mar 2022
    1. In 1994, The Unix-Haters Handbook was published containing a long list of missives about the software—everything from overly-cryptic command names that were optimized for Teletype machines, to irreversible file deletion, to unintuitive programs with far too many options. Over twenty years later, an overwhelming majority of these complaints are still valid even across the dozens of modern derivatives. Unix had become so widely used that changing its behavior would have challenging implications. For better
    1. Object hierarchies are very different from relational hierarchies. Relational hierarchies focus on data and its relationships, whereas objects manage not only data, but also their identity and the behavior centered around that data.
    1. Understanding a strange codebase is hard.

      John Nagle is fond of making the observation that there are three fundamental and recurring questions that dominate one's concerns when programming in C.

      More broadly (speaking of software development generally), one of the two big frustrations I have when dealing with a foreign codebase is the simple question, "Where the hell does this type/function come from?" (esp. in C and, unfortunately, in Go, too, since the team didn't take the opportunity to fix it there when they could have...). There's something to be said for Intellisense-like smarts in IDEs, but I think the criticism of IDEs is justified. I shouldn't need an IDE just to be able to make sense of what I'm reading.

      The other big frustration I often have is "Where does the program really start?" Gilad Bracha seems to really get this, from what I've understood of his descriptions about how module definitions work in Newspeak. Even though it's reviled, I think Java was really shrewd about its decisions here (and on the previous problem, too, for that matter—don't know exactly where FooBar comes from? welp, at least you can be reasonably sure that it's in a file called FooBar.java somewhere, so you can do a simple (and cheap) search across file names instead of a (slow, more expensive) full-text search). Except for static initializers, Java classes are just definitions. You don't get to have live code in the top-level scope the way you can with JS or Python or Go. As cumbersome as Java's design decision might feel like it's getting in your way when you're working on your own projects and no matter how much you hate it for making you pay the boilerplate tax, when it comes to diving in to a foreign codebase, it's great when modules are "inert". They don't get to do anything, save for changing the visibility of some symbol (e.g. the FooBar of FooBar.java). If you want to know how a program works, then you can trace the whole thing, in theory, starting from main. That's really convenient when it means you don't have to think about how something might be dependent on a loop in an arbitrary file that immediately executes on import, or any other top-level diddling (i.e. critical functionality obscured by some esoteric global mutable state).

  13. Dec 2021
  14. Nov 2021
  15. Oct 2021
  16. Jun 2021
  17. Apr 2021
  18. Feb 2021
    1. provide interfaces so you don’t have to think about them

      Question to myself: Is not having to think about it actually a good goal to have? Is it at odds with making intentional/well-considered decisions?  Obviously there are still many of interesting decisions to make even when using a framework that provides conventions and standardization and makes some decisions for you...

    1. I think a better, more immediately understandable name for this concept would be command object, because it lets you pass around commands (or a list of commands) as objects.

      That's the only thing you really need to know abut this pattern. The rest seems like boring implementation details that aren't that important, and that naturally follow from the primary definition above.

    1. In programming language design, a first-class citizen (also type, object, entity, or value) in a given programming language is an entity which supports all the operations generally available to other entities. These operations typically include being passed as an argument, returned from a function, modified, and assigned to a variable.
    1. In object-oriented programming, information hiding (by way of nesting of types) reduces software development risk by shifting the code's dependency on an uncertain implementation (design decision) onto a well-defined interface. Clients of the interface perform operations purely through it so if the implementation changes, the clients do not have to change.
  19. Oct 2020
    1. 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.
  20. 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. 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.
    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.

  21. May 2020
    1. Don’t go to code academy, go to design academy. Be advocates of the user & consumer. It’s not about learning how to code, it’s about translating real-world needs to technological specifications in just ways that give end users agency and equity in design, development and delivery. Be a champion of user-centric design. Learn how to steward data and offer your help.

      The importance of learning to design, and interpreting/translating real-world needs.

  22. Feb 2019
  23. Jan 2019
    1. If one object is part of another object, then we use a diamond at the start of the arrow (next to the containing object), and a normal arrow at the end.

      Another way of thinking of this is, if the original owner (source) object and the owned (target) object share the same life cycle -- that is, the owned exists only when the owner does -- we say that the owner aggregates owned object(s). They share a whole-part relationship.

      What I did like very much about the video, was when the instructor pointed out that there's a small fallacy: aggregation, in OOD, does not really imply that owned object(s) must be a list.

  24. Nov 2018
    1. One thing Component taught me was to think of the entire system like an Object. Specifically, there is state that needs to be managed. So I suggest you think about -main as initializing your system state. Your system needs an http client, so initialize it before you do anything else

      software design state on the outside, before anything else lessions from Component

  25. Oct 2018
    1. Rob Pike has described Plan 9 as "an argument" for simplicity and clarity, while others have described it as "UNIX, only moreso."

      idea of a system as an argument pointed out by: https://twitter.com/rsnous/status/1054631468142493696

  26. Aug 2017
  27. Apr 2015
    1. Do you need to learn code to use The Grid? No coding is required to use The Grid. Just do what you're already doing on Facebook, Twitter, Instagram, etc. Post images, video, and content to your site and our AI Designer will make it beautiful. If you know code, you can extend functionality using our platform tools and API.

      Coding skills are a plus but not necessary. Accessibility!...

  28. Jan 2014
    1. Once you abandon entirely the crazy idea that the type of a value has anything whatsoever to do with the storage, it becomes much easier to reason about it. Of course, my point above stands: you don't need to reason about it unless you are writing unsafe code or doing some sort of heavy interoperating with unmanaged code. Let the compiler and the runtime manage the lifetime of your storage locations; that's what its good at.

      Understanding what you should (and should not) reason about in the language you are using is an important part of good programming; and a language that lets you reason (nee worry) about only the things you need to worry about is an important part of a good programming language.