OSNews: http://www.osnews.com/story/26699/The_rise_and_fall_of_programming_languages_in_2012 Exploring the Future of Computing en-us Copyright 2001-2013, David Adams adam+nospam@osnews.com Sat, 25 May 2013 18:35:02 GMT http://www.osnews.com/images/osnews.gif OSNews.com http://www.osnews.com It does NOT mention C# http://www.osnews.com/thread?548794 http://www.osnews.com/thread?548794 C# dulls the mind.

Would anyone use Objectionable-C were it not required for Apps for Apple?

Java is cross-platform and consistent, but Android and some web' apps need it.

FORTRAN, nor its more malignant sibling, COBOL, aren't dead yet.

C comes closest to the hardware, a high level assembler. C++ is nonplussed. Scriptography needs simplicity and flexibility, so Python is squeezing out the competitors.

I like the a-b-c's, Awk, bash, C. Tue, 15 Jan 2013 01:16:00 GMT donotreply@osnews.com (tomz) Comments Renaissance? http://www.osnews.com/thread?548795 http://www.osnews.com/thread?548795 Nobody expects a C++ renaissance.

Even so, it's a bit premature to declare anything given C++ has only just been standardized and compiler support is traditionally slow. Tue, 15 Jan 2013 01:52:00 GMT donotreply@osnews.com (kwan_e) Comments RE: It does NOT mention C# http://www.osnews.com/thread?548799 http://www.osnews.com/thread?548799

FORTRAN, nor its more malignant sibling, COBOL, aren't dead yet.


Fortran is the correct spelling, and it's been the correct spelling since Fortran 90 was ratified some 23 years ago.

BTW, what language were you trying to use when you composed the above sentence? Tue, 15 Jan 2013 03:05:00 GMT donotreply@osnews.com (kargl) Comments RE: It does NOT mention C# http://www.osnews.com/thread?548802 http://www.osnews.com/thread?548802 I'm with you on everything except Objective-C -- what's wrong with it in your estimation?

To me it's a winner: all the benefits of C, combined with an object-orientation system with a simple, smalltalk-like syntax and dynamic dispatch. Tue, 15 Jan 2013 03:39:00 GMT donotreply@osnews.com (Hypnos) Comments RE: Renaissance? http://www.osnews.com/thread?548803 http://www.osnews.com/thread?548803 Renaissance? What for? It never died! ;) Tue, 15 Jan 2013 04:05:00 GMT donotreply@osnews.com (ebasconp) Comments Comment by RareBreed http://www.osnews.com/thread?548805 http://www.osnews.com/thread?548805 I do hope that functional programming languages undergoes a renaissance. However, in my opinion, imperative style languages have made it harder for people to think that way if they have been coding in an imperative style for too long. The thought process requires a radical shift which takes time. For me, it became relatively easy to pick up a new OO or imperative style language. However, it took me several months of wracking my brain to even begin to program in a functional style.

immutable vs. mutable data
recursion vs. iteration
closures vs. objects
method dispatch vs. polymorphism
pattern matching vs. switches
composition of functions vs. aggregation of objects
Macros vs. DSLs
Continuations vs. Exceptions/goto/setjmp

But once you do figure out, it just becomes more elegant. I don't know how software is going to get faster with multi-cores unless people switch to functional languages. Lock-based concurrency is just really hard to get right.

