The programming language/paradigm debate

[Icemage]

Re: XB1 3 Million Units Sold

And yet the most successful of multi-national companies do just that. It isn't fragmentation. It's diversity. And through diversity you build on strength. If this country still ran a largely white male dominated society, do you think it would be a stronger country than it is now? If the engineering and scientific community still ran on principles of the "aether", do you think we would be anywhere near the level of technological capacity that we are at now?

Standards are and have always been a double edged sword. Luckily, STEM people are always of the school of thought, "let's always try to build something better than the last". Those of the business and financial worlds are always of the school of thought of, "if it ain't broke, why fix it". Lately, it's been more like, "dude, if the servers get taken offline for even just one hour to upgrade, we'll lose $XX billion in revenues, so let's not do that, no matter how much we really should..."

I'll let you figure out which of the two camps are currently in charge of most of the institutions around the world and why we're in such deep shit...

That argument seems deliberately obtuse.

Large multinationals and other monolithic institutions would love to be on a single standard. The reason they usually aren't is because no one is in charge of everything, there are often conflicting interests and tasks that suit different tools, and such. It's not really because of some sort of ideological rift where people just do things differently because they want to be different.

In the case of software development, having a single language codebase makes things simpler; one IDE, one compiler, one set of tools and libraries, etc. Doesn't mean that there aren't advantages to splitting up tasks between components that are more suited to one language than another, but that's a lot of advantages to give up.


Icemage

[Aeni]

Re: XB1 3 Million Units Sold

While you can indeed have software developed in other languages, fragmenting the market so that you have many languages in common use instead of a handful makes the task of trying to find competent staff more difficult, not less, and makes no more sense than having all your management staff speak different languages internally in a multinational corporation.

And yet the most successful of multi-national companies do just that. It isn't fragmentation. It's diversity. And through diversity you build on strength. If this country still ran a largely white male dominated society, do you think it would be a stronger country than it is now? If the engineering and scientific community still ran on principles of the "aether", do you think we would be anywhere near the level of technological capacity that we are at now?

Standards are and have always been a double edged sword. Luckily, STEM people are always of the school of thought, "let's always try to build something better than the last". Those of the business and financial worlds are always of the school of thought of, "if it ain't broke, why fix it". Lately, it's been more like, "dude, if the servers get taken offline for even just one hour to upgrade, we'll lose $XX billion in revenues, so let's not do that, no matter how much we really should..."

I'll let you figure out which of the two camps are currently in charge of most of the institutions around the world and why we're in such deep shit...

[Armando]

Re: The programming language/paradigm debate

I guess it's been too long since I've programed in a functional language. Armando, you want to pick one for me to get the mental gears turning again? (My previous-and-only experience was with Scheme, a LISP derivative with a clean syntax and too many parenthesis, IIRC.)

The short answer would probably be F# or Scala.

The 5 languages I've brought up at some point or another in this thread - Standard ML, Ocaml, F#, Scala, and Haskell - are all statically typed and have plenty of overlap in their features. But I find Haskell problematic because it's pure and lazy (see below for details).

On Haskell

It's not that you can't write side effects in Haskell, but the type system distinguishes between functions that have side effects and those that don't. That distinction can occasionally be useful but it can also be detrimental, so I'm not a fan of enforcing it at the language level. I think the hoops you have to jump through to get side effects raise the barrier to entry for people still new to functional programming as well. The other issue is laziness, which again can occasionally be useful, but I think is also detrimental when used across the board. It essentially turns errors and infinite loops into values:

x = 1.0/0.0
y = loopsforever()

Execution will continue past both of those lines and those variables become ticking time bombs in your program that blow up later on when it can't proceed any further without evaluating those expressions. So x is a variable that's supposedly a float but blows up when you use it, while y causes your program to hang. So every type in Haskell implicitly contains two additional values that you probably don't want. The other issue is that it's difficult to reason about the space usage of Haskell programs since it's hard to predict when the expressions that are bound to variables will be evaluated. Plus, Haskell seems to be deeply rooted in academia and the programming language research community so you sometimes bump into a bunch of category theory you really don't need/want to know about.

F# and Scala are the most likely candidates for real-world functional languages since they interoperate with .NET and the JVM, respectively. So if you want to dive straight into something that could be immediately useful, those two are your best bet. You probably won't have too much trouble finding learning material, since both languages have had some limited acceptance in the real world, unlike the others. As mentioned previously, Standard ML, OCaml and F# are closely related, with OCaml being a dialect of Standard ML with some OO mixed in, and F# basically being OCaml with .NET interoperability, so I think OCaml is too redundant without any compelling use case over F#.

