That's not quite correct. Snapdragon chips that are advertised as being good for "AI" also come with the Hexagon DSP, which is now used for (or targeted at) AI applications. It's essentially a separate vector processor with large vector sizes.
For everyone here complaining about this, have you ever looked at how many ways there are to access your history on Firefox? At my last count, there were 4 different ways to do it, depending on which menu you picked first. Cutting down this kind of inconsistent, and repetitive flow is something that we should be applauding.
No, Firefox never targeted geeks. It's just that, when it came out, the only people who used a browser other than Internet Explorer happened to be geeks. The audience came to them, rather than them going to the audience.
From the article: "[...] as developers get more and more senior, they tend to ignore more and more problems, because they've gotten so used to it. That's the way it's always been done, and they've learned to live with them, so they've stopped questioning it any more."
As developers get more and more senior, they have a different perspective on what constitutes a "serious" problem. Also, as developers get more experience with a language, they get better at doing things in ways that are idiomatic for that language - they work with the language instead of against it.
Take Haskell. If I were a Haskell novice, and tried to do everything procedurally with do notation, and then complained that Haskell had all these problems, would that make Haskell a bad language? No. Would it mean that all Haskell programmers were telling themselves lies in order to keep using it? No. It would mean that I was using it badly.
If I were a brand new programmer, and took up Java, I might well complain about "public static void main(String[] args)". But an experienced programmer would brush that off, telling me that that's just syntax - there are real problems with Java, but that isn't one.
So this particular statement, that senior and more experienced devs ignore more and more problems, isn't proof of anything. It's particularly not proof that developers have to keep lying to themselves in order to keep using Go. (They may, but this isn't proof.)
As developers get more and more senior they tend to ignore more and more problems because they realize the majority of them actually don't matter very much to doing useful work.
He made some good points in the article but this particular paragraph stuck out as being hypocritical. The entire motivation of him writing this was because he felt people dismissed his previous article out of hand. And then he makes a remark that preemptively dismisses any rebuttal out of hand (and as others have pointed out, can equally apply to any language so hardly a point worth complaining against Go specifically).
> as developers get more and more senior, they tend to ignore more and more problems, because they've gotten so used to it.
I've been coding professionally since the 90s. The last project I worked on was in Go. It was pleasant and surprisingly productive. A few warts, like the parent said, but all told it was a great experience. I'm now working on a Typescript project. It is painful. Typescript itself is quite nice, but the deep problems with the rest of the ecosystem have not gone unnoticed.
Hmm won't this apply to any language and therefore not a valid argument? A: language FOO is a great language! B: You are telling lies because you are fluent in this language and ignore the problems in the language.
IME there are sort of two kinds of people here. People who are "fans" and defend "their" toy and people who don't. For example, I've been using Python for a very long time. I'm a "Senior Python Developer" so to speak. I quite like it for various purposes, but I can also talk your ear off about problems with Python.
I'd say if you run into someone who says they're experienced with X or love X etc., but they can't give criticism of it, they're most likely either not that experienced with X, or fanboys.
Yes. This is true of any environment. That's why I ask new hires to write down every WTF moment, every question and every idea for improvement they have as they get up to speed on our systems. Just because I'm used to avoiding a problem doesn't mean the problem must exist.
It seems to me there are two ways to evaluate the "beauty" of a language: there's the people who love the language theoretically (well constructed, coherent, nice typing, etc) and then there's people who love the usefulness/utility of the language.
For example, I hate python as a language (spaces syntax? Self,self,self, lack of static type, etc) but I've been using it lately and it's nice using it due to libraries, community,etc.
This is wrong - triSYCL is roughly the same age as ComputeCpp, and hipSYCL is only slightly younger. There has been a lot of academic interest in SYCL, but as with any new technology (especially niche technologies) it's always going to take time to get people on board.
Also, from a quick look at your profile, you seem to have quite a lot of comments criticizing or commenting on CodePlay. Do you have some sort of relationship or animosity with them?
I wish all the luck to CodePlay, the more success the better for them.
They are well appreciated among game developers, given their background.
My problem is how Khronos happens to sell their APIs, and let everyone alone to create their own patched SDKs and then act surprised that commercial APIs end up winning the hearts of the majority.
The situation has hardly changed since I did my thesis with OpenGL in late 90's, porting a particles visualization engine from NeXTSTEP to Windows.
Nothing that compares with CUDA, Metal, DirectX, LibGNMX, NVN tooling.
Hence my reference to CodePlay, as for very long time their SDK was the only productive way to use SYCL.
Khronos likes to oversell the eco-system, and usually the issues and disparities across OEMs tend to be "forgotten" on their marketing materials.
Speaking as someone who (for a time) worked in the IT department of British Airways, the culprit is really just ancient systems that aren't well maintained, along with institutional and industrial pressure not to improve them or upgrade them.
For example, I worked as part of the team that managed the software that allowed pilots to submit flight plans. Any upgrades had to go through multiple weeks of reviews and testing (I don't mean code review - I mean reviews through managers and processes), and was run on some rather ancient hardware. Moreover, thanks to pressure from the pilots union, the system had to be able to accept flight plans by fax, so had a lot of legacy cruft to support that too.
The problem isn't agility, corner cutting or moving too fast - it's moving too slow.
As a pilot, I'm really sorry about the state of infrastructure at the destinations, but we need fax or phone sometimes.
For context: Imagine a crew room, with an old yellow looking windows 95 machine as the only "IT service" and only GSM-speed (or no reception at all) mobile internet in the area. The machine doesn't really work, or is on a dialup connection (yes this still exists).
These are the cases where we use the phone, or write the plan manually on a form and fax that. The phone has a high risk of mistakes, because you're reading lots of numbers and codes so it's easy to misunderstand one.
That's a much more reasonable explanation - thanks, I appreciate it! The way I'd had it explained to me was more along the lines of "greedy pilots want to be able to fax because they can't be bothered to learn how to use email", but your explanation makes a lot more sense.
The issue is that pickpockets and others looking to target more "naive" tourists will be less likely to target you if you're dressed less like a tourist.
reply