I'm toying with the idea of writing a command line interpreter and I suspect that a functional language such as Clojure is well suited to this task.
I am however 5 years out of a CS degree and my only experience with functional languages was a harrowing experience with Haskell in a third year languages course.
So, is a language such as Clojure ideal for this task? If not, what is an ideal language.
Loose requirements:
Has to run on a JVM
Provide an interactive shell where users enter commands with a CLI like syntax
User commands ultimately end up making calls to a remote service using SOAP.
Thanks!
You can approximately do that out-of-the-box with Clojure and Scala, and with Java if you add BeanShell. You might look at the REPL facilities they already have.
I imagine that's suited only for sophisticated users. But really, it's hard to imagine a language that wouldn't do a fine job on a CLI.
Deciding between platforms, the more of a modern system it is, the more it will have scripting language convenience.
I certainly know what I would use given your requirements: JRuby. (It has an out-of-the-box REPL, too.)
I don't think a CLI has any specific requirements language-wise; you could probably do just as well writing it in Java or Scala. Ultimately I think language choice is down to:
Which ones you are most comfortable working with.
Which ones have adequate library support for what you want to do (i.e. web services).
Related
We're a little aghast at how time consuming it is to develop syntactically correct ARM templates from scratch.
The Portal helps, but pushes out non-development ready templates (pretty hard to find what the bug is when all the templates use 'name' for the resource name, versus maybe something more verbose like ('microsoftStorageAccountResourceName', microsoftStorageAccountResourceLocation, microsoftStorageAccountResourceTags, etc.).
We understand that there are many ways to deploy -- but if at all possible, we'd like some assurances that ARM is the current preferred way and will continue to be the preferred primary means of scripting deployments via VSTS -- or is it sliding towards a different -- maybe more programmatic -- approach (eg: Powershell, CLI, other).
We're asking this because it looks like we will have to invest significant effort to create a resource library for this organisation (to decrease the need for all projects to become proficient at ARM deployment) -- and would prefer to do it using an approach that will be preferred by developers over the coming years, for maintainability objectives.
Thanks for any insight on which approach to recommend as the best investment.
Templates are going to be around for the foreseeable future... it really depends on whether you want to orchestrate the deployment yourself (imperative deployments using CLI, PS, SDK) or you want ARM to orchestrate the deployment (via templates). Happy to chat in offline if you want to discuss more - email bmoore at microsoft.
Writing this now one year after the original post: The answer to 'ARM Templates are still the preferred deployment mechanism?' probably depends on who you ask. "Preferred" by Microsoft according to their product strategy may be meant differently than preferred by actual users that, well, feel the pain of vendor strategy decisions. I had started with an Azure automation book that used PS scripting only; I was lead (maybe mis-lead?) then to the ARM Template deployment model, mainly by the Microsoft web documentations, but found out that those templates need so much rework that writing a PS script, or even writing an ARM Template from scratch, seems to be a more efficient way to go. In fact, I am confused at the moment about what the 'Best Practice' is, i.e. what method other developers actually use. Is there a community-established opinion on this matter, now in August 2019? Or is it all VSTS / 3rd-party IDEs nowadays?
Which programming languages provide the best support for self-modifying code?
In particular, since the program will need to make extensive use of self-modifying code, I am looking forward at the ability to remove from memory some parts of code, after they are no longer needed, thus freeing that memory. Also, it would be a plus if there was the ability to identify and index the routines (procedures, functions, etc) with some sort of serial number, so that they could be easily managed in the memory (deleted, cloned etc) at runtime.
Operating systems need to have some more-or-less "self-modifying code" in order to load programs and dynamic link libraries from storage into RAM and later free up that RAM for other things, do relocation fix-ups, etc.
My understanding is that currently the C programming language is by far the most popular language for writing an operating systems.
The OSDev.org wiki has many tips of writing a new custom operating system, including a brief discussion of languages suitable for writing an operating system -- C, Assembly language, Lisp, Forth, C++, C#, PL/1, etc.
Just-in-time (JIT) compilers also need to have some more-or-less "self-modifying code" to compile source text into native instructions and run them, then later free up that memory for the next hot-spot.
Perhaps you could find some OS project or JIT project and use their code with relatively little modification.
A few people, when they say they want "self-modifying code", really want a language that supports homoiconicity such Scheme or some other dialect of Lisp, Prolog, TCL, Curl, etc.
After looking at some OCaml graphics related projects it seems that no one using it for building GUI.
why ?
is there any modern alternatives to those outdated libraries ?
My colleagues and I use OCaml to build iOS apps that we sell. Everything is coded in OCaml, including the GUI. However, making a full OCaml binding to Cocoa Touch would be a very large undertaking, so we concentrate on building the parts that we need. It's definitely possible (and in fact enjoyable) to use OCaml for building real-world GUIs, but to get a really convenient environment would take some serious backing or a pretty big community effort. (If you're interested in our efforts, follow the link in my profile.)
I don't think you will find recent GUI bindings on the old OCaml website. As a rule of thumb, you should consider anything not available through OPAM as outdated. The most "mature" and "wall-supported" bindings for OCaml seem to be LablGtk found here: http://lablgtk.forge.ocamlcore.org/
Many people these days consider that the only GUI "library" that's not outdated is the Web. Whatever your stance on that matter, it's good to know that web is a portable alternative to traditional GUI, and that there are very serious libraries and tools available to program for the web with OCaml (from Ocsigen to Ocamlnet).
This is really a "pardon my ignorance" question so apologies if it doesn't meet the requirements.
I want to develop a fairly simple database application. It will be desktop based and lightweight so I'm happy that SQLite will suffice. I have also decided upon Qt and pyside.
Looking through the mass of tutorials out there, I keep coming across sqlalchemy and exlixir (and Camelot). I am basically just wondering what advantages there are to using sqlalchemy (and elixir) over basic QSql in Qt? What would I be missing if I didn't use such a thing.
I know this is basic but before I can progress on my self-tuition process, I just want to get this clear in my head.
Basically, you have 3 options here.
QtSql
QtSql is a separate module in Qt for working with SQL databases.
Pros:
Integration with Qt may be easier
Cons:
Hard to learn
Was made for C++, requires some redundant code
Requires adding one more Qt module to your project
Documentation looks bad
sqlite3 module
This a module in Python standard library to work with SQLite databases.
Pros:
Very easy to use
Code is quite concise
No external dependencies
Cons:
You do have to write SQL queries
SQLAlchemy ORM
SQLAlchemy makes work with databases similar to work with usual classes.
Pros:
Object Relational Mapper: exposes an object-oriented interface and makes SQL queries for you
Once you've set up the table information, work with databases is pure joy
Cons:
Steep learning curve
Here's my conclusion:
If you are comfortable with writing SQL queries and don't have to do a lot of work with databases, use sqlite3. And if you don't mind spending some time to learn something awesome, go for SQLAlchemy.
About the other projects you've mentioned:
Elixir seems dead, and SQLAlchemy has its functionality built-in now, probably better.
Camelot is just weird... I wouldn't use it.
I'm in a similar situation... fairly early in the PyQt learning curve, looking to work on some database-related projects. I've ran across some of what sound like the same threads that you have... they talk about sqlalchemy, elixir, or Project Camelot in conjunction with PyQt4. None of them really seem to go into much detail as far as explicit benefits, though. Apparently its assumed that the benefits are inherently obvious to the reader ;) For the most part... what I've gathered is that once you get to a certain level of complexity regarding your project, you'll most likely have more or less written some of the basic abstractions for database handling using the applicable Qt4 objects anyways and that you'd be money/time ahead to just use sqlalchemy/elixir rather than 'roll your own'. Camelot takes that a bit further yet, from what I can tell (as a green horn myself).
Here's what I've decided, for the near future: I plan to work my way thru the first few basic projects, using the DB stuff provided by PyQt. After I'm comfortable with that, then I may go back and rework things using sqlalchemy, elixir, etc.
Does anyone know of any semi-portable way to write console applications (e.g. basic animation) in scheme? I heard of an ncurses wrapper but I couldn't find anything.
You can't do any GUI in a portable way in Scheme -- because you only get very basic file IO.
Depends on your scheme of choice. Chicken Scheme, for instance, has good ties with C and has various Curses libraries. See their code examples:
ncurses
mojo, curses for the lazy :)
Have you checked out Guile? I've never used it myself except just to play around, but it is pretty cool, and even has a little GUI support. Not sure about portability, except it should port just fine between different Unix systems, but the same can be said about ncurses.
Don't give up hope! If you're dedicated to developing in Scheme, you can.