Developer burnout is helping to drive an exodus of software developer talent from organizations, as part of a larger trend known as the Great Resignation, according to a report released on April 13 by MuleSoft, which is a division of Salesforce. From a report: The MuleSoft report was based on research conducted by Vanson Bourne in February 2022 across the U.S., U.K., France, Germany, and Australia. Eighty-six percent of respondents indicated that in the last two years it has become increasingly difficult to recruit software developers. One of the reasons why is the larger macroeconomic trend of the Great Resignation, where employees are leaving their employers en masse during the COVID-19 pandemic as they seek a better work-life balance.

Burnout is also a large challenge for developers, according to the report. The top causes of developer burnout are increasing workloads and the challenges of learning new skills to adapt to emerging technologies. "The pandemic was a massive accelerator for the need of digital tools," Matt McLarty, global field CTO and vice president of the Digital Transformation Office (DTO) at MuleSoft, told ITPro Today. "Non-technology companies were ultimately forced to become technology companies overnight, and we saw nearly every organization require developers to help them achieve these new goals on high-pressure deadlines, all at once."

Long-time Slashdot reader theodp writes: Tech-backed Code.org reports that as part of efforts to provide scaled human-centered education, the Stanford AI Lab analyzed 711,274 solutions to interactive block-based Code.org programming assignments submitted by 3rd and 4th grade students to develop AI-based solutions for automatically grading student homework. The research project received funding from LinkedIn founder and VC Reid Hoffman, who is coincidentally a $1+ million supporter of Code.org, which provided the student data.

Autograding systems are increasingly being deployed at all levels of education to meet the challenge of teaching programming at scale. So, will AI make Computer Science grader and undergraduate teaching assistant jobs obsolete?

"Enabling developer productivity has become a key vector in every organization's success," writes Matt Asay at InfoWorld — not a nice-to-have feature but a must-have.

"Which is why, perhaps ironically, the best way to set your developers free may actually be to fetter their freedom." The more developers mattered, the more everyone wanted to cater to their needs with new software tools, new open source projects, new cloud services, etc. This meant lots of new developer choice and associated freedom, but that wasn't necessarily an unalloyed good. As RedMonk analyst Steven O'Grady noted in 2017, "The good news is that this developer-driven fragmentation has yielded an incredible array of open source software. The bad news is that, even for developers, managing this fragmentation is challenging."

Can one have too much choice? Yep.

It's long been known in consumer retail, for example, that when there is too much choice, "consumers are less likely to buy anything at all, and if they do buy, they are less satisfied with their selection." Turns out this isn't just a matter of breakfast cereals or clothing. It also applies to developers building enterprise software. InfoWorld's Scott Carey writes that "complexity is killing software developers." He's right. But what can be done?

In a conversation with Weaveworks CEO Alexis Richardson, he related how self-service development platforms are reemerging to help developers make sense of all that open source and cloud choice. By giving developers "a standard, pre-approved environment in which the effort to create an app from an idea is minimal," he explained, it allows them to "focus on innovation not plumbing."
"Done right, a little bit of constraint goes a long way..." Asay argues, touting the benefits of PaaS (platform as a service) self-service development platforms. ("Enterprises that want to give their developers the freedom the cloud affords can couple it with just enough constraint to make that freedom useful....")

Asay argues that "However you approach it, the point is to stop thinking about freedom and control as impossibly opposed. Smart enterprises are figuring out ways to enable their developers using self-service platforms. Maybe you should, too."

The C programming language has many problems. But now the Registers notes that "Aria Beingessner, a member of the teams that implemented both Rust and Swift, has an interesting take... That C isn't a programming language anymore...."

"And it hasn't been for a long time," Beingessner writes in an online essay: This isn't about the fact that C is actually horribly ill-defined due to a billion implementations or its completely failed integer hierarchy. That stuff sucks, but on its own that wouldn't be my problem.

My problem is that C was elevated to a role of prestige and power, its reign so absolute and eternal that it has completely distorted the way we speak to each other. Rust and Swift cannot simply speak their native and comfortable tongues — they must instead wrap themselves in a grotesque simulacra of C's skin and make their flesh undulate in the same ways it does....

Everyone had to learn to speak C to talk to the major operating systems, and then when it came time to talk to eachother we suddenly all already spoke C so... why not talk to eachother in terms of C too?

