Functional programming imposes restrictions on otherwise imperative programming, in the hope that programs that satisfy this restriction are easier to manipulate as mathematical objects, both formally and informally. This restriction comes with an expressiveness price. For example, FP limits the kinds of nondeterminism that can be expressed in a program, because the lambda calculus is Church-Rosser: if you evaluate a lambda term twice, and both times arrive at an answer (normal form), then both times you arrive at the same answer.

A general-purpose programming language can’t be purely functional only. For example, Haskell has IO actions, and which are executed, not evaluated. However, a programming language can make it easier to implement parts of a program in a functional style, and integrate them with other parts implemented in a more traditional imperative style. For this to work, you need a guarantee that the imperative parts won’t compromise the abstractions that the functional parts depend on. Pervasive object identities compromise the irrelevance of the choice between multiple representations of the same value.

It should support both computation by evaluation and computation by execution. Evaluation is a smooth generalization of high school- and university-level mathematics, and is defined in terms of standard mathematical concepts such as tuples, functions, numbers, and so forth. Variables are given meaning by substitution, and evaluation consists of simplifying expressions. Execution is the action of a program on another agent or data structure conceived of as existing independently of the program itself. The data lives “over there” and the program “over here” diddles that data. Assignables (my word for what in imperative languges are wrongly called variables) are given meaning by get and put operations (fetch and store), not by substitution. Execution consists of performing these operations.

Source

For reference this is actually impossible by Rice’s theorem (which, in extreme brief, states that you can’t always tell what an algorithm will do). It’s actually strikingly easy to prove by reduction to the halting problem, and it’s my favorite result in computer science, because it’s both very general and simple and elegant to prove.

No. Function equality is undecidable in ML. “Being equal” doesn’t imply “can algorithmically be determined to be equal”.

I keep virtually all of my code on GitHub, that way, I have a backup. What few non-open source things I do are in private repositories.

Because other people can reference it if their time is not valuable and they’re willing to put the time in to read the source. Code gets open sourced for a lot of reasons, and a lot of them are not necessarily for to make something that’s immediately usable in a commercial setting. How people donate their time is really not something you can expect to really control.

Thus the above advice: If it’s not documented and you’re on the clock, assume the library doesn’t exist honestly.

There are plenty of employers who look at your github activity as a quick gauge on your code/activity level outside of work or classes. Not necessarily a fan of the practice, but it is a real reason people put up code that’s not for widespread consumption.

Many users shared your frustrations, but they’re still users. Their frustrations with the project must be less than whatever frustrations drove them to use someone’s undocumented code. If enough people find this code useful, maybe they’ll consider contributing documentation back to the code base as they figure it out. If the author sees this, they may realize that if people find the undocumented draft project useful, that maybe it’s worth some effort to improve it. Or the author doesn’t care, someone forks the project, and it takes off.

There are many paths to useful open-source projects, and they don’t all require the author to spend an inordinate amount of time documenting every feature for a project nobody may ever see. The onus on deciding how to put together your project is still on you, not the authors of every piece of open-source code that might be relevant to your project.

You think people publishing code are doing it for you, and want to chastise them for not bringing the quality to your standard?

I think it’s much more sensible to simply assume that they’re not doing it for you, but for some other reason. That is to say that I don’t think people post these projects with the intent that other people will use them, but for some other reason. Some do it because it is a convenient backup, and others because it’s the minimum needed to get a contribution, but I don’t know anyone who does it for other people.

And yet: I do want projects to have better documentation. I think a documentation standard is more valuable than a coding standard: We are writing for humans; the computer does what we say, but we write to express what we mean so that human beings can fix our mistakes in stating it correctly. To this end, I recommend that programmers write documentation first, and then implement the documentation, and I consider a programmer who cannot document his software to not be a very good programmer. I just don’t think this blog posting is how we get there.

The omnisharp-roslyn stuff technically uses Roslyn – the same thing we use in VS to power the C# language service, but the devil is in the details.

