Worried about types + Clojure Elitism

Found this edifying post in the “People are worried about types” section of The REPL:

The author takes Rich Hickey up on the challenge: to think of every parameter to and the return value from every Clojure fn as being of type EDN.

He then proceeds to define the EDN type (in Haskell) and then writes a map fn that uses it:

clmap :: (EDN -> EDN) -> EDN -> EDN

Along the way he makes a case for why you might want to use Maybe and Nothing to make the EDN type more tractable.

I’ve always thought of the static typing argument from the standpoint of “what would Clojure look like with static typing”. Seeing it from the other side: “what would Clojure typing look like in Haskell” provided a valuable shift in perspective.

I definitely think more effort could go towards making Clojure accessible. The language itself is easy to learn and fun to use once you develop a good workflow. However, lack of tooling and documentation around it make it unreasonably difficult to get up and running on your own.

I think the problem is also compounded by the fact that a lot of the tooling is not well known outside the Lisp community. Using Clojure without the REPL and paredit/parinfer can feel downright painful. If nobody shows you that these tools exist, or how to use them effectively, then you can spend a lot of time getting frustrated.

8 Likes

That Front Row Ed article is very biased and makes its “point” by misrepresenting EDN and Clojure and skimming over (i.e., ignoring) a lot of details about semantics. It gets many function signatures completely wrong, omits arities, and is really rather self-serving instead of being suitably enlightening.

1 Like

Hi,
I just signed up so I could reply to this as it is an issue I feel strongly about and perhaps could shed some light. I haven’t read all the replies on this thread but many here seem to be experienced with Clojure and programming in general and there seems to be a variety of opinions on why new programmers aren’t taking up the language.

I consider myself a beginner Clojure programmer and somewhat of a beginner programmer in general too, though I have enough experience to kind of know what I’m talking about. As background: I completed a BSc in Computer Science at a university in New Zealand in my early 20s having not done in any programming prior to that and did not get a job in the tech field after that and have not been programming since but recently got back into it. So I don’t really have much practical programming experience only undergrad programming experience so in that regard I am a beginner.

I started learning Clojure programming some months back using Clojure for the Brave and True tutorials online (I think that was it) and I found that while it can be easy to get started with toy stuff doing these tutorials using tools like LightTable, online sites that let you type and run Clojure code on the site page and just using Leiningen and the REPL then at some point you want to graduate to more practical real-world programs and want a more ‘professional’ dev environment. This is where it gets really, really difficult for me as now you’re looking at something like IntelliJ IDE with Cursive or Emacs with the associated Clojure plugins or whatever you call them.

Learning how to use Emacs is like learning a new lang in itself and I tried what I thought was the easier option in IntelliJ - as soon as I try to build or run my program or whatever, instead of my program building or running some menu screen pops up with no helpful error message or anything. I suspect I have some Java build configuration setting or what not misconfigured. I can build and run Java programs and other langs just fine though.

After looking at various IntelliJ tutorials and searching for help on that, after a couple days, I just gave up, despite Clojure being my favourite programming language out of what I looked at so far. I still am planning on giving it another go and have already but each time I get stuck on getting a decent dev environment set up.

Learning a language full of parentheses, Lisp weirdness and a different way of thinking about things than OOP was not such a problem for me as a beginner. In fact it makes it more exciting and inspiring to learn because it’s fresh food for the brain. Getting stuck on build configuration issues or whatever it was while trying to get a bare minimum decent dev environment up and running is really not a fun, inspiring problem for a beginner. That’s the kind of problem that makes a beginner go “Ah! Screw it! This isn’t worth the trouble.” Especially when for just about every other language under the sun you can download, install and have a nice dev environment up and running in around 10 minutes. So given how long it’s taken me to get a dev setup going with Clojure which I still haven’t managed then I am thinking Clojure is worse than other languages in that area by many orders of magnitude.

So in conclusion, speaking as a Clojure beginner, I would say Clojure’s number one problem with attracting beginners is the dev environment setup. It’s simply monumentally painful for me. Any other reasons that may be mentioned here in this thread I would say are very secondary issues to this one here. Some batteries included IDE that can make useful real-world programs with fairly professional tooling but is still easy on beginners would go a long way towards fixing this situation I would think. And it would need to be promoted by the community as a clear choice for beginners.
I think Zach Oakes has something new out. So I will check that out and see if it helps :slight_smile:

7 Likes

