Story of my life. In my opinion the best tool for basically all jobs is usually the main programming language of your project / team / company. Everyone can read it, change it and run it. It can do everything. It has the best tooling support. The best IDE, which everyone has installed, licensed and knows how to operate. It is hopefully compile- and type safe. It is hopefully under source control. And hopefully a mainstream language, so you can find tons of help and resources online.
But for some reason, every f* new task is always first solved with some interpreted weakly typed scripting language, shell script or batch file, config file, xml programming, open source tool or web service. Unversioned, and with the weakest tool and team support imaginable. Probably a separate git repository with separate login credentials is created somewhere along the way as well.
Totally with you, except you need to choose your primary language carefully if you want it to scale up and down like that. Don't expect people to write little command-line tools and one-off scripts in C or Java. You'll see an apparent lack of tooling for little tasks, as people hoard their secret scripts. And it's really important to get people to check code like that in, as then it will be subject to PRs where bugs will be spotted, documentation requested, and general awareness of the code's existence raised.
Also, junior people will translate "code I will never be able to check in anyway" to "perfect opportunity to play around with that new language I want to learn" and then you've got them making the usual mistakes as noobs in that language.
> Don't expect people to write little command-line tools and one-off scripts in C or Java
Assuming you’re a C/Java shop, why not? You get to leverage all of your coworkers code to make that little CLI app. The whole thing will probably be “parse args and then call an existing method.”
Then that little tool is part of your app, callable wherever your app is, stored in Git, testable with your existing tools, etc.
Parsing args in Java is okay, I guess, but it doesn't meet people's expectations for knocking out a quick script to get something done. When it comes to writing a script to parse some arguments, send requests to a few endpoints, process the responses, maybe send more requests, it's a lot faster to write something in Python from scratch using Click and Requests than it is to write it in Java even taking advantage of the model and client classes that we have for all of our services. Scripting in Scala using Ammonite would be the best of both worlds, but our Java code requires a ton of stuff to be set up and initialized before it can work.
And that's another big issue with Java. If you start out writing plain Java, people feel like they're missing out on all the "help" they'd get from a framework, and pretty soon you can't figure out how to make your code run at all except inside the framework. So you have to either write your scripts using the framework's CLI helper, which is probably some enormous abstract class that has its own argument parser you have to integrate with, or you start reverse engineering the framework's CLI helper to figure out which parts you need and end up running out of time and falling back to Python and swearing to figure it out someday. That's my experience, anyway.
You are assuming that people are not capable of "parsing args and sending request to endpoints" in an efficient way, using a few lines in their main programming language. This assumption is probably very offensive to any competent developer. Your are right, however, that a junior developer who is still getting up to speed with the main language of the team will be tempted to use whatever language / script that he already knows or encounters in a stack overflow answer.
I feel your pain. For me the worse case of this is web dev, where there's a different language for every task: html, CSS, javascript, SQL, your back-end language, XML, JSON, and so on.
Can I replace a LAMP stack with SWI-Prolog?
Yes, you can, and you'll be happier for it.
LAMP is short for the following open source components to realise a web
server:
Linux
Apache
MySQL
PHP
In this picture, Linux provides the OS, Apache the web server, MySQL the
database and PHP server-side scripting facilities. In fact, most of these
components can be replaced. One can replace Linux with almost any other OS,
Apache with Nginx, MySQL with PostgreSQL. PHP is similar to ASP.
There are also larger replacements of this stack, such as Tomcat, which
replaces both Apache and PHP. Similar architectures are available for Python
(django), Ruby (Ruby on Rails) etc. As we will see below, this is the picture
into which SWI-Prolog fits.
The SWI-Prolog web framework
The SWI-Prolog web framework (obviously) does not replace the OS. It does
replace Apache, PHP and to some extent MySQL. We could refer to the stack as
LP (Linux Prolog). Below, we point at the various libraries that make up the
stack and relate them to the LAMP components they replace.
You can't quite replace html/css/js of course, since the browsers depend on them- but they can be embedded in Prolog easily. I believe the http library in my other comment here has facilities to do this.
Also- if you ever need to write a parser for some topsy-turvy ad-hoc markup language some third-party is using that you are forced to process, Prolog is probably the best language to do this, thanks to its Definite Clause Grammars notation that's basically BNF, except that it's not restricted to context-free grammars:
While I generally agree with your comments, I am currently working on a project with a React front-end in Typescript and a Node back-end in Typescript, the first time I've ever had the same primary language everywhere. It is a HUGE productivity boost, and most importantly makes it much easier for anyone on the team to review and understand pretty much any area of the codebase.
Folks should not underestimate the benefits of having a single primary common language everywhere.
> Folks should not underestimate the benefits of having a single primary common language everywhere.
Indeed, that's why I'm getting past my static HTML comfort zone and trying out the SAFE template for F# development on both client and server via .NET Core. Super new at it, but excited to learn.
Apparently there is this thing out there called Fable that lets you use the same domain types on both client and server, now THAT sounds like fun to me.
I've always wondered why support wasn't added. It's a very simple change to add them; and everyone continuously tries-and-fails to use them. @dang et al, is there nobody on your side who can make little patches like this to "pave the well-trod path"?
> If people could understand what computing was about, the iPhone would not be a bad thing. But because people don’t understand what computing is about, they think they have it in the iPhone, and that illusion is as bad as the illusion that Guitar Hero is the same as a real guitar.
-- Alan Kay
Direct your complaints to the source of your problem, namely the shitty browsers on mobile. Even suggesting to let HN fix their abysmal stylesheet would be wrong. Go to the source -- and if it turns out they don't care about requests to provide actual tools, tell them off.
Sorry about that, but that's 78-character columns, plus two columns for indentation. It's not too wide.
Also, I hope I'm not rude to point out that I expect people interested in an article on Prolog to have a non-phone computer that they can read this more comfortably on.
You're right, it's not urgent—and neither is it important (as far as they know, not having read it.) So people will just scroll right by your hard-to-view comment†. And if that's the case, why bother writing it?
Would you post a comment here in a language only you speak? No, because the point of commenting is communication, and that comment wouldn't be communicating, right?
† Many people only view HN on mobile. It's a time-killing social news app; I don't want it anywhere near my workstation!
It's still one that doesn't mesh perfectly with the WWW on less tiny form factors. You could also try turning your phone sideways.
Code blocks, in some cases, are just the simplest way to quote things. Random people on Internet forums should not have to compensate for other people not being on devices that make sense for an Internet forum.
I was with you for the first paragraph, but not the second one.
Yes, you should use a relatively small toolset and use it well. Whether that toolset is prolog or JS or bash or whatever depends entirely on your needs and requirements and will vary from team to team.
If bash scripting meets your needs, then use bash scripting! There's nothing wrong with it. Likewise for clojure or C# or any other tool.
Most companies have sets of supported languages and you need to use the right tool for the job.
For small one-off tasks or simple services, your company should have a template for writing those in a good scripting language: Python, Ruby .. something you can write tests/specs for if it grows, that has a good amount of programmers you can hire, etc.
Your core service apps might be written in something different, that can scale up, whether that's a JVM lang (Java/Scala/Clojure/Kotlin) or a .NET (C#/VB.Net) or Elixir or Rust or whatever depends on a lot of things. You want to have something your core programmers enjoy writing in, but also something you can find new people for as your company expands. It can be a delicate balance. You can have multiple core languages (my current company is Node/React for most front end, React Native for apps, Clojure for almost all backend, some .NET and Python/Go/Terraform for all devops).
It's best to have a core tech stack with some choice than just let every team do anything in whatever. But of course, it's dependent on your company and market. Your mileage will vary.
I would update my CV. Don't get me wrong, you can do a lot of good stuff in Bash. But if I want to do a lot of more complex processing, having a language with useful iteration constructs like Python, Ruby, Groovy or others needs to be an option that's on the table.
> In my opinion the best tool for basically all jobs is usually the main programming language of your project / team / company.
I read a wonderful article some time ago (here maybe?) arguing exactly this, and positing that any language unsuitable for replacing every other language in a company is insufficiently powerful. As I recall, by 'language' the author meant every single computer language: shells, interpreted scripting languages, compiled languages, perhaps even markup languages.
IIRC, the author came from a Lisp background, which shouldn't really be surprising: so far as I am aware only Lisp and maybe Forth would do a decent job at all those tasks.
The obvious counterpoint is that then you'd have to rewrite every single tool in every language people used.
I don't care about extending most of my tooling, I just want it to work. I'm not going to spend years rewriting Terraform in Rust just because I don't use Go in my company.
I don't think that follows. I think the idea was that you should write all of your in-house tools in your main programming language, not necessarily third-party tools.
Unless you're planning on submitting PRs for that tool, I don't see what different it makes what language the tool is written in. What should matter is if the tool solves more problems than it creates.
Language purity is great as an intellectual pursuit but it shouldn't distract you from picking the best tool for the job.
Most importantly: You can debug it and it probably provides an API in your main language. Bonuses: It integrates with your other tools. You can fork it if necessary. You talk the language of their support forums. And you don't know in advance whether you will need to submit patches.
Some interesting points there. Some I agree with and some I don't.
> You can debug it
That's your strongest counterargument and I agree it is easier if it's written in a language (or at least ecosystem) that you're already skilled in. But you have to be careful not to overstate the importance of this feature ie is it a tool that likely needs to be debugged using your preferred language tools (eg is it a simple tool, or stable and mature. Does it already have a suite of debugging tools available thus not requiring engineers to debug the executable itself? Are other tools like strace better suited for debugging instead of language-specific tools, etc).
There's very few tools I use daily that I've needed to debug. Even fewer that I've needed to resort to source code and language debugging tools.
> and it probably provides an API in your main language
That's a huge assumption to make. However if it does and it's an API you're likely to use then that is a differentiating feature which makes it the best choice tool and plus the tool is no longer something you're not using to develop in house.
So your point actually aligns with the point I was making.
> Bonuses: It integrates with your other tools
Again, that becomes a feature and thus you're not picking a tool for language purity reasons thus not violating the point I was making.
> You can fork it if necessary.
It's almost never necessary to fork a tool your using outside of your development framework (and if it is part of your development framework then it's something you are expecting to maintain so that point was covered in my previous post).
Or to put things another way, how many people here have forked Terraform to run their own distinct version of it?
If it's a tool you think you might like to fork or maintain then again, that's not violating my previous post since you picked that tool with the plan to maintain.
> You talk the language of their support forums
This is your weakest argument. :)
I've never typed a line of TypeScript in my life yet can talk in depth about it with the TS developers when issues arise. Why? Because I've programmed in well over a dozen other languages and the way we communicate different concepts doesn't generally change that radically from one language to another.
> And you don't know in advance whether you will need to submit patches.
You can make a reasoned guess though. A bug in the Linux kernel: I think I'll raise a bug report and leave that to others to fix. A bug in Terraform: then maybe I might submit a PR but odds are I wouldn't have the time to learn the code, devise a fix, write tests, etc. Again, I'd probably end up raising an issue on Github and working around the problem at work. Anything higher level than that then perhaps I'd raise a PR but choices often get more diverse and the impact of picking "the wrong tool" becomes less significant.
Of course, if only the foreign tool has the required functionality, it wins (no purity here).
API: Like patches, you might not need it now, or the API might not even exist yet.
Fork: Agreed, that was not a realistic scenario. Maybe a better argument would have been the ability to write plugins or extensions (even if you do not need them now).
Forum: Yeah not really important.
Patches: Agreed, who has time for patches. Like forking, probably not going to happen.
Additional (weak) argument: Better paradigm / metaphor match between tool and your system.
But yes, other factors are probably even more important, like will the tool still be actively maintained in 10 years? How big and active is the company / community behind the tool. How mature is it. How big is the existing user base. Cost, support options...
I agree. But also it doesn't make sense to pick a tool that doesn't quite fulfil your requirements, is buggy or has other problems over a battle tested tool that does solve all of your requirements bar the language it's compiled in.
I have no issue with people picking tools written in their preferred language if that is the differentiator between two competing solutions. However picking the wrong tool because it's written in the right language is a fools move. Which is the point I'm making. Language purity is great just so long as it doesn't lure you into using shit tools.
Ah hmm. For most in-house tools I usually start by taking something that already exists and configuring it to do what I need, there's little tooling I usually need to create from scratch.
I don't think that's a fair interpretation of the previous post. They weren't talking about rewriting every tool in your preferred language otherwise how far down the stack do you go (Terraform in Rust today, Linux in rust tomorrow, etc)?
Their point is software you actually develop in house. So that might be HCL code used by Terraform (in which case you might still need to use another tool or SDK in place of Terraform) but it wouldn't be Terraform itself (ie the Go code used to compile the Terraform executable).
> They weren't talking about rewriting every tool in your preferred language otherwise how far down the stack do you go (Terraform in Rust today, Linux in rust tomorrow, etc)?
Well, I'd say that one must start at the highest level and work one's way down. Clearly there're neither time nor resources to write an amd64 OS in Lisp when one is trying to get one's AirBnB-for-pools app out the door. But maybe one can give a little love to Hunchentoot. Maybe one can spend some time replacing Makefiles with ASDF. Maybe at some point one might even replace some uses of the shell itself. Maybe someday one might spend some time on SBCL.
And sure, someday, if one's firm really lucks out and achieves Google scale then maybe one will have the resources to build a new compiler or even a new OS.
So I guess I am somewhere between the two positions, at least if I wear the hat of the original article's author. I think it could make sense to write everything in one language, and I think maybe someday it might make sense to go a level deeper — and maybe someday further still a level yet deeper.
Because it would be nice, someday, to get something better than Unix-like OSes!
Also, I am a man, not a group: 'he,' not 'they' please grin
As I posted elsewhere, unless you plan to raise PRs, fork or take any other maintenance ownership of a project -- be that an orchestration tool or an operating system -- then it shouldn't matter what language it was written in.
At least with your Makefile example, you'd need to edit and maintain those Makefiles, so there is logic in rewriting them in $LANG_PREFERENCE.
But if you're rewriting services you wouldn't otherwise need to maintain just for the sake of language purity then you have to ask yourself if what you're doing is a smart use of your time or if you're actually just "shaving a yak".
> Also, I am a man, not a group: 'he,' not 'they' please grin
It's often impossible to know the gender of someone, let alone their preferred pronoun, from their post alone. So you're going to run into a lot of people saying "they" when referring to you.
edit: getting a lot of downvotes on this so it's clearly an unpopular opinion. I probably should point out I've ran several development teams over the years and it's very easy to go down the rabbit hole of NIH. There's a saying about "standing on the shoulders of giants" which I think applies here; and there's no shame in sacrificing language purity if it gives you increase productivity without any side effects (aside selling off a little of your soul). The key is being able to balance need from want. eg does that orchestration tool need to be written in $LANG_PREFERENCE or does this one on Go actually work pretty well? The ironic thing is as we get more accustomed to using cloud tools, we're becoming more reliant on stuff written which we have no visibility of. So in a way, the language purity war has already been lost.
I get where that is going, and agree with the sentiment. But this assumes that companies, engineering teams and problem domains all perfectly overlap.
I'm a systems guy in a Java shop. Ignoring obvious nonstarters like trying to shove Java into early Linux boot, this still implies I should be hiring Java programmers for systems engineers. Which, no, not only don't I care, doing that would select for a very small subset of available candidates.
There are multiple reasons, but the big one is there is almost no overlap between the engineering team's reason for existing (writing and maintaining line-of-business applications) and ours (keep systems up, compliant, performant and safe).
But if it makes you happier, one tool we use is Puppet. That runs in JRuby in a JVM to execute their own weird DSL. So to use it in a nontrivial environment, you need to be able to tune Java and write both Ruby and Puppetese.
No thought experiment necessary. On my first job, someone created Python scripts (hot & new then) to initalize our warehouse databases. Checked in, too (good!). Became a huge maintenance hassle and forced everyone to learn Python on the side. I fail to see why you would not check in a script, no matter what language... And yes, I would, have and do write database initialization "scripts" in my main language all the time.
I used to enjoy hacking with Prolog, and I used Swi-Prolog when experimenting with the semantic web, in the sw’s early days. My only real problem with Prolog is that I have only been paid to use it for one intense six week project and a few one or two day gigs. I compare this to getting lots of work with Common Lisp, Java, Ruby, Haskell, Python, etc. Contact me if you have Prolog work you want done :-)
Prolog also has some really impressive debugging tools. It allows you to pause execution, change the code, and then resume execution from an earlier point in time.
I don't know if he browses this site, but wanted to give a quick thank you to Markus Triska - the posted website and his YouTube channel are both simple but informative Prolog resources. He's also made many contributions to SWI-Prolog and a new experimental flavor called Scryer. Would encourage everyone to give it a quick look, especially the fantastic reif and ediprolog tools. Thanks Markus!
I think the last time I touched prolog was in University. Looking back through my class assignments, I think we discussed prolog but didn't actually write anything in it. The only assignment I see from that era was writing our own First-Order-Inference engine (really basic implementation; lots of limitations):
But for some reason, every f* new task is always first solved with some interpreted weakly typed scripting language, shell script or batch file, config file, xml programming, open source tool or web service. Unversioned, and with the weakest tool and team support imaginable. Probably a separate git repository with separate login credentials is created somewhere along the way as well.