Yeah, it's basically a toolkit for building jitted languages. Basically the easiest way to get a tracing jit these days. So it'll be a self-hosting jit similar to pypy or pixie.
Yeah, it was a difficult decision to remove types - I'd gotten myself into a corner trying to tack on dependent types, and it just wasn't happening. My bet is that unlike most of the un{i,}typed languages out there (most of which I'd categorize as lisps and smalltalks), tulip provides tagging and destructuring that allows the programmer to maintain some level of control over the polymorphism. Tulip will panic at runtime for non-total functions, but ideally you'll have the tools necessary to keep the panic as close to the problem as possible.
Yep, it's my opinion, and that's why I put it into the design. Lots of language design comes from opinions. I hope it's borne out. FWIW it's the same approach Rust has taken, where macros have to end with a ! to make them visually distinct.
That might be because Rust might not eat its own dogfood in that department, and build some of its own functionality out of its macro system.
But I can see just "knowing" at a glance if it's a macro or not.
I think the answer would basically be determined by how much of the language itself uses its own macro system AND what type of macro system it actually is. If it's significant, having special syntax would just look weird.
Rust does eat its own dogfood with regard to macros, and over time has steadily replaced former language-level features like `log` and `panic` with macros. Syntactic distinction is a philosophical choice in service of making costs more explicit (and while it's true that functions can hide behavior, overuse of macros can trigger enormous code bloat, such as the `regex!` macro which compiles your regex into a state machine).
(There are also valid technical reasons for requiring syntactic distinction, as the sheer flexibility of Rust's macros in their ability to create new syntax run the risk of making it a nightmare to parse if you remove the unambiguous ability of the compiler to drop into macro-parsing mode. These challenges aren't insurmountable, just very hairy.)
If you see (foo ...) but don't actually know what foo does, it doesn't matter all that much whether it is a function or an operator. Even if you know it's a function, that just tells you how the arguments are evaluated; but not what happens with those values. Untold effects could hide behind a function call.
Yep! It focuses more on dynamic type-checks than on static typing though, so I put it in the category of "untyped functional" - more like clojure and erlang than haskell or ml.
Well, dynamic types are still types. :) It also seems strongly typed through a lack of implicit conversions between types.
I would say this is more like go than anything, though it seems to lack methods (and interfaces) and includes a functional syntax.
You're going to run into issues when attempting to extend polymorphism for built-in functions to user-defined types—imagine trying to figure out how to sort an 'unknown' type without a way to compare them without modifying the method to be explicitly aware of the new type.
There does seem to be a method/interface system (Under the "Methods, Protocols, Implementations" header). And it seems to have some sort of dispatch system for tagged structures that can be later modified by the user.
Exactly! This is what the @method / @impl system is for - it's about equivalent to clojure's defprotocol. Future plans include named protocols consisting of multiple methods, and protocol-based matching.
This happens in hierarchies regardless of genders. Anyone bullied in school or a workplace can tell you this.
You would need to measure if it in fact happens more often if it's a woman being a victim which is very difficult as most of those situations are not reported by neither gender.
It's not easy for anyone though... Firstly, there are some people that are just assholes. Second, men in general (not all men/women), tend to be more aggressive than women. This can be intimidating or plain off-putting at times. Excessive arrogance has always bugged me a lot. The third is that some people are socially awkward in general, which can lean towards other issues.
Lastly, an all-male or all-female group will be much more crude or open about thoughts, jokes or concepts than in evenly mixed company. Groups that are very one-sided tend towards this as well. When I was younger, I worked in a few offices where I was the only man that worked there... What I overheard in those years of my life is far worse than what I've heard from any all-male or mostly-male offices I've ever worked in.
With time, as the numbers tend to even out, the feel of a space that is more equally mixed (genuine assholes aside) will be more even... Personally, I prefer to work with all men day to day. I do have to interact with women in another office, and have worked with them fine. I am just less distracted without women around, and that is on me.
I'm happy that she decided to share. It's easy to forget how real this issue can be. The shit show in the comments here when an article like this is new further demonstrates the fact that there's still more work to be done. I will say though I do like HN because it seems to pretty quickly approach reasonableness with the voting system.
That is one of the scariest aspects of all this: there is an aggressive Internet mob that does nothing of value for Free SW, but will come in full force any time that an issue like this one is debated in the open, and will stop at nothing to ruin the life of those they identify as enemies.
Encouraging civility and attracting new contributors are very important goals for the future of Free SW. Achieving that will help us create better products that can be useful for more people.
Therefore, having all this harassment and hate come up whenever there is talk about improving the community is tremendously hurtful. It is sabotage, that's what it is.
