benefit of dynamic typing?

[HamsterofDeath]

it's not related directly to scala, but what are the benefits of dynamic
typing? what can you do that you can't with statically typed languages
(especially scala)?
maybe i don't see the obvious, but .... i don't see an advantage. none
at all. what can one possibly achieve by inviting runtime errors?

[Tony Morris]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Not all programs can be represented by a given terminating static type
system. Scala's type system is turing-complete, involving
non-termination. Runar Bjarnason recently proved this by encoding the
SK combinator calculus, which is known to be turing-complete.

In practice, and for a sufficiently practical type system, these
instances of programs that cannot be encoded are rare and so the
advantages of dynamic typing might best be paraphrased, "allows
expression of esoteric programs." Unfortunately for progress in this
area, and for reasons for which I can only offer conjecture, these
cases are thought to be more common than is actual.

PS: I hope you're aware of the onslaught that you've invited.

- --
Tony Morris
http://tmorris.net/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1Q6rEACgkQmnpgrYe6r60oIgCgmegMfwHrO7y4oFkXQvt0Sryo
VnIAnjJmrYTa7qwnUEyO5Q5x+TjLgmTZ
=+iA0
-----END PGP SIGNATURE-----

[Russ Paielli]

Tony gave the theoretical answer, but let me take a shot at the practical answer. Dynamic typing lends itself to rapid prototyping and generally getting small-to-medium-sized, non-critical applications up and running faster. Whether that is wise in the long run is another matter altogether, but with dynamic typing you can often get things working with less hassle up front. It can also be useful for advanced scientific and engineering calculations (as in Matlab), when you need to get a result and then throw away or forget the code.

Beyond that, dynamic typing also allows you to generate code at run time and then execute it at the same run time. Apparently there is a legitimate use for that, but I don't know what it is off hand. Then there's "monkey patching." I googled it once, but I forgot what it is, and I have no intention of ever doing it.

--Russ P.

--
http://RussP.us

[Paul Phillips]

On 2/7/11 11:48 PM, Russ Paielli wrote:
> Then there's "monkey patching." I googled it once, but I forgot what it is,
> and I have no intention of ever doing it.

This evening, on Scala Programmers After Dark: True Confessions!
Tonight's topic: Are you curious about "monkey patching"? Hear what
others will admit when given dark glasses and dim lighting!

"I googled it once."
"I forgot what it is."
"I have no intention of ever doing it!"

Also be sure to join us next week, when we will ask leading scala
lumniaries about "hot fixes".

[Tony Morris]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/02/11 17:48, Russ Paielli wrote:
> Dynamic typing lends itself to rapid prototyping and generally
> getting small-to-medium-sized, non-critical applications up and
> running faster.

For the benefit of the curious, this particular statement is both very
popular and very not true in the veriest sense.

I think this belongs over in [scala-debate].

- --
Tony Morris
http://tmorris.net/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1Q//UACgkQmnpgrYe6r62UAgCgt7bG47UKfI9OYHRpUOtjSv5s
KyUAoMxAVrC8mm/I9KxBSVlW8RJ0HfBs
=JdfA
-----END PGP SIGNATURE-----

[Dennis Haupt]

i was hoping for a piece of code that shows how easily it can be written using dynamic typing and then showing how troublesome it was if one were forced to use static typing.

so far i've read
"less code, because you don't have to write the types" -> it's also potentially less readable & type inference can also achieve this
"faster prototyping" -> i disagree. i can write code quick & dirty in java which is the most cluttery language that i can handle. my ide takes care of writing a lot of the code for me.

-------- Original-Nachricht --------
> Datum: Tue, 08 Feb 2011 17:03:13 +1000
> Von: Tony Morris <tonym...@gmail.com>
> An: scala...@googlegroups.com
> Betreff: Re: [scala-user] benefit of dynamic typing?

[Tony Morris]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/02/11 18:50, Dennis Haupt wrote:
> i was hoping for a piece of code that shows how easily it can be
> written using dynamic typing and then showing how troublesome it
> was if one were forced to use static typing.

Hi Dennis,
There is a reason that no such thing is forthcoming.

>
> so far i've read "less code, because you don't have to write the
> types" -> it's also potentially less readable & type inference can
> also achieve this

I didn't see anyone say that on this thread, but I have heard it
countless times. It's nonsense and demonstrates a lack of
understanding of type systems. For example, it is extremely rare that
one needs to write type annotations in haskell. There are also
languages where *you only write types*. You end up with less code and
proof of program correctness. How about that -- terse and correct!

> "faster prototyping" -> i disagree. i can write code quick & dirty
> in java which is the most cluttery language that i can handle. my
> ide takes care of writing a lot of the code for me.

That's because it's blatantly false, regardless of Java. These claims
merely invite education on the topic at hand.


====

To share an anecdote, I once worked with someone who told me that
dynamic typing was "great for prototyping" because to get started with
python, you simply write:

x = 3

"See! No handwaving with types!"

So I changed his file extension from .py to .hs and loaded it with
GHCi. We continued down this path; while I took advantage of the
richer libraries of haskell and more amenable syntax (for example, try
to achieve point-free or compositional programming in python; yeah
exactly). It wasn't long before there were bugs in the python code and
it was also messier. I invited him to try again. Same result again.

Unfortunately for him, he called me names and ran away. He didn't come
out of his office after that and I quit that job. I haven't seen him
since.

- --
Tony Morris
http://tmorris.net/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1RCBoACgkQmnpgrYe6r63NOwCdG5OwpEMOUTtl/mxAwZLzQJ/l
TFQAoKjjKiCiBvTYN4hNcNGNEPkenqiP
=ofPC
-----END PGP SIGNATURE-----

[Mirko Stocker]

I agree with you. My experience is that people are using "dynamic languages"
because they were scared away by very verbose and cumbersome statically typed
languages like Java to more fun-looking languages like Ruby. Not because they
actually need the dynamic parts, but more as some kind of protest and
demarcation against the established business/enterprise programming cultures.

Cheers,

Mirko

--
Mirko Stocker | m...@misto.ch
Work: http://ifs.hsr.ch | http://infoq.com
Personal: http://misto.ch | http://twitter.com/m_st

[Paul Butcher]

This is an excellent opportunity to point you at my favourite paper on this subject "What To Know Before Debating Type Systems" :-)

http://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/

--
paul.butcher->msgCount++

Snetterton, Castle Combe, Cadwell Park...
Who says I have a one track mind?

http://www.paulbutcher.com/
LinkedIn: http://www.linkedin.com/in/paulbutcher
MSN: pa...@paulbutcher.com
AIM: paulrabutcher
Skype: paulrabutcher

[Philippe Lhoste]

Somewhere in The Making of Python series of articles [1], Guido van Rossum explains why he
thinks dynamic typing is great. I should re-read them as I don't recall the exact arguments...

Still in Artima, I just found a small article [2] exposing some of the classical arguments
of dynamic typing and showing (in accompanying slides, not seen yet) how the same things
can be done in Scala...

From an uninformed point of view, to bring back the discussion on Scala, where, if I
understood correctly, dynamic typing have been introduced in trunk in some form or other,
I think one possible interest of dynamic typing is to avoid using reflection in some
cases, like building dynamically a data structure from some hierarchical markup language
(XML, Json, Yaml, etc.).

[1] http://www.artima.com/intv/pythonP.html
[2] http://www.artima.com/weblogs/viewpost.jsp?thread=253855

--
Philippe Lhoste
-- (near) Paris -- France
-- http://Phi.Lho.free.fr
-- -- -- -- -- -- -- -- -- -- -- -- -- --

[Paul Butcher]

On 8 Feb 2011, at 06:42, HamsterofDeath wrote:

> maybe i don't see the obvious, but .... i don't see an advantage. none
> at all. what can one possibly achieve by inviting runtime errors?

