For 16 years, Rik Farrow has been an editor for the long-running nonprofit Usenix. He's also been a consultant for 43 years (according to his biography at Usenix.org) — and even wrote the 1988 book Unix System Security: How to Protect Your Data and Prevent Intruders.

Today Farrow stopped by Slashdot to share his thoughts on Codon. rikfarrow writes: Researchers at MIT decided to build a compiler focused on speeding up genomics processing... Recently, they have posted their code on GitHub, and I gave it a test drive.
"Managed" languages produce code for a specific runtime (like JavaScript). Now Farrow's article at Usenix.org argues that Codon produces code "much faster than other managed languages, and in some cases faster than C/C++."

Codon-compiled code is faster because "it's compiled, variables are typed at compile time, and it supports parallel execution." But there's some important caveats: The "version of Python" part is actually an important point: the builders of Codon have built a compiler that accepts a large portion of Python, including all of the most commonly used parts — but not all... Duck typing means that the Codon compiler uses hints found in the source or attempts to deduce them to determine the correct type, and assigns that as a static type. If you wanted to process data where the type is unknown before execution, this may not work for you, although Codon does support a union type that is a possible workaround. In most cases of processing large data sets, the types are known in advance so this is not an issue...

Codon is not the same as Python, in that the developers have not yet implemented all the features you would find in Python 3.10, and this, along with duck typing, will likely cause problems if you just try and compile existing scripts. I quickly ran into problems, as I uncovered unsupported bits of Python, and, by looking at the Issues section of their Github pages, so have other people.

Codon supports a JIT feature, so that instead of attempting to compile complete scripts, you can just add a @codon.jit decorator to functions that you think would benefit from being compiled or executed in parallel, becoming much faster to execute...

Whether your projects will benefit from experimenting with Codon will mean taking the time to read the documentation. Codon is not exactly like Python. For example, there's support for Nvidia GPUs included as well and I ran into a limitation when using a dictionary. I suspect that some potential users will appreciate that Codon takes Python as input and produces executables, making the distribution of code simpler while avoiding disclosure of the source. Codon, with its LLVM backend, also seems like a great solution for people wanting to use Python for embedded projects.

My uses of Python are much simpler: I can process millions of lines of nginx logs in seconds, so a reduction in execution time means little to me. I do think there will be others who can take full advantage of Codon.
Farrow's article also points out that Codon "must be licensed for commercial use, but versions older than three years convert to an Apache license. Non-commercial users are welcome to experiment with Codon."

"I write all novel client-side code as JavaScript instead of TypeScript, and it's a delight," says the creator of Ruby on Rails. Posting on Twitter, David Heinemeier Hansson opined that TypeScript "sucked out much of the joy I had writing JavaScript. I'm forever grateful that Yukihiro 'Matz' Matsumoto didn't succumb to the pressure of adding similar type hints to Ruby."

When it comes to static vs dynamic typing, "I've heard a million arguments from both sides throughout my entire career," Hansson wrote on his blog today, "but seen very few of them ever convinced anyone of anything."

But wait — he thinks we can all get along: Personally, I'm unashamedly a dynamic typing kind of guy. That's why I love Ruby so very much. It takes full advantage of dynamic typing to allow the poetic syntax that results in such beautiful code. To me, Ruby with explicit, static typing would be like a salad with a scoop of ice cream. They just don't go together.

I'll also confess to having embraced the evangelical position for dynamic typing in the past. To the point of suffering from a One True Proposition affliction. Seeing the lack of enthusiasm for dynamic typing as a reflection of missing education, experience, or perhaps even competence.

Oh what folly. Like trying to convince an introvert that they'd really like parties if they'd just loosen up a bit...

These days, I've come to appreciate the magnificence of multiplicity. Programming would be an awful endeavor if we were all confined to the same paradigm. Human nature is much too varied to accept such constraint on its creativity...But it took a while for me to come to these conclusions. I'm a recovering solutionist. So when I see folks cross their heart in disbelief that anyone, anywhere might fancy JavaScript over TypeScript, I smile, and I remember the days when I'd recognize their zeal in the mirror.
Hansson also sees the "magnificence of multiplicity" in positions about functional vs object-oriented programming. "Poles on both these axes have shown to deliver excellent software over the decades (and awful stuff too!)."

