Lambda the Ultimate

Thanks for your answer.

I'm fond of pl-enthusiast, but I don't see it as a place where discussion happens. (Even less so accepted paper lists.) I don't know where "the POPL crowd" would discuss online, feel free to share pointers if you have some.

I'm understanding my own view as I go, but I think one important point is the following: an important difference is on the form, rather than the content, of the discussions.

Discussing from a paper is good because papers are damn hard to write, and they present ideas in a form that is in most cases well above the usual two-participant dialogue in an obscure subthread. This tends to be true no matter what the paper is about. When you say that the "PL academic community" is conservative, well I guess it is conservative on both the form and the content, but the variable I would like to tweak foremost is the form here. LMereyov's work on adoption of programming language was well outside the conservative area of *content* (you could even say it was ground-breaking), but its *form* made it a formidable point to start or enrich a discussion.

Of course a paper is damn hard to write and we should not require this sacrifice as the basis to any discussion. The next best thing is a good blog post. I've thoroughly enjoyed blog posts by dmbarbour or John Shutt that I'm sure you wouldn't categorize as mainstream academia "gone commercial" content.

So I don't think my criticism comes from the difference in focus between POPL and LtU. (Of course I would also be interested in discussing POPL papers.)

I think the front page articles should be reserved for discussions around published papers, and such recent developments. However I would like to keep the discussions open, as I for one do not get paid to write papers, and my interest in doing so is minimal. I am more interested in developing practical implementations (like the C++ parser combinator library that started from an LtU discussion).

I am also interested in getting community feedback on things I am working on, good or bad (I guess I learn more from bad). I understand why you might want to focus on more well defined ideas, but that rather excludes those of us that do not have direct colleagues who are also interested in programming languages. For me, without LtU I would be back to emailing a few willing collaborators directly.

I tend to use published code on GitHub as the basis of any post I start, or it is a question where I want to get input from the community.

What is this front page you talk about? Is it like reddit or hacker news where the submissions are sufficiently crowd sourced to the top?

Discussions are good, but we are all kind of lone wolfs with very diverse interests. This is why they often devolve to a couple of participants.

Some things get published on the home page, others are forum discussions. My understanding was the 'home' page was reserved for topics relating to published work (papers and blog posts), but the discussion forums were more open.

I will also gladly take one other person being interested in the same topic than complete isolation. Most people I talk to about type systems (even good programers) I can see their eyes glazing over after a few minutes. On the other hand I realise I know very little compared to some people here.

I doubt many people even see the LtU via its front page, an antiquated concept that is too static to be useful. Compare with hackernews' front page, which I find very useful since it changes often and is heavily crowd sourced.

I understand why you might want to focus on more well defined ideas, but that rather excludes those of us that do not have direct colleagues who are also interested in programming languages.

I'd like to insist that I don't think exclusion would be a good thing. We should have more of the other stuff, not less of what we have.

And implementation-centered discussions have also been interesting, I enjoyed the discussion of your work on templatey parsing library. Talking concrete implementation is certainly also a way to keep discussion focused, and I should have mentioned that along with papers and blog posts.

I wouldn't mind having less of what we're having lately.

I don't think your criticisms come from a focus between LtU and POPL, it is just that I'm going in directions where the conversations don't exist and it's quite lonely.

There are plenty of places where things are discussed, just maybe not online...the Internet is a new fangled medium. You interact with it by reading and writing POPL or PLDI or ICFP papers (and if sufficiently depraved, OOPSLA and ECOOP, or if nutters Onward). If you are lucky (or maybe unlucky), you get invited onto a PC, and get to start discussing things by playing the "game of thrones."

What you are fishing for is just something more timely, but again, this interweb thingy is too new, and it will take a while to support it. They just decided to make papers available via open access, "open debate" is still not done yet, and anyways, runs counter to the communities' goals of high brow discussions with very select participants. The community is a conversation, but you should only listen unless spoken to.

Frankly I'm more interested in listening to what non academics have to say, since it feels much more grounded to me anyways. I often absorb academic work via another's nonnacademic interpretation, or at least get an idea of why I should read something, since even with the community's high conservative standards, there is still way too much noise vs. signal.

