What is your favorite shell?

With tcl you have the widget toolkit tk, a very comfortable way without much effort and lines of code of writing GUIs.

True but I kinda got burned by dtksh which allowed ksh93 to connect to Motif widgets. After the deprecation of Solaris 10, I had to wait many years to be able to use my old GUI scripts again XD.
At least being open-source tk will be around for many years to come, but I would rather avoid dependencies for my own personal convenience scripts. X11's Xaw provides all I need for a button / textbox for example.
 
bash and ksh for interactive use

sh for simple scripts (lowest common denominator / portability)

C for anything I cannot script (i.e X11). I don't bother with Python, perl, java and all that stuff because I despise pointless bindings and dependencies which can simply be avoided by using C.

Come on, all programmers use heavy advanced programming languages for easy programming.

You cannot use C on Android,... rapid software developments and customer implementations. There is no money there.
 
kpedersen, tk is one of the oldest toolkits, tcl/tk scripts may run on unixoides, Windows and Mac.

Spartrekus, scripting is more expresive: a script (including sh scripts) for example can dynamically write code and interpret it. Sure, a C program can also write a file and with system calls compile and run it, but that is not very elegant, not so expressive, not so readable. One uses C and scripting for different purposes.
 
You cannot use C on Android,... rapid software developments and customer implementations. There is no money there.

Luckily the game industry is one of the last bastions of light where much of the engine work needs to be native C++ (with some C). Thus on Android the Google NDK (or Intel NDK) is king. There is still hope! ;)
 
kpedersen, tk is one of the oldest toolkits, tcl/tk scripts may run on unixoides, Windows and Mac.

Spartrekus, scripting is more expresive: a script (including sh scripts) for example can dynamically write code and interpret it. Sure, a C program can also write a file and with system calls compile and run it, but that is not very elegant, not so expressive, not so readable. One uses C and scripting for different purposes.

1. TK
Precautions with TK. tk is quite complex, it looks to me more like a possible «Vipers' Tangle», «The Knot of Vipers». I likely prefer following solution, better to use C on top of X11. Anyhow both are outdated and will likely no longer exist some day. FLTK??

2. C versus Scripting
Scripting has its own strengths. Too much Scripting can slow down your system heavily. C has its own strengths as well. Both are necessary, actually scripting can be removed fully. Actually C too. "Most modern operating systems are written in C/C++. That's very useful when portability and code-maintainability are crucial, but it adds an extra layer of complexity to the proceedings. " He is very right, there is lot of complexity using Clang or the gcc compilers.
Yeah, assembler would be only what we need. Asm : http://mikeos.sourceforge.net/write-your-own-os.html

Edit:
3. Hope
there is no hope for Android : it .... runs ... ultra ... slow as hell.
 
I prefer the shell with a ghost in it ;)

Otherwise, csh for interactive and sh for the rest.
 
what does it mean?

Crivens is obviously referring to the infamous Ghost Clam series of anime. ;)

5989
 
Too much Scripting can slow down your system heavily.

Why? I run my scripts when I need to run them.

If you like C, you can very easily extend Tcl with C programming. You write the critical parts in C, pack them as new Tcl commands, and the rest of the uncritical things (including the GUI that does not need to be much faster than humans) in Tcl/Tk. This has many advantages.

But even if you write big scripts with Tcl/Tk you get lightweight programs.

The well known sqlite3 database began as tcl extension and has a very nice tcl API. Tcl and sqlite3 work very good together. I got the feeling of how reliable sqlite3 is when I learned about this nice program:

https://www.fossil-scm.org/index.html/doc/trunk/www/index.wiki
 
could be possible. In fact, Lisp always existed. tcl might be good.
Ideally we should use assembler
Ahmmmm NO.
Ideally we should identify the 5% of the code which eat up 60% of the time and tune that code. Find the 1% that has 40% of the time and maybe use assembler for that. What you might gain from using assembler for more than a few very hot spots will be spent in debugging and porting. Also you need to re-tune everything by hand when the silicon changes.
 
Lisp is after FORTRAN the second oldest high level programming language, the elementary part is easy to implement and it is powerful for its purpose. The later extensions are sure an alternative to scripting languages, but the syntax is not very readable. Some people say that LISP means: List of Insipid and Stupid Parenthesis.

Gnu Guile, a Scheme (Lisp dialect) interpreter, was mean as a concurrent to Tcl and is as Tcl also extensible with C programming. But, as far as I know, not much people use Guile, not even GNU emacs, but a lot use Tcl.

Tcl allow also recursive functions and depending on your programming style may seem to Lisp. I personally try to avoid recursiveness.

No, I do not follow Spartrekus with "Ideally we should use assembler". There are many, many reasons why this is not ideal. Crivens mentioned only one. One could also say, ideally we should save all electronic written documents as bitmap (I save my TeX code, not even as ps/PDF).

But the article I quoted (Worse is better) is not about Lisp, or not only about it, and it brings a point against C for everything.
 
Ahmmmm NO.
Ideally we should identify the 5% of the code which eat up 60% of the time and tune that code. Find the 1% that has 40% of the time and maybe use assembler for that. What you might gain from using assembler for more than a few very hot spots will be spent in debugging and porting. Also you need to re-tune everything by hand when the silicon changes.

Assembler allows to spend (lot of) time on a smaller approach, which could gain in efficiency for a given (small) base operating system.
 
One could also say, ideally we should save all electronic written documents as bitmap (I save my TeX code, not even as ps/PDF).
I know of one company where the long term archive for safety relevant stuff (about 30 years storage) ONLY accepts ASCII and PNG. Want to hand in your presentation, .doc or .pdf? Print it out page for page.
 
Crivens, this is perhaps offtopic inside of offtopic thread. :)

I begun to use again FreeBSD because ZFS hails files using redundancy. Although ZFS is bloated for an archiving file system, I think (or hope) it will be there for 30 years: for normal use I preffer ufs. I use magnetic disks, not flash rom, for archiving, but the firmware of the disc is sure flash rom and the whole data goes with it. And are modern magnetic disks or tapes with so dense data reliable? And of course the format of the data must be readable in the future. Archiving is not a simple problem, is not solved, and unfortunately it seems there is no much interest.
 
Crivens, this is perhaps offtopic inside of offtopic thread. :)

I begun to use again FreeBSD because ZFS hails files using redundancy. Although ZFS is bloated for an archiving file system, I think (or hope) it will be there for 30 years: for normal use I preffer ufs. I use magnetic disks, not flash rom, for archiving, but the firmware of the disc is sure flash rom and the whole data goes with it. And are modern magnetic disks or tapes with so dense data reliable? And of course the format of the data must be readable in the future. Archiving is not a simple problem, is not solved, and unfortunately it seems there is no much interest.

It is a consequence of what is today considered as important.
 
Back
Top