I smelled that the author is pushing his own, so I went to see what’s going on.

This is actually post-rationalization because although it gives a good rational, this is not really what’s going on. What is actually going on is that the modulus and division are connected.

The way how they are connected can be described as: a = (a / b) * b + a % b.

Division gives a different result depending on rounding. C99 spec says that the rounding goes toward to zero, but we have also had floor division implementations and systems where you can decide on the rounding mode.

If you have floor division, the 19 / -12 gives you -2. That is correct when the modulo operator gives you -5. If you do a round-towards-zero-division, the 19 mod -12 must give you 7.

On positive numbers, the rounding to zero and floor rounding give the same results.

Also checked on x86 spec. It’s super confusing about this. If the online debugger I tried was correct, then the x86 idiv instruction is doing floor division.

Computer science clocksteps at the rate of algorithms and discoveries. Languages are always going to come and go, unless the language springs up from a good theory.

If you want to understand why this would be true, just look at the history of mathematics. Read about algebraic representations, which kind of abacuses have been used, slide rules, mechanical calculators. You will find out that what we have present today is a small fragment of what used to be, and the stuff that still exists was lugged to today because there’s not many obvious better ways to do the same thing.

By this basis, I’d propose that the current “top 20” by Redmonk cannot form any kind of a long-running status quo. It’s a large list of programming languages rooting to the same theory (Javascript, Java, Python, PHP, C#, C++, Ruby, C, Objective-C, Swift, Scala, Go, TypeScript, Perl, Lua).

There is going to be only one in 30 years, and I think it’ll be falling to C or Javascript axis. They are syntactically near and lot of software was and gets written with these languages. Although there is even more written with C++, it’s way too contrived to survive without reducing back to something like C.

CSS may have some chance of surviving, but it’s pretty much different from the rest. About Haskell I’m not sure. I think typed lambda calculus appear or will reappear in a better format elsewhere. The language will be similar to Haskell though, and may bear the same name.

Unix shell and its commands will probably survive, while Powershell and DOS will wither. Windows seems to have its days counted already by now. Sadly it was not because of open source movement. Microsoft again just botched themselves up.

R seems like a write-and-forget language. But it roots to Iverson’s notation.. Though perhaps the notation itself will be around, but not the current instances of it.

I think that hardware getting more concurrent and diverging from linear execution model will do permanent shakeup on this list in a short term. The plethora of programming languages that describe a rigid evaluation strategy will simply not survive. Though I have bit of bias to think this way so I may not be a reliable source for checking into the future.

But I think this be better than looking at programming language rankings.

I’m disappointed to read the negative comments on TFA complaining that the author has “merely” identified a problem and called on us to fix it, without also implementing the solution. That is an established pattern, a revolution has four classes of actor:

• theoreticians
• propagandists
• agitators
• organisers

Identifying a problem is a necessary prerequisite to popularising the solution, but all four steps do not need to be partaken by the same person. RMS wrote the GNU Manifesto, but did not write all of GNU. Martin Luther wrote the ninety-five theses, but did not undertake all of protestant reform. Karl Marx and Friedrich Engels wrote the Communist Manifesto but did not lead a revolution in Russia or China. The Agile Manifesto signatories wrote the manifesto for agile software development but did not all personally tell your team lead to transform your development processes.

Understandably, there are people who do not react well to theory, and who need the other three activities to be completed before they can see their role in the change. My disappointment is that the noise caused by so many people saying “you have not told me what to do” drowns out the few asking themselves “what is to be done?”

Not surprised. Oracle’s Java copyright lawsuit going the way it is, Google is going to be license price extorted if they stick to Java so they pretty much need to kill Android if the lawsuit succeeds. Working their own version also gives them the copyrights so the ruling will be helpful in maintaining a tight grip on the new platform.

Programmers mental model changes while he learns and is very flexible. Statically typed languages cannot match to this.

Many statically typed languages still allow you to do really bad errors and botch it in numerous multiple ways despite their type system. Very classic example of this would be the whole C language. But it is not the only statically typed language ridden full of foxholes. For example, you may use variables before you’ve set their contents in some corner-case that the language designer did not manage to solve. Then you got a surprise null, despite that careful use of Maybe or nullable-property.

Another example of this kind of failure would be the introduction of corruption bugs. Too many popular statically typed languages do not protect you from data corruption bugs when handling mutable data, and do not provide tools to protect your mutable data from corruption bugs.

I think that dynamically typed languages are easier to use because they genuinely let you decide afterwards on some design problems that you face. They are polymorphic without work, and programmers who use them naturally produce more abstract code. I also think that you can prove dynamically typed programs correct, and you don’t need full type annotations for that which means it can still be dynamically typed after that.

They are simply, just better programming languages.

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.

You forgot to point out that Python provides a traceback:

Traceback (most recent call last):
  File "smalldemo.py", line 17, in <module>
    main()
  File "smalldemo.py", line 8, in main
    bar(target)
  File "smalldemo.py", line 11, in bar
    foo(target)
  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.

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.

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

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

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

What’s an LCS?

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.

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..

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.

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.

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

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?

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.

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.

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.