I think you’re right about this. We need an integrated dev setup solution. That means REPL, testing, and dependencies, all set up for you, without requiring any particular editor.

1 Like

I love Zach’s idea to start with a lot of hand holding but allow users to export their projects into a local setup when they feel ready.

3 Likes

Okay, I’ll bite.

I think it is useful to look at the type signature for something like clmap that @billburcham mentioned. That article definitely shows the mindset of the statically typed (Church types) crowd. Clojure data is untyped, so obviously it would all be one big algebraic data type.

If you were going to go all the way with Clojure, functions are a valid data type, so you actually need a case for functions in your EDN type. The clmap type would then be:

clmap :: EDN -> EDN -> EDN

How absurd this type is! What’s more, nearly every function’s type signature would look like this. There’s no information in it except the number of arguments. And that’s true from a certain perspective. This is exactly as much static type safety we have in Clojure–none.

However, we, as Clojure programmers, know that not all EDN values are valid for the arguments to map. We know it, even if it’s not written down. Even if no checker is watching over our shoulder. We know that the first argument should be a function. We know the second argument should be something you can call seq on. And we know it will return a seq.

But the article does not acknowledge that. It just says “look at this silly type” to dismiss Clojure. Such an obvious straw man. The challenge is to do what Clojure does but in a Haskelly way, not to do what Clojure does in Haskell. Why use Haskell at all if you’re going to throw out type safety?

So let’s start to build out the types. The mental types for Clojure’s map are very similar to Haskell’s, but perhaps a little richer.

clmap :: Seqable L => (a -> b) -> L a -> Seq b

It’s something like that, except it’s only as strict as you want to be. That is, a and b can be precise types that a Haskell compiler would understand, but that’s up to you. You could do anything you wanted. That’s actually a huge difference between the static and dynamic views. In static, what you can do is primary. In dynamic, what you actually do is primary. For instance, you could say that a doesn’t have to be any particular type, just that the values in the Seqable are printable. The Seqable could be heterogeneous, but that’s okay because we’re only going to call print on them. It’s not possible to do that in Haskell without building a new type and all the ceremony that entails. To me, though, it seems perfectly reasonable to build a List of printable stuff to print out later. Making that possible seems like a good thing and I have ideas about how to make it possible in Haskell. That would give you the type safety of Haskell with some of the flexibility of Clojure.

Let’s look at Clojure’s hash maps. When we use maps in Clojure, there are a few possible scenarios.

  1. We know (or assume to know) that the map contains some known keys and potentially others that are unknown.

    In this case we treat the hashmap like an “entity”. We can dig values out and update them, leaving the keys/values we don’t care about in place.

  2. We don’t know what keys are in it.

    We can treat the map as a generic container of key-value pairs. That means we can iterate over the keys, merge two of them, etc.

  3. We don’t know the keys and values, but they’re of homogeneous types.

    This is like the index pattern, where you’re using the hashmap not as an entity record but to provide a constant-time lookup for values based on an index. group-by and frequencies provide hashmaps like this, and it’s common to build them yourself. Think of a hashmap used to look up something by name.

Hashmaps in Haskell are really only meant for #3, where things have easy types (Hashmap String Int). In Haskell, they use data types to represent entities like #1, but those have fixed keys. And you can’t do #2 with them, that is, treat them as generic containers. I know people mention Row Types. That’s great! I think they’re really interesting. But it’s just one feature that kind of solves for case #1 – it lets you talk about minimum subsets of keys and treat them somewhat generically. But #2 can’t be solved by them.

When I say “Row Types are just one feature”, what I’m trying to get at is the challenges of “situated software” require a wholistic view on things. Row Types could play a significant role in a proposed design solution. But there are countless other decisions that need to be made. It’s like saying you can use Immutable.js in your JavaScript, so why use ClojureScript? Sure you can use it, but is it integrated in? Does it cause more impedance mismatch than it solves?

You can’t point at Row Types as an answer and then give your examples in Haskell because Haskell doesn’t have Row Types. You can’t point to a bunch of features and tell me to put them together however I want. That’s a bit like someone asking what web framework to use in Clojure and I tell them to put together a bunch of libraries themselves. It might be how we do it, but it’s not a satisfying answer to the question.

