What makes LtU more or less enjoyable?

What makes LtU more or less enjoyable?

These last few months I have been a bit frustrated by my own relation to LtU; I wondered on a few occasions whether I should stop visiting the website frequently, and I eventually sort of decided not to. It is not easy to voice exactly what the problem is, even less easy to know what a solution could be.

I would say the observed symptom of the problem is simple: the proportion of LtU's discussion that I feel strongly interested in is decreasing. What about you?

I think decrease in interest for LtU wouldn't be a frustrating problem if there was another place to supersede it. Unfortunately, I know of no such place: the alternative that is developping right now is a balkanization in a multitude of places, many of which are closed gardens (eg. Quora) I don't wish to help grow prosperous.

(It's of course to be expected that not all LtU discussions interest everyone, as the topic is quite broad and people have different tastes about different subdomains.)

Why am I less interested in LtU discussions? I think there has been at times a better balance between technical discussion around articles (articles mostly following the standards of academic presentation) and less-focused discussion, possibly more radical but less precise viewpoints.

I don't think there are more less-focused / off-original-topic discussion than before, or too much of them, but rather that there not enough of the more structured technical comments. In particular, I mean no criticism of the current LtU members or discussions, which bring many interesting point of views -- there might be things to improve in this area, but I don't think that is where the real gains are. I would be more interested in attracting more "research discussions" but I don't know how to do it.

On the positive sides, here are three examples of interactions that I personally enjoyed a lot recently, and would by themselves justify my continued LtU activity this year:

  • Tom Primožič linked the draft version of Andreas Rossberg "amazing" 1ML paper; without this link, I probably wouldn't have learned about this exciting work for a few months.
  • Sean McDirmid posted article versions of his work on type inference (and previously, Glitch), that helped make more precise interesting discussions that had been going on and off on LtU for a long time.
  • Robert Atkey saw an on-the-side remark inside the LtU submission on the very interesting work on incremental computation, and gave it enough thought to produce an amazing blog post -- that I'm sure will bear further fruits.

(That's of course not the only things I liked on LtU recently. There are many things I come to know through LtU that I wouldn't otherwise learn about, typically on approaches to programming languages that are closer to social sciences (user psychology and experimental studies, sociology of adoption, etc.)

What were your own "value moments" on LtU lately?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

I've been frustrated lately

I've been frustrated lately also, but in a different way. The quality of LtU's discourse has gone downward but that doesn't bother me so much; there are plenty of (famous) lurkers who read but aren't willing to engage in conversation (I know this because they tell me).

My crisis is that I've wandered too far out of the box for the PL academic community, which is actually quite conservative on average. So it never bothered me that LtU wasn't a clearing house for the academic stuff, we got plenty of that and if you want such "excitement" head on over to pl-enthusiast, or go browse the accepted SNAPL paper list. The POPL crowd is alive and well, just mostly not here.

But I see your point: LtU works really well as a forum for paper discussions, especially since the ACM Digital Library failed so horribly in this regard. It could be much better: LtU needs crowd sourcing to scale up...it needs the ability to up/down vote articles and posts, just like every other platform you mentioned (we cannot filter the noise now, and fewer are willing to stick around without it).. And then it needs a lot of TLC, of course.

Or maybe we just need a pl-rebellion, what if lambda wasn't the ultimate? And are those academic presentations really that interesting? One Bret Victor learnable programming essay is probably worth 10 POPL papers. I really would like to see more content like that.

Form vs content

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

Papers, Source Code and Discussion.

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

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.

Front Page = Home Page

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

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

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

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

I don't think your

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.

I would say the observed

I would say the observed symptom of the problem is simple: the proportion of LtU's discussion that I feel strongly interested in is decreasing. What about you?

Agreed, but how to fix it? Perhaps:

  • Submit more papers. If you look at the new forum topics or active forum topics, you see that most would not foster technical discussion.
  • Post more technical comments (for those who are experts in the field).

Beyond this I don't see any non radical/questionable solutions. You could introduce rules that prohibit or limit the volume of non technical discussion, or introduce social engineering with an upvote system and hope that the general audience votes for technical discussion, or try to establish another place for discussing papers (e.g. reddit, stack exchange, or a new platform).

Outreach?

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,

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)

Silver bullet

I will probably post a more thoughtful reply later, but I will say now that I think most of our problems could be immediately solved by banning raould.

odd

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

Or I can go on hiatus

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

Doubling down

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

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

gullible not in the dictionary

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

No

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

it ain't necessarily so

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

Feedback

I just skimmed through the last year of topics and I recognized quite a few that I found informative and useful (1ML, the next stage of staging, etc), though I agree with the general sentiment that general quality has been decreasing for some time. There are also just a bunch of one-off comments that link to interesting things (David's recent link to Unison comes to mind).

I will say to Gabriel that I've appreciated every forum topic I recall you having ever created even if no one ended up responding. Maybe we should be posting 'interesting, thanks' if you're going to using ensuing conversation length as your success metric. Skimming the recent topics has reinforced to me that I probably post enough, though...

My personal opinion is that until fairly recently, a high volume of low quality posts hasn't been the problem as much as the low volume of high quality posts. We'll have bursts of fluffier posts, but they seem mostly to spring up after extended periods of nothing substantial.

The best way to improve the situation is probably to discuss interesting research. Maybe if we're lucky (and the discussion seems cordial) some of the researchers will stop by to discuss. And even if they don't, you know... it's still interesting.

I've sometimes thought that

I've sometimes thought that a comment length limit might actually improve discussion quality. Nothing so drastic as twitter's limit of course, but most long comments either tend to wander across many topics, or feel like a small paper. Anything so detailed ought to be posted as a more fully formed idea elsewhere, and linked from here.

Then again, there are exceptions. Oleg's rare posts tend to be quite long as well, but always on-topic, focused and relevant. So a comment a length limit is a big and imprecise hammer for this specific problem.

An outsider's 2 cents

I "found" Ltu a few years ago and as I am creating a language/database system, I thought I could discuss issues having to do with programming languages on this forum. 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. This blanket statement isn't 100% justified or I wouldn't still be checking for interesting things on Ltu from time to time. For a forum that purports to be the "best" PL forum on the web (I don't disagree), should some large set of topics (imperative, object oriented, dynamic and script languages) and actual developers be un-welcome?

On Ltu, I read how bad some features and ideas were that created languages like PHP, Javascript, etc and isn't it too bad that experienced PL specialists weren't consulted on some of the most egregious mistakes made by these "amateur" developers before it was too late. None of the current crop of popular languages were known ahead of time that they would be so widely used so what languages deserve our attention? If there had been a place for those developers to get a little help, (in the idea department) those languages would probably have been better designed.

I takes a lot of work to categorize forum posts but PL ideas are timeless. Unlike many other topics, and even though many discussions are only by a few posters, if the posts were categorized better (multi-level organization of topics) it would make for a more useful resource for those looking for ideas.

I would prefer that more actual PL features and their implementations be discussed. Even critiques about PL features that are done right or wrong in specific languages would be very interesting. I find algorithms of all kinds very interesting and PL language implementation are full of those. If there are interesting things in papers described in Math, it would be very nice to discuss the ideas using PL ideas like memory locations, pointers, loops, pseudo code etc. Even though I have a minor in Math from University, I find a heavy reliance on Math to describe PL ideas quite unhelpful. We already have many formal and strict ways of describing ideas in terms that are easier to translate into code a computer can actually execute. I am not trying to start a fight about CS and Math. 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.

partly due to shaping noise vs signal

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.

there's good drivel, and there's bad

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

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.

It's your party after all.

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

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

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

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

All programmers don't make good PL designers

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.

Ironic

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.

Programming as language design

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]

programming as language design

I've reached the same conclusion: a programming language is a problem domain like any other problem domain and a good design will share the same characteristics of other good designs. 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 (which could be driven by any example domain) are immediately confirmed in your language design itself.

What is unique is that a

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

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

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

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.

Precise semantics

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

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.

Benefits of formalization

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

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?

Simplicity Follows Complexity

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

Co-design is the thing

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.

Alan Perlis said:

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

It is more like

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

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.

advice and revolution

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

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.

reactionary, yes

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

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.

psychoceramics

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

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

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!

Language Designers should consult PL specialists

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

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

Friendships

For me, I have calmed myself considerably, and don't post as much because I have managed to control my absurdly bad ADHD through several self-help books and calming my mind through dance therapy.

I would probably post if it was more collegial. I think the discussion is a lot more about proving people wrong now than it was to share in the excitement of this wonderous hobby/field of study.

Also, as a general observation, so much has become a science now that I can't even worry about new innovations so much as taking results from the lab and applying them to my day job. When I started programming 18 years ago, it was rare to encounter good programmers who knew why they did what they did. Now, for me at least, it is more common.

I also am in the process of getting rid of 1,000 computer science books I bought over the past 10 years, so once that is finished, I doubt I will have as much motivation to share my references, as most of them were scrawled in the margins in red ink/sticky notes of the 1,000 books I owned/read. -- You can message me if you live/are visiting Boston and you would like a free book and don't mind my obsessive red ink.

Nice

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.

Who is benefiting from this?

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.

post more

please. seriously.

Suggestions

As many know, my professional interests have changed quite a bit, and coupled with family obligations I spend much less time on plt issues. However, my three cents: (1) I think the policies and LtU spirit pages are still on the money. (2) I think the main thing that changed is that there are fewer contributing editors posting "big" items for discussion on the home page. Quite a few regulars decided they don't want to do this, as opposed to many of the regulars in the earlier days of LtU. Sign up and post! (3) LtU is great when there are discussions of cool new papers/projects/events/languages/approaches. These discussions typically begin when a contributing editor identifies something as cool and spends some 15 minutes composing a post explaining why others should bother reading up on something and joining the discussion. In this way LtU serves as a venue for discovering new things.

When I had more time to do this, I would go over the recent publications of all known-to-me-as-cool researchers whenever the discussion started to get dull. I still think this might be a good thing for some enterprising member to do occasionally.