Related
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.
Is there some graphical shell like ghci for Haskell and Linux? I know about Winghci and it is very good interpreter but it is Windows only.
Regarding "what does WinGHCi do that GHCi does not?":
The command prompt, user input and program output are different colours. I can't begin to tell you how helpful this is when you're scrolling through huge pages of text trying to find the last command you typed. I wish more Haskell programs would produce coloured output...
You can load files using an actual GUI, rather than having to memorise a 200-mile long file path.
It has a whole bunch of buttons and menu items for common operations, which can be useful if you're new to GHCi and don't know the corresponding command names.
On Windows, terminal windows look horrifyingly ugly, while WinGHCi does not. Whether this problem exists on Linux is a matter of opinion.
Regarding the actual question asked: I'm not aware of any nice GUI tool for GHCi on Linux. Probably the best you can do is use the Emacs operating system; I'm sure somebody will have built some kind of GHCi support for that by now...
ghci runs fine on Linux, although I don't know of any graphical versions of it.
A few options if you want more features:
Use a powerful terminal emulator
Integrate ghci into your editor with something like 'Emacs Haskell Mode' or 'SHIM for Vim'
Have you heard of HUGS ? I only used it for Windows, but on the website you can download it for some Linux distributions, too.
It's a long time ago since I used it, but as far as I can remember it was an easy to use but powerful and fairly good documented interpreter.
hope this helps
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.
Does anyone have experience using SLIME on the console for Common Lisp? I'm trying to go through Practical Common Lisp but the commands in the book don't seem to work for the console version of emacs/SLIME. I suppose my question is: is there somewhere where I can find documentation specifically for SLIME on the console? Or if you have a suggestion for a completely different approach on the console, I'm all ears.
I assume you mean running slime with emacs on the console ie without X. Slime requires emacs (eq slime 'superior lisp interaction mode for emacs').
I ran it with emacs -nw (which just uses the terminal and no X facilities that I can see) and slime worked fine (Ubuntu 10.04 X86-64).
Are you running in emacs?
Is slime set up in your .emacs file?
Did you start slime via alt-X slim?
Tell us more about what you did and what you have set up and what output you get and we may be able to help more.
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