Trying to communicate about LtU in some other places may also help (more so, I suspect, than internal social engineering changes).

PS: I would be happy to gather feedback on what makes a paper a good fit for LtU submission nowadays. I try submitting some papers, it's very hard to decide (and quite enriching as well; maybe my standards are too high but I try to submit papers I understand and appreciate). I like doing this, and I think it is useful, but my submissions haven't been very successful at fostering discussion so far.

Perhaps outreach would help, and perhaps also investigating why those in the PL field who do know about LtU do not participate in discussions. I wouldn't be surprised if it's a chicken and egg problem: people may be discouraged by the proportion of non technical discussion.

I like your submissions a lot. How about opening an ongoing forum topic where people post papers in the comments so that there is a much lower barrier than the front page? (this could also work as a staging ground for the front page, and increase the number of papers posted there)

Odd. Right up to the last word of your sentence, that wasn't the name I expected to see.

I love LtU super dearly, so I'd of course rather shut up than be a root cause of it going south.

This is just another example of the kind of post that's ruining LtU. (I will acknowledge that I was joking only after you acknowledge that you already knew that)

You can see a maturation of LtU participants over time. It is a good place to grow and "be wrong."

i know lots of people see me as 'one of those assh*les online' so i see critiques as un-sarcastic.

I wouldn't call you an asshole. Shifty-eyed, maybe. I still want to know who John Shutt thinks we should ban.

Hey, I didn't say we should, I just said I'd had a guess who might be named.

After reading Clay Shirky's A Group Is Its Own Worst Enemy -- which I assume most folks have -- it seems clear healthy groups have some form of negative feedback built-in to prune destructive (to the group) influences. So hostility of some kind seems required as part of the package, toward things off the charter. And the folks running things have the right to set and evolve the charter.

I just accept it. Ideal things don't exist. A pragmatic approach works. I prefer a limited LtU that stays around to a better one that blows up. I'm mainly interested in practical implementation issues, but I accept this is only marginally on topic most of the time on LtU, because it's hard to stop folks from discussing progressively more trivial things, which sounds like a recipe for chaos. Implementation can be discussed abstractly, but most people seem to think pretty concretely, and there's an easy slippery slope to triviality.

Suppose you want to talk about finalization. Do object destructors always run? What happens when you have lightweight processes that get killed, and running code in them must end as soon as killed. In what scope do finalizers run? Unless you think carefully about it, you can easily work yourself into a quandary best solved in up-front design, because resolving it incrementally might not work -- what if fundamental definitions contradict each other? What kind of math describes finalization? In the end, I think you want to redefine what is meant by destruction, if it will otherwise contradict process definitions.

That's fairly abstract, which makes it somewhat interesting. But it's easy to see any discussion devolving into concrete detail bordering on drivel. I don't want whether destructors run to depend on whether fibers are still alive, so I don't want destructors, just resource release that's guaranteed, which amounts to one way notification handled by contexts that are still alive. But this makes the definition of what happens when refcount hits zero sound pretty weird to folks familiar with all code running in one global context.

Even a description as short as that is something folks want to appear somewhere else, in a paper or blog, because that requires a higher activation threshold, acting as a brake on continuous noise generation.

the good kind is the kind that is done by people who are always looking to find the ah-hah better abstraction in the morass. We have to go through heck of details and drivel and dead-ends and duh!s often before we can get to the real zinger that lets us throw away a ton of code and bugs for a much simpler approach.

I found instead a site that seems to be very hostile to most people that are not academics, and to those who are interested in any "non-functional" or practical language issues.

A general problem with many academic communities. The hostility is much worse if you try to work from within the community.

I am just saying that more non-Math PL discussions (rather than only) would make for a larger audience. It is possible that non academics (like me) can learn a thing or two from the academics and also the reverse.

PL used to include a lot of trail blazing non-academics, but they've been retiring lately to be replaced by a younger crowd of more traditional academics. So there are some big questions in the community right now about what we are becoming (mature? old? mid-life crisis?)

