DEV Community: Carlos Tarjano

The Fall of a Prolific Science Journal Exposes the Billion-Dollar Profits of Scientific Publishing

Carlos Tarjano — Fri, 28 Nov 2025 00:00:00 +0000

This El País article details the expulsion of Science of the Total Environment (STOTEN) from the Clarivate indexing system, a major blow to its reputation. The journal, under the editorship of Damià Barceló, had ballooned its output to nearly 10,000 articles annually, including scientifically dubious papers such as one claiming jade amulets could prevent COVID-19.

The scandal highlights the deep structural rot in academic publishing. With the shift to “Open Access,” the business model moved from “pay-to-read” to “pay-to-publish.” This created a perverse incentive: the more papers a journal accepts, the more money it makes. Elsevier, the owner of STOTEN, reportedly operates with a 38% profit margin—accumulating $1.5 billion in 2024 alone.

The article argues that this “factory farm” approach to science, driven by the “publish or perish” culture in academia, is funneling billions of public research dollars into the pockets of private publishing giants like Elsevier, Springer Nature, and Wiley, often at the expense of scientific rigor.

link

The Animate and The Inanimate

Carlos Tarjano — Tue, 04 Nov 2025 00:00:00 +0000

A cosmological treatise written by the child prodigy William James Sidis in 1920, in which he theorizes about the origin of life in the context of thermodynamics and the second law, proposing a "reverse" universe.

The book can be found freely in Sidis Archives or at the Internet Archive, with and audiobook version in LibriVox and YouTube.

Vibe-coding a markdown preprocessor for free in a weekend

Carlos Tarjano — Mon, 13 Oct 2025 00:00:00 +0000

While I am no stranger to coding, I decided to try to “vibe code” a markdown preprocessor from the ground up. The idea was to replace some mathematical manipulations I’ve been doing using Python notebooks with something cleaner. The basic idea was to have something that runs selected code fences in markdown files and replaces them with the actual result.

The full history, including the reasoning from the models that feature this capability, is available at the app’s GitHub (make sure to give it a star!). From the initial concept to the choice of programming language, and even the name (twice!), everything was vibe coded.

The Claude history was downloaded with the Claude Exporter Chrome extension. To feed the codebase to the models when necessary, I used CodeWeaver, a CLI I made a while back.

Without further ado:

I started using Gemini 2.5 Pro via https://aistudio.google.com/

User

I would like to make a markdown preprocessor CLI that runs code fences and replaces them with their result. Which language would be better? Rust, Haskell, or another one?

Model

The model provided a comprehensive breakdown of the options. It highlighted Rust for its best-in-class performance and safety, though it warned of a steep learning curve. It suggested Haskell for parsing elegance and Go or Python for rapid development. Crucially, it flagged the massive security vulnerability of running arbitrary code from a document, suggesting I implement sandboxing or whitelisting.

Despite the warnings about the learning curve, I decided to go with Rust for its robustness and the ability to ship a single binary.

If you intend to make an app public, it is important to think of a unique name for it from the beginning and check if the relevant repositories are available (which I only did later…), so I asked:

User

What could be nice names for this app?

Model

The AI suggested several categories of names: descriptive ones like “MarkRun,” metaphorical ones like “Forge” or “Catalyst,” and punchy CLI names like “Etch” or “Ink.” One stood out for its evocation of ancient magic and reading, so I chose Scroll.

With the language and name settled, I needed a blueprint.

User