If you don't believe me, read Bartosz Milewski's post on why he switched to FP (and if you don't know who Bartosz is, just google him).

http://fpcomplete.com/the-downfall-of-imperative-programming/

My own dabble with functional languages has been mostly clojure and scheme based. Next on my list to learn is haskell. I tried Scala and didn't like it much (personal choice, it reminded me of perl's TIMTOWTDI and it wasn't really all that functional to which Odersky himself agreed). Clojure is nice, and it's way more readable than lisp/schemes since it also has [] for vectors and {} for maps. That little change makes clojure way more readable. That being said, being hosted on the JVM sucks for system programming. So that's why I've been learning scheme and next on my list is haskell. Tue, 15 Jan 2013 04:49:00 GMT donotreply@osnews.com (RareBreed) Comments Comment by YEPHENAS http://www.osnews.com/thread?548820 http://www.osnews.com/thread?548820 How did I know in advance that the article would link to the Tiobe Index? Tue, 15 Jan 2013 09:11:00 GMT donotreply@osnews.com (YEPHENAS) Comments RE: Renaissance? http://www.osnews.com/thread?548829 http://www.osnews.com/thread?548829 In the meantime, C code gets replaced by C++ (Windows, gcc, Quake3, ...). Tue, 15 Jan 2013 10:21:00 GMT donotreply@osnews.com (moondevil) Comments RE: Comment by RareBreed http://www.osnews.com/thread?548830 http://www.osnews.com/thread?548830 I started programming in 1975 with BASIC and COMAL and then later Pascal, FORTRAN, COBOL and assembly language at university. On the third year of university, I was taught LISP and was immediately sold. I have also used C, Java, Scheme, ML, Haskell and a dozen less known languages. I tend to use mainly Standard ML. Though it is not purely functional and rather less advanced than Haskell, I like its simplicity: I find that Haskell has evolved to a testbench for weird language and type features so people can write extremely generic programs that you need a PhD to understand.

Standard ML is, however, rather dated. Some attempts at revising it has been made, but they have, IMO, failed mainly by trying to add too many new features to the language. Then there are what I would call misguided derivatives (O'Caml and F#) that add object-oriented features to the language. I would rather see a minimal update that solves some of the more pressing problems (such as lack of Unicode support) and a more modern standard library. And parallelism, of course. Tue, 15 Jan 2013 10:21:00 GMT donotreply@osnews.com (torbenm) Comments RE: Comment by RareBreed http://www.osnews.com/thread?548835 http://www.osnews.com/thread?548835 The functional programming is going to be just another tool of multi-paradigm programming languages, I think.

From my enterprise experience I think functional programming has more chances of success by being integrated into mainstream languages (C#, Scala, ...) as pure functional only.

People finally discovered that single paradigm languages are not a good idea. Tue, 15 Jan 2013 10:33:00 GMT donotreply@osnews.com (moondevil) Comments RE[2]: It does NOT mention C# http://www.osnews.com/thread?548845 http://www.osnews.com/thread?548845
I'm with you on everything except Objective-C -- what's wrong with it in your estimation?

To me it's a winner: all the benefits of C, combined with an object-orientation system with a simple, smalltalk-like syntax and dynamic dispatch.


All the drawbacks of C too, unfortunately.

I really wish Apple would take Cyclone (http://cyclone.thelanguage.org/), which is basically C done right, lash it to their existing OO mechanism, and call it Objective-C 3.0. It wouldn't be perfect (e.g. error handling would still suck), but it'd address [Obj]-C's single biggest weakness (safety) and with luck help drive the wider adoption of 'safe C' dialects on other platforms too (something long overdue). Tue, 15 Jan 2013 11:59:00 GMT donotreply@osnews.com (hhas) Comments RE[3]: It does NOT mention C# http://www.osnews.com/thread?548847 http://www.osnews.com/thread?548847 Can Cyclone compile ANSI C code? If not, I don't think it will ever gain traction, so would not be worth including in a new Obj-C.

The beauty of Obj-C is that you have standard C (with all of its warts), plus an elegant OO system that includes all the niceties of a modern OO language. This gives you one toolchain for the entire OS stack, from kernel up to web services. Tue, 15 Jan 2013 12:21:00 GMT donotreply@osnews.com (Hypnos) Comments RE[2]: Comment by RareBreed http://www.osnews.com/thread?548850 http://www.osnews.com/thread?548850
People finally discovered that single paradigm languages are not a good idea.


I disagree. Maintaining a clear, precise focus is a Very Good Thing (see: Coupling and Cohesion 101). You never see a joiner using the same tool to do everything from slice wood to turn screws to drive nails to apply varnish. There's a reason for that.

I think the real problem is developers not being able to hop quickly and effortlessly between different languages within a project. That may be partly down to bridging and tools not being good enough to allow seamless mixing and matching. But I suspect the biggest barrier is developers themselves lacking the mental agility to switch between languages and idioms. That, compounded by a self-indulgent fondness for inventing complex solutions using tools they already know rather than seeking out simple solutions involving tools they don't. The modern trend for Computer Science courses to silently retool as Software Engineering, and from there to lowest-common-denominator Java diploma mills, probably doesn't help either; but that's another debate. Tue, 15 Jan 2013 12:37:00 GMT donotreply@osnews.com (hhas) Comments RE[3]: Comment by RareBreed http://www.osnews.com/thread?548852 http://www.osnews.com/thread?548852 I share the same opinion, although I do like multi-paradigm languages.

I loathe the way some developers seem to try to bend a given language to use it in ever conceivable scenario.

Don't mix Software Engineering with CS names. My university degree when I took it, was called Software Engineering in my mother language, but the actual contents were what is known as CS in other countries. Tue, 15 Jan 2013 12:47:00 GMT donotreply@osnews.com (moondevil) Comments RE[4]: It does NOT mention C# http://www.osnews.com/thread?548861 http://www.osnews.com/thread?548861
Can Cyclone compile ANSI C code? If not, I don't think it will ever gain traction, so would not be worth including in a new Obj-C.


I think that would depend on the particular piece of code. The following might help:

http://cyclone.thelanguage.org/wiki/Cyclone%20for%20C%2...

OTOH, Cyclone already has an 'extern "C"' feature for interfacing to C code, so it wouldn't be a big leap to extend that to Obj-C 2.0, which could be kept around for as long as needed. There's also the option of cross-compiling - I suspect with backing from the likes of Apple and LLVM it wouldn't take long for big improvements to appear there. The 'Porting C code to Cyclone' section of the Cyclone user manual has more info:

http://cyclone.thelanguage.org/wiki/User%20Manual/

Really, at age 40-something it's long past time C grew up and stopped behaving like a sloppy, stroppy teenager. The question is, who has the motivation to drag it up by its bootstraps? MS has no need to do so since it's already invested in C# and C++. The Linux world won't push it forward either, since it's even more sloppy and stroppy than C is.

The only real hope (for better or worse) is Apple, since C remains a foundation stone of their whole platform and therefore developer community, so as more (often less skilled) developers take up Cocoa development, the more of a liability C's flaws become. To their credit they have been trying to modernize the Obj-C language a bit, but so far the front-of-house changes are just nibbling at the edges. OTOH, now the move to LLVM is done, they're in a much stronger position to aggressively innovate.

Remember, Apple have pulled this sort of trick off before, in the transition from 'Mac' OS 9 to 'Mac' OS X. It'd be nice to see Apple demonstrate the same sort of boldness in their tool chain that they've shown in their hardware design and supply chain to such great success.

The beauty of Obj-C is that you have standard C (with all of its warts), plus an elegant OO system that includes all the niceties of a modern OO language.


Personally I really wish Dylan had worked out - it had a far more powerful and elegant OO model than ObjC/Smalltalk. Infinitely better macro system than [Obj]C too.


This gives you one toolchain for the entire OS stack, from kernel up to web services.


OTOH, even Unix Philosophy says it's better to have a compliment of dedicated tools that play well together than a single Swiss-army tool that tries to do it all. And OS X is nothing if not opportunist, happy to integrate whatever works. Tue, 15 Jan 2013 13:49:00 GMT donotreply@osnews.com (hhas) Comments RE[4]: Comment by RareBreed http://www.osnews.com/thread?548867 http://www.osnews.com/thread?548867
Don't mix Software Engineering with CS names.


I'm absolutely for the existence Software Engineering courses; after all, there's a huge need in today's world for applied software engineers, and plenty folks who desire such jobs. I just hate it when such courses call themselves 'Computer Science' [1] when the curriculum clearly is not.

Personally I think a big heaping dose of honesty is needed from universities... and from students too. Everyone's perfectly happy to distinguish between, say, Applied and Theoretical Physics, so why conflate Applied and Theoretical Computing? The only reason I can think of is ego marketing: students want to be software engineers but call themselves 'computer scientists' because that sounds cleverer.

And so everyone forgets what CS actually is and what it's meant to do: push the boundaries and [re]define the state of the art. Just as in the sciences, you need a vibrant theoretical community generating new ideas and improvements that can eventually feed into the applied world, otherwise the latter grows close-minded and stagnant. It's not healthy, but I suspect a lot in the programming world isn't what it ought to be.


[1] Which should probably be called 'Computer Math', but that's a separate gripe. Tue, 15 Jan 2013 14:21:00 GMT donotreply@osnews.com (hhas) Comments RE[2]: Comment by RareBreed http://www.osnews.com/thread?548884 http://www.osnews.com/thread?548884 Have you tried F#? It's a Functional Language. Comes in Visual Studio and can be used in MONO. Tue, 15 Jan 2013 16:56:00 GMT donotreply@osnews.com (Accident) Comments RE[3]: Comment by RareBreed http://www.osnews.com/thread?548886 http://www.osnews.com/thread?548886 Functional languages are beautiful; but getting tied to a specific proprietary platform (.NET framework) is not a good idea.

I would take a look to Jaskell ( http://jaskell.codehaus.org ) instead.Edited 2013-01-15 17:18 UTC Tue, 15 Jan 2013 17:03:00 GMT donotreply@osnews.com (ebasconp) Comments RE: Renaissance? http://www.osnews.com/thread?548887 http://www.osnews.com/thread?548887
Nobody expects a C++ renaissance.

Nobody expects the Spanish inquisition ;)

Seriously though, I fully agree with you. I can't see how someone could expect a long-time established language like C++ suddenly have a noticeable user surge due to new features being added.

Also I can't see how javascript could possibly be 'treading water' given how pervasive it's become on the web, not to mention new 'technologies' like HTML5 relying on it. Tue, 15 Jan 2013 17:08:00 GMT donotreply@osnews.com (Valhalla) Comments RE: Comment by RareBreed http://www.osnews.com/thread?548888 http://www.osnews.com/thread?548888 Carmack had a (imo) interesting blog post on functional programming from a C++ perspective:

http://www.altdevblogaday.com/2012/04/26/functional-programming-in-... Tue, 15 Jan 2013 17:11:00 GMT donotreply@osnews.com (Valhalla) Comments RE[2]: Renaissance? http://www.osnews.com/thread?548890 http://www.osnews.com/thread?548890 Maybe for productivity applications, it does not make any sense; but if you plan to wrote something low level, the new features of C++ get you attracted more to the language than before. Tue, 15 Jan 2013 17:37:00 GMT donotreply@osnews.com (ebasconp) Comments RE[4]: Comment by RareBreed http://www.osnews.com/thread?548903 http://www.osnews.com/thread?548903 except it can be used in MONO which is open source. Tue, 15 Jan 2013 20:07:00 GMT donotreply@osnews.com (lucas_maximus) Comments but Perl may resurrect! http://www.osnews.com/thread?548906 http://www.osnews.com/thread?548906 into Perl 6, a complete rewrite of Perl that began 12 years ago. Tue, 15 Jan 2013 20:26:00 GMT donotreply@osnews.com (4biaggi) Comments RE[2]: Comment by RareBreed http://www.osnews.com/thread?548909 http://www.osnews.com/thread?548909
The functional programming is going to be just another tool of multi-paradigm programming languages, I think.


Agreed. Over the years, I've found very little value in purely-functional languages - but I find a *lot* of value in having functional elements within more traditional procedural or OO languages. Tue, 15 Jan 2013 20:33:00 GMT donotreply@osnews.com (Delgarde) Comments RE[5]: Comment by RareBreed http://www.osnews.com/thread?548914 http://www.osnews.com/thread?548914
"Don't mix Software Engineering with CS names.


I'm absolutely for the existence Software Engineering courses; after all, there's a huge need in today's world for applied software engineers, and plenty folks who desire such jobs. I just hate it when such courses call themselves 'Computer Science' [1] when the curriculum clearly is not. "

Eh, the line is somewhat blurry. Most CS degrees increasingly include a lot of practical stuff, while CE also covers theory. Not worth making a fuss over, I think. Tue, 15 Jan 2013 20:44:00 GMT donotreply@osnews.com (Delgarde) Comments RE[3]: Comment by RareBreed http://www.osnews.com/thread?548921 http://www.osnews.com/thread?548921
"The functional programming is going to be just another tool of multi-paradigm programming languages, I think.


Agreed. Over the years, I've found very little value in OO languages - but I find a *lot* of value in having objects in more traditional procedural or functional languages. "

Fixed that for ya ;)

Serious now.

It's true, pure functional is only a marginal improvement over impure functional. It's sort of like the distinction between weak and strong typing. But just as we prefer strong typing for the guarantees it gives us we should prefer pure functional to impure. Tue, 15 Jan 2013 22:09:00 GMT donotreply@osnews.com (satsujinka) Comments RE[4]: Comment by RareBreed http://www.osnews.com/thread?548923 http://www.osnews.com/thread?548923 "we prefer"? Tue, 15 Jan 2013 22:20:00 GMT donotreply@osnews.com (ndrw) Comments RE[4]: Comment by RareBreed http://www.osnews.com/thread?548927 http://www.osnews.com/thread?548927
It's true, pure functional is only a marginal improvement over impure functional. It's sort of like the distinction between weak and strong typing. But just as we prefer strong typing for the guarantees it gives us we should prefer pure functional to impure.



Disagree, pure functional is a serious step backward compared to a language that allow you to mix functional with procedural or OO techniques. Seriously, why should I prefer pure-functional when all that gives me is reduced flexibility? Tue, 15 Jan 2013 22:39:00 GMT donotreply@osnews.com (Delgarde) Comments RE[2]: Renaissance? http://www.osnews.com/thread?548928 http://www.osnews.com/thread?548928
Seriously though, I fully agree with you. I can't see how someone could expect a long-time established language like C++ suddenly have a noticeable user surge due to new features being added.


And it makes me wonder* about the figures when Java moved from 1.4 to 5 to 6 to 7. Tue, 15 Jan 2013 22:54:00 GMT donotreply@osnews.com (kwan_e) Comments RE[5]: Comment by RareBreed http://www.osnews.com/thread?548930 http://www.osnews.com/thread?548930 "pure functional" = functional,
"functional" = maybe functional, maybe not - review the code.

OTOH, I agree that current pure functional languages are too limiting/inconvenient in practice. Tue, 15 Jan 2013 23:23:00 GMT donotreply@osnews.com (ndrw) Comments RE: Comment by RareBreed http://www.osnews.com/thread?548935 http://www.osnews.com/thread?548935 I love functional programming.
But imperative programming more matches the way that people actually think. People think in concrete, step-by-step terms: I get out of bed, I take a shower, I brush my teeh, I comb my hair, I get dressed, I eat breakfast, I leave the house, I go to work, I park my car, I walk into the office, I etc, etc, etc. In order to achieve a particular goal, people do each step in a particular order.

Functional (and logic) programming, is more atuned to abstract/mathematical thinking (and the more declarative the programming is, the more it becomes like math). Most people are not adept at that. Tue, 15 Jan 2013 23:53:00 GMT donotreply@osnews.com (MollyC) Comments RE[5]: Comment by RareBreed http://www.osnews.com/thread?548936 http://www.osnews.com/thread?548936
Everyone's perfectly happy to distinguish between, say, Applied and Theoretical Physics, so why conflate Applied and Theoretical Computing?


That is because the boundary between Applied and Theoretical Computing is blurred.

"If I apply this patch, this should theoretically work" Tue, 15 Jan 2013 23:53:00 GMT donotreply@osnews.com (kwan_e) Comments RE[5]: It does NOT mention C# http://www.osnews.com/thread?548956 http://www.osnews.com/thread?548956 Your comment has a number of interesting points; I'll try to respond:

1) There's so much C code, and C retains such popularity, that porting is a non-starter IMHO. However, 'extern "C"' could work if perchance Cyclone were to catch on. But, as discussed on OSNews and elsewhere, "good enough" with inertia behind it is far more powerful than "better" without inertia. Even withing Apple, it's such a huge company now, their current toolchain has a lot of momentum, and there's no Steve Jobs anymore to impose big changes of direction.

2) Whether Dylan has a more elegant OO model than Smalltalk is a matter of taste. On a practical level, what can macros do that Obj-C categories cannot?

3) To "play well together" in the Unix philosophy means to have a simple common data format, the text file/stream. When it comes to system programming interfaces in Unix, this means SysV-like APIs in C. Most crusty old Unix types prefer to just code in C rather than have multiple language bindings and a more complex software stack; Obj-C is a viable compromise to many since it retains the "virtues" of C while including a usable OO model.

