What? You literally just call emacs --daemon on startup. You can also easily kill it and restart it.
1,207 karma · joined November 23, 2012
> It's not immediately clear to me how e.g. throttle is implemented, but it must accumulate state inside it somehow in order to replay the event after the timer.
Certainly, a lot of FRP (and functional programming in general!) concepts involve state. I would never argue that there is no state in functional programming, just that the state is more explicit, localized, and easier to reason about.
In fact, in pure FRP, there are two fundamental building blocks: Behavior and Event. A Behavior is simply a value over time, and an Event is a value at an instant in time. Therefore, Behaviors are where you store state. However, what makes them "easier to reason about" is that oftentimes the API forces you to construct them in a way that makes all of the possible ways to change the Behavior are clear and present at once.
In summary, all inherently stateful concepts require stateful code, at lease somewhere under the hood. I would say that FRP and functional programming just make the state explicit.
We didn't have a problem paying for college in the US until everyone decided that the government should help pay for it. Throwing more money at the problem won't fix it; in fact, it's been a huge part of the problem!
As opposed to the ability for the state to foolishly harm us? Sure, a free market allows humans to be human and make mistakes, but allowing others to take your freedom in the interest of self-preservation is a fool's compromise.
Certainly, you raise great philosophical questions though. One of my favorite thought experiments is to imagine how many things done by the government today could be accomplished without the government. I don't mean obvious things like the postal service, I mean fundamental services like road building and a court system. I plan to read David Friedman's book soon on this topic, called "Legal Systems Very Different From Ours":
http://www.daviddfriedman.com/Academic/Course_Pages/legal_sy...
We live in such a highly regulated world that I can't help but chuckle when someone blames the "free market" for many of the problems of today.
In every language I've used, the default is for a "rand" function to return random floats between 0 and 1, and given arguments it returns floats between the arguments. I don't think it has to do with learning Julia, it is just that including "integer" in the function name makes it clear the function returns integers.
> This is why I think the Julia approach is better. If I write `a == 7`, am I testing whether `a` is 7 or whether any of the elements of `a` are 7?
I think this is more of a comment about mixing arrays and scalars in a dynamic language. I made my comment assuming you are performing operations on arrays. If you are comparing two arrays, I think the default of element-wise operations makes more sense.
a = np.random.randint(-100, 100, size=100)
a[(a & 2 == 0) & (a > 0)]
I think this is clearer than your Julia example because:
- The numpy version makes it clear that you are using random integers, not floating point values.
- The keyword argument for "size" makes it clear what that second 100 is for. (The use of the first two numbers, -100 and 100, is pretty clear from context.)
- In numpy, most operations are element-wise by default, because the result would be ambiguous or not useful otherwise. This removes the line noise of the extra "." before operations.
Don't get me wrong, I think Julia is awesome. I just think you've constructed a very poor example for numpy.
I agree with the core idea of this quote: don't take people's money and run away, especially if you led them to believe you will support a paid product for a long time.
However, I wouldn't say that supporting every paid product you make is a moral obligation. Just because a couple of people paid you $20 doesn't mean you should force yourself to spend your valuable time improving and maintaining the product if you no longer benefit (through joy or money). Certainly, you shouldn't defraud people and lead them to believe you will maintain a product for a long time, but this kind of blanket statement might scare away people from trying to create a paid service because of the fear of having to perpetually support a handful of users.
Again, I agree with the principle in particular cases, but there are cases where it doesn't apply (at least in my opinion).
Thanks for the writeup!
To anyone else who uses nixops, why does nixops use this state file? Can't they use labels like Ansible to identify deployed machines? Can't you just require the user to provide their own secrets instead of auto-generating a new keypair for each machine?
* It is plain text, so you can keep your data in version control.
* It has awesome reporting capabilities. These are builtin, so you don't have to create them from scratch.
Spreadsheets are nice and simple, but once you do anything moderately complex you are asking for bugs under all of your hidden formulas.
We would like to hire someone full-time, but if you are unsure about committing to the company, we would be fine starting off with a short contract period of a few months.
Work Environment
We highly value self-directed individuals who also have a thirst for learning. In fact, we strongly encourage our team to take time to learn new things to do their job more effectively. We understand that trying to force productivity out of people creates unhappy workers and leads to technical debt. We strive to meet deadlines early and often so we can have breathing room to test new ideas or refactor existing ones.
Remote
Remote is OK if you have experience working remotely; we just might want you in Riverside a few times a year. All of our 3 person team lives in Riverside, but we are always happy to accommodate a remote position if it means we can get the best talent. We use version control, continuous integration, and are very comfortable communicating ideas/issues online.
Apply!
If interested, contact me directly at my email: john.reaver@frackoptima.com. Please attach a resume as well.
My email: john.reaver@frackoptima.com
About Us
FrackOptima is a startup in the petroleum industry that aims to make hydraulic fracturing safer and more efficient through industry-leading simulation software. We are currently a small, 3-person team based in Riverside, CA, but we are already in the middle of a few development contracts with some very large companies, including Shell Oil Company. We get requests every week from other companies who want to use our software, but sometimes we have to turn them away because we simply need more manpower!
Position
We are looking for someone with extensive desktop GUI and graphics programming experience to help us refactor and improve our user interface. Our software is currently being used by dozens of researchers across a few large companies, and we need your help to build the next generation UI by using feedback from our existing customers and your experience.
Required skills/attributes:
- Experience with a large GUI codebase (using Qt is a plus since we use PyQt/PySide)
- Experience with Python (C++ is great too, especially if you used Qt)
- Self-directed and a thirst for learning
- Very effective communicator, especially if you are working remotely
Desired skills/attributes:
- Experience leading the development of or architecting a large user-facing application
- Experience in scientific programming
- Engineering experience or an interest in applied physics (we use solid mechanics, fluid mechanics, heat transfer, various numerical methods for a tightly coupled simulation).
- A technical degree. Having a non-CS technical degree is perfectly fine. In fact, all three current team members have either an MS or PhD in mechanical engineering!
- Extensive graphics programming experience
Some people make software for fun, or to help others. If my software helps someone make millions, then cool, good for them. Personally, I would certainly monetize free software I made if I saw the opportunity. However, some people might already be wealthy and want to play with their kids or something instead of chasing a new startup opportunity, so they shouldn't care if someone else makes millions off of their software. You are acting very arrogant when you assume everyone's values line up with yours.
* I can keep arbitrary asset, liability, and expense categories in a tree-like structure.
* I can split up transactions between different accounts. This is useful because I can split a dinner bill between my credit card and cash. It is also useful because I can split items from a large Amazon order into their respective categories.
* The ledger file is a very simple text file, so I can keep it in version control.
* I haven't taken advantage of the report features yet, but they look very flexible. You can add up any accounts you want based on regular expressions.
* You can have "virtual" accounts that can be used for budgets. For example, you can set aside arbitrary chunks of your savings account for different purposes and keep track of them separately, even though they all actually reside in your savings account at your bank.
I will take a look a hinance to see how it could be useful for me!
I didn't say that. Killing someone is irreversible, so the error rate better be extremely low, or you just shouldn't do it. I understand that justice can't be perfect.
A project I have been wanting to start is to use Qt as a substrate for a (functional) reactive programming framework in Haskell or Python. The Haskell lib could be based on any current FRP implementation, and the Python lib could be based on RxPY [1].
One thing I would change in Qt would be the Model/View system. I try to use a strict Model-View-Presenter approach, but since we have millions of rows in our tables we have to use Qt's Models/Views instead of controlling all view behavior ourselves. It would be nice to have performant views easily while using a different API, instead of being forced to use the QAbstractItemModel API.
Congrats Qt project, and thanks for the hard work!
I also find it curious that he comments on big pharma already having access to abundant supplies of opium, but it would be disaster if local producers could produce morphine or heroine. God forbid anyone else undercuts them with a cheaper-to-produce product.
Any talk of how to better fight the drug war is just rearranging the deck chairs on the titanic. Drug use is a medical and social issue, not a criminal one. The attitude of drugs as a criminal issue is also one of the reasons the US has the highest incarceration rate in the world. I am frankly tired of being fed the notion that the existence of drugs is a constant danger to society, and the only way out is to fight a never-ending war.
I think they are trying to eventually become independent. I think of this as a kind of bootstrapping procedure, where they start off inside the waters of a nation, and eventually move into international waters once they are established. Indeed, staying inside a nation's waters indefinitely would be counter to their stated goals.
If these ships are movable, then one advantage over a land-based city is they could even change nations when they felt like it.
Arguing against government services while still using them is not in any way hypocritical, precisely because you have already paid for those services with taxes. For example, I am not a fan of social security and how it is managed, but you can be damn sure I will use it once I reach the required age, because I have already paid for it. I will be trying to get the money that was taken from me back.
I think socialized medicine is a huge, clunky band-aid on top of a broken healthcare system already made worse by government intervention, but I won't stop going into hospitals if the US adopted a fully socialized healthcare system.