Fed-up with strongly typing

Lost User

Aah, never miss the times running into an "m_intFoosBar" that contained a string.

Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]

Guirec

Was that a test which was 'really' doing something like generate some content and write it to the response stream or was it just returning a ok/200 ? I might actually be interested in your codebase if you want to share. The 3000 req/sec I am talking about are real dynamic websites running on production, so they obviously have content.

Seulement, dans certains cas, n'est-ce pas, on n'entend guère que ce qu'on désire entendre et ce qui vous arrange le mieux... [^] Joe never complained of anything but ever did his duty in his way of life, with a strong hand, a quiet tongue, and a gentle heart [^]

Andy Brummer

Anyway, it's the architectural change in node and nginx that lets it scale to really high levels. Any of the platforms these days can get that kind of performance if you know what you are doing. It's more about developer experience and knowing how to take advantage of the platform than the platform itself. If you wanted to, you could drop back down to straight C++ and hook into the same low level http apis that IIS uses and crush the performance of just about anything else out there. Or you could do the same in Linux and beat the pants off node. Anyway I've worked on a web service that saturated the network at 6000-7000 req/sec and used 18Gigs of memory to predict fraud in advertising clickstreams. The cut off response time was 200ms, the service averaged under 1ms even when it was getting hammered. That was over 3 years ago on a relatively low end 2 proc VM. I never really got to the point of really tuning it, but I'm sure there was a lot more it could have done.

Curvature of the Mind now with 3D

jschell

Guirec Le Bars wrote:

What do you guys think?

It isn't significant so it doesn't matter.

jschell

Freak30 wrote:

And what if the proficient programmer misses one of the code paths during his tests?

And thus they could have a logic error as well, which would be harder to diagnose in a production system - so what is your point?

jschell

BobJanova wrote:

The C# compiler, and any other compiler for a strongly- and statically-typed language, certainly will check the data type of variables through every possible code path

Neither C# or any other compiler in that category will check dynamically loaded code paths. Where as unit testing would check that.

jschell

Marc Clifton wrote:

If you don't like typing, you shouldn't be a programmer.

Or write code that writes code for you.

jschell

Guirec Le Bars wrote:

At that point in time you will end-up with "the code simple, elegant and fast to write as well as robust to changes".

You must either program by yourself or work with a very extraordinary group of programmers and an extraordinary company. The rest of us must work in the real world where the average programmer, by definition, is average. And some are below average. Thus over time larger systems are neither "robust" nor "elegant". And that even presumes that the business requirements and delivery times allowed for that in the first place.

Guirec Le Bars wrote:

Isn't it the point?

Might be the intent but that isn't what happens. What happens over time is that there is little to no documentation. One must look to the code to find out what is going on and one must often delve through multiple layers to understand it. Which becomes even more true when someone, previously, decided that some generic, meta data, multi-layered solution was appropriate to solve what would have been a trivially simple bit of code.

BobJanova

Well obviously you need to test and pay attention as well. Compile time type checking catches a few silly mistakes that would otherwise cause you trouble, though.

Marc Clifton

jschell wrote:

Or write code that writes code for you.

Quite so. I haven't needed to write a line of SQL in a while now. :) Marc

Testers Wanted!
Latest Article: User Authentication on Ruby on Rails - the definitive how to
My Blog

sashan govender

Compilers already check all paths because they have to. The 'art' of writing good code or being a proficient programmer is to write code such that the compiler can perform the checks itself. You essentially move what can be checked at runtime into something that is checked at compile time. This is what a strongly typed language will allow you to do. This requires more thought and effort from the programmer, which discourages them, as well as the fact that the majority of programmers don't understand this.

Lost User

[quote]But here we are: when you are proficient in your domain of expertise (eg: embedded, gaming, LOB apps, multi-million users websites or whatever is your mod) then strongly typing is just a pain... [/quote] Are you talking about yourself only? I don't always program multi-million users websites, but when I do, I use strongly typed languages.

Patrick Fox

