jonnycat

If you want to take this question to the next level (and beyond any current real-world applications), read up on Reversible Computing (https://en.wikipedia.org/wiki/Reversible_computing), which is the concept of performing computation at (near) zero energy cost.

I've used Rails for various products for 10+ years (and plenty of other tools for comparison) and really appreciate it for the productivity, conventions, philosophy, etc. But after spending most of this year with Elixir/Phoenix, I don't think I'll ever go back.

In my opinion, Phoenix competes well with most of the strong points of Rails, and avoids many of the downsides - including the ones discussed in this article. It's also built on a more performant and robust foundation (Erlang/OTP). You may not truly "need" some of those advanced foundation features at first, but at just the same point where a Rails project starts to struggle, Phoenix really shines.

Phoenix is not the solution for every app, but for every app where I would have used Rails in the past, it's looking like Phoenix from now on.

Yes, the advantage is getting the actual IPO price, rather than buying on the open market. For example, BYND IPO'd at $25, but shares hit the open market in the mid $40s (and climbed very quickly into the $60s). That kind of performance is obviously not guaranteed, but is not exactly atypical for hot offerings.

My brokerage (Fidelity) does this for free. But the problem is not knowing about the IPO, it's getting an allocation. As a retail investor, it would seem my position size is not big enough to get any shares. I know this varies by brokerage, so this may or may not be typical of others.

If you could pool together retail investors to increase the possibility of getting shares allocated, that would be something special...

Reading that article and the context of the quote, it appears that Carmack is using that statement to extol the benefits of functional programming styles, not commenting on abstraction.

Refactoring code is a continuum, from "let's do nothing" (0%) to let's rewrite the whole damn thing" (100%). There's a whole spectrum in between.

While I'm a "never say never" kind of guy, I do think many well-intentioned engineers make a leap to the 100% solution too easily. There are lots of other tools in the toolbox that can de-risk the process, like becoming more service oriented, implementing facade patterns, etc., which all in some way or another work towards a "rewrite" usually without ever rewriting everything.

Sometimes you get the benefits of the 100% solution with 25% of the work, and without most of the risk. "Yeah, that part of the codebase is old and crufty, but we never have to touch it because it Just Works and there's no point in rewriting it."

Given the innovation we've seen from some industries in these times, I'm surprised I haven't seen any in dentistry.

I'm probably just naïve about the challenges – or maybe it's happening and I'm just not aware. But I'm surprised my family (3 dental offices between us) hasn't gotten any emails from our dentists selling cleaning kits with elaborate instructions or offering Zoom consultations where they ask the same old questions they'd be asking at a cleaning, planning treatment, etc.

Yes, I realize these things are no replacement for regular cleanings or appointments, but certainly they'd be better than... nothing?

I would add: have a process or framework for evaluating and adopting new technologies. Sometimes new technologies end up as part of the stack through pure momentum (hey, we built this prototype...) rather than deliberate choice. Be mindful of what the technology is being used for and what the costs of changing down the road might be.

One critically important question here I think - has the startup achieved product/market fit, or gotten a strong market signal that you were building the right thing?

If the answer is "no", then the tolerance for bad code goes way up.

Either way, in the early stages of a startup, a great deal of the code will end up being throwaway, and the trick is sometimes knowing which things are important to get right upfront, and which things can be punted on.

Well-defined service boundaries help a lot. This doesn't mean going to microservices, but it does mean keeping things well-isolated and independent even in the same codebase. In effect, you can have "well-architected bad code" which will help you stay flexible even as you move quickly.

The real meat of this post is:

> "No more class, no more worrying about const, no more worrying about memoization (it becomes the caller’s problem, for better or worse)."

By making the memoization the "caller's problem", this refactor has completely changed what the code does, for the sake of calling out "an OO antipattern".

Yes, there are of course other ways to implement some form of memoization or caching without classes. And without knowing the particular use case, it's impossible to form an opinion on whether it should be the caller's responsibility or not. But I find it unconvincing to make an argument for "here's a better way to solve problem X" and then present a solution for solving problem Y.

Like the author, I'm really truly loving Elixir. I recently wrote up some of my experiences with Elixir/Phoenix coming from a Ruby/Rails perspective - https://medium.com/swlh/3-months-with-elixir-phoenix-2810f65....

Curiously, unlike most others here, I'm not completely loving Ecto. I appreciate the philosophy and get changesets, but I'm finding the query syntax clumsy.

I've been building a product for automating the collection and production of customer testimonial & review videos - https://verifiablee.com/

Actually started just pre-pandemic, so the timing has been quite interesting.

And yes, also lots of bread.

If you had the stomach for such a thing, you might want to look at YANG, a 3x leveraged bearish China ETF, which is up about 30% over the past 3-4 days. Careful though - it will move just as quickly back down if the Chinese market recovers at all. I think the quote "markets can remain irrational longer than you can remain solvent" may apply here...

That's funny, because I often make the opposite point about SF. Living in the Boston area, there are areas of Boston that are as expensive as SF (Back Bay, South End), but I can go a very short distance out of the city (Somerville, Medford) and find considerably cheaper housing.

This might be the case "out of the box", but it's very simple to go multithreaded on the Cedar stack and avoid this issue (provided that your app is threadsafe, of course).

You can do this pretty easily with a Procfile and thin: bundle exec thin -p $PORT -e $RACK_ENV --threaded start

And then config.threadsafe! in the app

Regarding Rails app threadsafety, there are some gotchas around class-level configuration and certain gems, but by and large these issues are easily manageable if you watch out for them during app development.

It's not widely known, but in practice, you can get effective link tracking using the iTunes affiliate program. Here's a blog post on the topic I wrote up a while back: http://www.coursenotesapp.com/blog/?p=16 .

You're going to have to explain your math here, because I don't believe the diagonal is going to give you 40 (unless I'm visualizing the problem incorrectly). In fact, I believe the diagonal is longer than the naive solution.

Actually, I don't think this kind of standard iPhone app promotion advice is worthless at all. But like any business problem, not every technique works for every situation. I wish I had some better advice to suggest, but in my experience, games are a particularly hard category to market and I've never been able to figure out what works well there.

There are a lot of interesting companies in the space now. A couple that come to mind are http://www.betterlesson.org/, in Boston, who are building a way for teachers to share lesson plans and other resources; and http://www.learnboost.com, in SF, which is building an online gradebook and other tools for classroom management.

We use Google Translate where I work for a some very small customer service related tasks. Our business is not "built on" Google Translate (and has nothing to do with translation), but it solves some small problems for us and is easily worth $10-20 a month for a low volume of requests. Actually, since we already have it integrated and are happy with it, we'd probably pay more just to have the problems solved so we can focus on really important things.

The section on deprecation appears to say that the service may be deprecated without a deprecation period "providing the Deprecated Version of the Service could create a substantial economic burden as determined by Google in its reasonable good faith judgment". This is the explanation they used for deprecating the translate API, "substantial economic burden". Nobody is going to be able to argue against Google's "good faith judgement" on this point, so it sounds to me like this service could effectively be deprecated at any time.

This is a bit of a slap in the face -- could they not rate limit the service and charge for it?

The math is about the relative costs and benefits of altruistic behaviors. Altruistic behaviors must be a net benefit to an individual or group in terms of reproductive success, or else it would die out of a population. For a business analogy, the behavior needs to turn a profit.

In the case of kin selection in particular, the math is described by Hamilton's Rule, an inequality that must be satisfied in order for kin selection to explain a given altruistic interaction between individuals (http://en.wikipedia.org/wiki/W._D._Hamilton#Hamilton.27s_rul...).

Indeed, these kinds of altruistic behaviors have been demonstrated many times and in many different ways in simulation. It is interesting to see this implemented with real robots, but it is not at all surprising that the same dynamics would appear.

I made the comparison in the sense that if you want to use another language on the client-side (like CoffeeScript, for example) you end up compiling down to JavaScript as the low-level implementation.

Suddenly CoffeeScript makes a lot more sense to me:

"the language itself is held hostage by browser vendors, some of whom have shown a strong inclination to not give a fuck about owning up to and fixing their egregious mistakes"

So true. The JavaScript we've got now is the assembly language of the client-side. We can't easily change it, but we have to start building better tools on top of it.

I don't dare to make any sweeping generalizations about this, but I would love to see how age, location and amount of time spent working at startups correlates with some of the opinions here. I suspect there might be some interesting (if not entirely unsurprising) trends there.

Gaming is a cruel mistress for developers. It's so hit-driven that it can be hard to really predict what will do well and what won't. Something that is a smashing success on one platform might just be completely overlooked on another.

Awesome idea -- very useful. Thank you!

I "failed" (your word, not mine) on the App Store for almost two years before getting to some decent, steady success with an iPad app. I put out several apps myself and on behalf of two different employers since day one of the app store, and most of them went (more or less) nowhere.

For the app that does make money, it was really about the tried and true technique of "build something people want", instead of "build something useless you think is awesome and pray".