hasenj

Consequently, we have more and more incompetent people writing software with absolutely no concerns about performance.

> What's the most widely used Java desktop app? Was there ever one? Eclipse/Netbeans comes to mind.

Ironic, because these are just Java IDEs.

The "black markets" in officially communist countries tend to be diverse, though.

It's actually quite easy to understand, given a sufficient understanding of human nature.

You're trying to dominate a social situation, because you think you are right (and by extensions, that there are others who will support you and strengthen your position) and because there's a lack of physical threat.

In the real world, you would not want to cause a ruckus, because there could be consequences, and your are not the dominant member of the group. For example; someone could punch you.

If you could, you would want to dominate any situation that you can. We are wired that way.

eh, this is like an obese man complaining that thin women don't want to date him, then when people point out the obvious, he complains why is the onus being pushed on him instead of on the thin women who don't find him attractive.

I tried to freelance before. The number one concern for a freelancer is how do I get clients.

Nothing on your site provides a solution for my problem.

For the same reason that git turned out better than svn for a lot of use cases.

It seems like Windows is not really one of these use cases.

Fearmongering? That's a strange choice of words.

> Do you have profiler data showing that the microseconds needed to pass a message between a process is a significant limiting factor

What? I think you didn't get my point. Let me try again.

You can look at a single operation and say "oh, that's nothing, it's so cheap, it only takes a millisecond". Even though there's a way to do the same thing that takes much less time.

So this kind of measurement gives you a rational to do things the "wrong" way or shall we saw the "slow" way because you deem it insignificant.

Now imagine that everything the computer is built that way.

Layers upon layers of abstractions.

Each layer made thousands of decisions with the same mindset.

The mindset of sacrificing performance because "well it's easier for me this way".

And it's exactly because of this mindset.

Now you have a super computer that's doing busy work all the time. You think every program on your machine would start instantly because the hardware is so advanced, but nothing acts this way. Everything is still slow.

This is not really fear mongering, this is basically the state of software today. _Most_ software runs very slow, without actually doing that much.

What I find more surprising is the length they went through to make git work for them.

It would probably have been better if they had assigned a team of highly skilled engineers to design a distributed source control from scratch specifically to solve the problems faced by the windows team.

After all, `git` itself was developed for Linux because Linus was not satisfied with any of the existing solutions.

> We've already asked you this.

Am I on some kind of a black/gray list? Either that, or you specifically remember my name, which sounds odd.

Moving Windows development to git sounds like a completely irrational decision from a technical standpoint that was driven mostly by marketing concerns.

I think the language server is not a solution to a technical problem; it's a solution to a social/political problem.

How to support intellisense for a language one time and have it work on many editors?

Try harder.

A PC full of programs built with these assumptions will probably grind to a halt all the time despite having very high spec hardware.

> We know this from the number of people who are working and claiming benefit.

For how long do they claim benefits?

This could actually be a bad sign.

No I do not. I specially don't write unit tests.

For every guy who legitimately could use some temporary help until he gets back on his feet, there are hundreds of free loaders.

If you think about it actually more reason to hate on free loaders. They cause tragedies like this.

The other day I was listening to a clip from Jordan Peterson, and he said something that I found a bit surprising/shocking, but this articles seems to confirm it: people on the left who claim to side with the poor don't actually care about the poor, they just hate the rich.

This article is basically just hating on the rich people.

I think it's rather easy to understand what this author is puzzled by: people want to keep their money. If you've earned your money and you want to keep it, I can empathize with you. If you think you deserve to take other people's money, I can't empathize with you.

I'm sorry but if you have crippling anxiety that you cannot chat about subjects you find interesting then you're going to be a burden on any team.

Selecting only based on chattiness is not good, but filtering out people who cannot even chat is probably a good thing from a company's point of view.

What is behavioral test? Like, I don't understand all these weird paradigms that people come up with to deal with the deficiencies of dynamic typing.

If declaring structs is seen as costly overhead that complicates coding, tests are when more cumbersome.

> I really haven't seen much benefit in static typing in regards to software defect rate or quality

Hold it right there. I've never seen anyone argue that static type systems prevent bugs.

I mean they do prevent silly bugs that occur from mistyping variable/property names but I've never seen anyone claim that they eliminate other classes of bugs.

The biggest benefit of static type checking is you know what all the variables are.

    def checkout_cart(customer, payment_methods, cart, session):
        # body

What the hell is customer? What is payment methods? What fields are available on these objects? What methods can you call on them? no freaking idea.