IMO, if you can't handle strong typing, then you weren't completely sure what you were doing in the first place. Disabling strong typing, or using languages that don't feature it, are for the lazy in spirit and mind. Strong typing catches many simple, dumb little problems that can really bite you at runtime, when you may have already shipped the product. You can afford the compiler yelling at you for 5 seconds much more than you can afford a support call + an emergency patch.

Harley L Pebley

In a strongly typed language, I don't have to write tests that check type safety. In a weakly typed language I do. Strongly typed languages let me focus on the domain and mostly ignore the types because I know the compiler (and more recently the IDE and plug-ins) will flag any issues. Weakly typed languages force me to pay attention to the plumbing more, leaving less energy for the more important things.

RafagaX

Strong typing is better down the road, with it the compiler catches many "dumb" errors that will pass unmarked otherwise (for example undeclared variables, type mismatch, redeclared of variables, etc.). If you want to put it like this it gives me peace of mind that my solution will not blow up at runtime with some obscure and untraceable bug caused by a redefined variable somewhere in a function.

CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...

Member 4608898

I use them both. When it matters, I use a typed language, when it doesn't I use untyped. It would drive me crazy if shell/batch scripting was strongly typed. It would also drive me crazy if highly complex programs were untyped. I developed programs in BCPL for body scanners two years. BCPL has only one type: a word. There were times when I really wished it was typeless.

hpcoder2

Actually, not even that. Templated code is not compiled unless instantiated. Conditionally compiled code is not looked at by the compiler unless the argument to #ifdef is true. I've been looking at some of my regression tests using the gcov tool. The number of lines marked ### is bad enough, but all of those lines marked --- (not reachable) is even worse (if you're writing a library, that is). Incidently, a question for the dynamic typing guys, particularly Javascript - is there an equivalent code coverage tool for testing the coverage of a jsunit suite of tests?

irneb

I actually find myself in 2 minds about this. But it's not that I think strong vs weak is bad/good, or even that statick vs dynamic is good/bad. It's a case of most programmers misunderstanding the concepts. Usually I hear stuff like strong-static and weak-dynamic, in fact the opposite is mostly true in nearly all languages, i.e. you tend to find strong-dynamic languages and weak-static languages much more than the other ways round. Actually, most languages are not perfectly strong, perfectly weak, perfectly static nor even perfectly dynamic ... note "most". More usually you'd find something like a language which is mostly statically typed, but allows for automatic coercion when such is needed (e.g. adding a double and a long does not require an explicit type cast in nearly any language). Then also some strong-dynamic languages might assert interaction between different variable types, e.g. raising an exception / compile error when adding a string to an int. To define what's actually happening:

Weak (the extreme case): Any variable just contains data. There's no type inherent in the language and/or compiler which defines what that data is or how it's structured. Think of this as a pointer to a position in RAM without any further data about what is contained in RAM. Sample of this is C, where all variables are in fact simply containing byte arrays. There's no structure to the variable which defines what that variable's type is.
Strong (the extreme case): All variables are created as a record (or more usually an object) with some form of type descriptor. Followed by the data, which might then simply be a byte array or even just a pointer. See this as an Object with constructors and methods which check to see that only the correct types of data interact with it. A sample of this is Lisp, where each symbol (variable) contains a description of the type of data contained inside it.
Static (the extreme case): All variables will only hold the type which they are defined to hold. They may not be assigned another type. This is usually enforced at compile-time, though some languages also insert runtime assertions for this. A sample of this is C, where each variable (or rather most) are defined as containing some type. Then the compiler does type checking whenever that variable is used as input or being assigned to.
Dynamic (the extreme case): Any variable can be assigned any type at any time. A sample of this is Lisp, whenever you assign a value to

descenterace

Unit testing will check the set of code paths that you write the tests to exercise. Fine if you're testing small methods, with only a few possible code paths or edge cases. Then you need to test interactions between your classes, each of which has a dozen methods with 2-5 paths each. Suddenly you have tens of thousands of tests, most of which differ in very small ways. A strong type system enables invariants to be proven efficiently, regardless of the number of possible paths through the code, because it does not need to rely on executing every possible path. A type system is not a replacement for unit tests, and unit tests are not a replacement for a type system.