This seems all over the place. You're marketing this to, what, people who have experience in C and want a better experience?
Why is there a readme link to download a .zip of the repo? I know how to clone.
Why is there a link to wikipedia's section on object orientation? I know that.
I don't understand the updates section. v3 parser implemented...okay? How is that better? What?
Then this big example which looks a lot like vanilla C. Is this the sum of what Nymph offers?
What I really want to know, and what is absent is:
* What does this give me that ordinary C doesn't?
* What are the longer-term goals of this project?
* Who is this intended for?
* How compatible will this be with ordinary C? Is there an interest in, say, gradual migration if this is to take off? What's the C <=> Nymph interop to look like?
Your target audience is c programmers right? Which c programmer knows Object Oriented Programming so poorly that you have to link to the Wikipedia article about it?
I'm currently working on a programming language (Lily. See this name on github), and this is really helpful. I've been thinking about adding debugging support, and this will help a lot toward doing that.
I really hate what seems to me a new trend of co-opting terms to muddy the waters and confuse the issues. This guy is not in support of NN. That's it.
Ideally we'd have so much ISP competition that NN wouldn't need be as necessary because the first company to propose splitting up the net would be laughed out of business.
But we've screwed that up, because there's hardly any ISP competition in America. NN makes sure they don't split up the net. Because we've seen before that they don't really care about the end consumer.
This is possible exactly because Java is statically-typed. Java's type system works over the operands, and does implicit conversions before the expression gets a chance to run. It sees values and does implicit magic from left to right.
Python, on the other hand, does not need to do a typing pass at parse-time. Instead, literals are stored as values, and those values are tagged with their source class. Python's way of doing it means that a + operation is called upon with an integer and a string.
Java might be able to yield the same kind of result as Python if it had operator overloading. It could define Integer's + operator as only taking other Integer values, therein yielding a type error at parse-time.
My own language uses ++ instead of + to distinguish between addition and concatenation, though I've considered some other token since the two are quite similar to each other.
> This is possible exactly because Java is statically-typed.
Are you saying that Python can't make "a"+1 become "a1" because it lacks static typing? That's not true. If they wanted to, they could have added an overload for the string+integer case.
> Java might be able to yield the same kind of result as Python if it had operator overloading.
Not necessary. They would have just had to omit the built-in overload for string+integer (and perhaps also for string+object, given the newish auto-boxing feature).
This has literally nothing to do with static typing. It is 100% due to implicit promotion (demotion?) of addition operands to string if either operand is a string.
All static typing does is mean that the type check, and so decision to insert the conversion call is done at compile time. Dynamic typing just means that the type check and decision to insert the conversion is done at the point the + is evaluated.
As someone who's writing a programming language, I find this to be utterly terrifying. At least start with some small tools to make sure the basics work! Somehow I doubt they had a good testing suite too, which is so very important when creating a new language to prevent "this won't hurt anything" fixes from creating a hidden bug far away.
You might think this is a curse, but as someone writing a language, people like yourself are a blessing. Exercising the weird cases that the original people overlooked and filing a bug is really, truly helpful.
Blink (Chromium’s engine) was forked from WebKit (Safari’s Engine) and the two have developed separately. Safari is not a skin of Chromium or vice versa.
As the sole maintainer of a pretty big repo, these are all super helpful. Another is that, if the project in question is compiled, add in a gdb trace. It's often the difference between "I know exactly what this is and I'll do it now to get it over with." and "There's about three+ ways this could be happening, I'll check it out later."