If the existing tools of Haskell (or any language) do give you what you need to write “situated programs”, then where are the guides for how best to do that? Or if they are cumbersome to use, perhaps there are best practices around how to reduce the cumber. Clojure isn’t perfect and we have to do a lot of the same. Or maybe people know it’s possible but they haven’t quite found out how yet. Just be honest and say that. I mean, Rich Hickey really did just give that talk. No pressure to answer right away. Or maybe the whole enterprise of “situated programs” is not relevant. But they’re not saying that, either.

Eric

7 Likes

Yes I think so. I’ve done the exercises and Clojure tutorials and stuff, it is not so difficult to get started, though certainly the lack of clear cut choices there doesn’t help much either. It is now when I want to take the training wheels off and graduate to a more full-powered dev setup that things fall apart. There is no great dev setup with first class Clojure support. No Visual Studio for Clojure. And I think that really hurts it for gaining new people. It has certainly proved a major frustration and roadblock for me.

Just having IntelliJ with Cursive integrated already and everything pre-configured would certainly help. I believe they may have mentioned on their site that they were going to do that at some stage unless I’m mistaken.

I’m still not sure that would be the best solution though as their business model seems more geared towards upselling people to the paid IDEs and you need to sign off on that agreement thing they have to download Cursive. I imagine that would put off a fair number of people getting started too. If they had a decent, free, fairly full powered, batteries included Clojure IDE that would be pretty cool though. I think that is what is needed to get more people to adopt the language.

A critique of types as entities

Rich Hickey has a really nice talk called Clojure Made Simple: Clojure Made Simple - YouTube

At around 50min, he shows this slide:

The question is, how many key-value mappings are there? It’s actually really hard. Because there are some that are explicit, like getAttribute() that returns the value of an attribute given the name of the attribute. And there are other similar ones, like getHeader() and getProperty(). But then, if you squint, you see that all the get... methods are really just keys for their respective values. So getLocalPort() is just going to return the port. The method is the key, the port is the value. And most of the other stuff is like that. But they’re all ad hoc and different. He then shows how a Ring request map can represent the same stuff but through a unified interface, the map.

Now, to be clear, you lose something. Specifically, you lose static type information. That Java class did encode a lot of static information that we’re now throwing out. And you get static checks on the names of the methods.

But we gain a lot, too. We can iterate over the keys. We can serialize it as we serialize other things. And generally, we know how to operate on hashmaps because it’s common in Clojure. We don’t have to learn any new patterns. It’s at this higher level where a lot of the magic happens. Reuse. Decoupling. Composability. Higher-order constructs.

I think Rich is making a similar claim with Haskell’s types. Many times, you’re just creating ad hoc key-value data containers. And each of them has a name and writes in stone what keys it accepts. You get safety. But if you put them in a map, you’d get the other things.

Clojure separates out defrecords from deftypes. deftypes are for low-level implementation entities. They have a fixed set of fields. These are equivalent to Haskell’s records. But there’s nothing like defrecord in Haskell. There’s nothing to flexibly and consistently represent domain entities. Haskellers use the same construct for both. At first I didn’t understand why Clojure had two things. But after a while I saw that it was a very profound design decision. In the end, though, using hashmaps instead of defrecords won out. It turns out you didn’t need a third thing except in very limited cases.

2 Likes

I haven’t tried that one but I did try the pre-cursor nightcoders and liked it. Indeed I made it my main tool for learning Clojure at the time. My main issue is that it is nice to start off with these environments for beginners but then when you want a more fully tooled environment there is no easy entry point in the Clojure world. There is no fully tooled environment with first class Clojure support.

Other languages have their Visual Studios and Netbeans that are fully powered and easy to get up and running.
Clojure has a variety of choices none of which are particularly ideal, especially for someone just getting started having come off something like Nightcoders or LightTable.

I did hear a little while ago that Zach had something even newer than nightcoders.net which sounded like it was aiming to be more fully tooled, batteries included but I only read a couple sentences of description quickly so I may have misread. I plan on checking it out as soon as I can :slight_smile:

I believe you’re referring to Lightmod. Thanks for your feedback on your early Clojure experiences!

1 Like

Ah yes that’s it :slight_smile: It looks cool, I’ll definitely check it out. I think it might be a bit basic compared to what I am looking for but batteries included and everything is a great start and I’d say that might be looking like the best place to start for a beginner at square one.

You’re welcome for the feedback - yeah I just feel the setup of all the tooling to get a dev setup going with Clojure is the biggest impediment to it’s adoption by beginners, it’s certainly what stopped me in my tracks, and that applies from beginner environments all the way through to fully tooled pro dev setups. Most other languages are much easier to get started with a dev setup in comparison. It looks like Zach Oakes is making some good progress with the beginner dev setups but at the more pro end it could still really do with some kind of 'Visual Studio" for Clojure.

