Strongly agree. We liked Fennel so much we adopted it for building our mobile apps. We have a SQLite + Lua core that handles business logic and increasingly also view and controller logic with a thin native wrapper for iOS and Android. With over 100k downloads and active users, it’s proven itself stable and practical.
It’s a convenient way to access the immense power of SQLite, with the succinctness of a lisp-like syntax. Throw in tests that execute at 350 tests per second and it’s a fast, stable development platform.
Right now we’re building a wrapper to display graphics sufficient for simple puzzle games so we can generate the layouts and handle interactions also in Fennel (by mapping to native iOS and Android views). It also does hot reloading in the iOS simulator. Very much a WIP though. We haven’t shipped this part yet.
Fun times. Stable. Small. Uncomplicated. Great community.
Sad that Facebook Marketplace appears apathetic. Is it naive to think they could stop being part of the problem?
Facebook Marketplace will not lift a finger to help you, period. Don't even try. You can click 'report this ad' or 'report seller' but I can pretty much guarantee you literally nothing will happen.
Facebook has no functional customer service, and to be honest they've repeatedly demonstrated that they do not care that Marketplace is used to fence stolen goods. There is literally nobody behind the scenes at FB Marketplace who is going to care, or help you.
Point being: don't waste your time contacting Facebook.
Another vote for s7. We successfully embedded it and SQLite as the (non graphics) engine for otherwise native apps on iOS and Android. Super fast. Great FFI. Reliable. Small. Huge benefits from shared code across our mobile apps, insanely fast unit tests and a clean set of tooling.
Ultimately we switched to Fennel as a more pragmatic Lisp for mobile. AFAIK we were alone using s7 on mobile whereas Lua especially is a common mobile extension. Partly also this reflected the state of r7rs Scheme compatibility. We were running Guile on the desktop for development while shipping s7 and subtle incompatibilities would bite us regularly (a fun one was parameter evaluation order).
Thumbs up to both s7 and fennel for their great projects and community.
No secret. A little puzzle app company I’ve been running for a while: www.eggheadgames.com. No ads or gamification. Just classic paper magazine puzzles. Pay for more or subscribe for unlimited play.
As we’re small, rewriting the code over and over for cross-platform is costly. But as they’re games with words, we want a fully native experience for the highest quality app with great accessibility and full integration - as well as easier crash log debugging without intrusive 3rd party packages.
The classic solutions are either not native enough (Flutter), are graphics-based (Unity), too expensive to maintain the stack (React *), don’t integrate well with the native mobile tooling (Go, various ports of Python, Ruby, Lisps apart from s7) or also end up being a separate core but are harder to debug via crash logs (various JS, Kotlin or Swift cross platform).
Plus once we tried Lisp it was hard to go back! Succinct, fast, great editing. And yeah, it’s just fun to do something different. We also get a kick from being part of and contributing back to the Fennel community. It’s nice to mix some open source with commercial apps.
Man I hear you, on my music pedagogy app just being able to do the actual "business logic" in Scheme is soooo nice. And I can share my code with my Max based work, which is awesome.
It introduced me to the idea that most employees are "economic losers" who are "people who have struck bad bargains economically – giving up capitalist striving for steady paychecks." (At least in the early - middle life cycle of a company).
It encapsulates this as "The Gervais Principle":
Sociopaths, in their own best interests, knowingly promote over-performing losers into middle-management, groom under-performing losers into sociopaths, and leave the average bare-minimum-effort losers to fend for themselves.
(The terminology is quite specific to the article - i.e. not sociopaths in the movie-cliche view).
I won't attempt to summarise the article here. Suffice to say it altered my thinking about future roles. Search HN for many prior discussions here of that post.
Yes, I encountered this. Soon after I had set ddg to the default on all my browsers (mobile & desktop), I found that DDGs results have been perfectly acceptable most of the time.
Further, I find that I use shortcuts like !w, !yt, or plain "!" much more often than I use !g due to poor (or simply less targeted) search results.
My (still incomplete) analysis of whether it's worth it for my apps...
I have some paid and freemium puzzle apps on Amazon and Play that would fit this model well, because they don't currently have ads, large numbers of people play them for free without ever buying, and the puzzles take 10+ minutes to solve and people often play for 20-30mins most days. So, this was intriguing to me.
However, as always, the devil is in the details. Some things that I haven't seen (much?) in other comments yet:
- to be accepted to Underground, you have to have an existing app on Play or Amazon.
- the submitted app must be "substantially similar to or better". I.e. no stripping out extra volumes or removing key features
- that app must not already have ads
- you have to seamlessly migrate state for players already using your game (i.e. help your current paid? users move to free (for them))
- Amazon can show ads at the end, as well as at the beginning
- you can't change your mind and withdraw the app within the first 3 months
- if you do withdraw your app, you must continue to support it for anyone who has downloaded it (including keeping backend servers running etc)
- it's not permitted to tweak your app to try and game it for extra time spent
- if your app uses subscriptions, it's not eligible
I ran basic numbers for my apps through Amazon's convenient calculator (https://developer.amazon.com/public/solutions/underground/ca...). It's impossible to know some of outcomes, notably: how much appearing in Underground will canibalize my existing apps in either Play or Amazon?
If I niavely assume that all my usage & IAP payments switch immediately from Play & Amazon combined, to be just Amazon Underground, the numbers for one of my apps works out as:
- Number of user engaged minutes last month: 728300 (according to Flurry session tracking)
- Revenue for this app: USD$1446.37 (this is for 2 months prior, but close enough)
So, if I go to the calculator and enter 728300 minutes into Amazon, 0 mins for Google, $1446.37 Amazon revenue, $0 Google revenue, and 0% increase for both, then I get the magic number of $1457.
I.e., $10 more with Underground. But ... does this really mean anything?
On the dev/web jockey side, I figure about a day per app to adapt and submit it. Some of the steps needed for my apps are:
- rebuild the app with a different package name (presumably so it doesn't conflict with a prior installed version of my app
- ideally remove all IAP (if it is already Amazon IAP, then they'll just make it free anyway, but if it's Play, then rip it out / replace with "Unlock" instead of "Purchase" and skip the calls to Google). I have Amazon IAP already, but I'd spend a few minutes to make them all free instead. And maybe a few more minutes to remove the Amazon IAP support library. Then a few more minutes to resolve build errors. Then a few more minutes to test that I didn't screw it all up. (Repeat.)
TL;DR: I'm on the fence. Switching would indeed capture revenue from the 90% of users who never buy extra volumes. However, it could kill revenue from those who do. Other intangibles:
- will it annoy the customers who have paid me so far - by definition my best customers. Will they ask for refunds?
- will iOS customers demand something simlar?
- should I promote this to my customers?
- should I jump in REALLY fast (today!) so all the early Underground adopters find my apps because there will be fewer to choose from initially
For now, I'm sitting tight. I've had a strict "no ads" policy in all my apps so far (and no spyware either), so I'll see how it evolves.
One related detail: my app revenue for Android used to be evenly split between Amazon and Google Play. For the past twelve months, Amazon has been declining, even though Play (and iOS) have been gradually increasing. I'm not sure if this reflects declining Kindle Fire adoption, decreased visible of my apps in the Amazon store, or ... ?
Congrats on working hard & smart and getting results.
Also impressed by Starbucks' role in all of this. How many other companies would have supported you through that period and perhaps in some way made this possible for you! I can't say I like their coffee much, but I've always admired them as a company that values employees and your experience adds to their cred imnsho.
Back in the 80s, I was one of those bright-eyed smart young things that went to work for a startup as a developer. Before I knew it, I had a team of developers working for me, and we were all working 80-100 hours / week. At first it was fun. We enjoyed the work and each others company. We cranked out code. We laughed at, and with, the sales people as they tried to make the first big sale that "just needed one more feature".
And then, as their (very young) manager, I realized that we were all being royally abused by the company. I don't recall what the trigger was, but the light bulb went off.
I started telling people to go home at 8pm. I urged them to "take weekends off".
A few months later I was ask to resign ... or to open a new office for the company in another country. (Never mind that productivity had gone up and people were way happier - the CEO loved that people were working all night and weekends and was royally pissed off that they no longer were).
Having worked in several startups since, and a couple of big companies too, I have a few takeaways that might help newer engineers:
* predictability trumps productivity - if you tell management it will be done by Friday, have it done by Friday. Don't promise them Tuesday and pull an all nighter to do it, and then miss by a day. Pad by a day or two to allow for the inevitable. If you get done early, use it to catch up on your personal work projects (exploring new tools, cleaning up that code from last week, helping out a co-worker). As a manager of engineers, I came to appreciate the (seemingly) slower but more predictable performers, as well as the rockstar miracle workers -- and they usually got paid the same.
* make managers choose what you work on, don't just do it all (they're paid to choose!) - The most useful scheduling / workload trick I learned was to always have handy a list of all the things expected of me. So, when big boss comes over and says "Hey, I know you're busy, but is there any chance you can squeeze in XYZ for me?", you can say, "Sure, I'd LOVE to Mr Big Boss. Which of the following should I push to next week: project A, B or C?" Nine out of ten times, XYZ is less important than what you're already doing and Big Boss will (honestly) re-think and move on. (The sleazy ones will try and find another patsy, so watch to see what they do next so you can calibrate accordingly).
* find a life & validation outside your workplace. When you enjoy your work and your colleagues, it's easy to make that your life. Resist, for fear of living at work. It can be good for a while, but it becomes a rut and you can easily be abused. It's better to find something outside that will forcibly pull you away and give you perspective. Find a sport, form a band, take up a new hobby. Anything that gives you a compelling reason to be out of the office.
* take vacations a week or more at a time. Don't let them expire unused. Don't take them as pay. Get out of town. Go see family. Go skiing/biking/sailing/hiking. Do a course. It will give you perspective and you'll come back to work renewed and a little more clear-eyed.
It’s a convenient way to access the immense power of SQLite, with the succinctness of a lisp-like syntax. Throw in tests that execute at 350 tests per second and it’s a fast, stable development platform.
Right now we’re building a wrapper to display graphics sufficient for simple puzzle games so we can generate the layouts and handle interactions also in Fennel (by mapping to native iOS and Android views). It also does hot reloading in the iOS simulator. Very much a WIP though. We haven’t shipped this part yet.
Fun times. Stable. Small. Uncomplicated. Great community.