>>There are lots of pros and cons for both loosely typed and strongly typed languages. I've never found there's less code in a loosely typed language.
>>
>>
>>>Writing less code is, that why I keep away from anything strongly typed . Having to type hints and keywords for keeping the compiler happy is not my favourate hobby.
>>>
>>>Thats one of the reasons that I'll be looking into products like windev, lianja and Servoy. Less code to be written and excellent platforms to do RAD development.
>
>I agree, there are pros and cons, though I argue strongly that heavy reporting applications benefit greatly from strong typing. And much of the work I do is on the analysis/OLAP side these days, so it's not even an argument - semantic models are, almost by definition, strongly typed.

There is a reason that SQL is not strongly (err.. I mean strict) typed and yet is the standard in data analysis and DML. Yes there is a component in T-SQL that require variables to be typed at forehand, but SQL does not break if you enlarge columns or even in some cases change datatypes. It does do a great deal of automatic casting and the result columns of the resultset are determined at runtime.

Its ridiculous that you have to type datasets, just because you need to tell the compiler what a query returns, only to keep the compiler happy. Everytime you change something on the backend, its not the SQL that breaks, but the application because the typed datasets do not match what is returned from the SQL server.

When it comes to data analysis, there are many dedicated packages, but all of them deal with SQL sources in a dynamic (thus not strictly) typed way.

You'd be right if you had to write algorithms or functions that process lots of data in a customised way (E.g. aggregation functions in SQL server written in .NET), but in the vast majority you do not need strict typing to have well performing solutions just by using SQL (E.g. SQL on local cursors), OR VFPs' xBase specialised functions.