I'm very good at hand-crafting Mac apps among a very few other things. Check out my website, https://sephware.com/ or say hi at contact@sephware.com :)
That reminds me of me. I was overconfident in my abilities so I didn't take the advice of people who were trying to guide and help me. But looking back, I think a big part of what played into that overconfidence was not seeing that I actually could do the cool things I saw other people doing, because I had no one to show me how. So I was satisfied with doing slightly cool things and convincing myself it was amazing. I think a good mentor can show you a clear path from A to Z and get you excited about the fact that you actually can do B, you just have to start with A, then go to B, etc. That's one of the things I've been doing with my son, is trying to show him a cool thing that seems too advanced for him, and show him that it's only a small step up from where he is, and that after a simple 30 minute lesson that he fully understands, suddenly he can actually do the thing he thought was impossible! He just went from A to B in 30 minutes! Enough times of doing that and you're already half way to Z and it doesn't seem so impossible, so you stop being satisfied with letting yourself thinking B is actually Z. I'm probably not making much sense, but I hope the point is coming across at least a little.
I love the simple software-centric approach to analyzing this survey and categorizing the answers.
There's one thing I'm sure was mentioned a lot by 17.1% of the participants, but it's one thing I'd like to stress:
Find a good mentor!
I've been teaching my son programming steadily for a few years now, and every so often he likes to take what he just learned, go and revisit some old programs he wrote or read from before he understood the new concept, and understand it better and often improve on it a lot (even rewriting it sometimes), and then he comes back to me very excitedly telling me how the new concept I taught him greatly improved the thing he did.
He's already writing code better than I did when I was a decade older than him, easily grasping new concepts like linked lists, garbage collection, pointers, and Lua coroutines and so on. When I was his age, I was still struggling to understand arrays in QBasic, had nobody to mentor and guide and teach me, and was generally pretty lost. Having a mentor who can guide you carefully and at your pace is an incredibly powerful shortcut.
Even so, I'm glad it's been written. I didn't know you could call Go code from C code (new feature since Go 1.5 apparently) or that Swift could access compiled files with these "module map" things. I'm really glad to see they've both evolved to include useful interoperability and play nicely with other things now, and I'm glad this article shows how in a practical way.
We're at that point too. My solution is a combination of downsizing our life and making my own app business. So far the only app I released (Autumn) was a bust because I stupidly released it on New Year's Eve so practically nobody knew about it, also it's too niche. But everyone loves the quality, so I figure I'll just keep writing more apps. I've got a lot of ideas and a lot of energy. I may have to work at Walmart or something, but I can keep doing this in my spare time. As long as there's at least some food on the table, even if ramen noodles, my family can keep going.
Lua can also be modified to have "engine.shared.entities" look for a file named "/engine-shared-entities.lua" and similar things. The creators have cited that Lua is sometimes used in environments where directories do not exist, only files.
> "But should you use it for your large scale app development project?"
This seems to imply that for whatever reason, TS may not be suitable in larger projects, but both Vue.js and Visual Studio Code are full TypeScript projects.
> "Programs that manipulate other programs are powerful, interesting and fun. I’ll use Ruby to take you on a tour of how interpreters and compilers work, introduce the ideas behind a technique called partial evaluation, and explain a surprising computer science result which allows compilers to be generated automatically."
I was considering using bash, some command line markdown transformer, and a makefile to transform my blog posts from markdown into HTML by wrapping them in an HTML template that just have the strings $TITLE, $BODY, and $DATE substituted. I think that would be a fun way to do this with zero C code. One of the hard parts was figuring out how to avoid too many nested data structures, like embedded title in the markdown files via front matter. But I figured out that if all you have is a title and it's a one-line string, you can just use the `head` and `tail` command line utils to extract either the title string or the markdown body depending on which operation you're in the middle of, and you can still just use bash (except for the markdown converter). I plan to use this on my blog[1], and maybe also to generate a blog index.
Can confirm, have sometimes added /* * @type Foo */ above a type and VS Code assumed that type was Foo everywhere else in my project, as if I typed `foo: Foo` directly. Didn't even have TypeScript in the project itself, purely an IDE feature. Extremely well thought out and useful ecosystem.
I tried Flow and TypeScript out about half a year ago in a client project and Flow was kind of painful and difficult to use, the updates, bug fixes and new features weren't coming as often as TypeScript's were, and maybe 70% of people I talked to were using TypeScript instead of Flow. Since then it's more like 90% now, and the TS team seems to be adding and announcing features faster than before, whereas I haven't heard about any new features in Flow. Maybe they're there, I'm just saying I haven't heard about them. This is all anecdotal but from what I've heard, it's very common. This is a big reason I chose TypeScript in Autumn. Also, VS Code has become the de facto free editor of JavaScript projects with a full set of professional-grade IDE features across the board, and VS Code has first-class support for TypeScript but only plugin-level support for Flow. Since Monaco is simply extracted from VS Code, that means I got all VS Code's IDE features for free when I embedded Monaco into Autumn, all I had to do was set the language to "typescript" and it just works. All these free and serious benefits of TypeScript's ecosystem kind of point to this conclusion that I've seen on HN and elsewhere over and over, that TypeScript has already won and Flow is on its way out.
Productivity is one of those things that I think should be motivated with reward for increasing it instead of punishment for decreasing it. I love the nice feeling I get when I use my own custom window manager to shave another 3 seconds off a thing I commonly do. It's an amazing feeling, it makes me feel like Tony Stark, building my own personalized JARVIS, a program that automatically does exactly what I would have done manually. That's a big part of why I built my window manager and why I want to share it with people, because I want them to feel that same excitement and joy of directly improving your own quality of life, even in a tiny but very real way. I would open source it and give it away for free if I could do that and still keep the lights on.
That's why C is the way it is, for all the hate it gets. I've been teaching my son the beginnings of C now that he's proficient in JavaScript and Lua, but making sure that every step of the way, we jump from a concept he already understands, to a new but related concept, and how they're connected.
For example, when I explained signed and unsigned to him, since we already covered the concepts of groups of bits having 2^n possible values, he quickly understood that signed has just as many values as unsigned, but the upper half just become negative inverse of the lower half.
C evolved from actual needs, and the fact that it's still widely used today shows how incredibly well designed it was for practical but relatively general problem solving. The C committee's job is mostly just a matter of saying "no" to every new feature request, because C has proven to be versatile enough to work in an extremely diverse array of situations.
We've been using Lua's C API and the Win32 API[1] to make cool things, such as a primitive Love2d clone, and just last night he said "Wait, you're telling me this is the old way of programming Windows? It just makes so much sense and seems so well designed!" C isn't perfect, but if you start from where C started, and trace it until now, you'll learn all the reasons behind its decisions, and they make sense in practical situations.
Kind of like the difference between metric and imperial measurement systems. Metric makes sense in an isolated mathematical world (i.e. science), bu imperial units make sense when you're working with real physical objects (e.g. construction).
I kind of wish I was in that boat right now. I made a highly praised window manager[0] for macOS that some people[1] have reported some performance issues with. But I can't reproduce the issue, possibly because I have 16GB of RAM and don't use it all. Maybe I don't have enough Electron apps running and should install Slack and others (I run Slack in Safari when working with clients), not joking that literally seems to be the main environment difference.
I think this is the key that separates Facebook from group emails. Facebook got people into the habit of checking something regularly, so regularly that you could expect that if you post something today, they'll see it within a few days. People never had that habit with email, which is a lot more like mail: you check it when you're waiting for something specific. But you check Facebook when you're bored and want to be entertained with short paragraphs or videos or by participating in gossip.
Facebook is harmful because it's reckless with your personal data, but Google is invaluable because of its utility and amazing results? It's able to provide those results because it steals your data, which it also abuses and sells. And as an alternative to YouTube, there are free public libraries with similar DIY books complete with pictures and drawings, but without stealing and selling your data.
I think the "have everyone learn how to use something like IRC" solution would have been a lot more feasible if the technology behind it (servers and clients) didn't stagnate and cater only to technophiles. Most of the concepts of Facebook were around already in UNIX, such as having your own mailbox in your own user account and being able to check it for new mail, wherever it was sent from. Imagine something like AOL in 1995 except instead of real-time chat and single-person email, it also had the few features of Facebook. They weren't missing the technology, they were just missing the imagination and the realization that connecting groups over longer term (followable status updates) was higher priority than connecting individuals over a longer term (email) or connecting groups in the immediate term (chat).
My son and I have been using the Win32 API and Lua 5.2 to make fun things, such as a simple window manager and a simple Love2d clone. This file is extremely helpful especially considering we don't have internet at home, and MS Visual Studio Community doesn't seem to come with offline API documentation.
Not only is TypeScript's typing system less verbose, but it's smarter than old school (Java-esque) type systems. I just released a new version of Autumn[1] this morning that uses TypeScript's union types and type literals, and has this built-in: `type ModString = "command" | "control" | "option" | "shift"` so that now, even though you're still passing strings to Hotkey.activate, the IDE will actually warn you if you pass a typo like "comman". Not only that, but if you press Control-Space (same as in VS Code), it will actually auto-complete valid options for you. TypeScript is full of little goodies like this that are IDE-friendly, which is why I chose it for Autumn instead of plain JavaScript or Lua.
As a cool example of the practicality of generators, my son and I wrote a generator in PICO-8 (Lua calls it coroutines) to animate moving the tiles in a 2048 game we made, using simple a for-loop to animate the tile's pixel coordinates, but yielding at the end of the loop body, so that we could let _update() and _draw() continue. This allowed the program to still be able to respond to key presses, which would "skip" to the end of an animation by fast-forwarding the coroutine until it was dead, and then create and start the next animation coroutine. I think when he saw that it was just a for-loop but it that kept "pausing" (yielding) at the end of each iteration, he finally understood generators.
Someone recommended this to me as a simpler alternative to Preact (for certain simple use-cases) and I think it's just absolutely brilliant. It's React's logic of this.state and this.setState, separated out into generic function. Beautiful.
It was the most recent thing I did (literally this morning) so it was fresh in my mind. I'm also not an expert in virtualization solutions given how I haven't needed to use it until now. But this has held true for many, many apps and their open source alternatives. Paid products generally tend to be higher quality than open source, for whatever reason.
I was just running into this dichotomy this morning. To test my app Autumn on High Sierra, I had to install it in a VM, so I tried VirtualBox (open source) and Parallels Desktop Lite (in-app purchases). Not only did Parallels have a smoother, cleaner, more modern and easier GUI, VirtualBox just out-right doesn't work when trying to install High Sierra, and I had to find third-party instructions online just to bypass this bug. Plus it likes to crash right after shutting down the VM. I'm not really sure if there's some deeper philosophical reason behind this dichotomy, but I've seen it hold true for a lot of apps and their open source alternatives, and many people have said the same thing holds true about my app Autumn and open source alternatives like Hammerspoon and Mjolnir. As a rule, we really do seem to get what we pay for.
Hi, maker of Autumn here, would be glad to answer any questions or hear your feedback on Autumn! I just got it working this morning on High Sierra and it was interesting some of the things that made it not work there in the first place. One being that WKWebView on Mojave has Array.prototype.flatMap but on High Sierra does not, so I had to polyfill my own (2-line) version!
Your scenario sounds not only plausible but highly likely. Especially the point about individuals or other principle-driven organizations being relatively unable to reproduce the closed-source advantages that they could tie into open source projects to make them significantly more useful on MS-blessed platforms and systems. This is all a very real possibility.
TypeScript has other features such as Enums that don't exist in JavaScript but aren't pure type annotations either. It transforms into very clever bidirectional map tables.
Along those lines, I think a heavily commented version of fff would be a great learning tool. The concepts of fff are simple enough that anyone could follow along easily without really having to learn fff first. This idea came partly from the fact that when I tried reading fff's new source code yesterday, while knowing exactly what fff does and understanding the comments completely, I was still pretty lost as to what it was doing and how it worked.
This is how Bezos built AWS, so he meant services that are needed to build websites, such as databases, servers, containers, queues, caches, storage...