1 Like

Thank you for courageously sharing your experiences to kick off this vital, but potentially sensitive topic. I appreciate that you don’t assume your perceptions are 100% accurate but that you are confident enough in them to raise this issue as a possible concern, which I would summarize as: Does elitism exist in Clojure and is it harming our community?

I’ve been thinking a lot lately about the paradox of communication. On the one hand, it’s so easy. Words roll off the tongue, often automatically. On the other, it can be extremely difficult!

We can talk about talking, but it’s a different thing to be there in that moment in time, in that group of people, perceiving the interactions through our own lens, life experiences and goals. All of which differ from those of each member of the group, the group and its network of sub-groups. It’s complicated. We work and interact within schedules and deadlines and people are naturally interested in participating, understanding, and getting their points across.

Compounding the difficulty, in our industry, we often work alone for long stints, coming out of our hermit phases, unpracticed in the finer nuances of communicating gracefully with others.

I’m keenly interested in this topic because I think our community’s success will be directly proportional to how effectively we learn to help newcomers learn Clojure’s unique approaches to problem-solving. If memory serves, according to surveys done by FreeCodeCamp, some 65% of programmers are self-taught. Every individual learner matters, but to exclude such a massive share of the market of minds would be foolish, at best.

But isn’t that easy for me to say, today. I’m not the one who authored Clojure, or who painstakingly supported its growth from its earliest days, doing the long, hard work of caring for the details which have made it as successful as it is today. I didn’t suffer through decades of programming in Java, working around the object impedance mismatch issues of traditional database systems, or developing web applications with pervasive, cyclical object mutation.

Those who did suffer through these stages are naturally more expert in Clojure than I. Relative to me, they are elite in our given field of endeavor. I hang on their every word to refine my mental model of solving problems with Clojure.

Each of them only ever had 24 hours in a day, a portion of which to dedicate to improving the Clojure experience for future Clojurians. Trade-offs had to be made! Should they have marketed Clojure to someone who didn’t know what OOP is, or wait for them to “get it”. How much time in their day did they have to explain rudimentary concepts? Or could they get more traction by focussing on professional developers who can immediately understand the significance of Clojure’s basic value propositions?

After re-reading Eric’s quote above I can see I’ve spent the last two paragraphs emoting the stages of “crossing the chasm”. I’m trying to use that emotion to make a point.

How easy is it for us to throw around the language “elitist” while leaving out a potential host of positive adjectives to describe those selfsame conversations among Clojurians. Are we the elitists, ascribing the worst of attributes to those who simply learned the most efficient path to get us here and took it?

Please don’t read into my point that I’m suggesting we shut down this conversation. On the contrary, I assume your perceptions have an essence of validity, the conscientious exploration of which can improve our outreach.

Moreover, I think this conversation is a positive sign and an indication that we might be ready to cross the chasm by standing on the shoulder’s of giants and polishing the Clojure tooling to make getting started with Clojure mind-blowingly awesome, a no-brainer for the average aspiring programmer. But we have other work to do too. And you’re tapping that vein of gold by airing your inner-most thoughts on fragile ground. And doing so with care.

At a recent Clojure meetup in Raliegh Durham, Stuart Halloway gave a talk about Spec, during which he used his jovial and light-hearted sense of humor to make some comments about deciphering Rich Hickey’s ultra-concise language around Clojure. I thought to myself, “Thank goodness, it’s not just me!” It was an almost gleeful moment of relief, probably because I was imagining in my head Stuart hanging onto every one of Rich’s words like I was his in that moment, and giggling to myself at the universality of the challenge of communication, even between two great minds like Rich and Stu. After all, there’s only so much time in a day and eventually Rich has to get off the phone with Stu and go about his own affairs.

Why was I so gleeful? We invest ourselves so fully into this shared pursuit. I’m no exception. I want to master this craft so badly! I look up to these people. To imagine Stu flailing about like me to expand his understanding was a comic relief and cathartic on a deeply personal level. This is the place from which I’m hearing you say we likely have something to improve on as a community.

In watching a handful of Lambda Island videos, I’ve gained a sense of how thoroughly you approach a subject and a respect for your analytical skills, which is why I look forward to unpacking this problem further, together.

