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:

                              https://lobste.rs/s/cfugqa/modelling_data_with_hypergraphs#c_bovmhr

                              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:

                                          http://penguindreams.org/blog/the-philosophy-of-open-source-in-community-and-enterprise-software/

                                          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.

                                            https://inductive.no/jai/

                                          1. 0

                                            Go is getting a very popular language, but I just wait for the time when people realize how silly all of this sounded like.

                                            Seriously? Performance is your first reason? What did you lose in exchange to that? You usually lose something when you buy runtime performance.

                                            Using a language that doesn’t let you go creative? Doesn’t your workforce know how to restraint themselves? Is it exactly the best decision to limit your options in the first place?

                                            Fast compile times? Are you exactly happy with the fact that your computer does a lot less for you? Keep in mind that this is a hint of offloading work from the computer to a human. People have a tendency to not be good at the kind of logical works a computer does without flaws. Could you have obtained fast development time in somehow an other manner?

                                            Concurrency support, strong ecosystem, automatic formatting, protocol buffer/gRPC support and team building are plausibly good reasons to pick a language.

                                            1. 4

                                              Oh please. It’s absolutely ridiculous to pretend performance is way less important than anything else. When I read vitriolic trash about performance like this, I can’t help but think “here’s another person who has never deployed anything at scale.” But if I’m wrong, do please correct me. When was the last time you built a large scale data processing application in Python? How’d that work out for you?

                                              1. 0

                                                Performance is important, but there is a thing that much more valuable. That more valuable thing has the following properties:

                                                • It has fixed capacity and it cannot be expected to increase over time.
                                                • It has fixed bandwidth, the bandwidth won’t increase at least to another 20 years.
                                                • If you add more of them to compensate, their efficiency decreases drastically while the costs increase evenly.

                                                Go belongs into the past. The stuff I’ve made will put it there eventually. I will just tell you that I warned you.

                                            1. 2

                                              This is a rambling disaster of an essay. It commits the cardinal sin of extrapolating from a single example to greatly overreach on its conclusions.

                                              I’m happy the author has learned that abstractions leak, but to say that “a whole industry gets it wrong” because it doesn’t have standards it agrees on only demonstrates the sheer naivete of the author.

                                              1. 1

                                                I agree. I feel I have failed to explain the thing I was trying to explain.

                                                It’s also true that there are probably examples of how someone has gotten these things right in the software industry. But the ideas of encapsulation and data hiding is taught along OOP in the schools. I feel unable to stand and say that the whole industry wouldn’t have a problem here.

                                                Btw. You are extrapolating as well.