(assuming that you've now read that link that I posted :-)

Bear in mind that anyone who is on this list (including me) is likely to be pro static typing, so you may not get a particularly balanced view here. Having said that, I've spent a great deal of time writing code in dynamically typed languages (primarily Ruby, but also Python and various Lisp variants) so I hope that I have a reasonable grounding in both cultures.

If you want one concrete example of something that's much easier to achieve in a dynamically typed language, take a look at mocking frameworks. Indeed, the framework that I've been discussing on this list over the last few days, even though it's written in Scala, is effectively dynamically typed (it passes AnyRefs around and casts them to what they "should" be at runtime).

If there's a way to achieve this without resorting to dynamic typing (or extra-linguistic techniques such as runtime code generation or a compiler plugin), I certainly don't know what it is. Although I'd be delighted if someone could point me in the right direction if it is possible.

[Tony Morris]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/02/11 20:44, Paul Butcher wrote:
> If there's a way to achieve this without resorting to dynamic
> typing (or extra-linguistic techniques such as runtime code
> generation or a compiler plugin), I certainly don't know what it
> is. Although I'd be delighted if someone could point me in the
> right direction if it is possible.

I know a way, but that depends on what you mean by mocking. By this, I
mean what underlying problem are you trying to solve by mocking?

I've seen a few answers to this, but there is one that stands out as
most popular: testing by quantifying against interface
implementations. Specifically, asserting that some property holds for
all instances of an interface. A noble goal indeed.

The short answer to your question is then,
"org.scalacheck.Arbitrary.arbFunction1" solves all problems that
mocking sets out to solve, although a little differently and more
effectively. I will attempt a brief explanation of why this is the case.

First, observe that an interface is a tuple of zero or more functions.
For example:

interface CharSequence {
def charAt(index: Int): Option[Char]
def first3Or(n: Int, or: => (Char, Char, Char)): (Char, Char, Char)
}

...is equivalent to the pair:

(Int => Option[Char], Int => (=> (Char, Char, Char)) => (Char, Char,
Char))

So then, the "quantification against interfaces" becomes
"quantification against tuples of functions."

With automated testing (not to be confused with xunit testing), we can
generate tuples of values for quantification if we can generate the
values to put in. This is because the notion of "generation" forms a
monad. So for the tuple (A, B, C) if we have generators for A, B and C
(genA, genB and genC), then we can get a generator for (A, B, C) as
follows:

for(a <- genA; b <- genB; c <- genC) yield (a, b, c)

Next the question becomes, can we get generators for functions (to
quantify over ala "mocking")?

If we formalise this question, we can get it down to the following
(important steps omitted here, but they are covered in the QC paper):

Can we inhabit this signature?
(T => Generator[A]) => Generator[T => A]

The answer is yes for a given useful definition of Generator.

In conclusion, if you accept this as a solution to the underlying
problem that "mocking" sets out to achieve, then the goal is certainly
achievable within a static type system (I have even implemented this
in Java). Indeed, it is static typing that makes it even more useful
than otherwise. So not only have you a solution within a static type
system, but it is significantly more thorough in the objective
(program correctness verification) and it also requires less effort on
your behalf (automation).

For more, see ScalaCheck, QuickCheck and automated specification-based
testing. The Java implementation, including an arbitrary generator for
function values, is in the Functional Java project. I have also
written this in python at a previous place of employment, but it is
useless/impractical in my opinion.

I hope that helps.

- --
Tony Morris
http://tmorris.net/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1RJwAACgkQmnpgrYe6r61uiwCfcpw3IJQC3KwZ7ivlla6m2wse
3OAAnRcJRrUYiFUtizogUHMThypUK7Gn
=/l69
-----END PGP SIGNATURE-----

[Paul Butcher]

On 8 Feb 2011, at 11:20, Tony Morris wrote:
> I know a way, but that depends on what you mean by mocking. By this, I
> mean what underlying problem are you trying to solve by mocking?

I am familiar with ScalaCheck (although I've not used it in anger). I can see how it's a really useful tool for testing functional code. I'm struggling to see how it could solve the kind of problem that mocks (using the more traditional meaning of the word) address for code with side-effects.

This is probably best illustrated with an example. Imagine that I'm writing the control system for a nuclear missile installation. I'm trying to test the code that launches the ICBMs when the Big Red Button is pressed. Clearly I would rather avoid the side-effect of destroying the world each time I run my test suite :-)

Here's how I would do this with traditional mocks:

> trait Launcher {
> def launch(): Unit
> }
>
> class UserInterface(launcher: Launcher) {
> def bigRedButtonPressed() { ... }
> }
>
> "The Big Red Button" should {
> "launch ICBMs" in {
> val mockLauncher = mock[Launcher]
> mockLauncher.expects('launch).once
>
> val ui = new UserInterface(mockLauncher)
> ui.bigRedButtonPressed
> }
> }

This test should pass if and only if the launch function is called exactly once.

I'm not sure how I could achieve this with the approach you outline?

[Philippe Lhoste]

On 08/02/2011 11:44, Paul Butcher wrote:
> (assuming that you've now read that link that I posted :-)

Personally, this reminder sent me back to your previous message and I am happy to have
followed the link, as I find that you captured well most of the debate.

> If you want one concrete example of something that's much easier to achieve in a

dynamically typed language, take a look at mocking frameworks. [...]

>
> If there's a way to achieve this without resorting to dynamic typing (or
extra-linguistic techniques such as runtime code generation or a compiler plugin), I
certainly don't know what it is. Although I'd be delighted if someone could point me in
the right direction if it is possible.

Indeed, I mentioned reflection to build classes but now I doubt we can do that (it can
change visibility and such, but not sure about creating fields for example).

IIRC, most Java-based mocking frameworks use bytecode instrumentation to generate the objects.

[Lex]

What nobody mentions is that languages with dynamic typing are perceived as EASIER to use and are DESIRABLE by the general population. There is plenty of empirical evidence to back that up: just look at all the people using said languages. There is not smoke without a fire. If people are using something means it meets their needs (or they think it does) and they see no compelling reasons to switch.

I see people criticizing dynamic languages without ever spending enough time to try one. Yet, one of the most common reactions when someone says "Scala is too complicated" is "They haven't given it an good try". Maybe we should all give dynamic languages a good try, note the features that makes them being perceived as "easier" and try to add these features to Scala using libraries. Of course, not everything should make it across, and things like "monkey patching" are best left alone.

Another interesting aspect of this never ending debate is the question: What makes Scala better than Java?

- Omitting type declarations when declaring variables (also true for dynamic languages to a greater extent).

- Closures (...also available in dynamic languages).

- Passing functions to manipulate collections (also present in many dynamic languages).

I am sure you can come up with many more.

So many features Scala shares with dynamic languages make it more attractive than Java. Does anyone recall the typical response from the Java community when any of these features come up?

"Closures: it can be done in Java but with more code."

"Omitting types: we don't need that."

"Passing functions around: this is too complicated and hard to debug."

If this attitude feels familiar, you should take the time and try (I mean really try) a dynamic language of your choosing.

[Brian Maso]

One big difference I've noticed between strongly-typed and weakly-typed languages: programmers who don't have a good foundation in programming with strongly-typed languages can't produce solutions very quickly or very well in strongly-typed languages, compared to what they can accomplish in weakly-typed languages.

Considering the vast armies of old VB programmers, as well as the newly-forming armies of JavaScript and PHP programmers, who I am positive would not be very effective using a strongly-typed language like Scala, there's little doubt these programmers would be able to generate solutions efficiently ot effectively without a weakly typed language.

Brian Maso

--
Best regards,
Brian Maso
(949) 395-8551
br...@blumenfeld-maso.com

[√iktor Klang]

On Tue, Feb 8, 2011 at 4:47 PM, Brian Maso <br...@blumenfeld-maso.com> wrote:

One big difference I've noticed between strongly-typed and weakly-typed languages: programmers who don't have a good foundation in programming with strongly-typed languages can't produce solutions very quickly or very well in strongly-typed languages, compared to what they can accomplish in weakly-typed languages.

That's never a good thing in my book.
Productivity unrelated to product quality is pointless.
 

Considering the vast armies of old VB programmers, as well as the newly-forming armies of JavaScript and PHP programmers, who I am positive would not be very effective using a strongly-typed language like Scala, there's little doubt these programmers would be able to generate solutions efficiently ot effectively without a weakly typed language. 

Brian Maso

On Tue, Feb 8, 2011 at 2:44 AM, Paul Butcher <pa...@paulbutcher.com> wrote:

On 8 Feb 2011, at 06:42, HamsterofDeath wrote:

> maybe i don't see the obvious, but .... i don't see an advantage. none
> at all. what can one possibly achieve by inviting runtime errors?

(assuming that you've now read that link that I posted :-)

Bear in mind that anyone who is on this list (including me) is likely to be pro static typing, so you may not get a particularly balanced view here. Having said that, I've spent a great deal of time writing code in dynamically typed languages (primarily Ruby, but also Python and various Lisp variants) so I hope that I have a reasonable grounding in both cultures.

If you want one concrete example of something that's much easier to achieve in a dynamically typed language, take a look at mocking frameworks. Indeed, the framework that I've been discussing on this list over the last few days, even though it's written in Scala, is effectively dynamically typed (it passes AnyRefs around and casts them to what they "should" be at runtime).

If there's a way to achieve this without resorting to dynamic typing (or extra-linguistic techniques such as runtime code generation or a compiler plugin), I certainly don't know what it is. Although I'd be delighted if someone could point me in the right direction if it is possible.

--
paul.butcher->msgCount++

Snetterton, Castle Combe, Cadwell Park...
Who says I have a one track mind?

http://www.paulbutcher.com/
LinkedIn: http://www.linkedin.com/in/paulbutcher
MSN: pa...@paulbutcher.com
AIM: paulrabutcher
Skype: paulrabutcher

--
Best regards,
Brian Maso
(949) 395-8551
br...@blumenfeld-maso.com

--
Viktor Klang,
Code Connoisseur
Work:   Scalable Solutions
Code:   github.com/viktorklang
Follow: twitter.com/viktorklang
Read:   klangism.tumblr.com

[Clint Combs]

Most of the features that I hear people raving about regarding dynamic languages are related to the syntax and not the semantics.  I've said before that "Scala is what I was looking for when I found Groovy."  Needless to say, I'm glad I subsequently found my way into the Scala community.

For me, Scala provides the syntactic feel of a dynamic language with the semantics of a static language.  That's the right fit for me.

-Clint

[Tim Underwood]

I totally agree with this.  My original draw to Ruby from Java was all about cleaner syntax.  For me, that cleaner syntax lead to productivity gains during initial development but made longer term maintenance much harder due to the lack of typing information and ease of generating runtime errors that should have been caught by a compiler.

Back then I always said that I wanted the static typing of Java with the cleaner syntax of Ruby.  Scala provides that for me.

-Tim

[Jim Powers]

Meta programming allowed in the discussion?  ;-)

There are a number of things I like about Lisp macros that I miss terribly in Scala.  I've looked at Template Haskell, but it really is not the same thing.  Writing code that can examine the code around it (essentially local compiler extensions) without having to actually hack the compiler is really nice.  The various approaches to DSLs in pretty much every other language either: are not equivalent to Lisp macros (by design) or can do what Lisp macros can do in some non-obvious ways.

This said, I like Scala a lot, I wish it was more like Haskell (especially with function currying), and I use it every day as part of my job.  For me it has made the JVM a generally pleasant place to live.

--

Jim Powers

[Razvan Cojocaru]

The only possibly useful use of dynamic types I encountered was writing some
glue for some ActiveX components, some decades ago, in Visual Basic. You are
able to bypass any discovery, interface generating and importing and all
that stuff and just write down two lines of glue that work in like Excel,
with all the risks involved.

So you can do something like
Let object = // somehow dynamically discover an ActiveX called
"mine" in the current environment
object.doThis (1,2,3)

I guess, since the scala.nsc.tools.Interpreter is just one <<set (object,
XXX) andThen eval( "object.doThis (1,2,3)" )>> call away, we can easily do
that in scala as well :)

Cheers,
Razie

[Mike]

http://xkcd.com/353/

[Clint Combs]

Hehehe... enjoyed that.  Hmmm... I wonder.  Does Scala feels like Python with a parachute?

-Clint

On Tue, Feb 8, 2011 at 2:07 PM, Mike <fort...@good-with-numbers.com> wrote:

http://xkcd.com/353/

[Alex Boisvert]

Probably like many of you, I've had a fair number of discussions with dynamic-typing advocates.  To those I talk to, the question is "why static typing?".  Assuming we're past the boilerplate/verbosity argumentation, I hear mostly three things:

1) They generally find static typing gets in the way of free expression.  With dynamic typing, they can structure applications in different ways that are more suitable to the problem at hand.  Metaprogramming quickly becomes an integral part of the discussion.

