-
This definitely resonates with me.
At $work we’ve been using ansible for 4 years. It’s a great tool, and I still recommend it for some use-cases. But you definitely end up needing a more flexible flow and control over it. Now, ansible offers you plenty of escape hatches, you can use conditionals in the list of yaml statements, and you can add parameters to your playbooks. But over time this becomes increasingly hard to parse, and exposes an unclear interface to the users (developers.)
Recently I’ve been converting our infrastructure to a kubernetes environment, and it’s the same story. When you’re working through a simple kubernetes example, the minimal deployment-spec-as-yaml is wonderfully clear. But in order to support different flows (or even just different environments as part of the same flow,) you need more power. That’s why, this time round, I have written a small library+cli that is specific to our conventions and requirements. All it does is wrap existing tools (docker, kubectl etc.) but the point is it exposes commands to do certain things with them. And it’s written in an actual programming language (in our case, python) so that conditionals, parameters etc. are easy to write and read.
-
There’s this great debate in tech about the benefits of simple configs that are easily to statically analyze vs flexible turing complete languages. Often we see “simple” config language will rather quickly grow conditionals and loops via recursion.
In most cases I’d much rather just start with a real programming language with real testing frameworks and analysis tools. In my personal projects I prefer using lisp, lua, or (if needed) javascript.
You can start with:
( :http 80 :https 443 :keyfile foo.key :certfile foo.crt )and let that grow naturally.
Also, same argument for me applies to ansible and salt. I can test my chef recipes using rspec. I’ve recently moved to salt because it has other nice properties, but I find jinja templated yaml files to be yuck and I’m in the process of moving towards more python so things can be re-usable and unit testable (salt supports a python “renderer” and python modules).
-
The alternative dating back to LISP is a powerful language with great support for DSL’s. Then, you can use increasingly complex DSL’s and/or language primitives. I see this repeating with better safety in Haskell-land.
EDIT: Ive also seen logic approaches like Prolog where they just describe it. The runtime does the rest. One did it for Cmake.
-
-
Do you use sed, HTML, or SQL? Those are DSL’s. The main value users mention is that they’re declarative, often concise, often clear in meaning, and improve productivity. The disadvantage comes when you need something they’re not good at or just raw performance. During debates on the topic, the DSL proponents often pointed out that the alternative, flexible language + libraries, essentially devolves into the same problem on the library side with you stuck memorizing their terms, working within their patterns/frameworks, having to call external things, and so on. Between then, DSL’s are cleaner for a lot of purposes. Aside from above examples, state machines, GUI generation, data formats, bindings, language grammers, test engines, and so on all come to mind. Way easier to do that stuff in a DSL that autogerates code for your language of choice.
Pieter Hintjens has a nice write-up on the topic given iMatix delivered robust, high-performance apps in C using a set of DSL’s. Recall, though, I advise a powerful language like Scheme that can DSL within itself for consistency. A developer named sklogic does the same for his compiler-writing tool with ability to use LISP, Standard ML, Prolog, XML, etc all in one app seemlessly depending on best tool for the job.
https://web.archive.org/web/20160427063252/http://download.imatix.com/mop/introduction.html
https://github.com/combinatorylogic/mbase
Another example is Galois using Haskell DSL’s for stuff like writing correct C code. Their Ivory language is good example where it’s advantageous to DSL in Haskell w/ C extraction than build their own tool or exclusively rely on either language in isolation.
-
Your response is spot on, but because I wasn’t clear enough in my original post, let me shed some light on what I was trying to express.
I’ve been working in the new fangled sysadmin/ops/devops/whatever you want to call it space for about 5ish years now. I’ve used Chef pretty much that entire time. I’m pretty familiar with it.
In my experience, I have found that Chef works really great when your configuration management needs are comparatively simple, but when they become complex, Chef’s DSL starts to become more of an encumbrance than it’s worth - you end up lost in a sea of detail that’s germane only to the DSL.
As a very concrete example - Chef’s execution model is not intuitive to say the least - is this executing at compile time or at convergence? Why does
notifynot work the way one would expect? Why are there 40 different syntaxes for attributes?So, rather than adding value in a very constrained problem space (e.g. query a database, edit streams of text), in my experience configuration management DSLs can become a morass of detail to master, ultimately requiring that you dive deep and learn the underlying code anyway.
So what’s the point? Wouldn’t a nice straight forward Python or Ruby library with a well thought out, properly abstracted API do a better job of helping the programmer solve the problem at hand? With that approach, you only have to master a single set of semantics - those of the programming language being used.
-
An internal DSL (like Ivory) does reuse a lot of the core semantics of the language – and can be a nice and intuitive way to work with an underlying API. For example, Rake’s DSL is a succinct way to work with the internal
Taskabstraction.It is external DSLs – which require laborious redefinition of every PL feature – that are the real problem in my mind.
A “cute” Ruby DSL for configuration management could still be importable – it doesn’t have to be like Chef where
requireis replaced withrequire_recipe. Let’s say the DSL is calledbbq. You could write a config like this:require "bbq" require "company/infra" bbq "App Server" do use Company::Infra::NTPConfig use Company::Infra::SSHConfig use Company::Infra::Users task "Update Ruby" do if ENV["RUBY3"] curl_pipe_sh "https://company-infra.s3.amazonaws.com/ruby" else bash "aptitude install -y ruby" end end end -
-
Ok, I see where you’re coming from. What you’re actually experiencing are two problems with only one being common with DSL’s: pain of moments where your needs mismatch what the DSL provides (common); the DSL’s actually being a complicated piece of software without clear model of how it works (uncommon). The most prominent DSL’s of the past were BASIC-like 4GL’s, Excel, HTML, and SQL. Your experience with these should show they were fairly easy to understand at a glance. The conceptual mapping is straight-forward plus the language itself is high-level enough to save time. That’s how a good DSL should be. It seems to me Chef just isn’t well-designed or what it’s being used for has high complexity that’s seeping into the language too much. Maybe it needs increased flexibility.
“So what’s the point? Wouldn’t a nice straight forward Python or Ruby library with a well thought out, properly abstracted API do a better job of helping the programmer solve the problem at hand?”
It can. You can use either. The best DSL’s will be embedded in your language’s semantics or be similar. Moreover, they should provide a way to call custom functions for weird situations. An easy example of that are state machine compilers that let you combine a high-level description of states/transistions and a list of custom functions. It does the rest.
In most cases, libraries are fine. It’s really when there’s a lot of glue, boilerplate, scaffolding, portability issues, error handling, etc that it helps to modify the language itself to do those cleaner. DSL’s are easier than doing a whole language or ecosystem, though. So, it’s really what tool suits your needs for a given situation. I’d also recommend, as with any dependency, that you have an exit strategy where you’ve chosen a DSL or tool that’s easy to move off of if it becomes a problem. A simple one in terms of syntax and execution model might even be automatically translated into something else during a move.
-
-
-
-
-
-
-
As mentioned last week, I took part in Ludum Dare this weekend. You can see/play my daft entry here: Bathroom Break Manager
Had an absolute blast, and did not completely kill myself. Got a full 8hrs of sleep on of the nights. Definitely the most complete game I’ve submitted out of my three attempts. Spent a reasonable amount of time laughing childishly at variable and function names relating to toilet activity.
This week I will be attempting to get enough work done that I can happily relax for the holiday period. This mostly means tidying up a kubernetes setup and helping team members get set up and running with it.
-
If you have some spare time or particular pain points, please feel free to PM me with any feedback around getting devs set up with kubernetes. I work on local kubernetes developer velocity.
[0] https://lobste.rs/s/d4ben6/what_are_you_working_on_this_week/comments/qpcive#c_qpcive
-
Nice! Thank you, I will definitely ping you if I have questions / come across a problem etc. I’ve been using minikube extensively to get setup and build out our developer workflow, and it’s been a treat to work with, so thanks for all your work
-
-
-
I like using inoremap jk <Esc> instead of inoremap jj <Esc>. It’s quicker to hit two keys in quick succession and it has the benefit of being mostly being a no-op in normal mode since you just go down a line and then up a line; which is nice if you have a nervous habit of returning to normal mode even though you might already be in it.
-
I am a big fan of using jk, and like you have never run into any issues where I need to type “jk” in insert mode. I recently switched to spacemacs, where they introduce a default of “fd” which I have found similarly ergonomic.
-
So doing that would cause typing ‘jk’ in insert mode to return you to normal mode? What would happen if you actually wanted to type ‘jk’?
-
-
-
-
-
I’ve dropped off these weekly threads purely because I rarely get the time to do much interesting work atm. But this weekend I will be taking part in Ludum Dare (a global game 48hr game jam) so I’ve got that to look forward to! Anyone else here taking part?
I’ve dabbled with various game engines/frameworks in the past, but have decided this time to stick to phaser because it’s nice and easy to distribute browser-based games, and I can use my usual stack of tools for developing (on linux) - rather than having to deal with Unity on windows or mac.
-
Well, I just made the move from London to San Francisco. I’ve transferred internally within the same company, so no new-job-jitters, but starting on the mountain of boring personal admin I need to get sorted. First up, SSN and bank account.
Who knows if I’ll have any time to do anything interesting this week :)
-
-
Thanks!
-
-
-
Both of these users have fairly simple use-cases. Check email, skype and photo sharing.
I’m certainly no expert but isn’t this issue solved to a certain extent by tablets/phones? I’m thinking of the meme about how toddlers can pick up and navigate an ipad with little or no introduction. Certainly they offer less power in return for simpler interactions (jab this icon, poke about etc.)
-
-
Really like this idea!
Will have to watch myself - I can imagine accidentally staying in a “sudo>” shell :/
-
Does eat history though (commands run in sub shell are not captured)
-
-
-
Yeah you’re absolutely right :) - although I tend to avoid su for the exact same reason
-
or
sudo -s
-
-
-
Similar to @ericdykstra I’ve struggled with technical podcasts, as I feel as though I am not absorbing the content. However, podcasts I tend to listen to a lot are:
- Idle Thumbs - entertaining stuff about video games
- In fact anything on the Idle Thumbs Network is probably worth a listen, they’ve got in depth interviews with game designers, strategy game chat and a Netrunner podcast
- The Adventure Zone - three brothers and their dad play DnD. Worth starting at the beginning. Can be completely hilarious.
Having said the above about technical podcasts, I did enjoy the HaskellCast. Wish there were more episodes though :(
-
I own this and I’m not sure I can recommend it. Nothing wrong with it per se. It is most definitely a “cookbook” as it is essentially lots of fairly small code snippets. Unfortunately a lot of them seem to be about how to use a particular library rather than general techniques.
I guess I’m saying it’s not terrible but don’t expect it to get continued usage over the years.
-
Nim is one language I always forget about but every time I look at it, I’m impressed with it’s feature list.
Out of interest, anyone had any experience using it in anger?
-
From the example you showed, it looks like you don’t validate the individual inputs until you get to them? I would probably expect the options parser to check all the args first…
Anyway, your question - definitely not 1) but I would say there’s nothing wrong with 2) or 3) - if I had to choose I would say 3) because then you can pipe input from another process.
-
I play Android: Netrunner. It’s a fun universe to immerse yourself in, and the different/emerging mechanics and play styles really appeal to me.
When I’m not playing Netrunner, I work on a Chrome extension for an online Netrunner implementation. It’s fun to use new ES6 syntax without worrying about polyfills and transpilers. I also murder the guitar, mostly in the form of failing to be good at Rocksmith.
-
-
-
-
Ooh! Jankteki right? Thanks for your work :)
I’m an intermittent player, I’ve been noodling with jinteki.net because I can’t get RL games much. Sometimes a bit hard to find matchups. Looks like there’s a few players here, perhaps we should share details for a game sometime?
-
-
-
I work for a company where the majority of the devs (myself included) are based in a London office, but we’ve slowly grown a group of remoters. As it happens, I will be moving across the world in a few months, so will be becoming remote, and have been reading this thread with interest.
A point I definitely suspect is true, is that it’s harder when (like us) there is a largish group of you who do work in the same place. It’s inevitable that you will miss out on ambient conversations etc. It was also definitely the case for us that we didn’t do a good enough job of including the remote members from the get-go. Now we do a much better job of keeping as much discussion as possible in public slack channels.
One recent change I made, which has got good feedback from all, is that for our standups and meetings, as much as possible, everyone dials in separately, even if we are in the same office. We got some weird looks from other depts in our (depressingly) open plan office when we started speaking to each other over headphones, but it prevents the larger group from dominating the discussion, and tailing off to sub-conversations that the others are left out of.
The only other morsel I have, is that one of my (remote) colleagues took it upon himself to setup 1-1 time with all the other members of the team once a week. We usually chat for 20mins or so, and often just end up chatting about books we’ve read, or games etc. but I think it’s had a positive impact.
Good luck!
-
tigerfinch
2 years ago
|
link
| on:
A simple starter project for building Reflex applications with Stack.
I hadn’t come across reflex before, there’s some nice recipes/examples here http://web.mit.edu/greghale/Public/my-reflex-recipes/
-
I was tempted to stop reading this after the weird “alpha geeks” comment in the first sentence. Turns out I should have listened to my instincts. I will leave it there, as the issues with this article have already been highlighted by others here.
-
Nice article. I guess I was waiting to hear the result though - did you end up using Haskell/Purescript? From the sounds of it maybe not?
It’s a conundrum I’ve wrestled with recently. Where I currently work we have a few components I believe would suit Haskell particularly well, and as a relatively green fanboy of the language, I would relish the chance to get some real production use out of it.
Not only that but I’ve discussed it with my immediate superior and he would be open to persuasion. However, as a pragmatic lead developer, I haven’t been brave enough to fully push for it. I know I am nowhere near expert-level and would struggle to teach a full team on it. We could learn together (good smart team of senior developers) but there’s an obvious trade off in productivity for some unknown period of time, and it would require a reasonable amount of enthusiasm from everyone to dive in.
My current plan is to continue working through @bitemyapp ’s book (http://haskellbook.com/) to see if that eases some of the learning pain, and find a suitable chunk to bite off and suggest for work.
I guess I don’t have much of a point to make here, just that this resonated with me.
-
The goal with the book is to get people to a place where they can do practical projects (not the only goal, but a big one).
My recommendation is to start making toy projects after the book and try to get some breathing room at work where you’re allowed to get stuck on an prototype. Mistake I see people make is to do something high stakes just as they’re getting comfortable. Most common mistake is not asking for help, so please do ask for help! If you’re comfortable with IRC, #haskell and #haskell-beginners have friendly souls, otherwise, my email is on my Github. I may not have time to address your problem in detail but I should be able to get you pointed in the right direction.
Hope you’re enjoying the book :)
-
Thanks for the advice - I only hope I can find that breathing room ;)
I will certainly reach out on IRC or to you when I hit any stumbling blocks. I’m really enjoying the book currently, just wish I had more time to dedicate to getting through it. Having messed around with Haskell for a while, some of the challenge is making myself work through everything, even the parts I think I know - just to make sure I don’t miss some key intuition or lesson to be extracted. Great work though, and thank you for the book.
-
-
did you end up using Haskell/Purescript?
I’m not going to stop learning Haskell because it is hard. I’m definitely thinking about where Haskell might fit in our infrastructure: we have tons of Python and some Clojure. I seem to think that Haskell is quite well-suited for small services (ie the opposite of Rails or Django).
So the answer is yes, we’re open to the idea of Haskell but maybe not just yet.
I’m glad to see that this post has resonated with so many people.
-
-
I completely agree with the author’s overall point - for FOSS projects, slack is the wrong tool. However, I find the rebuttal to the integration argument slightly misses the point. Slack has a bunch of integrations that require a few clicks, and authorising with the relevant service.
When we switched to slack at work, one of the product team was able to quickly set up integrations with trello etc. and the first we knew about it was when he told us it was a fait accompli. Even as a developer, I can still see the benefit of having to write no code rather than some code. Especially given that it’s not even a fun problem to bikeshed.
But yes, please use something open (preferably IRC) for FOSS projects.
-
Thanks for this, and for highlighting the course. Signed up and looking forward to it!
-
This is great, I’ve looked for similar introduction-level information about databases before, and always come up short.
This is the clearest, simplest explanation of what hpack is and why I might want to use it, that I have come across.