Quora and Stack Exchange are good sources of non-academic PL information. Hackernews also.

I read many sources, including some Reddit blogs and Hackernews. In the end, the rules (official and unofficial) for Ltu belong to you all collectively. It probably would be better to describe your blog as "Academic Paper Study" rather than "Programming Languages", however. I will continue to check out your posts from time to time, as I wouldn't want to miss any nuggets.

It is quite funny that 2 of the most interesting posters (Rys and Sean) for my interests, would be 2 of the 3 to reply to my post. I am not so sure that the "younger academics" are doing so well in programming languages. It seems to me that most of the languages used today were either made many years ago like C, C++, C#, Java, D, PHP, Ruby, Javascript etc and/or by non-academics. I don't want to get into a pissing contest but long experience with real world problems on hundreds of real projects should be a prerequisite for PL design and no matter how smart the "younger crowd" may be, you can't get experience and wisdom from a book or paper. It has to be earned the hard way.

There are different battles going on that can't really be grokked from the outside. It is not so much about experience (though that is definitely useful!) as it is about maturity. There are two schools of thought about what "PL research" is and should be.

First, there is the current orthodoxy that PL is a mature field that should be studied more scientifically, hence the papers with all the math in them (and soon to come...empirical studies). This point of view has been productive in getting funding, so it has begun to dominate our collective output and is more popular with younger researchers (because getting a job and not starving is useful in surviving natural selection).

Second, there is a view that PL is still a wide open field open to wild experimentation. When PL was new, this dominated of course (there was no orthodoxy to fight with), hence the cultural change as the next generation takes over. None of that should be surprising: as our languages get better, it is hard to "see" how things could be better and we just wind up with a lot more incremental academic papers. Those who somehow wind up in this camp anew are often called crackpots (since everything in PL has already been invented....they must be the crazies!).

There is a actually a third more pragmatic view that you are hinting at that is more in line with what the systems community is doing. It is actually in between the two positions: PL is mature, but let's just focus on building and improving things without getting bogged down in the bike shedding. This has led to MapReduce, Spark, and so on... Since they aren't building OS's anymore, the systems community sees it more as their responsibility to "design programming abstractions to access computational resources" which is very...erm...similar to doing PL.

Second, there is a view that PL is still a wide open field open to wild experimentation.

I can see the merits of both perspectives. Clarkd originally stated that PHP and JavaScript were recipients of much "scorn" here on LtU, but I don't think that PHP falls into either school of PL research you listed. Does this mean PHP deserved the scorn?

I think criticism is too readily perceived as hostility, which is unfortunate because they're not the same thing. Hostility has no place, but heavy criticism ought to be encouraged IMO.

I don't think I've ever seen anyone seriously state on LtU that language designers ought to have "consulted PL specialists". I've many times seen the sentiment that language designers ought to have done more research into the problem being solved, which I think is pretty reasonable complaint when solving any problem.

Who wouldn't complain about a matrix library written by a novice to the field and providing naive, sub-optimal matrix algorithms, but presented as a serious library for numerical computations? Is such a criticism really so unreasonable? It seems PLs alone are somehow sacrosanct from such criticism.

