Why the Creator of Ruby on Rails Prefers Dynamic Typing

“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!).”

Read more of this story at Slashdot.

Rust Foundation Solicits Feedback on Updated Policy for Trademarks

“Rust” and “Cargo” are registered trademarks held by the Rust Foundation — the independent non-profit supporting Rust’s maintainers. In August 1,000 people responded to the foundation’s Trademark Policy Review Survey, after which the foundation invited any interested individuals to join their Trademark Policy Working Group (which also included Rust Project leaders). They’ve now created a draft of an updated policy for feedback…

Crate, RS, “Rustacean,” and the logo of Ferris the crab are all available for use by anyone consistent with their definition, with no special permission required. Here’s how the document’s quick reference describes other common use-cases:
Selling Goods — Unless explicitly approved, use of the Rust name or Logo is not allowed for the purposes of selling products/promotional goods for gain/profit, or for registering domain names. For example, it is not permitted to sell stickers of the Rust logo in an online shop for your personal profit.
Showing Support of Rust — When showing your support of the Rust Project on a personal site or blog, you may use the Rust name or Logo, as long as you abide by all the requirements listed in the Policy. You may use the Rust name or Logo in social media handles, avatars, and emojis to demonstrate Rust Project support in a manner that is decorative, so long as you don’t suggest commercial Rust affiliation.
Inclusion of the Marks in Educational Materials — You may use the Rust name in book and article titles and the Logo in graphic components, so long as you make it clear that the Rust Project or Foundation has not reviewed/approved/endorsed your content.
There’s also a FAQ, answering questions like “Can I use the Rust logo as my Twitter Avatar?” The updated policy draft says “We consider social media avatars on personal accounts to be fair use. On the other hand, using Rust trademarks in corporate social media bios/profile pictures is prohibited…. In general, we prohibit the modification of the Rust logo for any purpose, except to scale it. This includes distortion, transparency, color-changes affiliated with for-profit brands or political ideologies. On the other hand, if you would like to change the colors of the Rust logo to communicate allegiance with a community movement, we simply ask that you run the proposed logo change by us…”

And for swag at events using the Rust logo, “Merch developed for freebies/giveaways is normally fine, however you need approval to use the Rust Word and/or Logo to run a for-profit event. You are free to use Ferris the crab without permission… If your event is for-profit, you will need approval to use the Rust name or Logo. If you are simply covering costs and the event is non-profit, you may use the Rust name or Logo as long as it is clear that the event is not endorsed by the Rust Foundation. You are free to use Ferris the crab without permission.”

Read more of this story at Slashdot.

Something Pretty Right: a History of Visual Basic

Long-time Slashdot reader theodp writes: In Something Pretty Right: A History of Visual Basic, Retool’s Ryan Lucas has a nice round-up of how Visual Basic became the world’s most dominant programming environment, its sudden fall from grace, and why its influence is still shaping the future of software development.

Visual Basic (or VB) burst onto the scene at a magical, transitional moment, presenting a radically simpler alternative for Windows 3.0 development. Bill Gates’ genuine enthusiasm for VB is evident in an accompanying 1991 video in which BillG personally and playfully demonstrates Visual Basic 1.0 at its launch event, as well as in a 1994 video in which Gates thanks Alan Cooper, the
“Father of Visual Basic,” with the Windows Pioneer Award.

For Gates, VB was love at first sight. “It blew his mind, he had never seen anything like it,” recalls Cooper of Gates’s reaction to his 1988 demo of a prototype. “At one point he turned to his retinue and asked ‘Why can’t we do stuff like this?'” Gates even came up with the idea of taking Cooper’s visual programming frontend and replacing its small custom internal language with BASIC.

After seeing what Microsoft had done to his baby, Cooper reportedly sat frustrated in the front row at the launch event. But it’s hard to argue with success, and Cooper eventually came to appreciate VB’s impact. “Had Ruby [Cooper’s creation] gone to the market as a shell construction set,” Cooper said, “it would have made millions of people happier, but then Visual Basic made hundreds of millions of people happier. I was not right, or rather, I was right enough, had a modicum of rightness. Same for Bill Gates, but the two of us together did something pretty right.”