Oops! Now C is the lingua franca of programming.

Oops! Now C isn't just a programming language, it's a protocol.
The Register picks up the argument: it's fair (if wildly controversial) to say, as this 2018 Association for Computing Machinery paper puts it, that C is not a low-level programming language. As its subtitle says: "Your computer is not a fast PDP-11."

This is not a relative assessment: that is, it's not saying that there are other programming languages that are lower-level than C. It's an absolute one: C is often praised for being "close to the metal," for being a "portable assembly language." It was, once, but it hasn't been since the 1970s; the underlying computational models of modern computers are nothing like the one that C represents, which was designed for a 1970s 16-bit minicomputer.
The Register summarizes what happens when a language has to interface with an operating system — and thus, that operating system's C code. [I]t has to call C APIs. This is done via Foreign Function Interfaces (FFIs).... In other words, even if you never write any code in C, you have to handle C variables, match C data structures and layouts, link to C functions by name with their symbols....

The real problem is that C was never designed or intended to be an Interface Definition Language, and it isn't very good at it.

About one-third of U.S. subscribers to Netflix share their login credentials with others, according to new data from Leichtman Research Group. From the report: The research firm's online survey of 4,400 consumers confirms the company's own conclusions in recent years. While 64% of respondents said they pay for and use Netflix only in their own household, 33% indicate some form of sharing. (The remaining 3% are households whose Netflix comes packaged via other subscriptions.) Netflix has about 74 million subscribers in the U.S. and Canada and has penetrated nearly 70% of U.S. broadband homes. With subscription growth flattening in the region of late, Netflix has recently phased in rate increases in order to continue funding its $18 billion in annual programming spending. Earlier this month, Netflix announced a test of monthly fees for password-sharing in three territories outside of the U.S. The rise of password sharing between households, a blog post explained, is âoeimpacting our ability to invest in great new TV and films for our members.â

"Pong on a Commodore 64 is one thing... but Pong in a single C64 sprite? That's uncharted territory," writes Slashdot reader segaboy81.

Neowin reports: The Commodore 64 is an iconic machine. For many of us boomers, it was our introduction to programming... Josip Retro Bits is a YouTube channel that specializes in fun challenges on old hardware like the Commodore 64. In an older video, Josip creates a game of Pong using Basic. On the surface, this doesn't sound very interesting, but it's a real challenge because Basic is very limited when compared to writing machine code. Basically, the C64 is perfectly capable of a game like Pong, but not really in Basic. Spoiler alert: he does it. However, a commenter on that video had a novel idea. How about creating an entire game of Pong in a single spite?
That's a 24 x 21 pixels object. ("It can be seen as a bigger programmable character that can be moved on hardware on steps of one pixel," explains one tech blog.) And another spoiler alert: he does it again.

Here's the repository for the "Tiny Pong" code. It's written in C, with functions like drawScreen() and batSound().

And about 18 minutes into the video, he not only plays a game of Pong inside the sprite — he simultaneously makes that sprite move around the screen like the ball in a game of Pong.

GitHub has introduced a new feed into the dashboard of users and it doesn't appear to have gone down well with the code shack's regulars. The Register reports: As soon as the new feed arrived, replete with all kinds of exciting suggestions for developers to look at, the complaints began rolling in as users worried the recommendations were turning GitHub into something distressingly like a social media platform. "I do not need to see recommendations, nor activity of people I don't follow," said one user. "Don't fix what's not broken." Others were blunter, stating: "I don't want algorithmic feed" and requesting a feed on stuff that actually mattered â" issues, releases, PRs and so on. GitHub pushed out a new beta version of its Home Feed earlier this week, with the avowed intention of developers reaching a wider audience and building communities. The plan is to make discovery easier and help users "find new repositories or users to follow based on your interests."

As if to demonstrate the levels of discontent around GitHub's new feature, a Chrome extension quickly showed up to disable the social feed by removing the "For You" section on the GitHub dashboard. Not all users were upset by the appearance of the new feed, and GitHub staff popped up to promise that there would be an option to make one's profile private and opt out of pretty much everything via a single setting. It will, however, take until late April before this option is likely to appear, they said. Which prompted the obvious question: "Why is this opt-out instead of opt-in?"