It seems to me there are two design questions here: (a) whether C is worth continuing to use as a systems programming language and (b) what should the higher levels of the toolchain look like -- many languages (hopefully with a common runtime, e.g. LLVM) or just one tool like Obj-C? Wed, 16 Jan 2013 02:58:00 GMT donotreply@osnews.com (Hypnos) Comments RE[5]: Comment by RareBreed http://www.osnews.com/thread?548966 http://www.osnews.com/thread?548966 If you'd like to be helpful, please point me to someone who prefers weak typing to strong typing. Then put that in context of everyone who prefers the reverse.

Please note that this is not a comment on the preference for dynamic or not. A dynamic language can still be weakly or strongly typed underneath (Python for instance is a strongly typed dynamic language.)

"We" in this case is in reference to the general populace of programmers. Wed, 16 Jan 2013 06:02:00 GMT donotreply@osnews.com (satsujinka) Comments RE[5]: Comment by RareBreed http://www.osnews.com/thread?548967 http://www.osnews.com/thread?548967 Exactly because it reduces flexibility. That's why I compared it to weak/strong typing.

Both strong typing and "pure functional" provide additional guarantees about the content of some object (values/variables and functions respectively.) In the case of pure functions, the guarantee is that they will always be referentially transparent and have no side effects. It's simply impossible to construct something which isn't. This is a valuable guarantee, at least for a compiler, due to the optimizations such a function allows. Wed, 16 Jan 2013 06:06:00 GMT donotreply@osnews.com (satsujinka) Comments RE[6]: Comment by RareBreed http://www.osnews.com/thread?548968 http://www.osnews.com/thread?548968 In very simple terms, you've gotten the core of my argument.