It sounds like my experience (or the perception thereof) has been somewhat different than yours. I’m not formally trained or educated in programming. I’m one of the 65%. I first learned some JavaScript, then Python. I had a prototype for my web app in Python but my code was distorted with ORM concerns to keep the database happy. I didn’t want to be forced to alter my data model to satisfy performance.

My relentless research into the impedance mismatch problem led me to Datomic, upon which I discovered Clojure. I watched Rich’s talk Simple Made Easy and I knew in that moment that I was in the right place with the right people learning the right things. That feeling has never left me.

I’ve felt incredibly welcome and supported at every Clojure event and group I’ve plugged into. From the Google Group to the beginner’s channel on Clojurians Slack, the Clojure user groups to the 2016 Austin Conj, I’ve been blown away by the incredible people I’ve met and their willingness and desire to help me learn. I can’t list everyone here, but experienced developers from Clojure’s inner rank, Russ Olsen, Michael Nygard, Luke Vaderhart, have all invested one-on-one time to mentor me into a better developer.

So much so, that I have caught myself feeling guilty for wasting their time with trivial questions which I would know with a more formal education in our field. To be clear, no one ever did or said anything to make me feel this way, it’s just that I realized the inefficiency I was party to.

In fact, these feelings got me thinking about how to improve that situation. I think we could do a better job of developing, and more importantly, organizing curriculum paths which would spare both mentors and mentees from the distracting minutia, thus freeing both parties to interact around more core fundamentals.

And maybe we need to set aside a time and place for experts to convene, to interact unimpeded by trivial education distractions. Just as we need an outright revolution in education itself. We open source our code. Maybe its time to open source our education, en masse. ClojureBridge is a step in the right direction. I propose we need a sibling effort open to all persons.

In conclusion, I believe the sentiment behind your concerns about elitism is an important catalyst for positive change because we are at a natural stage of community evolution, not that we have an inherent elitism problem preventing our growth. It feels like we are at a critical juncture for moving Clojure into the limelight and I’m ecstatic that you are the people I’m playing that game with. Looking forward to your critiques, rebuttals, and proposals. My best : )

3 Likes

Hi,

Clojure beginner perspective (~1 year). Worked in python, js, coffescript & mysql about 10 years experience, never seen a lisp before and I don’t really like math :slight_smile:

Pretty surprised how good most clojure developers are. And to be honest I really think most are “ellite”.
Clojure isn’t that popular and the number of jobs isn’t that big. So it kinda makes sense that most are experienced developers, that have decided to spend there nights in search of a “better way of crafting software”. Think you have to be pretty crazy as a beginner to not learn Java/python, javascript well (be able to find a decent payed job) and just start with learning clojure.

The thing I find really strange is there’s not really a big focus on “clojurescript” & reactjs. From my perspective clojure (java) is a lot better than python… But still don’t think it adds enough value to justify changing technologies. Python is decent enough, the number of developers that know it is pretty big, just not enough value if there isn’t a strong FP community in your city.

Clojurescript on the other hand, paired together with libs like: fulcro, re-frame. I can really make a case it makes all the sense in the world to ditch javascript and go for it especially you’re already using react-js. If you have the front-end in clojurescript ditching something like python in favor of clojure starts to make a lot more sense (same language, shared code, etc…).

The think I find strange is that I know a lot of people that do react-js and none of them have heard about clojurescript (they heard about elm some even did an app in elm). Not really much buzz about how awesome react-js is with clojure. Egghead.io for example, has everything but the kitchen sync (reactjs, rxjs, purescript, elm, etc…) but no clojurescript.

I was lucky that a colleague played a bit with clojure and suggested it, so I decided to “give this alien looking ugly language 1 month” since I wasn’t happy with the end results of using: react, redux, graphql, immutablejs, python/nodejs.

Clojure is an amazing language, clojurescript tooling & libs are really impressive.
But marketing & outreach to javascript developers, it’s really not that great… or at least that was/is my experience :slight_smile:

3 Likes

Hey @claudiu,

Thanks for sharing your experience. Sometimes it’s hard for us who live in the ecosystem to know how it’s perceived.

I think you’re right that ClojureScript is not as well-known as some other languages, though it is really mature. I gave a ClojureScript talk at a local JavaScript conference and when I listed all of the features, they were very much like “we have that with webpack”. Live reloading, for instance. But then when I dug deep, it turned out that they had it sometimes, after two weeks of trying. How do you market that? Because sometimes we feel like webpack is stealing from us (and the stealing is welcomed), but then doing it badly and giving the feature a bad rap. Same goes for React. And Redux. And Immutable. We need better marketing, for sure.

