The programming language/paradigm debate

[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.)

[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.)

[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

[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.

[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...

[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