Personally, I don't find the limitations of a pure language to be particularly restrictive. I mean, I am most productive in Haskell. Wed, 16 Jan 2013 06:11:00 GMT donotreply@osnews.com (satsujinka) Comments RE[2]: Comment by RareBreed http://www.osnews.com/thread?549068 http://www.osnews.com/thread?549068 I would disagree here. The problem is that it only takes one mutable piece of data or one function with a side effect to ruin an entire call chain. Mixing and matching pure FP with anything else renders your code non-pure and thus you may as well not have written in an FP style at all.

Less seriously, it forces users to think multiple ways. I saw many java developers complain vehemently about the upcoming lambdas in Java 8. So one developer might write code in an OO style, and another in an FP style, and now everybody has to learn both ways of doing it. Wed, 16 Jan 2013 20:46:00 GMT donotreply@osnews.com (RareBreed) Comments RE[3]: Comment by RareBreed http://www.osnews.com/thread?549069 http://www.osnews.com/thread?549069 Perhaps FP is a special case, but it only takes one mutable piece of data or a function with a side effect to make it useless (in a concurrent/parallel context).

So I agree that single paradigm languages have their place. Also, many of the things done in OOP can be done in FP but using a different way of thinking.

And I think that is the crux of the problem. People don't want to have to learn a new way of thinking. They are ok with learning new API's or even new languages that fit their mold (OO, imperative, Relational, logical etc), but having to think in a new way is too much work for many people. Wed, 16 Jan 2013 20:50:00 GMT donotreply@osnews.com (RareBreed) Comments RE[6]: Comment by RareBreed http://www.osnews.com/thread?549098 http://www.osnews.com/thread?549098 There are many programmers out there who prefer weak typing, so "general populace of programmers" is, well, generalization.

