Mythryl Programming Language(mythryl.org)
mythryl.org
Mythryl Programming Language
http://mythryl.org/
45 comments
http://mythryl.org/book130.html gives some differences from SML/NJ. It looks like it's slightly more than a new syntax skin (which is good, because otherwise the decision to fork was horrible; SML/NJ now has 64bit and the fork doesn't).
Mythryl handles (as part of language defn) printf format strings => type safe library call (I think Ocaml did this too).
The only thing I found that seemed substantial (more than syntax) was explicit support for an eval facility (also in SML/NJ, but not officially) -
Syntax difference table: http://mythryl.org/book135.html
I definitely prefer mythryl's syntax on the whole, to SML's.
Mythryl handles (as part of language defn) printf format strings => type safe library call (I think Ocaml did this too).
The only thing I found that seemed substantial (more than syntax) was explicit support for an eval facility (also in SML/NJ, but not officially) -
eval: String -> Void;
evali: String -> Int;
evalf: String -> Float;
evals: String -> String;
evalli: String -> List( Int );
evallf: String -> List( Float );
evalls: String -> List( String );
Syntax difference table: http://mythryl.org/book135.html
I definitely prefer mythryl's syntax on the whole, to SML's.
Mythryl is not just a bag of features like C++ or Python
This reads like programmers' dialect of a marketing speak. It's bold, flashy, presumably based on some facts that are not immediately obvious and it also trashes competitors along the way :)
This reads like programmers' dialect of a marketing speak. It's bold, flashy, presumably based on some facts that are not immediately obvious and it also trashes competitors along the way :)
Python is a really clever small(ish) language and VM that can be embedded in C other programs and serve as glue code for modules in C. It's also grown to be a good scripting language for the technical crowd. C++ started out as a way to have decent OO on top of C as a preprocessor. There are far too many features in it for my taste.
Ruby: lots of nice things, but err on the "bag of features"
side.
Lisp: syntax stripped of almost all sugar. Stripped down to the
basics. Scheme is the Ariel Atom of programming
languages.
Smalltalk: add just enough syntax sugar to lose some power of
Lisp, but retain enough to be a complete meta-language.
(Not enough syntax to please most of the non CS crowd.)
You might want to look at Lua, FWIW. It focuses more on being a "really clever small language for embedding in C". (It also actually has tail call optimization, non-broken lambdas, no need for a GIL, etc.)
I've never really looked much into Lua before? Does it also have some sort of unifying base underneath it all? I liked Why's Potion because it reused many of the same syntax constructs in different places, so that there were few special cases.
It does, actually. Lua uses tables as its underlying data structure in the same way that Lisp uses the list. This is where a lot of its power and simplicity comes from. In fact, the language authors have stated how Lisp was one of their inspirations for the language.
You can read about lua tables here: http://www.lua.org/pil/11.html
You can read about lua tables here: http://www.lua.org/pil/11.html
Lua is intentionally very small ("doing more with less"). It has a lot in common with Python, Scheme, and Javascript, but was designed for embedding, and where Python prioritizes "batteries included", it puts more emphasis on "small/simple/powerful". (If you're extending a C project, you've already got libraries.)
The _Programming in Lua_ book is the best place to start. The previous version is free at http://www.lua.org and will give you a good impression. (The main diff between 5.0 and 5.1 is the module system.)
The _Programming in Lua_ book is the best place to start. The previous version is free at http://www.lua.org and will give you a good impression. (The main diff between 5.0 and 5.1 is the module system.)
Worse is Better -- being a better product can't make up for a lack of momentum.
"Worse is Better" is just an inaccurate way of saying it. More accurately, "It's the Culture, Stupid!"
If a language fits a group's culture better, it will be adopted more. Smalltalk lacked operator precedence for algebras -- big lose for the non CS sci/tech crowd. At first Java had some of what Smalltalk had, but fit general programming culture better in terms of C-like syntax, free (beer) tools, and static types.
Lisp is close to timeless mathematics, but a bit farther away from everything else than everything else. I don't think it's a coincidence that the AI field gravitated towards Lisp -- those guys were used to meta-abstraction.
Perl just threw every Unix tool there was into a burgeoning scripting Swiss-Army knife. As a result, everyone in the Unix camp could relate to it instantly.
Worse is not better. Better is better. But designing to fit existing cultures has a big short-term payoff for a programming language. This means a bigger user base, which means more eyeballs, more libraries, and other dynamics that also get you lots of Better.
The Best would be: a programming language that has a high fit with non-CS/programming sci/tech types and elegant design, first-rate implementation, and mathematical universality.
If a language fits a group's culture better, it will be adopted more. Smalltalk lacked operator precedence for algebras -- big lose for the non CS sci/tech crowd. At first Java had some of what Smalltalk had, but fit general programming culture better in terms of C-like syntax, free (beer) tools, and static types.
Lisp is close to timeless mathematics, but a bit farther away from everything else than everything else. I don't think it's a coincidence that the AI field gravitated towards Lisp -- those guys were used to meta-abstraction.
Perl just threw every Unix tool there was into a burgeoning scripting Swiss-Army knife. As a result, everyone in the Unix camp could relate to it instantly.
Worse is not better. Better is better. But designing to fit existing cultures has a big short-term payoff for a programming language. This means a bigger user base, which means more eyeballs, more libraries, and other dynamics that also get you lots of Better.
The Best would be: a programming language that has a high fit with non-CS/programming sci/tech types and elegant design, first-rate implementation, and mathematical universality.
"Worse is Better" is just an inaccurate way of saying it. More accurately, "It's the Culture, Stupid!"
No, this is an oversimplification. Richard Gabriel's original essay[1] says it best near the end:
The lesson to be learned from this is that it is often undesirable to go for the right thing first. It is better to get half of the right thing available so that it spreads like a virus. Once people are hooked on it, take the time to improve it to 90% of the right thing.
1- http://www.jwz.org/doc/worse-is-better.html
No, this is an oversimplification. Richard Gabriel's original essay[1] says it best near the end:
The lesson to be learned from this is that it is often undesirable to go for the right thing first. It is better to get half of the right thing available so that it spreads like a virus. Once people are hooked on it, take the time to improve it to 90% of the right thing.
1- http://www.jwz.org/doc/worse-is-better.html
Is it your assertion that Lua does not have momentum?
Yes. Nobody I know or am in contact with through the Ann Arbor tech scene uses Lua.
Loathe as I am to engage in a programming language pissing-match, I think you will be surprised at how widely lua is embedded, perhaps even in products that you have used.
http://en.wikipedia.org/wiki/Lua_%28programming_language%29#...
http://en.wikipedia.org/wiki/Lua_%28programming_language%29#...
Now you do! Well, I don't use it, but I work in Ann Arbor, and a guy who sits about 30 feet from me uses it in his product.
You should not evaluate the worth of something by the number of people that use it.
Pithy and sounds good, but totally discounts network effects. Programming languages are subject to network effects -- users create libraries in the language, increasing the usefulness of the language. Of course, interoperation between languages is possible to some degree, but that doesn't detract from the core statement.
It's really not hard to use C libraries from Lua, and its design for embedding / use as an off-the-shelf extension language has made interfacing easily with other languages a high priority.
There are projects that supposedly allow interoperability with Python, Perl, and several other languages (http://lua-users.org/wiki/BindingCodeToLua), though I have only used the C API thus far.
The core language is also small and simple enough that adding major language extensions, such as Erlang's concurrency model (http://concurrentlua.luaforge.net/), is feasible.
There are projects that supposedly allow interoperability with Python, Perl, and several other languages (http://lua-users.org/wiki/BindingCodeToLua), though I have only used the C API thus far.
The core language is also small and simple enough that adding major language extensions, such as Erlang's concurrency model (http://concurrentlua.luaforge.net/), is feasible.
> It's really not hard to use C libraries from Lua, ...
My understanding is that it's actually very easy to use C libs from Lua.
My understanding is that it's actually very easy to use C libs from Lua.
You have to be comfortable with C, so that rules out some people.
Many useful libraries are in languages other than C.
> Python is a really clever small(ish) language and VM that ...
I wouldn't call Python clever, per se. I'd call it sensible. Possibly conservative. Maybe hoity toity.
I wouldn't call Python clever, per se. I'd call it sensible. Possibly conservative. Maybe hoity toity.
I'm sorry, but their code formatting (an equals sign and a brace each on their own line to start a function???) and choice of syntax is just atrocious. "Fi" and "esac"... are you serious? At least we don't have to type nuf to end functions and ipa to end api definitions. In VB, you type End and then what you are ending. In Ruby, you just type end. In Mythryl, who knows? Sometimes it's a backwards word, sometimes it's end, sometimes it's a brace. This is what a well-designed language looks like to them?
Furthermore, they talk about things being built in from the start, but the site says that one of the current projects is implementing object oriented programming. How in the world is that not going to be bolted on? If there's anything that you need to bake into a language (if it's going to have them) it's objects.
Finally, there is a lot of talk on that page to not have any sense of organization or "here is some cool stuff you can do now that you couldn't before."
Usually I'm excited to read about new languages. (Potion looks AWESOME.) This... was disappointing. Sure, it may perform well, but I really don't care. I'd rather ease of programming and maintenance any day. Python and Ruby for the win (at least until Potion is done).
Also, they say they're putting the "fun" in "hacking", but as mentioned before, the page looks like it was written for managers and certainly not for hackers.
Furthermore, they talk about things being built in from the start, but the site says that one of the current projects is implementing object oriented programming. How in the world is that not going to be bolted on? If there's anything that you need to bake into a language (if it's going to have them) it's objects.
Finally, there is a lot of talk on that page to not have any sense of organization or "here is some cool stuff you can do now that you couldn't before."
Usually I'm excited to read about new languages. (Potion looks AWESOME.) This... was disappointing. Sure, it may perform well, but I really don't care. I'd rather ease of programming and maintenance any day. Python and Ruby for the win (at least until Potion is done).
Also, they say they're putting the "fun" in "hacking", but as mentioned before, the page looks like it was written for managers and certainly not for hackers.
I agree that the consistency of esac isn't very nice. I prefer } to esac/fi to end, actually. "end" is horrible. You can consecutively }}}} or )))) in a way that reduces some of the whitespace-significance jealousy
The two line = { is only for compound functions; a single expression with a "where" seems fine. I do agree that code layout conventions that reduce the usable vertical space are questionable; scrolling sucks.
I didn't especially like SML (or Ocaml) syntax, but they're both solid languages.
http://www.smlnj.org/dist/working/index.html seems to contradict the story by Mythryl's author that SML/NJ isn't maintained. His fork doesn't seem to do 64-bit, while SML/NJ does.
I'd be interested in hearing more about the reason this project is not just a set of libraries for SML/NJ. I guess the author has strong opinions about syntax and didn't like ML's.
end
end
end
end
The two line = { is only for compound functions; a single expression with a "where" seems fine. I do agree that code layout conventions that reduce the usable vertical space are questionable; scrolling sucks.
I didn't especially like SML (or Ocaml) syntax, but they're both solid languages.
http://www.smlnj.org/dist/working/index.html seems to contradict the story by Mythryl's author that SML/NJ isn't maintained. His fork doesn't seem to do 64-bit, while SML/NJ does.
I'd be interested in hearing more about the reason this project is not just a set of libraries for SML/NJ. I guess the author has strong opinions about syntax and didn't like ML's.
[deleted]
"fi" and "esac" come from shell programming. He's copying various style/syntax elements (including ugly bits!) from sh and C in hopes that it will be less off-putting to mainstream programmers than ML syntax.
The problem with having a built-in object system is that you're stuck with it. People mean very, very different things by OOP, and being able to add an OO system when it's useful is probably a better approach. Using OO without "bolting it on" works well for the Lisp family and for Lua. (Adding a prototype-based, class-based, or message-passing object system with via metatables is quite easy.) You just need to have a sufficiently flexible core language.
Of course, doing it in a fully static-typing-safe manner is tricky, but since OO is arguably defined by late binding, that's naturally works against pinning as much as possible down at compile time. (Lisp and Lua are just dynamic and don't worry about it.)
The problem with having a built-in object system is that you're stuck with it. People mean very, very different things by OOP, and being able to add an OO system when it's useful is probably a better approach. Using OO without "bolting it on" works well for the Lisp family and for Lua. (Adding a prototype-based, class-based, or message-passing object system with via metatables is quite easy.) You just need to have a sufficiently flexible core language.
Of course, doing it in a fully static-typing-safe manner is tricky, but since OO is arguably defined by late binding, that's naturally works against pinning as much as possible down at compile time. (Lisp and Lua are just dynamic and don't worry about it.)
Aren't "fi" and "esac" from Algol?
Site is running really slow now, but the wikipedia article provides a quick taste. http://en.wikipedia.org/wiki/Mythryl
C++, Java, Python, Perl, Php and Ruby are all based on software technology dating back to 1972. Switching from one of them to Mythryl means leaping forward thirty years to thoroughly modern technology, yielding a quantum jump in expressiveness and flexibility.
Robin Milner started working on ML around 1973-1974. Finished by 1978. So it's a 6 year leap at best.
Robin Milner started working on ML around 1973-1974. Finished by 1978. So it's a 6 year leap at best.
"Mythryl is currently supported only on 32-bit x86 Linux."
It sounds cool, but bootstrapping elsewhere would probably be a huge pain. (I port stuff, and generally work on 64-bit AMD OpenBSD.)
Too bad, really - I would love to see a more "mainstream" dialect of ML than OCaml.
It sounds cool, but bootstrapping elsewhere would probably be a huge pain. (I port stuff, and generally work on 64-bit AMD OpenBSD.)
Too bad, really - I would love to see a more "mainstream" dialect of ML than OCaml.
What would you say prevents OCaml becoming more mainstream?
F# gets the full backing of the world's biggest software vendor in VS 2010...
F# gets the full backing of the world's biggest software vendor in VS 2010...
1. Lack of documentation. While there is some documentation on the web (and the free translation of the O'Reilly book is quite good), it's probably too little, too late. There are very few books published in English, and one of the most accessible of them (Practical OCaml by Joshua Smith) is IMHO one of the most poorly-written programming books I have ever seen.
2. Haskell seems to be getting most of the attention in that niche. (This is arguably the biggest factor.) Its community is somewhat small, and it doesn't have the general presence, marketing, word-of-mouth, etc. that Haskell does, and it had years and years to do so.
3. There are lots of cases in the OCaml implementation where they could have made it much, much more friendly to people trying to learn its typing, but didn't. ("Error: This expression has type t but is here used with type t" is baffling.) The exception system has a lot of rough edges, too - Debugging a program throwing the exception of "Not_found" without any context provided is rather irritating.
4. It cuts more than a few usability corners for sake of pure speed. Some people consider this a feature, but I don't like it as a default.
5. Its support for concurrency is not great (though this may have gotten better lately).
OCaml is one of my favorite languages, but there are a lot of ways it could be made nicer. While I don't use the .NET languages, it's at least reassuring to see that other languages are using the good ideas from the ML family.
2. Haskell seems to be getting most of the attention in that niche. (This is arguably the biggest factor.) Its community is somewhat small, and it doesn't have the general presence, marketing, word-of-mouth, etc. that Haskell does, and it had years and years to do so.
3. There are lots of cases in the OCaml implementation where they could have made it much, much more friendly to people trying to learn its typing, but didn't. ("Error: This expression has type t but is here used with type t" is baffling.) The exception system has a lot of rough edges, too - Debugging a program throwing the exception of "Not_found" without any context provided is rather irritating.
4. It cuts more than a few usability corners for sake of pure speed. Some people consider this a feature, but I don't like it as a default.
5. Its support for concurrency is not great (though this may have gotten better lately).
OCaml is one of my favorite languages, but there are a lot of ways it could be made nicer. While I don't use the .NET languages, it's at least reassuring to see that other languages are using the good ideas from the ML family.
Ocaml is still making you fork to multiprocess.
I agree that the docs + stdlib aren't great.
But the performance is very good, and the type checker is awesome. I like it (in my experience on toy problems).
You mentioned performance vs. usability - Not_found is vague for a reason; it's the way you find out if a key is in a hashtable (no null or Maybe return). Exceptions without payload are apparently very efficient in Ocaml; they're used often in "non-exceptional" cases in the library.
I agree that the docs + stdlib aren't great.
But the performance is very good, and the type checker is awesome. I like it (in my experience on toy problems).
You mentioned performance vs. usability - Not_found is vague for a reason; it's the way you find out if a key is in a hashtable (no null or Maybe return). Exceptions without payload are apparently very efficient in Ocaml; they're used often in "non-exceptional" cases in the library.
I understand why they do it, but I don't like speed over usability as a default. I would rather be able to tighten up the execution via a few declarations, compiler options, etc., if necessary, but have the default be maximum flexibility, detail for debugging, etc.
I like the typechecker mostly because it's easy to use a few type annotations to do things that would otherwise require loads of unit tests.
My rule of thumb these days is, "Python is fast enough, without proof otherwise."
I like the typechecker mostly because it's easy to use a few type annotations to do things that would otherwise require loads of unit tests.
My rule of thumb these days is, "Python is fast enough, without proof otherwise."
In Mythryl unit becomes Void. The value syntax is unchanged: ()
No! This is a regression into darkness! Unit should stay unit!
According to type theorists: Unit is the data type inhabited with exactly one value (the zero-tuple). That's why it's called "unit". Void is the data type not inhabited with any values. Therefore, a function that typechecks to return type Void never terminates, because there is no value it could return. (The use of "void" in mainstream programming languages corresponds to "unit" in academic settings).
Also, if our notion of "function" is an expression with exactly one argument and one return value (like in lambda calculus), then tuples come in handy as function arguments. Especially the zero-tuple, for functions with side effects that need no input data. Like...
No! This is a regression into darkness! Unit should stay unit!
According to type theorists: Unit is the data type inhabited with exactly one value (the zero-tuple). That's why it's called "unit". Void is the data type not inhabited with any values. Therefore, a function that typechecks to return type Void never terminates, because there is no value it could return. (The use of "void" in mainstream programming languages corresponds to "unit" in academic settings).
Also, if our notion of "function" is an expression with exactly one argument and one return value (like in lambda calculus), then tuples come in handy as function arguments. Especially the zero-tuple, for functions with side effects that need no input data. Like...
exit ()
The ocaml manual has me writing a basic lexer and parser by the end of chapter 1, with minimal cheerleading and condescension. http://caml.inria.fr/pub/docs/manual-ocaml/manual003.html. The mythryl docs had me annoyed after about 10 minutes of clicking around the various different areas trying to figure out the point of the language.
I kind of dig this language. It's enough like C and sh to be easy for just about anyone to pick up, but has some very nice features and a more elegant consistency than most of its cousins.
It's a shame that it's only available on Linux. Anyone tried to get it running on OS X?
It's a shame that it's only available on Linux. Anyone tried to get it running on OS X?
I like the (description of) the language.
I love statically typed functional languages with type inferencing. But look forward a few years. Hasn't F# definitively won, except for people who prefer Java libraries (Scala), and people who like lazy computation and/or extreme purity (Haskell)?
Yes, F# performance in Mono is bad right now. But there's no reason the language itself can't be implemented (perhaps as a skin on top of the Ocaml code base - or does the license not permit it?)
The size of a language community does matter. It's not "most popular 1-3 in each niche live, others die" but "15 years from now, will it still exist, or will the 1-3 hardcore hackers have moved on?"
I love statically typed functional languages with type inferencing. But look forward a few years. Hasn't F# definitively won, except for people who prefer Java libraries (Scala), and people who like lazy computation and/or extreme purity (Haskell)?
Yes, F# performance in Mono is bad right now. But there's no reason the language itself can't be implemented (perhaps as a skin on top of the Ocaml code base - or does the license not permit it?)
The size of a language community does matter. It's not "most popular 1-3 in each niche live, others die" but "15 years from now, will it still exist, or will the 1-3 hardcore hackers have moved on?"
Seems like a pretty nice language, though it's basically just syntactic sugar for ML. (Not such a bad thing; syntactic sugar is tasty, and I can understand not liking ML syntax much.)
I'm a bit put off by the way the documentation repeatedly says "continuation" where it means "closure".
I'm a bit put off by the way the documentation repeatedly says "continuation" where it means "closure".
I spent the first four years of this millennium doing eighty-hour weeks at a [...] division internally famous for producing more revenue per employee than the IRS.
Man ... how do I get a job like that?! I really want that job!
Man ... how do I get a job like that?! I really want that job!
[deleted]
Not sure if this is the reddit (et. al.) effect, but man that site is sllllloooowwwww for me.
When complaining about "the effect" on a news aggregation site it's customary to refer to it by the name of said site. So here it is called "The HN effect." Nevermind the absurdity of this name, on account of HN's (thankfully) small community size. It's just polite. If you MUST refer to "the effect" by any other name, give credit to the historical originator: It's called "The Slashdot Effect." Not Digg, and certainly not reddit.
(Actually I'm not sure Slashdot was the first, though I was aware of "slashdotting" as a verb more than 10 years ago. Anyone know of predating claim to "the effect" by another site?")
(Actually I'm not sure Slashdot was the first, though I was aware of "slashdotting" as a verb more than 10 years ago. Anyone know of predating claim to "the effect" by another site?")
Before being condescending, you should check to see if there is a valid claim to the reddit effect:
http://www.reddit.com/r/programming/comments/906yc/mythryl_p...
I'm not sure what your post added to the discussion, but his alerted other people that the problem wasn't on their side, and it also stated that there was a discussion on reddit.
http://www.reddit.com/r/programming/comments/906yc/mythryl_p...
I'm not sure what your post added to the discussion, but his alerted other people that the problem wasn't on their side, and it also stated that there was a discussion on reddit.
My apologies; I figured the "et. al." would have covered that.
http://mythryl.org/book153.html
And for the code examples:
http://mythryl.org/book117.html
It looks like they've put a familiar, scriptish, face on an old gladiator. SML/NJ has more academic street cred than any other compiler that I know of. It did for the compiler research of FPLs what the Fortran H compiler did for procedural languages on pipelined architectures. It has been hacked on by the who's who of compiler research groups; Princeton, Stanford, UT Austin, etc. (thank god CMU had better things to do, staying a Lisp shop ;-)
P.S. Dr. Norman Ramsey, I know you read Reddit but I am not sure if you come here; old man, you turned me to FPLs in 1998 with your original "hacker challenge" :-) I stumbled upon your site looking for blackhat "hacking" materials and ended up writing a linker a month later because I stayed and read your papers.