We’re still working on generating a completely platform agnostic Roslyn abstraction that will let consumers everywhere “plug in” to the language service at various points.

We had to use webforms on the assignement, but I’ll try again when we get to MVC.

“You can’t underdress to a Bio-tech interview” He was failing the come-over-for-dungeons-and-dragons test and he didn’t even know it…

I know of bio-tech startups that behave very similarly to this. Perhaps not in the clubby, hipster way, but in a manner that suggests a similar lack of professionalism in social aspects.

Yup.

I would maybe argue that this is personal bias. Understanding chemistry is the basis of petroleum engineering, pharmaceuticals, materials science, and a bunch of other really important stuff (generating and storing electrical energy efficiently, fertilizers/pesticides, etc.). Between them those things underlie a vastly larger fraction of socio/political/economic power in the world than software.

I think it’s easy to get an inflated idea of the importance of something (e.g. software) when you live and breathe it every day.

If I had to guess why there’s such an outsize effort to get people into software I would probably say it’s just because there happens to be a labor shortage at the moment, but I don’t really know ¯_(ツ)_/¯.

I think that’s totally personal bias. Oil has more power than computing could ever dream of and no one is saying “teach all our kids petroleum engineering.”

I think that the importance of software lies on the fact that it works as a tool to enhance people’s capabilities. While other fields may be directly involved in the production of good and services that are fundamental to support our modern lifestyle, software not only has an impact on these fields but in almost everything else we do, be it big or small. Because of this, its reach is, at least, much larger than any other field I know of.

The act of producing a value is a side effect. If you print it to a screen, it’s a side effect. If you set the exit code of your process, that’s a side effect. If you want to do anything like communicate with a database or a service or a keyboard, those are all side effects.

Even non-termination is a side-effect (one which happens to be uncontrolled in Haskell).

I think there’s a feeling that static types completely supersede dynamic types with such minimal side effects that there’s no conceivable reason to pick dynamic types should you have the option. These arguments usually proceed technically noting that statically typed languages can embed dynamically typed languages with no trouble while the opposite is not true. This seems to be a clear indication that static typed languages are “more powerful” than dynamic typed languages. Further, since this embedding proceeds via static typing formalism it’s easy to say that those who disagree simply have not learned sufficiently much to be familiar with this argument and would be immediately changed should they ever learn it. Finally, it’s sometimes the case that a person who’s been extensively exposed to dynamically typed languages will learn the static formalism to understand the “uni-typed argument” and then will end up feeling static types are superior thus forming an existence proof of this progression.

I think that’s a technical description of what happens sometimes from the statically typed languages camp. Note that it’s a bit fallacious in that it conflates “embedding” with “superiority” without really defining the latter. Oftentimes definitions of superiority are given but it’s unclear whether those notions still follow from “embeds” let alone whether everyone ever agrees about those definitions.

From the dynamically typed languages camp people tend to argue from proof of popularity and existence of solutions. It’s hard to understand why introducing more technology, its corresponding immediate mental overhead (again, static types embed dynamic types and thus, often, are additional formalism beyond dynamically typed languages), and the associated retraining costs will “improve” code which can and has already been written. It’s rare to find anyone who would argue that code written in a dynamically typed language cannot be more easily made to run than code written in a statically typed language (though both camps may implicitly assign different value judgements on this outcome).

As a final force, it’s often the case that additional formalization can be added “atop” a language. Some might even consider “unit testing” at large to be such a thing, although a more commonly acceptable example might be Valgrind. This extra formalization can be seen as either “checking programs” or “restricting the language definition” based on your point of view. It turns out that oftentimes people using dynamically typed languages will seek out these extra formalizations in order to provide faster feedback loops on the correctness, safety, or resource utilization of their programs. It also turns out that people using statically typed languages do the same (again, see Valgrind) although these tend to be characteristically different from the systems used for dynamically typed languages since statically typed languages already have higher levels of formalization.

