Ixiaus

> Have any numbers to back up this assertion...

Nope, just anecdata (based on being a startup in the IoT space).

> Amazon does not have tight enough control over its smart home ecosystem...

I don't know that for sure, TBH, though I think the more open and universal platform will win. Currently the Echo is that, it's not an app you have to launch from your phone (Revolv), you just talk to it, and it does things for you.

Echo's superbowl ad also catapulted it, we have emails from people left and right asking for Echo integration (not Apple TV integration).

Also, why would the customer blame Amazon if their bulbs cause a fire? The customer clearly bought the bulbs, then hooked Echo up to the bulb (in the case of Philips Hue), I'm not saying Echo is infallible but I do think your criticism is unfair.

Thanks, we've bled a lot to get this product built :-p If you do want one I can give you a discount coupon (my email is in my profile).

We have a lot of backers waiting on a European compatible version but it's a classic startup story for us: funding is the limitation. It requires a different power board in our product, which we're totally capable of designing, but the cost of maintaining those two versions, the cost and time to certify, and getting the contract manufacturer spun up for it is quite a hurdle in terms of bandwidth and money for us.

I believe we're aiming at building a European version once we've closed our Series A.

Negatory on Apple winning. I think Amazon is much more likely. They're dominating the connected home right now with the Echo; as a developer, integrating the Echo with Plum's Lightpad is extremely easy, I can't do the same thing with Siri.

We don't have a 220v version of the Plum Lightpad, otherwise I would offer to send one to you, but not all "smart" switches are quite as bad as your experience. We've done our best to focus on build quality, security, and usefulness (we do need a neutral though).

Haskell version is naive too.

My laptop runs the original in about 3.07s and my improvements bring it down to 1.20s though I think there's room for improvement.

[EDIT] My improvements were actually not the same algorithm as the original's, with algorithm corrections my version is actually slower!

The other comments have you covered I think but I wanted to reiterate how worth it learning org-mode and spending the time to customize your configuration is. It's a bit daunting at first, so it may take a bit of time and some learning, but it's absolutely worth it.

I use org-mode for my entire GTD workflow (calendar Agenda, next-actions, tickler, maybe, and projects), I use it for capturing quotes or blocks of text that I really want to save for later (my spark notes file), I use it for capturing my "recipes" of anything (software, realizations, food, etc...) in my grimoire file, I use it for capturing notes or thoughts while I'm reading books (with nice capture templates for guiding me through setting the page # and paragraph # in the property drawer), I use it for all of my web bookmarks (I have a bookmarklet integrated in Chrome that auto-fills fields in the capture template for the website), I use it for articles in my To Read list with a Chrome bookmarklet for auto-filling the capture template, AND I use it for my spaced repetition routine with org-drill.

I also use it extensively for work on-top of all the above. I have a capture template for my team's weekly standup meetings, I use it for taking notes during meetings and structuring action plans, etc...

The capture templates, org-protocol for external programs to activate a capture template and pre-fill with data, customized Agenda views (so I get a nice "HUD" for long-running tasks + my 4 day agenda), and refiling (this is one of my favorite parts of org-mode!!!) are absolutely invaluable and an incredible tool for my productivity.

