Dynamic languages are the future

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Dynamic languages are the future

Jay Nelson-2
http://www.eweek.com/article2/0,1895,2009010,00.asp

A four page article which claims the next generation of programming will
be with "dynamic languages" like Ruby, Python, Perl, .NET and others.



Some quotes:

-----------------

The appeal of dynamic languages is clear: As systems continue to grow
more complex, developers seek simpler ways to get their work done.

...

And simpler code tends to attract developers. "I think that dynamic
languages are really the next big thing," said John Lam, a principal
consultant and partner at Toronto-based ObjectSharp Consulting.

----------------

Meanwhile, Sun also is making changes to the JVM, so, in the future, it
can bring over new languages, Hamilton said.

Gilad Bracha, a computational theologist at Sun, said the company is
broadening its support for dynamic languages not only to satisfy user
demand but also to help broaden the overall community of developers who
use the Java platform.

Bracha noted that Sun currently offers support for some dynamic
languages on the Java platform, including Jython, Kawa, Groovy and
ECMA­Script.

"We're solidly committed" to providing enhanced support for dynamic
languages by adding a bytecode called invokedynamic and adding
hot-swapping support, Bracha said. Hot swapping is the ability to modify
code on the fly. Both efforts are part of Java Specification Request
292, the goal of which is to allow scripting languages to be implemented
natively on the JVM, Bracha said.

-------------------

Meanwhile, Anders Hejlsberg, a Microsoft software architect in Redmond,
Wash., and father of C#, said the days are numbered for imperative
programming, which instructs the computer to make room for more
declarative programming, which describes what something is like rather
than how to create it. This style of programming is especially effective
in helping developers take advantage of multicore CPUs, Hejlsberg said.

...

Although dynamic languages have momentum, Hejlsberg said they lack
scale. "Dynamic typing only scales so far," he said. "When you get into
really big projects, it's problematic."

---------------------

For his part, Lam said it's too early to know how dynamic languages will
scale. "We just don't have enough experience in building large systems
on these things," he said.

Cedric Beust, an engineer at Google, in Mountain View, Calif., said,
"Dynamic languages suffer from some inherent limitations that make them
inadequate for 'large software.' So I definitely see them as gaining
momentum, but they will never displace 'enterprise' languages such as
Java, C# or C++. Some of their features are slowly percolating into
enterprise languages, though, which is a good thing."

Sridhar Iyengar, an IBM distinguished engineer, in Durham, N.C., offered
more questions regarding large-scale deployment of applications built
with dynamic languages.

"One of the challenges of dynamic languages is how do you test it, how
do you debug it and how do you make sure that your application is
secure," Iyengar said. "All of this is tough to do with static
languages. It's incredibly harder in dynamic languages."


-------------------
Reply | Threaded
Open this post in threaded view
|

Re: Dynamic languages are the future

Jay Nelson-2
Byron Hale wrote:
> Depends on what you mean by "dynamic," I suppose.
Just quoting the article.
> If you mean run-time binding, then it is the wave of the past.  To be
> specific, Lisp had run-time binding and was superseded by Scheme
> because run-time binding is a horrible flaw in a scientific language.  
> Scheme was superseded by typed functional languages.
Hmm, my recollection was building commercial apps in Common Lisp and
CLOS, not Scheme.  I have yet to meet any language as powerful and would
take it back -- well, I think I like what erlang has to offer better,
but only because I've already done Lisp and my needs are different now.

Lisp gave you the power to do whatever you needed to do.  You could
avoid the power or you could use it.  The language didn't try to protect
you from making mistakes, it just gave you the choice to use the power.  
It was not a horrible flaw that enabled that approach.

I think you'll find that the XP (extreme programming) trend and test
first development will cause less reliance on statically typed
languages.  There are already rumblings that the straitjacket makes it
difficult to itch behind your ear.
>
> Charitably speaking, there seem to be only a few places where run-time
> binding might be desirable.  Remember: Shoe salesmen sell what they have.
And people who wear wing tips don't realize they pinch your toes.