While working at Apple, Chris Lattner designed Swift to "fully leverage the power of LLVM," and "led a team for a while at Google to try to move Swift out of its Apple comfort zone, to become a replacement for Python in AI model development." That's according to a blog post by Jeremy Howard, an advisor to Lattner's Modular AI (which he co-founded in 2022 to build a next-generation AI platform for developers).

"But sadly," Howard writes, Swift "did not receive the support it needed from either Apple or from Google, and it was not ultimately successful." And yet... [W]hilst at Google Chris did develop another project which became hugely successful: MLIR. MLIR is a replacement for LLVM's intermediate representation [or IR] for the modern age of many-core computing and AI workloads. It's critical for fully leveraging the power of hardware like GPUs, TPUs, and the vector units increasingly being added to server-class CPUs.

So, if Swift was "syntax sugar for LLVM", what's "syntax sugar for MLIR"? The answer is: Mojo! Mojo is a brand new language that's designed to take full advantage of MLIR. And also Mojo is Python.

Wait what?

OK let me explain. Maybe it's better to say Mojo is Python++. It will be (when complete) a strict superset of the Python language. But it also has additional functionality so we can write high performance code that takes advantage of modern accelerators...

Whereas Swift was a brand new language packing all kinds of cool features based on latest research in programming language design, Mojo is, at its heart, just Python. This seems wise, not just because Python is already well understood by millions of coders, but also because after decades of use its capabilities and limitations are now well understood. Relying on the latest programming language research is pretty cool, but its potentially-dangerous speculation because you never really know how things will turn out...

A key trick in Mojo is that you can opt in at any time to a faster "mode" as a developer, by using "fn" instead of "def" to create your function. In this mode, you have to declare exactly what the type of every variable is, and as a result Mojo can create optimised machine code to implement your function. Furthermore, if you use "struct" instead of "class", your attributes will be tightly packed into memory, such that they can even be used in data structures without chasing pointers around. These are the kinds of features that allow languages like C to be so fast, and now they're accessible to Python programmers too — just by learning a tiny bit of new syntax...

I can't begin to describe all the little (and big!) ideas throughout Mojo's design and implementation — it's the result of Chris and his team's decades of work on compiler and language design and includes all the tricks and hard-won experience from that time — but what I can describe is an amazing result that I saw with my own eyes.
Mojo hasn't been released to the public yet, (other than an online "playground" with a waitlist where they're "rolling out access slowly.") But the blog post notes that creating a programming language's syntax is usually complex, error-prone, and controversial — a problem Mojo neatly avoids by "outsourcing" its syntax to an existing language, "which also happens to be the most widely used language today."

And "As a compiled language, Mojo's deployment story is basically the same as C," the post argues. [That is, "you can literally just make the compiled program available for direct download. It can be just 100k or so in size, and will launch and run quickly."]

"This means that Mojo is far more than a language for AI/ML applications. It's actually a version of Python that allows us to write fast, small, easily-deployed applications that take advantage of all available cores and accelerators!"

Python 3.12 was released today, with improvements to speed and efficiency, reports InfoWorld. Core developers explained the improvements at this year's PyCon convention in Salt Lake City, Utah, including efforts to reduce Python's memory use, make the interpreter faster, and optimize compilation for more efficient code: Subinterpreters is a mechanism where the Python runtime can have multiple interpreters running together inside a single process, as opposed to each interpreter being isolated in its own process (the current multiprocessing mechanism)... While subinterpreters have been available in the Python runtime for some time now, they haven't had an interface for the end user. Also, the messy state of Python's internals hasn't allowed subinterperters to be used effectively. With Python 3.12, core python developer Eric Snow and his cohort cleaned up Python's internals enough to make subinterpreters useful, and they are adding a minimal module to the Python standard library called interpreters. This gives programmers a rudimentary way to launch subinterpreters and execute code on them.

