1,085 karma · joined July 19, 2010
Support for GUI toolkits will probably require some glue code. I've heard that Windows is a particular source of headaches, but I'm not clear as to why. SDL seems to work everywhere; remember that Rust is designed for seamless C interop in both directions.
You have to eat to live. You have to pay to eat. Tricking people out of more money than they can afford, with no regard for how it might harm their lives, is negligence comparable in quality (though obviously not severity by degree) to firing a gun randomly in the dark.
There is a quantitative difference between running over one homeless person while speeding and running over a hundred people every day for a year. Yet both are illegal, for the same reason.
I'm afraid that hasn't been true for a number of years. Turn on the optimizer and the resulting assembly can be totally unrecognizable as a translation of what you actually wrote. The compiler takes all kinds of steps both to eliminate redundant operations (via CSE, loop unrolling, etc.) and to take advantage of the weird quirks of modern CPU architectures, like out-of-order execution.
It does, actually:
> And this is what they wanted to remove because they wanted static allocation of procedure activation records.
A stack frame is a dynamically allocated procedure activation record, but we no longer call them that because it's seen as absurd that they would be statically allocated.
---
[1]: http://www.ifwiki.org/index.php/FAQ
[2]: http://www.mspaintadventures.com/ (NB. Homestuck is the fourth adventure comic by this particular author. It's on hiatus while he writes and animates the last few chapters.)
I can think of a couple obvious reasons why they would take this approach: (1) Crypto is hard, and they want to get the core platform out the door in a usable form on a relatively tight schedule. (2) Designating an official Rust crypto solution would be a social statement about what crypto code you're supposed to use in Rust, even if the quality of the code itself is inferior due to being newly written and unvetted. This is riskier than just using existing C libraries, because at least now they can't be blamed for any horrible security bugs in libraries they didn't write.
If you'd only read past the specific sentence you quoted, you'd see that they do have plans to build crypto solutions in Rust, but that they're taking an extremely conservative approach to making it happen, and developing it "out of tree," ie. not as part of the Rust language codebase. Moving conservatively with respect to crypto development is not inappropriate. I'm sure you understand the sensitive nature of crypto libraries and why they need to be treated with as much care as possible.
In principle there's no longer any reason why it has to work this way, because now we have shaders. These are a more domain-specific tool than a C API, and can thus safely present large cross-sections of graphics card functionality in a higher-level way without taking power away from the graphics programmer. So, for example, people modding Minecraft can introduce their own visual effects stages by hotloading shaders into the standard Minecraft graphics pipeline.
EDIT: I haven't talked about performance. For game developers, rendering a frame quickly is as important as having total control over the output of the rendering process. For the most part, building an API higher-level than OpenGL also means dictating a particular scene graph structure, as with OS-specific window system APIs. If the API imposes a certain way of organizing your scene graph, this can have serious impacts on your game's performance, because the scene graph traversal is optimized for one type of scene and you're using it for another. I'm not sure I'm simplifying this explanation very well, but that's the gist of it.
Here's an example of a type definition that specifies strict evaluation https://github.com/vincenthz/hs-tls/blob/master/core/Network...
See? They don't have to switch languages after all.
Because Markdown doesn't cover everything, and because there are other sets of semantic markup conventions used in a plain text setting, there's certainly room for "Markdown-likes" which attempt to replicate the same kind of effort with those other conventions in mind. For example, Fountain[1] is a language for writing screenplays, and its conventions are a fairly close (though not as close as possible) approximation of the same ones used in real screenplays.
I've never authored a manuscript for a book, so I don't know myself whether such conventions for things like tables of contents exist in the publishing world. But I have a feeling that if they do, they wouldn't look like this. What UBook actually reminds me of is troff/nroff macro syntax[2], which was developed for a similar purpose and is still in use today as the lingua franca of Unix manpages.
You've implied in other comment threads that you don't really intend this for writers to use directly. If this were to be the output of a more user-friendly writing tool, I'm curious what such a tool might look like, and how it could differ from existing WYSIWYG rich text editors (where everything looks like a nail and your hammers are labeled "bold" and "bigger font"). For example, how would you represent section and paragraph structure in an editable way without the use of inline control characters that you edit the same way as other text? I don't think I've ever seen an editor built that way, but if that's what you're going for, I look forward to it.
[1]: http://fountain.io/
That's exactly what it's like, and the worst thing (in my opinion) is how it has spread to every facet of American life, so that arguments over factual information are seen the same way. The country as a whole is far more concerned with winning or losing than with the actual significance of the "field" on which their "team" is "playing."
Mind you, given how central sports is to American lifestyles[1], it's not like nobody could have seen this coming. But that doesn't reduce how dangerous it is.
[1] Walk into any American high school. Chances are, the walls are lined with football trophies, and the faculty's letterhead is plastered with logos for the resident teams. The social hierarchy of the students revolves around the star players. Outcasts are called "losers."
Haskell's reputation exaggerates how this API was less powerful, or missing altogether, in early versions of the language. But its reputation is not what you write programs in.
What I'm saying is that untrained users have trouble with the idea, fundamental to markup languages, that some text can represent attributes of other text. To such users, an asterisk means "the text has an asterisk in it." They cannot reinterpret asterisks as markup without relearning the way they look at text itself. They're used to having the territory laid out in front of them, and all of a sudden you're handing them one map and asking them to write another, but they don't know what a map is.
The problem for a lot of users is the disconnect between a logical style (the actual boldness of the text) and representations of that style. If you haven't learned to handle this kind of abstract symbolism, plain text markup formats just don't make sense to you. Your brain instead registers it as a combination of "this editor doesn't have bold for some reason" and "the computer garbled my copy and made parts of it bold for some reason" without ever drawing the connection between one and the other.
This is only really an issue in places where abstract thought is seen as an innate ability which can only be tested for and not taught to people. Unfortunately this includes the US.
I could see the EU implementing it as part of its ongoing privacy/transparency efforts, but I doubt the US Congress would be of any help.
- The "random" groups don't look random at all to me. More like there's a series of "standing" characters left behind by the light-green leader, and behind that there's a stream of "running" characters advancing at a different rate. We only see the running characters through gaps in the standing characters, and only in cells that the leader has already visited.
See also: Radio and television.
The rationalization most moviegoers would use is one of legitimacy. Many people see film as the only "serious" medium for storytelling (live action TV is too cheap, books are too academic) and categorically dismiss newer media (video games, comics, etc.) as having no cultural value whatsoever. Thus, a good story is not actually good until it's a movie.
Hollywood loves this attitude and may be entirely to blame for it. It's hard to tell how many studio execs actually think this way though. I get the impression there are also a lot of people in Hollywood who don't believe in the concept of art.
Some quick reading on the phenomenon: http://en.wikipedia.org/wiki/Saccade
The difference between Vim and the original vi is pretty huge. Just as an Emacs user might be stymied by the missing Lisp support in uemacs or zile, a habitual Vim user leans on stuff like text objects and visual selections, which were never even a twinkle in Bill Joy's eye.
main = interact id
I would explain further and implement more than what the blog post suggested but there's already a book (Real World Haskell) that does this with a number of other Unix commands.
Long answer: One of the conditions for contributing code to the GNU project is assigning copyright to the FSF. That means they're legally the sole copyright holders for all software they distribute. The official reason for this is so they can pursue GPL violations in court without involving the actual authors of the code. It also permits them to change the license on any of their software. Finally, there are various reasons they might be able to do this anyway even if they didn't have the copyright assignment rule, so long as the new restrictions didn't conflict with whatever license the original software was distributed under.