WalkerCodeRangr

Author here.

I don't have any direct experience with Menhir because I haven't tried to write a compiler in OCaml yet. It does seem to be one of the better parser generators and is frequently recommended. Skimming the docs, its seems to be lacking in these areas:

  * Concrete syntax trees (as you pointed out)
  * LR(1) will probably still be more restrictive than I want
  * Unicode support (defaults to ocamllex, requires custom code to use ulex)
  * Intransitive Operator Precedence isn't supported (though it does have regular precedence levels and associativity)
  * While it looks to have better error handling than most LR parser generators, I suspect it still isn't where I'd want it to be.

I'm the author of the post.

With regard to operator precedence, my position may be closer to yours than you think. In the post I linked to about intransitive operator precedence (https://blog.adamant-lang.org/2019/operator-precedence/) I describe what I want. Basically, I think basic order of operations like `*` before `+` and associativity are important. But in more complicated cases you should be forced to put in parentheses. Exactly where that line is drawn can be debated. What I want is a way of handling operator precedence that is more complicated under the hood, but should be more natural for the programmer as it will respect basic precedence, but not leave you guessing about confusing expressions. i.e. `a/b/c` could be illegal and require parentheses even though `a+b/c` doesn't.

Check out https://www.folioinvesting.com They allow you to create your own "index funds" as well as select from a list of existing folios. Flat monthly fee.

Such things are so subjective, but the sources I read usually only list the first three. I'm not opposed to learning about ClojureScript, but I have to make choices about where to spend my time. At this point, I think I need to focus on addressing JS Linters and what I think an answer would look like. When I write those up, I'd love to hear feedback from someone who knows ClojureScript about how closely (or not) it matches what I would be looking for.

Thanks for the good info about the DT project. I want to say that even though I'm not personally a fan of TypeScript I really appreciate the work of you and everyone else who has contributed to the DT project. I know from my previous work on OSS how much work that can be.

My only experience using DT was through Nuget so I didn't realize you had the semver postfix. I suspect that like me most .NET devs will go to Nuget first, so I personally would place a high priority on getting semver in Nuget, but I understand that there are lots of other important things too.

My suggestion would to make including a semver part of your quality requirements so that at least you have a record of what version they were working against when they made the type definitions.

I hadn't realized the interdependent library testing/validation. You really are in a pickle about git branching/tagging and not being able to have separate repos. Problem is, the side by side definitions for different versions makes it difficult to merge fixes across versions (as compared to say a different branch for each version of the library). I think this is something that needs to be thought about long and hard. Could you use git submodules or subtrees to do what you need? Perhaps have each library in its own repo but then have a repo that pulls them together and has the interdependecy testing? That way most contributors could work in the repo for the project they care about and only a few contributors would worry about the combined one?

Thanks for sharing your experience with TypeScript and what is good about it. It's just not possible for me to address everything bad & good about a language in one blog post, so I have to focus on what's relevant to the point I am trying to make (in this case why I don't personally think TypeScript is the answer to JavaScript).

I absolutely agree that meshing with the JS ecosystem is of critical importance and Dart just doesn't have that the way TypeScript or CoffeeScript does.

I'm working up to that.

It's not just about staying at a particular version. It is about being able to find the version that matches what you are using. I recently started an new project using bootstrap and had to downgrade to v3.0.3 due to some incompatibilities. I have no idea how I would go about finding the matching type definitions from definitely typed. Their version numbers don't match bootstrap's (http://www.nuget.org/packages/bootstrap.TypeScript.Definitel...).

Also, how will the Definitely Type project be able to handle a fix to the definitions of an old version that doesn't apply to the current version?

Like jstclair I appreciate their hard work, but I think they really need to change their approach soon to avoid a lot of pain down the road.

Sorry you feel I am wasting your time. I am actually working up to the point of what I think would be better. The purpose of writing about the inadequacies of the existing tools is to provide a justification for creating an alternative.

I also want to gauge interest in creating another alternative to see whether it would be worth my time and effort.

Actually, I don't start with the premise that static typing is bad. I actually prefer static typing and if I was designing a language from the ground up it would probably be statically typed. In my day job I work largely in C# and JavaScript and much prefer C# (though it could be better). Unfortunately, we have an dynamically typed foundation (in JavaScript) to work from which makes it very difficult. None the less, dynamically typed prototype based languages can be powerful and have their advantages.

I actually really like Haskell though I have never had the chance to do a project in it. I appreciate the strong type inference and its flexibility in static typing. I occasionally find myself frustrated my C#'s limitations around complex typing. Like that there is nothing close to existential types and you can't create more complex generic type constraints.

Scala seems cool in what little I have read about it. I really respect Martin Odersky who designed it. I'd like to learn more about it, until I do I can't speak much to it.

I'm getting there. Check back in a few weeks!

Lol, I can't address every single one https://github.com/jashkenas/coffee-script/wiki/List-of-lang...

I'm certainly all for choice in development tools and I understand that there are people who like each of these languages. I think it is great that people are experimenting with all these extensions to JavaScript, both because they can inform the future of JavaScript or its successor and because eventually someone will come up with the right mix of features/changes to really supplant JavaScript.

That being said, for the reasons I spelled out I think the current crop of options are really lacking. I get that developers are going to use whatever tool they have to get what they need done, but I don't see why we shouldn't provide them great tools to do their work in.

I'm interested in a source for your statement that "Crockford loves Coffeescript". What I found was http://zhan.renren.com/h5/entry/3602888497994246013 which while very favorable sounds more like my statement that it is good things like this are happening. He concludes "I'm not sure there's enough of a payoff there. But just as an experiment, as a design exercise, I think it's a brilliant piece of work."