14 ms·

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 rea

• YeGoblynQueenne 7y ago
  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. But, Swi has my back on that, too: https://www.swi-prolog.org/FAQ/PrologLAMP.txt https://www.swi-prolog.org/FAQ/PrologLAMP.txt 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: https://en.wikipedia.org/wiki/Definite_clause_grammar https://en.wikipedia.org/wiki/Definite_clause_grammar
  • martinlaz 7y ago
    > We could refer to the stack as LP (Linux Prolog). Nice pun (not sure if intended).
  • choward 7y ago
    Please don't format your comments like this. Nobody is going to read it on mobile.
    • jlarocco 7y ago
      What's the problem, exactly? He's quoting a paragraph out of a document, and appropriately used a blockquote... Maybe it's a bug on your phone or the HN codebase?
      • NextHendrix 7y ago
        On mobile it doesn't wrap, and renders in a very narrow frame that must be scrolled sideways, which is a faff especially in portrait mode.
      • YeGoblynQueenne 7y ago
        Who's he? :)
      • deleted 7y ago
        [deleted]
      • j88439h84 7y ago
        Hn doesn't support block quotes
        • derefr 7y ago
          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"?
    • 7y ago
• zeveb 7y ago
  > 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.
  • StavrosK 7y ago
    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.
    • wtetzner 7y ago
      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.
      • StavrosK 7y ago
        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. Fair point in that case, though.
      • rho4 7y ago
        Indeed. But have a very strong preference for tools written in your main language.
        • laumars 7y ago
• vorpalhex 7y ago
  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.
  • rho4 7y ago
    In my opinion there is everything wrong with bash scripting. As per the 1st paragraph, I would argue to use your main language instead.
    • Singletoned 7y ago
      What if bash scripting is your main language?
      • rho4 7y ago
        Then use bash scripts for everything. Good luck.
      • djsumdog 7y ago
        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.
    • djsumdog 7y ago
      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.
• dkarl 7y ago
  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.
  • Spivak 7y ago
    > 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.
    • dkarl 7y ago
      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.
• mhd 7y ago
  > It can do everything. For some weird value of 'It'. People went way overboard, but early Java really was as expressive as a stone mask.
• veeralpatel979 7y ago
  You're right, maybe the tool or script would be more maintainable if it was written in the company's main programming language. But also, a developer may not even write it if he or she feels pressured to do this. Here's a thought experiment: say you're seeding data into your local database server using the `mysql` CLI. - Would you write and check in shell script to do this, so coworkers can use it? Probably yes. - Would you write a Python script to do this? Probably no. - Would you write a Java or C program to do this? No way.
  • rho4 7y ago
    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.
    • veeralpatel979 7y ago
      The point I was trying to make is that there's many scripts which are easy to write as shell scripts, so developers will write them as shell scripts. But they are time-consuming to write in mainstream languages, so developers often won't do it if that's their only choice.