Dynamic languages are high-level, dynamically typed open source languages. These languages, designed to solve the problems that programmers of all abilities face in building and integrating heterogeneous systems, have proven themselves both despite and thanks to their independence from corporate platform strategies, relying instead on grassroots development and support. Ideally suited to building loosely coupled systems that adapt to changing requirements, they form the foundation of myriad programming projects, from the birth of the web to tomorrow’s challenges.
Dynamic Languages are the Future
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSAlert.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
One of the best things that could happen for Python would be for Python 2.5 or 2.6 to be built on top of Parrot. The speed improvement would probably be just tremendous, and it would lead the way for people to begin writing some very serious software in Python and Perl 6. Parrot could easily be the foundation of an open source alternative to ASP.NET and JSP.
While the definition of “high-level” is totally subjective, Obj-C certainly qualifies as both dynamically typed and open source. Given the attitude towards C in the article, I would assume the author would not include Obj-C in his list of “dynamic languages,” but it certainly seems to qualify based on his criteria.
Maybe “high-level, dynamically typed, open source and slow” is more what he like meant.
I know what parrot is, but I’m not sure how this would help python.. maybe someone could answer some questions?
Parrot is basically a virtual machine that runs bytecode; which means you have to compile whatever code you have to run on parrot’s virtual machine. Much of the code you run in Python ends up being C code (many __builtins__, and of course any C-wrapped library which brings me to…)
How will library wrapping and compiling for parrot work? How is it going to work with other languages?
Activestate…activestate…aren’t they big with Perl?
I didn’t read it, as I would likely agree that these scripting languages will likely take over where compiled languages had once ruled, although never everywhere.
Some of us just still love our glorified assembler!
And some of us like statically typed languages in certain situations. I’d like the compiler (or the runtime… whatever…) to tell me that my program has a flaw before I find out the hard way!
While their article seems to minimize Ruby by saying it isn’t very popular, Ruby actually seems to be gaining popularity recently, especially with the release of Rails (a web applications framework written in Ruby, see: http://www.rubyonrails.org/ )
Rails has gotten lots of favorable reviews from people who have never used Ruby (but now are using it because of Rails).
I couldn’t agree more. Objective-C hasn’t yet gotten its due, despite its use in MacOS X. I wonder if Apple inadvertently hurt Obj-C by not using it to write MacOS X device drivers.
Instead, they used a restricted subset of C++ for the I/O kit
that disallows the use of exceptions, multiple inheritance, templates and runtime type information.
Perhaps, it would have been better for them to have used Obj-C for the I/O kit and written a informational document for C/C++
programmers. After all, if you are experienced in C/C++ how hard can learning Obj-C be?
It’s really all information.
The questions you see across platforms boil down to what information was known, when, and where we want to do the work.
Attempts to come up with taxonomies and terminology seem more driven by the marketing and legal departments than the propeller heads, near I can tell.
“Dynamic languages are high-level, dynamically typed open source languages” is a completely inaccurate statement. Dynamic languages do not have to be open source.
“…proven themselves both despite and thanks to their independence from corporate platform strategies, relying instead on grassroots development and support” is a completely inaccurate statement – the grandaddy of all dynamic languages is Lisp, which has extensive corporate backing (see Franz, Xanalys, several other vendors).
Get your information straight if you want to be taken seriously.
Was this supposed to be a ‘news item’ (the article it links to is dated 2004-07-27, hence two months old) or was it supposed to be a ‘forum item’?
Or to be precise, where’s the implied article (no, not ActiveState’s, Sanjaya’s!)?
I don’t get it. How can implementing Python inside a VM, rather than implementing it in whatever native CPU instructions the current computer uses, magically gain you more speed? Can someone explain?
Some languages have been built for the here and now. We don’t want to run a marathon just to deserve to drink a glass of water. We want to drink glasses and glasses of water whenever we feel like. Other languages, you first ask for permission to get the glass of water, then you run a marathon to deserve it, and finally you can drink it!
No wonder some people look so dehydrated.
Interesting that they left out the granddaddy of all dynamic languages, Lisp. Unlike most other dynamic languages, Lisp has the benefit of an ANSI standard and several implementations – from the lightweight, bytecode-compiled clisp, to the native compiled Steel Bank Common Lisp (which is competitive with C++ in performance). In addition, there are several proprietary implementations with commercial support. Scheme is also a good choice for those looking for a lighter-weight dynamic language.
If you want to learn a high level dynamic language that actually lets you experience the full power of “high level”, there aren’t many choices out there. Python does not have full closures, which means that many advanced higher-order techniques can’t be used. Perl’s reference counter has problems with circular references, which makes using interesting data structures difficult. Common Lisp and Scheme, on the other hand, are production-ready environments with many good implementations and libraries for doing everything from web applicatios to embedded logic programming.
But they state:
“There is a category of programming languages which share the properties of being high-level, dynamically typed and open source.”
And I’m afraid Lisp has lots of commercial support to make it competitive.
Brian has it right.
Why use languages that are just trying to be Lisp when you can really use Lisp. Honestly, the parenthesis are *NO BIG DEAL*. Get over it and use Lisp.
For instance, seee: http://www.findinglisp.com
Parrot is most likely years off from production use and by that time Mono/.NET or maybe even Java’s virtual machine will have surpassed any design advantages that Parrot might have had for dynamic languages. CLR 2.0 will have closures/lambdas and IronPython is already running on top of .NET/Mono current with a decent (1.7x) speedup.
It seems that the trend is to re-implement established ideas from long-available languages in new ones. I don’t know why programming, more so than any other discipline, loves to re-invent the wheel.
I’ve been playing around with Lua lately (www.lua.org). It’s very lightweight (I think the stripped version of the runtime, compiler and libraries will come in at about 100k), has lisp-like features, and will most likely build for any platform that has an ANSI compiler.
They didn’t mention Lisp because they don’t work with it. Astonishing that a company that does work with dynamic languages would tout them as the “future of programming”? Not hardly. Sad that Eugenia would post such an obvious press release as “news”? Maybe, but not surprising.
If what you mean by Python not having full closures is that the lambda functions are limited to an expression, then check out Lua (www.lua.org). I don’t think Lua has that limitation.
uhhh…should’ve been that Lua will build for any platform that has an ANSI C compiler.
NT
Lumbergh: a closure also contains scope. An example:
(define (make-addn n)
(lambda (x) (+ x n)))
This defines a function make-addn, which returns a closure. The closure, when called, returns the sum of its argument and the value that was passed to make-addn. E.g.:
(define add5 (make-addn 5))
(add5 4) ; returns 9
(define add6 (make-addn 6))
(add6 4) ; returns 10
(add5 3) ; returns 8
These examples are in Scheme, but Common Lisp has closures too, and so does Ruby.
HTH
Lisp has a totally inadequate standard library by modern standards (that is, the standards set by Java and Python). For example, neither sockets nor threads can be manipulated in a standard way across all conformant Common Lisps. This pretty much kills the Lisp language’s considerable advantages right off the bat, because it makes the construction and distribution of reusable libraries very difficult.
Another problem is that the production-quality open source Lisps (such as CMUCL) tend not to run on Windows. Most business software developers can’t afford to forego portability to Windows (witness the ability of open source database engines that run on Windows and *nix to surpass PostgreSQL’s popularity by a mile). For that matter, relational database access (the bread and butter of business programming) from Lisp is a mess, with no standard API and a very limited set of available libraries.
Also, the Lisp community is populated in no small part by arrogant people more interested in trumpeting their language’s superiority (and by extension, their own) than in delivering a set of tools that can compete with the best put forth by the object-oriented camp.
I agree that the Lisp *language* is superior, but the tool and library support are sorely lacking, and there’s no sign that these devastating limitations will be overcome, because Lisp is unpopular.
Yes, I realize that closures have lexical scoping. I know Lua has this, but I thought the reason why Brian considered Python to not have full closures is because Python’s lambda functions can only be simple expressions. Is there another reason why Python doesn’t have full closures?
CTRL + F -> “REBOL” – nothing? How comes? It has some very good remarks, but for e.g. what does the dynamic nature of a language have in common with being open-sourced?
Back to rebol now …
-pekr-
You can’t manipulate variables in your lexical scope in Python. This makes it very difficult to use Python closures for e.g. generators, where it’s handy to use a lexical variable to keep the previous state (and then manipulate it when generating a new answer).
Anon makes several very good points about Lisp; however, it’s important to note that you don’t need to target every Common Lisp. Also, CL is very good about read-time conditionalization, which allows you to write simple wrapper routines for e.g. sockets. You should look at Araneida (http://www.cliki.net/Araneida), a simple web server that runs on virtually every Common Lisp, and uses threads when they are available.
As far as Lisp not being popular – there are many free implementations of Common Lisp under active development. We certainly have enough developers to support these multiple efforts, and all of them are making good progress (not just bug fixes). Clisp and Armed Bear Common Lisp (a new CL for the JVM) both run on Windows, and ports of CMU and SBCL are underway (Windows-using developers are encouraged to contribute).
For database access, I would recommend the excellent cross-implementation CL-SQL library. I think it solves the problems you describe quite well.
I think your impression of the Lisp community is based on forums like the usenet group comp.lang.lisp, which admittedly is a cesspool. There is a young and dynamic lisp community centered around IRC, the CLiki site, and implementation mailing lisps that has no such problems and certainly spends quite a bit of time on their implementations. I would encourage you to visit freenode #lisp if you want to see the real nature of open source lisp development.
And for your reference: Common Lisp is part of the object-oriented camp. It was the first ANSI standard object-oriented language.
Ok, thanks for the clarification.
Apparently Lua does not have the limitation of not being able to manipulate the lexical scope variable and it’s also not limited to simple expressions.
I don’t find it surprising that ActiveState would talk very little about Ruby. In talking to AS representatives in the past, they’ve looked at Ruby, but they’re clearly banking on Perl, Python and Tcl.
I was a bit disappointed by the response, seeing it as rather close-minded for a company whose bread and butter is open source, where rapid changes in which language and platform is in favor can and do occur. I guess that’s business, though.
Neither Lua nor Ruby have the limitations I described for Perl and Python. I don’t know much about Lua, other than that it seems to be used fairly heavily for game engine scripting. My impression of Ruby is that it’s a well-thought-out and slightly quirky language, and it’s exciting to see it catching on. I’m still addicted to Lisp (and especially Lisp macros), but I’d choose Ruby over Python or Perl in a heartbeat.
What kind of dumb definition of “dynamic language” are they using? Being open-source is a qualification for being dynamic? WTF?
In any case, I’m impressed with the Lisp-love in here
One thing I’d like to point out (this is somewhat motivated by captrb’s comment), is that unlike most of the more recent dynamic languages (Ruby, Python, etc), older dynamic languages like Lisp and Dylan allow type declarations. That way, the programmer can add type declarations as necessary to either improve performance (when the compiler can’t infer the type), or to make assertions about what types a given piece of code expects.
Ruby actually seems to be gaining popularity recently, especially with the release of Rails
I’ve been hearing lots good things about Rails. Ruby itself is just pure joy. It’s great that we’re starting to see some actual paying Ruby jobs listed recently ( like these: http://robotcoop.com/jobs ). Those of us who snuck Ruby in the backdoor a few years back are starting to see that sneakiness pay off: first our co-workers got to liking Ruby and now management is starting to accept it and this is leading to paying Ruby jobs.
I don’t find it surprising that ActiveState would talk very little about Ruby. In talking to AS representatives in the past, they’ve looked at Ruby, but they’re clearly banking on Perl, Python and Tcl.
Back in 2001 I recall that AS was considering hiring a Ruby developer, so at that time they were considering Ruby support. But then the bubble burst and they couldn’t afford to hire more people. Maybe now that the economy seems to be improving they’ll reconsider.
I was a bit disappointed by the response, seeing it as rather close-minded for a company whose bread and butter is open source, where rapid changes in which language and platform is in favor can and do occur.
I would tend to think that at this point there are more people actively using Ruby than TCL (which is a language they support). Certainly the trend with Ruby is in the right direction vs. TCL. (I’ve had to work on some legacy TCL code lately, and as far as I’m concerned, TCL should be shot and put out of our misery. I’m sure it was great in it’s day, but now that there are much better alternatives, that day is long over )
(I’ve had to work on some legacy TCL code lately, and as far as I’m concerned, TCL should be shot and put out of our misery. I’m sure it was great in it’s day, but now that there are much better alternatives, that day is long over )
Considering that the de-facto GUI toolkit for most scripting languages, Tk, is in fact a Tcl extension, I’m a bit puzzled by this statement. I decided to learn Tcl as my main scripting language because I’m mainly interested in GUI programming and didn’t see much point in learning two languages to accomplish the same thing (Perl/Tk, Python/Tkinter, Ruby/Tk); I thought this would make me productive more quickly, and that’s proving to be the case.
I’m not knocking the other languages. I’ve done a little bit with Python, and it’s a nice language. And Python + wxPython is a very slick combination; wx is a much more sophisticated (and complex) GUI framework than Tk. But I’m finding Tcl to be relatively easy to learn; it’s lightweight but very powerful in its libraries. Tk is a very solid GUI toolkit, particularly if you use the new Tile theming extension (makes Tk apps look native on WinXP and OS X). And with deployment technologies like starkits and starpacks (wrapping the interpreter and all scripts to a single executable), Tcl apps are very easy to install and remove.
So, despite being unfashionable, I think Tcl has a lot to offer.
rainer, you miss the point the author of that paper makes.
He’s not saying “a dynamic language is one that has not strong static typing”.
He’s saying “I define a dynamic language as one that has the charcateristics ActiveState’s supported languages have”.
This is why SmallTalk and Lisp are not there.
You’re just being diverted from the marketspeak, he could have said ‘open source scripting languages’ but that would have been much less sellable.
OTOH I even think there is a major difference beetwen this so called dynamic languages and Lisp/ST.
They have a focus on getting the job done that is missing in the others. I recall a recent thread on lambda-the-ultimate.org about this. Many of the writers where thinking on the lines of “I love haskell, I really like scheme, I script in perl”
My problem with the statement is that “dynamic language” already has a pretty well-specified meaning in programming language lingo. You can’t just redefine a well-accepted term to fit your particular marketing purposes. Well, I suppose you can, but you shouldn’t.
Tk is a venerable GUI toolkit. I must admit I do like Tk’s Canvas widget – I haven’t found anything equivilent in the newer GUI toolkits I’ve tried. That said, though, from my perspective TCL as a language just sucks! (of couse that’s my opinion, YMMV) The need for ‘set’ is an obvious first target of dislike: I really don’t like having to say “set variable value” instead of “variable = value”. I’ve run into several other frustrations as I’ve had to use TCL recently. One that comes to mind is that you can add a value to a list, but there wasn’t any built-in way to pop or shift the value off the list (if there is a way, I couldn’t find it in the book I was using, nor could our TCL programmer tell me of a built-in way of doing it). The whole language just feels so ’80s’ (and of course it was designed in the ’80s). Like I said, I’m sure it was great at the time…
Maybe I’ve just been spoiled by Ruby where a task like looking for the string “Failed” in all files with a ‘.rep’ extension looks like:
repfiles = Dir[“*.rep”]
repfiles.each {|file|
puts “Looking in file: #{file}”
File.foreach(file){|line|
puts line if line =~ /Failed/
}
}
(OK, how come they don’t have pre or code tags available here?)
Or where I can just use push and pop on an Array to add remove items, etc…
As for learing something like Ruby/Tk – I really don’t think you need to know much if any TCL to use Tk with Ruby. And as you mention WxWidgets is a nice toolkit and there is a WxRuby available as well.
ruby’s been around since 1994. i don’t think you can call a language that old UP and coming. groovy and prothon are “no name languages” that are brand new. ruby’s been around for quite awhile. this author is very uninformed.
ruby’s been around since 1994. i don’t think you can call a language that old UP and coming
First off, I believe I said or implied that Ruby’s popularity is rising – what does the age of the language have to do with popularity? Lisp is a much older language, but it occassionally experiences upsurges in interest and is still popular in some circles. Similar for Smalltalk.
Given that Ruby doesn’t have the marketing budget of a Sun (in the case of Java) or M$ (in the case of C#) behind it, it doesn’t seem odd that it’s taken nearly 10 years for Ruby to gain traction.
Perl was created in the late 80’s (’87 or ’88, I believe) and it became very popular in the mid-90’s. Python was created around 1990 and it was probably ’98 or ’99 before it really gained traction.
I’m with you on that, Petr! Rebol is a very nice languange indeed. I’ve been learning and putting it to a little use, and it’s been a lot of fun.
It may not be open source, but it works on so many platforms that it hardly matters.
Here’s another version of the Ruby code another posted a few posts up:
Dir.glob(“*.rep”).each do |file|
puts “Looking in #{file}”
puts File.new(file).readlines.grep(/Failed/)
end
Reason why people love to code in Ruby’s ‘cos it’s so natural, and cuts out any unncessary clutter, and still maintains excellent readability. More verbose code does not mean better readiability. Try doing the above in Java and you’ll see the Ruby code’s a lot more understandable.
To the earlier posters, I can see why Obj-C is not quite the same as other high level dynamic languages. Yes it’s dynamic, but one of the appealing factor of high level dynamic languages is quick development time, and automatic memory management is essential to that. Obj-C does not do auto memory management like Ruby, Perl, Python, that makes a huge difference.
Obj-C does not do auto memory management like Ruby, Perl, Python, that makes a huge difference.
With the OPENSTEP-style frameworks that come with OS X (Cocoa), or GNUstep, yes it does. They provide support for autorelease pools. You can also add garbage collection to Objective-C if you really wanted to also.
Have you tried GnomeCanvas? I believe it was explicitly created as a clone of Tk’s canvas.
IMHO the dynamic typing is totally unuseable for professional developers. Because strong types system can help to keep off many possible bugs, the implementation + test/debug phase of dynamic typing system longer then implementation + test/debug with static typing.
IMHO the dynamic typing is totally unuseable for professional developers.
It is obviously not, because many companies do use dynamically typed languages in very important work. Ericsson uses the dynamically typed language Erlang in mission-critical telephony work. Orbitz programmed their travel reservation system (which actually turns out to be a very complicated piece of software), in Lisp. Lisp was used in the planning software for the NASA Mars Pathfinder mission, as well as to write Mirai, the 3D modeling software used to (among other things) model Gollum in LOTR. Python is used extensively to do important work at Google.
Because strong types system can help to keep off many possible bugs
Static type systems can only eliminate a certain class of programming errors, namely type errors. They are an assertion mechanism that can only make assertions about a very limited subset of the overall program logic. In my experience with Python and Lisp, type errors make up a very small percentage of programming errors, particularly if the programmer takes care to keep the typing in a program simple (which, unfortunately, many programmers do not do).
On top of that, I should point out that the permissive type systems of Java and C#, as well as their emphasis on polymorphic behavior, take away a lot of the theoretical advantages of static typing as seen in ML or Haskell. Since casts are so common in C# and Java programmers, runtime type errors can still occur in many places.
the implementation + test/debug phase of dynamic typing system longer then implementation + test/debug with static typing.
Well, this is just completely false. In many real world projects, the timeline doesn’t go “design, implement, test.” Instead, the design process is an iterative loop, consisting of design, prototyping, feedback, more design, more prototyping, etc, sometimes with constantly changing requirements from the customer. This is especially true when doing “hard” projects in science or engineering, where it’s not very clear what the final system should look like. In most cases, there are additional steps over the lifetime of the product, including bug-fixing, refactoring, and addition of new features.
In situations like this, dynamically typed languages are an absolute boon. As I said before, typing is a way of making an assertion. It’s a way for the programmer to say “I want fact X to be true at a certain point in time.” Well, in the middle of iterative development, you don’t necessarily want to make such a statement, because after some feedback, you might decide that such a requirement doesn’t really make sense. Or, while you are refactoring, you might find that an existing piece of code can be reused for a certain purpose, if the original code’s assertions were not so unnecessarily restrictive. In an iterative development process, users of a static language often have to spend lot’s of time fighting the type system, rolling back assertions that no longer make sense. In a dynamic language, this is doesn’t happen nearly as often.
I think I should make an additional thing clear with regards to testing. All else being equal, yes, a statically-typed program probably does require less testing than a dynamically-typed one. However, all else is not equal. The fundemental weakness of statically typed languages is that refactoring is much harder to do than it should be (even with automated hacks like you find in Java IDEs). Thus, it is common for programmers in these languages to write a quick-and-dirty prototype, and then start afresh to write the final version. Programmers of dynamically typed languages, on the other hand, can write their quick-and-dirty prototype, and then iteratively refactor that prototype and turn it into the final version. This is a far superior model, because it seperates the process of “making it correct” to “making it polished.” It’s far easier to polish up the known-working prototype, than to ditch the prototype and start over.
You should try a language with a type inferencing system, such as OCaml or Clean. Polymorphism gives you all the benifits of a weakly typed language, while strong typing (real strong typing) and functional style programming ensures program correctness.
Did I also mention both bytecode and native compilers (the latter ranking right after C/C++ for performance in the Great Computer Language Shootout)? Or the garbage collector? Or the very modern multithreaded libraries? Or, or…
Well, I learned ML, but it didn’t hit me with the kind of epiphany Lisp did. I tend to agree with Alan Kay when he says: “Until real software engineering is developed, the next best practice is to develop with a dynamic system that has extreme late binding in all aspects.” That said, my ML is probably as mediocre as my French, so I should probably give it another shot one of these days…
t is obviously not, because many companies do use dynamically typed languages in very important work.
And many companies do use visual basic. But IMHO is not the best language…
Static type systems can only eliminate a certain class of programming errors, namely type errors.
But type error can meant other error (wrong wariable name after cut&paste from other source code, etc).
Well, this is just completely false. In many real world projects, the timeline doesn’t go “design, implement, test.” Instead, the design process is an iterative loop, consisting of design, prototyping, feedback, more design, more prototyping, etc, sometimes with constantly changing requirements from the customer.
In my practice it is not true. My software is not individual development, it is a product with static timeline: desing – implementation – test – new release.
I simply can’t single out one aspect of Ruby of why we consider it worth of our time.
It’s clean. It’s complete. It’s slow but fast enough. It has a strong influence from the oriental culture (that’s unique!). I see myself working with Ruby 10 years from now. It’s pragmatic. Its syntax does not get in the way (no forced indentation). It empowers classes and methods (the less, the better). See? And there is more to it. I think everyone has something unique of why he likes Ruby.
“One of the best things that could happen for Python would be for Python 2.5 or 2.6 to be built on top of Parrot. The speed improvement would probably be just tremendous, and it would lead the way for people to begin writing some very serious software in Python and Perl 6. Parrot could easily be the foundation of an open source alternative to ASP.NET and JSP.”
well, Python already generated byte code. That’s what the pyc files are.
and plus, Python is already fast enough for most applications and is in relatively common use for major project development. I suggest you look at the Python Success Stories on Pythonology.
As an example of Python being plenty fast for most tasks, I recently wrote a text processor for UNIX mail files in Python. On a 400 Mhz K6/2, it will process 85,000 lines of text per second. I certainly can’t complain about that.
“MHO the dynamic typing is totally unuseable for professional developers. Because strong types system can help to keep off many possible bugs, the implementation + test/debug phase of dynamic typing system longer then implementation + test/debug with static typing.”
That’s why you have the “isinstanceof” function in Python. Normally, you don’t need type checking. But in the few cases where you do, you can simply use isinstanceof to make sure that a variable of the correct type is being passed.
And many companies do use visual basic. But IMHO is not the best language…
Well, NASA has never used Visual Basic in a space probe, and I’ve never heard of anybody using Visual Basic to run a mission-critical communications system. In any case, the comment was not about the “best language” but rather whether dynamically typed languages are “totally unusable for professional developers.” Clearly, that is not the case.
But type error can meant other error (wrong wariable name after cut&paste from other source code, etc).
First, you shouldn’t be cutting and pasting code. Cut & paste is actually a problem endemic to statically-typed programs (at least, of the C++/Java/C# variety), because overly-restrictive types tend to lead to brittle code that is hard to reuse “as is.” Second, if you’re copying code that blindly, without checking to see the meaning of each variable name, then a runtime type error is the least of your problems.
My software is not individual development, it is a product with static timeline: desing – implementation – test – new release.
Do you add features to an existing code base? Do you refactor? Do you ever have to deal with changing specifications? Do you work on cutting-edge problems, where the precise form of the solution can’t be pinned-down beforehand? If you do any of these things, then it’s likely that the flexibility of a dynamic language will outweigh the percieved disadvantages of losing static typing Again, this is especially true if you use polymorphism in your code, in which case you’ve already compromised the rigorous safety of static typing. If you don’t have to do any of these things, then consider yourself very lucky.
In my practice it is not true. My software is not individual development, it is a product with static timeline: desing – implementation – test – new release.
In theory that might be a good idea, but in practice most software development is not done using the waterfall method you describe. Heck, a lot of the time people don’t even know where they’re going to go with their software. They might have some subroutines that they expand upon.
Design, implementation, and testing tends to be pretty messy in practice and tend to overlap quite a bit. What the dynamic languages afford you is the ability to rapidly try out new ideas without getting bogged down in a bad design when its too late.
It’s nice to be able to write some code in an editor, import it into the interpreter, try out different things.
One reason I’m kindof getting into Python now is because it doesn’t bog you down with classes and other stuff if you don’t want to.
I’m not putting down static typing, I’m just saying that the case for static typing has been overblown.
Welcome to 1958.
Not necessarily. Some of the modern languages like Ruby have chosen some points of the old languages and from the assemble of those features we get new ways of looking at problems and solving them. The old languages have been important, as well as the current languages are important for the future ones. Visual tools are ok, but many things could be simplified with a “simplified” language. A future dynamic language could be built upon the successes of Ruby and Python, and with the resources of Microsoft or the industry, really change the way we code. Think about getting the support of an IDE like Eclipse, the support of the JVM and CLR, native compilation, etc. So there is room for great improvements, but they don’t coincide with the interests of the organizations. If we want to change anything, it should start with our “votes”.
Welcome to 1958.
Bring Elvis back from the dead, program in ruby. Suits me
Static type systems can only eliminate a certain class of programming errors, namely type errors.
But type error can meant other error (wrong wariable name after cut&paste from other source code, etc).
so?
you still need test to check that the code you cut/pasted is functionally correct. The same test will also test the type correctness that you’d get assured from the compiler.
So one thing is redundant, guess what?
Also, there is *no* strong statically typed system as expressive as the one found in dynamic languages.
I’d choose a strong static type system everyday of my life if it was as expressive as others, but there are not.
Also, every strong+static type system has holes, I won’t even talk about the kind of errors you get from crappy systems like java’s one, but consider that even *far more better* systems like OCAML’s have holes (plus it misses runtime reflection).
Look at LambdaTheUltimate’s archives, this has been debated so many times from people with a better knowledge of the subject thn me and you.
Ah, it seems someone has seen the light.
Before you get too excited, I’m using the Visual Python plugin for Visual Studio, and am still mostly interested in compiling Python down to MSIL (IronPython)
First, you shouldn’t be cutting and pasting code. Cut & paste is actually a problem endemic to statically-typed programs (at least, of the C++/Java/C# variety), because overly-restrictive types tend to lead to brittle code that is hard to reuse “as is.”
Cut&Paste doesn’t depend on typing. This cut&paste codes tipically relative small things(30-50 lines) and create similar but different things. For example modify a table rows in the database and I want to modify a rows with similar algorithm but differend table (and field names).
I can create a general function and I can give the field names as parameters, but is not always a good idea. In this case I use the cut&paste. If the code is reuseable “as is” I create a common function or object.
Second, if you’re copying code that blindly, without checking to see the meaning of each variable name, then a runtime type error is the least of your problems.
This code pieces is always my code from the other part of the program or other older source code. I know what the code do but I can forget a little variable.
The other important help of the strong-typed compilers the suggestions: uninitalized, not used, etc variables.
Before you get too excited, I’m using the Visual Python plugin for Visual Studio, and am still mostly interested in compiling Python down to MSIL (IronPython)
You should be most interested in using the .NET classes from python. Whether or not the python is running under MSIL or some another VM seems beside the point. Are the .NET classes better than the python equivalents? Or if you want to call the .NET classes from python, is running on the same VM the best way to do it?
The other advantage given for having multiple languages running on the same VM is that it means you don’t need to write language bindings. But the rules for overloaded method resolution differ from language to language. The rules for VB.NET are different from the rules for C#. And python doesn’t have method overloading of course. They are done at runtime by the particular language implementation; it isn’t intrinsic to the CLR itself.
The other problem having a common VM doesn’t solve, in itself, is marshalling types such as lists or strings from one language to another. The CLR solves that by having the same primitive types, which is ok as long as it’s acceptable to have the same primitive types for all languages.
C# methods start with an uppercase letter, whereas java methods start with a lower case letter. Some languages use camel case method names with mixed upper and lower cases, where others use all lower case with underscores. Unless you have a mechanism for mapping method names from one naming convention to another, your language binding will probably look a bit strange. Who would like to do java programming where some methods start with an uppercase letter, and some with lowercase?
I’m not saying that it isn’t a good to have lots of languages running on the CLR, just that it doesn’t solve as many problems as it’s cracked up to solve.
My favorite languages for real projects are static languages such as Ada, Haskell and Java. I like ruby and perl for little one-off scripts. I tried to do a larger project in ruby and it was difficult. It just seemed hard to manage. I really felt the lack of typing was a serious hinderance. This may not be the case for every programmer, but it was in my case. I translated the code to Java and finished it off easily. It may have also been a case of a rich API helping as well.
Personally, I think the API of the language is probably the most important aspect of a computer language. Scheme and Haskell do have other wonderful features though.
Porting languages to run on top of the same VM brings in a set of problems that you’ve described, but I believe the tradeoffs are worth it. Having to use camel casing is not going to kill me unlike some of the Perlish syntax that I’ve seen in Ruby
Something like Boo (boo.codehaus.org) is was built from the ground up to interact with the CLR and the developer is a big Python fan. He actually does all his development on Mono.
In the long term, I think Microsoft (and hopefully Novell too) has the brainpower and the resources to pull off the closest to an ideal, generic VM we’re going to get. If the parrot folks can eventually get something implemented for production-use then that’s good too, but I’m not holding my breath on that.
Python seems to have many options though. Run it on top of its native interpeter, some PythonC thingie, Jython, on top of .NET/Mono/(dotGNU?), and maybe Parrot in the future.
My issues right now are ease of use and deployment. The guy that was writing some configuration and management tools in Java for us seemed to have a mental meltdown, so we’re back to square one. I looked at Ruby, but I don’t like the Perlish syntax and after I write the initial version of the code, a guy in tech support that is interested in programming will probably be maintaining it, so it’s got to be readable and easy to get up to speed.
Perl does not have closures, symbols, clean OO, etc. Maybe you haven’t seen Ruby the way we see it, with a nice syntax highlighting, for example.
At my blog, you will find some example of how I see it:
http://sinsalabintrix.blogspot.com/
And at codepaste, you can see some code with a more or less syntax highlighting:
http://www.codepaste.org/
The IRC is friendly at irc.freenode.net #ruby-lang
Cut&Paste doesn’t depend on typing.
Cut & Paste tends to be a problem with statically typed languages. I often see code that get’s copied from someplace else (instead of being subsumed into a function), just because the types in question are slightly different. Not that all cut & paste is due to static typing, but proper lambdas and dynamic typing can cut down on a lot of that.
This code pieces is always my code from the other part of the program or other older source code. I know what the code do but I can forget a little variable.
The only situation in which static typing will help you here is if a variable with the same name has different types in the cut context and the pasted context. Unless you name your variables things like ‘i’ and ‘j’, this would seem to be an exceedingly rare situation. Hell, even then, assuming a language with a smart compiler (cmucl, d2c), the problem would only hit you if the compiler couldn’t do the type inference and report a potential type error.
The other important help of the strong-typed compilers the suggestions: uninitalized, not used, etc variables.
There is no reason a compiler for a dynamically typed language cannot warn you about the exact same things. Most good dynamic compilers do exactly this sort of thing, even though they tend to be warnings rather than flat-out errors.
I like scripting languages like Python and Ruby alot.
I don’t like having to hack in a text editor, fly to the command prompt in one window, and an interpretor in another window to test my results.
Unfortuantely, there are no good — GOOOOOOOD — free IDEs for Ruby, which sucks. ;(
I think the way to speed up python would be to replace TkInter
with wxPython/wxWidgets as the official GUI toolkit. I find that programs I make with this using even just source code without the bytecode outdo Java and Mono in the speed department at least on my machine. Adopting a Python/wxPython/
wxWidgets system would be a Godsend for GPL programmers who would be able to ship an EXECUTABLE application as source code alone and not have to get their users involved in a compilation process before they can use the software. (Also for beginners python only has five basic loops and switches as compared to the seven that have to be learned in systems langiages like Pascal, C/C++ Java and C#.)
of slow, unoptimized, resource hungry programs.
Unfortuantely, there are no good — GOOOOOOOD — free IDEs for Ruby, which sucks. ;(
I’ve been so busy with getting the QtRuby/Korundum bindings finished, I haven’t had time to contribute to KDevelop ruby support. But I’ve tried out KDevelop recently and it does have ruby syntax highlighting, and a ruby class parser. Although I couldn’t seem to get the class parser working.
I’ve been using the KDE Kate text editor for my ruby development and that’s been mostly ‘good enough’. I think you need an IDE much more with a language like Java because it takes at least 5 times as much code to say anything. And refactoring with an ‘over complicated’ language like Java needs more IDE support than Ruby. Maybe if some code from FreeRIDE could be merged into KDevelop that would be the best bet for a killer Free Software Ruby IDE.
of slow, unoptimized, resource hungry programs.
As distinct from the sheer perfection and speed of Java Swing or .NET WindowsForms on the client side?
There are lot’s of slow, unoptimized, resource hungry programs written in C. At the end of the day, a good native compiler for a dynamic language will get you to 10% to 20% the speed of C. At that point, the user-noticible differences come not from language speed, but from using good algorithms.
On top of that, if you can trade 10% to 20% performance for even the same amount of developer time, your program is going to be a lot faster iin the end because you can spend more time optimizing.
wspython apis are awful, imo, choosing Qt or Gtk would be much better.
And, python has 5 basic loops compared to the seven you find in pascal. So what?
just teaching a newbie the for/else construct and how it behaves with break/continue/StopIteration and normal termination would be a killer experience.
But I understand that it’s really understandable, not that stupid absurd repeat/until syntax.. I mean wtf “until” should mean?
Python is a nifty language and I do think it’s good for a noob, but for sure this has nothing to do with iteration.
Yeah, I agree, using a behemoth like Java means you NEED an IDE that is all powerful, but still, I view IDEs as incredibly handy tools – syntax completion, highlighting, class documentation, an interactive shell and a little green button that you press to make the project “Go” all within one enviroment? Cha-ching!
How rocking handy is it to check the documentation of a method just by hovering your mouse over it?
What kind of sweet sauce oozes from your mouth when you make a syntactical error and the IDE *immediately* notifies you before you’ve already left that code block behind?
I can dig it, man, I’ve tasted the future and I like it.
Rayiner: At the end of the day, a good native compiler for a dynamic language will get you to 10% to 20% the speed of C.
Objective-C or other dynamic languages are about 50% or less the speed of C++ if you look at ‘programming in the small’, by measuring a loop calculating the Sieve of Eratosthenes or whatever. On the other hand if you write a large system using Objective-C, you’ll find they’re more efficient because they scale better for ‘programming in the large’. I’m talking about Objective-C because I do have experience of working on ‘seriously large’ Objective-C programs/systems (which I haven’t done for Ruby yet).
In theory Java event listeners are highly optimized because of static typing, and using reflection should be less efficient. In practice subclassing event listeners is highly inefficient, hard to program and doesn’t scale if you want to write a real app. It doesn’t work with ‘programming in the large’. Sun have taken a dynamic language and ignored that capability, whereas Trolltech have taken a static language and made it more dynamic via the moc preprocessor.
In theory QtRuby apps which use Ruby, which is about 40 time slower than C++ via ‘programming in the small’ benchmarks, should be slower than Java Swing for writing GUI apps. But they’re not, because the underlying toolkit, Qt is highly efficient and ruby just has to orchestrate calls to the toolkit, rather than doing anything much itself.
This is a PR page.
It’s no article.
It’s so totally wrong to link from this site to that article.
OSAlert is really publishing just anything these days.
I call that being desperate to generate more page impressions…
Hi,
After writing the following article in response to David Ascher’s white paper, “Dynamic Languages – ready for the next challenges, by design”, he and I had lunch (a few weeks ago). In addition to acknowledging the points that I make below he agrees that a rewrite or updated version of his white paper is needed however you don’t usually update “white papers”.
In any event, it’s clear to all including David that Smalltalk and Lisp are dynamic langauges and open source languages and should be included.
The issue of dynamic languages continues to be volitile as there are many valid perspectives that people are coming from.
When creating a next generation language are you adding complexity or attempting to reduce it?
i.e. Will Perl 6 be simplier or more complex than earlier Perls?
Those that are working on the next generation of languages would be wise to learn from Smalltalk’s simplicty and power which derive in part from it’s elegant and simple syntax that enables most extensions to be implemented in the class hierarchy library rather than in adding layers of complicated syntax.
Smalltalk is spreading. Catch the wave.
All the best,
Peter William Lount, Smalltalk.org Editor
http://www.smalltalk.org/articles/article_20040912_a1.html