An anonymous reader shares an opinion piece: Protest is an important element of free speech that should be protected. Openness and inclusivity are cornerstones of the culture of open source, and the tools of open source communities are designed for global access and participation. Collectively, the very culture and tooling of open source -- issue tracking, messaging systems, repositories -- offer a unique signaling channel that may route around censorship imposed by tyrants to hold their power.

Instead of malware, a better approach to free expression would be to use messages in commit logs to send anti-propaganda messages and to issue trackers to share accurate news inside Russia of what is really happening in Ukraine at the hands of the Russian military, to cite two obvious possibilities. There are so many outlets for open source communities to be creative without harming everyone who happens to load the update.

We encourage community members to use both the freedoms and tools of open source innovatively and wisely to inform Russian citizens about the reality of the harm imposed on Ukrainian citizens and to support humanitarian and relief efforts in and supportive of Ukraine. Longer term, it's likely these weaponizations are like spitting into the wind: The downsides of vandalizing open source projects far outweigh any possible benefit, and the blowback will ultimately damage the projects and contributors responsible. By extension, all of open source is harmed. Use your power, yes -- but use it wisely.

Stephen Wilhite, one of the lead inventors of the GIF, died last week from COVID at the age of 74, according to his wife, Kathaleen, who spoke to The Verge. From the report: Stephen Wilhite worked on GIF, or Graphics Interchange Format, which is now used for reactions, messages, and jokes, while employed at CompuServe in the 1980s. He retired around the early 2000s and spent his time traveling, camping, and building model trains in his basement.

Although GIFs are synonymous with animated internet memes these days, that wasn't the reason Wilhite created the format. CompuServe introduced them in the late 1980s as a way to distribute "high-quality, high-resolution graphics" in color at a time when internet speeds were glacial compared to what they are today. "He invented GIF all by himself -- he actually did that at home and brought it into work after he perfected it," Kathaleen said. "He would figure out everything privately in his head and then go to town programming it on the computer."

If you want to go more in-depth into the history of the GIF, the Daily Dot has a good explainer of how the format became an internet phenomenon. In 2013, Wilhite weighed in on the long-standing debate about the correct pronunciation of the image format. He told The New York Times, "The Oxford English Dictionary accepts both pronunciations. They are wrong. It is a soft 'G,' pronounced 'jif.' End of story."

After much speculation, Nvidia today at its March 2022 GTC event announced the Hopper GPU architecture, a line of graphics cards that the company says will accelerate the types of algorithms commonly used in data science. Named for Grace Hopper, the pioneering U.S. computer scientist, the new architecture succeeds Nvidia's Ampere architecture, with launched roughly two years ago. From a report: The first card in the Hopper lineup is the H100, containing 80 billion transistors and a component called the Transformer Engine that's designed to speed up specific categories of AI models. Another architectural highlight includes Nvidia's MIG technology, which allows an H100 to be partitioned into seven smaller, isolated instances to handle different types of jobs. "Datacenters are becoming AI factories -- processing and refining mountains of data to produce intelligence," Nvidia founder and CEO Jensen Huang said in a press release. "Nvidia H100 is the engine of the world's AI infrastructure that enterprises use to accelerate their AI-driven businesses."

The H100 is the first Nvidia GPU to feature dynamic programming instructions (DPX), "instructions" in this context referring to segments of code containing steps that need to be executed. Developed in the 1950s, dynamic programming is an approach to solving problems using two key techniques: recursion and memoization. Recursion in dynamic programming involves breaking a problem down into sub-problems, ideally saving time and computational effort. In memoization, the answers to these sub-problems are stored so that the sub-problems don't need to be recomputed when they're needed later on in the main problem. Dynamic programming is used to find optimal routes for moving machines (e.g., robots), streamline operations on sets of databases, align unique DNA sequences, and more.

"Supporting generics has been Go's most often requested feature, and we're proud to deliver the generic support that the majority of users need today," the Go blog announced this week. *

It's part of what Go's development team is calling the "biggest change ever to the language".

SiliconANGLE writes that "Right out of the gate, Go 1.18 is getting a CPU speed performance boost of up to 20% for Apple M1, ARM64 and PowerPC64 chips. This is all from an expansion of Go 1.17's calling conventions for the application binary interface on these processor architectures."