I tried to present a balanced perspective and I think there is room for both. But try convincing the conservatives of that...accusations that "you aren't a real scientists" are thrown around a lot. There is also a matter of interest overlap: I find group A papers to not be very interesting (for me to read, of course) since I'm so far out in left field already. You don't want to read about practical airplanes when you are trying to figure out how to build a starship! (incidentally, the former are much more practical than the latter, which is almost science fiction, maybe I'm a science fictionist?)

as for the other problem...we design many languages at Microsoft...but outside of devdiv or research, they are usually done by domain experts without the benefit of specific PL design input. The domain experts don't feel like we have much to offer, but this is true in other supporting domains also (e.g. systems).

Put it another way. Bill Buxton is famous for saying that "because we choose our own clothes in the morning, we all think we are (fashion) designers." Likewise, since we (as programmers) all program, we all feel like we are qualified to design the programming languages we need. In some ways they are right, the languages aren't great, but they get the job done (e.g. PHP).

I agree with you that "just because you have programmed for many years", doesn't qualify you as a PL designer. It also doesn't disqualify you either. In the late 1980's, I created a language/database program that sold over 30,000 copies and at a trade show more than a few people told me how obvious is was that I actually used the language I had created. When languages are created by committee or where the language designer doesn't actually code the language himself or where the features come from web posts rather than experience, it is patently obvious.

Instead of using myself as an example, I would point you to a set of videos on YouTube by an "indie" game developer named Jonathan Blow. He has decided to create a PL to write his games in and he has at least 30 hours of video of him designing, debugging and programming his language compiler in real time. You might call him an amateur PL designer but he has decades of experience in his area and he has made many starts at languages in the past. Within 2 months of him starting his project, he had space invaders running in a byte code interpreter inside his compiler while it compiled. His goal for this language is to produce faster compiled code than C++ with less "friction" and with more and better PL features that are particularly needed by top rank game designers.

One last comment before your collective patience wears out. A few years ago I got some comments about my proposed security system from dmbarbour. I thought they were quite harsh at the time but he hinted at using a "capability security model" instead of what I was proposing. The system I am creating lives on the Web so security is especially important. I read at least 100 academic papers and web site articles about security systems (even though I thought I knew quite a lot about security systems) over the next few weeks and my hybrid security system has this "capability model" at it's core. Much credit to dmbarbour. Thanks.

Interestingly, the "capability security model" that you (rightly) found so interesting has been kept alive precisely by researchers and hobbyists (people like shap, Mark Miller, dmbarbour), while the developer crowd with decades of experience programming systems with security requirements had in overwhelming majority moved on to access-control techniques.

Thanks for your respective, it's interesting to get inputs that reflect the diversity of the LtU demographics. I think you are mistaken about the "hostile towards non-academics idea" (people privately told me that they found today's LtU "hostile towards academia", and I think you are both wrong in the sense that the reality is much more nuanced). On the other hand I did like the second paragraph of your first post in this thread ("... isn't it too bad that experienced PL specialists weren't consulted ..."), and I think your perception is rather accurate.

I like the idea of having discussion of implementation techniques. raould already stepped up to propose that, and I'll try to find inspiration for submissions in that direction.

It's long seemed to me the act of programming is the same act as that of language design. A programmer creates a language, by modifying the one given to them. Programming language designs go awry when their designers fail to sufficiently appreciate this. What programmers will do with your language later is of the same essence as what you are doing in designing it. The dynamic this sets up beteween original language designer and programmer is incredibly subtle; you don't want too restrictive a language, you don't want a shapeless language (or we'd all be writing in assembly language), but just avoiding those extremes isn't even a start on what you do want. You need a deep sense of how the character of your language will propagate, and perhaps mutate, through a growing codebase written in it. Using it yourself is part of that, certainly. There's a whole realm of insights you miss if you're not in the trenches, and another whole realm of insights that require a vantage elevated above the trenches.

[edit: start of first sentence read so poorly to me, I adjusted it]

What is unique is that a programming language is essentially a conceptual framework for thinking about and understanding problem domains and thus you get this virtuous cycle of feedback where improvements to your language

This was exactly my thought on reading John's comment. Programming languages are not quite like other problems, which tend to be strictly restricted in scope, they are largely general purpose tools with very broad scopes. The expertise required to achieve a good result is high.

Whether this expertise is achieved by studying academic literature, or by lots of individual trial and error is theoretically irrelevant. In practice it is relevant though, because other people adopting your language practically inscribes any fundamental mistakes into the bedrock of society.

Thoroughly studying background first is thus a more responsible choice IMO. Choosing the alternate route is fine too, but it should be done with the understanding that you're much more open to criticism and scrutiny as a result. I don't think that's unreasonable.

The problem is that the academic literature is mostly retrospective with little interest in actually improving programmer experiences. Why go down path B when we went down path A in the 70s and have since studied it to death? PL is surprisingly a conservative field.

