0 Persons are tagged with #programminglanguages

#programminglanguages

waynerad@diasp.org
Wayne Radinsky

Technique for adding compile-time checks to anything you can define as an invariant.

Many people have tried to make it so that buggy programs simply don't compile. But the netstack3 team has a concrete, general framework for approaching this kind of design. He broke the process into three steps: definition, enforcement, and consumption. For definition, the programmer must take something that Rust can reason about (usually types) and attach the desired property to it. This is usually done via documentation -- describing that a particular trait represents a particular property, for example. Then the programmer enforces the property by making sure that all of the code that directly deals with the type upholds the relevant invariant.

The article goes on to describe some specific techniques for doing this: adding a hidden field to a structure that is used to verify the invariant condition is being fulfilled, and zero-sized types that don't exist at run time, and have no run-time overhead, but enable the compiler to check things. The example language is Rust but these techniques may generalize to other languages and type systems.

Safety in an unsafe world [LWN.net]

#solidstatelife #computerscience #programminglanguages

2 Likes
5 Comments
waynerad@diasp.org
Wayne Radinsky

"The Safe C++ project adds new technology for ensuring memory safety, and isn't just a reiteration of best practices."

"Safe C++ prevents users from writing unsound code. This includes compile-time intelligence like borrow checking to prevent use-after-free bugs and initialization analysis for type safety.'"

"Sean Baxter, creator of the Circle compiler, said that rewriting a project in a different programming language is costly, so the aim here is to make memory safety more accessible by providing the same soundness guarantees as Rust at a lower cost. 'With Safe C++, existing code continues to work as always,' he explained. 'Stakeholders have more control for incrementally opting in to safety.'"

The empire of C++ strikes back with Safe C++ blueprint - The Register

#solidstatelife #computerscience #programminglanguages

5 Likes
2 Likes
waynerad@diasp.org
Wayne Radinsky

Douglas Crockford says we should quit using JavaScript.

Douglas Crockford is the author of JavaScript: The Good Parts, creator of JSLint, the linter that has become the basis for JSHint, ESLint, etc -- all the JavaScript linters -- and creator of the JSON data interchange format.

"There are lots of terrible mistakes in the way that the web works, in the way our operating systems work, and we can't get new ones. We're just stuck with this crap and they keep piling new features on everything and the new features always create new problems and it doesn't have to be like that. We could be using a really clean operating systems with really clean languages and really clean runtimes and doing all this stuff in a much more reliable way. But we don't seem to want to do that."

I have a theory as to why we never seem to want to do that. But first, an explanation (quickly) of how I came to have some appreciation for what I've come to call "minimalism" -- the idea that in programming languages, more is not better. I've told the story before so you can skip if you've already heard it. Years ago I was working on a C++ project and my boss said, "Hey Wayne, so-and-so has left the company. You're taking over his code and we need you to fix some bugs and add some new features immediately." I went into his code... and couldn't even read it. Like, at all. It was like it was written in C++. I thought I knew C++, but no -- I realized that C++ was such a huge language (the official spec was something like 1,100 pages if memory serves -- it's probably even bigger now) that every developer uses a subset of C++. My subset and his subset had little overlap. This is not a recipe for long-term maintainability. For long term maintainability, one of the things you want is what I've come to call "ambiguity reduction". It's important to realize this is about the human reading the code, not the machine. To the machine, everything is always deterministic, no matter how complex. For the human, you want to be able to read a line of code and know exactly what it does. This makes it easy to reason about the program's behavior. This means not having hidden "magic" in programming language features. The more of these "magic" features you have to memorize, and the more complex the rules you have to memorize, the more liklihood you have ambiguity when you read lines of code.

Ok, now to my theory as to why "we don't seem to want to do that" -- make really 'clean' languages. New languages are often created by new people entering the industry, who have great enthusiam for one or another set of ideas. But what they don't know is how a design decision you make today will affect your software 10 or 20 years down the line. For that, you need to have been around for 10 or 20 years, and had that experience. In other words, it's the old people that have that knowledge. They "greybeards". And whatever the equivalent term is for the gals. But because the industry has been expanding exponentially, more or less since its inception, the old people are always outnumbered by the young people. And the young people think "more is better" so they always pile on the features. (Now we have young people with LLMs.)

What do y'all think?

Why we should stop using JavaScript according to Douglas Crockford (inventor of JSON) - Honeypot

#solidstatelife #computerscience #programminglanguages

6 Likes
8 Comments
waynerad@diasp.org
Wayne Radinsky

