Emojicode: a static, strongly typed programming language(emojicode.org)
emojicode.org
Emojicode: a static, strongly typed programming language
http://www.emojicode.org/
22 comments
I wonder how many people in the world would have any idea what on earth the sentence "Finally a common "bimbominkia"can write accidentally a Sieve of Eratostenes" means. You may be unique :-)
It has generics?! My god, its already more advanced than Go.
I really hope this guy has written a regular language and has made a tool to convert the keywords to unicode symbols. Otherwise this is the most professionally presented waste of time I've ever seen.
It's about time we let go of the symbols hardcoded onto our keyboards and start finding better abstractions for our thoughts.
Touch devices have already started the move to a virtualized keyboard, but so far they only parrot the static layout of a QWERTY keyboard and add a few tabs for emojis.
Predictive typing adds a few higher-level, dynamic keys to your virtual keyboard as a top row.
But if you make every key dynamic and predictive, you have a self-programming macro generator guessing your next keystroke and combining frequent sequences into a new single function.
And if you have that, why do you need a 2D keyboard with the confusing N-to-1 mapping of functions to fingers?
The keyboard has to rest on a surface, you need to make non-discrete movement in space to find what you want, and the whole thing leads to enormous bodily stress.
It is time to wash the printed letters off our keyboards, tear out anything that is not the homerow, glue those buttons to our 8 homerow fingers, and live a full, untethered, virtual, predictive typing life =)
I want to tap on my thighs while zooming through predictive VR code interfaces, not go back to ASCII.
Touch devices have already started the move to a virtualized keyboard, but so far they only parrot the static layout of a QWERTY keyboard and add a few tabs for emojis.
Predictive typing adds a few higher-level, dynamic keys to your virtual keyboard as a top row.
But if you make every key dynamic and predictive, you have a self-programming macro generator guessing your next keystroke and combining frequent sequences into a new single function.
And if you have that, why do you need a 2D keyboard with the confusing N-to-1 mapping of functions to fingers?
The keyboard has to rest on a surface, you need to make non-discrete movement in space to find what you want, and the whole thing leads to enormous bodily stress.
It is time to wash the printed letters off our keyboards, tear out anything that is not the homerow, glue those buttons to our 8 homerow fingers, and live a full, untethered, virtual, predictive typing life =)
I want to tap on my thighs while zooming through predictive VR code interfaces, not go back to ASCII.
That would be APL! J is similar in using 'Tools for Thought' per Ken Iverson's paper, but it uses ASCII to APL's symbols as abstractions for larger concepts similar to the way math symbols stand for more.
I think a concatenative language with an immutable append-only log (instead of a stack, like Forth) as its implicit data structure would be the best fit for this sort of keyboard.
You don't need to type commands and then run them if the commands themselves are the keys.
The advantage over concatenative languages like Forth is that if you assume a graphical virtual keyboard from the start, you can also use a GUI to give you instant feedback on the state of the log instead of guessing by keeping the stack in your head.
All in all, this is circling back to keyboard terminals and session logs like we do in our shells today.
The difference is that, instead of looking at graphics and thinking of a table with papers shuffling around (thank you so much for that, Xerox PARC </s>), you set yourself free from ASCII paint on the keyboard and ASCII paint on the screen, keep the 1D terminal metaphor, and help users figure out what's possible through predictive typing (of which bash completion is an ugly toothless old cousin) instead of statically patronizing them with a limited set of options on a window.
The web has been moving in that direction. Twitter/FB news feeds are a command prompt with a log where you see yours and other people's commands (only "echo", unfortunately). WeChat, FB Messenger and Slack are all in on the "chat everywhere" UI concept.
What screwed with the CLI was not the metaphor. We've been chatting with our computers on the command line and it's great. The limitations were 1) in command & syntax discoverability and 2) in the richness of content that could be represented.
We fixed the latter with rich text popping up in our logs (Twitter was text-only before it started embedding stuff), now we need to fix the former with virtual predictive keyboards.
You don't need to type commands and then run them if the commands themselves are the keys.
The advantage over concatenative languages like Forth is that if you assume a graphical virtual keyboard from the start, you can also use a GUI to give you instant feedback on the state of the log instead of guessing by keeping the stack in your head.
All in all, this is circling back to keyboard terminals and session logs like we do in our shells today.
The difference is that, instead of looking at graphics and thinking of a table with papers shuffling around (thank you so much for that, Xerox PARC </s>), you set yourself free from ASCII paint on the keyboard and ASCII paint on the screen, keep the 1D terminal metaphor, and help users figure out what's possible through predictive typing (of which bash completion is an ugly toothless old cousin) instead of statically patronizing them with a limited set of options on a window.
The web has been moving in that direction. Twitter/FB news feeds are a command prompt with a log where you see yours and other people's commands (only "echo", unfortunately). WeChat, FB Messenger and Slack are all in on the "chat everywhere" UI concept.
What screwed with the CLI was not the metaphor. We've been chatting with our computers on the command line and it's great. The limitations were 1) in command & syntax discoverability and 2) in the richness of content that could be represented.
We fixed the latter with rich text popping up in our logs (Twitter was text-only before it started embedding stuff), now we need to fix the former with virtual predictive keyboards.
[deleted]
I prefer ArnoldC:
https://github.com/lhartikk/ArnoldC
This is actually a really interesting concept to use symbols to program. I'm curious if somebody will expand Yoon this to make it more usable.
And next is PL/Emojicode for PostgreSQL...
How long before we have a javascript version of this? Surely it's already in the making somewhere?
I had a nightmare strangely similar to this recently...
Reading through the documentation I was trying to get the naming conventions or the tongue in cheek humor (which I presume is there).
Please make the emojis in the documentation code snippets clickable else it is really hard to follow.
Please make the emojis in the documentation code snippets clickable else it is really hard to follow.
They are selectable, aren't they?
Or did you mean something else?
Or did you mean something else?
I believe he means make it so you can enlarge them by clicking.
An enterprising contributor might enrich two worthy Open Source projects simultaneously by writing a Hoon <-> Emojicode transpiler.
This makes me want to kill myself.
Wasn't there a lisp implementation using emojis before? I forgot the name of it. This looks a little interesting I gotta admit.
> I forgot the name of it.
Uh, "emojilisp".
https://news.ycombinator.com/item?id=8342069
Uh, "emojilisp".
https://news.ycombinator.com/item?id=8342069
I guess they named it as simple as possible, thanks!
This may have the highest quality-of-implementation/quality-of-idea ratio of anything I've seen.
Finally, a language whose syntax is impossible to discuss on HN. I think I'm sticking to LOLCODE.
> static, strongly typed
:-(
Blech, impractical, academic garbage for people who wear starched shirts and arrange pencils on their desks in neat rows. I'm sticking with Emojilisp for all my development.
http://emojilisp.com/
:-(
Blech, impractical, academic garbage for people who wear starched shirts and arrange pencils on their desks in neat rows. I'm sticking with Emojilisp for all my development.
http://emojilisp.com/
Strong static typing is pretty much an unmitigated win.
OK, program in a language where an array's size is an immutable part of its type. No casting, no autoconversion, no manual conversion. Now write reusable functions which operate on arrays.
Remember that a string is a kind of array, and inherits all of the same properties.
Remember that a string is a kind of array, and inherits all of the same properties.
That's just an argument against languages with broken arrays. I'm guessing you've been doing a lot of Java lately?
Even Java has a sane typing system if you stay away from arrays (use ArrayList for crying out loud) but beyond Java, there is a wealth of languages with very good static type systems (Scala, Kotlin, Ceylon).
Even Java has a sane typing system if you stay away from arrays (use ArrayList for crying out loud) but beyond Java, there is a wealth of languages with very good static type systems (Scala, Kotlin, Ceylon).
Or how about one in which "upper case letter" is a static type. A string of all upper case characters is statically declared; we don't have to iterate at run-time to check it character-by-character any more, wee!
Division by zero is passe; we just define a type that excludes zero, and make the division operator's denominator of that type.
Division by zero is passe; we just define a type that excludes zero, and make the division operator's denominator of that type.
There is a non-zero integral type in Haskell, I believe.
This feels like a straw man argument against static typing. No statically typed language I use suffers from this because they have great data structures and generics.
Languages such as Rust that lean on inference are an absolute joy to program in.
Languages such as Rust that lean on inference are an absolute joy to program in.
Actually, Rust arrays have the size as part of their type, and without type-level-integers, there is a lot of pain around them. :(
That said, there's the solution: type level integers.
(That also said, Rust's String type isn't an array, because it's mutable, so the size can't be a part of the type)
That said, there's the solution: type level integers.
(That also said, Rust's String type isn't an array, because it's mutable, so the size can't be a part of the type)
Fortunately, Liquid Haskell already exists.
I wouldn't say it's production quality yet... But it's a work in progress, and achieves far more than you are requesting here.
I wouldn't say it's production quality yet... But it's a work in progress, and achieves far more than you are requesting here.
You can also go with Agda for full on dependent typing.
Or Idris, which is (IMO) more practically useful than Agda.
The big advantage to liquid types, a la liquid haskell, is that you get far more inference than you can get in full dependent typing.
I still think liquid haskell is too immature (Integer is not a good theory for Int, type classes aren't handled well, etc), but the promise is fascinating if the issues get worked out.
I still think liquid haskell is too immature (Integer is not a good theory for Int, type classes aren't handled well, etc), but the promise is fascinating if the issues get worked out.
At last. A true mobile-first language.
this was inevitable
APL for the millennials!
I think this is a great artistic piece. It made me think about lucky I am to have English as a first language, as it's also the language of CS and thus, computer language keywords. For those learning programming who don't know English, I assume this isn't too far removed from their experience.
We should propose to the mobile world congress to add it on every mobile device.