Ultimately, all of these forces are at play and lead to a great deal of debate while the real value judgements at play are ignored. Greater formalization leads to faster response cycles on program creation (which is often considered a pro) but may do so using less information and thus be less informative themselves. Ultimately, this forms a UX problem: for different kinds of programming tasks do you want a programming interface which tells you quickly when you’ve made some class of errors or one that defers failure and allows you to determine more information about the runtime first?

A further concern is that systems which defer more errors for later stages today tend to be less capable of “completeness”. As an example, building a unit testing suite will help you to validate your program but due to its expense and nature it’s unlikely to ever build a unit testing suite which comprehensively confirms global properties of your program (such as static type safety). Dually, systems which respond more quickly tend to be less capable of “depth” as they must operate with less runtime information.

Both of these weaknesses are being addressed. “Incomplete” systems are growing more powerful and seeking out ways of examining whole ASTs for interesting properties (see: Typed Clojure or Dialyzer) while “shallow” systems are growing stronger formalisms for capturing higher information scenarios (see dependently typed languages and theorem provers).

The “embedding” property is an interesting one that everyone should be familiar with—and I think personally I agree with some of the static typing zealots who suggest that people who “do not understand static types” tend to be unfamiliar with it whether or not I agree that this unfamiliarity is damaging. However, instead of using it as a poor proxy for “superiority"—especially of any particular language over any other—it’s better to see it as evidence that all of these techniques are, in theory, composable.

Since we’re ultimately solving a UX problem which discerns between variables like “error detection turnout cycle time”, “richness of error information”, and “completeness of evidence of validity” we might prefer a system (or set of systems) which allow us to tune each of these things and use them as the situation calls for it. As far as I’m aware no such system exists, though GHC’s –fdefer-type-errors is a step in that direction as is Typed Clojure and Typescript.

Finally, there’s an open research question as to “ease of use” and “error risk”. It’s hard to answer questions directly such as “is it easier to learn a statically typed language or a dynamically typed one” as it’s impossible to (a) formulate what “easier to learn” means and (b), more powerfully, it’s impossible to establish that counterfactual without using a randomized study which is, today, infeasible.

There is a lot of evidence in process engineering that suggests that early error detection vastly improves total cost of creation (I wish I could remember the guy’s name who pioneered a lot of the observational research on this!). This seems to provide justification that statically typed languages can lead to much faster total development time. Unfortunately, this effect is often compared with startup times (which can be mitigated by an enormous variety of techniques including pure tool familiarity) and mischaracterized. This is sad because it’d be great to have real data about how different kinds of process testing (and I’ve outlined quite a variety above) actually do or do not improve various kinds of projects. Information like that would be instrumental to efforts to better solve the language UX problem outlined above.

Welcome to tribalism on the Web, I guess? People identify with their tools inappropriately and interpret good things said about alternatives as attacks on themselves.

Knowledge of the state of the art almost always means not finding uni-typed systems very interesting. At least for practical day-to-day work anyway. We’re talking about differences on the scale of arguing in favor of outhouses rather than indoor plumbing. You won’t get serious arguments for that from people with comprehensible value preferences.

I used to use Clojure (Python, Common Lisp), now use Haskell. I simply didn’t know any better despite thinking I knew what type systems were like due to exposure to other statically typed langs.

I was very wrong. And no, Scala and OCaml don’t hit the mark.

I’ve talked to people that have published on augmented uni-typed systems who still didn’t know much about what writing code in more advanced languages was like, so it’s not only industrial programmers that lack exposure.

Mine and other peoples' experiences are discussed here: http://bitemyapp.com/posts/2014-04-29-meditations-on-learning-haskell.html

Repeat: I used to be on the other side of these debates. Had tons of experience in Lisps, statically typed languages, FP, the works. I still didn’t know any better.

The one and the same!