"Rust is the fastest-growing programming language, with its developer community doubling in size over the past two years, yet JavaScript remains the most popular language with 25.2 million active developers, according to the results of a recent survey."

"Python has overtaken Java as the second most popular language, driven by the interest in machine learning and AI."

"Meanwhile, the Go language saw its developer population grow by 10% over the last year."

"Objective-C has stagnated for the last two years."

"Swift has seen a small growth over the past 12 months (5%) to 4.6 million developers, which led to it being overtaken by Go."

Rust growing fastest, but JavaScript reigns supreme

#solidstatelife #computerscience #programminglanguages

Rust Growing Fastest, But JavaScript Reigns Supreme

The Rust community doubled its number of users over the past two years -- from two million in the first quarter of 2022 to four million in the first quarter of 2024.

2 Likes
13 Comments
1 Shares
5 Likes
1 Comments
waynerad@diasp.org
Wayne Radinsky

"Mojo vs Rust: is Mojo faster than Rust?"

"Rust was started in 2006 and Swift was started in 2010, and both are primarily built on top of LLVM IR. Mojo started in 2022 and builds on MLIR (Multi-Level Intermediate Representation), which is a more modern 'next generation' compiler stack than the LLVM IR approach that Rust uses. There is a history here: our CEO Chris Lattner started LLVM in college in Dec 2000 and learned a lot from its evolution and development over the years. He then led the development of MLIR at Google to support their TPU and other AI accelerator projects, taking that learning from LLVM IR to build the next step forward: described in this talk from 2019."

"Mojo is the first programming language to take advantage of all the advances in MLIR, both to produce more optimized CPU code generation, but also to support GPUs and other accelerators, and to also have much faster compile times than Rust. This is an advantage that no other language currently provides, and it's why a lot of AI and compiler nerds are excited about Mojo. They can build their fancy abstractions for exotic hardware, while us mere mortals can take advantage of them with Pythonic syntax."

The article goes on to describe Mojo's native support for SIMD which stands for "Single Instruction, Multiple Data" and refers to special instructions that have been part of CPUs for a long time but are hard to use.

Mojo frees memory on the last use of an object, instead of waiting for when an object goes out of scope, a subtle difference that makes a big difference in the field of AI, "where freeing an object early can mean deallocating a GPU tensor earlier, therefore fitting a larger model in GPU RAM." It's also advantageous in a type of optimization called tail call optimization that applies to recursive functions.

Mojo vs Rust: is Mojo faster than Rust?

#solidstatelife #ai #computerscience #programminglanguages #python #mojo #rust

Modular: Mojo vs. Rust: is Mojo 🔥 faster than Rust 🦀 ?

We are building a next-generation AI developer platform for the world. Check out our latest post: Mojo vs. Rust: is Mojo 🔥 faster than Rust 🦀 ?

3 Likes
1 Comments
waynerad@diasp.org
Wayne Radinsky

"Hero C Compiler is a C compiler that allows you to compile your C codebase (with limitations) to SPIR-V for the Vulkan graphics API. This means you can share struct's, enum's and functions between your CPU & GPU code. HCC targets the future of GPU programming so is designed around features such as bindless resources and scalar alignment. This makes it easier to interop with the GPU and focus on writing shader code without writing your own shader build system."

I thought this was a pretty interesting idea: a C compiler specifically designed to share data between CPUs and GPUs. I wouldn't've thought the C compiler would be the place to address this, but maybe it is.

Vulkan is a cross-platform GPU API for video games designed to replace OpenGL, Direct3D (on Windows), and Metal (on Apple devices). It originated at Valve but has since been spun out into a separate organization, the Khronos Group. The SPIR-V mentioned is part of the Vulcan API and pertains specifically to shaders.

Hero C Compiler

#solidstatelife #computerscience #programminglanguages #gpus #vulkan

hcc/README.md at main · heroseh/hcc

C Compiler to SPIR-V. Contribute to heroseh/hcc development by creating an account on GitHub.

2 Likes
1 Shares
waynerad@diasp.org
Wayne Radinsky

C-rusted is a new system for applying the safety features of Rust to the venerable C language. The developers are following in the footsteps of TypeScript. They say:

"C-rusted is a pragmatic and cost effective solution to up the game of C programming to unprecedented integrity guarantees without giving up anything that the C ecosystem offers today. That is, keep using C, exactly as before, using the same compilers and the same tools, the same personnel... but incrementally adding to the program the information required to demonstrate correctness, using a system of annotations that is not based on mathematical logic and can be taught to programmers in a week of training."