I'm somewhere in between. Sometimes I like strong typing (large models with a simple structure), sometimes not (complex or dynamic models). A quick exercise: how (and why) would you classify a small hungry, short-haired, black cat?

Also, while dynamic languages may or may not be strongly typed (semantically), they are all have to be weakly typed during compilation - the only time strong typing actually matters. Thu, 17 Jan 2013 00:10:00 GMT donotreply@osnews.com (ndrw) Comments RE[2]: Comment by RareBreed http://www.osnews.com/thread?549101 http://www.osnews.com/thread?549101
I get out of bed, I take a shower, I brush my teeh, I comb my hair, ...


If that was how OO programs are written the world would be better. Most programs (and toolkits) look more like this:

"[You,] get out of bed! Take shower! Brush teeth! Comb your hair!"

or even:
"take a comb, raise your hand, do {stroke your hair} until (enough)".

Calling other object's "doSomething" or "setSomething" methods is modern equivalent of calling "goto". A single setter may look innocent but try to sequence a number of them and you will have to deal with all the complexity (structure, sequencing, side effects) that leaked out from the object. That's because the control is no longer inside the object but in a caller of the method. Thu, 17 Jan 2013 00:47:00 GMT donotreply@osnews.com (ndrw) Comments RE[7]: Comment by RareBreed http://www.osnews.com/thread?549105 http://www.osnews.com/thread?549105 Of course it is a generalization, however, it's a perfectly valid one. There are very concrete reasons to prefer strong typing to weak typing in nearly all cases.

