quicknir

Citation needed? Better developers are more aware, in any language. There are some cases where idiomatic C++ may introduce more indirection over C (though I can't think of any); there are plenty where idiomatic C introduces more indirection than C++. However, with a little more effort and awareness, the faster and more maintainable solution is always accessible.

> I've noticed that using a lower-level language, where abstractions have to be built explicitly, tends to cause one to rethink the problem and often come up with an even simpler and more efficient solution, by approaching it from another direction which using a higher-level language may not even allow.

Having lots of developers, re-implement many things, mostly just results in much more buggy code. Getting things exactly right is hard. Having a bigger standard library and safer abstractions is a huge edge.

I don't think your anecdote has anything to do with C vs C++. I think basically some negative experiences with so-so C++ devs has colored your thinking rather than technical reasons.

Generally there's a lot of emphasis on RAII, clear ownership semantics, leveraging more of the standard library as its grown, using lambdas, avoiding shared mutable state, judicious but not excessive use of inheritance and in particular avoiding implementation inheritane, encapsulation.

It's not so much a middle ground in the sense you are thinking. The people I'm talking about don't advocate developers, particularly non expert, going crazy with templates. People do that on their own.

Hope that helps.

There are women that are just as good marines as men, and there are women that are just as physically fit as men. However, despite this, it's entirely possible that statistically fewer women pass. You haven't denied this empirical data nor tried to argue that it is purely for cultural reasons that fewer women can pass these physical fitness tests. So it's possible that fewer women end up in a profession for purely biological reasons, you are conceding?

Similarly, it's possible that there are women (many women) who are just as good or better programmers than many men, and enjoy it just as much and are equally capable. But, that when you look at the averages, fewer women prefer it. Then, part of that relative difference could be explained by biological factors.

Again, this is not a complicated argument. There's no evidence to suggest that biological factors account for 100% of the gender gap in developers but there's also not much evidence to suggest that any factor accounts for 100% of the gap. It's likely to be a combination of factors, and we should try to honestly understand how big a role each one plays.

At any rate, I would like to see some empirical backing for those who want to raise H1B salaries higher than inflation adjustment.

The side effect you think is great, is actually really bad. It's not a question of developing more talent, it's the fact that people move to the coasts for jobs. All this really does is disadvantage companies not in NYC and SF, and make it more likely that they will have a labor shortage they can't make up, and pack up. This isn't reflective of anything though, except basically regional inflation (it's not simply that salaries in NYC and SF are so much higher because the companies there are the most productive and therefore deserve the H1B slots more, the salaries are partly inflated because cost of living is also super high, i.e. a dollar is worth less).

I think that whatever is going on in the lower end of the market, there is still a substantial shortage of labor in the higher jobs that cannot be made up domestically anytime soon. Higher end jobs tend to have a much less elastic labor pool because fewer people can do the work.

Whatever the impact is for tech workers, for the general public it is definitely a bad outcome to have perpetual labor shortages at tech companies; it just means that they get their products/features/bug fixes/other improvements more slowly.

1. It makes a clear appeal back to the original intent of the law.

2. It would most likely end most of the perceived abuse/misuse of the law, which occurs at lower salary ranges.

3. It will not prevent tech companies that actually do cool stuff like Google & co from hiring, since most of their hires probably start over 110K now.

I also think that the impact on American workers in this salary range from H1B is pretty low. Many companies with salaries in this range are always hiring provided you have the skills.

People always push it to the extreme and mention some very difficult algo question they were asked, and say how it's irrelevant. And if you have been asked a question like that, I agree it's irrelevant and that sucks.

But having a basic understanding of algorithms and data structures is important to writing decent software. Can we please stop pretending like expecting people to roughly know and understand the content of the freshman data structures course is some kind of unreasonable expectation?

The prices for all of these things are almost certainly based on the conversion rate between Bitcoin and the US dollar (or other major currencies). If Bitcoin massively deflates you may be able to still do those things, but it will cost many more Bitcoin: that's the whole point of this discussion.

Yes, a $100 has no practical value either. But it's the official tender of the US government, which means that the US government does all of its spending in US dollars. Contracts, paying its employees, etc. The US government (federal, state, and local) spends a significant chunk of US GDP, i.e. a significant chunk of the world's largest economy.

A country's currency is understood to be tied to that country's economy and monetary policy. As the economy is larger and the policy decisions are protected from craziness by checks and balance, currencies tend to be volatile only to a certain point in practice.

This is even more true when you live in said country: if you live in the US, even if the US dollar is inflating considerably as measured against foreign currencies, the inflation of the dollar on the local economy is generally less. US annual consumer price index inflation has only cracked 10% for the year a handful of times in the last century.

I took ML in person at UIUC 4th year / graduate cross-listed level, and the 3rd year Stanford algos course on Coursera (supposed to be identical to the material in the actual course, yes yes though feel free to laugh b/c it's Coursera). These classes were interesting, but about as challenging as typical second year math/physics classes. They are peanuts compared to senior math/physics classes.

That said I still think CS is more challenging than most majors, it's just that the "few" is much more highlighted because there is very high demand. Certainly way higher demand than math/physics, and more demand than other fields that are still reasonably challenging like engineering, pre-med, etc. It's definitely the field where some reasonable increasing function on both demand and difficulty is maximum.

That's your mistake right there.

However, with regards to your example, things like easy motion/avy solve this exact problem, I think no slower than a mouse. You basically punch in one, two, or more characters at the place you want to jump (depending which package/command you call), and then every match on the screen is highlighted and replaced with a different letter. Then you press that letter and jump there.

Not arguing that's it's much better, just that's approximately the same. Check it out: https://github.com/abo-abo/avy.

According to the poll that JetBrains did when it started working on CLion, about half of C++ usage is in financial software. I will tell you first hand that in most applications in financial software, C++ servers will be talking to other internal servers, exchanges, reputable data distributors, etc. The idea that memory = security risk is just not a connection that people around here generally make.

I also know some game developers and my strong sense is that games are similar. Video games may talk to a specialized multiplayer server, an update server, and that's mostly it.

I could continue, but you get the idea. For most C++ developers I've ever encountered, memory issue == bug, != security risk.

Browsers, which operate on maximally complex data (a Turing complete programming, JS) and are by nature exposed to the entire world, including malicious users who want to harm other browser users, are simply not the typical domain for C++. I think there's every chance that Rust is a good fit for writing browsers, but outside of that things are much less clear (at least, at the moment).

I'm not a game developer so I can't judge your estimation of bug severity there but it seems highly speculative to say the least.

On the other hand your comments vis-a-vis HPC and HFT show that you have very little domain knowledge. Memory corruption is far more likely to crash a program, or to cause results that are wildly wrong. Wildly wrong is not so bad; any scientist worth his salt will question the results and see there are issues.

Your comments on HFT are even worse. Exchanges will not accept "selling items way lower", placing orders too high or too low produces rejects. And even if the order is accepted, it simply crosses the book at the best prices on the book. If you want to write about how you really lose millions, read about Knight Capital. Nothing to do with memory.

In both HPC and HFT, subtly wrong is a much bigger problem than wildly wrong. And memory is much less likely to produce subtly wrong unless someone is deliberately exploiting it. Again, it's not a matter of this never happening. It's just that it's rare in comparison to all of the other ways in which you can make mistakes, and particularly subtle mistakes.

This really seems to be one of the problems with Rust. Most people involved seem to be very firmly in the classical SV-esque tech world, working on browsers or core infrastructural components for the internet, or web servers, or what not. Chrome bugs and heartbleed are the examples du jour.

The problem is that this is not the main area of use for C++. The dominant industries for C++ are finance, video games, and HPC, along with some more demanding programs on mobile, or (rarely) on desktop. People like you who lack domain knowledge about the main areas in which C++ are used, stomping their foot and insisting that memory problems are central and that Rust is valuable, does not really achieve anything.

If you're writing Firefox or SSL, a memory mistake may be a vulnerability and a serious issue. In games, hpc, hft, etc, a memory mistake is almost always just another bug.

Would be great instead to see more examples of how e.g. destructive move in That allows generating better assembly.

The only fair thing to say at present is that Rust's main/most useful/most performant/most whatever implementation is a mixture of Rust and C++.

The only other thing that can break you other than updating spacemacs is updating packages, but that's a factor with vanilla emacs and with vim. This happens occasionally but not too often.

Also keep in mind: spacemacs is not all or nothing. There are many, many layers that are higher in the dependency tree, that both get less attention and are easier to swap. For instance, even though I mostly develop in C++, I don't use the C/C++ layer from spacemacs. There were things I wanted that were missing (like rtags), and things that I didn't want that were there (like older tags solutions).

I started out by just configuring rtags inside a single simple file, the same way a vanilla emacs user would, and I dropped the C++ layer. I eventually added more stuff and wrote my own C++ layer. I'm quite happy with the result. I still got a ton of useful layers/packages from spacemacs that were easily setup and configured, like evil, magit, helm, company, flycheck, etc. And the whole layer system itself made even the parts that I customized myself more modular.

It can store it's own length, but the compiler will still not be aware of the length, except in a real local context (i.e. in the same block of code, either actually, or via inlining). So if you decide to loop over your array, you have to pay the price of looping (jumping and comparing).

If you know that you are working with an array of fixed length, and you use a C++ std::array, you can pass this by reference to functions and those functions will know at compile time how long the array is. So you don't have to pay for looping at all; if you do something small in a loop the compiler will unroll it to 3 assignments or what not.

In addition, the reason that C programmers don't build their own abstractions is because C does not have templates. So building your own abstraction either means that it's not very abstract (i.e. restricted to one data type), or you are using void, or macros, or both. These things are all horrible to work with, void based data structures also involve a performance hit. This tilts the trade-off between writing abstraction and single-use code far, far towards the latter.

In C++ you have templates which are far better for writing your own data structure than macros, and have no performance penalty.

On the other hand, in C you are stuck with a built in array now. If you pass this to a function that doesn't get inlined, it will decay into a pointer, then inside that function the compiler has actually "lost" knowledge of the size of the array. Now you have to pay for a loop.

In C++ you can pass a std::array by const reference, the compiler knows exactly how big that array is at all times, and for small arrays the loop checks can be eliminated entirely.

Many of the arguments against C++ boil down to: if you're working with a lot of people who have a knowledge level below what I would expect someone with 1 year of good experience to have, then they can make more mistakes. Is the level of developers generally really that low?

I think your attitude is more that nothing is really bad with js relative to other languages, more so than actually trying to understand why it draws a lot of criticism, which is what you claimed and what I tried to link to.

Statistics works the other way. You basically always start with some kind of probabilistic model. And then, if you even bother with prediction, you work towards prediction from the probabilistic model. With stats you don't need to interpret or add probability after the fact, it's already there.

Obviously stats and ML are enormous fields, with quite some overlap. And people tend to go after low hanging fruit; if many people who studied neural nets have formal probability backgrounds it simply makes sense that someone will write a paper on it. And I'm generalizing here (same goes with frequentist & Bayesian comment). But there absolutely is justification for saying "neural nets are not really a statistical technique".

The answer doesn't really end up being static vs dynamic, but rather how dynamic languages often lack the other facilities that make programming in the large easier, and Eric Lippert uses js as an example.

Companies with a lot of money at stake have spent a lot of money and effort on things that transpile to js. The people making these decisions are almost always quite smart and very practical. They don't care if first class functions are sexy. They just want to write high quality code quickly. If they've spent so much time wrapping it up, you know it's because they had serious issues being productive at scale with js. They, and people on their team, probably got extremely frustrated along the way. Hence the hate.

Anyhow, tl; dr: Canada is most certainly independent, and gained its independence peacefully (although there were minor conflicts prior to that).

It's the people who want to pass sweeping laws that penalize everyone, instead of something more targeted, who are obligated to provide sources and research.

The scenario you're describing is possible, kind of, maybe. Usually rent controlled apartments also have pretty strict laws about subletting, to prevent this exact kind of thing (and this is all legislation that predates airbnb).

Put in that context, the legislation seems pretty well-aimed at its goal of keeping up demand for hotels at the expense of average people getting to recoup a bit of their enormous rent expenditure.

I've worked on C++ codebases where I just never spent any time on this stuff, at all.