Snow's own initial experiments with subinterpreters significantly outperformed threading and multiprocessing. One example, a simple web service that performed some CPU-bound work, maxed out at 100 requests per second with threads, and 600 with multiprocessing. But with subinterpreters, it yielded 11,500 requests, and with little to no drop-off when scaled up from one client. The interpreters module has very limited functionality right now, and it lacks robust mechanisms for sharing state between subinterpreters. But Snow believes by Python 3.13 a good deal more functionality will appear, and in the interim developers are encouraged to experiment...

Python 3.11 introduced new bytecodes to the interpreter, called adaptive instructions. These instructions can be replaced automatically at runtime with versions specialized for a given Python type, a process called quickening. This saves the interpreter the step of having to look up what types the objects are, speeding up the whole process enormously. For instance, if a given addition operation regularly takes in two integers, that instruction can be replaced with one that assumes the operands are both integers... Python 3.12 has more adaptive specialization opcodes...
And starting with Python 3.12, object headers now use 96 bytes, which InfoWorld reports is "slightly less than half of what it was before."

AI startup Hugging Face and ServiceNow Research, ServiceNow's R&D division, have released StarCoder, a free alternative to code-generating AI systems along the lines of GitHub's Copilot. From a report: Code-generating systems like DeepMind's AlphaCode; Amazon's CodeWhisperer; and OpenAI's Codex, which powers Copilot, provide a tantalizing glimpse at what's possible with AI within the realm of computer programming. Assuming the ethical, technical and legal issues are someday ironed out (and AI-powered coding tools don't cause more bugs and security exploits than they solve), they could cut development costs substantially while allowing coders to focus on more creative tasks.

According to a study from the University of Cambridge, at least half of developers' efforts are spent debugging and not actively programming, which costs the software industry an estimated $312 billion per year. But so far, only a handful of code-generating AI systems have been made freely available to the public -- reflecting the commercial incentives of the organizations building them (see: Replit). StarCoder, which by contrast is licensed to allow for royalty-free use by anyone, including corporations, was trained on over 80 programming languages as well as text from GitHub repositories, including documentation and programming notebooks. StarCoder integrates with Microsoft's Visual Studio Code code editor and, like OpenAI's ChatGPT, can follow basic instructions (e.g., "create an app UI") and answer questions about code.

Phoronix reports: With the financial backing of Amazon Web Services, sudo and su are being rewritten in the Rust programming language in order to increase the memory safety for the widely relied upon software... to further enhance Linux/open-source security.
"[B]ecause it's written in C, sudo has experienced many vulnerabilities related to memory safety issues," according to a blog post announcing the project: It's important that we secure our most critical software, particularly from memory safety vulnerabilities. It's hard to imagine software that's much more critical than sudo and su.

This work is being done by a joint team from Ferrous Systems and Tweede Golf with generous support from Amazon Web Services. The work plan is viewable here. The GitHub repository is here.

HackerNoon tested five AI bots on coding problems from Leetcode.com — GPT-4, GitHub Co-Pilot, Bard, Bing, and Claude+.

There's some interesting commentary on the strengths and weaknesses of each one -- and of course, the code that they ultimately output. The final results? [GPT-4's submission] passes all tests. It beat 47% of submissions on runtime and 8% on memory. GPT-4 is highly versatile in generating code for various programming languages and applications. Some of the caveats are that it takes much longer to get a response. API usage is also a lot more expensive and costs could ramp up quickly. Overall it got the answer right and passed the test.