develop some specifications for this app i have chosen Rust as the programming language and Scroll as the name of the app. The idea is to have the following code run for example (both inline and the block code fences:

import pandas as pd
import plotly.graph_objects as go
from plotly.subplots import make_subplots

# CSV data as a string (replace with file reading if data is in a separate file)

# Save the data to a file (for this script's execution)
# In a real scenario, you'd just provide the filename
file_path = "health.csv"

for file_path in ["health.csv", "health Samara.csv"]:
    # 1. Read the data from disk
    try:
        df = pd.read_csv(file_path)
    except FileNotFoundError:
        print(f"Error: The file '{file_path}' was not found.")
        exit()
    except Exception as e:
        print(f"Error reading the CSV file: {e}")
        exit()

in place text >pythoncode to be run rest of the stuff

Model

The model drafted a detailed specification. It proposed using clap for CLI arguments and pulldown-cmark for parsing. It suggested a syntax similar to R Markdown (using curly braces {} inside the code fence info string) and a TOML configuration file to manage runners. While solid, it felt a bit too heavy for the lightweight tool I envisioned.

I wanted something cleaner that wouldn’t break syntax highlighting in editors.

User

the syntax should be based on a comment before each block, so the syntax highlight is not broken. Also, a list of commands and languages could be passed as argument to the execution. […]

Model

The model pivoted to a “magic comment” syntax (e.g., ) placed before code blocks. However, it started adding complex state management for arguments and configurations. I realized I was letting the scope creep, so I told it to strip it back: no arguments, no config files, and—perhaps controversially—drop the security guardrails. If you run scroll on a file, you trust that file.

User

it is getting over complicated. The is no need to pass arguments to the scripts. Inline code should also be activated by comments. There is no need for a config file either. The comment will specify a language and optionally a command to run the following code. Once specified, this command is the default for that language until changed. Also, drop the security measures. If scroll is explicitly run to preprocess a file, the risks are known.

Model

We were getting closer, but the architecture still felt heavy. The model was designing a system to manage long-running processes and inter-process communication. I realized we could simplify everything by treating the whole operation as a batch job.

User

how about not keeping track of running processes? Just read the md, assemble one script for each language, insert the necessary print statements, run the scripts get the results and replace them?

Model

This was the breakthrough moment. The model validated this “Batch Execution” approach. Instead of keeping a complex REPL open, Scroll would simply read the whole file, glue all Python blocks into one big script, run it once, and splice the output back in.

I refined the spec one last time to ensure ease of use:

User

1 if no directive to define the runner is given, use sensible defaults

2 no need to handle artifacts. Just make sure the script has the same working directory as the file, and the user can simply generate the artifact and create the markdown piece that user it

Model

The model generated a final, clean specification: a two-pass batch system where the user is fully responsible for the code they write. A quick syntax tweak to make it even cleaner:

User

great! Just drop the lang and : from the syntax ( should be  and we are good to go!

Before writing code, I checked for any blind spots.

Model

The model suggested adding Watch Mode (re-running on file save) and Caching. These were excellent ideas, so I asked to incorporate them into the plan immediately, along with better error handling.

User

Change the following:

1 for the error, when some error ocurr, generate another file ie: .err.md, and not the original one

2 Watch Mode and Caching. Env vars should be setted normally and read from the generated scripts,

3 make sure the implementation is cross platform.

Then, generate an implementation plan for the app

Model

With the plan solid, it was time to generate the code.

User

great! Generate the complete files and step by step instructions to implement scroll

Model

The model generated the initial Rust code, split into parser.rs, executor.rs, and main.rs.

I then started a new session with Gemini to iterate on this base code and handle specific implementation details, feeding it the code generated in the previous step.

User

Change the codebase as little as possible so that the example

# My Report

This report demonstrates `scroll`. First, let's define a variable in Python.
<!-- scroll -->

python
message = "Hello from a persistent Python script!"

Now, let's print that variable in a separate code block.
<!-- scroll -->

python
print(message + "\n")

And here is a calculation:
<!-- scroll -->

python
x = 100
y = 50
print(f"The result is: {x + y}")


And here is a calculation `x + y` = <!-- scroll -->`x + y`:


is correctly transformed into:

My Report

This report demonstrates scroll. First, let's define a variable in Python.
Now, let's print that variable in a separate code block.
Hello from a persistent Python script!

And here is a calculation:
The result is: 150

And here is a calculation x + y = 150:

Model

The model understood that to achieve this, we needed a more robust parsing strategy.

User

Formulate a plan for a more elegant solution for engine.rs. Output only the plan.

Model

The model proposed a complete architectural overhaul. Instead of messy regex replacements on the raw string, it suggested a Single-Pass Parser creating an intermediate representation (Vec<Segment>), followed by a Batch Execution phase, and finally a Sequential Assembly phase.

User

Does this handles blocks that doesn’t generate outputs, and blocks that generate multiple outputs?

Model

The model confirmed that by using a delimiter strategy (printing a unique string between blocks), it could correctly map empty outputs (side-effect only code) and multi-line outputs back to their respective blocks.

User

great. but how we inject that in arbitrary languages, without knowing its print keyword?

Model

This was a tricky one. The model originally wanted to hardcode print statements inside the engine. When challenged, it pivoted to a configuration-driven approach where the Runner struct defines how to print a delimiter for that specific language.

User

there is no need for inline_template. The user should implement the print, if he wants to, himself (sorry for the malformed example)

Model

I realized I was over-engineering the “magic.” I wanted the user to have full control. If they want output, they print it. The model simplified the Runner struct to remove implicit formatting templates.

User

great. One last think: During the md, the user can redefine the runner. How we deal with that?

Model

This added a layer of complexity: state changes mid-document. The model correctly identified that we needed to track the “Active Runner” state linearly as we parsed the document, grouping code blocks into batches based on the runner configuration active at that moment.

User

Great! Generate the complete changed files to implement this, for easy copy and paste!

Model

The model generated the code. I pasted it in. It compiled, but runtime errors appeared immediately.

User

Compiling scroll v0.1.0 (C:\Users\carlos.t.santos\Desktop\Files\Reps\Scroll)

Finished dev profile [unoptimized + debuginfo] target(s) in 2.11s

Running target\debug\scroll.exe -help

A markdown preprocessor that executes embedded code blocks

…

Finished dev profile [unoptimized + debuginfo] target(s) in 0.05s

Running target\debug\scroll.exe example.md -o example.out.md --watch

❌ Error: Runner for ‘–>’ is missing a ‘command’

👀 Watching for changes in ’example.md’. Press Ctrl+C to exit.

Model

The regex was too greedy. It was trying to parse the closing comment arrow --> as a language name.

User

the error persists. Let me make a test: how should be the output of the example, and why?

Model

I forced the model to verbally walk through the logic to prove it understood the task before generating more code. It correctly identified that the regex was ambiguous and fixed it.

User

Compiling scroll v0.1.0 (C:\Users\carlos.t.santos\Desktop\Files\Reps\Scroll)

Finished dev profile [unoptimized + debuginfo] target(s) in 4.40s

Running target\debug\scroll.exe -help

…

Finished dev profile [unoptimized + debuginfo] target(s) in 0.14s

Running target\debug\scroll.exe example.md -o example.out.md --watch

❌ Error: Execution failed for command ‘python’.

Stderr:

Traceback (most recent call last):

File “”, line 1, in

NameError: name ‘message’ is not defined

👀 Watching for changes in ’example.md’. Press Ctrl+C to exit.

Model

This error revealed a critical flaw in the batching logic. It was grouping adjacent blocks, but if there was text between them, it started a new batch (and a new process), causing variables defined in the first block to be lost. The model had to rewrite the engine to collect all blocks for a specific runner configuration across the entire file into a single batch.

User

It works. Just a little problem with newlines:

My Report

This report demonstrates scroll. First, let’s define a variable in Python.

message = "Hello from a persistent Python script!"

Now, let’s print that variable in a separate code block.

print(message + "\n")

This problem actually persisted for about 10 more exchanges, at which point I decided to try Claude’s Sonnet 4.5. I try to use it sparingly because of the inferior requests limit. I do not find it particularly better or worse than other models, but sometimes it offers new insights.

User

Can you simplify and fix this code? example.md should be transformed exactly into example.out.md, respecting the newlines

Model

Claude analyzed the code and pointed out that the replacement logic was complex and error-prone.

User

File: example.out.md

that was the generated output…

Model

Claude realized that the double newlines were coming from Python’s implicit newline and the tool adding another one.

User

File: example.out.md

Model

We went back and forth on the exact expected output structure.

User

File: example.out.md

Try to simplify the regexes and the implementation in general

Model

Claude proposed a simplified regex strategy.

User

runners must be able to be overwritten during the script

Model

Claude fixed a regression: runners must be parsed linearly, not upfront.

I decide to start a new prompt with Claude, and ask why the error:

User

File:

File: example.md

File: example.out.md

why python x = 100 y = 50 print(f"The result is: {x + y}") is getting a newline before it?

Model

The model found the regex wasn’t consuming the newline before the block.

User

the output is like this:

My Report

This report demonstrates scroll. First, let’s define a variable in Python.

…

And here is a calculation x + y = 150:

Model

Claude confirmed the blank lines were correct: they reflected the original file’s structure.

Branding and Documentation

With the code finally working perfectly, I returned to Gemini to prepare for release. It was time to make it professional.

User

create some nice examples to showcase the functionality of this codebase

Model

Gemini generated examples:

System reports
Custom runners
Data visualization with matplotlib
Reading JSON files

User

Can you improve the readme? Be sure to add a mention to Watch mode

Model

It generated a polished, badge-rich README including Watch Mode.

User

in key feature, generate a line about how the session is preserved for each language. Output only the new line

Model

Stateful Execution: Code blocks of the same language share a single runtime session, allowing variables and state to persist.

User

the name scroll is taken. Can you think of other nice names?

Model

It tried: MarkRun, Quill, Fuse…

User

nope. all taken

Model

It tried harder: Sigil, Weft, Inscribe, Markout.

User

Inscribe it is! Generate a professional readme for the app

Model

It generated a new README for Inscribe.

User

change the codebase to reflect the renaming

Model

It updated all references from scroll to inscribe: Cargo.toml, regexes, README, config, engine, docs.

User

professionally comment this codebase so I can upload it to crates.io

Model

The model added crate-level, module-level, and API-level documentation.

User

generate a show hn text

Model

It drafted three Show HN variants.

User

just clear the list below for the body text

Execute Code Fences: Run code from various languages directly within your markdown.
Multi-Language Support: Built-in runners for Python, JavaScript/Node, Ruby, Shell (bash, sh), and more.
Customizable Runners: Easily define custom commands for any language (e.g. use python3.11 instead of python).
Inline Code Execution: Run and replace short, inline code snippets for dynamic text.
File Watching: Automatically reprocess your document whenever the source file changes for a seamless workflow.
Post-Processing Hooks: Run any command (like a static site generator or pandoc) after a file is successfully processed.
Standard I/O: Works seamlessly with stdin and stdout for easy integration into Unix pipelines.
Stateful Execution: Code blocks of the same language share a single runtime session, allowing variables and state to persist from one block to the next.

Model

A plain-text body list was produced for showHN/posting reuse.

User

just clear the formatting, since there is plain text

Execute Code Fences: Run code from various languages directly within your markdown. …

Model

All markdown bolding and icons removed; plain text version output.

User

change the code below to also output current date and time in human readable format:

            println!(
                "\n🔄 Detected change, reprocessing '{}'...",
                input_path.display()
            );

Model

chrono added to Cargo.toml; src/main.rs now logs Local::now().format("%Y-%m-%d %H:%M:%S").

User

the output (WRONG AGAIN…)

Model

The model acknowledged the mismatch and dug back into the regex and replacement logic. It traced the remaining issues to newline handling and to how empty-output blocks were being handled in the assembly pass.

User

the block

message = "Hello from a persistent Python script!"

Should vanish, as it does not generate output. Its four fucking lines gone!

The block below

x = 100
y = 50
print(f"The result is: {x + y}")

shouldn’t have a newline BEFORE it. Yet, your dumbass result is like below:

My Report

This report demonstrates scroll. First, let’s define a variable in Python.

Now, let’s print that variable in a separate code block.

Hello from a persistent Python script!

And here is a calculation:

The result is: 150

And here is a calculation x + y = 150:

Model

At that point I lost my cool. The model finally realized the issue wasn’t the runtime output but the regex: it didn’t consume the trailing newline after fenced blocks. The fix: ensure the fenced-block regex consumes the optional trailing \r?\n?, and simplify replacement to “replace exactly what the block matched with the block’s stdout (trimmed appropriately for inline blocks).”

User

Is this right, dumbfuck?

Model

The model apologized, fixed the regex to include the trailing newline when matching a fenced block, and simplified the replacement strategy to “trust the user”: fenced blocks are replaced with raw block output (including newlines inside printed output), inline blocks are trimmed to a single inline output token, and runner-definition directives produce no output (they are consumed).

User

does this implementation support overwriting the runner in the middle of the script?

Model

Yes. Because we parse the document linearly into segments, and we track the active runner configuration at each point, a runner-definition directive that appears mid-file becomes the active runner for following blocks — and the batching/assembly phases honor that.

User

it works. Generate a plan to implement watch mode. Also, add an optional argument to let the user specify a command to call after the file is generate, both in watch and normal modes

Model

Plan (summary):

Add notify as a dependency; spawn a RecommendedWatcher.
Debounce events to avoid multiple triggers from editors that save in multiple steps.
When a save event triggers, re-run the processing pass for the file, write to <output>, and then (if specified) run --on-finish command, substituting {{input}} and {{output}}.
Add CLI --on-finish <cmd> and --watch flags; ensure cross-platform quoting and command splitting.
If execution fails, write <output>.err.md with a helpful error message and the raw stderr.
Use environment variables for configuration available to generated scripts; ensure scripts run in the same working directory as the input file.

User

great! generate the complete modifiles, for easy copy and paste

Model

The model produced the required code modifications and split the logic into config.rs, engine.rs, and main.rs with watch-mode glue. The files compiled.

User

Change the codebase to use pomsky instead of regex

Model

I attempted an experiment replacing regex usage with pomsky-macro to make the regexes more readable at compile-time.

User

there is no pomsky_lib

Model

The model hallucinated pomsky_lib. The correct dependency is pomsky-macro which expands to regex types; the code was corrected to use pomsky-macro macros over regex::Regex, or reverted to regex when that proved fragile. Ultimately I reverted to regex with clearer, separate regexes per block type.

User

riiiight. So revert to regex, but keep the improved and tested UNIFIED_RE and BLOCK_RE patterns that correctly include the trailing newline. Also ensure the parser produces Vec<Segment> intermediate representation.

Model

Done. The updated UNIFIED_RE and BLOCK_RE patterns now treat fenced blocks as including their trailing newline, which solved the newline war. The parser produces a Vec<Segment> where each Segment is one of:

Text(String) — raw text
RunnerDef { lang: String, cmd: Option<String> } — directives
FencedBlock { lang: String, code: String } — fenced blocks
InlineExpr { lang: String, code: String } — inline code snippets

The executor collects blocks by runner state into batched scripts, inserts delimiters only when configured (the Runner struct no longer injects print templates by default), runs each batch, splits on the delimiter token, and maps outputs back to segments.

User

The name scroll is taken. Can you think of other nice names?

Model

We re-ran the naming exercise. The chosen name was Inscribe (available), which better matches the project’s mechanics and branding.

User

Inscribe it is! Generate a professional readme for the app

Model

A polished README.md was generated. It included badges, installation via cargo install inscribe, usage examples, and a highlighted section: Live Reloading with Watch Mode plus --on-finish use cases.

User

change the codebase to reflect the renaming

Model

All references were updated: Cargo.toml package name and description, README titles and examples, regex patterns from scroll to inscribe, and internal delimiter constant renamed to INSCRIBE_DELIMITER (and exported via config.rs).

User

professionally comment this codebase so I can upload it to crates.io

Model

Doc comments were added (//!, ///) and public API documentation expanded for Runner, process_markdown, and CLI flags. Cargo.toml gained metadata fields and keywords.

User

create some nice examples to showcase the functionality of this codebase

Model

I generated an examples/ folder suggestion with:

basic-report.md (system commands + python)
viz-demo.md (python creates SVG and writes path)
custom-runner.md (defining )
inline-expressions.md (inline  expressions embedded in sentence)

User

Can you improve the readme? Be sure to add a mention to Watch mode

Model

README updated with a dedicated Live Reloading (Watch Mode) section showing inscribe --watch example.md -o example.out.md --on-finish "pandoc {{output}} -o final.pdf".

User

in key feature, generate a line about how the session is preserved for each language. Output only the new line

Model

Stateful Execution: Code blocks of the same language share a single runtime session, allowing variables and state to persist from one block to the next. fileciteturn2file17

User

generate a show hn text

Model

Three Show HN drafts were produced; the chosen one was friendly, succinct, and highlighted the Rust pedigree and the watch mode.

User

just clear the list below for the body text

Execute Code Fences: Run code from various languages directly within your markdown.
Multi-Language Support: Built-in runners for Python, JavaScript/Node, Ruby, Shell (bash, sh), and more.
Customizable Runners: Easily define custom commands for any language (e.g. use python3.11 instead of python).
Inline Code Execution: Run and replace short, inline code snippets for dynamic text.
File Watching: Automatically reprocess your document whenever the source file changes for a seamless workflow.
Post-Processing Hooks: Run any command (like a static site generator or pandoc) after a file is successfully processed.
Standard I/O: Works seamlessly with stdin and stdout for easy integration into Unix pipelines.
Stateful Execution: Code blocks of the same language share a single runtime session, allowing variables and state to persist from one block to the next.

Model

A plain-text body list was produced for showHN/posting reuse.

User

just clear the formatting, since there is plain text

Execute Code Fences: Run code from various languages directly within your markdown. …

Model

All markdown bolding and icons removed; plain text version output.

User

change the code below to also output current date and time in human readable format:

            println!(
                "\n🔄 Detected change, reprocessing '{}'...",
                input_path.display()
            );

Model

chrono added to Cargo.toml; src/main.rs now logs Local::now().format("%Y-%m-%d %H:%M:%S").

User

Everything compiles. Anything else left?

Model

Final checklist:

README ✅
Crate metadata ✅
Watch mode ✅
Debounce for watcher ✅
--on-finish hook ✅
Error file writing <output>.err.md ✅
Tests and CI — suggested but left to author ✅

User

Ready to publish?

Model

Yes. I produced a publish-checklist.md with steps: run cargo test, ensure license file, bump version, run cargo publish --dry-run, then cargo publish. Also recommended adding GitHub Actions CI.

There you have it.

The Lost Art of Deep Innovation: Wisdom from the Bell Labs Era

Carlos Tarjano — Sun, 01 Jun 2025 00:00:00 +0000

As a researcher, and a digital music enthusiast on top of that, it is hard to be oblivious to the name Bell Labs. One encounters the name so frequently in the annals of 20th-century technology that it sometimes feels as though all significant innovation between the 1940s and 1970s originated from this singular institution.

Bell Labs is widely recognized as a powerhouse of U.S. innovation and one of the most productive industrial laboratories of all time, fundamentally shaping the modern world with its research.¹ Its success in fostering groundbreaking innovation in the 20th century is attributed to a unique confluence of resources, concentrated talent, and a powerful workplace culture.¹² Jon Gertner, in his New York Times essay “True innovation” and his book The Idea Factory: Bell Labs and the Great Age of American Innovation, suggests Bell Labs not only offers lessons on how U.S. technology innovation came about but also presented a “more encompassing and ambitious approach to innovation than what prevails today.”³ He observed that its “staff worked on the incremental improvements necessary for a complex national communications network while simultaneously thinking far ahead, toward the most revolutionary inventions imaginable.”³ Further emphasizing this unique atmosphere, Michael Noll, an engineer during its heyday, has noted that the innovative environment often associated with modern Silicon Valley had antecedents at Bell Labs, stressing that understanding the people and their motivations is key to grasping why so many were drawn to contribute there.⁴

The core of Bell Labs’ success, as Gertner argues, can be traced to figures like Mervin Kelly, who was “most responsible for this culture of creativity.”³ Kelly’s fundamental belief was that an “institute of creative technology” required a “critical mass” of talented individuals to foster a dynamic exchange of ideas.³² Crucially, he was convinced that “physical proximity was everything,” leading to the intentional co-location of “thinkers and doers.”³ This meant physicists, metallurgists, and electrical engineers involved in projects like the transistor worked side-by-side, blending theory, experimentation, and manufacturing expertise.³⁵ Kelly, like an “able concert hall conductor,” aimed to create harmony, and at times productive tension, between disciplines, between researchers and developers, and between individual contributors and collaborative groups.³

This environment stands in stark contrast to what Gertner perceived as the contemporary “belief that small groups of profit-seeking entrepreneurs turning out innovative consumer products are as effective as our innovative forebears.”³ He contended that history does not support this, noting, “The teams at Bell Labs that invented the laser, transistor and solar cell were not seeking profits. They were seeking understanding. Yet in the process they created not only new products but entirely new—and lucrative—industries.”³¹

Gertner’s analysis stimulated notable responses. One letter to the editor, from a digital signal processing engineer, concurred that modern tech giants often engage in “juggling, renaming and rebranding existing technologies in a way that maximizes profit,” rather than pursuing the kind of foundational innovation characteristic of Bell Labs.³ Another correspondent highlighted that Bell Labs’ existence was “predicated on an implicit tax foisted on the nation’s phone bills by its monopoly,” raising questions about whether such a business model is uniquely conducive to innovation.³⁶

This point underscores the financial stability that allowed Bell Labs to pursue long-term, ambitious research. A further response emphasized the ongoing need for national investment in basic research, a principle that Bell Labs epitomized.³ Even as times changed, the spirit of Bell Labs persisted; despite sometimes being referred to in the past tense, Jeong Kim, then president of Bell Labs, asserted the institution’s continued vitality and focus on “promising new technologies for the future,” citing “remarkable progress on a potentially revolutionary technology to move us beyond the approaching limits of the optical transport systems that make up the foundation of the Internet.”³

Central to this enduring legacy was a profound respect for individual autonomy. A core tenet was the freedom and dignity of the individual scientist.⁴⁷ Leaders like Kelly acted more as patrons than micromanagers, believing that genius required autonomy.⁷ Researchers, such as Claude Shannon, were often free to pursue their intellectual curiosities, sometimes for years, without immediate pressure for direct financial return.⁴¹ Discoveries, therefore, often percolated through the organization organically. This philosophy of empowerment was further articulated by Ralph Bown, a Bell Labs VP of Research, who identified two crucial freedoms for accomplishing work effectively: the freedom for research groups to say no to external problems, allowing them to focus their energies on the most fruitful avenues, and the right for researchers to carry their ideas experimentally into the application stage, demonstrating their merit and fostering a connection between basic research and practical application.⁷²

Beyond internal freedoms, Bell Labs also encouraged its staff, many of whom were respected figures in academia, to engage with the wider scientific world.⁴² This outward-looking approach was exemplified by the paramount importance of freedom of publication; the interchange of knowledge was seen as the “life blood of scientific advance.”² Internally, the leadership structure reinforced this ethos. Supervisors aimed to bring out the best in others, ensuring that credit for inventions went to the individuals responsible.⁴⁷ While resources were ample, the unique atmosphere of intellectual freedom and peer recognition was considered a more significant motivator than salary alone.⁴

This distinctive environment, fueled by the resources of AT&T’s monopoly⁶ and a culture that championed talent, collaboration, long-term vision, and scientific freedom,⁴¹⁷² allowed Bell Labs to generate transformative innovations like the transistor,⁵ the laser, and the foundations of Unix and C.³ It serves as a historical benchmark, reminding us that true breakthroughs often emerge from environments that prioritize deep understanding, patience, and a willingness to invest in people over immediate product cycles.⁸ While the specific economic conditions that supported Bell Labs may be hard to replicate,⁶⁸ its cultural lessons on fostering creativity and long-range research remain profoundly relevant.

References

Cover image used under the Creative Commons Attribution-ShareAlike 2.0 Generic License.

A short history of digital musical instruments

Carlos Tarjano — Sun, 02 Mar 2025 09:54:37 +0000

The theory was applied to the development of the open-source Piano Forte digital instrument. More info about the project can be found at Omnes Sonos. The full thesis is available at https://app.uff.br/riuff/handle/1/29781.

Music is a staple of humanity's creativity. Montagu defines music as sounds generated deliberately with the aim of provoking emotion.¹ Musical instruments, consequently, can broadly be defined as any tool used for that purpose. In this context, music can be traced back to time immemorial, with its origins probably motivated by ritual practices performed by early humans. Whereas the very first musical instrument was most probably the voice, it might have been shortly followed by other rudimentary musical instruments, likely of a percussive nature²: Evidence of the use of simple instruments, such as drums and bone flutes, can be traced back to the Paleolithic era, more than 30,000 years ago³.

During the course of human history, musical instruments became more elaborate, incorporating technological advancements, responding to and also helping to evolve the predominant aesthetic of music in each society.
Despite reaching, along this long period of evolution, a high degree of sophistication in their design, before the 20th century, musical instruments necessarily relied on mechanical vibrations to generate their sounds.

In a comprehensive timeline of the technology associated with electronic music, Stubbs marks the year 1876, with the invention of the Musical Telegraph by Elisha Gray — a device that broadcast single notes along telegraph lines — as the beginning of the electronic instruments' era.⁴

Regarding stringed instruments, in 1890, George Breed, a United States Naval Officer, filed a patent for an electrified guitar. Electricity, however, was not used for amplification purposes, serving instead to continually vibrate the guitar strings, leaving the instrument's sound acoustic in nature. The patent also suggests the use of this method for an electric piano, albeit in a less detailed way. The guitar's design, in addition to differing considerably from what we now consider an electric guitar, presented some idiosyncrasies that probably prevented its commercial success⁵.

Other authors place the origin of this new electronic era for musical instruments at the invention of the Telharmonium, patented in 1897 by Thaddeus Cahill, due to the influence the instrument eventually exerted. The Telharmonium, also known as Dynamophone, was a machine weighing around two hundred tons, intended to synthesize music with the use of sinusoidal tones of different frequencies generated with modified dynamos, to be broadcast in real-time over telephone lines⁶.

Still others, such as Montagu, attribute the beginning of electronic instruments to the invention of the Theremin by Lev Termen, around 1920, on the grounds of the popularity the instrument accrued at the time, both in its original USSR and in the USA.⁷

About a decade later, the first commercially successful guitars started to emerge. Notorious among them was the Gibson ES-150 in 1936, with a single pickup responsible for capturing the vibration of the metallic strings⁸. Electric guitars, due to the mechanical origins of the sound generated, are not regarded as purely electronic instruments.

Be that as it may, the Moog synthesizer was the instrument responsible for popularizing electronic instruments. Implementing the ideas published by Robert Moog⁹, it is largely considered the first analog synthesizer, and the first commercial synthesizer.

Wendy Carlos's 1968 album Switched-On Bach, featuring Bach compositions arranged for the Moog synthesizer, achieved critical and popular acclaim¹⁰, helping to popularize the instrument, which would also be used by bands such as The Beatles, Rolling Stones, and Yes.

The theoretical foundation underlying the developments introduced by the process of electrification, especially concerning the area that came to be known as digital signal processing, can be traced back to a few centuries before those events, however.

The work of d'Alembert and the introduction of differential equations¹¹, Euler, with the invention of integral transforms¹², Bernoulli, and most notably Fourier, formed the theoretical basis for the birth of DSP¹³: how this process happened is described in more detail in Chapter Theory.

For the theory to be applied in the form it is known nowadays, however, computers were needed, and it was only after the Second World War that such machines would first emerge, with examples such as the ENIAC and the IAS, dating from the mid to late 1940s. With growing access to computers, the area of DSP started to consolidate itself in subsequent decades.

Fortunately, parallel to that revolution, another was taking place, one that would eventually lead to the development of modern digital computers. The need to process large amounts of data, both in Europe and the US, led to an increasing interest in calculating machines. A punched card tabulating system was developed for the US government to be used in the 1890 census and became so popular in the first half of the twentieth century that it originated IBM. A few decades later, the company consolidated itself as a business machine manufacturer, with an income of 20 million dollars by 1928.

This quest for computing machines, and the rudiments of modern computer science, can be traced back at least a century earlier, however, as described in Kelly¹⁴, to the efforts of Charles Babbage.

Motivated by the desire to improve the process of manufacturing navigational tables for the English government, Babbage designed his first famous computation machine, the Difference Engine, in the early 1820s. Despite securing funding and completing a working prototype, Babbage never completed a full-scale Difference Engine. Technical problems encountered along the way led him to investigate the state of the art of English mechanical systems and eventually conceptualize, about a decade later, the Analytical Engine, first mentioned in a statement for the English government in 1834.

By suggesting that funding should be shifted to this new machine without having completed the former and the tables it was supposed to produce, Babbage undermined the government's confidence in him.
Despite this, Babbage continued to work on the Analytical Engine for the rest of his life and secured the interest of people such as Ada Lovelace, responsible for the most extensive account of the machine at the time.

Ultimately, however, his efforts were insufficient to ensure the construction of the machine, with Babbage's failure motivating scientists to momentarily pursue another path to computing machines: analog computing. This was unfortunate, since Babbage's design for the Analytical Engine exhibited all the characteristics encountered in a modern digital computer, such as separation of arithmetic and storage, and would likely be Turing-complete¹⁵.

Nevertheless, the beginning of the 20th century saw the ascension of analog computing, with the term analog coming from the word analogy. Analog computers were single-purpose machines built as scale models of the problems they were intended to solve, such as dam building and electrical grid design.

In 1937, inspired in part by Babbage's concepts, Aiken proposed to IBM the first designs of the Mark I, which was finalized, after a series of delays, in January 1943, becoming the first fully automatic computation machine. It was electromechanical in principle, with an abundance of moving parts, and was eventually superseded by strictly electronic designs.

Parallel to those developments, in the field of mathematics, Turing and Church were making advancements in the theory of logic, independently arriving at similar results in the mid-1930s. Turing's approach, however, involved a conceptual computer, later known as the Turing Machine, and a proof, described in his article ``On Computable Numbers with an Application to the Entscheidungsproblem''¹⁶, that this idealized machine could compute any function.

While staying at Princeton University, Turing met John von Neumann, who would go on to play a prominent role in the invention of the modern electronic computer, inspired in part by Turing's work.

John von Neumann became involved in the computer development scene when he became aware of the ongoing efforts for the construction of the ENIAC, around 1944, a computer that used thousands of valves and was built to use the decimal system. Neumann started to work as a consultant for the team and soon identified many potential problems with the machine, leading him to start designing a successor capable of addressing those problems.

His report ``A First Draft of a Report on the EDVAC''¹⁷, originally from June 30, 1945, laid the basis for modern digital computers. When finally operational, at the beginning of 1950, the EDVAC ushered in the new era of digital computers. From this point on, the process of popularization of the computer, from a mathematical machine to a general-purpose appliance, would continue, eventually culminating in the creation and widespread adoption of personal computers.

Since the early days of digital computers, even when mainframes were the only available machines, restricted to organizations with considerable resources, people found ways and motivation to overcome technical limitations and develop artistic applications, like video games, in their — and the machines' — spare time.

At the 1940 New York World's Fair, for example, the Nimatron was first exhibited¹⁸. It was a single-purpose, electromechanical machine designed to play the game of Nim, described in Redheffer¹⁹.

Another example is a computer chess game for programmable machines, written by Turing in 1947, that could not be implemented due to the limitations of available computers at the time²⁰. In the following year, the patent for the cathode-ray tube amusement device, considered the first known example of an interactive electronic game, was granted²¹.

Regarding musical applications, in 1957, while working at the Bell Telephone Laboratories, Max Mathews created MUSIC I, a programming environment intended to simulate the circuitry for analog musical synthesizers in digital computers²². His efforts are described in Mathews²³, and inaugurated the quest for digital sound synthesis.

In the seminal paper ``The Digital Computer as a Musical Instrument''²⁴, Max Vernon Mathews, after years of using computers to analyze sounds at Bell Labs, argued that digital computers could be used not only to aid in composition and other high-level music-related tasks, but also to generate sounds that could be reproduced by loudspeakers.

The paper highlights that computers are theoretically capable of synthesizing any sound, proceeding to describe the process in which discrete numbers can be transformed into sounds and, in so doing, introducing the concept of discrete numbers as samples from the instantaneous pressure of a sound wave.

To convert those numbers to sound, a digital-to-analog device, capable of generating pulses proportional to the magnitude of each number, is to be used, and those pulses smoothed a posteriori. The paper also highlights the practical necessity of compact sound representations.

Mathews went on to implement, in 1968, the successor to the MUSIC I-IV family, Music V, in Fortran, the first music programming language to be implemented in a portable programming language²⁵.

Around that time, in 1965, Cooley and Tukey introduced what is now known as the FFT algorithm, in the paper ``An algorithm for the machine calculation of complex Fourier series''²⁶, one of the 10 most influential algorithms of the 20th century²⁷.

The FFT algorithm, by exploiting symmetries, reduced the complexity of the calculation of the DFT from $O(N^2)$ to $O(N \log_2(N))$, where $N$ is the length of the original discrete signal, for cases when $N$ is a power of $2$. Although this algorithm was originally discovered by Gauss²⁸, and rediscovered at least a handful of times in the approximately 100 years between Gauss and Cooley²⁹,³⁰, it became famous in the form proposed by the latter.

Montagu, Jeremy (2007). Origins and Development of Musical Instruments. Scarecrow Press. ↩
Montagu, Jeremy (2007). Origins and Development of Musical Instruments. Scarecrow Press. ↩
Bovermann, Till, Alberto de Campo, Hauke Egermann, Sarah-Indriyati Hardjowirogo, and Stefan Weinzierl (2017). Musical Instruments in the 21st Century. Springer Singapore. https://doi.org/10.1007/978-981-10-2951-6 ↩
Stubbs, David (2018). Mars by 1980 : the story of electronic music. Faber and Faber Limited. ↩
Hill, Matthew (2008). “George Breed and His Electrified Guitar of 1890”. The Galpin Society Journal 61, 193–203. [Link not available] ↩
Collins, Nick and Julio d'Escrivan, eds. (2007). The Cambridge Companion to Electronic Music. Cambridge University Press. https://doi.org/10.1017/ccol9780521868617 ↩
Montagu, Jeremy (2007). Origins and Development of Musical Instruments. Scarecrow Press. ↩
French, Richard Mark (2012). Technology of the Guitar. Springer US. https://doi.org/10.1007/978-1-4614-1920-4 ↩
Moog, Robert A. (July, 1965). “Voltage controlled electronic music modules”. journal of the audio engineering society 13 (3), 200-206. [Link not available] ↩
Collins, Nick and Julio d'Escrivan, eds. (2007). The Cambridge Companion to Electronic Music. Cambridge University Press. https://doi.org/10.1017/ccol9780521868617 ↩
Oliveira, Agamenon R. E. (2020). “D'Alembert and the Wave Equation: Its Disputes and Controversies”. Advances in Historical Studies 09 (04), 229--239. https://doi.org/10.4236/ahs.2020.94019 ↩
Dominguez, Alejandro (January, 2016). “Highlights in the History of the Fourier Transform”. IEEE Pulse 7 (1), 53--61. https://doi.org/10.1109/mpul.2015.2498500 ↩
Alessio, Silvia Maria (2016). Digital Signal Processing and Spectral Analysis for Scientists. Springer International Publishing. https://doi.org/10.1007/978-3-319-25468-5 ↩
Kelly, Martin (2014). Computer : a history of the information machine. Westview Press, a member of the Perseus Books Group. ↩
Graham-Cumming, John (December, 2010). “Let's build Babbage's Analytical Engine”. New Scientist 208 (2791), 26--27. https://doi.org/10.1016/s0262-4079(10)63100-4 ↩
Turing, A. M. (1937). “On Computable Numbers, with an Application to the Entscheidungsproblem”. Proceedings of the London Mathematical Society s2-42 (1), 230--265. https://doi.org/10.1112/plms/s2-42.1.230 ↩
Neumann, J. von (1993). “First draft of a report on the EDVAC”. IEEE Annals of the History of Computing 15 (4), 27--75. https://doi.org/10.1109/85.238389 ↩
Condon, E. U. (May, 1942). “Clubs and Allied Activities”. The American Mathematical Monthly 49 (5), 330--335. https://doi.org/10.1080/00029890.1942.11991234 ↩
Redheffer, Raymond (June, 1948). “A Machine for Playing the Game Nim”. The American Mathematical Monthly 55 (6), 343--349. https://doi.org/10.1080/00029890.1948.11999249 ↩
Donovan, Tristan (2010). Replay: the history of video games. Yellow Ant. ↩
Wolf, Mark (2021). Encyclopedia of video games : the culture, technology, and art of gaming. Greenwood, an imprint of ABC-CLIO, LLC. ↩
Collins, Nick and Julio d'Escrivan, eds. (2007). The Cambridge Companion to Electronic Music. Cambridge University Press. https://doi.org/10.1017/ccol9780521868617 ↩
Mathews, Max V. (May, 1961). “An Acoustic Compiler for Music and Psychological Stimuli”. Bell System Technical Journal 40 (3), 677--694. https://doi.org/10.1002/j.1538-7305.1961.tb03237.x ↩
Mathews, M. V. (November, 1963). “The Digital Computer as a Musical Instrument”. Science 142 (3592), 553--557. https://doi.org/10.1126/science.142.3592.553 ↩
Collins, Nick and Julio d'Escrivan, eds. (2007). The Cambridge Companion to Electronic Music. Cambridge University Press. https://doi.org/10.1017/ccol9780521868617 ↩
Cooley, James W. and John W. Tukey (1965). “An algorithm for the machine calculation of complex Fourier series”. Mathematics of Computation 19 (90), 297--301. https://doi.org/10.1090/s0025-5718-1965-0178586-1 ↩
Dongarra, J. and F. Sullivan (January, 2000). “Guest Editors Introduction to the top 10 algorithms”. Computing in Science & Engineering 2 (1), 22--23. https://doi.org/10.1109/mcise.2000.814652 ↩
Cooley, James W. (January, 1987). “The re-discovery of the fast Fourier transform algorithm”. Mikrochimica Acta 93 (1-6), 33--45. https://doi.org/10.1007/bf01201681 ↩
Heideman, Michael T., Don H. Johnson, and C. Sidney Burrus (1985). “Gauss and the history of the fast Fourier transform”. Archive for History of Exact Sciences 34 (3), 265--277. https://doi.org/10.1007/bf00348431 ↩
Ceccherini-Silberstein, Tullio, Fabio Scarabotti, and Filippo Tolli (2018). Discrete Harmonic Analysis. Cambridge University Press. https://doi.org/10.1017/9781316856383 ↩

Two thousand years of garden urbanism in the Upper Amazon

Carlos Tarjano — Sun, 14 Jan 2024 00:00:00 +0000

Published in Science, this study led by Stéphen Rostain (CNRS) unveils the earliest and largest urban network ever documented in the Amazon. Using Lidar technology in Ecuador’s Upano Valley, researchers discovered a dense agrarian civilization lasting over 1,000 years, featuring more than 6,000 earthen platforms, plazas, and an intricate system of straight roads connecting 15 distinct settlements. Described as “garden urbanism,” this complex infrastructure rivals Mayan systems and definitively disproves the notion that the pre-Columbian Amazon was sparsely populated by small nomadic tribes.

Link

BBC Coverage

Smithsonian Magazine