However, there's a case to be made for learning Standard ML because it's a more streamlined language (no extraneous features related to interoperating smoothly with OO languages) and perhaps more interestingly, it's got a more powerful module system than other languages. For instance, OO languages don't really have a middle ground between a class and an interface. E.g. In Java, if you depend on ArrayList then you've got a dependency to that particular implementation of Lists, but if you depend on List you can receive any class that implements the interface, even multiple different classes in the same run of your program. Standard ML lets you express "OK, I want my program to be able to use different List implementations but I'll only ever use one implementation at a time." In practice that's often what Dependency Injection frameworks like Google Guice are used for. It also allows modules to implement signatures after the fact, so you can create new views of modules without modifying them (unlike most languages where classes must know beforehand every Interface they wish to implement.) As a bonus, it wouldn't be too much of a leap to jump to F# afterwards. (Scala has similar features but syntax that's closer to the familiar curly-bracket languages).

If you go the Standard ML route, I learned with Programming in Standard ML. There's a couple of chapters missing from Section IV (Programming Techniques), but the material concerning the language itself is complete. I would, however, skip chapter 1. It's an overview of the language, and I found it mostly impenetrable on first reading. Coming from an OO background, chapters 6 and 7 were probably the biggest eye-openers for me. Being able to easily define a type by cases and using pattern matching is the feature I miss the most when I work in mainstream OO languages, and I never would've expected it's practical to prove a piece of code is correct.

There's also some lecture notes from Carnegie Mellon University's Functional Programming course, which the author of the book helped revamp.

[Icemage]

Re: The programming language/paradigm debate

Eww @ Scheme. I was forced to use that back in college for a class. Quite possibly the worst language syntax ever devised. Up until that point, I thought PERL was the most impenetrably difficult to read programming language, but Scheme puts PERL to shame for illegibility. I had nightmares about parentheses for months after that class.


Icemage

[ItazuraNhomango]

Re: The programming language/paradigm debate

I guess it's been too long since I've programed in a functional language. Armando, you want to pick one for me to get the mental gears turning again? (My previous-and-only experience was with Scheme, a LISP derivative with a clean syntax and too many parenthesis, IIRC.)

[Armando]

Re: The programming language/paradigm debate

True, but who uses D, and why would/should they? See my comment below regarding interpreted vs. compiled development.

It's a fairly new language, so right now, not a whole lot of people. But why would they? For the same reasons you might use C++. It's a C-style language (so low barrier to entry) that compiles to native code, gives you low level hardware access, and interoperates easily with C. The difference is it sacrifices being a superset of C's syntax in order to have a language with sane syntax, fast compile times, garbage collection, a more modern multithreading model, and most importantly no undefined behavior by default. It's a language you can write full applications in without dozens of potential traps and pitfalls, while still making it easy to do hacky, low level optimizations (you just have to ask).

While I'm not personally a proponent for typing drudgery, there are common use cases where having explicit type declarations enforced is useful. Specifically when other people are reading your code (or vice versa). You may know that arg1 is a real number, but if your coworker Joe has to come in during your vacation and tries to figure out what's wrong with your code, that's one more thing he has to research.

I still feel that's a non-issue, since documenting the code is mandatory for any kind of team-based work, and the IDE should know the types just as well as the compiler. In the very worst case, figuring out the type should just be a mouse hover away.

There are times when state-based values can be both practical and efficient, and functional programming holds the concept as anathema.

Only pure functional programming holds it as anathema. The only pure functional language that's not completely obscure is Haskell. All the others - Standard ML, OCaml, F#, Scala, and even Lisp - let you use side effects if you want to; they just don't assume that's what you want by default. I agree that mutable state is sometimes necessary, either because what you're trying to do just can't be done immutably (e.g. a circularly-linked list) or because the immutable solution doesn't have the performance you want. Sometimes you even need mutable state to create immutable values (e.g. using memoization to create a stream out of an ephemeral process like reading user input.)

[Icemage]

Re: The programming language/paradigm debate

D compiles lightning fast, fast enough to use it as a "scripting language" for the sort of throwaway command line programs you'd write in, say, Python.

True, but who uses D, and why would/should they? See my comment below regarding interpreted vs. compiled development.

That still doesn't answer why. C#'s features are pretty much a superset of Java's, so how can Java's iteration times be shorter?