[Bing's submission] passed all the tests. It beat 47% of submissions on runtime and 37% on memory. This code looks a lot simpler than what GPT-4 generated. It beat GPT-4 on memory and it used less code! Bing seems to have the most efficient code so far, however, it gave a very short explanation of how it solved it. Nonetheless, best so far.
But both Bard and Claude+ failed the submission test (badly), while GitHub Copilot "passes all the tests. It scored better than 30% of submissions on runtime and 37% on memory."

Long-time software engineer Blake1024 (Slashdot reader #846,727) writes: We are thrilled to announce the release of Kiss v2.0, a comprehensive, Java-based, open-source, full-stack web development framework... Kiss v2.0 provides an even more seamless, out-of-the-box experience, including pre-configured front-end and back-end components... Key Features:

* Custom HTML controls
* RESTful web services
* Microservices architecture
* Built-in authentication
* SQL API integration
* Robust reporting capabilities

Kiss utilizes microservices, allowing developers to work on a running system without the need for rebuilds, redeploys, or server reboots... Production systems can be updated without any downtime.

With proven success in commercial applications, Kiss v2.0 is ready for prime time. It's not a beta, but a reliable solution for your web development needs.

Jules Wang from Android Police reports on the cases of two icon pack artists who had their products taken down from the Play Store for supposedly violating the platform's Repetitive Content policy. Despite both creators' products being reinstated, they revealed that Google's opaque application of its rules has caused frustration and hopelessness among developers. From the report: All this heartache stems from Google Play's Repetitive Content policy. While on its face a well-meaning effort to reduce spammy apps and keep quality up, there's a core problem with compliance when creators find themselves forced to use apps to distribute content: "If these apps are each small in content volume, developers should consider creating a single app that aggregates all the content."

If you've browsed on the Play Store, you'll immediately know this guidance isn't universally followed: many artists like JustNewDesigns will have multiple designs in their portfolio and each of those designs will come in multiple colorways or shapeways -- whether they're changing out an accent in a line design or are implementing some sort of adaptive element.

Not only are there so many apps, but they also look so much alike -- artists, many of whom might not consider coding their strong suit, tend to use open-source templates to create the actual app. You'll likely see them credited to Sarsa Murmu, who runs a GitHub project called CandyBar, or Jahir Fiquitiva, the maintainer of the Blueprint repository. These resources take care of the "packaging" for the assets. They include integration compatibility with various popular launchers, a license scheme to prevent those who sideloaded the app for free from having the icons applied, and all sorts of other functionality. In addition to the icon assets, the apps may also house wallpapers and links to other apps. [...] What is Google's role and what should it be? Wang writes: Artists would have much to gain from a new or revised API. Adding and adapting new icon designs to existing products would be much easier. New designs may be able to take advantage of changes to the Adaptive Icons API as Google lays them out. There would be unease as to how the business model could shift -- should publishers charge by the app, through in-app purchases, or both? But as it stands, the biggest benefit with such a change is that it would presumably get Play's "RoboCops" off their back. Of course, we can't be sure of that with how Google's enforcement apparatus operates, but the notion of unfairness lends credibility to those supporting the status quo unless the company is willing to come to the bargaining table.

At the end of the day, Google is certainly within its right to build regulations around apps to respond to emergent scammers and distressing content. Automation is meant to render manageable the sheer volume of content the Play platform sees published on a daily basis. But so long as icon artists sit under threat from a rulebook that can be arbitrarily thrown at them at any time, if nothing changes, we may be on a road leading to the degradation of a core Android tenet that even the most casual tech consumer associates with the platform -- user customizability.

Last year Python's massive PyPI repository of pre-written software packages had 235.7 billion downloads — a 57% annual growth in its download counts and bandwidth. So now Python's nonprofit Python Software Foundation has an announcement.

Their director of infrastructure said today that they're rolling out "the first step in our plan to build financial support and long-term sustainability of PyPI, while simultaneously giving our users one of our most requested features: organization accounts." Organizations on PyPI are self-managed teams, with their own exclusive branded web addresses. Our goal is to make PyPI easier to use for large community projects, organizations, or companies who manage multiple sub-teams and multiple packages.

We're making organizations available to community projects for free, forever, and to corporate projects for a small fee. Additional priority support agreements will be available to all paid subscribers, and all revenue will go right back into PyPI to continue building better support and infrastructure for all our users... Having more people using and contributing to Python every year is an fantastic problem to have, but it is one we must increase organizational capacity to accommodate. Increased revenue for PyPI allows it to become a staffed platform that can respond to support requests and attend to issues in a timeframe that is significantly faster than what our excellent (but thinly spread) largely volunteer team could reasonably handle.

We want to be very clear — these new features are completely optional. If features for larger projects don't sound like something that would be useful to you as a PyPI maintainer, then there is no obligation to create an organization and absolutely nothing about your PyPI experience will change for you.

We look forward to discussing what other features PyPI users would like to see tackled next...

Long-time Slashdot reader theodp writes: According to Google Trends, peak "Lean to Code" occurred in early 2019 when laid-off Buzzfeed and Huffpost journalists were taunted with the phrase on Twitter... As Meta founder and CEO Mark Zuckerberg recently put it, "We're in a different world." Indeed. Encouraging kids to pursue CS careers in Code.org's viral 2013 launch video, Zuckerberg explained, "Our policy at Facebook is literally to hire as many talented engineers as we can find."

In Learning to Code Isn't Enough, a new MIT Technology Review article, Joy Lisi Rankin reports on the long history of learn-to-code efforts, which date back to the 1960s. "Then as now," Lisi Rankin writes, "just learning to code is neither a pathway to a stable financial future for people from economically precarious backgrounds nor a panacea for the inadequacies of the educational system."
But is that really true? Vox does note that the latest round of layoffs at Meta "is impacting workers in core technical roles like data scientists and software engineers — positions once thought to be beyond reproach." Yet while that's also true at other companies, those laid-off tech workers also seem to be finding similar positions by working in other industries: Software engineers were the most overrepresented position in layoffs in 2023, relative to their employment, according to data requested by Vox from workforce data company Revelio Labs. Last year, when major tech layoffs first began, recruiters and customer success specialists experienced the most outsize impact. So far this year, nearly 20 percent of the 170,000 tech company layoffs were software engineers, even though they made up roughly 14 percent of employees at these companies. "Early layoffs were dominated by recruiters, which is forgoing future hiring," Revelio senior economist Reyhan Ayas told Vox. "Whereas in 2023 we see a shift toward more core engineering and software engineering, which signals a change in focus of current business priorities."

In other words, tech companies aren't just trimming the fat by firing people who fill out their extensive ecosystem, which ranges from marketers to massage therapists. They're also, many for the first time, making cuts to the people who build the very products they're known for, and who enjoyed a sort of revered status since they, like the founders of the companies, were coders. Software engineers are still important, but they don't have the power they used to...

The latest monthly jobs report by tech industry association CompTIA found that even though employment at tech companies (which includes all roles at those companies) declined slightly in March, employment in technical occupations across industry sectors increased by nearly 200,000 positions. So even if tech companies are laying off tech workers, other industries are snatching them up. Unfortunately for software engineers and the like, that means they might also have to follow those industries' pay schemes. The average software engineer base pay in the US is $90,000, according to PayScale, but can be substantially higher at tech firms like Facebook, where such workers also get bonuses and stock options.

The Rust team released a new version Thursday — Rust 1.69.0 — boasting over over 3,000 new commits from over 500 contributors.

Phoronix highlights two new improvements: In order to speed-up compilation speeds, Rust 1.69 and moving forward debug information is no longer included in build scripts by default. Cargo will avoid emitting debug information in build scripts by default — leading to less informative backtraces in build scripts when problems arise, but faster build speeds by default. Those wanting the debug information emitted can now set the debug flag in their Cargo.toml configuration.

The Cargo build shipped by Rust 1.69 is also now capable of suggesting fixes automatically for some of the generated warnings. Cargo will also suggest using "cargo fix" / "cargo clippy --fix" when it knows the errors can be automatically fixed.

"The Rust Foundation on Monday apologized for confusion caused by the organization's proposed trademark policy changes," reports the Register.

The Foundation now says their proposed policy "clearly needs improvement" and "there are many valid critiques of the initial draft," promising to address them and adopt a more transparent process (with a report summarizing the feedback soon). From the Register's report: The foundation, which provides financial and legal support for the memory-safe programming language, had proposed fresh rules on the use of the word Rust and its logo, which included the recommendation that people not use 'Rust' in their Rust crate names, eg: vulture-rs would be preferred over vulture-rust. These draft changes triggered a backlash... Over the weekend, Rust creator Graydon Hoare voiced support for the community's objections in a Reddit discussion thread, in response to a post by programmer Andrew Gallant, a former member of the Rust moderation team, who argued the new policy was not all that different from the old one.

"Open them up side by side — old and new — and look at what they each say about, specifically, package names, project names, repos or websites using the word 'rust', or modified versions of the logo used for small groups or projects," wrote Hoare. "These are specifically the things people are upset about, because they all changed from 'acceptable' to 'prohibited' when 'clarifying' the policy. And those are specifically things that everyone in the community does, and has done, for years. There are zillions of packages, projects, repos, websites and groups using the names and logo this way, as the old policy said they could. The new policy tells them all to stop."
Long-time open source advocate Bruce Perens told the Register that Rust's trademark policy "goes far awry of fair use which is legally permitted. Books on Rust will always have its name in their title, commercial products will be advertised as being written in Rust, being compatible with Rust, or compiling Rust. But the policy attempts to deny permission for these things. A proper trademark policy prevents others from representing that their product is Rust or is endorsed by the trademark holder of Rust. That's really as much as you can ever enforce, so there's no sense in a policy that asks for more."

The Register also spoke to Ashley Williams, a former member of the Rust core team and the original executive director and founder of the Rust Foundation, who argued upheaval in Rust's governance over the past year led to a team with less experience dealing with the Rust community. "I think a couple of very passionate people participated in the trademark working group and they didn't involve a lot of people who have even basic experience interacting with the community. So really classic community behaviors ended up getting prohibited in that [draft] policy. And that's really why everybody got upset. The policy ultimately said, 'a thing that you do all the time as a way of contributing to the Rust community is now against our policy.'"

ChatGPT, OpenAI's large language model for chatbots, not only produces mostly insecure code but also fails to alert users to its inadequacies despite being capable of pointing out its shortcomings. The Register reports: Amid the frenzy of academic interest in the possibilities and limitations of large language models, four researchers affiliated with Universite du Quebec, in Canada, have delved into the security of code generated by ChatGPT, the non-intelligent, text-regurgitating bot from OpenAI. In a pre-press paper titled, "How Secure is Code Generated by ChatGPT?" computer scientists Raphael Khoury, Anderson Avila, Jacob Brunelle, and Baba Mamadou Camara answer the question with research that can be summarized as "not very."

"The results were worrisome," the authors state in their paper. "We found that, in several cases, the code generated by ChatGPT fell well below minimal security standards applicable in most contexts. In fact, when prodded to whether or not the produced code was secure, ChatGPT was able to recognize that it was not." [...] In all, ChatGPT managed to generate just five secure programs out of 21 on its first attempt. After further prompting to correct its missteps, the large language model managed to produce seven more secure apps -- though that's "secure" only as it pertains to the specific vulnerability being evaluated. It's not an assertion that the final code is free of any other exploitable condition. [...]

The academics observe in their paper that part of the problem appears to arise from ChatGPT not assuming an adversarial model of code execution. The model, they say, "repeatedly informed us that security problems can be circumvented simply by 'not feeding an invalid input' to the vulnerable program it has created." Yet, they say, "ChatGPT seems aware of -- and indeed readily admits -- the presence of critical vulnerabilities in the code it suggests." It just doesn't say anything unless asked to evaluate the security of its own code suggestions.

Initially, ChatGPT's response to security concerns was to recommend only using valid inputs -- something of a non-starter in the real world. It was only afterward, when prompted to remediate problems, that the AI model provided useful guidance. That's not ideal, the authors suggest, because knowing which questions to ask presupposes familiarity with specific vulnerabilities and coding techniques. The authors also point out that there's ethical inconsistency in the fact that ChatGPT will refuse to create attack code but will create vulnerable code.

The Linux Foundation, the nonprofit tech consortium that manages various open source efforts, today announced the launch of the TLA+ Foundation to promote the adoption and development of the TLA+ programming language. AWS, Oracle and Microsoft are among the inaugural members. From a report: What is the TLA+ programming language, you ask? It's a formal "spec" language developed by computer scientist and mathematician Leslie Lamport. Best known for his seminal work in distributed systems, Lamport -- now a scientist at Microsoft Research -- created TLA+ to design, model, document and verify software programs -- particularly those of the concurrent and distributed variety.

To give a few examples, ElasticSearch, the organization behind the search engine of the same name, used TLA+ to verify the correctness of their distributed systems algorithms. Elsewhere, Thales, the electrical systems manufacturing firm, used TLA+ to model and develop fault-tolerant modules for its industrial control platform. "TLA+ is unique in that it's intended for specifying a system, rather than for implementing software," a Linux Foundation spokesperson told TechCrunch via email. "Based on mathematical concepts, notably set theory and temporal logic, TLA+ allows for the expression of a system's desired correctness properties in a formal and rigorous manner."

Apple in iOS 17 will for the first time allow iPhone users to download apps hosted outside of its official App Store, according to Bloomberg's Mark Gurman. From a report: Otherwise known as sideloading, the change would allow customers to download apps without needing to use the App Store, which would mean developers wouldn't need to pay Apple's 15 to 30 percent fees. The European Union's Digital Markets Act (DMA), which went into effect on November 1, 2022, requires "gatekeeper" companies to open up their services and platforms to other companies and developers. The DMA will have a big impact on Apple's platforms, and it could result in Apple making major changes to the App Store, Messages, FaceTime, Siri, and more. Apple is planning to implement sideloading support to comply with the new European regulations by next year, according to Gurman.

"Java would become easier for students to learn under a proposal to introduce flexible main methods and anonymous main classes to the language," reports InfoWorld.

Details of the plan include enhancing the protocol by which Java programs are launched to be flexible, in particular to allow the String[] parameter of main methods to be omitted and allow main methods to be neither public nor static; the Hello World program would be simplified. Anonymous main classes would be introduced to make the class declaration implicit.
It's currently a disabled-by-default preview language feature in JDK 21 (scheduled for General Availability in September), included to provoke developer feedback based on real world use (which may lead to it becoming permanent in the future). This wouldn't introduce a separate beginner's dialect or beginners' toolchain of Java, emphasizes Java Enhancement Proposal (JEP) 445. "Student programs should be compiled and run with the same tools that compile and run any Java program."

But it argues that a simple "Hello World" program today has "too much clutter...too much code, too many concepts, too many constructs — for what the program does."


public class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello, World!");
}
}