Let me try just one: XML.  Have you ever seen a piece of commercial code
using XML to deliver domain-specific data which doesn't require
recompiling if a new attribute is added to the XML stream?  The promise
of XML was to dynamically define the content using a DTD, but everyone
is using static languages so they don't do things dynamically.  They end
up putting the attribute names in the code because they have to map to a
semantic implementation.
>
> As for scripting languages, what major system has ever successfully
> been held together by band-aids and bubblegum?
Well, actually just about every commercial system I've worked on had its
share of band-aids and bubblegum and not due to the scripting language,
but rather due to evolving requirements for a code base that had too
much inertia.  The scripting language was generally used to clean up the
holes because it was easier.  Scripting offers quick solutions to small
headaches.

But I would not use a scripting language to deploy something that needs
to scale or needs to be reliable.

Erlang is dynamic and right now it is the only language I would use for
scale and reliability.
>
> Byron Hale

Reply | Threaded
Open this post in threaded view
|

Re: Dynamic languages are the future

David Hopwood
In reply to this post by Jay Nelson-2
Jay Nelson wrote:
> http://www.eweek.com/article2/0,1895,2009010,00.asp
>
> A four page article which claims the next generation of programming will
> be with "dynamic languages" like Ruby, Python, Perl, .NET and others.

Maybe the "next generation", but not the generation after that. My impression
is that there are few purely dynamically typed languages being designed any
more. Type inference has won the argument. It will just take a while for this
to filter through to the mainstream, as it always does.

Mind you, the definition of "dynamic" that this article uses is so fuzzy
that it could include almost any language.


(.NET CLR is statically typed. Of course you can still implement "dynamic"
languages on it inefficiently.)

--
David Hopwood <[hidden email]>


Reply | Threaded
Open this post in threaded view
|

Re: Dynamic languages are the future

James Hague
On 8/29/06, David Hopwood <[hidden email]> wrote:
>
> Maybe the "next generation", but not the generation after that. My impression
> is that there are few purely dynamically typed languages being designed any
> more. Type inference has won the argument. It will just take a while for this
> to filter through to the mainstream, as it always does.

I disagree.  Type inference simply prevents you from having to
manually specify many types.  Indeed, the Erlang compiler already does
this where it can.  It doesn't magically solve problems like coming up
with a static type system that can handle dynamically reloading
modules in live system (without full recompilation) and messages
between processes.
Reply | Threaded
Open this post in threaded view
|

Re: Dynamic languages are the future

David Hopwood
James Hague wrote:

> On 8/29/06, David Hopwood <[hidden email]> wrote:
>
>> Maybe the "next generation", but not the generation after that. My
>> impression is that there are few purely dynamically typed languages being
>> designed any more. Type inference has won the argument. It will just take
>> a while for this to filter through to the mainstream, as it always does.
>
> I disagree.  Type inference simply prevents you from having to
> manually specify many types.  Indeed, the Erlang compiler already does
> this where it can.  It doesn't magically solve problems like coming up
> with a static type system that can handle dynamically reloading
> modules in live system (without full recompilation) and messages
> between processes.

These problems are in principle already solved for statically typed languages.
Some of them are only solved in research papers (e.g. typing of first-class
messages in <http://www.cs.jhu.edu/~pari/papers/fool2004/first-class_FOOL2004.pdf>),
others in real languages (e.g. open distribution in Alice ML or Acute), but
there are no fundamental obstacles to doing *any* of these "dynamic" things
in a language with static type inference.

--
David Hopwood <[hidden email]>


Reply | Threaded
Open this post in threaded view
|

Re: Dynamic languages are the future

yarivvv
In reply to this post by James Hague
On 8/29/06, James Hague <[hidden email]> wrote:

> On 8/29/06, David Hopwood <[hidden email]> wrote:
> >
> > Maybe the "next generation", but not the generation after that. My impression
> > is that there are few purely dynamically typed languages being designed any
> > more. Type inference has won the argument. It will just take a while for this
> > to filter through to the mainstream, as it always does.
>
> I disagree.  Type inference simply prevents you from having to
> manually specify many types.  Indeed, the Erlang compiler already does
> this where it can.  It doesn't magically solve problems like coming up
> with a static type system that can handle dynamically reloading
> modules in live system (without full recompilation) and messages
> between processes.
>

+1

If static typing  were added to Erlang, (type inference included)
Smerl and ErlyDB would be toast :)

