Weakly/Dynamically typed languages confu

Testing. Check out Test Driven Development, Coveralls, and Red-Green-Refactor.

Basically, everything that happens in an application should by tested. If you want a new feature, you write a test first. Slowly add code until the test passes, and then you know your application is still working.

It basically frees you up to make any changes to your code, and as long as all of the tests pass, you know the changes you made are okay.

First of all C++ does not have strong typing. It is has static weak typing. (it is debatable though)
Python is dynamic, strongly typed.

For one, what am I supposed to do when my code is fed data of the wrong type?

Try to cover maximum range of input types and ignore others: it is caller responsibility to call function with correct types.

If you absolutely need concrete type, you can use isInstance or you can use reflection to tell if object has needed methods.

Secondly, how am I supposed to know what kind of data types other code accepts?

From self-descriptive names, function purpose and PyDoc documentation.

if you have function contains(container, value), can't you determine what is it for what should you pass to it and what it will return?

What kind of container? One I invent myself? One from a different library? The same library? A map? A set/vector/array? Any object defining begin and end? Any object implementing Iterable?

Last edited on

What kind of container?

Any which satisfies Container concept.

Any object implementing Iterable?

It usually reflected in argument name.

You are not afraid of using templated functions, do you? And templates uses duck typing: you can pass anything which looks like compatible object.
When you writing function which takes input iterator you do not fear that somebody will pass this class:

class evil
{
  public:
    operator++()
    {
        std::cout << "MWAHAHAHA\n";
    }
    operator*()
    {
        system("start calc");
    }
};

OK, now that I know there is a Container concept that makes me feel better. All the tutorials I've read to try and understand Python don't mention any such concepts, however.

htirwin (1208)

How does it work? I can understand small projects, but anything large seems like it would quickly get out of hand and fall into chaos. How do people write code at all in weakly typed languages?

That's why you make something large out of a bunch of smaller modules. Each module is self contained. Nothing falls into chaos because each module is simple to understand internally by looking at it, and when looking at the larger picture, you only need to consider each module as a black box. You do need good documentation though because of the ambiguity of having no type associated with the variable.

Where things can get crazy is when people start introducing variables such as info, which are used all over the place to represent json objects where it is elusive which properties the object should have.

While you can successfully write very large projects in javascript and maintain clear code and good organization, many people write horrible javascript that is a nightmare to use. Personally I do not even think that idiomatic javascript is good.

Basically if you use json objects, then name them well, and keep a corresponding documentation of the properties, what they are for, and when they are necessary.

https://docs.python.org/3.4/reference/datamodel.html#emulating-container-types
Or you can inherit from abstract Container (or some more specific) class (I do not remember where exactly it defined) of from another container.

rapidcoder (1010)

"advantages" of dynamic languages over statically typed ones I could think of are:

1. it is much easier to implement a compiler/interpreter - no typechecking phase, which is one of the most complex phases

2. the type system does never get in your way - this is useful in very rare edge cases, where in a statically typed language you'd have a correct program that would not type check successfully.

The biggest drive behind dynamic typed languages are statically typed languages with verbose and inexpressive static type systems like Pascal or C++ (and Java/C# not much better really), where you very often need to do type casting to shut up the compiler.

Last edited on

I wrote this as a little guide to testing with Python:
https://github.com/Lowest0ne/python_test_prime

You can look through the commits to see the development process. With the test in place, if there ever is an edge case, I just add that case to the list of assertions in the test and change the code until the tests pass. I can do anything I want with the code and I know everything is okay because I keep the tests passing.

As far as containers, the last commit include a method, range, something like this:
range( 1, 10 )

Do I really care what type that method returns? I don't. All I care is that I will have the numbers 1 through 9 in some sort of collection.

The actual code I wrote"

1
2

for value in range( 3, int( sqrt( x ) ) + 1, 2 ):
  # something with value

is the same thing as:

1
2

for ( int value = 3; value < sqrt( x ) + 1; value += 2 )
  // something with value

I wrote a recursive folder walk for a job interview, this is it:

from os import walk
for path, directories, files in walk( '.' ):
  for file in files:
      print path + '/' + file

I don't need to care what types I'm dealing with.

Last edited on

How are you supposed to know you need three things (path, directories, files) for iterating the result of walk? Do you just have to consult documentation every single time or memorize it?

The first time I learned about walk, it was through reading documentation.

Besides memorizing, you can also use a command line interpreter:

$ python
Python 2.7.6 (default, Mar 22 2014, 15:40:47) 
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from os import walk
>>> for x in walk('.'):
...     print x
...     break
... 
('.', ['.git', 'txt', 'tif'], ['find_diff.py'])
>>>

From that I can see I have three things, a string, a list of strings, and another list of strings.

If that's not enough, I can also get docs from inspect:

1
2
3

>>> import inspect
>>> print inspec.getdocs( walk )
documentation about how to use walk including examples

One can install ri documentation for Ruby:

$ ri Array.each


= Array.each
  ary.each { |item| block }  -> ary
  ary.each                   -> Enumerator

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

Calls the given block once for each element in self, passing that element as a
parameter.

An Enumerator is returned if no block is given.

  a = [ "a", "b", "c" ]
  a.each {|x| print x, " -- " }

produces:

  a -- b -- c --

Last edited on

rapidcoder (1010)

I don't need to care what types I'm dealing with.

quicksort [] = []
quicksort (p:xs) = (quicksort lesser) ++ [p] ++ (quicksort greater)
    where
        lesser = filter (< p) xs
        greater = filter (>= p) xs

Do you need to care what types are you dealing with in the above code?
No. Is it statically type-safe? Yes.

Static typing != putting type annotations everywhere

Last edited on

I'm just noting that these are higher level languages made for rapid development, you don't have to be as concerned about the types that you are using.

closed account (10X9216C)

you don't have to be as concerned about the types that you are using

That is a bit misleading, the concern changes from getting an error to getting a result you don't want.

I forget which language it was but basically:

x = "some str"
y = 90;

z = x + y; // want to concat the number to a string...

It was probably PHP. Depending on string content and operand order you can get contacenated string, integer sum or error. *Shudders* extreamely weak typing, strange operators properties...
Python will give you an error here.
Perl will try to convert string to integer with default value of 0 (like stoi() on C++)

JavaScript has some pretty weird quirks too:
https://www.destroyallsoftware.com/talks/wat

One of the biggest leaps for me in javaScript was that nobody told me objects in JavaScript were actually just std::map<boost::any, boost::any>, so for a long time I had no idea why so much code was so inconsistent. Once I learned that objects are just maps of anything to anything else, it made a lot more sense to me but made me want to avoid the language at all costs.

ResidentBiscuit (4459)

+1 LB. JavaScript objects are super weird. It's a weird language in general.

BHX (3450)

JavaScript has some pretty weird quirks too

True, but you can just as easily say "<Language> has some pretty weird quirks" because I've yet to see a language that doesn't have people pointing out problems with them.