At its peak, Visual Basic had nearly 3.5 million developers worldwide. Many of the innovations that Alan Cooper and Scott Ferguson’s teams introduced 30 years ago with VB are nowhere to be found in modern development, fueling a nostalgic fondness for the ease and magic VB delivered that we have yet to rekindle.

Read more of this story at Slashdot.

Programming Pioneer Grady Booch on Functional Programming, Web3, and Conscious Machines

InfoWorld interviews Grady Booch, chief scientist for software engineering at IBM Research (who is also a pioneer in design patterns, agile methods, and one of the creators of UML).

Here’s some of the highlights:

Q: Let me begin by asking something “of the moment.” There has been an almost cultural war between object-oriented programming and functional programming. What is your take on this?

Booch: I had the opportunity to conduct an oral history with John Backus — one of the pioneers of functional programming — in 2006 on behalf of the Computer History Museum. I asked John why functional programming didn’t enter the mainstream, and his answer was perfect: “Functional programming makes it easy to do hard things” he said, “but functional programming makes it very difficult to do easy things….”

Q: Would you talk a bit about cryptography and Web3?

Booch: Web3 is a flaming pile of feces orbiting a giant dripping hairball. Cryptocurrencies — ones not backed by the full faith and credit of stable nation states — have only a few meaningful use cases, particularly if you are a corrupt dictator of a nation with a broken economic system, or a fraud and scammer who wants to grow their wealth at the expense of greater fools. I was one of the original signatories of a letter to Congress in 2022 for a very good reason: these technologies are inherently dangerous, they are architecturally flawed, and they introduce an attack surface that threatens economies….

Q: What do you make of transhumanism?

Booch: It’s a nice word that has little utility for me other than as something people use to sell books and to write clickbait articles….

Q: Do you think we’ll ever see conscious machines? Or, perhaps, something that compels us to accept them as such?

Booch: My experience tells me that the mind is computable. Hence, yes, I have reason to believe that we will see synthetic minds. But not in my lifetime; or yours; or your children; or your children’s children. Remember, also, that this will likely happen incrementally, not with a bang, and as such, we will co-evolve with these new species.

Read more of this story at Slashdot.

Meet Zig: the Modern Alternative to the C Programming Language

Systems-oriented developers already have programming languages like C, C++, Rust, and Go, notes InfoWorld.

But now, “we also have Zig, a newer language that seeks to absorb what’s best about these languages and offer comparable performance with a better, more reliable developer experience.”

Zig is a very active project. It was started by Andrew Kelley in 2015 and now seems to be reaching critical mass. Zig’s ambition is rather momentous in software history: to become the heir to C’s longstanding reign as both the go-to portable low-level language and as a standard to which other languages are compared….

Currently, Zig is being used to implement the Bun.js JavaScript runtime as an alternative to Node.js. Bun’s creator Jarred Sumner told me “Zig is sort of similar to writing C, but with better memory safety features in debug mode and modern features like defer (sort of similar to Go’s) and arbitrary code can be executed at compile-time via comptime. It has very few keywords so it’s a lot easier to learn than C++ or Rust.”

Zig differs from most other languages in its small feature footprint, which is the outcome of an explicit design goal: Only one obvious way to do things. Zig’s developers take this goal so much to heart that for a time, Zig had no for loop, which was deemed an unnecessary syntactic elaboration upon the already adequate while loop. Kevin Lynagh, coming from a Rust background, wrote, “The language is so small and consistent that after a few hours of study I was able to load enough of it into my head to just do my work.” Nathan Craddock, a C developer, echoed the sentiment. Programmers seem to really like the focused quality of Zig’s syntax.
While Zig is “approaching” production-ready status, the article notes its high degree of interoperability with C and C++, its unique error-handling system, and its elimination of a malloc keyword (leaving memory allocation to the standard library).

“For now, the Zig team appears to be taking its time with the 1.0 release, which may drop in 2025 or later — but none of that stops us from building all sorts of things with the language today.”

Read more of this story at Slashdot.

