Shipyard Command Interpreter

[robject]

So here's how low I've sunk.

Since I haven't yet learnt Angular, I'm thinking about command-line programs. Oh, the horror.

But track with me here. It might not be so bad. There are good things about a CI.

First, build commands are scriptable. That is, the commands you type into a CI can be redirected from a file, or to a file. You can save a session and come back to it later, or even tweak it "offline", and pass it around as you would a finished design.

Corollary, your design document is also the set of commands issued to design a ship. A ship's "design" just becomes a codification and computation of the orders you place. A ship "design", and the commands to build one, may blur to some extent.


Finally, a GUI can be built on top of a CI, so it's not like the effort is otherwise useless.

There. Have I talked myself into it?

 

[coliver988]

Talk yourself into it. Not only can CLI be scripted, but chain enough together and you can do some powerful things (I really miss working on Unix and writing scripts that used commands that piped out/piped in results and stuff; although I have just tasked myself scripting the deployment process which is on a Linux system, so I guess I am back to at least a UNIX-like environment and scripting!)

Plus a CLI is a lot more likely to be able to be used on more than 1 system - Mac, Windows, Linux. GUIs tend to be specific to a single OS and have a lot more overhead (databinding, graphical frameworks).

Just have clear input & output: i.e., I can see a small one that just generates a UPP (and may have mods if you want an alien with +/- on the die rolls); followed by a command that takes a UPP and 1st choice as input and tries to get into a career, which results in the UPP and the career, which then gets piped into the career builder, which results in a UPP, skills, age, rank, etc.

Single repository/purpose modules. My problem is I always start there, and then feature bloat...

 

[Leitz]

Depends. I do a lot of CLI stuff and enjoy it, until it comes time to share it. Need to test against Linux, OS X, and Winderz. And Python 2 and 3. And iPad, which is supposed to be different.

That 'sharing' is what kills me. So, there are at least two solutions; don't share, or use a web interface so the client OS is irrelevant. I tend to work via CLI until I understand the process and then put something in PHP or whatever web interface the language I'm using uses.

So, bottom line is use CLI to learn and work out the issues, then look at a web GUI. Bottle or Flask should be doable.

 

[nobby-w]

So here's how low I've sunk.

Since I haven't yet learnt Angular, I'm thinking about command-line programs. Oh, the horror.

But track with me here. It might not be so bad. There are good things about a CI.

[ . . . ]

Back in the late Jurassic period, there was a language called tcl which was designed to do this sort of thing. It's still around and there are similar embeddable languages such as lua, although tcl is interesting for reasons I'll explain below.

The main claim to fame of tcl is that it's very easy to embed anything that can work with C style argv structures into a tcl interpreter. It was originally designed to build wrappers around command line C programs that took arguments through its argv structure and the API makes extensive use of this sort of structure to pass data between the tcl interpreter and host application.

What really makes Tcl interesting is that it can do interactive interpeters as well, and it's also a full programming language (albeit not a particularly nice one) so you can implement as much or little of your program in it as you want before you drop out into your native language. Your program can register commands with the interpreter, so it's easy to make domain specific langugages.

Now, before you go Ooooo yuck! C!, there are java and .net analogs to tcl, and other languages with similar capabilities and native integration into those environments. There are also bindings for rust, go, objective-C, object pascal, C++ and any number of other languages.

I would suggest that it's probably easier to build bindings into the tcl interpreter than write your own command shell. The effort for doing this is small enough to fit tutorials into a couple of two hour computer science labs schedule a few days for an assignment, so it really is quite straightforward to do. Ousterhout (the author of tcl) was a prof in an engineering school, so they could teach engineers who weren't necessarily software specialists to do it.

As a bonus, Tcl has a gui toolkit called tk (other languages can use various gui toolkits as well). tk's UI styling is traditionally a bit retro (it was originally designed to look like motif), although on Windows it has a wrapper that uses native widgets.

When you use it in this mode, it's traditional to build the CLI version first, and then build the gui so it essentially dispatches commands into the cli version. You can add primitives into the back end to support the gui as needed. A common way to implement saves on programs like this is to dump your data out as tcl scripts that you can just read back in through the tcl interpreter.

