Front Row Education (https://www.frontrowed.com/) - San Francisco, Fulltime
== Position ==
Early Full-stack web engineer to join fast-growing education startup that changes how hundreds of thousands of kids learn math.
== TL;DR - Reasons to care about working with Front Row ==
A mission you can be proud of: kids using Front Row improve twice as much at math
Tremendous impact on a small team
Flexibility on what you work on, and autonomy over your schedule
Effective & exciting tools: Clojure, Haskell, PostgreSQL, Backbone.js, Ansible
Be part of a growing success: in just over a year after launch, we are in more than 6% of all US schools
== The Business ==
Millions of teachers around the USA are struggling to help 30+ students in their class learn math because every student is in their own place. In a typical fourth grade classroom, there may be students learning to count, students learning to add, students learning to multiply, and students learning how exponents work - and one teacher somehow needs to address all these needs.
Thousands of teachers use Front Row every day to save hours of time and make sure their students are growing quickly. Front Row active users have been growing 100% a month for the past 8 school months.
== The Role ==
As one of our very first engineers, you will be part of a team of developers who are passionate about their vocation, take pride in their craft and who push each other to grow as professionals. You will strive for pragmatism and 80/20 in your work. You will be using tools that provide you with the most leverage and make you most effective. By working really smart, you will produce more than the average developer ever will, but without the crazy hours.
You will work in an effective team that plans, executes and reflects together. Because we’re a small team, everything you create will go into production and be used by students. You will never do unimportant work: every contribution will make a clear and tangible impact on the company’s trajectory. Your personal success will be directly aligned with that of the company.
Most importantly, your work will have purpose: Front Row is a mission-driven company that takes pride in making a significant impact in the lives of hundreds of thousands of students.
== Benefits ==
Generous equity option grants
Medical, Dental, and Vision
Work from home up to 1 day a week, extremely flexible work schedule
Team meal outing every week, and half-day event every month (trip to Sonoma, BBQ, etc)
Flexible, untracked vacation day policy
Working from Runway - one of the best startup coworking locations right in the heart of San Francisco
Get information on how to apply for this position.
The abstracts of recently completed PhDs in functional programming can be published in the Journal of Functional Programming. Simple process, please advertise widely! http://tinyurl.com/jfp-phd-abstractssubmitted by grahamhutton
[link] [2 comments]
This Senior Software Engineer position is with the new LearnSmart team at McGraw-Hill Education's new and growing Research & Development center in Boston's Innovation District.
We make software that helps college students study smarter, earn better grades, and retain more knowledge.
The LearnSmart adaptive engine powers the products in our LearnSmart Advantage suite — LearnSmart, SmartBook, LearnSmart Achieve, LearnSmart Prep, and LearnSmart Labs. These products provide a personalized learning path that continuously adapts course content based on a student’s current knowledge and confidence level.
On our team, you'll get to:
- Move textbooks and learning into the digital era
- Create software used by millions of students
- Advance the state of the art in adaptive learning technology
- Make a real difference in education
If you're interested in functional languages like Scala, Swift, Erlang, Clojure, F#, Lisp, Haskell, and OCaml, then you'll enjoy learning Flow. We don't require that you have previous experience with functional programming, only enthusiasm for learning it. But if you have do some experience with functional languages, so much the better! (On-the-job experience is best, but coursework, personal projects, and open-source contributions count too.)
We require only that you:
- Have a solid grasp of CS fundamentals (languages, algorithms, and data structures)
- Be comfortable moving between multiple programming languages
- Be comfortable with modern software practices: version control (Git), test-driven development, continuous integration, Agile
Get information on how to apply for this position.
Friends of the Functional!
The λheads will be meeting at 19:30 in the Metalab library (Rathausstraße 6, 1010 Wien) as usual.
This time we have a presentation on Swift. And if I have enough time I will present on my current Haskell project.
Hope you are interested in coming. Yours Martin (ε/2)submitted by epsilonhalbe
[link] [1 comment]
Here's something that makes no sense to me. Sometimes after I've run cabal configure and cabal build and everything worked, I got to run cabal install and it wants to download and build some new dependencies -- even though the library I'm installing is already fully built.
Why would this happen?submitted by singpolyma
I'm doing a tutorial exercise for my functional programming course. I'm not entirely sure how to code this...
- (a) Write a function inRange :: Int -> Int -> [Int] -> [Int] to return all numbers in the input list within the range given by the first two arguments (inclusive). For example, inRange 5 10 [1..15] == [5,6,7,8,9,10] Your definition should use a list comprehension, not recursion. (b) Write an equivalent function inRangeRec, using recursion. (c) To confirm the two functions are equivalent, write a test function prop_inRange and run the appropriate QuickCheck test.
An explanation would be awesome. Thank you! :)submitted by el_rais
[link] [11 comments]
Summary: For GHC 7.10, Traversable and Foldable are going to be in the Prelude. I missed the original discussion, but I suspect it's a bad idea.
Types are how Haskell programmers communicate their intentions to each other. Currently, the Haskell Prelude contains:mapM :: Monad m => (a -> m b) -> [a] -> m [b]
Surely that's a good thing? Aren't more general types always better? Isn't the Prelude an archaic beast from the time before? I'd argue functions which are highly polymorphic are hard to use, and hard to think about, especially for beginners. I'd also argue the Prelude is remarkably well designed, not perfect, but quite an impressive feat.
What makes a type signature complex?
I've been thinking recently about what makes type signatures complex, both to practitioners, and to relative beginners. My rough metric is:
- Fully concrete types are usually simple, as long as they aren't too long. The longer a type gets, the more complex it gets.
- Types with functions in them aren't too bad (order-1 types), but as you go up to order-2 types things start to get more complex.
- Fully polymorphic functions can be simpler than concrete functions, since they declare what you don't need to worry about.
- Functions with type classes are more complex, since you need to read the type signature while looking at the context, and need to know each class being used.
- Simple type classes (Eq, Show) aren't too bad, but custom type classes impose more of a burden.
- As you add more type classes, the complexity grows faster than linearly. Three type classes are not three times as complex as one, but quite a bit harder.
- Higher kinded type classes are significantly more complex than kind * type classes, e.g. Monad, Functor. The reason is that instead of having a hole you fill in, you now have a hole which itself has a hole.
- The higher-kinded type classes Monad and Functor aren't as bad as the others, since Functor is really the "simplest" higher-kinded type class, and Monad is required knowledge for IO.
- As you have more higher kinded type classes, the complexity burden grows even worse than for kind * type classes. Two is significantly more complex than one.
By that metric, the old mapM isn't too bad, but the new mapM is quite complex. It has two higher-kinded type classes, and one of them is not one of the common ones. I appreciate that making Foldable and Traversable key to Haskell will probably lead to them being more used, but now all beginners are going to have to wade through the Monad tutorial, their Foldable tutorial and their Traversable tutorial before they start programming (or just give up).
Why generality hurts
There are two main reasons why generality hurts:
Reading type signatures becomes difficult/impossible. We already have that problem with the Control.Arrow module, which (as far as most people use it), is just a pile of tuple combinators. But unlike other tuple combinators, these are ones whose type signature can't be understood. When I want to use &&& or *** I just pick randomly, see if it type checks, then try again. When other people I know what to use these functions they just use an explicit lambda. No one thinks of referring to the documentation, since the documentation presents a unification problem (which most of the people I know could solve), not an intuition.
Reading code becomes difficult. Haskell is brilliant for letting you write a composable pipeline of code that takes some input, does some processing, and produces some output. But that only works if you have enough concrete pieces in each function to read each piece in isolation. As an example:test = foo . mapM baz . bar
Using the current mapM definition I can, in a fraction of a second, know the approximate shape of what foo consumes, and what bar produces. With the new mapM I don't, and have to keep more context in my head to reason about the code.
Who it hurts
Generality of this nature tends to hurt two types of people:
Beginners are hurt because they need to know more concepts just to get going. As a beginner I read through Data.List regularly to build up weapons in my arsenal to attack larger problems. The new Data.List will be generalised, and reading it won't give the insights I enjoyed. Maybe the beginner can instantiate all Foldable things to , but that adds a mental burden to exactly those people who can bear it least.
Practitioners, those who are paid to code for a living, will have greater problems with maintenance. This isn't an unsubstantiated guess... I have taken over a project which made extensive use of the generalised traverse and sequence functions. Yes, the code was concise, but it was read-only, and even then, required me to "trust" that the compiler and libraries snapped together properly.
Who it benefits
The benefit probably comes from those who are already using the Applicative/Traversable classes regularly. For these people, they can probably avoid an import Prelude(). I am not against ever changing the Prelude, but I do think that for changes of this magnitude the ideas should probably be prototyped as a separate package, widely accepted, and only then should significant surgery be attempted on the Prelude. The classy-prelude work has gone in that direction, and I wish them luck, but the significant changes they've already iterated through suggest the design space is quite large.
I realise that I got to this discussion late, perhaps too late to expect my viewpoint to count. But I'd like to leave by reproducing Henning Thielemann's email on the subject:
David Luposchainsky wrote:
+1. I think the Prelude should be a general module of the most commonly
needed functions, which (generalized) folds and traversals are certainly
part of; right now it feels more like a beginner module at times.
It is certainly a kind of beginner module, but that's good. Experts know
how to import. Putting the most general functions into Prelude does not
1. There are often multiple sensible generalizations of a Prelude
2. You have to add more type annotations since types cannot be infered
from the functions.
There is simply no need to change Prelude and all packages that rely on
specific types. Just don't be lazy and import the stuff you need!
I should change my vote to:
seems dead with 504s
edit: it's definitely back up now, nvmsubmitted by Intolerable
[link] [3 comments]