Nothing matches it in breadth and depth, nothing. And as is the case w/ Emacs, you can customize everything to suit your workflow or make tweaks - maybe you have a great idea for improving something! For me I was able to create a highly customized Agenda view specific to my personal deficiencies (I forget about long-running important tasks that aren't a "SOLVE IT TODAY" task).

This as well: http://ivorylang.org/ivory-introduction.html

Yes, that's a good point of clarification, one that the Ivory or Atom DSL is trying to tackle though.

Warning: highly biased opinion incoming.

I came from Python to Erlang / Scheme / Haskell and at this point I would answer your question,

> What kind of things can I build with Haskell?

With: Everything.

We use Haskell in production at Plum for our REST APIs, job schedulers, web applications, AWS service interfaces, a static site compiler, DB modeling, command line utilities, etc...

We also use it for two CLI utilities that are cross-compiled for the ARM9 on our IoT product.

I consider Haskell to be superior to any of the dynamically typed languages when writing production-level code, it's cleaner, safer, easier to maintain, easier to refactor, and much more fun IMHO.

[EDIT] I neglected the other part of your question, "What is the learning flow like?"

Definitely a bit rougher than Python or Ruby, I will not lie, but don't be discouraged. It simply means you need to do a bit more studying up-front first before you can tinker without being caught at every turn by the straight-jacket.

I would first go through Learn You a Haskell because it is pretty accessible and introduces the language basics well enough. Then study the type system. You must learn Haskell's type system and terminology before you can understand more advanced code.

You've clearly been burned in the past and I'm sorry that was your experience. Not all founders, executives, or organizations are like that though. You will always have to grapple with sociology, hierarchy, and power structures but that's a fact of human life - not all are "bad" though.

It's also on you to be clear about what you want and to vet orgs and people. If an org will not share sensitive information with you in order to make a sound decision, then I certainly would not join it. If the leadership won't go to bat for their own people or honor their word, I will not work for them.

Again, there you go with saying I've said something I did not. I never once said you should feel bad for only caring about money, I said if that's all you care about, I would go do something else that's more lucrative and predictable (work in the fintech sector or defense sector, lots of money there).

Your thinking is clearly very black and white, also highly entitled - quite common with engineers. There is no doubt that a product would not exist without the people to build it but an organization would not exist without the people to organize it.

Many roles in the company are invaluable. Not just the engineer.

It sounds like you've had a bad experience and I'm sorry if you have, but not all companies are "pointy haired bosses that take advantage of the underlings".

> Also, what risk?

You clearly have no idea.

> There has never in history of history been easier access to money than now, and never better terms.

You still have no idea. I'm not even going to try.

> Hell, tell a stranger in palo alto you're an MIT dropout, and have a Stanford dropout friend, and they will practically write you a blank check.

This is a pretty offensive statement and you've lost me entirely, your perspective is so far detached from reality that it makes a lot of sense why you're so upset, sarcastic, and frustrated. Instead of a self-righteous attitude, go build your own startup if it really is that easy and low risk.

If you have built your own startup and received a blank check and performed the feat [of building a startup] with no risk to yourself or your peers then I call bullshit or you're just internet trolling.

Sarcasm is a crude tool for communicating your point, it also causes me to have less empathy for you.

> It is rude to lie to people about the value of their options to hire them. ("Your options are 0.866% of the company"). But to try to defend that practice in public is just hilarious.

I never once stated that one should lie to employees about the value of their options. Those conversations are always highly specific to the situation, the negotiated contract with the person, and how fluid the actual current "valuation" is. It's very difficult to pin-point a true value for a set of options in a private company - sometimes you can come close, particularly once major funding events and milestones have been hit, but it is still difficult. I usually do my best to have a candid conversation with prospectives or currents about that value. A lot of founders do.

If all you care about is the financial upside in joining a startup, then I will always say that you should not join one. The risk is very high and it takes an enormous amount of cooperative collaboration from numerous people that are willing to be "in it together" - it also takes many years before you have something valuable enough to make those early options worth it. If you get in before the Series A and you really give it your all and it's a good product that people want and you're surrounded by peers who are the top of their game and you've got excellent leadership: Hang on because it will be a rocket ride. If not, then it might not be worth it.

The other reasons to join a small startup are numerous. In the early stages it's mostly intangible and the later stages are usually very tangible. The "option" for a financial upside is there and should factor into how much risk you're taking as an early employee, but unless that is all you care about then it should not be the only factor in your censure of an organization.

Figure out what's important to you and act accordingly.

> Heh, at least now we know what it does take to be a cofounder :)

Become one. You'll find out. I've been unable to accurately convey it to people it seems; most think it's glamorous. It is not. Most think they're entitled to it. They most likely are not. Most think founders have the upper-hand. Very few ever do (hint: the board and the investors control the strings more than most think).

Most founders go with no pay for quite some time. You can still be a co-founder and receive pay but being a co-founder conveys far more risk and responsibility than being one of the first x employees in the company. Even if you happen to be the person "building pretty much everything", it still does not justify being a co-founder.

If you wish to be a co-founder, you typically have to be willing to take more than 40% pay cut for much longer. You must be willing to defer your paycheck so that your other employees (who are usually on a paycut too) can get paid if funds get tight - this is even expected of most CO employees in the company but the first ones to go are always the founder's. You are usually involved in most fundraising activity in addition to your other duties, whatever they may be* and customer support early on.

The list is quite long, I was once a highly entitled "engineer" until I built a few of my own companies. The dynamics are so much more complicated and tailored to each individual situation that it's disingenuous to lay out blanket statements the way most people in these comment threads have been doing.

Being a founder is brutal.

I'm not saying key engineers aren't entitled to good or fair treatment or that it is impossible to become a co-founder if you're #3 or #4 or #5, but I do not believe you're entitled to founder status just because you're an early hire. Sometimes it can happen that way if you choose to take on those responsibilities and risk and negotiate that dynamic with the other founders - setting up achievement milestones and what-not.

Similarly: Just because you're a founder doesn't mean you're actually entitled to the role of C*O (though you may hold that position early on as it needs to be "filled" it can quickly out-grow you). Some can become those roles and some simply aren't capable of scaling with the needs of the company.

It does not warrant cofounder status at all. So much more goes into being a cofounder than simply being one of the first x employees.

I second org-drill. Org-mode is my whole personal information manager including information learning w/ org-drill.

Seconded on the big backlogs point.

Overall I've been pleased though with the rate of releases for JIRA. It hasn't stagnated like many enterprise offerings.

I know I'm not the OP but John Dewey came to mind when I first read OP's comment. If I really sit down and dig through some of my books I'm sure I could pull up a few more.