The design space for PL is so incredibly broad that we have just explored only a very tiny bit of it. But we seem to be stuck in those limited spaces we have explored since, well, as you said, we made so many mistakes in the past that we are deathly afraid of making new ones. Yet most new successful PLs are made by those who don't have that fear (and yes, mistakes are made!). Getting criticized by a navel gazing PL community is quite irrelevant.

In other words, new languages are only designed by those who are too dumb to realize that "you shouldn't design a new language." And there are many more mistakes to be made if we want to make any real progress.

The problem is that the academic literature is mostly retrospective with little interest in actually improving programmer experiences.

I think most work in type systems is exactly focused on improving programmer experiences, just not the kind of experience your work suggests you're interested in. And that's fine, but I don't think its unreasonable that forging your own path comes with increased risk of criticism. It seems like that's exactly as it should be.

In other words, new languages are only designed by those who are too dumb to realize that "you shouldn't design a new language."

I don't think anyone in PL would say you shouldn't design a new language. There is great utility in designing languages to increase expertise and explore new ideas.

But that's not the same as immediately marketing your project as a good general purpose language that others should start using until you have some idea whether you really have something. If you build on literature, it's pretty easy to know if you have something because you can point to non-trivial improvements in expressiveness, or the elimination of certain classes of errors.

Forging your own path has the potential for non-incremental increases in productivity, but with a decreased likelihood of making a real, global improvement. Shouldn't the standard of evidence for claims of improvement be subsequently higher in this case? And yet, the complete opposite seems to be the case, and when such seemingly appropriate criticism is given, it's perceived as "harsh".

I don't think anyone in PL would say you shouldn't design a new language. There is great utility in designing languages to increase expertise and explore new ideas.

This is actually super common, it is advise I got as a grad student from a famous PL researcher who I probably shouldn't name.

But that's not the same as immediately marketing your project as a good general purpose language that others should start using until you have some idea whether you really have something.

But we've never done that, heck, I'm not even comfortable releasing any of my demos yet (but..that will change soon hopefully). I'm frustrated instead that certain researchers call me "not a real scientist" even after my talks get good reviews. That is harsh, but maybe true. I'm not practicing science, PL design is not a science.

Forging your own path has the potential for non-incremental increases in productivity, but with a decreased likelihood of making a real, global improvement. Shouldn't the standard of evidence for claims of improvement be subsequently higher in this case? And yet, the complete opposite seems to be the case, and when such seemingly appropriate criticism is given, it's perceived as "harsh".

Seeing as no one has really figured out how to measure productivity of holistic PL experiences empirically in any way at all, it does seem to be harsh standard that just shuts down the conversation. We are instead expected to pretend validate our designs with irrelevant proofs or benchmarks for the sake of scientific appearance. Critique is fine, that is what you are supposed to actually do in a design field. But we don't even get there. PL conferences are just boring to me as a result...with just a lot of pointless formalism.

I'm frustrated instead that certain researchers call me "not a real scientist" even after my talks get good reviews. That is harsh, but maybe true. I'm not practicing science, PL design is not a science.

This is something that my advisor warned me about quite early when we working together: design work is hard to evaluate and get recognized. I am not sure that makes exploring specific directions harder than others as you claim, but it certainly pushes people to tone down certain form of presentation of their work. Working to improve that is a laudable goal (Functional Pearl come from a bit of this idea, I believe), but is indeed hard because of inertia.

My personal standards would require that, when you present a new programming language, you give a precise semantics of what its programs are and do. (And if you design a program analysis on top of this, I would expect to see a proof that the analysis really checks for the situations it says, by relating the precise semantics of programs and the results of the analysis.)

I think this is an idea that has indeed grown from a certain vision of PL theory, but I don't see it as forcing you to take any given path and barring the others. I understand it more as a methodology to validate the choice you made along the path you took.

(There is a subtlety here, which is that indeed having nice ideas and providing a formal semantics for them is harder than just having the nice ideas in the first place. There are situations where publishing the ideas without the semantics first, and being precise only later, is the best thing to do for the overall advance of those ideas, because formalizing them is just too hard (type polymorphism was one such examples, Reynolds held off publication of his language design because he was unable to prove strong normalization.) There is still an important difference between saying "we haven't managed to formalize this yet because of this and this problem, here is the idea" and not trying in the first place.)