Anonymous main classes would make the public class declaration implicit (while also sparing newbies the "mysterious" modifier static and the args parameter String[] ). The program is streamlined to:


void main() {
System.out.println("Hello, World!");
}


The proposal argues this change reduces "the ceremony of writing simple programs such as scripts and command-line utilities." And since Java is intended to be a first programming language, this change would mean students "can write their first programs without needing to understand language features designed for large programs," using instead "streamlined declarations for single-class programs". (This allows students and educators to explore language features more gradually.) A Hello, World! program written as an anonymous main class is much more focused on what the program actually does, omitting concepts and constructs it does not need. Even so, all members are interpreted just as they are in an ordinary class. To evolve an anonymous main class into an ordinary class, all we need to do is wrap its declaration, excluding import statements, inside an explicit class declaration.

Amazon is making its AI-powered coding assistant CodeWhisperer free for individual developers, reports the Verge, "undercutting the $10 per month pricing of its Microsoft-made rival." Amazon launched CodeWhisperer as a preview last year, which developers can use within various integrated development environments (IDEs), like Visual Studio Code, to generate lines of code based on a text-based prompt....

CodeWhisperer automatically filters out any code suggestions that are potentially biased or unfair and flags any code that's similar to open-source training data. It also comes with security scanning features that can identify vulnerabilities within a developer's code, while providing suggestions to help close any security gaps it uncovers. CodeWhisperer now supports several languages, including Python, Java, JavaScript, TypeScript, and C#, including Go, Rust, PHP, Ruby, Kotlin, C, C++, Shell scripting, SQL, and Scala.
Here's how Amazon's senior developer advocate pitched the usefulness of their "real-time AI coding companion": Helping to keep developers in their flow is increasingly important as, facing increasing time pressure to get their work done, developers are often forced to break that flow to turn to an internet search, sites such as StackOverflow, or their colleagues for help in completing tasks. While this can help them obtain the starter code they need, it's disruptive as they've had to leave their IDE environment to search or ask questions in a forum or find and ask a colleague — further adding to the disruption. Instead, CodeWhisperer meets developers where they are most productive, providing recommendations in real time as they write code or comments in their IDE. During the preview we ran a productivity challenge, and participants who used CodeWhisperer were 27% more likely to complete tasks successfully and did so an average of 57% faster than those who didn't use CodeWhisperer....