If anything, complex models dictate strong typing. If simply to give you appropriate guarantees and sign posts for navigating the model. It's simple models in which adhering to rules isn't so important. For example, your cat is a simple model having just 4 properties to vary on (plus animal type, if we're dealing with other animals.)

A strongly typed language is a strongly typed language, no matter when the enforcement occurs. Static types merely help catch violations sooner, but you're still not allowed to violate the system if we check later. Thu, 17 Jan 2013 01:04:00 GMT donotreply@osnews.com (satsujinka) Comments RE[8]: Comment by RareBreed http://www.osnews.com/thread?549115 http://www.osnews.com/thread?549115 No generalizations are valid. Especially when there are whole groups of people thinking otherwise (here: for very concrete reasons prefer weak typing to strong typing in nearly all cases).

Strong typing works extremely well with abstract single-function objects (a number, a string, a list, a set) and fails *badly* at any attempt of modeling real objects. In a way, you have admitted that yourself - a "cat" from my example would be an "Object" type, distinguished only by its fields, not the type.

Strong typing implies enforcement, otherwise it wouldn't be "strong". Preferably at compile time, and at least at runtime, although many advocates of strong typing would disagree with that. The problem with your example is that Python doesn't even enforce types at runtime - a "type" (class) is just a method of reusing implementation. At runtime the interpreter is only interested whether the field/method you're accessing is defined or not - something that may and does change at any the time. Thu, 17 Jan 2013 02:15:00 GMT donotreply@osnews.com (ndrw) Comments RE[9]: Comment by RareBreed http://www.osnews.com/thread?549117 http://www.osnews.com/thread?549117
No generalizations are valid.


I see what you did there. Thu, 17 Jan 2013 02:50:00 GMT donotreply@osnews.com (kwan_e) Comments RE[9]: Comment by RareBreed http://www.osnews.com/thread?549118 http://www.osnews.com/thread?549118 Your cat example was simple, so it deserves a simple implementation. If you'd wanted me to model the complete biological workings of a cat; that'd be an example of a complex model that would very much have components that differ in type. And I'd almost certainly want them to be strongly typed; no using a lung as a leg!

All current development models fail horribly at modeling the real world. Weak typing gives you no leverage here. Dynamic typing gives you no leverage. Structured, functional, or object oriented paradigms give you no leverage. The world is a messy graph that you can't simplify into something nice and neat.

Python is a strong language. There isn't any debate about this. It's simply a fact. Thu, 17 Jan 2013 02:56:00 GMT donotreply@osnews.com (satsujinka) Comments RE[8]: Comment by RareBreed http://www.osnews.com/thread?549119 http://www.osnews.com/thread?549119
If anything, complex models dictate strong typing.


If we go meta and take a look at this whole conversation (which has gone on since the invention of those terms...

The fact that you can categorize something as strong or weak typing, but differentiate it from compile-time or run-time typing, and differentiate it from static and dynamic typing, and the conflation with OO, says something about the inherent flaws of any kind of language typing.

Really the conversation should be about:

Strong, compile-time, static typing vs
Strong, compile-time, dynamic typing vs
Strong, run-time, static typing vs
Strong, run-time, dynamic typing vs
Weak, compile-time, static typing vs
Weak, compile-time, dynamic typing vs
Weak, run-time, static typing vs
Weak, run-time, dynamic typing. Thu, 17 Jan 2013 03:07:00 GMT donotreply@osnews.com (kwan_e) Comments RE[9]: Comment by RareBreed http://www.osnews.com/thread?549134 http://www.osnews.com/thread?549134 Sadly, that's not even a comprehensive listing of possible type systems...

Of course, Gödel's incompleteness theorems apply to type systems. So any type system is going to be incomplete or inconsistent. Generally speaking, the most extreme strong type system is going to be incomplete and a very weak type system (say that has no types) is going to be inconsistent. Compile/runtime follows the same sort of pattern (in that compile time checked systems will filter out some "valid" programs and runtime checked systems will have some inconsistent programs [corner cases where there's no way to figure out how to operate on what we have].)

