Couldn't agree more. R and dplyrs ability to pass column names as unquoted objects actually reduces cognitive load for new people so much (pure anecdata, nothing to back this up except lots of teaching people).
And that's on top of the vastly simpler syntax compared to what's being shown here
I've been programming for decades. I've used dozens of different, at times enormously esoteric languages. At one point I built ERPs in a language where operators were abbreviated Russian terms. After just a few years of using Lisp dialects I am absolutely convinced - there's no simpler and more readable syntax than of Lisp's. Anyone who doesn't see that, in my eyes just not made the distinction between familiarity and simplicity.
They're measuring how quickly their eyes can parse something they've already seen a thousand times, and calling that readability. But readability isn't recognition speed - it's the cognitive distance between the code and the computation it describes. And on that measure, Lisp is essentially lossless. There's no syntactic residue. No ceremony the language demands for its own sake. What you write is the structure of the thing, all the way down.
"You get used to it. I don't even see the code. All I see is blonde, brunette, redhead..." I don't look at Matrix feeling puzzled anymore. I see the truth.
People who bounce off the parentheses are reacting to something real: it doesn't look like what they already know. But that's not the language failing them. That's just the last bit of the old syntax dying. Give it a few months of structural editing and a proper REPL workflow, and you won't see parentheses anymore - you'll see shape. You'll see depth. And going back to anything else will feel like someone handed you a map drawn in crayon and called it a feature.
Even though I'm firmly in the familiarity camp, I love this description of what it's like to be fully lisp-pilled. I definitely want to try it out one day.
One doesn't need to dance around weird circles to give it a try. VSCode's Calva extension has great "Quickstart guide". Or you can just install Clojure, run it - it drops you into a REPL. Once you ready to get serious, grok some basic structural editing commands (grabbing an expression and moving it somewhere else would suffice) and REPL-driven workflow (Lispers typically don't type into REPL, they eval things directly where the source is)
I enjoyed reading this but felt like it missed a few of the points on why a lot of companies are indexing heavily on the context layer.
1. While AI is capable of driving massive value, chatbots are very rarely the solution
2. You need much more than this sort of text data to represent an enterprise. Timeseries, SAP (and other ERPs), and general relational data is part of building a knowledge graph, ontology, etc
3. Storing it the way this article presents makes it usable for agents, but not humans. Whereas the point of knowledge graph, ontology, etc is to create the same layer for both humans and AI to interact with
> 3. Storing it the way this article presents makes it usable for agents, but not humans. Whereas the point of knowledge graph, ontology, etc is to create the same layer for both humans and AI to interact with
If storing it this way makes it usable for agents, then why don't humans just use agents when they need to interact with it?
Let's say that you want to know who your largest customer is, both by order value and volume. I could either:
1. Prompt my agent and deal with writing the prompt, waiting for the agent to sift through all the data (which would be massive), and pay the token costs, all of which has to be repeated everytime I want to answer this question, OR
2. I check my ontology for the answer, probably in a dashboard, and it takes 5 seconds. I have a link I can freely share around my enterprise and I haven't spent token costs.
Whats more, when I have sent my agent out to some tasks (go find out what revenue we're leaving on the table by not selling spot contracts to our biggest customers) my ontology gives me a few bits of data to validate the agents work against. For humans and AI to work together, they need the same context layer
Yea I agree. for most big enterprises, you probably need robust RBAC and multitenancy.
But I do think this pattern of letting agents figure out your company autonomously in some text-like format will be the core pattern going forward
Exactly this. Having spent almost three decades in enterprise context I see a lot of reinvention of something like a poor mans, unstructured, enterprise architecture - because AI agents.
I keep repeating ”what is good for humans in an organization is also good, or even required, for AI agents”.
Imagine every new instance of an AI agent as a new employee.
With humans its ok to slowly accumulate knowledge through word of mouth, trail and error and the general inertia of larger orgs almost seem structured (or unstructured) knowledge-wise for this.
AI agents will never be useful in high value operations in a larger orgs without organizational knowledge available and reliable.
I can write code like:
penguin_sizes <- select(penguins, weight, height)
Here, weight and height are columns inside the dataframe. But I can refer to them as if they were objects in the environment (I., e without quotes) because the select function looks for them inside the penguins dataframe (it's first argument)
This is a very simple example but it's used extensively in some R paradigms
The mistake here is having an architect who is not shipping product. Architects who's job it is to define 'rules' and 'patterns' without actually impending anything are almost always a bad idea. Just focus on shipping. Have at least one experienced engineer who can guide the development but don't give those decisions over to some 'architect' who is not even going to write 10 lines of code in your codebase
> We had 4 backend developers and a DevOps guy who was already stretched thin.
The mistake here was having an architect full stop. The team is too small, a good tech lead can manage to plan a service with 50k MAU (and way beyond) without an architect. The problem with some companies that get millions in seed funding is that they need to spend the money and they do so by adding roles that shouldn't exist at that stage.
Another favourite antipattern: making devops a bottleneck. Don’t over-engineer production, don’t buy abstraction you can’t afford, and educate your colleagues to lower the bus factor.
Dedicated devops that aren’t co-founders are notorious for cv optimizing: working with cool, but time-consuming stuff they don’t yet master, at the cost of delivery-time risk.
I strongly think that R has outgrown just having statistics as its killer feature. The killer feature of R is data analysis
I have yet to see any software that rivals dplyr, data.table, and ggplot2 in the balance of power and ease of use. It also has all the auxiliary packages you need to fetch your data (DBI, httr, rvest), model it if necessary (parsnip, caret) and visualise it (ggplot2, plotly, shiny)
I know python is more popular here but I would choose R in a heartbeat 19 times out of 20
Possibly. I think R is actually easier to learn for people who have never studied or done programming before.
1. It's easier to get up and running as RStudio is much more 'batteries included' than other popular IDEs, it's harder to get into the case of multiple different python versions, and you install packages through the R interpreter rather than via pip at the command line
2. I would say R data analysis packages are easier to learn than the python equivalents. Because the dataframe is a native structure in R there has been a lot more packages that have tried alternative syntax approaches to try and find the 'optimal' one. Python has really only had pandas, polars, and pyspark (all of which have implemented their own data structures and therefore have focused more on performance than syntax)
3. This doesn't hold if you're studying a language to be a general purpose programmer. Then python is much better. Anything to avoid the hell of the R standard lib. But if you need to do a bit of coding to analyse data and you've never done any before, my vote would be for R.
However, these are thoughts from my own personal anecdotes rather than any pedagogical theory
I haven’t used matlab for 10+ years, but back then Matlab used to provide engineering packages for vibrations and non-linear models approximations, I’d imagine the effort of going Python/ open source code to just to redefine your model for both purposes and then validate and verify the results would be a 10-50 fold cost of paying for a license
Very cool! Are you planning for there to be a corresponding R package that exposes the high level commands? The popularity of the usethis package really showed the power of keeping people within the R interpreter rather than going back and forth with the terminal. This is so important for a language like R that has so many users without much CS training
Yes! Absolutely in the plans to have a corresponding R package. In the meantime, we've created a `.rv` R environment within rv projects that allow users to call things like `.rv$sync()` and `.rv$add("pkg")` from the console. Our internal user bases is primarily not CS based and have found these functions extremely helpful
That’s awesome! I have been playing off and on since 2009!
If you haven’t heard of it, check out The November NetHack Tournament [1]. I played it for the first time in November of last year and almost got a Wizard win (ran out of time) after getting so close with a Monk (got killed by Rodney’s touch of death after he stole my only source of magic resistance).
And that's on top of the vastly simpler syntax compared to what's being shown here