next »

[isthisthingon]

These issues are less likely to happen: http://www.networkworld.com/news/2009/101609-programmer-slip-up-produces-critical-bug.html?source=NWWNLE_nlt_daily_pm_2009-10-16

[perkiset]

Amen.

[kurdt]

Uuh, that's some some nasty slip. Hmm, it's kinda odd that software house as big as Microsoft doesn't do hardcore fuzz testing when they are famous for their security holes.

[nop_90]

Bug has nothing to do with strongly typed language or not me thinks.

the line with the bug is this
if( ValidateRoutines[pHeader->Command ] == NULL )

the fix is this
if( ValidateRoutines[pWI->Command] == NULL )

So basically a programmer mental error.

According to the site the code compiles correctly without any warnings or errors.
Therefore from the pHeader and pWI structures command both must point to the same "type".
So it has nothing to do with a strongly typed language or not, even if u used pascal,java or what ever u would have still had the same bug.

[isthisthingon]

According to the site the code compiles correctly without any warnings or errors.
Therefore from the pHeader and pWI structures command both must point to the same "type".
So it has nothing to do with a strongly typed language or not, even if u used pascal,java or what ever u would have still had the same bug.

"These issues are less likely to happen."  You're correct that since the types in this case were actually the exact same, therefore allowing the variable to be swapped without seeing an issue at compile time, that a strongly typed language wouldn't have prevented this.

But my issue is that in a loosely typed language you can do something like this and never know there was an issue:

Code:

Bug:
if( ValidateRoutines[pWl->Command ] == NULL )

Fix:
if( ValidateRoutines[pWI->Command] == NULL )

Seriously harder to see the issue no?  The bug in this case??  I used pW(lowercase L) instead of pW(uppercase I).  I just see issues like these as less likely to happen since especially in large projects the compiler catches so many things like this for you 

[vsloathe]

There is no type. All will be one, all will be objectified.

[nop_90]

There is no type. All will be one, all will be objectified.

 
Funny because it is true.
In Lisp (granddaddy of Perl,Python,PHP,ruby etc) all datatypes behind the scenes are an "object".
That is how you can convert from one data type to another.

A strongly typed language that does not appear to be a strongly typed language is OCAML.
The compiler figures out the "type" and compiles. So you as the programmer do not have to worry about that stupid shit.
That is how OCAML can speed that rivals C or in certain algos is even faster then "C".

Compare the size of code for an untyped language for an http client compared to its counterpart in delphi etc.
1/10 the size easy. Therefore much easier to spot your logic errors. Which will eliminate more logic errors which make u more secure.

Erlang is an untyped language.
Erlang has 99.9999999% uptime.
Also because it was designed for the telco industry it is also designed to be distributed.
Because of the way it is designed it is virtually impossible to crash (or if u can crash a node it recovers itself).
Also because it was designed as a "functional language" no deadlocks because of threads are possible, and it can do 100% CPU scaling.
You can read on erickson's site why they invented the language etc.

Downside of the language is erickson except for telcom use does not really care about the language.
So not many modules for it etc.

Anyway I am just curious, what "typed" language are u talking about that will eliminate these problems ?

[isthisthingon]

There is no type. All will be one, all will be objectified.

Anyway I am just curious, what "typed" language are u talking about that will eliminate these problems ?

Decrease these problems, not completely eliminate them.  This is my experience.  It's far easier to have the following mistake:

Code:

lookOverHere = 'Here's my SSN: ' + mySSN;

// ... meanwhile, and further down in the code ...

look0verHere = 'Here's my SSN: ' + mySSN;

Weakly typed language says: 
Strongly typed language says:  --- look0verHere does not exist ---

I realize there's strong arguments for both approaches.  But I can't understand why the most obvious benefit of strong typing is completely dismissed as useless by the opposing school of thought    Watching teams of engineers in both environments over long periods and seeing the results of each approach has made me a believer of strong typing    I would return the question to you and ask - what can you possibly do with a loosely typed language that you cannot do in a strongly typed language? 

Apex was rated as 5X faster than Java in terms of development time and has ruthlessly strict typing.  I think the time to market argument has many other unconsidered elements that loosely typed languages benefit from like um.... let me see...... Rails? 

[nop_90]

@isthisthingon
Typed languages are good for certain things. Making an OS, Making a device driver etc.
As quirks in history, if unix had not been based on C ...
But lets say pascal, history would have been different.
The argument what u can do with a typed language vs a not typed one is a mute arguement.

Basically lines of code saids it all.
Lets take a look at drakma
http://weitz.de/drakma/
A complete web client, with cookie jar, error reporting, multi-part encoding etc.
1.1K lines of code. Python/Ruby webclient probably 2-3K lines of code.
Less code = Less complexity = you can code faster.
Saying that typed languages are "safer" is like saying all bikes should have training wheels.

Probably a language like APEX like Java is good for a cooperate environment.
Cathedral vs Bazaar arguement.

[nop_90]

Concrete example what u can do with untyped languages that u can not do with typed
(or that u can do but next to impossible).

http://code.google.com/p/pywebkitgtk/issues/detail?id=28
Basically a patch to webkit that allows u to call JS functions from python inside the webkit browser.

The person who wrote it was brilliant 
It examines the JS Object (DOM is an object) inside the webkit.
It then creates a binding to the object on the other side.

If i remember correctly approx 500 lines of Cython code.
Try doing that with a statically typed language good fuking luck
The webkitgtk project has been trying to make a similar bridge in C, over a zillion lines of code, buggy as shit, still no commit after 1.5 years.
Same story with the QT team for webkit.

SQLObject from python is another example.
Create an Object bridge to an SQL DB.
So called untyped languages are not really untyped, the types are determined at runtime.

Again apples and oranges.
OCAML which is typed (but appears to be untyped), knocks the socks off anything for calculating FFT, DCT etc.
Speed wise typed will always be faster.

[isthisthingon]

Again apples and oranges.

  zactly

[isthisthingon]

Saying that typed languages are "safer" is like saying all bikes should have training wheels.

More like rock climbers should use safety clips, if they intend to live through the experience

Training wheels imply the inability to ride a bike fully.  Safety clips don't change the complexity of the climb.  But they catch you if you or someone else on the climb makes the smallest mistake.  Heck they help if mother nature causes a random accident    I'm not ashamed to prefer safety clips on expert climbs, since without that concern my brain is freed up to handle more of the things I choose to take on

But apples and oranges man, apples and oranges