And Go 1.18 also introduces native support for fuzz testing — the first major programming language to do so, writes ZDNet: As Google explains, fuzz testing or 'fuzzing' is a means of testing the vulnerability of a piece of software by throwing arbitrary or invalid data at it to expose bugs and unknown errors. This adds an additional layer of security to Go's code that will keep it protected as its functionality evolves — crucial as attacks on software continue to escalate both in frequency and complexity. "At Google we are committed to securing the online infrastructure and applications the world depends upon," said Eric Brewer, VIP infrastructure at Google....

While other languages support fuzzing, Go is the first major programming language to incorporate it into its core toolchain, meaning — unlike other languages — third-party support integrations aren't required.
Google is emphasizing Go's security features — and its widespread adoption. ZDNet writes: Google created Go in 2007 and was designed specifically to help software engineers build secure, open-source enterprise applications for modern, multi-core computing systems. More than three-quarters of Cloud Native Computing Foundation projects, including Kubernetes and Istio, are written in Go, says Google. [Also Docker and Etc.] According to data from Stack Overflow, some 10% of developers are writing in Go worldwide, and there are signs that more recruiters are seeking out Go coders in their search for tech talent..... "Although we have a dedicated Go team at Google, we welcome a significant amount of contributions from our community. It's a shared effort, and with their updates we're helping our community achieve Go's long-term vision.
Or, as the Go blog says: We want to thank every Go user who filed a bug, sent in a change, wrote a tutorial, or helped in any way to make Go 1.18 a reality. We couldn't do it without you. Thank you.

Enjoy Go 1.18!
* Supporting generics "includes major — but fully backward-compatible — changes to the language," explains the release notes. Although it adds a few cautionary notes: These new language changes required a large amount of new code that has not had significant testing in production settings. That will only happen as more people write and use generic code. We believe that this feature is well implemented and high quality. However, unlike most aspects of Go, we can't back up that belief with real world experience. Therefore, while we encourage the use of generics where it makes sense, please use appropriate caution when deploying generic code in production.

While we believe that the new language features are well designed and clearly specified, it is possible that we have made mistakes.... it is possible that there will be code using generics that will work with the 1.18 release but break in later releases. We do not plan or expect to make any such change. However, breaking 1.18 programs in future releases may become necessary for reasons that we cannot today foresee. We will minimize any such breakage as much as possible, but we can't guarantee that the breakage will be zero.

Russia's invasion of Ukraine turns up in Mike Melanson's column "This Week in Programming": While the Open Source Initiative's (OSI) definition of open source software is quite clear on the matter — there must be "no discrimination against persons or groups" and "no discrimination against fields of endeavor" — the issue of who should be allowed to use open source software, according to ethical considerations, has long been debated.

Over the last month, this topic has again become a focus of debate as Russia's invasion of Ukraine has led to developers calling for blanket bans by companies like GitHub and GitLab; and to some developers even taking action. Earlier this month, we wrote about how open source gateway Scarf began limiting access to open source packages for the Russian government and military entities, via its gateway.

As we noted at the time, there was a primary distinction made when Scarf took this action: distribution of open source software is separate from the licensing of it. Those points of the OSI definition pertain to the licensing, not to some entity actively providing the software to others.

Since then, discussions around these ideas have continued, and this week an essay by Bradley M. Kuhn, a policy fellow and hacker-in-residence at the Software Freedom Conservancy, argues that copyleft won't solve all problems, just some of them.

The essay specifically takes to task the idea that open source software can effectively affect change by way of licensing limitations. He spent nearly 3,000 words on the topic, before pointedly addressing the issue of Russia — with a similar conclusion to the one reached by Scarf earlier this month. Kuhn argues that "FOSS licenses are not an effective tool to advance social justice causes other than software freedom" and that, instead, developers have a moral obligation to take stances by way of other methods.

"For example, FOSS developers should refuse to work specifically on bug reports from companies who don't pay their workers a living wage," Kuhn offers in an example.

Regarding Russia specifically, Kuhn again points to distribution as an avenue of protest, while still remaining in line with the principles of free and open source software.

"Every FOSS license in existence permits capricious distribution; software freedom guarantees the right to refuse to distribute new versions of the software. (i.e., Copyleft does not require that you publish all your software on the Internet for everyone, or that you give equal access to everyone — rather, it merely requires that those whom you chose to give legitimate access to the software also receive CCS). FOSS projects should thus avoid providing Putin easy access to updates to their FOSS," writes Kuhn.