"Only when the addition of annotations shows the presence of a problem will a code modification be required in order to fix the latent bug that is now visible: in all other cases, the code behavior will remain exactly the same. This technique is not new: it is called gradual typing, and consists in the addition of information that does not alter the behavior of the code, yet it is instrumental in the verification of its correctness. Gradual typing has been applied with spectacular success in the past: Typescript has been created 10 years ago, and in the last 6 years its diffusion in the community of JavaScript developers has increased from 21% to 69%. And it will continue to increase: simply put, there is no reason to write more code in the significantly less secure and verifiable JavaScript language."

They celebrate the greatness of C, citing such things as:C compilers exist for almost any processor, C compiled code is very efficient and without hidden costs, C is defined by an ISO standard, C, possibly with extensions, allows easy access to hardware, C has a long history of usage, including in critical systems, and C is widely supported by all sorts of tools. The cite disadvantages, such as he fact that C code can efficiently be compiled to machine code for almost any architecture is due to the fact that, whenever this is possible and convenient, high level constructs are mapped directly to a few machine instructions, but given that instructions sets differ from one architecture to the other, this is why the behavior of C programs is not fully defined, and that is a problem. And of course, memory references in C are raw pointers that bring with themselves no information about the associated memory block or its intended use and there are no run-time checks made to ensure the safety of pointer arithmetic, memory accesses, and memory deallocation, leading to all the problems we are familiar with: dereferencing null and invalid pointers, dangling pointers (pointers to deallocated memory), misaligned pointers, use of uninitialized memory, memory leaks, double-freeing memory, buffer overruns, and so on.

Since those of you who are familiar with Rust know its claim to fame is the borrow-checking system to ensure memory integrity, I'm going to jump right to the description of how C-rusted handles memory:

"C-rusted distinguishes between different kind of handles:"

"Owner handles: An owner handle referring to a resource has a special association with it. In a safe C-rusted program, every resource subject to explicit disposal (as opposed to implicit disposal, as in the case of stack variables going out of scope), must be associated to one (and only one) owner handle. Through the program evolution, the owner handle for a resource might change, due to a mechanism called ownership move, but at any given time said resource will have exactly one owner. The association between the current owner and the owned resource only ends when a designated function is called to dispose of the resource. Note that an owner handle is a kind of exclusive handle."

"Exclusive handles: An exclusive handle referring to a resource also has a special association with it: while the resource cannot be disposed via an exclusive non-owner handle (only an owner handle allows that), the exclusive handle allows modification of the resource. As a consequence of this fact, no more than one usable exclusive handle may exist at any given time: moreover, the existence of an usable exclusive handle is incompatible with the existence of any other usable handle."

"Shared handles: A shared handle referring to a resource can be used to access a resource without modifying it. As read-only access via multiple handles is well defined, there may exist several shared handles to a single resource. However, during the existence of a shared handle, no exclusive handle to the same resource can be used."

C-rusted in a Nutshell

#solidstatelife #computerscience #programminglanguages #rust

3 Likes
7 Comments
2 Shares
waynerad@diasp.org
Wayne Radinsky

"The world's first programming language based on classical Chinese is only about a month old, and volunteers have already written dozens of programs with it, such as one based on an ancient Chinese fortune-telling algorithm."

The core of the language "includes a renderer that can display a program in a manner that resembles pages from ancient Chinese texts."

I lucked out that the language used for programming languages is my native language, English.

"Currently wenyan-lang contributors are working on transpilers for Python, Ruby, JavaScript, C++, and Java, libraries for graphics and the graphical user interface (GUI)" and "Lingdong Huang is currently working on an introductory guide to programming in wenyan-lang that is itself written in classical Chinese."

World's First Classical Chinese Programming Language

#solidstatelife #computerscience #programminglanguages #chinese

World's First Classical Chinese Programming Language

Programs written in the language include one for fortune-telling from the I Ching

10 Likes
17 Comments
3 Shares
waynerad@diasp.org
Wayne Radinsky

What makes a programming language "sticky"? What determines what languages grow and what languages die? According to Chris Hay, it's got nothing to do with how good the language is as a language. He says it depends on 3 things: 1) Raison d'être -- the original reason the language was created, 2) platform, 3) ecosystem.

Warning: Opinions.

"If we take a look at some of the other languages that are not on the list but will appear in some of the other stuff, things like Go which is created by the folks at Google, back in 2007, very similar reasons to Rust. A couple of different paradigms but very similar reasons. They hated C++, they wanted a simpler language, they wanted something that could deal with concurrency, and Go came off the back of that." -- No no no, Go and Rust were not created for similar reasons, not at all.