Google’s Go May Add Telemetry That’s On By Default

Russ Cox, a Google software engineer steering the development of the open source Go programming language, has presented a possible plan to implement telemetry in the Go toolchain. However many in the Go community object because the plan calls for telemetry by default. The Register reports: These alarmed developers would prefer an opt-in rather than an opt-out regime, a position the Go team rejects because it would ensure low adoption and would reduce the amount of telemetry data received to the point it would be of little value. Cox’s proposal summarized lengthier documentation in three blog posts.

Telemetry, as Cox describes it, involves software sending data from Go software to a server to provide information about which functions are being used and how the software is performing. He argues it is beneficial for open source projects to have that information to guide development. And the absence of telemetry data, he contends, makes it more difficult for project maintainers to understand what’s important, what’s working, and to prioritize changes, thereby making maintainer burnout more likely. But such is Google’s reputation these days that many considering the proposal have doubts, despite the fact that the data collection contemplated involves measuring the usage of language features and language performance. The proposal isn’t about the sort of sensitive personal data vacuumed up by Google’s ad-focused groups. “Now you guys want to introduce telemetry into your programming language?” IT consultant Jacob Weisz said. “This is how you drive off any person who even considered giving your project a chance despite the warning signs. Please don’t do this, and please issue a public apology for even proposing it. Please leave a blast radius around this idea wide enough that nobody even suggests trying to do this again.”

He added: “Trust in Google’s behavior is at an all time low, and moves like this are a choice to shove what’s left of it off the edge of a cliff.”

Meanwhile, former Google cryptographer and current open source maintainer Filippo Valsorda said in a post to Mastodon: “This is a large unconventional design, there are a lot of tradeoffs worth discussing and details to explore,” he wrote. “When Russ showed it to me I made at least a dozen suggestions and many got implemented.”

“Instead: all opt-out telemetry is unethical; Google is evil; this is not needed. No one even argued why publishing any of this data could be a problem.”

Read more of this story at Slashdot.

Code-Generating AI Can Introduce Security Vulnerabilities, Study Finds

An anonymous reader quotes a report from TechCrunch: A recent study finds that software engineers who use code-generating AI systems are more likely to cause security vulnerabilities in the apps they develop. The paper, co-authored by a team of researchers affiliated with Stanford, highlights the potential pitfalls of code-generating systems as vendors like GitHub start marketing them in earnest. The Stanford study looked specifically at Codex, the AI code-generating system developed by San Francisco-based research lab OpenAI. (Codex powers Copilot.) The researchers recruited 47 developers — ranging from undergraduate students to industry professionals with decades of programming experience — to use Codex to complete security-related problems across programming languages including Python, JavaScript and C.

Codex was trained on billions of lines of public code to suggest additional lines of code and functions given the context of existing code. The system surfaces a programming approach or solution in response to a description of what a developer wants to accomplish (e.g. “Say hello world”), drawing on both its knowledge base and the current context. According to the researchers, the study participants who had access to Codex were more likely to write incorrect and “insecure” (in the cybersecurity sense) solutions to programming problems compared to a control group. Even more concerningly, they were more likely to say that their insecure answers were secure compared to the people in the control.

Megha Srivastava, a postgraduate student at Stanford and the second co-author on the study, stressed that the findings aren’t a complete condemnation of Codex and other code-generating systems. The study participants didn’t have security expertise that might’ve enabled them to better spot code vulnerabilities, for one. That aside, Srivastava believes that code-generating systems are reliably helpful for tasks that aren’t high risk, like exploratory research code, and could with fine-tuning improve in their coding suggestions. “Companies that develop their own [systems], perhaps further trained on their in-house source code, may be better off as the model may be encouraged to generate outputs more in-line with their coding and security practices,” Srivastava said. The co-authors suggest vendors use a mechanism to “refine” users’ prompts to be more secure — “akin to a supervisor looking over and revising rough drafts of code,” reports TechCrunch. “They also suggest that developers of cryptography libraries ensure their default settings are secure, as code-generating systems tend to stick to default values that aren’t always free of exploits.”

Read more of this story at Slashdot.