Pamela Burdman, the executive director of Just Equations, a policy institute focused on the role of math in education equity, writes in an op-ed for Scientific American: All routes to STEM (science, technology, engineering and mathematics) degrees run through calculus classes. Each year, hundreds of thousands of college students take introductory calculus. But only a fraction ultimately complete a STEM degree, and research about why students abandon such degrees suggests that traditional calculus courses are one of the reasons. With scientific understanding and innovation increasingly central to solving 21st-century problems, this loss of talent is something society can ill afford. Math departments alone are unlikely to solve this dilemma. Several of the promising calculus reforms highlighted in our report Charting a New Course: Investigating Barriers on the Calculus Pathway to STEM , published with the California Education Learning Lab, were spearheaded by professors outside of math departments. It's time for STEM faculty to prioritize collaboration across disciplines to transform math classes from weed-out mechanisms to fertile terrain for cultivating a diverse generation of STEM researchers and professionals. This is not uncharted territory.

In 2013, life sciences faculty at the University of California, Los Angeles, developed a two-course sequence that covers classic calculus topics such as the derivative and the integral, but emphasizes their application in a biological context. The professors used modeling of complex systems such as biological and physiological processes as a framework for teaching linear algebra and a starting point for teaching the basics of computer programming to support students' use of systems of differential equations. Creating this course, Mathematics for Life Scientists, wasn't easy. The life sciences faculty involved, none of whom had a joint appointment with the math department, said they resorted to designing the course themselves after math faculty rebuffed their overture. The math faculty feared creating a "watered-down" course with no textbook (though after the course was developed, one math instructor taught some sections of the class).

Besides math, the life sciences faculty said they experienced "significant pushback" from the chemistry and physics departments over concerns that the course wouldn't adequately prepare students for required courses in those disciplines. But the UCLA course seems to be successful, and a textbook based on it now exists. According to recently published research led by UCLA education researchers, students in the new classes ended up with "significantly higher grades" in subsequent physics, chemistry and life sciences courses than students in the traditional calculus course, even when controlling for factors such as demographics, prior preparation and math grades. Students' interest in the subject doubled, according to surveys.

Sophos threat researcher Nick Gregory discovered a hole in Linux's netfilter firewall program that's "exploitable to achieve kernel code execution (via ROP [return-oriented programming]), giving full local privilege escalation, container escape, whatever you want." ZDNet reports: Behind almost all Linux firewalls tools such as iptables; its newer version, nftables; firewalld; and ufw, is netfilter, which controls access to and from Linux's network stack. It's an essential Linux security program, so when a security hole is found in it, it's a big deal. [...] This problem exists because netfilter doesn't handle its hardware offload feature correctly. A local, unprivileged attacker can use this to cause a denial-of-service (DoS), execute arbitrary code, and cause general mayhem. Adding insult to injury, this works even if the hardware being attacked doesn't have offload functionality! That's because, as Gregory wrote to a security list, "Despite being in code dealing with hardware offload, this is reachable when targeting network devices that don't have offload functionality (e.g. lo) as the bug is triggered before the rule creation fails."

This vulnerability is present in the Linux kernel versions 5.4 through 5.6.10. It's listed as Common Vulnerabilities and Exposures (CVE-2022-25636), and with a Common Vulnerability Scoring System (CVSS) score of 7.8), this is a real badie. How bad? In its advisory, Red Hat said, "This flaw allows a local attacker with a user account on the system to gain access to out-of-bounds memory, leading to a system crash or a privilege escalation threat." So, yes, this is bad. Worse still, it affects recent major distribution releases such as Red Hat Enterprise Linux (RHEL) 8.x; Debian Bullseye; Ubuntu Linux, and SUSE Linux Enterprise 15.3. While the Linux kernel netfilter patch has been made, the patch isn't available yet in all distribution releases.

South Africa's Competition Commission says it had referred Facebook and WhatsApp owner Meta Platforms to a tribunal for allegedly abusing its dominant position in the market. From a report: But a spokesperson for WhatsApp said the regulator was objecting to actions meant to protect the platform's users from abuses of WhatsApp's terms. In a statement, the regulator accused Meta of "abusing its dominance by engaging in exclusionary conduct geared at preventing competitors or potential competitors from entering into, participating, and expanding in a market". The commission said Meta had decided to "offboard" GovChat (a start-up that connects government and citizens) and its subsidiary #LetsTalk from its WhatsApp Business Application Programming Interface. It also said the company had "imposed and/or selectively enforced exclusionary terms and conditions regulating access to the WhatsApp Business API, mainly restrictions on the use of data".

