91–100 of 334 posts
Earlier quoted context omitted.
That is really cool. How did you go about designing the language. Did you go for a full lexer and parser ? or it was more functional. Curious to understand how you built it.
Ruby's super power is it's meta programming ability. So they were really just writing Ruby. If you google, I think there's a bunch of tutorials out there for creating a DSL in Ruby... but I learned from a book called "Metaprogramming Ruby"
This delusion is especially visible in the DevOps space. For some reason we have decided as an industry that instead of writing some code in whatever 'real' language we will base operational work on YAML with ad-hoc templating and stringly-typed programming constructs. The main culprits are Ansible/Salt and all the string-templating based tools for Kubernetes (Helm/Kustomize/...). Especially with tools like Helm I be…
Thank god trends like Pulumi and the new AWS sdk is emerging. General purpose programing languages are getting more expressive by the day, why do we use data serialization languages instead for configs? it doesn't make any sense. Configuration is code not data.
The more things change, the more they stay the same.
The pendulum is swinging back towards scripting languages. But give it a few years, and we'll be railing against scripting languages for not being idempotent enough, and moving back to the latest version of YAML and XML (perhaps we'll go with TOML this time) with custom interpreters.
We have seen this half a dozen times already, between turing complete DSLs in ruby, to plain bash, perl, and python scripts. The other side are the DSLs written using YAML, JSON, and XML (and every other config language written in history).
Earlier quoted context omitted.
Is that very different from the websites of the 90s? I distinctly remember creating a somewhat-dynamic site in FrontPage, then rendering it into static HTML and FTPing it to the webserver. Perhaps this was an impedance mismatch: "web requires coding" - it mostly doesn't, most people would be okay with a better HTML editor, and providing that via WP was a historical quirk.
Those would be examples of static sites, which are "read only" to most users. Wix, Squarespace etc can handle form submissions and online payments of course. And with third party solutions like Intercom and Optimizely, things like customer support chat and A/B testing can be done with pretty much no code.
This delusion is especially visible in the DevOps space. For some reason we have decided as an industry that instead of writing some code in whatever 'real' language we will base operational work on YAML with ad-hoc templating and stringly-typed programming constructs. The main culprits are Ansible/Salt and all the string-templating based tools for Kubernetes (Helm/Kustomize/...). Especially with tools like Helm I be…
You can implement LUA in less lines of code than YAML, lua has been around longer, easier syntax, loads of support, proper community around it. Yet people still use YAML on hype alone, it's awful.
And LUA has its own hype, just not in configuration scenarios.
#include
#include
char *add_domain_name(char *source) {
const size_t size = 1024;
char *dest = malloc(size+1);
strncpy(dest, source, size);
strncat(dest, "@example.com", size);
return dest;
}
strncat(dest, "@example.com", size - strlen(dest));
Earlier quoted context omitted.
Nearly 40 years for me; I remember reading about The Last One [1] back in 81. [1] https://en.wikipedia.org/wiki/The_Last_One_(software)
Yes, in the 80's and 90's we called it CASE (Computer Aided Software Engineering). It was just as fascinating then and equally impractical now. Text turns out to be a great, compact way to convey ideas or instructions which is the heart of software development.
I dabble in graphical programming languages from time-to-time, and one feature they all share is the editing environment for code makes entire categories of syntax error impossible; there is no way in the language's design to pass a string to a function that only accepts a number, for example, because the "blocks just don't fit together." It's a level of integration between the space of all possible arrangements of elements and the set of arrangements that constitute valid programs that I see text-based IDEs approach, but struggle to catch up with. And I suspect part of the challenge is that as a tool for describing programs, sequential text has too much dimensionality; the set of strings of sequential text is much, much larger than the set of valid programs, and it's easy to put text sequences together that aren't valid.
Earlier quoted context omitted.
I can train one of my juniors in how zapier works in an afternoon. Teaching them (or myself) a programming language would take years and be more error prone.
I can teach IF, FOR, and the basics of python in a week. I can teach ruby in about the same. For what they are going to need for a low code solution, that's enough. You don't need to teach all of programming - only a subset that would be covered in a low/no code solution. If you don't believe this, look at how many non-CS professionals have learned VBA as their excel-fu reached a limit. Even if it's not clean to star…
This delusion is especially visible in the DevOps space. For some reason we have decided as an industry that instead of writing some code in whatever 'real' language we will base operational work on YAML with ad-hoc templating and stringly-typed programming constructs. The main culprits are Ansible/Salt and all the string-templating based tools for Kubernetes (Helm/Kustomize/...). Especially with tools like Helm I be…
This delusion is especially visible in the DevOps space. For some reason we have decided as an industry that instead of writing some code in whatever 'real' language we will base operational work on YAML with ad-hoc templating and stringly-typed programming constructs. The main culprits are Ansible/Salt and all the string-templating based tools for Kubernetes (Helm/Kustomize/...). Especially with tools like Helm I be…
IMHO a big part of the problem is that the companies involved are actively incentivized to justify their existence by making things more complicated instead of less complicated. If things are too simple, nobody needs their consulting, training, support, etc. Worse most of these companies are competing for attention and typically only provide part of the solution instead of the whole solution. So there's a lot of money in cross integrating multiple complicated solutions from different companies. Indeed many of the companies involved are serial offenders when it comes to this. As soon as you get companies like Red Hat, Amazon, Oracle, etc. get interested in stuff, brace yourself for some convoluted vendor lockin. That's basically what happened to Kubernetes.
When it comes to languages, I'd love something that has a compiler and auto complete. I'd also like something that has a notion of internal domain specific languages. IMHO Typescript, Kotlin or Rust could work for this. The point of this would be leveraging a type system for static checks and code completion. That kind of rules out dynamic languages like javascript, python, or ruby (all of which have been used in devops in the past). They are nice but not nice enough.
However, typescript has enough static typing that you get some meaningful autocomplete. Also, it's already popular in the node.js world (i.e. lots of stuff available to integrate). Kotlin would also be able to fit in that world since there's a transpiler to javascript, it can utilize typescript type definitions and it integrates with node.js and npm. Rust would be a bit of an outlier here and probably a bit too much in terms of language complexity for the average yaml loving devops type with a mere few years of full stack experience. With Kotlin, the transition of gradle from groovy to Kotlin has been interesting. Groovy basically is a dynamically typed language and they've slowly been replacing it with the more strictly type Kotlin. That sort of stabilized with v5 and with v6 it got usable for a lot of projects and recent updates to Intellij have improved how it is able to support developers with e.g. code completion and other features. Something like that aimed at devops could work.