Giving me some ideas. I’m not that great at online community building or social media. But it does seem like some effort in that direction would be useful.

Rock on!
Eric

2 Likes

@ericnormand

Static typists believe that untyped programs are a subset of typed programs […] dynamic typists see typed programs as a subset of dynamic.

This is a super salient observation!

But, IMO, therein lies the value-add of dynamic languages: You can always impose static strictness on a dynamic system - the other way, not necessarily so easy.

Might any sufficiently complicated set of Haskell or Idris type definitions contain an ad-hoc, under-specified, bug-ridden, slow verification of half of Clojure’s semantics? :joy:

1 Like

But, IMO, therein lies the value-add of dynamic languages: You can always impose static strictness on a dynamic system - the other way, not necessarily so easy.

That’s right. But everything is parallel. They can make types as loose as they want, e.g., use Strings for everything.

Dynamic: Loose now —> Strict later
Static: Strict now —> Loose later

Where later usually means never.

It sometimes feels that way :slight_smile:

Eric

1 Like

Dynamic: Loose now —> Strict later
Static: Strict now —> Loose later

Is not strict-to-loose inherently more difficult than loose-to-strict? Perhaps not inherently. Though I can’t imagine how more constraints could increase the expressiveness… Could be my failure of imagination.

But your observation brings up some other question for me:

Is not the base type of everything a 1 or a 0?

Then we have higher composed types like words, ints, longs, etc.

And whether we call them statically typed or not, aren’t all modern languages statically typed in this way? Where the base byte formats are all marshaled, checked and managed by the language, often at compile time?

In that sense, untyped programs would be a subset of typed programs, in the sense of byte-layouts being managed.

Wouldn’t it be unfortunate if, in our high level languages, we still had to always handle marshaling data between byte formats manually?

So it would seem that formal type definitions are extremely useful when a problem domain is well specified / defined, especially when you want to build a rigorous model that can abstract over those minutia internal to that domain, like byte-layouts. In other words, strict typing seems to allow for the creation of more generic, loose abstractions.

If that were true, then it would seem zealotry on the strict typing side would be missing the forest for the trees - types should allow us to abstract over the semantics of the objects they define, not to be imposed on the rest of the universe.

Do those intuitions ring true to you or do you think I’m off base?

I my experience, strict to loose is easier. You can always make types that encode something without the benefits of type safety. For instance, you can encode stuff in Strings without type safety.

Loose to strict, however, requires you to write a type checker. Not a gargantuan task, but not trivial either.

I think that’s what they try to do in the best cases. They’re building abstractions on top of abstractions, usually for stuff that are discovered in mathematics. That would be where category theory enters the conversation.

They will acknowledge that static types have a cost. But they perceive the benefit to be much greater. They’re willing to appease the pedantic type checking for the benefits of reasoning at a higher level of abstraction.

Eric

It wasn’t so much that Evan Borden succeeded in the details—it was the shift in perspective (“what would Clojure typing look like in Haskell”) that was interesting and new (to me).

Taking that a step further, it is interesting to think about what happens with interoperability between languages/type systems. Re-watching Wadler’s Propositions as Types led me to his blame calculus paper (with Findler): Well-typed programs can’t be blamed.

In that paper, if I may butcher the terminology, they develop a hybrid language with untyped exprs and typed exprs bridged with casts. They introduce a “blame” concept that captures two kinds of error that can occur at a cast. They then, I think, go on to show how such a language can be pretty good. (I say “I think” because the notation gets pretty dense in the body of the paper, so I have to admit to very skimming those bits.)

They conclude with:

Can we promote the evolution of programming languages by
some mechanism other than ‘survival of the fittest’? Integrating two
competing designs into a single language may provide a better basis
for comparing the strengths and weaknesses of each

(my emphasis)

The model in the Wadler-Findler paper is contract-based. Contracts à la Eiffel and specs à la Clojure are strongly connected of course. It makes me wonder:

  • what is the real relationship between specs and types?
  • could we use specs to support the vaunted IDE refactorings so many of us seem to care so much about?
  • is there something to be learned by exploring the use of specs at the FFI between e.g. Clojure and Eta or ClojureScript and TypeScript—in particular would that exploration lead us to a better “understanding” between the Clojure community and the static typing communities?
2 Likes