1. 3

    A message veiled into a personal learning story to make it more palatable. I would not care much, but it scratches an itch.

    We got a slight tests vs. type checking going in the middle of the lines. These subjects should not be dumped together because you may also do Python without any tools and get along just fine.

    My opinion about types and type checking has changed as well, but it has grown to very different direction than the posters. I also have had some sort of enlightenment going along. I am a die-hard dynamic-typing proponent. I did not need a static type system, and I neither needed tests. The author had to work with something else than Python to form his opinion. I had to go into other direction, deeper into Python and finally into my own improved variation of Python.

    If type checking is sound, and if it is decidable, then it must be incomplete. I’ve realized this is really important as the set of correct and useful programs that do not pass a type checker is large. Worse, often these are the most important sort of programs that spares a person from stupid or menial work.

    “If it compiles, it works” and “type system make unit tests unnecessary” are hogwash. It doesn’t really matter how much you repeat them or whether you clothe them into a learning story. There was a recent post pointing out how difficult it is to construct a proof that some small program is actually correct. This means you cannot expect that program works or is correct despite that it types correctly in any language.

    There is an aspect that is required for making computation and logical reasoning possible in the first place. That is in recognizing variant and invariant parts of the program. I’ve realized that spamming variants is the issue in modern dynamically typed languages. That cannot be solved by adding type annotations because you still have tons of variables in your code that could theoretically change. And you really have to check whether they do, otherwise you have not verified that your program is correct.

    Statically typed languages commonly do better in keeping variances smaller, but they are also stupid in the sense that they introduce additional false invariants that you are required to satisfy in order to make the type checking succeed. And you cannot evaluate the program before the type checker is satisfied. This is an arbitrary limitation and I think people defending this for any reason are just dumb. Type checker shouldn’t be a straitjacket for your language. It should be a tool and only required when you’re going to formally verify or optimize something.

    During working on software I’ve realized the best workflow is to make the software work first, then later validate and optimize. Languages like Python are good for the first purpose while some ML-variants are good for the middle, and for the optimization C and similar are good. So our programming languages have been written orthogonal, to cross with the workflow that makes most sense.

    1. 19

      the set of correct and useful programs that do not pass a type checker is large

      If it’s large then you should be able to give a few convincing examples.

      1. 5

        I haven’t had the problem the quote implies. The basic, type systems were about enforcing specific properties throughout the codebase and/or catching specific kinds of errors. They seem to do that fine in any language designed well. When designers slip up, users notice with it becoming a best practice to avoid whatever causes protection scheme to fail.

        Essentially, the type system blocks some of the most damaging kinds of errors so I can focus on other verification conditions or errors it can prevent. It reduces my mental burden letting me track less stuff. One can design incredibly-difficult, type systems that try to do everything under the sun which can add as many problems as they subtract. That’s a different conversation, though.

        1. 1

          This set includes programs that could be put to pass a type checker, given that you put extra work into it, or use a specific type checker for them. Otherwise that set is empty: For every program you can construct such variation where the parts that do not type check are lifted outside from the realm of the type checker. For example. stringly typed code.

          The recipe to construct a program that does not pass a type checker is to vary things that have to be invariant for the type checker. For example, if you have a function that loads a function, we cannot determine the type for the function that is produced. If the loaded function behaves like an ordinary function, it may result in a dilemma that you may have to resolve either by giving it some weird different type that includes the idea that you do not know the call signature, or by not type checking the program.

          Analogous to the function example: If you define creation of an abstract datatype as a program, then you also have a situation where the abstract datatype may exist, but you cannot type the program that creates it, and you will know the type information for the datatype only after the program has finished.

          And also consider this: When you write software, you are yourself doing effort to verify that it does what you want. People are not very formal though, and you will likely find ways to prove yourself that the program works, but it does not necessarily align with the way the system thinks about your program. And you are likely to vary the ways you use to conclude the thing works because you are not restricted to just one way of thinking about code. This is also visible in type systems that themselves can be wildly different from each other, such that the same form of a same program does not type in an another type system.

          I think for the future I’ll try to pick up examples of this kind of tricky situations. I am going to encounter them in the future because in my newest language I’ll have a type inference and checking integrated into the language, despite that the language is very dynamic by nature.

          There is some work involved in giving you proper examples, and I think people have already moved to reading something else when I finish, but we’ll eventually resume to this subject anyway.

          1. 6

            Looking forward to seeing your examples, but until then we don’t have any way to evaluate your claims.

            About your function loading example, that may or may not be typeable, depending on the deserialisation mechanism. Again, can’t really say without seeing an example.

            1. 6

              When you write software, you are yourself doing effort to verify that it does what you want.

              That’s exactly why I find type systems so useful. I’m doing the effort when writing the code either way; types give me a way to write down why it works. If I don’t write it down, I have to figure out why it works all over again every time I come back to the code.

          2. 6

            A message veiled into a personal learning story to make it more palatable.

            Why do you think this is veiled message instead of an actual personal story?

            1. 5

              If type checking is sound, and if it is decidable, then it must be incomplete.

              Only if you assume that some large set of programs must be valuable. In my experience useful programs are constructive, based on human-friendly constructions, and so we can use a much more restricted language than something Turing-complete.

              1. 1

                If type checking is sound, and if it is decidable, then it must be incomplete.

                That’s not a bug. That’s a feature.

                If you can implement a particular code feature in a language subset that is restricted from Turing completeness, then you should. It makes the code less likely to have a security vulnerability or bug. (See LangSec)

              1. 1

                You forgot to point out that Python provides a traceback:

                Traceback (most recent call last):
                  File "smalldemo.py", line 17, in <module>
                  File "smalldemo.py", line 8, in main
                  File "smalldemo.py", line 11, in bar
                  File "smalldemo.py", line 14, in foo
                    value = target.a['b']['c']
                KeyError: 'b'

                And the varying error messages it gives is enough to pinpoint which one of these operations failed.

                It looks like a good exercise project though. Someone saw time to work out the documentation and it didn’t fail entirely explaining what this thing is doing. Good exercise especially for the purposes of explaining what’s the purpose of that thing. It can get tricky.

                1. 2

                  EDIT I just realized that you were referring to the author’s statement about which dict get is causing the error. My statement below is not relevant to that.

                  The traceback is good, but if you are getting lots of deeply nested json documents some fields might be present on one document and not on another within the same collection. So you end up in this loop where you process a piece of the collection, hit an exception, stop and fix it. Repeat this a while until you think the code is stable. Then at some point in the future you end up with another piece of a new collection that blows up. C’est la vie.

                  1. 2

                    Trust me, no forgetfulness occurred here. If 'b' and 'c' were variables, which they commonly are, you wouldn’t know which one had the value which caused the KeyError. And furthermore, the example was more about the TypeErrors, such as the one raised when a dictionary is replaced with a list.

                    The traceback sheds no light on that. The only way to make the traceback work is to split up the operation into multiple lines, and that’s why that code ends up verbose and un-Pythonic.

                  1. 3

                    It would be better to talk about tagged records in place of sum types because you would then immediately understand what the subject is about.

                    I’m commenting because I think it’s interesting to point out. I plan to write a type system into my language that relies on conversions between types, and on tagged records. It won’t have typecases though, because I thought out that the definition of type ended up being very unstable. Also the type annotations do not really have a reason to feedback into the value space.

                    1. 2

                      This thing feels genuine, but I can’t stop the feeling that something is missing.

                      1. 1

                        This thing feels genuine, but I can’t stop the feeling that something is missing.

                        The BBS interface. ;)

                      1. 15

                        What happened? Did Oracle find a judge who does not know programming?

                        1. 29

                          In 2010, Oracle sued Google. In 2012, District Court ruled API uncopyrightable. In 2014, Appeals Court ruled API copyrightable. Google petitioned Supreme Court, which denied the petition. In 2016, District Court, operating under the assumption that API is copyrightable, ruled Google’s use was fair use. In 2018, Appeals Court ruled Google’s use was not fair use. Now the case is back in District Court to determine the damage, operating under the assumption that API is copyrightable and Google’s use was not fair use.

                          1. 3

                            Most people do not understand the significance of this decision, so it’s enough for Oracle to re-roll the dice until they get the answer they want.

                            Besides I think the crowds inflate the significance of this. It’s almost as if somebody unconditionally respected copyrights here.

                          1. 1

                            Reorder items not appearing in the LCS, but present in the structures.

                            What’s an LCS?

                            1. 1

                              LCS is an acronym for the longest common subsequence problem. You may know it if you’ve studied how diff works because it’s one, but not only, way to calculate diff between two text files. The point to using it here is to keep the moving of indeterminates few while shuffling them into same order. LCS reveals the longest sequence of indeterminates that are already in the same order.

                              I added this into the post as well.

                            1. 1

                              Most of the points raised in the post are quite awful.

                              1. If you don’t write code that can be read, then you should learn. Don’t use comments as a crutch as that will fail.
                              2. You can have ‘sections’ titled with comments, but your code should be structured-enough to not need them.
                              3. Author, date, license, copyright: These things do not belong into the code. Author info belongs to the AUTHORS -file and git. Date comes from ctime&git. License belongs to the LICENSE -file. Copyright is implied.
                              4. All rules fly out of the window with esolangs.
                              5. Appeal to authority. Very convincing.
                              6. Generating documentation out of your comments is an ugly and terrible way to do documentation.
                              7. TODO is indeed great way to use comments. Though hilariously often you notice that the TODO can be just removed because there was a better way to do the same thing, or the thing in TODO didn’t matter after all.

                              The things that the code doesn’t tell, or things that are hard to gather from the code should go into the comments.

                              When I think something is even slightly surprising later on, I write a comment to describe why it’s there and what it’s needed for. That has turned out to be useful because it allows you to resume on the code much faster than otherwise.

                              1. 2

                                To me this reads like recommendations for internal corporate code shops.

                                1. 2

                                  If you don’t write code that can be read, then you should learn. Don’t use comments as a crutch as that will fail.

                                  A nice ideal, but why insist that code take on the job of conveying the full semantic intent of the algorithm it’s implementing? Including natural language comments can separate the concern of semantic communication from the concern of accurate and clear implementation.

                                  1. 1

                                    I do not think that I did insist anything like that.

                                    Readability is about the ability to understand the written code. There is no emphasis that you’d tell anything more than what the code would inherently tell.

                                1. 6

                                  This is a problem with any score-keeping or “gamification” mechanism online.

                                  • You often forget the fun part and take the scoreboard to measure who’s the better person. Until you realize it does not matter. It never mattered anywhere. You see life is full of scoreboards like that, starting out from the school. Lot of people want something from you and they scapegoat it into scoreboards.
                                  • The score-keeping is always disjointed from what is desired (good attendance to discussion, good articles, great questions/answers)
                                  • There are people who love playing, and they take the optimal route to gain score. This often means that they “drop the payload” that the whole score-keeping system was supposed to support.

                                  Though I honestly wonder where people go to talk once reddit/lobsters has been explored..

                                  1. 5

                                    Though I honestly wonder where people go to talk once reddit/lobsters has been explored..


                                    1. 2

                                      When I joined reddit years ago I cared about my karma count so much and I would delete comments when they start to get downvoted so I wouldn’t lose my karma but after hitting about 10k I stopped caring and now I can say what I want and stand behind it even if it’s not a popular opinion.

                                      Reminds me of that first episode of black mirror season 3. Only when you ignore scoring systems can you truly be free.

                                    1. 1

                                      I had a friend visit over to learn programming few days ago. That made me finally realize what’s wrong with Quorum.

                                      I was teaching basics of Java: variables, types, conditionals, constants, methods. I showed the friend how to think about programming by writing a naive Fibonacci function from its definition, discussed properties of the produced code and such. And after few minutes prompted him to do the same exercise with the factorial function.

                                      I told him to not care about java’s syntax and write down the ideas first. The code he ended up writing was something like:

                                      static public void factorial() {
                                          if n = 0 then factorial = 1
                                          if n = 1 then factorial = 1
                                          else if n=2 then factorial * factorial - 1

                                      Well.. You see some obvious BASIC influence there. There are other influences of languages commonly used for training people.

                                      I then helped him by rewriting these concepts to actual Java and left him the recursive part of the code left to figure out on himself. Again discussing what is going on there.

                                      The problem is that practically there is no human being on the Earth who has not been learning some programming before. If you ask their opinion with A/B tests then they tend to pick patterns that are familiar to them.

                                      What’s familiar for today’s people is not going to be that for tomorrow people.

                                      1. 2

                                        It sounds like this page misuses the “straw man” -term.

                                        To “attack a straw man” is to refute an argument that was not made by anyone.

                                        There are people who have used these arguments, and they’re only strawmen in the sense that they have been disassociated from the people who made the arguments.

                                        1. 5

                                          To “attack a straw man” is to refute an argument that was not made by anyone.

                                          While this might be a definition, it’s most certainly not the only one peope think of when talking about “straw man” or “straw person” arguments. Another usage I have hear people use, and what I understand this page to imply, is to simplify or stupidify an opponents position, and then attack this easily attackable argument, thereby avoiding the actual issue. I belive that this is being done here, they take points raised against Lisp and lisp like languages, and show that these either miss the point or don’t really make sense anyways.

                                          But regardlessly, if it’s a “misuse” of the term or not, I belive everyone on this site is bright enoug to understand what is intended, regardless of this or that proposed formal definition, as well as being able to enjoy an article in it’s own merit, instead of an abstract notion of total semantical correctness in regards to each term, especially when it’s not crucial to the intend of the piece.

                                        1. 2

                                          The update on how the performance characteristics of this thing changed after JIT would have been interesting. The paper’s 11 years old now.

                                          1. 3

                                            There’s a follow-up paper (2010) with the JIT implemented and reporting some benchmarks. I don’t think the project continued after that, although the lead author has continued research in related areas.

                                            1. 2

                                              Oh darn, I didn’t realize he was also an author of a paper I was saving for next week when more readers are on. He’s doing some clever stuff. Interestingly, he also ported Squeak to Python while Squeak people made it easier to debug Python using Squeak’s tooling. Some odd, interesting connections happening there.

                                          1. 0

                                            I hate this project. It’s had big names, big fanfares, big talks, big money grants, they were hiring people.

                                            But very little was done that mattered in the end. We barely remember this project by now. Nobody even cares about this thing in 15 years. It created absolutely nothing of value and all the ideas presented were already done better in 1980s. It was kind of Bret Victorian in that sense.

                                            And now it’s going to die. If they had just pushed on something might have come out of this. Now it is guaranteed that everything of this will be forgotten in very short time.

                                            If you try to shoot at the moon, at least.. Could you try to aim upwards and put enough fuel into the tank?

                                            1. 2

                                              I love all the saltiness. I wish the GPU prices would still rise a little bit more so we’d see more bickering.

                                              I think the prices keep rising though. Crypto prices are rising and it’ll be profitable to buy those cards off from shelves.

                                              There’s hard time seeing how this could be bad except for few PC enthusiasts who end up having to pay a bit more for their hardware in the short term. GPU hardware also faces demand for improvement for general purpose parallel workloads and it cannot happen only within the terms of cryptocurrency mining because the demand it creates can collapse without a warning.

                                              Good times ahead.

                                              1. 1

                                                There are plenty of tutorials like this out there. Some are cross-platform, this one is Linux-only and omits the W^X limit that’s wanted these days. Most of these write hexadecimals into a buffer and then call it.

                                                I’m a bit tired to seeing clones from the same story. It’d be nice if people writing new tutorials would sometimes continue from someone else’s tutorial.

                                                1. 5

                                                  The post in question Big-O: how code slows as data grows

                                                  The comment by ‘pyon’:

                                                  You should be ashamed of this post. How dare you mislead your readers? In amortized analysis, earlier cheap operations pay the cost of later expensive ones. By the time you need to perform an expensive operation, you will have performed enough cheap ones, so that the cost of the entire sequence of operations is bounded above by the sum of their amortized costs. To fix your list example: a sequence of cheap list inserts pays the cost of the expensive one that comes next.

                                                  If you discard the emotion, he gives out a fairly interesting additional note about what amortized analysis means. Instead of giving the information value, Ned reacts on the part that questions his authority. Such a brittle ego that puts you to writing a small novel worth’s of rhetoric instead of shrugging it off. Childish.

                                                  1. 52

                                                    If @pyon had just phrased the first part of the comment like “You’re making a number of simpliications regarding “amortization” here that I believe are important…” this would probably not have escalated. This is what Ned means with being toxic - being correct, and being a douche about it.

                                                    1. 10

                                                      Indeed; the original article appeared on Lobsters and featured a thoughtful discussion on amortization.

                                                      1. 2

                                                        I wonder whether better word choice without changing the meaning would help one step earlier: the original post did include «you may see the word “amortized” thrown around. That’s a fancy word for “average”», which sounds a bit dismissive towards the actual theory. Something like «Notions of ‘‘amortized’’ and ‘‘average’’ complexity are close enough for most applications» would sound much more friendly.

                                                        (And then the follow-up paints the previous post as if it was a decision to omit a detail, instead of a minor incorrectness in the text as written, which can be (maybe unconsciously) used to paint the situation as «correctness versus politeness», and then options get represented as if they were mutually exclusive)

                                                        1. 4

                                                          I feel like that would have put the author in a more defensible position on this specific point, yes. Being clear about where additional nuance exists and where it doesn’t is something that anyone writing about technical subjects should strive for, simply because it’s useful to the reader.

                                                          I don’t think it’s likely that that clarification would have much of an effect on most readers, since the hypothetical reader who’s mislead would have to study complexity theory for some years to get to the point where it’s relevant, and by that time they’ll probably have figured it out some other way. We should all be so lucky as to write things that need several years of study before their imperfections become clear. :)

                                                          But more to the point, while I can’t know anything about this specific commenter’s intent, somebody who’s determined to find fault can always do so. Nobody is perfect, and any piece of writing can be nit-picked.

                                                          1. 1

                                                            Several years sounds like an upper bound for an eventually succesful attempt. A couple months can be enough to reach the point in a good algorithms textbook where this difference becomes relevant and clear (and I do not mean that someone would do nothing but read the textbook).

                                                            I would hope that the best-case effect on the readers could be a strong hint that there is something to go find in a textbook. If someone has just found out that big-O notation exists and liked how it allows to explain the practical difference between some algorithms, it is exactly the time to tell them «there is much more of this topic to learn».

                                                            These two posts together theoretically could — as a background to the things actually discussed in them — create an opposite impression, but hopefully it is just my view as a person who already knows the actual details and no newbie will actually get the feeling that the details of the theory are useless and not interesting.

                                                            As for finding something to nitpick — my question was whether the tone of the original paragraph could have made it not «finding» but «noticing the obvious». And whether the tone may have changed — but probably nobody will ever know, even the participants of the exchange — the desire to put a «well, actually…» comment into the desire to complain.

                                                            1. 3

                                                              Not having previous familiarity with this subject matter, I was guessing at how advanced the material was. :)

                                                              I agree about your best case, and that it’s worth trying for whenever we write.

                                                              I’ve never found anything that avoids the occasional “well, actually”, and not for want of trying. This is not an invitation to tell me how to; I think it’s best for everyone if we leave the topic there. :)

                                                              1. 1

                                                                I consider a polite «well, actually» a positive outcome… (Anything starting with a personal attack is not that, of course)

                                                      2. 25

                                                        It’s possible to share a fairly interesting additional note without also yelling at people. Regardless of what Pyon had to say, he was saying it in a very toxic manner. That’s also childish.

                                                        1. 5

                                                          Correct. But I don’t just care about the emotion. I care about the message.

                                                          Instead of trying to change web into a safe haven of some kind, why not admire it in its colors? Colors of mud and excrete among the colors of flowers and warmth, madness and clarity. You have very little power over having people get angry or aggressive about petty things. Though you can change a lot yourself and not take up about everything that’s said. Teaching your community this skill is also a pretty valuable in life overall.

                                                          1. 32

                                                            I don’t want my community to be defined by anger and aggression. I want beginners to feel like they can openly ask questions without being raged or laughed at. I want people to be able to share their knowledge without being told they don’t deserve to program. I want things to be better than they currently are.

                                                            Maintaining a welcoming, respectful community is hard work and depends on every member being committed to it. Part of that hard work is calling out toxic behavior.

                                                            1. 5

                                                              I want beginners to feel like they can openly ask questions without being raged or laughed at.

                                                              While I agree this is critically important, it’s not entirely fair to conflate “beginners asking questions” and “people writing authoritative blog posts”.

                                                            2. 10

                                                              Yeah. That kind of self-regulation and dedication to finding signal in noise are endlessly rewarding traits worth practicing. And to extend your metaphor, we weed the garden because otherwise they’ll choke out some of the flowers.

                                                              1. 5

                                                                But I don’t just care about the emotion. I care about the message.

                                                                I’m with you unless the message includes clear harm. I’ll try to resist its affect on me but advocate such messages are gone. That commenter was being an asshole on top of delivering some useful information. Discouraging the personal attacks increases number of people who will want to participate and share information. As Ned notes, such comment sections or forums also get more beginner friendly. I’m always fine with a general rule for civility in comments for such proven benefits.

                                                                Edit: While this is about a toxic @pyon comment, I think I should also illustrate one like I’m advocating for that delivers great information without any attacks. pyon has delivered quite a lot of them in discussions on programming language theory. Here’s one on hypergraphs:


                                                                1. 5

                                                                  I personally always care about the emotion (as an individual, not as a site moderator), it’s an important component of any communication between humans. But I understand your perspective as well.

                                                                  1. 3

                                                                    I may have been unclear. I do too. I was just looking at it from other commenters’ perspective of how Id think if I didnt care about it but wanted good info and opportunities in programming sphere. Id still have to reduce harm/toxicity to other people by ground rules to foster good discussion and bring more people in.

                                                                    So, whether emotional or not, still cant discount the emotional effect of comments on others. Still should put some thought into that with reducing personal attacks being among easiest compromise as they add nothing to discussions.

                                                                    1. 2

                                                                      Ah! Okay. I misunderstood then, and it sounds like we’re in agreement.

                                                                2. 4

                                                                  It’s ridiculous to say that if someone cannot ignore personal attacks, they have a brittle ego and are childish. While also defending personal attacks and vitriol as being the thing that we should celebrate about the internet. Rather, we should critique people for being assholes. The comment was critiquing the manner and tone in which he explained amortized analysis, but he’s not allowed to say that the comment’s manner and tone was bad? It’s ridiculous. The comment was bad, not because of the point it made, but because it made the point badly.

                                                              2. 22

                                                                Compare this approach:

                                                                I believe this post simplifies the idea incorrectly. In amortized analysis, earlier (cheap) operations pay the cost of later (expensive) ones. When you need to perform an expensive operation, you will have performed enough cheap ones that the cost of the entire sequence of operations is bounded by the sum of their amortized costs. In the context of your list example, a sequence of cheap list inserts would pay the cost of the expensive one that comes next.

                                                                This is the same content, free of “shame” and accusations of “misleading.” The original comment is a perfect example of the terrible tone that people take, as discussed in this post and in my previous post of Simon Peyton-Jones’ email.

                                                                1. 4

                                                                  Instead of giving the information value, Ned reacts on the part that questions his authority.

                                                                  The author does give it value. You’ve missed the point. The author isn’t saying it’s incorrect or not valuable; he’s saying that this attitude from experts (who use their expertise as a tool to put others down) is highly toxic.

                                                                  1. 4

                                                                    If you discard the emotion, he gives out a fairly interesting additional note about what amortized analysis means. Instead of giving the information value, Ned reacts on the part that questions his authority.

                                                                    It’s not clear that Ned interprets pyon as questioning his authority. His criticism is of pyon‘s tone, which is histrionic. The cutting intro isn’t bad if we discard it; but what is the effect if we include it? It would be more balanced for Ned to discuss the details and value of pyon’s post, but that does not invalidate Ned’s point.

                                                                  1. 2

                                                                    I find lots of statements about hate and negatives. It’s funny when I thought the title belongs to a story about motivation.

                                                                    1. 2

                                                                      People don’t quit because of all the things they like.

                                                                    1. 3

                                                                      I found it really hard to track what the author really tries to explain here at first. But…

                                                                      It’s easy to hear critiques of static typing and interpret them as “static typing is bad”. Rich Hickey was certainly not doing that. He had a particular problem to solve and was noting how static typing was not particularly well-suited to that problem.

                                                                      What I gather so far is that somebody/some people became agitated because they absolutely love static typing and love towards dynamic typing is inexcusable to them. This post attempts to keep up relations and rebuild the burnt nerves.

                                                                      I find the whole discussion retarded. Idiotic. And I’ve participated in it many times defending my favorite and demoting the opponent. I’ve been pretty dumb in this sense, and I will probably still do something equally as dumb.

                                                                      Static vs. dynamic typing debates are harmful because it forms an irrational bias depending on which group you feel to belong into. It leads to early dismissal of ideas that could otherwise fly.

                                                                      Static vs. dynamic typing debates are almost always centered about languages each one participant use to participate with. If you look at the selection that is available, you can find an awful specimen of a dynamically typed language as well you can find one for statically typed languages. “That’s not really a statically/dynamically typed language” Congratulations for a yet another great sample of “no true Scotsman” argument, your very little own inbred brainchild nobody shares with you!

                                                                      “But it’s not type safe.” – No type checking before runtime, which means no type safety. Of course not! That’s kind of type safety is consequence of static typing. Btw. if you do this you usually have an axiom that safety is paramount and cannot be compromised. Ironically you compromise it yourself because type safety is not same as safety, and you deny yourself the discussion around that subject.

                                                                      “This is too restrictive!” – Well.. um. What? Do you know how restrictive do I find the lack of operator overloading in Javascript? Restrictivity is not strictly a property of static typing. It’s a result from a dull mind and opponent’s belief you took as your weapon. The belief that the most annoying restrictions in his type system are a protection against misuse.

                                                                      Every other babble and argument you usually throw up with Static vs. dynamic is emotional in nature. It is rare to see someone admire and observe the differences to learn something. It’s more like you’re trying to protect your tribe from some imaginary conclusion, or an imaginary opinion in worst!

                                                                      Take the The dark side of java (1997) and replace the “Java” with your language of choice and the story holds true. This is all about that, nothing else.

                                                                      1. 1

                                                                        “But it’s not type safe.”

                                                                        I agree that this is not an argument, but for a different reason. What do people mean by type safety? The original definition is about progress and preservation. Under this definition all dynamically typed languages are type safe because they do not get stuck.

                                                                        Sometimes people actually mean memory safety, but dynamically typed languages are memory safe as well.

                                                                        The safety the static camp desires is actually about the contract between caller and caller. Which parameters are allowed and which are not. I do not know a term for that, though.

                                                                      1. 3

                                                                        It’s surprisingly better written article than expected. It walks upwards from facts and produces a chain of reasoning.

                                                                        But.. The propositions to harden with flags seem quite fragile. When you leave a flag away, or if your compiler ignores it, the protections are no longer produced.

                                                                        Not a nice thing really.

                                                                        1. 1

                                                                          The article does say that you should test that the binaries produced are instrumented, and does mention that doing so is a bit tricky.

                                                                        1. 6

                                                                          The most despicable thing I’ve seen is a person who makes a victim of himself or a group they represent. The instance I remember was a man who said he was poorly educated because he was poor financially. Every time when I offered new ideas and/or teaching, it was seen as an assertion of oneself. That was a one way to live and I’m not blaming him for it. But my sympathy response on that eventually eroded away.

                                                                          By the way, I agree with the conclusion of this article. If you keep repeating “java sucks lol”, although there were facts to support your claim, it matters where you represent that claim and why. You might have ended up to use it as a mantra. I’ve observed that mantras are often associated with a blunt mind.

                                                                          1. 4

                                                                            You have to acknowledge the limitations of everything. You should never be a fanboy. I use to like PHP, then I looked at the internals. Then I ran into the weird comparison bugs. Then I had to deal with PHP apps at scale.

                                                                            Back in the 90s I was a hardcore anti-Microsoft; Bill Gates is a Borg; etc. I grew up. I worked for an open source company (same company that the author of their article worked for, for a bit actually) and saw people who were hard core in their ideology. Today I use some commercial software, a lot of open source software, and recognize the limitations of each. I did a post on it not to long ago:


                                                                            My last job involved a lot of Scala. I do enjoy Scala over Java. I also have run into code hell with some of the more insane functional concepts and category theory. In frustration, I sometimes feel like Scala would be better if everything from TypeSafe/LightBend died in a fire.

                                                                            I’d like to think that as I’ve grown, I’ve come to see the advantages and limits of most of the tech we use. Everything is terrible, but some of it is kinda neat. When people become hardcore evangelists for a certain technology, or denigrate those because of a choice of tech stack, they close themselves off to really knowing and learning the tools they use. Such people tend to get defensive about their code as well and don’t do well with code reviews.

                                                                            The girl who wrote this article once apologized to me in an elevator after making fun of me for being on the Java team. She had been on a Python project. I honestly didn’t care that much. I hated the limitations of Java and kinda got sucked into that team due to the way projects were delegated at the company. While in that team I was able to push our first Scala project as well.

                                                                            Even PHP is getting better with PHP7 having a real AST and Facebook attempting to write a real spec. I still don’t understand why anyone thinks node is a good idea; but maybe I just need to get stuck in a project using it. :-P

                                                                            All our technology is somewhat terrible. We just need to acknowledge the limits of everything.

                                                                            1. 4

                                                                              When people become hardcore evangelists for a certain technology … they close themselves off to really knowing and learning the tools they use.

                                                                              I understand that people do this, but it just seems so alien to me. The technologies I evangelize the hardest are also the ones I’m most comfortable mocking. If I love something, I’ll use it enough to know what’s frustrating and where it breaks down. You’re only an authority on something when you’re painfully aware of its shortcomings.

                                                                          1. 8

                                                                            Boxed values vs. unboxed. I think most people understand C here so lets put it with those concepts. It helps to understand the subject of the link.

                                                                            A boxed value:

                                                                            typedef struct { int number; } box;
                                                                            box* number = box_integer(5);

                                                                            Unboxed value:

                                                                            int number = 5;

                                                                            The box_integer allocates a place from heap where to write the integer, whereas the lower writes an integer directly. The implementation and the rules may vary here.

                                                                            How the data is stored in memory matters a lot because tighter it is packed, more information the processor can load to work on at once. Being able to work on an array of unboxed integers vs. boxed values can triple the performance. List strategies in PyPy rely on that difference, by attempting to use simpler list representations when it can.

                                                                            1. 4

                                                                              Memory layout control is one thing I particuarly find interesting in the Jai programming language.