If you yourself have little interest in doing formalization work, have you considered pairing with someone that would be motivated to bring that perspective to your work?

I'm not against formalization, but I currently have no ideas on how to do that with Glitch, nor is there much work on formalizing eventually consistent systems based on replay rather than something more determinstic (like say memoization). If formalization was an initial goal...you wouldn't dare come up with something like glitch! Anyways, it has to work in practice before it works in theory.

Formalization of the type system work is much more feasible and necessary, though I'm not entirely there yet (I know the rules now, but have little intuition for why they work yet, and I'm still trying to figure out how to do proofs on statement traces rather than with syntactic reduction). Typically, things become more clearer as you work on it and talk about it... And now this is the big question: do you hold off publishing your design until all the science is done, or do you talk about it earlier. If the community is a conversation, what should we be talking about and when should we talk about it?

Frankly, my goal isn't to publish papers, I just find it to be useful to write down what I'm working on once a year and get some peer review, and maybe give a talk or something. But ultimately, I want my system to really work and it's what I spend all my time on. If someone was interested enough in the theory, I definitely wouldn't mind, I don't claim turf, but why would they bother with an untested crazy PL idea? And if you are going to do theory, it makes more sense to work off more mature models where the formalisms are more well understood, you want to build off of Igarashi, cardelli, wright. So work on things that fit into the theory you know and have invested in.

I don't see formalization as a way to increment your publication count, but as a way to have a better understanding of what you do, see simplifications that you didn't see before (case in point, the work on KScript/KSWorld), and maybe most importantly to describe your ideas in a way that can be effectively communicated to others, with lowered risk of misunderstanding.

If someone was interested enough in the theory, I definitely wouldn't mind, I don't claim turf, but why would they bother with an untested crazy PL idea?

One way to approach this is to hire a student/intern/postdoc. As to "why?", well, what convinced you that this was an important problem to work on in the first place? If this an important problem, the usefulness of working on it should be visible. (Of course such a proposal could still be perceived as less attractive than others because of the imagined or real risk of being isolated while on the job. On the other hand, maybe some people are attracted in China and that would be a plus for them.)

And if you are going to do theory, it makes more sense to work off more mature models where the formalisms are more well understood, you want to build off of Igarashi, cardelli, wright. So work on things that fit into the theory you know and have invested in.

I don't see things this way. I'd rather pick a problem I care about, and then decide on the tools that seem appropriate to solve it. If one is comfortable with advanced theories in one domain, translation into said domain may be profitable.

Ksscript/KsWorld are not formalized in the work you link to, it seems instead to be one of borning's constraint language.

Yes, of course. Formalization should lead to some interesting insights about the system, they might even be seen as "good starting" points. But it is far from the only way to move a system forward, and most formalization are done after the fact anyways (related to the high overhead in doing them, so they are applied to what works in practice), they don't immediately inform design (well, they have influence on the design of the next system).

I don't see things this way. I'd rather pick a problem I care about, and then decide on the tools that seem appropriate to solve it. If one is comfortable with advanced theories in one domain, translation into said domain may be profitable.

The learning curve on any formal framework is huge, which necessarily leads to bias in the problems you whack with your hammer of sunk costs. Maybe you are different, but I bet if you look at your work objectively, you'll find a bias to leveraging your investments over time. And there are plenty of interesting problems with what you know, so why venture outside of that box?

... and much in the same way formalism follows understanding; it does not precede it. Formalism helps you catch problems; it exposes your lack of understanding. It is, however, not a substitute for understanding.

The major difficulty for formalization is you need some kind of foundation to build on. In my experience if you have the right foundation then formalization is fairly easy which generally means the right foundation doesn't exist (because otherwise it would be easy enough that if the problem is truly interesting then someone would have solved it already) so you end up dealing with a lot of foundational issues which is definitely not everyone's cup of tea.

I think of formalisation and (intuitive) understanding as members of a virtuous circle (along with manual experiments, prototype implementations, case studies, etc.).

