They've also (supposedly) been profitable since inception. It's likely that this round has a significant secondary, which means they're just cashing out part of a profitable business.
Exactly. An increasingly common thing lately is what’s effectively a “private IPO”. That’s what this sounds like - liquidity for investors / staff, and ownership to a small cadre of professionally managed funds vs. the Wild West open markets.
Funny, "private IPO" is exactly what I said to someone I was discussing these types of rounds with.
Going public has very tangible costs, but also massive intangible costs. Private markets are extremely frothy and keep ownership and control within an aligned group of investors. This can make all the difference in the world to management.
Google video search does not recommend. You must make a search query. I'm talking about actual recommendations that you didn't explicitly search for which is where discoverability stems from.
So you intend to collect detailed view data to feed your model? Kind of like a browser extension spying on every video you watch anywhere, collecting detailed data about how you watch, etc? Don't count me in.
I'm thinking more about a website (Client) where you get the recommendations then if you click on one of the recommended videos (either by watching the embed or redirecting from the website) we'll assume that you liked it.
Outside of this website (client) you won't be tracked.
I also highly recommend Affinity Photo. It covered all of my use cases for photoshop and some for lightroom. Adobe is a scummy corporation who doesn't deserve their customers.
Arrogant is the most accurate word to describe Elm and its leadership. I tried to use Elm in production between 0.14 and 0.18 versions and it was fun and mind expanding experience. I'm truly grateful that I've used it because it introduced a lot of functional stuff to me. But I no longer use it myself or recommend it for any serious work.
Breaking changes were negligible in the beginning. But I got fed up with rewriting the app after the 3rd Elm upgrade. I think it's irresponsible to advertise the language to be used in production and break it every fucking year. Speeches about finding the perfect solution are great for academical discussions and toy languages, but you can't just remove the stuff that your community uses without offering any alternative. It all stems from the arrogance and cult-like behavior of the core team. I'm sure that they're wonderful and very smart people who do their best to create the best version of the language that they can. But their management style is too dictatorial and they don't respect their community.
For me, the split started with elm formatter discussion on github. I disagreed with some of decisions that the core devs made and I wanted to see what other developers have been saying about it. On of the issues was the preference for 4-space indentations instead of 2-space. I understand that it's important to have a single source of formatting for the language. But at that time there was no consensus on what amount of spaces to use. Basically, the community divided almost 50/50 between the two. Moreover, a lot of core libraries and example code still used 2-space indentation. (that's why I preferred it). Due to lack of consensus, there was a suggestion to add a flag to formatter to set the indentation. It required to change some parts of code to pass the flag to the formatting module. At that moment, one of the core devs stepped up and closed the discussion because he didn't approve of this decision and he just said that 2-space people should adapt to the new 4-space default (that wasn't supported by any majority). It was the first time when I felt that the Elm management is too strict and I don't want to have anything to do with people with such attitude.
Yep! If people used tabs, then everyone can display it how they like and these stupid discussions wouldn’t be necessary. Alas, for some reason the world has rallied behind spaces. Sigh.
It doesn't really solve the problem. How do you format this code with tabs:
<TAB><TAB>function name(arg1, arg2,
<TABs or spaces?????> arg3 <-- align with arg1)
The other issue is with maximum line length. If you have a maximum line length of 80, do tabs count as 2 spaces, 4 spaces, or 8 spaces towards meeting that line length?
Using spaces ensures that it at least looks consistent, independent of your tabstop settings.
Indent with tabs, align with spaces. Alignment never follows any "N number of spaces" style guide, since by definition its to align with something else.
since we were talking about indention, not alignment, I don't see how anything changes. If I want my indent to be 3 spaces and you want 8, we can set our tab width and arg3 will still be aligned correctly for both of us.
Or you live with misaligned arguments (its a bit of a smell imho to have so many arguments that you need to split them over many lines, although it for sure does happen) and just use tabs for both.
My main point is that with tab, each individual has some control over their preferences, even if not perfect for alignment, while with spaces everyone has to live with the standard and nobody has control over their preference. That is, tabs is "mostly people get what they want", spaces is "nobody gets what they want unless they happen to want the style guide imposed on them". The former seems a lot better to me!
You learn to live without precisely aligned arguments!
Really this is a peculiar kind of OCD. You don't need to have arg3 precisely lined up with arg1. Or better yet, indent all the arguments in a nice column - if there's so many that they can't fit horizontally, render them vertically. Most IDEs default to two indentations for continuation.
I've had some discussions with folks on projects who are very... focused on linting and formatting rules. They've reformatted my code in the past, and have insisted on blocking code that doesn't pass all their listing rules.
Them: "We have to use these tools to avoid disagreements about spacing and formatting choices".
Me: "But... I wasn't having any in the first place. It's only the 3 of you that were having these disagreements. And now you're spending ridiculous time planning reformat of entire codebase, instead of actually... moving the project forward.
Please don't bitch about me using $x = new Temp(); in a test file. I'm the only person on the project even making test files, and you're blocking my TEST file because you don't like variable name style..."
They got in to a quandary when trying to inline some JS in to a PHP view file. The PHP standard is 4 spaces, and the person doing some of the JS had defined 2 spaces for JS ("so we can all agree on it") and ... all hell broke loose trying to determine what the style/formatting should be for JS-inside-PHP files. 4 spaces? 2 spaces?
Not the person you're responding to but I do, or actually spacemacs does. The sequence would be $ -> J -> i -> ENTER -> ESC and I guess it's muscle memory.
I agree that this kind of indentation might not make sense on a collaborative project because different people have different standards, but if I'm the only one working on a piece of code I really think precise alignment makes the code a lot more readable.
I don't actually personally do this kind of alignment, but it was the easiest example for me to come up with to illustrate the problem of needing to align text on different lines.
In elm you'd do one of two things: keep all the arguments on one line, or put each on its own line. At least, according to the formatter's opinion (which is honestly so nice to use when it just snaps everything into place every time you hit cmd-s). Of course, this convention is violated all the time when listing all the public exports of a package (with good reason IMHO; it lets your group similar things onto lines together) so it's not much of a convention: https://github.com/rundis/elm-bootstrap/commit/e412efe628854...
My main objection to using tabs has always been that the Tab key is heavily overloaded: it navigates (one Tab press to move the cursor to the correct indentation point), selects (tab completion), and it puts a variable-width character into my monospace-defined text file.
I'd rather drop the insertion part and have my editor handle adding an appropriate number of spaces.
Let me add this: there's actually nothing stopping you from displaying a four-space indented file as a two-space indented file. Just parse, replace indentation-dictated groups of four spaces with two spaces, you're done.
I don't know of a plugin that does this for $your-favorite-editor but it's, y'know, software. There's nothing which prevents it.
My editor maintains it automatically, so it is never wrong. There is nothing to check.
I'm sure there is a command-line pre-commit formatter I could use. But I have never tried to set it up, since I can reformat existing code with a couple of keystrokes in my editor.
Ok, but if you get "\t[space][space][space][space]", how do you know this wasn't supposed to be "\t\t"? That is, how do you know trailing spaces are for alignment and not for indentation?
A code formatter knows, so your editor and other tools can also know.
Most editors have code structure parsing of some kind built-in for tabbing already. E.g. pressing the <tab> key indents the current line to match the structure of surrounding code (or cycles between valid indents for something like Haskell or Python). So they know the difference between initial indentation (that people want to be able to configure visually) and alignment.
I have over 6 years of commercial experience with Ruby, JavaScript, and Elixir. Throughout the course of my career, I developed multiple diverse projects, such as fintech payment service, hardware monitoring web panel, e-commerce websites, and various catalogs.