2) They generally don't find static typing to be a "good enough" safety net (worth sacrificing free expression) and they find that they need to write about the same amount of test code to get to the same level of quality.

3) They generally dislike the tool-heavy orientation of static languages (incl. compilation, code generation, annotation processors, slow/heavy IDEs, etc.) and prefer to be able to hack everything as part of the runtime environment.  To them, the separation between compile-time and run-time seems like a detriment.

I do use and like dynamic languages and I do find some measure of truth in all the above arguments.   But please don't take me up on these arguments, as I don't want to debate them personally.   I'm generally on the static typing side of the argumentation unless I find somebody who'll boldly claim that static languages are superior in every respect and that all languages should be statically typed.

alex

[HamsterofDeath]

Am 08.02.2011 20:45, schrieb Alex Boisvert:
> Probably like many of you, I've had a fair number of discussions with
> dynamic-typing advocates. To those I talk to, the question is "why
> static typing?". Assuming we're past the boilerplate/verbosity
> argumentation, I hear mostly three things:
>
> 1) They generally find static typing gets in the way of free
> expression. With dynamic typing, they can structure applications in
> different ways that are more suitable to the problem at hand.
> Metaprogramming quickly becomes an integral part of the discussion.

we demand an example

[Russ Paielli]

On Tue, Feb 8, 2011 at 12:33 AM, Tony Morris <tonym...@gmail.com> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/02/11 17:48, Russ Paielli wrote:
> Dynamic typing lends itself to rapid prototyping and generally
> getting small-to-medium-sized, non-critical applications up and
> running faster.

For the benefit of the curious, this particular statement is both very
popular and very not true in the veriest sense.

I beg to differ. The rapid prototyping capability of, say, Python is well known. It may or may not constitute a significant advantage over Scala (or Haskell), but that's a separate issue from the truth of the statement quoted above.

Personally, I would favor Scala over Python even for rapid prototyping, but I know at least one very competent aeronautical research engineer who uses Python to prototype advanced concepts in air traffic management. His focus is on the concepts and algorithms, and he feels that Python is the fastest and cleanest way to prototype them. I suspect he would appreciate Scala too if he tried it, but he just hasn't perceived the need yet.

Python is also very popular among scientists and engineers who use Numpy and Scipy for advanced calculation and rapid prototyping. These people may or may not be misguided, but I think we can safely assume that most of them are not simple-minded dolts.

[Jim Powers]

Garg!  Meant to reply to the list

Rails ActiveRecord - Active record creates objects on the fly with attributes (getters and setters) based on "what came back" from a SQL query.

For instance:

If I instantiate an AR object tied to the following SQL:

SELECT bar, baz FROM foo

My resulting AR objects will respond to bar and baz:

row = Foo.find(...)

row.bar # works

row.baz # works

Now, say you use the following SQL

SELECT bar, baz, <computed expression> goo FROM foo

row = Foo.find(...)

row.bar # works

row.baz # works

row.goo # works!

Now, mind you, one could easily do the equivalent in Scala using Maps (or some-such), after all the meta-programming being done for you (code writing code) is just syntactic sugar right?

val row = Foo.find(...) // returns Map[String,Any]

Now you have to type-cast values:

row.get("bar").asInstanceOf[Option[String]]

Or some such (Mind you this is not a particularly efficient encoding, but we can ignore that for this discussion).

An alternative is "classic" ORM:

class FooRow(val bar:String, val baz:Int)

But what about the second case?  Well, either create a second type of FooRow (then three, four five, etc.) or just aggregate all the possible variations as Options into the first.  Less than exciting boilerplate work.

Alternatively you could just project through tuples:

superSQLFunction("SELECT bar, baz FROM foo")(asString("bar"),asInt("baz")) match {

  case (bar,baz) => ...

}

Which isn't horrible except when you don't know what your SQL will look like to begin with:

superSQLFunction(comptedSQL)(???) match {

  case (???) => ...

}

Where the expected result is a function of what SQL is passed to the superSQLFunction

Static typing vs dynamic typing often (not always) boils down to early vs late binding (or early vs late decisions on the structure of things)

No doubt that many complaints can be raised against the examples I just used but the reality is that a considerable amount of software development occurs (successfully, mind you) in just such a loosy-goosy fashion.  That said, such success does not refute the benefits of static typing.

-- 

Jim Powers

[Tony Morris]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/02/11 00:51, Lex wrote:
> it meets their needs (or they think it does)

What you have parenthesised there is a crucial distinction.

- --
Tony Morris
http://tmorris.net/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1RtkUACgkQmnpgrYe6r61qqgCgtaD34w4pq9qvvq0E96vsUDm6
WOcAn3faU5/xmH8rJCK+HNpUOZw20z6i
=/dDH
-----END PGP SIGNATURE-----

[Tony Morris]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yeah things change a little once we start talking about side-effects.
Nevertheless, the situation is being addressed.
http://www.cse.chalmers.se/~rjmh/Papers/QuickCheckST.ps

- --
Tony Morris
http://tmorris.net/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1RtycACgkQmnpgrYe6r60XrACdFrMv1QywSGj/k6aGxExOcDoF
99EAn10aOzmkyyVuMpJIG/qUXd5keFLk
=ccb8
-----END PGP SIGNATURE-----

[Tony Morris]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

One thing I have found is that programmers who have a good foundation
in programming, and this includes type theory, intuitonistic log,
would rarely choose a language without significant machine-checked
static verification (call that weakly typed if you like) for practical
productive use.

- --
Tony Morris
http://tmorris.net/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1Rt7MACgkQmnpgrYe6r63WMgCgp/n6ppR49zwOvkjzIhj2a7F8
lf8AoMWNBSQ/T8DiM3DwZpA3b9/atXpI
=S4v7
-----END PGP SIGNATURE-----

[Tony Morris]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/02/11 07:19, Russ Paielli wrote:
> On Tue, Feb 8, 2011 at 12:33 AM, Tony Morris <tonym...@gmail.com>
> wrote:
>
>>
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>
>> On 08/02/11 17:48, Russ Paielli wrote:
>>> Dynamic typing lends itself to rapid prototyping and generally
>>> getting small-to-medium-sized, non-critical applications up
>>> and running faster.
>> For the benefit of the curious, this particular statement is both
>> very popular and very not true in the veriest sense.
>>
>>
> I beg to differ. The rapid prototyping capability of, say, Python
> is well known.

I think if you interview those with a solid understanding of the
underlying computability theory, you'd get a different result. Even
so, "well known" does contribute anything.

> It may or may not constitute a significant advantage over Scala
> (or Haskell), but that's a separate issue from the truth of the
> statement quoted above.

It doesn't. I prototype my Scala with Haskell all the time. And here
is one of the major reasons why: when I screw up, the type system
shouts at me in a very informative way. There are a zillion other reasons.

Let's be clear, I have used python in depth. I have never met an
well-informed argument that claims it is useful for rapid prototyping.
Not even close. Surprise me.

>
> Personally, I would favor Scala over Python even for rapid
> prototyping, but I know at least one very competent aeronautical
> research engineer who uses Python to prototype advanced concepts in
> air traffic management. His focus is on the concepts and
> algorithms, and he feels that Python is the fastest and cleanest
> way to prototype them. I suspect he would appreciate Scala too if
> he tried it, but he just hasn't perceived the need yet.

I'm not sure why this is mentioned. The original statement remains false.

>
> Python is also very popular among scientists and engineers who use
> Numpy and Scipy for advanced calculation and rapid prototyping.
> These people may or may not be misguided, but I think we can safely
> assume that most of them are not simple-minded dolts.

There is a distinction between "being wrong" and being "simple-minded
whatever." The entire reason I use Haskell (practical static typing)
mostly in my work is because of the degree to which I am wrong. This
is a crucial factor in "rapid prototyping" and is the reason that even
Java trumps Python for such a task.

>
> --Russ P.
>

- --
Tony Morris
http://tmorris.net/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1RuesACgkQmnpgrYe6r61PpQCfUxCsNlMDgvRdQoAqolNgjM13
OvUAmwXfW3ORYuZwZBLiqnXwA3Oedowv
=TsbF
-----END PGP SIGNATURE-----

[Volodymyr Kyrychenko]

HamsterofDeath wrote:
> it's not related directly to scala, but what are the benefits of dynamic
> typing? what can you do that you can't with statically typed languages
> (especially scala)?

> maybe i don't see the obvious, but .... i don't see an advantage. none
> at all. what can one possibly achieve by inviting runtime errors?

Building objects/functions from some description that is external to the
code (SQL, WSDL, JSON).

Take a look at E4X. The thing is great.

So dynamic typing benefits mostly in the integration sphere - plugins
and so on.

--
Best Regards,
Volodymyr Kyrychenko

[Russ Paielli]

Tony,

You seem to be very oriented toward Haskell and functional programming. I'm curious about why you use Scala. Do you think Scala has any inherent advantages over Haskell, or do you perhaps use Scala only because it is the closest thing to Haskell that seems on its way to becoming a mainstream language? In other words, if you could choose your preferred language for any project you work on, would you ever choose Scala, or would you always choose Haskell? Also, do you recommend using the object-oriented features of Scala, or do you recommend using Scala for straight functional programming? Just wondering. Thanks.

--Russ P.

On Tue, Feb 8, 2011 at 1:08 AM, Tony Morris <tonym...@gmail.com> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/02/11 18:50, Dennis Haupt wrote:
> i was hoping for a piece of code that shows how easily it can be
> written using dynamic typing and then showing how troublesome it
> was if one were forced to use static typing.

Hi Dennis,
There is a reason that no such thing is forthcoming.

>
> so far i've read "less code, because you don't have to write the
> types" -> it's also potentially less readable & type inference can
> also achieve this

I didn't see anyone say that on this thread, but I have heard it
countless times. It's nonsense and demonstrates a lack of
understanding of type systems. For example, it is extremely rare that
one needs to write type annotations in haskell. There are also
languages where *you only write types*. You end up with less code and
proof of program correctness. How about that -- terse and correct!

> "faster prototyping" -> i disagree. i can write code quick & dirty
> in java which is the most cluttery language that i can handle. my
> ide takes care of writing a lot of the code for me.

That's because it's blatantly false, regardless of Java. These claims
merely invite education on the topic at hand.


====

To share an anecdote, I once worked with someone who told me that
dynamic typing was "great for prototyping" because to get started with
python, you simply write:

x = 3

"See! No handwaving with types!"