Yariv
Reply | Threaded
Open this post in threaded view
|

Re: Dynamic languages are the future

Nick Linker
In reply to this post by Jay Nelson-2
Jay Nelson wrote:

> Hmm, my recollection was building commercial apps in Common Lisp and
> CLOS, not Scheme.  I have yet to meet any language as powerful and
> would take it back -- well, I think I like what erlang has to offer
> better, but only because I've already done Lisp and my needs are
> different now.
>
> Lisp gave you the power to do whatever you needed to do.  You could
> avoid the power or you could use it.  The language didn't try to
> protect you from making mistakes, it just gave you the choice to use
> the power.  It was not a horrible flaw that enabled that approach.
I wonder why Erlang is not Lisp? I mean why inventors of Erlang chose to
create its own language instead of creating just ERTS-specific library
for LISP (or at least Scheme)?

Parentheses? :-)

Best regards,
Nick.
Reply | Threaded
Open this post in threaded view
|

Re: Dynamic languages are the future

Richard Carlsson-2
Nick Linker wrote:
> I wonder why Erlang is not Lisp? I mean why inventors of Erlang chose
> to create its own language instead of creating just ERTS-specific
> library for LISP (or at least Scheme)?

Here are some reasons why Lisp might not be a perfect match to
the problem they wanted to solve:
        - no built-in concurrency
        - destructive updates abound (in Scheme, too)
        - no pattern matching

And if you're going to fix those things, you might as well use a syntax
that feels more comfortable to you. In particular, pattern matching
makes function definitions and selective receives much more readable,
which I assume was an important goal for the kind of industrial
applications that Erlang was created for.

In most respects, Erlang _is_ a concurrent, nondestructive Lisp with
a Prolog-inspired syntax that focuses on pattern matching and rules.

        /Richard

Reply | Threaded
Open this post in threaded view
|

Re: Dynamic languages are the future

Joel Reymont
In reply to this post by Nick Linker

On Aug 30, 2006, at 6:40 AM, Nick Linker wrote:

> I wonder why Erlang is not Lisp? I mean why inventors of Erlang  
> chose to create its own language instead of creating just ERTS-
> specific library for LISP (or at least Scheme)?
>
> Parentheses? :-)

You don't have the process abstraction built into the language so  
Erlang cannot be recreated as Lisp, IMO. People are trying to do  
Erlang-like libraries for Lisp (MU-PROC) but they are still based on  
top of system threads which eliminates all the advantages, IMO.

--
http://wagerlabs.com/





Reply | Threaded
Open this post in threaded view
|

Re: Dynamic languages are the future

Mats Cronqvist
In reply to this post by Richard Carlsson-2
Richard Carlsson wrote:
> Erlang _is_ a concurrent, nondestructive Lisp with
> a Prolog-inspired syntax that focuses on pattern matching and rules.

   i nominate this to joe's "erlang in 5 seconds" competition.

   mats
Reply | Threaded
Open this post in threaded view
|

Re: Dynamic languages are the future

Richard Kilmer
In reply to this post by Joel Reymont

On Aug 30, 2006, at 4:47 AM, Joel Reymont wrote:

>
> On Aug 30, 2006, at 6:40 AM, Nick Linker wrote:
>
>> I wonder why Erlang is not Lisp? I mean why inventors of Erlang  
>> chose to create its own language instead of creating just ERTS-
>> specific library for LISP (or at least Scheme)?
>>
>> Parentheses? :-)
>
> You don't have the process abstraction built into the language so  
> Erlang cannot be recreated as Lisp, IMO. People are trying to do  
> Erlang-like libraries for Lisp (MU-PROC) but they are still based  
> on top of system threads which eliminates all the advantages, IMO.

Yep, and this article from January is a good presentation of the  
issues with theads:

http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.html

They speak positively of Erlang in there, although they imply that  
people will not switch.  Of course, in the Ruby community we felt  
that people would never switch from languages like Java to Ruby...but  
then came Rails and switch they are!  I think people underestimate  
the power of frameworks geared toward solving specific issues as a  
draw for others outside a language community.  I am just learning  
Erlang and am very much enjoying it so far.

