bendmorris

Not sure what you're getting at. People in this thread are discussing what it's like to use Nim, including its ecosystem, vs. other languages and ecosystems. You don't seem to have anything substantive to add to that other than that Nim is "new" which as I mentioned isn't relevant to the experience of actually using it.

What on earth are we comparing when discussing Nim vs. other languages, if not the language itself, in practice? Are we just discussing how good you feel about it?

My point is, this is an actual deficiency that you need to consider when evaluating Nim, that isn't just a function of the language being new. For example, Zig is another option which puts any C libraries at your fingertips, without requiring bindings. If Nim had better interop (not just relatively good, but zero effort) this would no longer be a concern and you wouldn't need all of your libraries to be in Nim.

>i don't understand why people make these kinds of criticisms.

Because language age doesn't make a difference. People have to actually use the language, and this is a practical concern.

If you were choosing to put a high school football player or an NFL player on your team right now it'd be an easy choice, wouldn't it?

That is correct. I think there are tradeoffs in making the language too extensible; in this case it's changing some of the details but not the high-level semantics of how the language works. If every library looked completely different lexically, it would be a nightmare to reuse code. Users of Rust macros may already start to feel this; many libraries are implemented as essentially DSLs.

With that said, down the line I plan to add procedural macros, and those will likely be lexical (they take a series of tokens as input, which doesn't need to parse into valid AST.) If I do go that route, such macros would have to be invoked explicitly.

Certainly. I don't used Scala much but the inspiration is probably easy to see.

These are valid concerns, particularly stability and long term support. Availability of libraries applies less to Kit or Zig thanks to first-class interoperability with C. I think this is the way forward for small new languages; you can avoid the challenge of creating an entire ecosystem for your language, and just fit it into an existing one.

I think this thread captures a more interesting application of term rewriting: https://twitter.com/bendmorris/status/1041130408463687681

>My intuition is that ambiguities are at least possible, so what about precedence, which AST term is evaluated first? I'm thinking of some situation where two subtrees match the rule, but you end up with different results depending on which is transformed first. E. g. if you were to define a cross product rule, and apply it to a × b × c.

This is absolutely a potential issue, and the examples I have up now are quite bad. This is why it's important for rules to be strictly scoped. The only rules that can affect an expression are the ones you've explicitly brought in with a "using" block, or those that are defined for the types you're directly working with. Given the scoping, I think overlapping rule applications will be uncommon in practice.

>What about infinite loops in rule sets? What about recursion?

There's a sanity limit on the number of times an expression can be rewritten, and it'll show an error in that case which displays the transformations that triggered the limit (including the first, last, and any non-repeating transformations going backward from the last - so it should be very clear.)

>Is there any way to debug the transformations?

This is definitely an area for improvement. I'm planning to (1) add enforced "rewrite this" metadata that will fail to compile if the expression isn't rewritten, and (2) enable dumping not only the final AST but also all of the transformations that occurred.

Good "catch" ;) "throw" in Kit is vestigial; there's no error handling mechanism implemented yet, and I've gone back to the design phase to consider some alternatives.

>Are people not skilled enough to propose or send commits to an existing or alternative programming language?

I'll just comment on this part. I'm a contributor to Haxe (not so mainstream perhaps but more so than Kit.) Kit was a chance to try out some features that don't fit in well to Haxe (and in fact I did propose several of these features as additions to Haxe, and they were explicitly rejected.) Sometimes the answer really is to write a new language, because language simplicity is still important and one language can't be everything to everyone.

And of course, Haxe wouldn't exist if its creator hadn't been unsatisfied with existing languages at the time...

I, uh...I know a little C++ :)

I like to think that when I'm writing Kit, I'm writing C, so I am writing in a "real language." Total interop, no real drawbacks.

I commented on Zig elsewhere in this thread. Since Jai is unreleased I don't know a lot about it, but their AoS/SoA convertibility was an interesting feature (you can do this in user space in Kit via term rewriting) and I wanted to make it similarly ergonomic to pass around custom allocators.

I feel like there's a gold rush on three-letter language names. It's going okay so far, but Nit and Zit and Nag had better have some nice features.

I'm planning to get a more detailed comparison with languages in the same space. Kit and Zig overlap quite a bit; the main difference I see is philosophical. A major goal in Kit is to be concise, expressive and eliminate boilerplate; Zig perfers to be straightforward and readable, where a function call at runtime always looks like a function call in your code. Term rewriting and implicits are examples of features in Kit that probably wouldn't be implemented in Zig. Also, Zig aims to replace and compete with C, Kit just wants to leverage it, so the scopes are quite different.

Zig is awesome - I've used it and would use it again, I'm funding the creator on Patreon, and I see these two languages as filling slightly different niches and having different pros and cons.

I've used Haxe a lot and at this point I see its wide array of targets as not only a strength but at times a major weakness. I used the C++ target most often, but didn't have access to all of C++ features because they had no analog on other targets like Lua or Python - essentially Haxe becomes a least common denominator of all its targets. Focusing entirely on C lets me have a great interop story, and C is highly portable already.