Because you can often prototype component functions in JavaScript to make sure they're conceptually sound before implementing them and incurring a compile/debug cycle cost. That's the big ticket item. No matter how fast the compiler is, it's never going to be as hassle-free as interpreted code. If you're just writing a building block function of some sort, it makes zero sense to compile your whole project just to test whether you've made some sort of basic error that isn't immediately visible to a compiler.

Type inference and dynamic typing are very different. Dynamic typing masks errors, type inference doesn't.

I'm aware of the difference. What I was referring to earlier is that, with a compiler that accurately infers data types, you still have the problem of the user taking the feature for granted and then still needing to recognize when they've made an error.

While I'm not personally a proponent for typing drudgery, there are common use cases where having explicit type declarations enforced is useful. Specifically when other people are reading your code (or vice versa). You may know that arg1 is a real number, but if your coworker Joe has to come in during your vacation and tries to figure out what's wrong with your code, that's one more thing he has to research.

I'm not advocating pure functional languages either, because side effects are sometimes necessary and insisting that you can never use them is counterproductive. What I'm advocating is that we stop using it as the default way of solving things, because it's a pretty dangerous and seldom necessary default.I think you're confusing "Programming with function calls and primitive types" with "functional programming". They're not the same; functional programming offers you a superset of what OOP does as well as a saner default approach to problems.

You're sort of preaching to the choir here. I dislike OOP for the same reasons you do; there's a whole generation of programmers out there who cut their teeth on it and insist on using it everywhere, even when inappropriate. I'm just not willing to throw it out in favor of functional programming paradigms because functional programming has its own set of challenges. There are times when state-based values can be both practical and efficient, and functional programming holds the concept as anathema.


Icemage

[Armando]

Re: The programming language/paradigm debate

Even with advanced compilers, it still takes a lot of time to recompile a build in all C variants compared to pretty much everything else.

D compiles lightning fast, fast enough to use it as a "scripting language" for the sort of throwaway command line programs you'd write in, say, Python.

Java is faster to iterate and test-bed code on compared to C#.

That still doesn't answer why. C#'s features are pretty much a superset of Java's, so how can Java's iteration times be shorter?

Relying on compiler intuition for data typing often causes issues when working with fractional values, and especially when there is a need to transliterate to text/string formats. I'm a big believer in explicit data typing, and letting the compiler take its best guess at it is sloppy at best and headache-inducing at worst if it causes problems like unforseen rounding errors.

And yes, I dislike PHP/Python/Ruby and other unitype languages for similar reasons.

Type inference and dynamic typing are very different. Dynamic typing masks errors, type inference doesn't. I haven't used F#, but I do use Standard ML which is what F# is based on, and I'm fairly sure they use the same type inference algorithm. Standard ML is extremely strongly-typed. There are no type coercions - you can't even mix integers with floats (e.g. 3 + 4.5 is an error). Save for one corner case*, the compiler can not only determine the correct types of variables, it'll determine the most general type. You get genericity for free. For example, consider this function that simply returns its argument:

fun identity(arg) = arg

This function works for any type, and the compiler correctly infers that the type is 'a -> 'a, where 'a is a type variable similar to the T often used in Java interfaces like List<T>. In other words, it infers that the argument can be any type, and that the return value must be the same type. That example is fairly trivial, but like I commented earlier, its real value starts to show once you start passing functions around. Let's write a function that composes two others:

fun compose(function1, function2) =
....fn arg => function1(function2(arg))

Where fn var => exp is the syntax for an anonymous function. What is the type of compose? (('a -> 'b) * ('c -> 'a)) -> ('c -> 'b). Or, to make it clearer:
* Type of arg 1: 'a -> 'b
* Type of arg 2: 'c -> 'a
* Type of return value: 'c -> 'b

Type annotations quickly get complicated once you start using high-order functions, even though what you're trying to do is often simple. You can just write what you mean and the compiler will verify that you haven't done something impossible.

If you tried doing that in Java, you'd need to do something ridiculous like:

Java

interface Function<A, R> {
....R eval(A arg);
}

public static <A, B, C> Function<C, B> compose(final Function<A, B> function1, final Function<C, A> function2) {
....return new Function<C, B>() {
........public B eval(C arg) {
............return function1.eval(function2.eval(arg));
........}
....};
}

God help you if you want to write an anonymous function. But passing functions around is still necessary, so instead you see a lot of hacky workarounds: classes/interfaces like FooProvider, BarFactory, and IClickable whose sole purpose is to pretend they're functions or using design patterns like Template Method or Strategy. So you complicate the design, or simply choose not to push all that boilerplate around and live with a certain amount of code duplication. Either way, you lose.

