The more established, bigger, unethical companies will crush the "our products don't poison you!" competitors out of existence before they even get started. They will maintain their poison-happy monopolies. So without regulation protecting anti-poison competition, there will be no money in these alternatives, and the economy will remain unbalanced and literally deadly.
It's interesting that you are using LuaJ in your clojure app! I thought Lua was mostly used for scripting games, so I'm curious now: What is the benefit of using it within your closure app? What do you use it for?
If this project relies on the GraalVM, I think it could go even further by implementing the GraalVM Polyglot interface [1] and becoming a first class language on the GraalVM. Then it wouldn't need to share Lisp syntax, and could use the real Lua syntax. It would also be much faster since it would be compiled into JVM bytecode by Graal compiler.
That seems to be because they use whitespace as commas (look at the parameter list). It also means you can't write "a - b" as "a-b" because the whitespace is now required. I can remember many times that I have typed "a-b" or "a+1" so I wouldn't be able to write in my natural style in this language. Maybe I'm wrong for using that style in the first place, but I think languages should be a little more permissive with style preferences like this.
I like the other advice here a lot and echo it, but I want to add one thing: don't panic! If you panic, it will actually slow you down and reduce your ability to concentrate. Just relax and accept that it may take time, and by just relaxing and not worrying about it, you will go faster :)
I haven't yet needed to use a constructor in a HOF. And in the event I do, I can just wrap it in a lambda. But I see your point, it feels cleaner to just not have the new keyword. But without it, you have no guarantee that the function is going to return a new object, it could return anything it wants. At least this way we have a little more safety from monkey patching or programmer error.
If the new one just wraps the old one, but the new one breaks on certain inputs, how is it breaking? Maybe the outer "new" layer uses a new string to number parser than the inner "old" layer used to use, and that's where the bugs are being introduced?
My rule of thumb is, write it yourself until it's painful, and spend a day looking for a good library to reduce the pain. If you can't find it after a day, or if you found one but it's taking longer than a day to configure it for your needs, try to write one yourself. This rule has not done me wrong yet. It's how I ended up moving away from Mobx and Redux in favor of RxJS and setState (just submitted a post about how to do this), and why I moved from Vue to React. But it is very subjective and subjectivity gets harder the more people you have on a team working on the same code.
I think about community quality content a lot. I see a lot of abuse of this all over reddit and other forums and stack overflow too. People have figured out how to game the system. I think the internet is ready for some forum software that uses machine learning to decide whether content is high or low quality. It could analyze the replies, the context, the content, the user's history, posting rates, all sorts of data is available to recognize low quality content and low quality users. Especially when you realize that a lot of reddit accounts are bots that farm points and then get sold. ML seems like the only real way to protect communities against this!
I can totally see an argument for that if you need gradual type coverage, which I guess is needed on large code bases. I have only worked on smallish ones of a few thousand lines of code, and it took maybe an hour to type everything, although most of it was really fun and exciting :) but in cases where that's not realistic, I could see using Flow to help transition.
I don't have any idea how to build a start up. And I don't live anywhere near people who can help me build a start up.
But I do have a great idea!
Without giving too much away about what kind of app this is, it's a missing app that I often see longed for on this forum. There are beginner apps like it and advanced apps, but no intermediate app like the one I have in my mind and heart. I suspect it's because all the advanced apps like it started out as intermediate apps, but said "yes" to every single feature its users asked for until they became that complicated.
It's not the kind of app anyone would spend money for an intermediate version of. But I am extraordinarily excited about using it myself, and other people who I have talked to about it are too. So I think I am going to make the app, make it freely available, and set up a Patreon for it. I have to make it outside work hours though so that slows it down. Maybe I should make a demo or prototype first and set up a Patreon before releasing it to help fund me spending more time on it more quickly...
I want to expand my knowledge but don't know whether to invest in learning C++ or Rust. Both look like they have interesting concepts, but Rust is new and not yet widely used, and I hear C++ is easy to break in confusing ways. (I have cut Go out of the picture because copying and pasting code is the first thing you learn not to do in school, but all the Go leaders say you have to do this since they don't want to implement generics, so I don't trust their judgment on language design.)
Similar, but harder to use safely and correctly in class methods using the new class syntax. There's more surface area for typos and other mismatch errors since you have to type the method names twice. See: https://mobx.js.org/best/decorators.html
I thought your name sounded familiar! I played around with Mithril.js for a bit before settling on React.js and was really impressed with how you took the simplicity of JS and used it to your advantage with Mithril! Sad to say that I couldn't replicate that cleverness in my own code because I could not really wrap my head around the reasoning you used to come to code you did in your examples of using Mithril, but that's just more evidence that you're a smart guy, so thanks for making Mithril which helped widen my view of what could be done with JavaScript frameworks! Also is there any reason you chose Flow over TypeScript?
And I think you're right about decorators. They are an iffy concept in the context of JS semantics, and I personally avoid using them and try to avoid libraries that use them. That's probably why TS has them disabled by default and calls them "experimental". I like the concept of decorators in and of themselves, but they don't fit cleanly into the JS world, and I am looking forward to seeing how the JS/TS world innovates alternative "cleaner" solutions that fit better into the existing model!
To me that's a feature and not a bug. A good codebase would have --noImplicitAny enabled, which would catch this. Relying on usage of a function to know its types is fragile, the function should be the one declaring the types it uses so that callers can adapt to changes, not the other way around.
That's not true. TypeScript spec is just the latest JavaScript spec. Decorators are a JavaScript (TC39 stage 2) proposal, and TypeScript only uses them if you use --experimentalDecorators. And TypeScript uses the ECMAScript module system. Whatever other features you think TypeScript has that aren't "proper JS" probably are either already JS, or are late-stage TC39 proposals.
I wonder if the same semantics that make Forth simple and fast can be used with another (higher-level) syntax to make it easier to write in, kind of like how C replaced Assembly. It could become a new family of languages that might rival modern high-level languages in the same way CL Lisp tried to shake things up by being both low-level and high-level at the same time.
> “These tech companies have decided to leave their suburban campuses because their employees want to be in the city, and yet the irony is, they come to the city and are creating isolated, walled-off campuses,” said Aaron Peskin, a city supervisor who is co-sponsoring the bill with Ahsha Safaí. “This is not against these folks, it’s for them. It’s to integrate them into the community.”
So, app developers face the difficulty of having high wages but higher costs, and in every single direction, greedy people are trying to get every dime out of them. I mean $3,258 for 1-bedroom apartments is outrageous! And now, while they're trying to cut some of the few costs they have control over (food), the local government is openly and brazenly trying to force them to spend more money on local lunch shops? Didn't we just read a few months ago about a high profile developer who lives in his car because he can't afford rent? Capitalism with rules that favor greed is pure evil. I'm all for looking for ways to monetize, but you're literally stealing from people living out of their cars.
> I tried Flow and TypeScript for the first time a few months ago. Flow is absolutely abandoned and dying. TypeScript is taking over where Flow left off, and is far ahead of the game by now. I use TypeScript with create-react-app in my client work and it is invaluable and a wonderful experience, with no downsides as far as I can see.
To add to that, the only reason I can see to use Flow in 2018 instead of TypeScript is if you already have a large project that uses Flow and migrating to TypeScript might take a few days. But even then it's probably worth making the switch. I have noticed a much smoother experience and much better integration with TypeScript than with Flow. And there are many type errors that Flow never caught no matter how much I tried to configure it right. Existing code bases may have these too. Even more reason to switch sooner than later!
Good point, I was reading through licenses and saw some like Apache and Mozilla mentioned trademark limitations, but now that you mention it, that probably only counts if you trademark it first! I will look into trademarking without an LLC, great idea.
I don't think the commercial aspect of AGPL helps me a lot since my app will use Electron to let people make Electron apps, and there's no way to keep Electron apps closed source. But it does sound like it protects me in the event that I get a source of donations from Patreon, so that contributors can't sue me to get some of the donations since they would have to sign an agreement. That said, I am not opposed to sharing donations with contributors based on contribution percentages, knowing I would be the one writing almost all the code. But I don't understand the legality of all this and I am wondering if they'd be open to suing to get some of the donation money! I try to be business minded like this because even though most of humanity tries to do the right thing, there's always eventually some bad actors who come in and try to take advantage of people.
That sounds like a great idea for the app I want to make! It would let users create and ship apps that come with my custom runtime functions bundled in. I'm trying to figure out how to monetize it, and my only thought so far is to open up a Patreon for donations from any very enthusiastic users. But sublicensing seems like a good alternative! Or maybe I can do both.
So if I'm getting what you're saying, then if I make an app that lets people design and generate their own apps (like Eclipse), using GPL would NOT force them to use GPL on the apps they create with it. But if I give them a runtime (like Unity), using GPL forces them to release their apps under GPL too?
I have seen some projects write their own documentation generating scripts, like RxJS, it may be worth writing your own home grown document generator if you can't customize Doxygen to your liking?
I'm surprised to hear it was faster, I just assumed C++ standard library is optimized for speed since I thought that's what C++ is known for compared to JavaScript.