>
> --
> http://wagerlabs.com/
>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Dynamic languages are the future

ke han
In reply to this post by Mats Cronqvist

On Aug 30, 2006, at 6:13 PM, Mats Cronqvist wrote:

> Richard Carlsson wrote:
>> Erlang _is_ a concurrent, nondestructive Lisp with
>> a Prolog-inspired syntax that focuses on pattern matching and rules.
>
>   i nominate this to joe's "erlang in 5 seconds" competition.

yes, well said Richard!!   This may work since I think there was  
mention that the target audience was Smalltalk-ers?
But, I am absolutely amazed at how many "20-something" programmers  
I've interviewed in the last two years that gave me a blank stare  
when you ask them if the've tried Prolog or Lisp.  That is, they  
haven't just not tried it, they've never heard of it.  To add further  
insult to this statement, these candidates all had master's degrees  
in CS from China's most prestigious schools... oops  ;-)

ke han

>
>   mats

Reply | Threaded
Open this post in threaded view
|

Dynamic languages are the future

fbg111


ke han wrote:
>
> But, I am absolutely amazed at how many "20-something" programmers  
> I've interviewed in the last two years that gave me a blank stare  
> when you ask them if the've tried Prolog or Lisp.  That is, they  
> haven't just not tried it, they've never heard of it.  To add further  
> insult to this statement, these candidates all had master's degrees  
> in CS from China's most prestigious schools... oops  ;-)
>

Same problem
http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html in
America .  More  http://paulgraham.com/popular.html good writings  on that
topic at Paul Graham's site.
--
View this message in context: http://www.nabble.com/Dynamic-languages-are-the-future-tf2181293.html#a6072416
Sent from the Erlang Questions forum at Nabble.com.



Reply | Threaded
Open this post in threaded view
|

Re: Dynamic languages are the future

kurtosis
In reply to this post by ke han
ke han wrote
But, I am absolutely amazed at how many "20-something" programmers  
I've interviewed in the last two years that gave me a blank stare  
when you ask them if the've tried Prolog or Lisp.  That is, they  
haven't just not tried it, they've never heard of it.  To add further  
insult to this statement, these candidates all had master's degrees  
in CS from China's most prestigious schools... oops  ;-)
Same problem in America.  More good writings on that topic at Paul Graham's site.
Reply | Threaded
Open this post in threaded view
|

Re: Dynamic languages are the future

Richard A. O'Keefe-2
In reply to this post by Jay Nelson-2
fbg111 <[hidden email]> wrote:
        Same problem
        http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html
        in America.  More
        http://paulgraham.com/popular.html
        good writings  on that topic at Paul Graham's site.

It must be synchronicity.
We've had a thread about strings that looks like reviving.
I'm in the middle of writing some Java classes for a 4th year student to use.
And now here's mention of Java.

The 4th year student is supposed to be investigating a topic in information
retrieval; I wanted to see if multicore systems could do IR faster, and
Andrew Trotman came up with the key concept for how to structure an index
so that this might actually work.

The student was given a tiny (< 500 line) IR engine in C that reads an XML
document collection and builds an index (~ 300 lines) and that reads
an index and queries (~ 300 lines; the two programs share some code).
It's small, dead simple, and reasonably fast.  It can index the test
collection in under 3 minutes.  The student basically got nowhere modifying
it because despite having had C in 3rd year, she only really knows Java.
Her Java rewrite of my C code (without the XML stuff; the document
collection had to be reformatted) takes eight hours.

Eight hours!  That's 160 times slower than C!

Just for grins, I rewrote the index builder in AWK.  44 lines of AWK.
(It works on the same reformatted document collection as the student's
code, uses built in hash tables, and writes numbers in ASCII, not binary.)
Her Java program was more than 50 times slower than AWK.

Profiling to the rescue:  "java -Xprof BuildIndex wsj.data".
It turned out that practically all the time was going in RandomAccessFile.
Guess what:  RandomAccessFile doesn't do any buffering, so each

    f.writeInt(x)

turned into 4 calls to f.write((byte)(x >> ...)), and each of *those*
is a call to a native method, involving a switch from Java to C and back.