* The corner case

As I mentioned before, there IS one corner case:

fun add(a, b) = a + b

Are a and b ints or reals (aka floats)? The compiler can't know, because the basic arithmetic functions are overloaded. My compiler defaults to choosing int. However, this only happens when the compiler has absolutely no information about the types. Even a single type annotation will completely disambiguate cases like these. For example:

fun add(a : real, b) = a + b
fun add(a, b : real) = a + b
fun add(a, b) : real = a + b

All completely disambiguate the function to be of type (real * real) -> real. If the function has any literals or constants, the whole problem goes away as well:
fun circumference(radius) = 2.0 * PI * radius

So the ambiguity is very easily avoided and only comes up in some very specific cases. Still, what if it does bite you? Well, your program won't compile when it infers the parameters are integers and you tried to pass floats, so you'll still catch the problem.

A (pure) functional programming language is something that every programmer needs to experience, but I'm not sure if it's the right kind of language for the most jobs. I think the majority of people (including myself) can conceive easier step by step path to solutions--imperative programming--than coming up with functional approaches for most problems. It's just more natural for humans, I think.

I don't believe it's more natural at all. It's what we're accustomed to putting up with, which is not at all the same. It is remarkably difficult to reason about imperative code, because side effects are hidden all over the place, and that destroys your ability to pick the code apart and reason about the statements on an individual basis. It is relatively straightforward to reason about functional code and prove it's correct, something that no amount of testing can do. We had a choice between languages close to a Turing Machine and languages close to Lambda Calculus. We chose the Turing Machine for efficiency reasons because we needed all the help we could get with that in the 70s-90s. But both hardware and functional languages have come a long way since then and the Turing Machine way of thinking isn't very amenable to humans. We haven't jumped ship yet because of the business problems Icemage put forth - first you have to convince people that functional programming is a good idea even though no one's doing it, and then you still have to deal with the hiring problem.

I'm not advocating pure functional languages either, because side effects are sometimes necessary and insisting that you can never use them is counterproductive. What I'm advocating is that we stop using it as the default way of solving things, because it's a pretty dangerous and seldom necessary default.

In general, I consider any fast "throw-away" tool like a bit of analytical code or a one-shot process to strongly favor functional programming techniques, while most processes that are built over many iterations over a long development standpoint or multiple programmers definitely favors OOP. There are of course exceptions to any rule, but these are "tendencies", and I think both approaches have value and should be evaluated case-by-case based on need.

I think you're confusing "Programming with function calls and primitive types" with "functional programming". They're not the same; functional programming offers you a superset of what OOP does as well as a saner default approach to problems.

[Icemage]

Re: The programming language/paradigm debate

I think if you include Go (from Google) as a C variant, that won't hold.

I don't consider Go to be a C variant any more than Esperanto is a Latin variant. It's a neat language, though.

I remember seeing somewhere a study that states Java is a significant improvement to programmer productivity compared to C++, but Python well ahead of both.

Python is indeed a much more productive language than Java or C++. C++ is actually one of the least productive programming languages ever conceived, aside from really low level stuff like Assembler or ridiculously verbose syntax languages like LISP or COBOL.

A (pure) functional programming language is something that every programmer needs to experience, but I'm not sure if it's the right kind of language for the most jobs. I think the majority of people (including myself) can conceive easier step by step path to solutions--imperative programming--than coming up with functional approaches for most problems. It's just more natural for humans, I think.

Functional languages have been around forever, and they haven't been able to make the case that their conceptual purity is worth the extra mental energy for most uses. Not yet, anyway.

I don't think ideological purity from either side is the appropriate viewpoint. Some applications lend themselves more fluidly to one approach than others, and sometimes it just doesn't matter. In general, I consider any fast "throw-away" tool like a bit of analytical code or a one-shot process to strongly favor functional programming techniques, while most processes that are built over many iterations over a long development standpoint or multiple programmers definitely favors OOP. There are of course exceptions to any rule, but these are "tendencies", and I think both approaches have value and should be evaluated case-by-case based on need.


Icemage

[ItazuraNhomango]

Re: The programming language/paradigm debate

Even with advanced compilers, it still takes a lot of time to recompile a build in all C variants compared to pretty much everything else.

I think if you include Go (from Google) as a C variant, that won't hold.

Java is faster to iterate and test-bed code on compared to C#. It's also less likely to produce an unrecoverable (and thus difficult to trace) fail state if there is a coding error.