So I changed his file extension from .py to .hs and loaded it with
GHCi. We continued down this path; while I took advantage of the
richer libraries of haskell and more amenable syntax (for example, try
to achieve point-free or compositional programming in python; yeah
exactly). It wasn't long before there were bugs in the python code and
it was also messier. I invited him to try again. Same result again.

Unfortunately for him, he called me names and ran away. He didn't come
out of his office after that and I quit that job. I haven't seen him
since.

- --
Tony Morris
http://tmorris.net/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1RCBoACgkQmnpgrYe6r63NOwCdG5OwpEMOUTtl/mxAwZLzQJ/l
TFQAoKjjKiCiBvTYN4hNcNGNEPkenqiP
=ofPC
-----END PGP SIGNATURE-----

--
http://RussP.us

[Russ Paielli]

On Tue, Feb 8, 2011 at 1:47 PM, Tony Morris <tonym...@gmail.com> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Let's be clear, I have used python in depth. I have never met an
well-informed argument that claims it is useful for rapid prototyping.
Not even close. Surprise me.

Well, I'm not sure what you are looking for in an "argument." The question of how useful a language is for rapid prototyping is largely subjective. I've used Python myself for rapid prototyping, and it worked reasonably well. But as I said, I would now favor Scala.

Let me tell you where I got the idea that Python is well-suited to rapid prototyping. Several years ago, I was interested in Ada, and I invited a gentleman named Robert Dewar to give a talk on Ada to my organization. Dewar is a professor emeritis of CS at NYU, and he is (or was) also the president and CEO of AdaCore Technologies. During his talk, he mentioned in passing that Python is well-suited for rapid prototyping. He didn't elaborate on it, because it wasn't the subject of his talk, but I had already started using Python, and I was surprised by his statement.

No, that's not an "argument," but it is consistent with my own experience, and I consider it a significant data point.

By the way, Prof. Dewar is no "lightweight." In fact, he is somewhat famous in CS circles for his claims about the "dumbing down" of CS programs in US colleges. Check out this article:

http://itmanagement.earthweb.com/career/article.php/3722876/Who-Killed-the-Software-Engineer-Hint-It-Happened-in-College.htm

Here is an excerpt:

A conversation with Robert Dewar is enough to make you wonder about the future of the American software engineer. Dewar, a professor emeritus of computer science at New York University, believes that U.S. colleges are turning out programmers who are – there’s no nice way to say this – essentially incompetent.

--Russ P.

--
http://RussP.us

[Jim Balter]

On Mon, Feb 7, 2011 at 11:03 PM, Tony Morris <tonym...@gmail.com> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/02/11 16:42, HamsterofDeath wrote:
> it's not related directly to scala, but what are the benefits of
> dynamic typing? what can you do that you can't with statically
> typed languages (especially scala)? maybe i don't see the obvious,
> but .... i don't see an advantage. none at all. what can one
> possibly achieve by inviting runtime errors?
>
>
>

Not all programs can be represented by a given terminating static type
system. Scala's type system is turing-complete, involving
non-termination. Runar Bjarnason recently proved this by encoding the
SK combinator calculus, which is known to be turing-complete.

In practice, and for a sufficiently practical type system, these
instances of programs that cannot be encoded are rare and so the
advantages of dynamic typing might best be paraphrased, "allows
expression of esoteric programs."

But virtually no one who prefers dynamic typing prefers it for that reason, so that is simply wrong -- what matters is *how* something can be expressed, not *whether* it can be expressed. People who ask "what can't you do" are playing on the wrong ball field. Consider, for example, the primary advantage of static typing -- early error detection. That has nothing to do with what you can or cannot do, but rather with issues external to the computation itself, issues that are about *us*, the human developers, and the costs and effectiveness of our efforts.

Proponents of dynamic typing may well be mistaken about any advantages it confers, but let's not misrepresent what advantages they *think* it has.
 

Unfortunately for progress in this
area, and for reasons for which I can only offer conjecture, these
cases are thought to be more common than is actual.

Again I think this is simply wrong. Proponents of dynamic typing don't think their programs cannot be written in static typed languages, they just think that various development benefits would be lost, just as proponents of static typing think the inverse.
 

PS: I hope you're aware of the onslaught that you've invited.

There would have been an ever greater one if he had lobbed this bomb into a Python or Ruby list. :-) But either way it's classic flame bait, like asking an emacs list why anyone in their right mind would use vi. I don't think that people who post such things actually want to know -- they are already convinced of a view and just want it confirmed. In any case, it belonged on scala-debate, if anywhere, but not here.

-- Jim

[Jim Balter]

On Tue, Feb 8, 2011 at 12:30 AM, Paul Phillips <pa...@improving.org> wrote:

On 2/7/11 11:48 PM, Russ Paielli wrote:

Then there's "monkey patching." I googled it once, but I forgot what it is,
and I have no intention of ever doing it.

This evening, on Scala Programmers After Dark: True Confessions! Tonight's topic: Are you curious about "monkey patching"? Hear what others will admit when given dark glasses and dim lighting!

"I googled it once."
"I forgot what it is."
"I have no intention of ever doing it!"

Also be sure to join us next week, when we will ask leading scala lumniaries about "hot fixes".

Ah, but actually knowing what these things are is irrelevant to formal proofs that statically typed languages are Turing Complete and thus irrelevant to those who like to pretend that that's what it's all about. They can ignore the existence of systems like Smalltalk that can run with accumulated changes indefinitely and they can thus pretend that there's no reason why anyone with any sense could possibly like dynamic typing.

-- Jim

[Matthew Pocock]

The dynamically typed langauges that I have used the most and am most familiar with are Perl and Javascript. In both cases, I find the time needed to get 'something, anything' working from scratch is very short compared to Java, and in practice short compared to Scala. This is the first 10% of sketching things out. The next 80% of the development is similar in speed to Java or Scala, become relatively slow as you go, but where as issues tend to be caught at run-time in dynamic languages, they tend to be caught at compile-time in static languages. Indeed, I aggressively refactor Scala code to make as many bugs I've introduced and found as possible manifest as type errors. When I get down to that final 10% (which of course nobody outside of formal methods applied to ATMs, missile guidance and nuclear reactors actually gets close to completing), I find dynamically typed languages are utterly impossible but with strong typing you have a fighting chance.

Oh, and I couldn't take on a 100k+ line project in a dynamic language, as I could never navigate the calls. I'd have a fighting chance of doing it with a statically typed language, as the IDE can figure out the inter-object calls and some of the data flow for me.

I have been involved in a number of large code-bases in a whole range of languages, and personally for anything large or mission-critical, I would go strongly-typed every time. For throw-away code, you test it by running it, so dynamically typed is just fine and the overhead of working with an intrusive type system and a heavy tool-chain that tends to come with strongly-typed languages can be prohibitive.

As a very wise man once said, "the plural of anecdote is not evidence".

Matthew

--

Matthew Pocock

mailto: turingate...@gmail.com

gchat: turingate...@gmail.com

msn: matthew...@yahoo.co.uk

irc.freenode.net: drdozer

(0191) 2566550

[Tomás Lázaro]

I stil don't understand when people say it's faster to prototype in dynamic languages.

All I hear is "I'M fast with Python"...

Well I'm not, I'm slow because I don't know their API, because it's hard to understand and browse their API and at every method I call I have now idea what to expect from it and how to treat it and won't know until I run it.

I'm really fast with Scala and Java because I know their API and language and use good tools like IDEs to speed up the process. I can even throw some lines into the REPL for quick testing or test small "script like" Scala code on the run.

In the end all arguments come down to personal experience.

Is it really faster because you use Python or is it that you just now it?

Is compile time the problem? That's the only reasonable time saver mentioned (which is highly debatable)

Like Tony Morris said "Let's be clear, I have used python in depth. I have never met an well-informed argument that claims it is useful for rapid prototyping. Not even close. Surprise me."

