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.
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.
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.
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.
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).
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.
Yeah, I heard PG built ARC in Emojilisp after giving up on Racket ;)
If I were to chose, I would choose Emojilisp too! Haskellers will certainly prefer Emojicode.
Finally a common "bimbominkia" (I don't know the word for that in English, he is a teenager that writes emoticons in a chat and post selfies on fb) can write accidentally a Sieve of Eratostenes.
We should propose to the mobile world congress to add it on every mobile device.
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 :-)
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.
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.
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.