As for redistribution, tcl is pretty amenable to building a binary with the interpreter and external commands statically linked into a single executable, and the baggage is much, much smaller than the runtimes for java or .net. The main caveat here is that (as far as I am aware) it has limited support for mobile platforms such as iOS.

 

[ShawnDriscoll]

I do the reverse. Make a GUI program, then make it work as a command line app.

 

[Leitz]

TCL is a great language but not what you need unless you're doing firewall rules on big Cisco devices. Python gives you a much broader usage base, actual OOP, the ability to call C directly, and TKinter for when you want a TK based GUI.

Seriously, you can make a long and well paying career out of Python; more than TCL or Ruby. Sad, but true.

 

[nobby-w]

TCL is a great language but not what you need unless you're doing firewall rules on big Cisco devices. Python gives you a much broader usage base, actual OOP, the ability to call C directly, and TKinter for when you want a TK based GUI.

One does not simply 'call C directly' from Python. Embedding C code in Python interpreters is a lot more of a faff than it is with Tcl - to the extent that there are multiple tools in circulation to assist with doing it. The C APIs of Python are more like wrapping your code to look like callables, sequences or other python primitive types. In order to do that you have to wrap your code with the whole API of a python language primitive.

There are several reasons why I suggested Tcl instead of python or ruby.

• OP indicates that he wants to make a command line driven program for his application, and his post suggests he wants an interactive CLI. Tcl is designed to do interactive shells as a core language feature. This is one of the reasons it has a sh-like syntax and why Cisco lifted it to embed in their networking kit. While python can do an interactive session, it's not actually designed to be used as a CLI - whereas Tcl is.
  
• Tcl is a lot easier to embed than Python and the APIs for embedding it are much simpler. As I said previously, you can teach folks to make extensions for Tcl in a couple of two hour labs.
  
• The Tcl language interpreter is extensible by registering commands, which makes it easy to build domain-specific languages (q.v. Expect). Again, this is a core language feature of Tcl. While you could do this to some extent with (say) python or ruby, it's much, much easier to do with Tcl, and neither Python or Ruby support language extensions through the APIs on the interpreter. At best, with Python you are wrapping objects in your native system to behave as if they were standard language primitives such as sequences.

Seriously, you can make a long and well paying career out of Python; more than TCL or Ruby. Sad, but true.

As far as I can tell OP hasn't indicated that he's asking for career advice, which makes this (while technically correct) a bit of a straw man argument in the context of OP's stated requirements.

 

[ShawnDriscoll]

One does not simply 'call C directly' from Python. Embedding C code in Python interpreters is a lot more of a faff than it is with Tcl - to the extent that there are multiple tools in circulation to assist with doing it. The C APIs of Python are more like wrapping your code to look like callables, sequences or other python primitive types. In order to do that you have to wrap your code with the whole API of a python language primitive.

A lot of my old Traveller stuff was written in C that I now make calls to from Python. It's how I've extended my Python's use.

 

[nobby-w]

A lot of my old Traveller stuff was written in C that I now make calls to from Python. It's how I've extended my Python's use.

Ahem. I sense someone is only telling half the story here. If it was this straightforward then there wouldn't be 13,572 search results for 'call c from python' on stackoverflow. Either you're using a wrapper such as swig, ctypes of cython or writing a fair amount of boilerplate code to handle the interface.

 

[ShawnDriscoll]

Ahem. I sense someone is only telling half the story here. If it was this straightforward then there wouldn't be 13,572 search results for 'call c from python' on stackoverflow. Either you're using a wrapper such as swig, ctypes of cython or writing a fair amount of boilerplate code to handle the interface.

It's called extending Python with C. Nothing fancy. I use my regular C compiler to recompile my C programs with Python's library. The C programs are then imported into Python as needed. Any good Python book will have a chapter that is specific on the subject. I've posted videos on the YouTubes about it.

 

[robject]

As I understand it, C works handily with Python -- moreso than Perl does, for instance, which apparently is a pain and a half to extend.

 

[ShawnDriscoll]

The trick is, the Python you're using has to be written with the C compiler you are using. All my stuff is classic these days. So MSVC 7.1 (Visual C++ .NET 2003) is the era I am in. If your Python is written in another language or platform, then C will be harder to integrate with.