Static and dynamic are the outliers here. Instead of being a characteristic of the expressiveness of a type system, static/dynamic is more about the actual expression of the types. They're more akin to SVO vs SOV vs VSO vs ... sentence structures then they are to choices in strong/weak or compile/runtime.*

*Dynamic languages are often conflated with runtime type checking, but this is technically unnecessary. Runtime checking is easier than compile time for dynamic languages (due to names/variables having no defined type,) but (for example) many lisp compilers have done compile time type checking en route to optimization. Thu, 17 Jan 2013 05:22:00 GMT donotreply@osnews.com (satsujinka) Comments RE[10]: Comment by RareBreed http://www.osnews.com/thread?549185 http://www.osnews.com/thread?549185 The "cat" example was simple object yet most type systems would fail to classify it properly. Real objects have multiple "types" in many hierarchies, often changing over time.

As for python - there was never any debate about it. It has always been a weakly typed language by most definitions (admittedly, not yours). In fact, Guido had to often defend his choice against legions of people who prefer strong typing:

http://www.artima.com/intv/strongweak.html Thu, 17 Jan 2013 19:54:00 GMT donotreply@osnews.com (ndrw) Comments RE[11]: Comment by RareBreed http://www.osnews.com/thread?549190 http://www.osnews.com/thread?549190 Then why does the second page of what you linked explicitly say it's not weak typing? Why does Wikipedia's page say Python is strongly typed? Why do all of c2's pages on typing say Python is strongly typed?