As always: depends on the use case.

We're using Erlang as the primary language environment for our IoT product for a lot of reasons but one big one is: Hot code loading and a very robust release upgrade environment with a lot of control over the process (including restarting everything inside the VM if that's what we wish to do).

For our product, a digital light switch / dimmer, high uptime guarantees is a very important requirement and Erlang has it all plus many other wonderful features.

Yes very much to org-drill. It's a huge part of my daily life.

Yes that's us. Android app will definitely come (I'm the Director of Software and I'm an Android user) but it's going to follow the iOS app which is what we're focusing on / nailing down currently.

No because the lightpads themselves are clustered, full-featured Linux machines in the form factor of a switch, they serve that purpose [of a server] within the home so you won't need a server internally at all.

But if you needed any access to the lights from outside the home, you would. In which case you can either colocate one or prop one up on AWS to serve as the remote command bus. Plum provides that right now but I want to, at some point, enable folks to do it themselves.

Or if you really want to, run the server in-house and port forward. That could work too.

Schedules for when and how long to turn a light on, artificially intelligent schedule or scene recommendations based on data from the motion detection sensor (recos first because poltergeist lights are more irritating than your thermostat occasionally thinking you're not home when you are), integration between our led light ring and security products, scenes for different moods triggered via phone or via AppleTV or an alarm clock / schedule, integration with Amazon Echo to control lights, rooms, and scenes via voice; geo-fencing of mobile phone to control lights or scenes based on whether you're coming home or leaving, etc...

This is actually what we're doing at Plum. We're making WiFi and Bluetooth enabled dimmer switches that are running Linux on-top of an ARM9. The primary software for controlling it is written in Erlang and we're using distributed consensus for providing "advanced lighting configuration and control features". Your light switches form a cluster in your own home.

That's the first step (we're trying to launch a product) and ultimately the goal is enabling customers to completely sever the Plum cloud dependency. Right now if you want 100% of the features (schedules, scenes, provisioning, what-not), you have to connect them to the internet, but we want users to have all of the features without any need for Plum's servers. As it stands, about 40% of the features do not require Plum's cloud and actually don't even use it if it's available, so we're working in that direction.

We've also talked about open sourcing a subset of the cloud infrastructure so that users could prop-up their own servers if they really wanted "remote control" of lights (which does matter to people).

Privacy sensitive IoT devices are certainly possible but until more people care about their privacy, it will unfortunately be very niche and a bit of an after-thought to go the extra mile to provide services that can be decoupled from the "smart devices" in the home. Particularly so, considering there's a land grab happening in the IoT space right now and corporations are trying to dominate the home IoT platform.

Humans, in a capitalist society, pretty reliably follow "ask for forgiveness, not permission". Which is interestingly at odds with the more fringe ethical philosophies of free software, privacy respecting software, and generally "ethical" software (that obviously needs explication but I won't go into it here).

His comparison sounded much more like "research languages vs. mainstream imperative languages" and Haskell definitely came from research land, just as Idris and Agda are.

Plus someone is seriously working on dependent types in Haskell - so no, I think it's fitting.

I'm shipping massive amounts of code written in Haskell - production worthy for a real product - and the benefits of using Haskell over any other mainstream imperative language have been fairly significant.

Garbage you say? Dynamodb blazed a trail for many open source, eventually consistent kv databases. Certainly not garbage.

You would be surprised, actually. I think there's quite a bit of work going into BEAMJIT, an LLVM based JIT for Erlang that far exceeds HiPE. I won't argue with you though that the VM could use improvements gleaned from the last ten-fifteen years of implementation and research.

> Probably. But why not spend that effort on the language and libraries?

Because the best Erlang has to offer isn't really in the Language. Some in the Libraries. Most in its VM. I would pick Haskell or ATS over Erlang - unless I need those few unique features that Erlang/OTP really got right.

> That makes as much sense as saying your language shouldn't run on the kitchen-sink Linux so as not to homogenized the OS field.

No, your analogy is moving the goal post. No one ever said someone couldn't implement Erlang the language for the JVM. As many people have pointed out to you, it isn't the language that makes Erlang. It's BEAM + OTP. We're not talking about moving the language around, we're talking about gutting the VM, my statement still holds: Exalting the JVM to be the one-true-VM for Erlang (therefore also implying any language you do not understand well that needs a VM) is a very bad idea and pretty silly.

Diversity is good. BEAM's VM is good. The JVM is good. Even the CLR is pretty amazing (F# beats the pants off of Scala). There's no reason at all to think that Erlang would be better off on the JVM; however, borrowing successful ideas from other awesome and successful technologies? I think that's a swell path to walk. Beware of the kitchen sink, though, is my only warning.

Also, I don't always think OS' are the best place to run your application. There are many arguments for using something like Erlang on Xen or HaLVM if the design requirements can justify it but arguing about your other critical statement should be a different thread.