This week Silicon Valley's Computer History Museum posted a PDF transcript (and video excerpts) from an interview with 81-year-old Margaret Hamilton, the programmer/systems designer who in the 1960s became director of the Software Engineering Division at the MIT Instrumentation Laboratory which developed the on-board flight software for NASA's Apollo program. Prior to that Hamilton had worked on software to detect an airplane's radar signature, but thought, "You know, 'I guess I should delay graduate school again because I'd like to work on this program that puts all these men on the Moon....'"

"There was always one thing that stood out in my mind, being in the onboard flight software, was that it was 'man rated,' meaning if it didn't work a person's life was at stake if not over. That was always uppermost in my mind and probably many others as well."

Interestingly, Hamilton had originally received two job offers from the Apollo Space Program, and had told them to flip a coin to settle it. ("The other job had to do with support systems. It was software, but it wasn't the onboard flight software.") But what's fascinating is the interview's glimpses at some of the earliest days of the programming profession: There was all these engineers, okay? Hardware engineers, aeronautical engineers and all this, a lot of them out of MIT... But the whole idea of software and programming...? Dick Battin, Dr. Battin, when they told him that they were going to be responsible for the software...he went home to his wife and said he was going to be in charge of software and he thought it was some soft clothing...
Hamilton also remembers in college taking a summer job as a student actuary at Travelers Insurance in the mid-1950s, and "all of a sudden one day word was going around Travelers that there were these new things out there called computers that were going to take away all of their jobs... Pretty soon they wouldn't have jobs. And so everybody was talking about it. They were scared they wouldn't have a way to make a living.

"But, of course, it ended up being more jobs were created with the computers than there were...."

Hamilton's story about Apollo 8 is amazing...

An interesting tidbit from Mike Melanson's column, "This Week in Programming."

"If a proposal unveiled this week gets its way, JavaScript developers will soon have something that many of them have long been asking for: a type system, of some sort at least." A blog post by TypeScript senior program manager Daniel Rosenwasser lays out the background and reasoning for the proposal for type syntax in JavaScript. He writes that "if we pull this all off, we have the chance to make one of the most impactful improvements to the world of JavaScript."

The proposal, which shares authors from Microsoft, Bloomberg, Igalia, and a number of other sources, suggests that JavaScript developers should be able to "add type annotations to their JavaScript code, allowing those annotations to be checked by a type checker that is external to JavaScript" and then be ignored at runtime. "Because this new syntax wouldn't change how surrounding code runs, it would effectively act as comments," writes Rosenwasser in his blog post, later adding that "JavaScript could carve out a set of syntax for types that engines would entirely ignore, but which tools like TypeScript, Flow, and others could use...."

One noteworthy part of the proposal lays out exactly what is not being proposed:

"Our team isn't proposing putting TypeScript's type-checking in every browser and JavaScript runtime — nor are we proposing any new type-checker to be put in the browser. We think doing that would cause problems for JavaScript and TypeScript users alike due to a range of issues, such as runtime performance, compatibility issues with existing TypeScript code, and the risk of halting innovation in the type-checking space." Similarly, several features from TypeScript that generate code, such as enums, namespaces, and parameter properties, are being explicitly excluded "because they have runtime semantics, generating JavaScript code rather than simply being stripped out and ignored...."

As the proposal's authors note, the proposal itself is presented as a "strawperson proposal".... Thus far, it would appear that there is debate aplenty, alongside a rather robust enthusiasm for the advent of type functionality coming to a JavaScript near you.

"Code generation AI — AI systems that can write in different programming languages given a prompt — promise to cut development costs while allowing coders to focus on creative, less repetitive tasks," writes VentureBeat.

"But while research labs like OpenAI and Alphabet-backed DeepMind have developed powerful code-generating AI, many of the most capable systems aren't available in open source." For example, the training data for OpenAI's Codex, which powers GitHub's Copilot feature, hasn't been made publicly available, preventing researchers from fine-tuning the AI model or studying aspects of it such as interpretability.