I remember seeing somewhere a study that states Java is a significant improvement to programmer productivity compared to C++, but Python well ahead of both.


* * *

I just think we've reached the limits of what we can do using OOP. I could go into examples of how functional languages improve upon the usual way of doing things, but I imagine you guys are getting tired of my soapboxing by now.

A (pure) functional programming language is something that every programmer needs to experience, but I'm not sure if it's the right kind of language for the most jobs. I think the majority of people (including myself) can conceive easier step by step path to solutions--imperative programming--than coming up with functional approaches for most problems. It's just more natural for humans, I think.

Functional languages have been around forever, and they haven't been able to make the case that their conceptual purity is worth the extra mental energy for most uses. Not yet, anyway.

[Icemage]

Re: The programming language/paradigm debate

The point is that clearly there's a demand for a language that's not C++ among indie developers, and clearly some people are trying to meet that need, so I think it's unfair to deny that indies try out alternative languages or frameworks.

Oh, no doubt. C++ (and even the farther offshoots like C#) have an iteration workflow that can be best described as "ponderous". Even with advanced compilers, it still takes a lot of time to recompile a build in all C variants compared to pretty much everything else.

This is kind of tangential but I'm curious why you consider Java good for productivity and not C#.

Java is faster to iterate and test-bed code on compared to C#. It's also less likely to produce an unrecoverable (and thus difficult to trace) fail state if there is a coding error.

What bad habits?

Relying on compiler intuition for data typing often causes issues when working with fractional values, and especially when there is a need to transliterate to text/string formats. I'm a big believer in explicit data typing, and letting the compiler take its best guess at it is sloppy at best and headache-inducing at worst if it causes problems like unforseen rounding errors.

And yes, I dislike PHP/Python/Ruby and other unitype languages for similar reasons.

That's all true, but the transition to a new technology or paradigm will pretty much always be uncomfortable. You can't ask for much more than good backwards compatibility. Somebody's gotta take the plunge somewhere, or we'd all still be coding in C.

I agree, but I don't think bolting on pieces of F# onto a C codebase is going to get you where you want to go. You can't really transition that schema to anything else, or even slowly convert the legacy C portions to F#. It's just an awful solution all around; if a language is to be seriously considered as a contender as a dominant language, it really ought to be feature-complete, not riding the coat-tails of what came before.


Icemage

[Armando]

Re: The programming language/paradigm debate

I don't know anything about programming, but I can comment on the developer culture if anybody's interested.

At least I'm interested, although it's probably better to re-start that discussion in the XBox 1 thread.

I don't want clever, I don't want the bleeding edge. Just something clear and readable, so I write fewer bugs and have easier time fixing stuff later.

I can understand that. I just think we've reached the limits of what we can do using OOP. I could go into examples of how functional languages improve upon the usual way of doing things, but I imagine you guys are getting tired of my soapboxing by now.

[DakAttack]

Re: The programming language/paradigm debate

Which is exactly why it's silly to be against the low barrier to entry for indie development. From what I've read - and hopefully someone else can chime in here - a very large portion of the professional game development is toxic - incredibly unhealthy work/life ratios, high turnover rates, and lower wages/benefits than being an average enterprisey software developer. They have a huge pool of young, unmarried people they can chew up and spit out over a short time span. With a process like that, a relatively low number of people last long enough to become experts. On top of that, the state of the art still involves using an antiquated and tragically flawed programming language (C++) and a very misunderstood and problematic programming style (object-oriented).

Letting anyone with a computer try to make a game may produce a lot of garbage but hopefully we'll see some progress in game development techniques and pass them on quicker and to a wider audience than the industry currently can.

I don't know anything about programming, but I can comment on the developer culture if anybody's interested.

[ItazuraNhomango]

Re: The programming language/paradigm debate

That's all true, but the transition to a new technology or paradigm will pretty much always be uncomfortable. You can't ask for much more than good backwards compatibility. Somebody's gotta take the plunge somewhere, or we'd all still be coding in C.

I'm all for progress. I just ask that we progress to a language where I can understand the code I wrote six months ago.

I don't want clever, I don't want the bleeding edge. Just something clear and readable, so I write fewer bugs and have easier time fixing stuff later.

[Malacite]

Re: XB1 3 Million Units Sold

See I always thought that was "geek argument".

Oh ffs... I know this is a woosh, but goddamn let the 2014 "Semantics Royal Rumble" (working title) begin!