Just adding a few lines of code to buffer stuff into a byte array and
flushing that every so often (just like using fwrite() in C would...)
speeded the program up by a factor of 10.

The mawk version is still sniggering at the Java version, but not as loudly.

Of course this says nothing about Java AS A LANGUAGE.
It's a library issue.  But in real Java, practically _everything_ is
a library issue.  There's another student doing a GA+IR project whose
program was speeded up by a large factor by another lecturer.  Same
thing:  run the program with -Xprof, spot that the time is going in a
library class (ArrayList, as it happens), rewrite to use plain arrays,
time goes way down.

One of the things that makes Erlang a practical language for real applications
is the tools for working with Erlang, like 'eprof' and 'cover'.

Reply | Threaded
Open this post in threaded view
|

Re: Dynamic languages are the future

ke han
 From 1998 to 2002 my company built an aggressive app framework in  
Java and a vertical app to leverage it.  We ended up with about  
500,000 lines of code.  Over half of this was replacing what should  
have been good enough in the core Java libraries.
By the time we were done, we rewrote just about every core Java class  
as the JDK equivalent was poorly designed/implemented.  We had to  
rewrite serialization, make thread safe collections and thread safe  
just about everything, rolled our own non-blocking io which after Sun  
came out with nio, we found ours was still much more time and space  
efficient....We ended up with something that showed Java as a  
language can be very efficient and scalable...but the libraries...not  
so much ;-)
ke han


On Aug 31, 2006, at 12:11 PM, Richard A. O'Keefe wrote:

> fbg111 <[hidden email]> wrote:
> Same problem
> http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html
> in America.  More
> http://paulgraham.com/popular.html
> good writings  on that topic at Paul Graham's site.
>
> It must be synchronicity.
> We've had a thread about strings that looks like reviving.
> I'm in the middle of writing some Java classes for a 4th year  
> student to use.
> And now here's mention of Java.
>
> The 4th year student is supposed to be investigating a topic in  
> information
> retrieval; I wanted to see if multicore systems could do IR faster,  
> and
> Andrew Trotman came up with the key concept for how to structure an  
> index
> so that this might actually work.
>
> The student was given a tiny (< 500 line) IR engine in C that reads  
> an XML
> document collection and builds an index (~ 300 lines) and that reads
> an index and queries (~ 300 lines; the two programs share some code).
> It's small, dead simple, and reasonably fast.  It can index the test
> collection in under 3 minutes.  The student basically got nowhere  
> modifying
> it because despite having had C in 3rd year, she only really knows  
> Java.
> Her Java rewrite of my C code (without the XML stuff; the document
> collection had to be reformatted) takes eight hours.
>
> Eight hours!  That's 160 times slower than C!
>
> Just for grins, I rewrote the index builder in AWK.  44 lines of AWK.
> (It works on the same reformatted document collection as the student's
> code, uses built in hash tables, and writes numbers in ASCII, not  
> binary.)
> Her Java program was more than 50 times slower than AWK.
>
> Profiling to the rescue:  "java -Xprof BuildIndex wsj.data".
> It turned out that practically all the time was going in  
> RandomAccessFile.
> Guess what:  RandomAccessFile doesn't do any buffering, so each
>
>     f.writeInt(x)
>
> turned into 4 calls to f.write((byte)(x >> ...)), and each of *those*
> is a call to a native method, involving a switch from Java to C and  
> back.
>
> Just adding a few lines of code to buffer stuff into a byte array and
> flushing that every so often (just like using fwrite() in C would...)
> speeded the program up by a factor of 10.
>
> The mawk version is still sniggering at the Java version, but not  
> as loudly.
>
> Of course this says nothing about Java AS A LANGUAGE.
> It's a library issue.  But in real Java, practically _everything_ is
> a library issue.  There's another student doing a GA+IR project whose
> program was speeded up by a large factor by another lecturer.  Same
> thing:  run the program with -Xprof, spot that the time is going in a
> library class (ArrayList, as it happens), rewrite to use plain arrays,
> time goes way down.
>
> One of the things that makes Erlang a practical language for real  
> applications
> is the tools for working with Erlang, like 'eprof' and 'cover'.
>