It provides additional data for suggestions — for example, the repository URL and license — when code similar to training data is generated, helping lower the risk of using the code and enabling developers to reuse it with confidence.

Several government cybersecurity agencies united to urge secure-by-design and secure-by-default software. Releasing "joint guidance" for software manufactuers were two U.S. security agencies — the FBI and the NSA — joined with the U.S. Cybersecurity and Infrastructure Security Agency and the cybersecurity authorities of Australia, Canada, the United Kingdom, Germany, Netherlands, and New Zealand. "To create a future where technology and associated products are safe for customers," they wrote in a joint statement, "the authoring agencies urge manufacturers to revamp their design and development programs to permit only secure-by-design and -default products to be shipped to customers."

The Washington Post reports: Software manufacturers should put an end to default passwords, write in safer programming languages and establish vulnerability disclosure programs for reporting flaws, a collection of U.S. and international government agencies said in new guidelines Thursday. [The guidelines also urge rigorous code reviews.]

The "principles and approaches" document, which isn't mandatory but lays out the agencies' views on securing software, is the first major step by the Biden administration as part of its push to make software products secure as part of the design process, and to make their default settings secure as well. It's part of a potentially contentious multiyear effort that aims to shift the way software makers secure their products. It was a key feature of the administration's national cybersecurity strategy, which was released last month and emphasized shifting the burden of security from consumers — who have to manage frequent software updates — to the companies that make often insecure products... The administration has also raised the prospect of legislation on secure-by-design and secure-by-default, but officials have said it could be years away....