I actually like that this guy raises the subject of what he calls the "raison d'être". I've alluded to this before: one of my main theories of technology these days is that technologies never forget the reason they were originally invented, no matter how they are bent and twisted afterwards into doing something different. This is a lesson I've learned from PHP and Go and reflecting deeply on why they are the way they are and what they are and are not good for. I've had to use PHP at work for years, introduced Go on some small projects years ago, and only recently got authorization to use Go in the main project, which is otherwise a PHP monolith. The thing about PHP is that, you would think, since it was born as a language for making websites and has been continuously improved ever since, that it would be the best language for making websites... but it isn't. And it turns out to understand why, you have to discard the phrase "making websites" because it is too vague, and instead replace it with "web development" vs "web templating". It turns out PHP was born to do web templating. Go was born to do web development. And the more fundamental point I'm making here is that, when examining a technology's "raison d'être", you have to care about the details -- you have to care about the subtleties. You can't just do as this guy does in the video and read a sentence or two from the original founder(s) and call it a day. That's how you end up saying things like "Go was created for very similar reasons to Rust", which is just flat out wrong.

This is the point where I started banging out a long rant about PHP and Go and in the interest of saving time, I decided to just scratch that and jump straight to the conclusion: PHP was invented for web templating while Go was invented for web development, where we define the distinction as follows: Web development means writing the code for the actual logic of an application -- what data it stores and retrieves and by whom and who is able to access it, what data is moved across the network to and fro other parts of the internet, and what computations are done -- while web templating means the visual appearance of a web application, the "outer skin" -- the choice of fonts, the colors, the spacing and layout, the use of icons, etc. PHP remains to this day the best web templating language in existence and a ton of web templates, if they're not in straight HTML, are in PHP. But you are in for trouble if you try to go beyond templating to implementing the complete logic of your application. (By the way, if you go to the PHP website, it will tell you PHP is a "recursive" acronym (an acronym that contains itself) that stands for "PHP: Hypertext Preprocessor" -- but PHP originally stood for "Personal Home Page" -- much more indicative of its original purpose.)

Go, on the other hand, is the best language in existence for making any program that sits out on a server out on a network somewhere and answers requests from the network, whether they come from an end user, with say a browser or mobile phone, or another computer, such as through an API call. Go was invented to do precisely that (by Google which does a lot of that sort of thing) and this can't be said of any other language that is used to program servers. Java was invented for interactive TV systems, JavaScript was invented so people could add simple scripts to web forms with the Netscape browser, Python was invented to be a shell scripting language that's a "real" language, Ruby was invented to combine object-oriented concepts with Lisp-like functional concepts, and so on.

It might be worth expanding slightly on that list. Most companies using PHP switched to Java after their PHP codebases became unmanageable, most famously Facebook. Java's "write once run anywhere" philosophy was conceived because it was conceived as a language to run on TV set top boxes made by lots of different manufacturers, and given that, it's current use as a language for Android phones, also made by lots of different manufacturers, isn't too far from its original raison d'être -- better than programming servers. JavaScript was put in as a language for web forms, but fortuitously the guy who came up with it based in on Scheme (modified to use curly braces like Java because "Java" was all the rage at the time), which made it a sufficiently powerful language that real, large applications could be built with it. I think the only reason it's ended up on the server is because "front end" programmers who were doing everything in JavaScript on browsers (because they had to) wanted to use the same language on servers to keep their lives simple (even though nobody should ever use JavaScript on servers). Ruby wasn't conceived as a web language at all and only took off with Rails, the web framework (and as noted in the video, has declined as the functionality of Rails has been replicated in all other languages). Python was conceived as a way of writing shell scripts with a "real" programming language, and it's current use as a "glue" language for "gluing together" functionality provided by massive C++ packages like PyTorch is maybe not too dissimilar to the basic idea of a shell scripting language, which is to glue together Unix commands with simple logic.

Anyway, this brings me to Rust. Rust was born at Mozilla by a developer working on the web browser itself who was frustrated by the difficulty of writing C++ code without bugs -- especially the kind of horrid memory-management bugs that are especially hard to track down. I'm going to skip going into detail of the technical features of the language that address this, like I am for all the languages to try to keep this short, but suffice to say Rust has a unique memory-management system that addresses "lifetime management" issues (memory isn't leaked because the programmer forgot to free it, or freed twice, etc) and "concurrency" issues (race conditions, etc), in such a way as to not sacrifice performance compared with C++ (the language the browser was written in) and have deterministic real-time performance -- unlike a garbage-collected language like Go -- in Go's use case the garbage collector is ok because Go programs sit on a server somewhere out on a network and answer requests from the network, and that usually involves allocating some memory to process some data and generate a reply, which all gets freed up when the request is done.