But I like the slogan that simplicity follows complexity; you could also say that elegant formalisations follow tedious ones, that clear implementations follow good formalisations (or tedious implementations and a good eye for design elegance... or both), etc.

"Simplicity does not precede complexity, but follows it." just in case someone didn't know the reference.

It is more like back-in-forth, but the formalization have to contribute to understanding or they'll get optimized out of the feedback loop (unless they are necessary for publishing). This is what is missing from most papers: what is the pay off in understanding formalization X, and could they make that pay off more explicit? 80% of the papers with formalization out there seem to be just going through the motions where the formalisms are merely details that provide no enlightenment. I hope everyone can "keep it real."

As for simplicity follows complexity...ya, this is true throughout programming and probably anything technology related; e.g. the code is not overengineered to handle future requirements, it is overengineered to handle existing fuzzy requirements.

This is actually super common, it is advise I got as a grad student from a famous PL researcher who I probably shouldn't name.

This lacks context. If your goals were achievable during the span of your grad work and they could only be achieved by designing a new PL, then that's a perfectly valid way to go. If neither of those conditions were met, then the advice you received sounds perfectly valid for grad work.

Re: "we've never done that", I'm not sure to whom you're referring. I think any language that publishes a nice website and articles on reddit for beginners is doing exactly what I said: marketing their language. Quite a few language designers have done this, and we have a glut of such languages, most of which are largely the same and differentiated in only minor ways. If that's the "we" to whom you're referring, I don't see how your claim could be true.

Seeing as no one has really figured out how to measure productivity of holistic PL experiences empirically in any way at all, it does seem to be harsh standard that just shuts down the conversation.

Would you agree that we know of some metrics, like expressiveness? Would you agree that we have at least some empirical evidence of the benefits conferred by static typing, at least for large projects?

Given these two premises, it seems reasonable to conclude that modest improvements in expressiveness and modest increases to the set of valid programs that can be typed (without decreasing the "strength" of those types) would entail that people can more naturally express their programs without fighting limitations that previously existed. That seems a pretty conservative argument for "increased productivity". Perhaps the gains are modest, but the assumptions are modest as well.

Entirely new approaches have the potential to find entirely new productivity maxima, but they need entirely new evidence to justify such claims, and can't build on familiar norms.

This lacks context. If your goals were achievable during the span of your grad work and they could only be achieved by designing a new PL, then that's a perfectly valid way to go. If neither of those conditions were met, then the advice you received sounds perfectly valid for grad work.

It does lack context. Of course. Speaking generally — As has been marked around here somewhere recently, a lot of really good advice to grad students consists of telling them to do less. There's also another side to it, though. In the late 1980s there was some perception (I know because I encountered it) that abstraction, my particular interest, was a solved problem, as it was known that the answer is OOP. I later noted, in literature search for my dissertation, that after the height of OOP's popularity in the 1980s, openly criticizing OOP seems to have become socially acceptable around 1990 plus or minus. There's the (apocryphal?) story of the prominent physicist (usually Lord Kelvin) who in the late nineteenth century was advising bright young men not to go into physics because there was nothing left to discover except measuring the physical constants to more decimal places. It seems like that sort of brittle attitude foreshadows that something is about to change radically.

It is not like this view is held OUTSIDE of the PL community (plenty of people are designing new languages), it is just that the PL community is ironically more anti-new-PL.

Lord Kelvin actually said:

There is nothing new to be discovered in physics now, All that remains is more and more precise measurement.

And a lot of other things like "heavier than air flight is impossible," he was the reactionary scientist of his times.

But that's kind of the point. Clearly bright youngsters didn't avoid physics. Nor did I abandon abstraction; though I did, in fairness, switch schools and do a master's thesis on a seemingly different topic.

(From what I gather, Michelson said an 'eminent physicist' said that, and people figure he was talking about Kelvin because, well, most likely candidate around. Wonderfully reactionary.)

Some people are just too stubborn to give into the orthodoxy...especially kids who don't know better, who are more likely to win Nobel Prizes as a result. The problem is, that such people are just as likely to be crackpots, especially if they are way outside the orthodoxy, so it is quite easy to call them as such even if they aren't.