The [international affairs think tank] Atlantic Council's Cyber Statecraft Initiative has praised the Biden administration's desire to address economic incentives for insecurity. Right now, the costs of cyberattacks fall on users more than they do tech providers, according to many policymakers. "They're on a righteous mission," Trey Herr, director of the Atlantic Council initiative, told me. If today's guidelines are the beginning of the discussion on secure-by-design and secure-by-default, Herr said, "this is a really strong start, and an important one."

"It really takes aim at security features as a profit center," which for some companies has led to a lot of financial growth, Herr said. "I do think that's going to rub people the wrong way and quick, but that's good. That's a good fight."
In the statement CISA's director says consumers also have a role to play in this transition. "As software now powers the critical systems and services we collectively rely upon every day, consumers must demand that manufacturers prioritize product safety above all else."

Among other things, the new guidelines say that manufacturers "are encouraged make hard tradeoffs and investments, including those that will be 'invisible' to the customers, such as migrating to programming languages that eliminate widespread vulnerabilities."

The Python Software Foundation is "concerned that proposed EU cybersecurity laws will leave open source organizations and individuals unfairly liable for distributing incorrect code," according to the Register. The PSF reviewed the EU's proposed "Cyber Resilience Act" and "Product Liability Act" and reports "issues that put the mission of our organization and the health of the open-source software community at risk."