[Tomás Lázaro]

Perhaps the "fast prototyping" was born from a comparison with C++ and wrongly generalized?

Synchronizing .h with .cpp is a mayor pain. Every method you introduce or modify takes a lot of time. And C++ constantly dis encourages you to create a new method because of that.

2011/2/9 Tomás Lázaro <tlaz...@gmail.com>

[Jim Powers]

2011/2/9 Tomás Lázaro <tlaz...@gmail.com>:

Racket: http://racket-lang.org/ Q.E.D. ;-)

--
Jim Powers

[Craig Tataryn]

On 2011-02-08, at 8:51 AM, Lex wrote:

> What nobody mentions is that languages with dynamic typing are perceived as EASIER to use and are DESIRABLE by the general population. There is plenty of empirical evidence to back that up: just look at all the people using said languages. There is not smoke without a fire. If people are using something means it meets their needs (or they think it does) and they see no compelling reasons to switch.

> I see people criticizing dynamic languages without ever spending enough time to try one. Yet, one of the most common reactions when someone says "Scala is too complicated" is "They haven't given it an good try". Maybe we should all give dynamic languages a good try, note the features that makes them being perceived as "easier" and try to add these features to Scala using libraries. Of course, not everything should make it across, and things like "monkey patching" are best left alone.
>
> Another interesting aspect of this never ending debate is the question: What makes Scala better than Java?
> - Omitting type declarations when declaring variables (also true for dynamic languages to a greater extent).
> - Closures (...also available in dynamic languages).

> - Passing functions to manipulate collections (also present in many dynamic languages).

I think a statically typed functional language like Scala really shines because functions are strongly typed. You know what you are getting because you say "I want a function that takes these parameters, and returns this type". As a callee in Ruby/Javascript you really can't guaranty you are getting an appropriate function passed to you without a bunch of runtime checks. In Scala you know at compile time whether things are peachy. When I presented the Scala Language Tour [1] to a Ruby UG, the oooos and ahhhs came after I showed them that functions are not just a generic honeypot, but are instead specific types based on parameters and return type.

Now, one can argue that *defining* the type of the function is really the equivalent of implementing the runtime checks... but my point is I am forced to *ensure* type-safety in Scala whereas I have to *remember* to in Ruby/JS.

The other argument I hear is "unit tests ensure type safety in dynamic languages". Ok, I kind of buy that, unit tests are good, but only as good as you can write them ;) I like my unit tests to focus on functionality, not language typing problems.

Craig.

[1] - http://basementcoders.com/2010/11/scala-language-tour/

[Jim Powers]

On Wed, Feb 9, 2011 at 12:18 PM, Craig Tataryn <cra...@tataryn.net> wrote:
> I think a statically typed functional language like Scala really shines because functions are strongly typed.  You know what you are getting because you say "I want a function that takes these parameters, and returns this type".    As a callee in Ruby/Javascript you really can't guaranty you are getting an appropriate function passed to you without a bunch of runtime checks.  In Scala you know at compile time whether things are peachy.  When I presented the Scala Language Tour [1] to a Ruby UG, the oooos and ahhhs came after I showed them that functions are not just a generic honeypot, but are instead specific types based on parameters and return type.
>
> Now, one can argue that *defining* the type of the function is really the equivalent of implementing the runtime checks... but my point is I am forced to *ensure* type-safety in Scala whereas I have to *remember* to in Ruby/JS.
>
> The other argument I hear is "unit tests ensure type safety in dynamic languages".  Ok, I kind of buy that, unit tests are good, but only as good as you can write them ;)  I like my unit tests to focus on functionality, not language typing problems.

Well, it does go further than that to be fair. All that typing also
helps the compiler generate more efficient code (by a considerable
margin). Everything in Ruby is dynamic dispatch (message passing) and
you really only discover things go wrong at run time and it's
basically impossible to optimize.

--
Jim Powers

[Ittay Dror]

One thing I found nice when working in Ruby is that I could easily fix 3rd party code. Just rewrite the method in the required class and the bug is gone.

Ittay

[Ittay Dror]

After reading the thread, I think the main benefit of dynamic languages is that you need to know less before starting to program in them:
* no need to learn much about type systems
* no need to know how to set up a build system
* less need to design well - these languages lend themselves more easily to hacking ("oh, i've got an instance with a missing method, well, i'll just add it now")
* quicker way to learn as you type - no compilation, just reload the page etc.

Ittay

[Jim Powers]

On Feb 9, 4:41 pm, Ittay Dror <ittay.d...@gmail.com> wrote:
> After reading the thread, I think the main benefit of dynamic languages is
> that you need to know less before starting to program in them:
> * no need to learn much about type systems

Not completely true. In dynamic systems *values* have type but
*variables* (and other compile-time identifiers) do not.

> * no need to know how to set up a build system

Again, not completely true. Some Scheme implementations are only
"ahead-of-time" compilers, for instance Stalin[1].

> * less need to design well - these languages lend themselves more easily to
> hacking ("oh, i've got an instance with a missing method, well, i'll just
> add it now")

This is a matter of opinion. For instance there are many many Rails
script monkeys that would disagree. I think that a healthier attitude
is to accept the fact that there are many skilled programmers working
with dynamic languages. Taking a default position that using a
dynamic language intrinsically produces bad design does nothing to
welcome dynamic language programmers to the world of Scala, Haskell,
OCaml, etc.

Take a look at the results of this year's Google AI challenge:
http://ai-contest.com/ - The winner used Lisp, but the leader board
is typically dominated by C++ and Java. The ML-inspired languages
placed behind them. The point is not about Lisp, it's about making
the mistake of attributing the use of dynamic languages as a reason to
dismiss programmers who use them or the programs they write. For
instance, Google Groups is substantially written in Python.

> * quicker way to learn as you type - no compilation, just reload the page

Mostly yes, see my point about build systems above.

[1] http://community.schemewiki.org/?Stalin

[HamsterofDeath]

you call it a benefit, i call it a maintenance nightmare. think about
"benefit" no. 3. what could go wrong if, let's say, 3 developers share
the same thought and add that missing method randomly to instances that
come floating by? 3 different implementations of the same method, with
slight differences in their runtime behaviour, depending on the order of
places the instance has visited so far.

[Tony Morris]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/02/11 02:08, Tom�s L�zaro wrote:
> I stil don't understand when people say it's faster to prototype in dynamic
> languages.

Argumentum ad ignorantiam. It doesn't get any easier than that.

- --
Tony Morris
http://tmorris.net/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1TGiIACgkQmnpgrYe6r62StACgxcsK4GVRZ3Q84sPM5rt581IJ
S5cAn0Dyy3gPJdbUUxcT3xmKRodYBVkS
=hftG
-----END PGP SIGNATURE-----

[Razvan Cojocaru]

I don't quite see those as a benefit though. It just means the person is less serious about programming (no knowledge of type systems) or about the system (no design).

If we're talking about rapid prototyping and rapid application development, static typing is the least of one's worries.

Having an environment where the UI is designed quickly, persistency generated automatically and all those other things one needs are automated, that's what gives you whatever speed you're looking for here. If you just want to hack text and syntax that may or may not work, then nothing can stop you but don't tell me that's what makes you more efficient.

That's not it! The environment, libraries and tools ( including automated build and deployment tools) make the difference.

Type swing java code in vi and you're just as hopeless and slow as doing JavaScript web apps in whathaveyou. Once it compiles you know it *may* work but throw nullpointers...While the JavaScript thing - well, there's no knowing that it would even work.

Resilience to change and content assist can be implemented even in JavaScript with the right tools, it's just that its not enforced by a compiler. Same as swapping the wrong jar file at runtime and getting "method not found" exceptions.

...I forget, what were we arguing here?

Oh, instant results. Much like fixing java code in the middle of an eclipse debugging session and continue with the fixed code, after eclipse deployed the fix and instantly rolled back to the caller? Can your python interpreter do that? Or it starts over again?

I don't see a big difference between properly test-harnessed and continuously integrated apps of either static or dynamic type.

So I don't think any of the things said here are what the real difference is ... The seriousness and completeness of the environment makes the difference! The specificity and applicability of the language to the problem domain, including libraries is!

Having said that, without a compiler to double check my wiring I feel like writing assembly on paper :)