To remedy this, researchers at Carnegie Mellon University — Frank Xu, Uri Alon, Graham Neubig, and Vincent Hellendoorn — developed PolyCoder, a model based on OpenAI's GPT-2 language model that was trained on a database of 249 gigabytes of code across 12 programming languages. While PolyCoder doesn't match the performance of top code generators in every task, the researchers claim that PolyCoder is able to write in C with greater accuracy than all known models, including Codex....

"Large tech companies aren't publicly releasing their models, which is really holding back scientific research and democratization of such large language models of code," the researchers said. "To some extent, we hope that our open-sourcing efforts will convince others to do the same. But the bigger picture is that the community should be able to train these models themselves. Our model pushed the limit of what you can train on a single server — anything bigger requires a cluster of servers, which dramatically increases the cost."

Sony Pictures Entertainment is consolidating its anime businesses under the Crunchyroll banner to better compete in the growing streaming market for Japanese animation. From a report: The company is adding hundreds of hours of programming and dozens of titles, including "Cowboy Bebop," to the Crunchyroll streaming service that were previously available through its Funimation outlet, the company said Tuesday. Culver City-based Sony Pictures, the film and TV entertainment arm of Tokyo electronics giant Sony Corp., made a big bet on the anime market last year when it bought streaming service Crunchyroll from AT&T for $1.175 billion. The problem was that Sony then had two subscription streamers focused on the market for Japanese animation. Fans had to subscribe to both Crunchyroll and Funimation to get everything they wanted, in addition to Netflix and other services, said Colin Decker, who runs Sony's anime businesses.

The creator of Apple's Swift programming language stayed involved in the Swift core team and Evolution community... until this week. Though he'd left Apple more than five years ago, "Swift is important to me, so I've been happy to spend a significant amount of time to help improve and steer it," Lattner wrote in an explanatory comment on the Swift community forum. "This included the ~weekly core team meetings (initially in person, then over WebEx)..."

The tech news site DevClass notes Lattner is also "the mind behind compiler infrastructure project LLVM," but reports that "Apparently, Lattner hasn't been part of the [Swift] core team since autumn 2021, when he tried discussing what he perceived as a toxic meeting environment with project leadership after an especially noteworthy call made him take a break in summer." "[...] after avoiding dealing with it, they made excuses, and made it clear they weren't planning to do anything about it. As such, I decided not to return," Lattner wrote in his explanation post. Back then, he planned to keep participating via the Swift Evolution community "but after several discussions generating more heat than light, when my formal proposal review comments and concerns were ignored by the unilateral accepts, and the general challenges with transparency working with core team, I decided that my effort was triggering the same friction with the same people, and thus I was just wasting my time."

Lattner had been the steering force behind Swift since the language's inception in 2010. However, after leaving Apple in 2017 and handing over his project lead role, design premises like "single things that compose" seem to have fallen by the wayside, making the decision to move on completely easier for language-creator Lattner.
The article points out Lattner's latest endeavour is AI infrastructure company Modular.AI.

And Lattner wrote in his comment that Swift's leadership "reassures me they 'want to make sure things are better for others in the future based on what we talked about' though...." Swift has a ton of well meaning and super talented people involved in and driving it. They are trying to be doing the best they can with a complicated situation and many pressures (including lofty goals, fixed schedules, deep bug queues to clear, internal folks that want to review/design things before the public has access to them, and pressures outside their team) that induce odd interactions with the community. By the time things get out to us, the plans are already very far along and sometimes the individuals are attached to the designs they've put a lot of energy into. This leads to a challenging dynamic for everyone involved.

I think that Swift is a phenomenal language and has a long and successful future ahead, but it certainly isn't a community designed language, and this isn't ambiguous. The new ideas on how to improve things sounds promising — I hope they address the fundamental incentive system challenges that the engineers/leaders face that cause the symptoms we see. I think that a healthy and inclusive community will continue to benefit the design and evolution of Swift.
DevClass also reported on the aftermath: Probably as a consequence of the move, the Swift core team is currently looking to restructure project leadership. According to Swift project lead Ted Kremenek... "The intent is to free the core team to invest more in overall project stewardship and create a larger language workgroup that can incorporate more community members in language decisions."

Kremenek also used the announcement to thank Lattner for his leadership throughout the formative years of the project, writing "it has been one of the greatest privileges of my life to work with Chris on Swift."
In 2017 Chris Lattner answered questions from Slashdot's readers.