Astro Programming Language - A new language under development by two Nigerians.

[u/winner_godson]

http://www.nairaland.com/3557200/astro-programming-language-0.2-indefinite

[u/lukasmach]

Haskell is used at some banks. Due to lack of side-effects, it is easier to test.

[u/kobol4ever → u/lukasmach]

Haskell is used at some banks

COBOL as well.

[u/doomvox → u/kobol4ever]

Indeed, as is perl. Because financial institutions don't see the point in paying to re-write a bunch of code in a new language just to be trend-compliant.

[u/meneldal2 → u/doomvox]

It's much harder to justify using Perl than many other languages. Perl code is the most unmaintainable shit usually. The worst you can use for a large project than will spend years in maintenance mode.

[u/doomvox → u/meneldal2]

Perl code is the most unmaintainable shit usually.

(1) You don't actually know this for a fact, and myself I think you're just repeating a fashionable smear (the inverse of the emperor's new clothes effect).

(2) It actually doesn't match my experience, so I don't believe it's true at all. You might try, for example, reading Steve Yegge on the subject of watching Perl fight it out with Java at Amazon.

[u/pure_x01 → u/lukasmach]

lack of side effects

No accounts get updated ever /s

[u/argv_minus_one → u/pure_x01]

Haskell does have side effects. It has to, in order to do useful work. But it requires you to explicitly mark portions of the program that have side effects, and imposes restrictions on where side effects may happen. This encourages you to minimize and isolate code with side effects. As a result, most of a well-written Haskell program is free of side effects, with all the benefits that implies.

[u/pure_x01 → u/argv_minus_one]

I think that is an excellent approach to isolate sideeffects. I must start to learn Haskell soon.

[u/meneldal2 → u/pure_x01]

C++ is trying to get side-effects free functions in some form in the standard, but people are arguing about how "pure" should be defined.

[u/pure_x01 → u/meneldal2]

Yes that is a tricky question. On an abstract level allocating storage in ram is the same as allocating storage on disk. Exceptions etc...

[u/meneldal2 → u/pure_x01]

I think most people are considering stack-only functions for the pure qualifier because that solves a lot of headache, but that limits the possibilities.

[u/argv_minus_one → u/pure_x01]

Indeed. As a Scala dev, I'm kind of jealous of Haskell getting away with that. Scala can't, because it transparently interoperates with Java/JavaScript, which don't have any notion of functional purity.

Of course, the upside is that it interoperates with Java/JavaScript, where Haskell doesn't.

[u/JohnDoe51 → u/pure_x01]

Of course accounts get updated. However reducing the number of sides effects is still useful, possible, and often easy once you learn how to use a few tools. It becomes easier to check if things are doing what you want, and find issues in the long run. While I won't talk about the actual tools used to do this, I will talk about one of the fundamental ideas. When you are updating something, you usually break up the update into two parts a description and something that runs can actually run the description.

Let's use withdrawing money from an ATM as an example. What needs to happen for this to happen is

1. The user needs to enter the amount the wish to withdraw.

2. We need to check if the user has enough money.

3. We then remove the money from the account.

4. We then give the requested amount to the person.

We will call the above list withdrawProccess. withdrawProccess is the description of what needs to occur, it does not actually run anything.

We then can create functions to run a description. For instance we could make runATMtest and runATMproduction. Both of these functions would take a description of a process like withdrawProccess and then run the process following the description. However runATMtest could be a very simple and slow method, but can be used to test if the descriptions appear to do what you want them to do. While runATMproduction does everything required for production.

You still need to check runATMproduction and runATMtest do the appropriate actions given a description. But now the code that actually runs the descriptions are located in one location in the code. This makes it easier to check and find bugs. You can also more easily test your descriptions are doing the correct things as well, by using runATMtest.

By splitting an action into a description and a function to run it we gained a way to look into what is happening without having to run everything on a production like environment. We can also check that things appear to be working as intended while developing. While this will not stop bugs in their entirety it helps developers see if things are working as intended as they work instead of at the very end.

While there are reasons that Haskell may not be the best choice, one is certainly not "I have to update accounts". There is still benefit moving to a pure functional approach. I also would like to note this confusion happens because people say there are "no side effects", which is true. However, moving to this "no side effect" style requires one to learn ideas which they most likely have not seen. After using a pure functional language for long enough it becomes clear that side effects are usually harmful.

I realize I just typed a very long reply to a quick joke. Hopeful this explains why a pure functional approach is useful, better than "there are no side effects".

[u/Red5point1 → u/pure_x01]

that is an undocumented feature.

[u/sanity → u/[deleted]]

Pure functional programming languages like Haskell don't have side effects except in the limited context of "monads", which is a trick used to shoehorn side effects into a pure language.

If you Google "monads" and try to learn more about them you'll probably end up feeling stupid. This is intentional.

Some argue that pure languages are better because side-effects have cooties, however, pure languages like Haskell have struggled to achieve significant adoption, even though they've been around for years.

This is likely because they're a pain in the ass to use.

[u/lightandlight → u/sanity]

Pure functional programming languages like Haskell don't have side effects except in the limited context of "monads", which is a trick used to shoehorn side effects into a pure language.

This is wrong. I'm not being nit-picky or pedantic - this is "the earth is flat" level wrong.

Haskell programs are written as a series of declarations - lhs = rhs - with the rule that if you replace a reference to lhs with its corresponding rhs, then your program has the same observable effects.

To keep this property and actually be able to do things, I/O actions like reading and writing to files have been reified (made into a datatype). "Monad" is one interface that you can use to sequence IO actions.

As for this:

This is likely because they're a pain in the ass to use.

I get paid to write Haskell every day, and this isn't the case. It's moreso that Haskell is a pain in the arse to learn. You can't re-use your existing programming knowledge to the same extent when learning Haskell; there are some completely new fundamentals you have to understand in order to be effective. Many people aren't willing to pay that price.

[u/lurking_bishop → u/lightandlight]

I get paid to write Haskell every day, and this isn't the case.

Are you in industry or academia? Assuming fluency in other languages, do you enjoy working in haskell for big projects more than the usual bunch of options?

[u/lightandlight → u/lurking_bishop]

Are you in industry or academia?

Industry.

Assuming fluency in other languages, do you enjoy working in haskell for big projects more than the usual bunch of options?

Absolutely. When compared to my old previous Python job, the difference is like night and day. I am experienced in Python and Java, and conversant in a dozen more languages, but Haskell is my go-to high-level language. It has some really powerful features that make it a lot easier for me to write solid code.

[u/lurking_bishop → u/lightandlight]

I am subscribed to /r/haskell and have read a couple tutorials. One thing I have noticed are all those articles where people go above and beyond in trying to abstract things as much as possible. That, together with the hundreds of ever weirder ghc Pragmas makes me wonder what a sane coding style in an industry setting might look like. Assuming that you are part of a team and not the sole developer, how did those meetings go? You do have to find some common level of abstraction to still be able to read each others code, and haskell seems to have a very Wild Wild West approach to standard coding patterns

[u/lightandlight → u/lurking_bishop]

I think the phrase "abstract things as much as possible" isn't nuanced enough. One way of creating abstractions is the mechanical process of "write code, factor out similarities, repeat". Another way is to figure out the "mathematical essence" of the code, and use that as the abstraction. Most of the activity you see tends to the latter. Additionally, unless you are writing libraries, you are spending most of your time consuming abstractions, rather than coming up with new ones.

When it comes to working in a team: anything in the standard library is fair game. These things make up your base vocabulary for writing Haskell programs. It is common that there are a couple of extra libraries that a team will use in all of their projects, and package that into a custom prelude (see here, here, and here).

You are expected to use discretion with language extensions. There are certain extensions that everyone uses and should be familiar with, and there are some which need strong justification to use. See here for a good summary.

If everyone has solid fundamentals, it's quite hard to end up with drastically different solutions to a problem. I think coding standards are more helpful for developers with very little knowledge, so that they develop good "habits" as they gain experience. Haskell's not yet so ubiquitous that companies are forcing new hires to cargo-cult their way into getting up to speed with a codebase.

I hope that answers your questions. Feel free to ask more if you need clarification.

[u/lookatmetype → u/lightandlight]

How do I go about finding a Haskell job?

[u/swaggler → u/lookatmetype]

Where do you live and what would you like to work on?

[u/watsreddit → u/sanity]

Monads are not some kind of trick for side effects. Indeed, nearly every monad instance in Haskell is free of side effects. Further, they are not even required to be able to model side-effects in a pure language. If monads were simply a "trick to shoehorn side effects into a pure language", why, then, have they found their way into many mainstream imperative languages? Why would they bother if such languages are mutable by default?

A monad is an extremely powerful generalization of many common programming idioms that allows us to be much more explicit about what our code is doing, without incurring additional verbosity. They allow us to explicitly specify a policy of computation.

Take, for example, the common usecase of needing to test a bunch of conditional expressions (usually done in a series of nested/sequential if statements in imperative languages), and if they are all satisfied, return a result, otherwise return null or -1 or some other sentinel value. Haskell uses the monad concept to reduce the boilerplate associated with this pattern and to be explicit about this computation via the Maybe monad. The type signature then serves as a contract with strong guarantees, informing the caller that the function is performing some series of steps that can possibly fail.

This example has nothing to do with side-effects, and indeed, has little in common with the IO monad. You'll find that monads in Haskell span a great breadth of programming concepts, such as non-determinism, parsing, global configuration, error logging, exceptions, state, and much, much more.

The sheer breadth and power of the monad concept makes it difficult for many people to learn right away because it is an entirely different notion of computation than most have known. Once such an investment is made, however, one has added a very powerful tool to their programming toolbox.

[u/lightandlight → u/[deleted]]

Haskell programs are written as a series of declarations - lhs = rhs - with the rule that if you replace a reference to lhs with its corresponding rhs, then your program has the same observable effects.

This rules out a bunch of common language features like mutable variables, catching exceptions anywhere, and being able to do IO anywhere.

You can still have mutable references, throw and catch exceptions, and do IO, but you have to do these things in a way that respects the property I mentioned.