From the Register's report: "If the proposed law is enforced as currently written, the authors of open-source components might bear legal and financial responsibility for the way their components are applied in someone else's commercial product," the PSF said in a statement shared on Tuesday by executive director Deb Nicholson. "The existing language makes no differentiation between independent authors who have never been paid for the supply of software and corporate tech behemoths selling products in exchange for payments from end-users...."

The PSF argues the EU lawmakers should provide clear exemptions for public software repositories that serve the public good and for organizations and developers hosting packages on public repositories. "We need it to be crystal clear who is on the hook for both the assurances and the accountability that software consumers deserve," the PSF concludes. The PSF is asking anyone who shares its concerns to convey that sentiment to an appropriate EU Member of Parliament by April 26, while amendments focused on protecting open source software are being considered.

Bradley Kuhn, policy fellow at the Software Freedom Conservancy, told The Register that the free and open source (FOSS) community should think carefully about the scope of the exemptions being sought. "I'm worried that many in FOSS are falling into a trap that for-profit companies have been trying to lay for us on this issue," he said. "While it seems on the surface that a blanket exception for FOSS would be a good thing for FOSS, in fact, this an attempt for companies to get the FOSS community to help them skirt their ordinary product liability. For profit companies that deploy FOSS should have the same obligations for security and certainty for their users as proprietary software companies do."
The article points out that numerous tech organizations are urging clarifications in the proposed regulations, including NLnet Labs and the Eclipse Foundation.