I didn't notice this initially, but it seems when the following line runs:directoryMove = do computername <- readfile "computername.config" sudo_ "mv" ["/home", "/home." `T.append` computername]
Instead of making a directory called home.computername, it makes a directory called home.computername? and this is not what I want. Computername.config contains the appropriate values so I'm sort of stumped. There's nothing in either file that contains a question mark and this line isn't dependent on any other lines...any ideas?submitted by scd250
[link] [11 comments]
One of the main reasons for choosing an inferior programming language is the existence of libraries in that language. The prototypical example is C. Will this consideration continue to be an issue forever? Or will tools for translating between languages, or tools to link to libraries written in different languages, become a lot better?
It is a difficult problem because of considerable "impedance mismatch" of execution models (and data models) between different languages: Haskell and its non-strict evaluation, or the many ways different languages and frameworks handle concurrency and multithreading.
Recently Microsoft updated the design of its Dynamics CRM to a “flat” look. Since then, we can’t figure out what is clickable or editable, and what is just content.
My plea to designers: make that clickable thingy look clickable. Make that editable input box look like an input box, and not just when I hover over it.
Buttons and interface widgets, when present, need to be easily distinguishable from content. They need to have good affordances that invite users to action. In the absence of strong signifiers, they can get ignored, and users may find themselves lost and disoriented.
Not all “flat” design has indistinguishable chrome from content, as pointed out in the above article.
BTW, I did not put the ads. WordPress.com told me: “Occasionally, some of your visitors may see an advertisement here.”
I have a new assignment at work and now find myself at yet another Windows shop. They are making embedded systems, but have for some strange reason decided that Windows is the only development platform to use. After only a few weeks here I’m noting a growing irritation with the tools offered for my use. The amount of forced mouse usage is astounding and the main tool, Visual Studio, is turning out to be the main culprit. After a week or so of exposure to VS I’ve found what I consider to be a serious flaw with a tool for developers: it doesn’t scale.
- No hierarchical structure It doesn’t scale very well with the size of a project. The concept of having a solution with a number of projects is not bad. But the implementation doesn’t scale. A project can’t have sub-projects, which means I can’t really layer the code in the IDE in the same way I do on disk. The only thing I can do is organise viewing of files through the concept of filters.
- All configuration is manual, part 1 MS seems to have optimised for small projects. All configuration is kept in XML files, and the only interface to them is a set of property dialogues (some which can be resized, others not) requiring an amazing amount of pointing and clicking to get anything done.
- All configuration is manual, part 2 MS have optimised for beginning new projects. Getting started is amazingly quick, but once you reach a size of about 10 projects it becomes daunting to fix anything that requires configuration in all projects. Making sure that all configurations are correct is a major undertaking, and requires an insane amount using the mouse. Some earlier versions of VS seem to even have made it impossible to edit the common settings of configurations properly; a simple mistake and the value of one configuration is lost.
- Experience There are no shortcuts to discover. The configuration is all in XML, which means it’s not really possible to jump out of VS and use a text editor for fixing up semi-broken configurations (like dealing with someone’s decision to place all intermediate files and final results in the top-level solution directory).
So, how do Windows developers cope with this? Don’t they use VS? Do they police the configurations diligently to ensure no silliness creeps in? Or are they all using tools to address these points (like CMake)?
FP Complete™ is excited to announce we are now offering a free community edition of FP Haskell Center™. To get it, all you need to do is login. Instantly you can start learning, developing and sharing Haskell code. Within the IDE you can open projects directly from Git, or the web. The free subscription also includes continuous display of type and error information and type autocompletion, Hoogle and Haddock integration, an easy to use build system, easy to understand error messages as well as vetted and stable libraries. By providing this free edition of FP Haskell Center, FP Complete is making it easier than ever to explore and share the benefits of Haskell.
For Haskell developers seeking more features like the ability to push projects to Git and GitHub, full Git integration, or access to a private repository, you can upgrade to our Personal edition for $9.99 a month. If you are a commercial developer of Haskell we offer a Professional edition starting at $75 a month which includes shared team accounts, support for sub projects, FP Application Server™ access, multiple repository projects as well as a commercial use license. Feel free to try a paid edition for 30 days for free before you buy.2.2 Feature Upgrades
With our most recent round of upgrades we have made FP Haskell Center more accessible than ever and interaction within the IDE even more responsive.
In addition to providing a free edition of FP Haskell Center, we’ve also streamlined the registration process to make account generation easier. We’ve added a one-click project cloning capability to make the sharing of your projects from your personal blogs even easier. From the IDE, once you’re ready to share a project, all you need to do is select the social media outlet you’d like to post to and you can instantly link to your project for feedback and collaboration.Within the School of Haskell, you now have the ability to embed YouTube videos into tutorials giving you the opportunity to make tutorials even more dynamic. To further integrate the School of Haskell with our IDE, we’ve made it so you can open active code from tutorials directly in the IDE. Now you can externally open a project into FP Haskell Center with /ide route: ?git for git cloning, ?paste for lpaste integration, or you could open a new, empty project.
To make interaction within the IDE more responsive we’ve added:
- Search/replace in editor
- Code search/grep
- Subexpression type information lookup
- Better error handling, Faster save/error message results
As always, we look forward to your feedback. Our goal is to make FP Haskell Center an invaluable resource for you. If there is a feature you’d like to see added, don’t hesitate to reach out to us. Leave a comment here or email us at email@example.com
In part 1 of this tutorial we talked about types and kinds. Knowledge of kinds will help to orient yourself in today's discussion of monads.
What is a monad? When you type "monad" into Hayoo the first result takes you to the documentation for the type class Monad. If you don't already have a basic familiarity with type classes, you can think of a type class as roughly equivalent to a Java interface. A type class defines a set of functions involving a certain data type. When a data type defines all the functions required by the type class, we say that it is an instance of that type class. When a type Foo is an instance of the Monad type class, you'll commonly hear people say "Foo is a monad". Here is a version of the Monad type class.class Monad m where return :: a -> m a (=<<) :: (a -> m b) -> m a -> m b
(Note: If you're the untrusting type and looked up the real definition to verify that mine is accurate, you'll find that my version is slightly different. Don't worry about that right now. I did it intentionally, and there is a method to my madness.)
This basically says that in order for a data type to be an instance of the Monad type class, it has to define the two functions return and (=<<) (pronounced "bind") that have the above type signatures. What do these type signatures tell us? Let's look at return first. We see that it returns a value of type m a. This tells us that m has the kind signature m :: * -> *. So whenever we hear someone say "Foo is a monad" we immediately know that Foo :: * -> *.
In part 1, you probably got tired of me emphasizing that a type is a context. When we look at return and bind, this starts to make more sense. The type m a is just the type a in the context m. The type signature return :: a -> m a tells us that the return function takes a plain value a and puts that value into the context m. So when we say something is a monad, we immediately know that we have a function called return that lets us put arbitrary other values into that context.
Now, what about bind? It looks much more complicated and scary, but it's really pretty simple. To see this, let's get rid of all the m's in the type signature. Here's the before and after.before :: (a -> m b) -> m a -> m b after :: (a -> b) -> a -> b
The type signature for after might look familiar. It's exactly the same as the type signature for the ($) function! If you're not familiar with it, Haskell's $ function is just syntax sugar for function application. (f $ a) is exactly the same as (f a). It applies the function f to its argument a. It is useful because it has very low precedence and is right associative, so it is a nice syntax sugar that allows us to eliminate parenthesis in certain situations. When you realize that (=<<) is roughly analogous to the concept of function application (modulo the addition of a context m), it suddenly makes a lot more sense.
So now what happens when we look at bind's type signature with the m's back in? (f =<< k) applies the function f to the value k. However, the crucial point is that k is a value wrapped in the context m, but f's parameter is an unwrapped value a. From this we see that the bind function's main purpose is to pull a value out of the context m and apply the function f, which does some computation, and returns the result back in the context m again.
The monad type class does not provide any mechanism for unconditionally pulling a value out of the context. The only way to get access to the unwrapped value is with the bind function, but bind does this in a controlled way and requires the function to wrap things up again before the result is returned. This behavior, enabled by Haskell's strong static type system, provides complete control over side effects and mutability.
Some monads do provide a way to get a value out of the context, but the choice of whether to do so is completely up to the author of said monad. It is not something inherent in the concept of a monad.
Monads wouldn't be very fun to use if all you had was return, bind, and derived functions. To make them more usable, Haskell has a special syntax called "do notation". The basic idea behind do notation is that there's a bind between every line, and you can do a <- func to unwrap the return value of func and make it available to later lines with the identifier 'a'.
In summary, a monad is a certain type of context that provides two things: a way to put things into the context, and function application within the context. There is no way to get things out. To get things out, you have to use bind to take yourself into the context. Once you have these two operations, there are lots of other more complicated operations built on the basic primitives that are provided by the API. Much of this is provided in Control.Monad. You probably won't learn all this stuff in a day. Just dive in and use these concepts in real code. Eventually you'll find that the patterns are sinking in and becoming clearer.
According to the German news page “heisse news”, the Debian Technical Committee has made a decision on the question about the default init system in Debian: There will be none!
Instead, according to Ian “Vorlon” Bart, Debian will start to distribute a suspend-to-disk image to their users, with all daemons already started, completely eradicating the need for an init system. If you are able to read German, read all about it at Debian Technical Committee entscheidet sich gegen ein Init-System