☆ Yσɠƚԋσʂ ☆

  • 1.39K Posts
  • 1.11K Comments
Joined 6 years ago
cake
Cake day: January 18th, 2020

help-circle





  • Right, I think the key part to keep in mind is that color revolutions do tend to have an organic component to them. You have to have existing discontent or tensions that are exploited. The trick is to direct the discontent towards political goals that favor the west. This is done through NGOs, western media, grooming young people, and so on.

    As you point out, a spontaneous uprising isn’t going to have the necessary structures to create a functioning and independent government. When the dust settles, the existing power structures will reassert themselves, but under new leadership, one that’s likely to be favorable to the west.

















  • I find the whole thing with task estimation is largely masturbative. The reality is that the only thing you have to decide is whether the task is worth doing or not. If it is, then it needs to be done correctly, and that means it’ll take as long as it takes to finish. You can’t just cut corners on a feature for the sake of a timeline. Realistically, deciding on what tasks are a priority should be the main focus of planning. You pick the tasks that are most urgent, and then you work on them till they’re done.

    Furthermore, there are broadly two types of tasks. First, is something you’ve done before using the same tools. For that sort of task you can give a relatively accurate estimate. However, any task where you’re doing something new, or using a different tool such as a new framework, library, etc., then all best are off. Even if the task is simple conceptually, it can take a long time because there will be some weird quirk in the libraries, or how they interface together, or a million other things that can go wrong. Best you can do here is to do a research spike that’s time boxed to get a feel for how long the task will take.

    The problem is that management gets really obsessive with trying to fit work into whatever timelines are pushed onto them from up top. So they end up forcing developers to commit to some arbitrary numbers that are largely pulled out of your ass, and then either projects run overtime or they’re delivered with lots of bugs because the timeline was completely unreasonable.


  • The total number of parens in your examples is about the same, except you also have a bunch of noise like random semicolons sprinkled in. Meanwhile, nesting is a feature, not a bug because it provides you with additional visual information about relationships in code. The only people who incessantly bray about nested parens are the ones who’ve never actually worked with Lisp for any period of time. If this was a genuine problem with the syntax then stuff like sweet expressions would’ve taken off. The reality is, as I already explained and you’ve ignored, is that the editor manages the parens for you. When you work with Lisp, typing opening paren is equivalent to having a command sequence to say I’m starting a new expression.


  • OK, my code snippets are Common Lisp. But note that none of them involve list/vector/set literals. I was thinking of [] for array indexing and {} for code blocks.

    Again, Clojure uses vectors for arguments, so you end up with syntax like this which provides the same visual information as any mainstream language.

    It doesn’t solve the main issue anyway. Take this snippet from the “infix” readme:

    Yes it does actually because you have syntax hints indicating the type of data structure you’re looking at. For example, in the snippet you highlight, the function arguments are in a vector.

    It ends with a cluster of )))) (reinforcing the “lots of parentheses” impression) and all of those parentheses mean something different

    First of all, you have exact same amount of parens as you would in a mainstream language like Java, C, or Js. Second, the parens do mean the same thing in that example. The big benefit with s-exps though is that you have structural editing, and you don’t actually manage parens by hand or even think about them. You treat expressions as building blocks that you manipulate and compose together. There’s nothing even remotely comparable to this available in languages like Haskell.

    However, here’s an example for you where you don’t have same parens.

    (defn foo [{:keys [x y]}]
      (let [z (str x " " y)]
        {:result z}))
    

    here you have different data structures manipulated, and you have different parens representing them.

    From the outside in, we have the end of a symbol definition (def …), the end of a function (fn …), the end of a macro invocation (infix …), and the end of a function call sqrt(…). It definitely isn’t just “the same number [of parentheses] as any other language that uses parentheses to make function calls”.

    It’s just broken down in the example. In practice you have defn and you just write:

    (defn hypot [x y]  (infix sqrt(x ** 2 + y ** 2)))
    

    The huge advantage over Haskell is that syntax is very simple and regular. You don’t have to think about it at all. Languages like Haskell and Perl introduce a lot of mental overhead because you have to memorize all the special cases and behaviors the syntax introduces. You can write really concise code, but there’s a cost to it. There’s a reason people refer to Perl as a write only language. On the other hand, Clojure hits the sweet spot of being very concise without needing a complex syntax.






  • This is false, Lisp is a family of languages. Clojure is an example of a Lisp where you have different types of literals using () for lists, [] for vectors, {} for maps, and #{} for sets. Furthermore, there are plenty of libraries for doing infix syntax which can be trivially expressed using macros. For example, infix library in Clojure lets you write math using infix syntax. That said, it’s pretty rare that you’re actually writing a bunch of math expressions in regular code unless you’re working in a specific domain, so this hardly comes up in practice.