21–30 of 59 posts
This might seem strange, but if there's one thing from Common Lisp that should receive wider adoption in other languages, it's hyphenated names. They are so much more readable than anything else (well, C with underscores comes close).
https://github.com/TazeTSchnitzel/Firth/commit/7b9bf0b4c090e...
Thanks for the idea! :)
Earlier quoted context omitted.
While I've never seen this use personally, UrbanDictionary very strongly corroborates this. http://www.urbandictionary.com/define.php?term=unf
It’s worth noting that “universal noise of fucking” is a backronym—the word was originally onomatopoeic.
Earlier quoted context omitted.
“Unf” is quite widely used as a spelling of a moan, to express sexual desire or gratification. While it can be used to express non-sexual enjoyment, the sexual connotation it evokes is just unnecessary when it comes to a programming language, regardless of the original intent.
As an counter datapoint, this is the first time I have ever heard of this.
This might seem strange, but if there's one thing from Common Lisp that should receive wider adoption in other languages, it's hyphenated names. They are so much more readable than anything else (well, C with underscores comes close).
This would be an easy text-transformation that you could do in vim. Upon opening the file, translate all dashes without spaces "foo-bar" to add spaces "foo - bar". Then convert all underscores to dashes. "foo_bar" to "foo-bar". On save, invert the process. You'd have to actually run the language's parser in order to do the transformation to avoid changing strings, and even then it'd only work if the parser output kep…
Emacs does this in some cases: specifically for camelCasedWords (http://www.masteringemacs.org/article/making-camelcase-reada...) and for the word 'lambda' which can be displayed as a symbol. There are many other modes which "overlay" some text over how it looked originally.
Note that it definitely has types, they just aren't required explicitly. It seems to use dynamic type matching.
It's unityped! It has one type with infinitely many variants/tags (. ). Match failure occurs at runtime as in any other safe typed language such as Haskell or ML.
That is incredibly disingenuous. The only way a Haskell or ML program could be as colossally unsafe as a unityped language program is if the programmer used only one giant sum type for the entire program, and most functions in the program were non-total with respect to that type.
"Unityping" provides no static type safety. It is isomorphic to, and usually a euphemism for, the lack of any static type system.
Earlier quoted context omitted.
It's unityped! It has one type with infinitely many variants/tags (. ). Match failure occurs at runtime as in any other safe typed language such as Haskell or ML.
If you customize your runtime behavior based on any metadata about the value on which you operate, you have multiple types. Attempting to change the syntax will not change the fact that you need to differentiate behavior for numbers and strings.
That's actually not exactly right: for example in Forth you really have no types at all.
Also, if somewhat uses a word such as "unityped" or "type with infinitely many variants" you should immediately know that any mention that "there are types, alright, just checked on runtime" will be immediately rejected. Majority of static typing fanatics are like that.
Earlier quoted context omitted.
As an counter datapoint, this is the first time I have ever heard of this.
Perhaps as "umph" or "umf"? No?
FWIW, I grew up in Scotland, then moved to England, so I'm probably from a rather different cultural background than the poster.
This looks cool -- is there any source code? What language is it written in? "Tulip is still in active development, and I could use a whole lot of help, both filling in the design gaps here and actually churning out the implementation"
Earlier quoted context omitted.
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 'unkno…
This looks cool -- is there any source code? What language is it written in? "Tulip is still in active development, and I could use a whole lot of help, both filling in the design gaps here and actually churning out the implementation"
https://github.com/jneen/tulip
https://github.com/jneen/tulip/blob/master/tulip/libedit.py
(RPython is the "static" subset of Python used to bootstrap PyPy)