I use Vim as my editor. "Practical common Lisp" suggest installing Lispbox, I don't know how to use emacs, don't know how to run lisp code with that T.T after that i find lisp plugin for vim called limp.vim with a long and hard install instruction :((
Finally i installed "Clisp" and i can run lisp code with a simple command:
clisp ~/test.lisp
But how to compile it? Is lisp a compiled language? sorry, i just don't know anything, i'm newbie in lisp
Can anybody tell me what exactly need to install lisp on my linux? What's SLIME, sbcl,.. etc.?
Install and learn the following things:
SBCL the compiler
install a binary from http://www.sbcl.org/platform-table.html Once your used to it, compile from source and keep the source around. This way you can easily jump to the definitions of functions of SBCL with M-. in Emacs.
Emacs
watch this screencast to see someone implementing a raytracer Raytracer in Common Lisp
quicklisp.lisp http://www.quicklisp.org/beta/
This is the new package management. When I started it wasn't there. Now we have it and you should use it. It makes things a lot easier.
Run 'sbcl --load quicklisp.lisp' and then enter (quicklisp-quickstart:install) press enter
and then run (ql:add-to-init-file)
SLIME runs within Emacs.
Try installing it with quicklisp. Read its manual and figure out what to write into your .emacs file so that it automatically starts when you open a lisp file. Optionally watch a screencast.
Paredit
Seriously, you have to learn that (even if the guy in the raytracing screencast didn't use it). You should start with ( , this will make two parenthesis. With M-( you can enclose an existing s-expression. C-k cuts the s-expression behind the cursor and with C-y you can insert it anywhere.
ASDF
This is the make for lisp. You should learn how to define a system in an ASDF file.
Reference
I printed this booklet, Common Lisp Quick Reference. It's very concise.
Lisp can be compiled but that is not "necessarily" so. Clisp is just one Lisp running on Linux. SBCL is another one. And SLIME is the interface from Emacs to one can say all Lisps on Linux.
You can use Slime with SBCL, CLisp, Lispworks and Franz Common Lisp.
You can even learn much of Lisp just by using Emacs. It has it's own Lisp-dialect Elisp, but you can use Common Lisp compatibility libraries also.
Emacs probably is a preferred IDE for Common Lisp because of it's use of an internal Lisp.
If you want one software to install you should check LispWorks or Allegro Common Lisp (formerly Franz Common Lisp).
Can anybody tell me what exactly need to install lisp on my linux?
The other answers have described what SLIME, sbcl etc. are. But I wanted to give a concise answer.
To install clisp on Ubuntu, just run sudo apt-get install clisp. Nothing else is necessary to run Lisp. For other distros find clisp on their relevant package managers. However do not be surprised not to find clisp on some distros, for example the Amazon Linux AMI appears not to have clisp. clisp ~/test.lisp is all you need to run Lisp.
Nowadays it is more popular to use SLIME and ASDF. As a beginner you will not need to use them yet. SLIME is a fancy editor for Lisp, and ASDF is a package manager. It is much easier to setup Clisp given that it literally takes just one line to install and one line to run. SLIME and ASDF are more involved and take more time to learn and setup. I personally would recommend starting off with using Clisp and only later on using SLIME and ASDF so that you will gain a better understanding of Lisp which will make using SLIME and ASDF much easier. When you are ready, then I recommend reading the documentation of SLIME and ASDF.
You can learn lisp using the idioms you're used to from other languages (editing, compiling, running). In the long run, lisp offers other choices, which you may come to prefer.
So long as Vim will balance ()'s as you type, it has the only feature you really need in your editor.
Eventually, you might well choose to look into SLIME (which needs emacs), but it's certainly not necessary to get started.
You can choose any 'Common Lisp' implementation (of which clisp appears to be one you already have). Some will compile to a standalone binary (as you may be used to from C like toolchains), but most will depend on the runtime the lisp comes with, even when the .lisp file is compiled (similar to Java, Python, etc).
You can lookup 'compile-file' in your lisp's documentation to see how to compile .lisp files. Common Lisp's include the compiler in the language runtime.
Related
I'm using Emacs + Typerex for OCaml programming. I have tried OcaIDE before in Windows. It's not as nice as Typerex, but it does have a good feature: Ocaml Browser
Is there anyway to have such a browser in Typerex?
(eclipse + OcaIDE in linux might work, but I do not like it as much as typerex)
Thanks
ocamlbrowser is actually the name of a program that has been distributed with the OCaml compiler for a very long time. It is written with LablTk, maintained by Jacques Garrigue, and was inside the "ocaml distribution" (instead of an external tool) because it accessed .cmi files in ways that rely on internal details of the compiler.
So the short answer is: "yes, just call ocamlbrowser in your terminal" (assuming your distribution packaged ocamlbrowser with the compiler, which may or may not be the case; there may be a separate ocamlbrowser package instead). The look&feel of the tool may be a bit dated compared to a shiny Eclipse version, but it indeed exists and works fine.
Is there a good 'how-to' or 'getting started' guide for getting started using g++ and gdb?
Some background. Decent programmer, but so far I have done everything on Windows in Visual Studio.
I have a little experience using terminal to compile files (not much beyond a .h and 1 or 2 .cpp). But nothing beyond that.
Anyone know of a good primer on on how to get started coding on Linux?
Read some good books, notably Advanced Linux Programming and Advanced Unix Programming. Read also the advanced bash scripting guide and other documentation from Linux Documentation Project
Obviously, install some Linux distribution on your laptop (not in some VM, but on real disk partitions). If you have a debian like distribution, run aptitude build-dep gcc-4.6 gedit on it to get a lot of interesting developers packages.
Learn some command line skills. Learn to use the man command; after installing manpages and manpages-dev packages, type man man (use the space bar to "scroll text", the q key to quit). Read also the intro(2) man page. When you forgot how to use a command like cp try cp --help.
Use a version control system like git, even for one person tiny projects.
Backup your files.
Read several relevant Wikipedia pages on Linux, kernels, syscalls, free software, X11, Posix, Unix
Try hard to use the command line. For instance, try to do everything on the command line for a week or more. Avoid using your desktop, and possibly your mouse. Learn to use emacs.
Read about builder programs like GNU make
Retrieve several free software from their source code (e.g. from sourceforge or freecode or github) and practice building and compiling them. Study their source code
Basic tips to start (if a command is not found, you need to install the package providing it) in command line (in a terminal).
run emacs ; there is a tutorial menu; practice it for half an hour.
edit a helloworld.c program (with a main calling some hello function)
compile it with gcc -g -Wall helloworld.c -o helloworld; improve your code till no warnings are given. Always pass -Wall to gcc or g++ to get almost all warnings.
run it with ./helloworld
debug it with gdb ./helloworld, then
use the help command
use the b main command to add a breakpoint in main and likewise for your hello function.
run it under gdb using r
use bt to get a backtrace
use p to print some variable
use c to continue the execution of the debugged program.
write a tiny Makefile to be able to build your helloworld program using make
learn how to call make (with M-x compile) and gdb (with M-x gdb) from inside Emacs
Learn more about valgrind (to detect most memory leaks). Perhaps consider using Boehm's GC in some of your applications.
You've got a lot of things to learn. I won't give you details, but as someone who's done unix and c/c++ development for a couple decades now I'll try to give you some topics to start with.
My main advice is to start experimenting. Write the most trivial program you can in C or C++ (something that prints "Hello there, world!" is traditional) and figure out how to compile and run it from the command line. Then, once you've got a compiled version, start it up under the debugger and play around with breakpoints, printing expressions, etc, etc. Once you've got this simplest program up and running and you sort of understand what the debugger is telling you, add a class, function, struct, or whatever else feels like a good small step and go through the cycle again. You'll proceed much faster this way than if you start with a very large program.
Still at a very high level, here are a handful of topics you'll need to figure out at least a bit about. Note that the "learn by starting small" approach works well for any of the topics below.
Running g++: it has pretty good online documentation for the command line syntax, and although you're bound to find it intimidating at first, try to look for the simplest starting point.
Find a text editor to use. Vim and emacs are traditional (and very very powerful) but both have a relatively steep learning curve. If you have someone around to help you, that's so much the better. There are other alternatives, but as an emacs user myself, I'm afraid I'm not that familiar with them.
Get familiar with gdb. It's an incredibly powerful tool for understanding your program. Again, it has extensive online documentation that will repay close reading.
Some familiarity with standard unix commands will be useful: ls, cd, and moving basics of the navigating unix directories; grep for quickly searching source files.
You'll have to get used to the command line approach versus the ide approach. The former is the traditional unix developer model, where you put together the operations you want from a collection of other tools, rather than having the ide hide most of this knowledge from you.
If your project is multi-file, and especially if it's a full-semester project, you might also consider learning something about the following topics.
Make is a tool for describing how to compile and link a multi-file project so that you don't have to remember how to do it by hand each time. Make, unfortunately, has a well-deserved reputation for being tricky to use, but this is mostly true in very large projects spanning multiple directories, and there are probably good simple examples online.
I would strongly consider making use of a source code control system such as git or hg, even for a few relatively small project. It's so much safer to have an archived version of what you've done so that you can back up quickly. Both git and hg are overkill for a small one-shot project, but they are worth learning on their own. Conventional wisdom as I understand it today is that they're very similar in philosophy and core functionality, but that hg is definitely a bit more consistent at the command line level, and therefore easier to start with.
I suspect this is rather intimidating, especially if you've got effectively no exposure to a unix command environment before. I re-emphasize my first piece of advice above: learn by starting simple and experimenting. This minimizes the amount of new stuff you're having to wrap your head around at any given point in time.
I've taken the plunge and installed Linux (Linux Mint 9 if that's important) on one of the boxes - and I'd like to start some small-time programming... but where to start.
My background:
Mostly LOB-applications in C#/WPF
Some XAL-basic
A wee bit of VB/VBA and SilverLight
I would like to turn to a new programming language - but still focused on desktop applications.
What I need:
An editor - preferably with good intellisense
A programming languages and the resources to get started
If anyone can point me in the right direction, I'd be happy for a little push...
EDIT:
Thanks for all the advice - I've come up with the following:
I'll start out with Python - and use Vim for the editor
I'll definetly try out Vala and Perl later and have MonoDevelop as backup editor - and if all else fails, I'll turn to C++. I've upvoted all answers as they all helped me.
EDIT2:
Okay - Vim was a bit too hardcore... Installed Cream on top.
Unlike the Windows world, where everything is designed to be Windows-only, I think it is quite typical to find that the rest of the world designs software to specifications, not to implementations. If you are developing in Java, then it doesn't matter what platform you intend to use, and Eclipse and NetBeans provide excellent tooling for Java on all platforms, Linux included. If you are developing in C++, then Boost and Qt provide excellent cross-platform support. If you need to go outside of Boost or Qt, then before delving into Linux-specific features, it is best to target the Single UNIX Specification also known as IEEE Std. 1003.1 POSIX, which will ensure that your application not only runs on Linux, but also on any UNIX-compliant operating system (including Mac OS X, FreeBSD, Solaris, and others).
As for IDEs and other editors... I think most programmers on UNIX platforms build from the commandline (using CMake, Make, scons, or some other standard build tool); however, there are plenty of IDEs with support for those that can run such tools automatically. Anjuta C++ and KDevelop are probably the easiest IDEs to use on Linux. Emacs (emacs, emacs-gtk, xemacs) and Vim (vim, gvim) provide a great deal of power and flexibility, but take a little bit more time to get used to. You might also want to consider a basic text editor such as GEdit (Gnome) or Kate (KDE); GEdit, though billed as a simple text editor, supports some more advanced coding features via a number of plugins. I don't recall whether it supports autocompletion, but it does support line numbers, automatic indenting, using spaces instead of tabs, commenting a block of code en-masse, and executing a Makefile with a shortcut.
Depends on how much you want to learn (from the easiest option to the hardest one):
Just use C# via Mono - that gives you access to most of the POSIX interfaces via Mono.UNIX, access to GTK# so you can do desktop apps, access to many linux libraries, so you can do more advanced stuff / integrate better. (you can program in Monodevelop - it's a Sharpdevelop clone, kind of VS-ish)
Learn Vala - it's a language compiled down to C, very similar to C# but closer to the bare minimum. It's gathers anti-MS people who wanted a response to C# IMHO. (never really used it, but apparently there's a Vala plugin for Monodevelop and the language itself is becoming more popular)
Learn Python - it's a scripting language. It's got bindings to most popular libraries (also GTK and QT) (IDE: anything that can edit text - you won't get good intellisense from a dynamic language anyways)
Learn C++ and QT, or C and GTK - although those are very low level languages where you will spend a lot of time just getting used to the environment. (IDE: Anjuta, Kdevelop, Monodevelop with C++ plugin, Eclipse+CDT, emacs, vim, etc. - anything goes really)
If you want "something new", but don't want to spend loads of time learning a completely new environment, I'd recommend trying out Vala. If you're more curious about different styles, go for Python, which I think has a very good tutorial for new people (but not new to programming): Tutorial or Beginner's Guide. With Python you also have an advantage of having the whole environment available in packages in any distribution, no such luck with Vala (yet).
Try perl and python and see what appeals to you. Learn bash to get around happily at the command-line. If you're feeling adventurous, give C/C++ a shot.
As for editors, this will probably spark up a holy war, but if you're using at the command line, check out vim and emacs, pick one, and lament never making friends of those in the "enemy camp." :-)
I say Python + Emacs or gEdit (what ever suits you)
Linux Mint is a KDE environment, right? That would make it pretty convenient for you to get started writing KDE apps in C++. The Qt toolkit which KDE is based on is widely considered to be relatively developer-friendly, which should make it easy for you to get started.
If you want to go on that route, I'd suggest downloading KDevelop, which is KDE's IDE (optimized for developing KDE programs, but it can handle several different languages). Alternatively, you could use Eclipse, which has C++ capability. You can find tutorials on how to develop KDE apps at http://techbase.kde.org/Development/Tutorials. (Unfortunately I think those are not as good as the documentation they used to have before KDE 4 came out, but it should be enough to get you started.)
EDIT: Come to think of it, you may want to try your hand at writing some C++ console (non-GUI) applications first, since it's probably easier to get comfortable with basic C++ before you jump into GUI programming. Given your experience, it shouldn't be too hard to pick up. Unfortunately I don't know of any particularly good resources to learn C++ with, but I'm sure that information is somewhere on this site, and KDevelop or Eclipse would work fine as an IDE for simple C++ console apps as well.
Weird that nobody suggested ALP, even if it is a bit outdated, it teached me a lot of things regarding the UNIX way of programming.
First, Learning C is a MUST!
Perl is underused for most stuff and you'll want to learn BASH Shell Scripting instead.
Grock the C code of existing (stable, well-written software) example is the Linux kernel itself! Google "Linux LXR"
Once you learn the basics to C (in Linux) the manpages are an invaluable resource. Just do man printf for information on writing characters to the screen, for example.
If you are talking GRAPHICAL GUI Programs, you need to learn GTK+ or one of the many cross-platform GUI toolkits (e.g. wxWidgets). Do not learn to program the X Windows System directly unless you are crazy.
For text editors, I like Komodo Edit and SciTE.
Is there a programming language which can be programmed entirely in interactive mode, without needing to write files which are interpreted or compiled. Think maybe something like IRB for Ruby, but a system which is designed to let you write the whole program from the command line.
I assume you are looking for something similar to how BASIC used to work (boot up to a BASIC prompt and start coding).
IPython allows you to do this quite intuitively. Unix shells such as Bash use the same concept, but you cannot re-use and save your work nearly as intuitively as with IPython. Python is also a far better general-purpose language.
Edit: I was going to type up some examples and provide some links, but the IPython interactive tutorial seems to do this a lot better than I could. Good starting points for what you are looking for are the sections on source code handling tips and lightweight version control. Note this tutorial doesn't spell out how to do everything you are looking for precisely, but it does provide a jumping off point to understand the interactive features on the IPython shell.
Also take a look at the IPython "magic" reference, as it provides a lot of utilities that do things specific to what you want to do, and allows you to easily define your own. This is very "meta", but the example that shows how to create an IPython magic function is probably the most concise example of a "complete application" built in IPython.
Smalltalk can be programmed entirely interactively, but I wouldn't call the smalltalk prompt a "command line". Most lisp environments are like this as well. Also postscript (as in printers) if memory serves.
Are you saying that you want to write a program while never seeing more code than what fits in the scrollback buffer of your command window?
There's always lisp, the original alternative to Smalltalk with this characteristic.
The only way to avoid writing any files is to move completely to a running interactive environment. When you program this way (that is, interactively such as in IRB or F# interactive), how do you distribute your programs? When you exit IRB or F# interactive console, you lose all code you interactively wrote.
Smalltalk (see modern implementation such as Squeak) solves this and I'm not aware of any other environment where you could fully avoid files. The solution is that you distribute an image of running environment (which includes your interactively created program). In Smalltalk, these are called images.
Any unix shell conforms to your question. This goes from bash, sh, csh, ksh to tclsh for TCL or wish for TK GUI writing.
As already mentioned, Python has a few good interactive shells, I would recommend bpython for starters instead of ipython, the advantage of bpython here is the support for autocompletion and help dialogs to help you know what arguments the function accepts or what it does (if it has docstrings).
Screenshots: http://bpython-interpreter.org/screenshots/
This is really a question about implementations, not languages, but
Smalltalk (try out the Squeak version) keeps all your work in an "interactive workspace", but it is graphical and not oriented toward the command line.
APL, which was first deployed on IBM 360 and 370 systems, was entirely interactive, using a command line on a modified IBM Selectric typewriter! Your APL functions were kept in a "workspace" which did not at all resemble an ordinary file.
Many, many language implementations come with pure command-line interactive interpreters, like say Standard ML of New Jersey, but because they don't offer any sort of persistent namespace (i.e., when you exit the program, all your work is lost), I don't think they should really count.
Interestingly, the prime movers behind Smalltalk and APL (Kay and Iverson respectively) both won Turing Awards. (Iverson got his Turing award after being denied tenure at Harvard.)
TCL can be programmed entirely interactivly, and you can cetainly define new tcl procs (or redefine existing ones) without saving to a file.
Of course if you are developing and entire application at some point you do want to save to a file, else you lose everything. Using TCLs introspective abilities its relatively easy to dump some or all of the current interpreter state into a tcl file (I've written a proc to make this easier before, however mostly I would just develop in the file in the first place, and have a function in the application to resources itself if its source changes).
Not sure about that, but this system is impressively interactive: http://rigsomelight.com/2014/05/01/interactive-programming-flappy-bird-clojurescript.html
Most variations of Lisp make it easy to save your interactive work product as program files, since code is just data.
Charles Simonyi's Intentional Programming concept might be part way there, too, but it's not like you can go and buy that yet. The Intentional Workbench project may be worth exploring.
Many Forths can be used like this.
Someone already mentioned Forth but I would like to elaborate a bit on the history of Forth. Traditionally, Forth is a programming language which is it's own operating system. The traditional Forth saves the program directly onto disk sectors without using a "real" filesystem. It could afford to do that because it didn't ran directly on the CPU without an operating system so it didn't need to play nice.
Indeed, some implementations have Forth as not only the operating system but also the CPU (a lot of more modern stack based CPUs are in fact designed as Forth machines).
In the original implementation of Forth, code is always compiled each time a line is entered and saved on disk. This is feasible because Forth is very easy to compile. You just start the interpreter, play around with Forth defining functions as necessary then simply quit the interpreter. The next time you start the interpreter again all your previous functions are still there. Of course, not all modern implementations of Forth works this way.
Clojure
It's a functional Lisp on the JVM. You can connect to a REPL server called nREPL, and from there you can start writing code in a text file and loading it up interactively as you go.
Clojure gives you something akin to interactive unit testing.
I think Clojure is more interactive then other Lisps because of it's strong emphasis of the functional paradigm. It's easier to hot-swap functions when they are pure.
The best way to try it out is here: http://web.clojurerepl.com/
ELM
ELM is probably the most interactive you can get that I know of. It's a very pure functional language with syntax close to Haskell. What makes it special is that it's designed around a reactive model that allows hot-swapping(modifying running code(functions or values)) of code. The reactive bit makes it that whenever you change one thing, everything is re-evaluated.
Now ELM is compiled to HTML-CSS-JavaScript. So you won't be able to use it for everything.
ELM gives you something akin to interactive integration testing.
The best way to try it out is here: http://elm-lang.org/try
I've been using Lisp on and off for a while but I'm starting to get more serious about doing some "real" work in Lisp. I'm a huge Vim fan and was wondering how I can be most productive using Vim as my editor for Lisp development. Plugins, work flow suggestions, etc. are all welcome.
Please don't say "use emacs" as I've already ramped up on Vim and I'm really enjoying it as an editor.
Limp aims to be a fully featured Common Lisp IDE for Vim. It defaults to SBCL, but can be changed to support most other implementations by replacing "sbcl" for your favourite lisp, in the file /usr/local/limp/latest/bin/lisp.sh
When discussing Lisp these days, it is commonly assumed to be Common Lisp, the language standardized by ANSI X3J13 (see the HyperSpec, and Practical Common Lisp for a good textbook) with implementations such as GNU Clisp, SBCL, CMUCL, AllegroCL, and many others.
Back to Limp. There are other solutions that are more light-weight, or try to do other things, but I believe in providing an environment that gives you things like bracket matching, highlighting, documentation lookup, i.e. making it a turn-key solution as much as possible.
In the Limp repository you'll find some of the previous work of the SlimVim project, namely the ECL (Embeddable Common Lisp) interface, merged with later releases (7.1); Simon has also made patches to 7.2 available yet to be merged. The ECL interface is documented in if_ecl.txt.
Short-term work is to do said merging with 7.2 and submit a patch to vim_dev to get it merged into the official Vim tree.
Which leads us to the long-term plans: having Lisp directly in Vim will make it convenient to start working on a SWANK front-end (the part of SLIME that runs in your Lisp, with slime.el being the part that runs in the editor - the frontend).
And somewhere in between, it is likely that all of Limp will be rewritten in Common Lisp using the ECL interface, making Limp easier to maintain (VimScript isn't my favourite) and being easier for users to customize.
The official Limp site goes down from time to time, but as pointed out, the download at Vim.org should always work, and the support groups limp-devel and limp-user are hosted with Google Groups. Don't hesitate to join if you feel you need a question answered, or perhaps even want to join in on development. Most of the discussion takes place on the limp-devel list. If you're into IRC, I'm in #limp on irc.freenode.net as 'tic'.
Good luck!
You might give slimv a break.
Here's a cool diagram by Xach that sums up the current situation.
Here we are 9 years later, and now we have Vim 8 and Neovim, both providing the ability to interact with plugins asynchronously.
vlime is an excellent, feature-rich plugin that takes advantage of the new async interface to provide a SLIME-like dev environment for Common Lisp.
Check out the Limp plug-in:
http://www.vim.org/scripts/script.php?script_id=2219
SLIME for EMACS is a wonderful tool for LISP programming. The best part is sending code written in your editor straight to a live LISP session. You can get similar behavior out of Vim using the tips here:
http://technotales.wordpress.com/2007/10/03/like-slime-for-vim/
I adjusted my own script so that I can send to either a SBCL or Clojure session. It makes you much more productive and takes advantage of the REPL.
":set lisp" starts the lisp indentation mode for Vim. But it won't work with some dialects like Clojure. For Clojure, use VimClojure.
Some people like LIMP also.
:set lisp
Vim has a mode to help you indent your code by Lisp standards.
Also, I modify the lispwords to change how vim indents my code.
:setl lw-=if (in ~/.vim/ftplugin/lisp.vim)
You can give Emacs with Vim emulation a try, is not perfect, but it may be somewhat familiar. I think Lisp shines if you use something like Slime or DrScheme doing iterative development, all other editors feel just wrong.
Vim add-ons: Rainbow Parentheses, Lisp syntax
SBCL add-ons: rlwrap, sb-aclrepl
Workflow: Ion3 (or some other tiled WM) with multiple terminal windows.
Edit Lisp in Vim
Switch to Lisp window (using the keyboard of course)
Use C-r to recall the line to reload the ASDF system in question so your changes become active.
Use X Window copy/paste for small snippets/changes.
Use DESCRIBE, TRACE and APROPOS heavily.
Repeat.
There seem to have been attempts at having a SLIME-like integration of Lisp in Vim, but none have really gone as far as needed to be really useful. I think ECL's integration has been done, though, but not committed upstream.
You should find all relevant links from Cliki's page about Vim.
I know you said not to tell you to use Emacs.
Use Emacs.
Serious, the SLIME setup for Emacs is pretty much the standard development platform for Lisp, and for very good reason.