Re:Crayon programming language
by clintonc on Monday April 09, 2018 @04:11PM
(#16796536)
Man, you sound pretty grumpy about it. I'm pretty sure that the author does not mean "just like Java but with no types". Python is all about the syntax (and it's certainly not all about "math-friendly" syntax), though the syntax was an interesting choice. "Fixing JavaScript" means different things to different people, but I take it to mean that crayon differs in some aspects that annoyed the author about JavaScript.
Notice that the author was rather effective at getting us to think about the features of these languages and how crayon fits in.
Re:Crayon programming language
by d--b on Monday April 09, 2018 @10:14PM
(#16798522)
Sorry, I didn't mean to sound grumpy. I just wanted to say that as a C#, Python and Javascript developer, I am put off by the arguments put forward in the landing page.
Saying that is as forgiving as Javascript, as productive as Python and as robust as C# is a better way to sell the language than saying it is C# minus typing, Python minus easy syntax and Javascript minus problems...
Re:Crayon programming language
by Waterluvian on Monday April 09, 2018 @03:35PM
(#16796211)
JavaScript is fine. It has quite the trail behind it and there's some things I hope arrive sooner than later, but I get a lot done these days without any pain. Its fixed/fixing itself.
Re:Crayon programming language
by barskern on Monday April 09, 2018 @01:29AM
(#16790637)
I'm not really sure I understand what Crayon fixes for Javascript. Based on my understanding from the intermediate tutorial it seems to be mostly identical to Javascript, with a game library built in. Can somebody help me understand what makes this language stand out?
Re:Crayon programming language
by blakeohare on Monday April 09, 2018 @02:46AM
(#16790923)
Hello, I'm actually the creator of Crayon and was surprised to find this showed up here.
Yes, the syntax very closely resembles JavaScript but there's more traits from static languages such as Java and less malleability than JS. For example libraries and dependencies are resolved at compile time and you can make it print out a tree of dependencies at compile time for use in environments that need to be properly sandboxed. Also, fields must be explicitly declared. This allows a lot more things like simple typos to be caught at compile time. The other thing is that it's export-ready for the platforms it supports. For example, when exporting to iOS, it generates a full XCode project. While this is similar to frameworks or languages like Cordova or Haxe, the thing that is unique to Crayon is the localizability of the language and libraries into non-English languages. This is still in the prototype phase, but currently works for Japanese and Spanish: https://crayonlang.org/gengo
Re:Crayon programming language
by barskern on Monday April 09, 2018 @06:03AM
(#16791686)
Thank you for the explanatory answer.
Localization seems like a two-edged sword. Wouldn't it cause a spilt in the community when it comes to tutorials and documentation? Especially if the community is small.
In Excel I repeatedly faced the problem that the formula "programming" language was my own language and not English, which meant that all English Excel formulas I found had to be translated. In my opinion the benefit of writing my native language does not outweigh the problems of constantly translating formulas.
What are your thoughts on this problem? Have you thought of any ways to prevent such problems?
Re:Crayon programming language
by barskern on Thursday April 12, 2018 @11:05AM
(#16821663)
I understand what you mean, but I don't think you understand my point.
I am not thinking about the official documentation of the language. Normally translating the explanations in the official documentation only requires contributers.
However when someone makes a tutorial series or similar, that series will normally only be limited to one language because they will write the actual code itself in their language.
I think this would split an already small community.
Re:Crayon programming language
by mintplant on Monday April 09, 2018 @02:54AM
(#16790956)
And it looks like Crayon has full-fledged classes instead of mutable prototypes on objects, awesome. JS engines jump through some really tricky hoops to make things performant in the face of that architectural mistake.
Any plans for something like coroutines/generators?
Re:Crayon programming language
by blakeohare on Monday April 09, 2018 @03:08AM
(#16791001)
Unfortunately, not currently. I'd say of the missing "common" features that people expect out of languages, lambdas are next on my implementation list. But for the most part, my near-term goals are focused more on platform support (both the compiler and for exporting) and localization.
Re:Crayon programming language
by SenHeng on Monday April 09, 2018 @09:44PM
(#16798399)
Hey, I saw you present this on Saturday and really loved the idea of 'I write programs in Crayon'. I couldn't find anything related posted on HN so I decided to make a submission. Hope it didn't cause too much troubles.
Re:Crayon programming language
by blakeohare on Monday April 09, 2018 @02:48AM
(#16790930)
Alas, it's true. While the platforms Crayon programs can export to can run on Linux, the compiler itself was originally written in C# back when it was just a tinker-hobby project and does too many Windows-y things. The OSX support is based on Mono but is somewhat flakey in certain environments. Eventually I have plans to migrate the compiler to another language (possibly Crayon itself).
Umph, these are not good selling points.
- Strong typing is one of the top features of C# and Java.
- Python is all about math-friendly syntax (ie no curly braces and semi colons).
- And claiming to fix javascript is presumptuous.
At best, this makes it sound like a toy version of kotlin.
Notice that the author was rather effective at getting us to think about the features of these languages and how crayon fits in.
Saying that is as forgiving as Javascript, as productive as Python and as robust as C# is a better way to sell the language than saying it is C# minus typing, Python minus easy syntax and Javascript minus problems...
How so? Lua did it, why not someone else?
Yes, the syntax very closely resembles JavaScript but there's more traits from static languages such as Java and less malleability than JS. For example libraries and dependencies are resolved at compile time and you can make it print out a tree of dependencies at compile time for use in environments that need to be properly sandboxed. Also, fields must be explicitly declared. This allows a lot more things like simple typos to be caught at compile time. The other thing is that it's export-ready for the platforms it supports. For example, when exporting to iOS, it generates a full XCode project. While this is similar to frameworks or languages like Cordova or Haxe, the thing that is unique to Crayon is the localizability of the language and libraries into non-English languages. This is still in the prototype phase, but currently works for Japanese and Spanish: https://crayonlang.org/gengo
Localization seems like a two-edged sword. Wouldn't it cause a spilt in the community when it comes to tutorials and documentation? Especially if the community is small.
In Excel I repeatedly faced the problem that the formula "programming" language was my own language and not English, which meant that all English Excel formulas I found had to be translated. In my opinion the benefit of writing my native language does not outweigh the problems of constantly translating formulas.
What are your thoughts on this problem? Have you thought of any ways to prevent such problems?
I am not thinking about the official documentation of the language. Normally translating the explanations in the official documentation only requires contributers.
However when someone makes a tutorial series or similar, that series will normally only be limited to one language because they will write the actual code itself in their language.
I think this would split an already small community.
Any plans for something like coroutines/generators?
1 - great work! 2 - connect it to LLVM on the back end. That will cause your user base to absolutely explode.
I like your idea.