I know I sound like I'm picking on the guy in the video but I've learned these subtitles really matter. He thinks Rust and Go were created for similar reasons, and maybe that's true in some superficial way, but when you look at the details, you realize the reasons for their invention are completely different and you shouldn't use Rust to make a web application that runs on a server and you shouldn't use Go to write a web browser from scratch. (Or a video game engine or anything else that requires high-performance, multithreading, and real-time constraints.) Technologies remember what they were born to do forever.

Maybe his latter two points -- platform and community -- hold greater merit. I don't have much to say about them so I guess I'll just let you watch the video and let his comments on those matters stand.

One of the things he mentions is Python in data science and it's really true, Python really dominates that space. Most of the work is done in Jupyter Notebooks, which are excellent for interacting with data and writing and playing with code to interactively explore data. But this concept was actually pioneered by Mathematica and the Wolfram language. And since this is the Wolfram language's "raison d'être" right from its inception way back in the 80s, you would expect the Wolfram language to dominate this space, but the company charges a lot of money for Mathematica, and kept the Wolfram language proprietary. I haven't used it so I can't say if there's some subtlety that would have kept the Wolfram language from taking over the world of data science had it been open source. Assuming there wasn't any, then Wolfram left the door open for Python to come in a take over.

is Rust and Go the new Ruby and PHP? what makes programming languages sticky and why they die - Chris Hay

#computerscience #programminglanguages

4 Likes
35 Comments
1 Shares
waynerad@pluspora.com
Wayne Radinsky

aussie++ is a programming language based on Aussie slang. Programs must start with "G'DAY MATE!". To assign variables you say "I RECKON", "YEAH" and "NAH" are used for boolean variables, nil pointers are "BUGGER ALL", to increment a variable you say "GOOD ON YA" and to decrement you say "PULL YA HEAD IN", to print to the console you say "GIMME", to do conditionals (if statements) you say "YA RECKON", to do loops you say "WALKABOUT", you can open block comments with "OI MATE!" and close with "GOT IT?", and boomerangs (< >) are used instead of curly braces ({ }).

Hilarious. Python better watch out?

zackradisic / aussieplusplus / DOCS.md

#solidstatelife #programminglanguages

waynerad@diasp.org
Wayne Radinsky

aussie++ is a programming language based on Aussie slang. Programs must start with "G'DAY MATE!". To assign variables you say "I RECKON", "YEAH" and "NAH" are used for boolean variables, nil pointers are "BUGGER ALL", to increment a variable you say "GOOD ON YA" and to decrement you say "PULL YA HEAD IN", to print to the console you say "GIMME", to do conditionals (if statements) you say "YA RECKON", to do loops you say "WALKABOUT", you can open block comments with "OI MATE!" and close with "GOT IT?", and boomerangs (< >) are used instead of curly braces ({ }).

Hilarious. Python better watch out?

zackradisic / aussieplusplus / DOCS.md

#solidstatelife #programminglanguages

8 Likes
2 Shares
19 Likes
11 Comments
ydennek@pluspora.com
Kyle Kennedy

This should be more widely known.

Rockstar

Rockstar is a dynamically typed Turing-complete programming language.

Rockstar is designed for creating computer programs that are also song lyrics, and is heavily influenced by the lyrical conventions of 1980s hard rock and power ballads.

But why?

Mainly because if we make Rockstar a real (and completely pointless) programming language, then recruiters and hiring managers won't be able to talk about 'rockstar developers' any more.

Also 'cos it's kinda fun and any language based on the idea of compiling Meatloaf lyrics has to be worth a look, right?

Also we can make stickers. Who doesn't want a sticker on their laptop saying 'CERTIFIED ROCKSTAR DEVELOPER'?

Sample code:
Tommy was a dancer
While Tommy ain't nothing
Shout it
Knock it down

Equivalent pseudo code:
var Tommy := 16;
while Tommy > 0
{
print (Tommy, stdout);
Tommy := Tommy - 1;
}

#programminglanguages #programming

GitHub - dylanbeattie/rockstar: The Rockstar programming language specification

The Rockstar programming language specification. Contribute to dylanbeattie/rockstar development by creating an account on GitHub.