Fog Creek Software
Discussion Board




How effective really are Scripting Languages?

Few months ago, I was pretty much interested in learning Python. But, I had to stop.

I liked the language. The fact that the language did not provide several ways to do the same thing meant that I could just code and not try to optimize. This made the language slow but equally useful for implementing quick / throw-away scripts.

But, later I realized that a major portion of the API (I wouldn't call it a class library) was a huge mess. Most of it was simply an abstraction over the underlying C and Tcl/Tk functions. I was also unable to find consistency within the API. Somewhere, it demonstrated the cleanliness of the Python language and somewhere it simply hung over the mess of underlying non-object oriented C functions.

When I actually tried writing some useful scripts in Python. It turned out that I could code an equal functionality in C# in lesser lines of code. Of course, .NET's Framework Class Library (FCL) is much more richer than what Python offers.

Joel, I remember your response to a Python-related thread earlier. But, my point is how Python (or any other scripting language) can justify its inconsistency within its API and its slow speed at least in the presence of C# and .NET (let's forget portability, Linux and Open Source for a moment).

Knowledge Seeker
Sunday, April 04, 2004

Well, I have to agree with you, in general... that's sort of what I meant when I alluded to the fact that I already had more general-purpose scripting languages than I needed.

Historically scripting languages had two big reasons to exist:

(1) to provide an embedded language inside an application allowing you to automate that application. Emacs lisp, Word Basic, JavaScript, and even shell programming.
(2) to provide for faster code development by sacrificing runtime performance in exchange for convenience in development through:
  (a) automatic memory management or garbage collection
  (b) late bound, variant data types
  (c) reduced need for formal structure to a program, eliminating even the main() declaration that traditional languages require

The need for #1 has been reduced a bit, although not eliminated through cross-application invocation technologies, especially COM... Although for the most part extensible applications still need to have a built-in scripting languages.

The need for #2 has been reduced a bit because many modern languages include automatic memory management through garbage collection or reference counting, and sometimes late bound data types. This is where languages like Java and the .Net family encroach heavily on the traditional territory of scripting languages.

Unfortunately .Net languages and Java are not quite embeddable enough due to their large footprints, so there's still a big niche for scripting languages as embedded languages.

Joel Spolsky
Fog Creek Software
Monday, April 05, 2004

At the moment I am working with three authoring programs for language teaching computer generated exercises and tests.

The first is a newish program, written in C++ as the apparently sole author proudly points out on his web site.

The second is a long standing program developed by language experts but written by an independent programmer in C or C++.

The third was developed in Javascript by a couple of Australian English lecturers as a hobby.

The third is now the most popular because its freeware, but also because it is, in the opinion of all my non-technical colleagues who have used it and looked at the alternative, by far the easiest program to use.

I have no doubt that this is because it was written by domain experts and not programmers. The great advantage of scripting languages is that they allow non-programmers to program. And of course they end up using the real stuff. The EFL lecturers I referred to earllier have been offering custom work in Delphi for two or three years now.

Stephen Jones
Monday, April 05, 2004

To Joel's list I would add (2)(d), Eliminates "compile" from the "edit-compile-test" loop: http://www.joelonsoftware.com/articles/fog0000000023.html

- former car owner in Queens
Monday, April 05, 2004

""". Most of it was simply an abstraction over the underlying C and Tcl/Tk functions. I was also unable to find consistency within the API. Somewhere, it demonstrated the cleanliness of the Python language and somewhere it simply hung over the mess of underlying non-object oriented C functions."""

That's because for anything that's OS-specific, the Python philosophy is to expose it with as thin a wrapping as possible.  Fewer abstraction layers = fewer leaky abstractions.  Eclipse's SWT GUI framework takes the same approach at a low level: exactly wrap the Windows API in Java, without adding any conveniences or abstractions.  Then, they code the next layer up in Java over the raw Windows API. 

Python's standard library takes the same approach to interfacing with C APIs of most kinds, and leaves fancier abstractions to third-party toolkits.  For example, Python gives you plenty of access to the raw C sockets API, but if you're going to build a sophisticated multiprotocol server you probably want to use the Twisted framework.  Twisted will probably never be part of the standard library, which is good because it keeps the standard library from getting too bloated.  Remember that one of Python's target areas is *embedding* the language into an application, like some of the 3D rendering tools and CASE applications that embed it.

Phillip J. Eby
Monday, April 05, 2004

Joel wrote:

----

(1) to provide an embedded language inside an application allowing you to automate that application. Emacs lisp, Word Basic, JavaScript, and even shell programming.
....
The need for #1 has been reduced a bit, although not eliminated through cross-application invocation technologies, especially COM

----

Presumably .NET offers another option.  With various ways to load assemblies dynamically, or even create them on the fly, I wonder if we may start to see applications where the "embedded langage inside the application" is simply VB.NET (or C#).  I.e. the app, and its scripting environment, are all .NET based.

John Rusk
Monday, April 05, 2004

VB.NET and JScript .NET support the IVsa interfaces for exactly that reason.

Eric Lippert
Monday, April 05, 2004

There's another dimension to scripting languages. They have tended to be interpretted and dynamically typed, and hence have tended to focus on being higher level than C and Java and so on.  A lot of language innovation has gone on in scripting languages such as perl, python and ruby.

According to John K. Ousterhout who made TCL, scripting languages tend to be an order of magnitude more productive too than C: http://home.pacbell.net/ouster/scripting.html - check out the table towards the bottom of article

Matthew Lock
Monday, April 05, 2004

Python is better than C# at handling lists and containers. You do this faster in Python.

Also, you write code faster because you don't have to declare things.


Also, in my opinion Python focuses on a "RAD everywhere" approach.

The traditional RAD tools were RAD only in the sense that you could build an UI quickly.

In Python, RAD is everywhere:

- the language itself is designed so that you code quickly

- the library is designed so that you use it quickly

- the documentation is written so that you read it quickly, understand it quickly, and get on with your work

This surprised me about Python.

I think that if someone wrote a good GUI builder and IDE for Python, that environment would be a lot more productive (a lot more faster to develop with) than Visual C# and Delphi.

Yes, there is BOA Constructor, but it's beta, and crashes a lot.


When MS designed C#, I kept hoping that they would copy features from Python. Instead, they copied from Delphi and Java. :-(

I can understand them - they want to attack the market Java has, so they had to come up with a Java-like language.

Also, they probably needed a language over which they had full control.

MX
Tuesday, April 06, 2004

Here's a Python (+perl, tcl and php) IDE: http://www.activestate.com/Products/Komodo/

Matthew Lock
Tuesday, April 06, 2004

Then don't use the tcl/tk gui library.
Use the wxpython (c++) gui-library.

anonymous
Tuesday, April 06, 2004

Knowledge Seeker, your point may answer why so many people are big fans of jython. Or Python over Java. Again, I am not sure if you derive a lot of value from using jython the way you would using straight python, but it would fix the inconsistent framework problem you talked about because it strips out the underlying python libraries and replace it with Java base classes (and in the case of the future Iron Python for Mono, with Mono or .Net base classes).

Li-fan Chen
Tuesday, April 06, 2004

Regarding scripting in .NET: you don't even have to use the "official" script provider. It's quite simple to compile a VB or C# program at run time, and then load & execute it using reflection. Indeed I see no reason to use a separate scripting language in a .NET program, except if you want to accomodate users of that language.

Chris Nahr
Tuesday, April 06, 2004

I'm new to Python and am curious about its potential for creating windows GUIs.  So far the Python GUI apps I've seen have had a look that said "not native to Microsoft" in mostly subtle ways.  Is it easy or even possible to build a GUI in Python with a slick windows look?  Is it better using TKinter or wxWindows (or something else)?

Ken Klose
Tuesday, April 06, 2004

"Is it better using TKinter or wxWindows (or something else)? "

I prefer wxPython. It can be made to look like Windows, after all, it's just a thin wrapper on top of the native Win32 widgets. But I suspect many authors don't bother putting the finishing touches on.

Tom H
Tuesday, April 06, 2004

Python and Perl have been hobbled by their early use of the (not so great) Tk widget set. I think wxWindows is the way to go today. GTK is good as well, but it doesn't look as "native".

Dan Maas
Tuesday, April 06, 2004

Can't speak for python but perl has a very nice wrapper around win32 http://sourceforge.net/projects/perl-win32-gui

Matthew Lock
Tuesday, April 06, 2004

I started learning python 6 months back, almost 1 year after I am officially working with C#. Coming from a C/C++ background, following are the things I have noticed

- Python programs are faster to develop. but difference is lower compared with C# then with C.
- I wrote something. I need some modifications. Edit script and run it out of the box!
- In most cases, It takes less lines of code maybe, because of no braces, no declarations, no class restrictions etc to get same thing done.
- I don't have to concentrate on design, classes organization etc right from the word go...
- I can read code as easily as I write it (Less lines of code to read anyway!).
- Interpreter always allow me to see results if it matches my expectations while I am coding. I don't have to wait for completing the program so that it compiles, then put a breakpoint to see results.

Though I have used Python when something smaller needs to be done and not done any large projects with it, I am sure it will hold its promise there also.

by the way, I love C#. Whenever I look at class libraries of .NET framework, I tend to love it even more.

Manish Singh
Wednesday, April 07, 2004

For that slick windows look:

venster.sourceforge.net

Grtz.

A beautiful day
Wednesday, April 07, 2004

For 'relatively simple *' scripts a scripting language offers more flexibility
  -  deployment/packaging/installation. Scripts don't require you to package a jar/assembly.
  -  versioning of jars/assemblies - script either works, or it does not work. JAVA/.NET the thing has to load first, then you have to check if it runs.

Of course, as your program grows, and you depend on components (other than the runtime library), a script gets too messy (for perl CPAN is a mess), and one would like to have some more order - here you have .net and friends.
 



* 'relatively simple' - don't know how to define that concept.

Michael Moser
Wednesday, April 07, 2004

What's messy about CPAN?

Matthew Lock
Wednesday, April 07, 2004

If you are targeting a Python app to Windows only, and don't need a cross-platform GUI, you should check into win32all, which is raw Win32 API and MFC-like stuff, as well as COM.

And, Python for .NET will let you access any goodies .NET has to offer as well.

Phillip J. Eby
Wednesday, April 07, 2004

If you put all the scripting languages in the same bag then C# may be better, if you don't mind MS stuff.
I for one don't like the syntax of Python. I perhaps would rather use C# than Python.
But there is Ruby for me! Thank God! (and Matz!).
I don't think that only the system programming languages evolve.

Dewd
Wednesday, April 07, 2004

I am an avid user and proponent of Python. What huge mess? I actually love the simplicity of the standard library and am very productive in it. I suppose it has ideological differences with the Java and C# style of doing things, but it is definitely just as effective at solving problems, if not more. I confess I have no experience in C#, but know Java well.

Actually I belive a bigger difference than the library is the dynamic vs static typing. This percolates into other areas of design and coding, for example a rigid interface based interaction style in Java vs a more flexible 'protocol' based interaction style in Python. Python proponents argue that the cost of static typing is not worth the benefit it offers.

All in all Python ends up being a big win for me (and many others) simply because of its very, very high productivity. This is without sacrificing any scalability (w.r.t. size of code) or robustness.

Why you may not want Python? Python generally runs slower, but the development-time run-time tradeoff exists elsewhere too (Java - C - assembly). Python has much less mindshare in the industry, and so there are fewer developers (harder to hire people) and fewer products and frameworks that use Python.

http://www.pythonology.com/ has some Python success stories.

Shalabh Chaturvedi
Thursday, April 15, 2004

When you talk about APIs, are you talking about the C api to interface it into our application?  If so, then perhaps you might like Boost::Python.  It's a simple wrapper around C++ classes that requires a simple extra declaration per class that you wish to expose in Python.  From that, you can call your C++ objects in Python.  It goes the other way too, but it's a bit more complicated for that.

It's not perfect, but easier than the C APIs calling C++.

Jay Kint
Thursday, April 15, 2004

"Actually I believe a bigger difference than the library is the dynamic vs static typing ... Python proponents argue that the cost of static typing is not worth the benefit it offers"

I am a C# developer but I agree with Shalabh on this point and I agree in lots of cases with Python fans on this argument. Bruce Eckel convinced me:

http://mindview.net/WebLog/log-0052

Josh Chisholm
Friday, April 16, 2004

*  Recent Topics

*  Fog Creek Home