No, I'm afraid you're wrong. Python is strongly typed. It's just checked at runtime.

How would most type systems fail to classify a cat properly?

data FurType = Short | Long | Medium
data Color = Black | Orange | White | Tabby | ...
data Cat = Cat { hungry :: Bool, fur :: FurType, color :: Color, ... }

mycat = Cat True Short Black ...

It isn't that cat's are hard to design a strong model for. It's that there's no point in doing it because it's irrelevant. The following is just as sufficient for this.

(True,"short","black",...) Thu, 17 Jan 2013 20:57:00 GMT donotreply@osnews.com (satsujinka) Comments RE[12]: Comment by RareBreed http://www.osnews.com/thread?549291 http://www.osnews.com/thread?549291
Then why does the second page of what you linked explicitly say it's not weak typing?


Easy enough to check:
"Weak typing is not really a fair description of what's going on in Python."

Which is fair given that Python uses types for implementation reuse and error reporting. This of course doesn't stop me from adding a method "bark()" to an existing class "cat".

Why does Wikipedia's page say Python is strongly typed?


It also says that Lisp is strongly typed (a language specifically designed for making all non-primitive values untyped). The reason they give is that it doesn't do type coercion, which is IMHO a stupid way of defining "strong typing". But I will accept that, so if you wish, we may end the discussion here.

How would most type systems fail to classify a cat properly?

data FurType = Short | Long | Medium
data Color = Black | Orange | White | Tabby | ...
data Cat = Cat { hungry :: Bool, fur :: FurType, color :: Color, ... }

mycat = Cat True Short Black ...


Interesting (really!). But note that Haskell's type system is definitely not what people would call "most type systems".

And even Haskell can't make a "cat" object sometimes hungry, sometimes not. (True, this goes deeper than the type system in Haskell). Fri, 18 Jan 2013 17:01:00 GMT donotreply@osnews.com (ndrw) Comments RE[13]: Comment by RareBreed http://www.osnews.com/thread?549346 http://www.osnews.com/thread?549346 http://c2.com/cgi/wiki?WeakAndStrongTyping
http://c2.com/cgi/wiki?TypingQuadrant
http://en.wikipedia.org/wiki/Weak_typing

Type coercion is a generally accepted criteria of strong/weak. Not the only one, but it's an easy to use tool.

Strong/Weak: Does the type of a value change? Or, is type checking even done?

Type systems are weak if the answers fall closer to "all the time and never" and type systems are strong if "never and always". Irrespective of when the checking is done. Mind you, this is a gradient. The exact point when a language ceases to be strong and becomes weak is fuzzy (and may effectively change depending on what subset of the language we're talking about.)

IMHO, adding cat.bark() isn't weak, so much as open typing (not sure this is an actual phrase, but I've heard people describe class systems as "open" when you're allowed to add things after definition.) Since it's not really that cat is no longer a Cat, it just got new abilities.

And as you say yourself, Lisp's data abstractions are untyped. But when there are types (e.g. primitives, functions, macros,) pretty much all Lisps use strong typing (some even insert static typing when they can.) In this case, it's sort of a value judgement. Is untyped the same as weakly typed? After all something that is untyped doesn't even have a notion of type to change, but it may have a structure that does get checked (which amounts to type checking.) Fri, 18 Jan 2013 22:38:00 GMT donotreply@osnews.com (satsujinka) Comments