And as a last note, dynamic languages I've seen tend to *not* have the level of development support usually associated or expected from static ones.

Thanks,
Razvan

[Jim Powers]

On Feb 9, 5:59 pm, Razvan Cojocaru <p...@razie.com> wrote:
> I don't quite see those as a benefit though. It just means the person is less serious about programming (no knowledge of type systems) or about the system (no design).

That is an unfortunate bias.

> If we're talking about rapid prototyping and rapid application development, static typing is the least of one's worries.

I disagree. Static typing imposes that you make decisions "early"
often resulting in a poor type zoo. The point of a (literal)
prototype is to explore the solution space then possibly throw away
the actual result and move forward with some better understanding.

> Having an environment where the UI is designed quickly, persistency generated automatically and all those other things one needs are automated, that's what gives you whatever speed you're looking for here. If you just want to hack text and syntax that may or may not work, then nothing can stop you but don't tell me that's what makes you more efficient.
>
> That's not it! The environment, libraries and tools ( including automated build and deployment tools) make the difference.

Certainly, all such goodness helps.

> Type swing java code in vi and you're just as hopeless and slow as doing JavaScript web apps in whathaveyou. Once it compiles you know it *may* work but throw nullpointers...While the JavaScript thing - well, there's no knowing that it would even work.

No doubt about that, but typically this does not happen. There's a
lot of JS out there running on a lot of browsers and the world has not
ended yet.

> Oh, instant results. Much like fixing java code in the middle of an eclipse debugging session and continue with the fixed code, after eclipse deployed the fix and instantly rolled back to the caller? Can your python interpreter do that? Or it starts over again?

OK, I'll bite: how about on-the-fly code augmentation, like instances
of objects being extended at run-time, as opposed to having to write
all that boiler plate or have a tool write it for you? How about code
that adds additional functionality only discoverable at run-time
(where the IDE is very much out of the picture)? Stuff like this is
the life-blood of the dynamic language programmer (whether that be
Lisp, Lua, Ruby, or whatever): writing code that writes the code, it
really is nice. Despite desires to the contrary it is surprisingly
effective.

I would presume (I cannot say for sure) that the example you cite
above about in-debugger updating of code could be applied to a number
of other languages on the JVM including, for instance, Clojure (I have
no idea about support to do this with Scala). It's really only a
matter of man-hours to achieving that goal. In the mean-time the
Clojure programmer goes about evolving their solution bit-by bit. It
really isn't as bad as it is being portrayed on this thread.

> I don't see a big difference between properly test-harnessed and continuously integrated apps of either static or dynamic type.

In a "prototype" situation often test-harnesses are optional. One is
seeking to explore the solution space.

> So I don't think any of the things said here are what the real difference is ...  The seriousness and completeness of the environment makes the difference! The specificity and applicability of the language to the problem domain, including libraries is!

Certainly such things have an impact. But riddle me this batman: Then
why choose *any* new language to work in at all? Scala's support in
IDEs is still way behind Java's and started out with no support at
all. Yet in the imaginings of potential Scala users a glimmer of "a
better way" emerged. The dynamic language programmer sees the same
thing in the toolchain they are using. It does really come down to
that.

> Having said that, without a compiler to double check my wiring I feel like writing assembly on paper :)

Understood, but having done a fair bit of Ruby, Perl, and various
forms of Lisp programming it is possible to live a productive and
healthy programming life in dynamic language land.

> And as a last note, dynamic languages I've seen tend to *not* have the level of development support usually associated or expected from static ones.

That is merely a result of the man-power not being applied. That
said, languages like Ruby are really hard to "properly cover" in an
IDE. Coverign the basics of a typical script using stuff from known
libraries, possibly, covering all the cases of meta-programming that
typical Ruby programs employ is neigh impossible.

[Randall R Schulz]

To me, all these things add up to programming by bluff. If nothing calls
your bluff at an inopportune time, you may congratulate yourself on a
job well done.

And if you believe that it is better to be lucky than good, then this
will appeal to you.

It does not appeal to me.

Note that nothing I've said is about the relative virtues of so-called
dynamic languages vs. so-called static ones. But if this is your
approach to programming, choice of language or language characteristics
aside, then I think it does just amount to programming via bluff and
bluster.

Randall Schulz

[Ittay Dror]

Randall R Schulz wrote:
> On Wednesday February 9 2011, Ittay Dror wrote:
>> After reading the thread, I think the main benefit of dynamic
>> languages is that you need to know less before starting to program in
>> them: * no need to learn much about type systems
>> * no need to know how to set up a build system
>> * less need to design well - these languages lend themselves more
>> easily to hacking ("oh, i've got an instance with a missing method,
>> well, i'll just add it now")
>> * quicker way to learn as you type - no compilation, just reload the
>> page etc.
>>
>> Ittay
> To me, all these things add up to programming by bluff. If nothing calls
> your bluff at an inopportune time, you may congratulate yourself on a
> job well done.

You can bluff in statically typed languages as well: NPE,
ArrayIndexOutOfBounds, etc. Maybe static languages (esp. scala with,
e.g., Option) make it hard for you to bluff, but it comes down to good
design. And with good design you are also safe in a dynamic language.

What I feel dynamic languages lack are these:
* external analysis: which allows navigating between classes in the IDE,
code completion, early detection of typos/missing arguments etc. These
are important for a large code base
* good support for refactoring. for large code bases, when you refactor
a method, you want to be sure of all the places that use it.
* performance and optimizations
** Note: I wanted to link
http://shootout.alioth.debian.org/u32/javascript.php as proof, but it
seems that javascript is up to 70 times faster than java there...

[Vlad Patryshev]

Add IndexOutOfBoundsException for String in Java.

The problem is, it is a habit to use partial functions as if they are total. This is another are where Haskell shines, kind of.

2011/2/9 Ittay Dror <ittay...@gmail.com>

--
Thanks,
-Vlad

[Tony Morris]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

s/Haskell/Agda

To best understand the issues of the original question, learn a more
advanced language along with several different type systems with
various trade-offs. Python, Scala and friends do not cut it. This is a
plea in disguise.

- --
Tony Morris
http://tmorris.net/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1ToH8ACgkQmnpgrYe6r63ODQCgwGIHuVkmfuf767HcZp1DF48l
27YAnjFhqJmdnwTPtkA5+C62JVaCBy5B
=QbjJ
-----END PGP SIGNATURE-----

[James Strachan]

On 8 February 2011 06:42, HamsterofDeath <h-s...@gmx.de> wrote:
> it's not related directly to scala, but what are the benefits of dynamic
> typing?  what can you do that you can't with statically typed languages
> (especially scala)?
> maybe i don't see the obvious, but .... i don't see an advantage. none
> at all. what can one possibly achieve by inviting runtime errors?

Its a pretty emotive subject and given you're posting on a statically
typed language mailing list you're probably already preaching to the
choir. (Scala is my favourite language too BTW).

For me the main advantages of dynamic languages are:

* simplicity: you can pick up any decent dynamically typed languages
like CoffeeScript, JavaScript, Ruby, Python, Groovy et al in a few
hours typically. I've been doing Scala for a while and I still keep
learning things about the language and its type system. Scala is very
deep. Given their simplicity you feel you can master
JavaScript/Ruby/Groovy as a language pretty quickly as the language
doesn't do as much (though you then just spend a lifetime learning
APIs and trying to remember the names of methods :). There's
definitely a crowd of folks who just wanna get stuff done easily; for
them a simpler language has appeal.