Hi, creator here.

>Basically, what "designed for game development" means?

I've been doing a lot of work in Haxe, but have struggled with performance issues due to GC and memory churn. I wanted a lower level language with more control, but without sacrificing the ergonomics and abstractions I'm used to. Term rewriting and implicits are examples of features that let me layer abstractions onto a language but still maintain complete control.

>What was the original language and why made the change?

It's not up on GitHub, but the prototype was begun in Rust. Ultimately I found I'm much more productive in Haskell and made the switch.

>Rust does not have this feature - unions must always have tags

Rust has had untagged unions since last year (https://blog.rust-lang.org/2017/07/20/Rust-1.19.html)

Nah. Having kids is a choice. If you're going to view/treat them as a burden, just don't do it.

I don't get this mentality at all. The number one thing I wish I had was more of in life was quality daytime hours to spend with my family. It's why I have kids. I've been spoiled by paternity leave for our new little one, and I don't know how I'll cope with having to go back to work.

Second this. I'm writing a compiler now (https://github.com/kitlang/kit) and this book has been invaluable.

A few other tips:

* Use a parser generator. Parsing is more or less a solved problem; get it out of the way as fast as possible.

* Writing a language that compiles to another language is very helpful as you can often borrow the underlying language's implementation of a feature. Doubly helpful if you can leverage the underlying language's libraries for things like syscalls.

* Make a todo list (I like Trello for this) full of self-contained tasks. Pick one at a time, think through how you would implement that feature, and go to work. Compilers look like a lot of work in the beginning, but if you take one step at a time, one day you'll look back and have accomplished more than you realize. The list can also be helpful to avoid scope creep; add any new ideas to your backlog and deal with them later.

* Write unit tests, as you'll very likely want to refactor something down the line. Once your compiler becomes complex enough, add functional tests that verify entire programs can compile and run and produce the expected output.

We're all in this together. You can support parental leave and also advocate for other types of family leave. Not only are they not mutually exclusive, stronger parental leave norms will probably make other types of leave more acceptable.

Scons (https://scons.org/) is one alternative. The configurations (and Scons itself) are Python.

I don't understand how anyone can spend a career in software development, and still have such a poor understanding of the process. Space and time are far from the only concerns.

>As an example, someone who thinks of the machine as something that can evaluate list comprehensions in Python and use OO to access data elements has no clue whatsoever about what and how might be happening at the memory level with their creations. Hence code bloat and slow code.

Not having to care about details that aren't contextually important is a good thing. When someone is constrained more by development time than by computational resources, working in a high level language means you're explicitly shunting low level concerns so you can spend more time dealing with domain logic.

There are many situations where finishing something faster, which will run 10x slower and use more memory, is a worthwhile tradeoff.

The H and L registers are special in that they can be used for indirect addressing: some opcodes will combine H (high) and L (low) into a 16-bit number, interpret that as an address and read from that memory location.

It's 70/20 in aggregate. It's your anecdotes vs. a Pew study, there's not much more to say.

>They are Democrats AND Republicans...

As of 2016 they are the most heavily Republican-leaning religious group in the U.S. [1]

Technically, there's a Democrat in every city in Utah, but let's not pretend they're a microcosm of the country without a very distinct culture.

[1] http://www.pewresearch.org/fact-tank/2016/02/23/u-s-religiou...

> Meekness is a positive trait in the LDS church.

Nominally, sure, just like other Christian religions. There are still plenty of big expensive houses in the Salt Lake area.

Haxe doesn't quite operate at that level, it's more compiler than build tool. You'd use Haxe to compile to Java or C++, but you'd use a framework such as OpenFL, which provides its own build toolchain, to actually build an Android app via Haxe.

Asking your age isn't illegal by itself. ADEA makes it illegal to discriminate against workers age 40 and up based on age. Doesn't apply here.

In fact, employers can have legitimate reason to ask your age, such as background checks.

>Homebrew was not something you could be proud of writing.

Anyone should be proud of writing a widely used tool that provides value to so many individuals and companies, regardless of nitpicks from the peanut gallery.

Some quotes:

>Does that mean I’m a happy camper? Fuck no. My total comp for the first year is only $145k out of undergrad with a base of $106k. My friends at places like Google, FB and Cruise are making more like $180k-$230k by comparison. Perks are also nonexistent.

>The worst part, though, is knowing that i have become stuck in a company with a significantly lower hiring bar. Im honestly terrified that the value on the resume will decline over time and i will never be able to get into a more prestigious company. The idea of being relegated to a 2nd or third tier company has been eating at me, and comments on places like CSCQ, Blind and this AskHN nearly drove me to suicide before.

OP, what makes you happy? I suggest that being at a "more prestigious" company like Facebook or Google (granting for argument's sake that they actually are) will not make you happier, neither will making a few thousand bucks a year more than your already higher-than-median salary. You can waste years of your life chasing these things only to discover they didn't make the difference you thought they would. At the end of the day, what do you want to do?