Kelvin was just being efficient with what he believed the world to be like. Most of us are limited by our world views.

The problem is, that such people are just as likely to be crackpots, especially if they are way outside the orthodoxy, so it is quite easy to call them as such even if they aren't.

There are a variety of was to look more crackpotted that you are. I've been wanting to write a blog post about that for some time, but it turns out to be really hard to explain well.

Let's not underplay Kelvin's reactionism. As something of a quaternionist at heart, I would be more resentful of his remark on quaternions,

Quaternions came from Hamilton after his really good work had been done, and though beautifully ingenious, have been an unmixed evil to those who have touched them in any way.

if he hadn't also said

Symmetrical equations are good in their place, but 'vector' is a useless survival, or offshoot from quaternions, and has never been of the slightest use to any creature.

Fun, being opposed to both sides of the 1890s vectors/quaternions debate. :p

The context was pretty general. I got the feeling that "there were too many innovative languages already" and that "your ideas are probably not original."

"We've" meaning "me" (or my company who decides ultimately whether or not I can release my stuff) :) I've been holding back on putting out prototypes just for the reasons you state, and its hurting me in the sense that people begin to wonder if my work is actually real or not.

Would you agree that we know of some metrics, like expressiveness? Would you agree that we have at least some empirical evidence of the benefits conferred by static typing, at least for large projects?

Stefan Hanenberg is able to evaluate PL features in isolation, but this does not necessarily scale to entire languages (at least, we don't know how to do that yet). Expressiveness is a metric as fuzzy as productivity.

Given these two premises, it seems reasonable to conclude that modest improvements in expressiveness and modest increases to the set of valid programs that can be typed (without decreasing the "strength" of those types) would entail that people can more naturally express their programs without fighting limitations that previously existed.

See, we are in completely different worlds at this point. So my work includes a development environment. The type system is designed to support that environment vs. the other way around where the environment magically appears after the type system is designed. And in fact, if you compare Type-less to say Scala, it is much less expressive: it is just subtyping + type parameters, which allows aggressive type inference that then feeds into the code completion system (that can also drive type formation). My goal isn't to build a more powerful type system that can "accept" more programmers; god forbid we have plenty of those and none of them are easy to use! Scala exists, we don't need another Scala. My goal is to build a better programmer experience.

Type systems research today seems to be all about "more power and expressive" to the point that typical programmers have no chance of using! If your type system requires a PhD in type theory to even understand, how is that going to lead to better programming languages? And then the research is biased to those structural type systems that can easily be studied formally even though the type systems in use are mostly nominal. The community's solution to that problem? Developers should become enlightened to use more mathy structural type systems! This is like saying "eat your vegetables, they are good for you."

But then again, much of the contemporary type systems work has evolved beyond programming, it is a topic in its own right these days that applies more to proof assistants than Joe Schmoe programmer.

Entirely new approaches have the potential to find entirely new productivity maxima, but they need entirely new evidence to justify such claims, and can't build on familiar norms.

And that evidence is typically called acceptance in the market. But really, look at past "weird" PL systems that were successful in academia...like Self. What was the evidence used to judge them at the time?

I've been holding back on putting out prototypes just for the reasons you state, and its hurting me in the sense that people begin to wonder if my work is actually real or not.

That's certainly not the intent behind what I said! I think prototypes are essential, as long as they're labelled as experimental. Of course, first impressions are also important, so perhaps that's making you gun shy?

And that evidence is typically called acceptance in the market.

I'd believe that if technical superiority had any correlation with acceptance by the market. Instead, marketing is correlated with acceptance by the market. Marketing wouldn't be so highly valued if it didn't actually work!

Well now you have. They should. Unfortunately, there's no free place to do so, and no reasonable obligation on the PL specialists to work for free.

Ross Tate has been doing great work with the kotlin and Ceylon designers.

Glad to hear from you, you are one of the people that makes LtU enjoyable to me! Good to know that you are doing well.

It's always good to ask "who is benefiting from further posts to this thread?" before posting. I don't ask myself enough :). Good to know you're still (at least) lurking.

please. seriously.