Of course, this kind of code is confusing in Java as well, but for a different reason: Java conventions encourage a kind of obtuse programming style where everything is hidden behind layers of abstractions of factories and managers, so that even when everything is typed, you're not sure what anything is doing because all the data that matters is private and so are all the methods that actually do anything useful. All you're left with is an abstract interface that can sometimes be just as bad as an untyped variable. But this is mostly a cultural problem. (I've digressed).

> Static typing make auto complete and refactoring tools easier, for sure, but it also slows down ease of experimentation

Java slows down ease of experimentation because it requires tons of boilerplate code for even the simplest tasks.

It's not the static type checking.

If anything, static type checking helps experimentation because you can change your mind quickly and the compiler will help you catch all the stupid mistakes that can occur from mismatching types or mistyping variable names. This removes a huge cognitive tax and makes programming more enjoyable. Although I will concede this is subjective.

Things that are full of bugs and are sluggishly slow are what makes customers scream their lounges out 99% of the time.

There's no evidence than any of this is true.

First market is not often the winner. Facebook came very late to the social media scene but it dominated.

Google came very late to the search engine scene, and people don't even remember this but there was a time when there were a ton of search engines and anyone at the time would probably think that the search engine market is saturated and there's no space for a new product.

All evidence actually points to better products dominating the market even if they come late.

If your competitors released their app 4 months ahead of you but it was full of bugs and always hangs up, and then you release your product which actually works and performs well, people will see your product as a breath of fresh air.

Another example is the Chrome browser, which came at a time when Firefox and IE were competing fiercely for market share, and Chrome completely dominated them on the simple basis that it was _really fast_.

For most products it doesn't even cost 6 months to make it fast. If you have that as a goal from the very start, there will never be a stage of "omg it's really slow let's try to make it a bit faster". It will always just be fast.

This quote is so misunderstood and so abused all the time.

The point of the statement is to not micro-optimize this and that corner of the program without having any data to guide you on what you should optimize and how.

It's not a rallying call to forgo all concerns about application performance and efficiency.

The mis-application of this quote is the root of all evil in modern software IMO.

It's why a chat program takes 500MB of RAM and why many programs take 10 seconds to load even though there's no technical reason they cannot startup instantly.

You should make it right and fast from the very start. You should not make something that "works" but is full of bugs and slow as hell. Like, that makes no sense at all. If it's full of bugs then it doesn't work. If it's slow as hell then it doesn't work.

1. Make it work correctly and efficiently (to a reasonable degree)

2. Make it even faster

3. Make it better

> No I think what we are seeing is a lot more hybrid systems.

I'm not sure why you started that sentence with "No". I actually agree with it.

There are many good ideas that have emerged separately in different languages, and are being combined in some of the new languages.

All I'm saying is, successful upcoming languages will probably be more statically typed than dynamically typed.

In other words, the dynamic typing paradigm is failing the real world test.

> Go is like a statically typed language with lots of dynamic features.

Go is statically typed.

The part that lacks static typing (no generics) is the worst part of the language that gets the most flak.

> Traditional statically typed OOP languages such as Java is what people want to get away from.

Java's problem is that it's just way too verbose.

    User user = new User(....); // This is not even that verbose

    // Maybe more like this:

    User user = new User(new UserProfile(....), UserManagerFactory.getDefaultUserManager());

People have misdiagnosed the problem and thought it was the static typing.

It turns out to be the lack of support for functions as objects. So for many things you end up having to create dummy classes and objects just to wrap functions.

Even C supported passing function pointers around.

So in this regard, Java is less expressive than C.

Somewhat off topic but I think that more and more people are learning (the hard way, unfortunately) how important static typing is, and how dynamic typing makes it very difficult to develop and maintain large projects.

I think the next generation of successful languages will all be statically typed (whether they will run natively or in a virtual machine is a different (even if related) question).

No necessarily competent. It could be that they are well read on the subject but have no practical experience in it. So they seem able to converse in the subject's vocabulary but if they were to sit down and try to make something they would fail.

That's just about the worst way to filter candidates. You are selecting for chatty people.

That's a common attitude, I was just pointing out how it puts the "passionate" part under doubt.

I've noticed the word "passionate" gets thrown around a lot cheaply.

It's seriously starting to lose all meaning.

Am I the only one who found the thing awkward and offputting?

And all the code pens are also slow. Between clicking the "run" button and the actual script running there's somewhat of a 3 second gap.

Which kind of puts the opening paragraph into question:

> I’m passionate about image performance optimisation and making images load fast on the web.

Like, ok, why aren't you using a simpler blog engine to post? As a plus, if you were in control of everything on the page, you wouldn't even need to use codepen; just include the javascript directly in your page.