* compiler speed: while this isn't true of all static and dynamic
languages, with Ruby / JavaScript / CoffeeScript apps, you hit reload
in your browser and everything reruns near instantly. e.g. to start
the CoffeeScript/JavaScript build tool Cake, re-generate the
CoffeeScript parser then run all its unit tests takes about 0.35
seconds on my laptop. You're typical JVM based language build tool has
barely even had chance to print that its starting to run by that time.
e.g. SBT takes 61 seconds to compile scalate-core on my laptop (1408
classes) after pausing for a few seconds before even deciding to
compile anything.

While I love Scala to bits, SBT is just about noticing you changed a
file by the time a typical Rails/JavaScript web app reloads itself and
renders itself on your browser. Scala's compiler is relatively slow
compared to dynamic languages - as its doing loads more things and it
generates much faster code at the end (so its a trade off really). But
when folks are building relatively small apps, just grabbing some data
from a database or web resource of some kind and painting it in a
browser the RADness of dynamic languages is very appealing due to the
very fast code-reload loop. Its also worth noting that in many typical
web apps; you've HTML, CSS, JavaScript/JSON, SQL to deal with most of
the time - dynamically typed languages of sorts, so having static
types in your programming language when most of your work is spent
moving columns from SQL/JSON to objects to HTML elements / ids /
classes; using static typing doesn't have a massive benefit as you're
mostly just moving named slots around.

While things like the REPL shell, JRebel and SBT really help give
Scala a bit more of a dynamic language feel, its still not really in
the same RADness league as the JavaScript/Ruby's of this world. But
then there's loads of applications out there that are large, involve
large teams and are not 'small' apps that hit this dynamic language
sweet spot; where incremental compiling with things like SBT start to
become a little better.

For me though the benefits of Scala far outweigh the advantages of
dynamically typed languages; though I hope the Scala community keeps
trying to improve the simplicity for programmers (e.g. easier to grok
docs that hide more of the language plumbing) & try to improve the
compiler speeds & incremental building features so that it feels more
like the RADness of dynamically typed languages.

Though I guess one big remaining benefit for one particular
dynamically typed language, JavaScript is the user interface platform.
These days all browsers, modern mobile devices and tablets have a
pretty quick JavaScript engine. The webkit + JavaScript user interface
platform does make JS appealing (or rather CoffeeScript which compiles
very quickly to JS or can be interpreted directly in the browser).
While I'd sooner write Scala, the user interface landscape is pulling
me towards CoffeeScript purely for its compiler speed, RADness and the
fact that it runs nicely inside all browsers and devices without a
really slow code generation step (am looking at you GWT; imagine
taking GWT and adding the slow scala compiler in there too, how unRAD
that'd be).

I'd love it if one day we could use Scala as a kinda CoffeeScript
alternative; though given how slow both GWT and the Scala compiler
already are, I suspect it'd just be too slow and unresponsive for UI
development. Though there's still plenty of other software out there
where Scala is the perfect choice! :)

--
James
-------
FuseSource
Email: ja...@fusesource.com
Web: http://fusesource.com
Twitter: jstrachan
Blog: http://macstrac.blogspot.com/

Open Source Integration

[James Strachan]

[Rex Kerr]

On Thu, Feb 10, 2011 at 2:37 AM, Ittay Dror <ittay...@gmail.com> wrote:

** Note: I wanted to link http://shootout.alioth.debian.org/u32/javascript.php as proof, but it seems that javascript is up to 70 times faster than java there...

That's because you're looking at a comparison to _interpreted_ Java (no JIT compiler!).  You need to link to

  http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=v8&lang2=java

to get anything relevant.  Now only regex wins, and that's because it's Google's JavaScript V8 which uses Google's crazy-fast regex engine.

  --Rex

[Philippe Lhoste]

On 09/02/2011 22:59, Jim Powers wrote:

> On Feb 9, 4:41 pm, Ittay Dror<ittay.d...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> After reading the thread, I think the main benefit of dynamic languages is
>> that you need to know less before starting to program in them:
>> * no need to learn much about type systems
>

> Not completely true. In dynamic systems *values* have type but
> *variables* (and other compile-time identifiers) do not.

Ittay wrote: "to learn *much*"
You mostly learn about strings, ints, floats, something to structure that, and some simple
collections (lists, hash maps) and you are good to go.

I still see things like
def padTo [A1 >: A] (len: Int, elem: A1) : Iterator[A1]
as a bit scary (slowly starting to learn type theory, covariance and similar concepts).

On 09/02/2011 23:59, Razvan Cojocaru wrote:
> Type swing java code in vi and you're just as hopeless and slow as doing JavaScript web
> apps in whathaveyou. Once it compiles you know it *may* work but throw
> nullpointers...While the JavaScript thing - well, there's no knowing that it would even
> work.

I use Eclipse all day on a large Java code body, partially unknown, and I really
appreciate it.
But if we are talking about fast prototyping and small scripts, I appreciate being able to
fire my favorite lightweight editor (I get it in the second while I wait up to one minute
for Eclipse to start on the 5 years old Windows computer we have at work), type a few
lines and get instant result.
I can do small scripts in Scala and I appreciate it, it is one of the first compiled,
statically typed language I use offering coding facilities (type inference) and capability
to run as script. But its startup time isn't stellar, compared to, say, a simple Lua script.
It can be unimportant (to do a task occasionally) or not (to run a script 100 times per day).

> Oh, instant results. Much like fixing java code in the middle of an eclipse debugging
> session and continue with the fixed code, after eclipse deployed the fix and instantly
> rolled back to the caller? Can your python interpreter do that? Or it starts over
> again?

I admit that's a very nice feature of Eclipse (as long as you keep changes within a
method). IIRC, Visual Studio was able to do that for C[++] code way before Eclipse.

> Having said that, without a compiler to double check my wiring I feel like writing
> assembly on paper :)

I did that in my early days of computing (coinciding with early days of personal
computers). I had at school a board with an hexa keyboard and LED display, and we had to
write down on paper the assembly mnemonics, compute by hand the jumps, and use tables to
convert all this to hexa... Was fun! For very simple code... :-)

--
Philippe Lhoste
-- (near) Paris -- France
-- http://Phi.Lho.free.fr
-- -- -- -- -- -- -- -- -- -- -- -- -- --

[Martin S. Weber]

Guys, if you're about as ignorant about moving this DEBATE to scala-debate as
has been asked for numerous times as you are to perceived or factual benefits
of dynamic typing, you can stop the whole discussion at this point.

If you're not, why don't you take it to scala-debate.

Just an observation from the outside, unfortunately adding to the noise (and I
tilt my head in shame).

Regards,

-Martin

[Sébastien Bocq]

2011/2/10 Jim Powers <j...@casapowers.com>

> If we're talking about rapid prototyping and rapid application development, static typing is the least of one's worries.

I disagree.  Static typing imposes that you make decisions "early"
often resulting in a poor type zoo.  The point of a (literal)
prototype is to explore the solution space then possibly throw away
the actual result and move forward with some better understanding.

Static typing is not only about subtype polymorphism. When you prototype code like this:

trait Function1[-A, +B] {
  def apply(a:A):B
  def andThen[C](f:B => C):A => C = error("todo")
}

trait MyOption[+A] {
   def cata[X](some: A => X, none: => X): X
   def map[B](f: A => B): MyOption[B] = error("todo")
}

you haven't taken any decision early, there is little to throw away and the compiler can already assist you exploring both solution and design spaces. It takes all kinds to make a world, but I see it as an improvement when a compiler exploits the mathematical properties of algorithms to offer better dependability guarantees, infer missing parameters, or tell me when I'm chasing rainbows.

Sébastien