At work we use four random words a la correct-horse-battery-staple for buildbots. At home I have a couple themes. Japanese tree names (matsu, ume, kaede, momiji, etc.) for desktops. For laptops, I use names of islands on the west coast of British Columbia where I grew up (saltspring, denman, valdes, thetis, etc.). Both of those have a nice abundance of choices.
“Snow job” is an older term that simply means saying a whole bunch of stuff to try and persuade people to believe a lie. The image is of a constant barrage of arguements that eventually overwhelms the truth and buries it from view. Think big snowfall that will take a lot of work to dig the truth back out.
Ok, wierd term. But do you know what happened between him and Jobs that could be described that way? I always thought that Apple was more or less parallel to Free Software (with the exception of adopting some terminal tools).
Might have to do with Jobs asking Stallman to distribute GCC as two programs, so that NeXT doesn’t have to release the source code to the Objective-C frontend for GCC that they wrote[1].
Just a guess but perhaps he’s referring the the controversy around the original APSL or Eric Raymond’s participation in that announcement? Perhaps he had also been approached by Jobs?
I can’t find a video clip of the event and my memory is hazy (this is ~19 years ago at this point) but I remember Raymond being onstage at an early OS X event to announce that the (at the time) new APSL licence and state that it met the OSD definition. Raymond makes a reference to it in this comment, which elaborates on this line from the article it comments on:
I met Steve Jobs once in 1999 when I was the president of the Open Source Initiative, and got caught up in one of his manipulations in a way that caused a brief controversy but (thankfully) did the organization no lasting harm.
Still in Kyoto for vacation, so I might check out some local arcades. I’ve heard there’s a nice bridge over east, too, but Sunday’s supposed to get really hot, so maybe not yet.
Won’t get you out of the heat, but you could head up to Kurama station on the north side of the city, do some hiking in the forest, and have lunch/dinner on one of the platforms suspended over the river. Makes for a pretty fun day trip!
Working with architects on renovating a 150-year old Kyōmachiya and trying to imagine ways to move back to Kyoto while continuing working on engineering challenges I’m passionate about. Sadly, Kyoto’s not exactly a major tech hub.
I have written lot of scrapers too in Python (I also create my own basic framework based on BS4 + aiohttp in order to plumb my own scraping pipeline), but right now I think Golang is a lot faster and very easy (using colly+goquery). I am not using REPL for Python, then it’s not an issue me. Anyway you can use Go Playground in order to have something similar to REPL.
Golang is less “battery included” comparing to Python, but concurrency is amazing
The most consistent difference I notice is that almost every Canadian or British person I know pronounces “char” as in “charred” but my American colleagues, almost without exception, pronounce it as “care”.
American here; I say “char” as in flame. But if I were going to make it short for “character” I’d pronounce it more like “carr”, i.e. “carry” without the final syllable.
I seem to recall switching from “datta” to “dayta” due to watching Star Trek: The Next Generation, but I still say “stattus”, not “staytus”.
I hadn’t previously heard of NanoGUI but the code examples look clean and readable and the dependencies look minimal. Curious if anyone here has experience using it, and if so what feedback you have on the pros and cons.
I’ve written a couple apps now with it (including a demo that was part of the release of flutter_web at I/O a couple days ago), and I’ve been a huge fan since I first worked with the alpha ~1.5 years ago.
Background: Been a mobile dev on both platforms since v1 on both platforms, I’m stronger on Android through.
Upsides:
The #1 upside for me is I’m just way way more productive than on either platform using their standard framework. Mobile development is fun again for me, and that hasn’t been true in a long time. I can just throw UI together and it usually works. Even if I was just writing an Android-only app, I’d prefer to write it in Flutter.
Really great async support, and it’s properly built into the entire framework. Things like getting a photo from the library which can turn into callback hell on Android, end up being a few lines in a method.
Lots of useful built in UI widgets. A lot of things I’d go custom for on other platforms are built in.
Stable and well designed toolset. Honestly, this one is way undervalued. For example, check out the the command flutter doctor - https://flutter.dev/docs/get-started/install/macos#run-flutter-doctor - which diagnoses problems not only with your flutter install but with the native build systems for both iOS and Android. And it outputs command line suggestions to fix them. This kind of thoughtfulness is everywhere.
It’s open source.
The Flutter team itself. They’re experienced, older devs with huge amounts of experience. They’ve made tough tradeoffs and are standing by them. They’re also super nice and patient, just look at people taking swings at them on HN and how patiently they respond.
False downsides:
Dart. It’s fine, and also it just doesn’t matter much. The value of Swift or Kotlin on dev productivity has been hugely overestimated in my opinion. To put this to the test, ask a developer the how long it would take to develop an Android app in Java, then ask them how much time they can cut off using kotlin. It’s probably on the order of 5%. Give me that choice between Android and Flutter though and I’d probably be able to half the time estimates.
Real downsides:
Less libraries available, although you need fewer of them in my opinion.
You are a bit at the mercy of the quality of the UI controls. The team has been very responsive in my experience though.
Dart. It’s fine, and also it just doesn’t matter much. The value of Swift or Kotlin on dev productivity has been hugely overestimated in my opinion.
While I tend to agree for the most part, non-nullability/optionality and value types are a current gap, and I find both help significantly when reasoning about the code. For the most part though, Dart was designed to be familiar and productive. I think it’s been successful in those regards, despite its perceived blandness.
That said, it’s worth noting that the language team is dedicated to evolving the language. Over the years we’ve seen both large changes like the addition of a strong type system, as well as smaller improvements such as making the new keyword optional, driven in part by feedback from Flutter users.
Real downsides
I work on the Flutter team; here are two more:
Depending on intended use-case, the current lack of a great add-to-app story. We’ve done a decent job of creating a great dev experience for new apps written entirely in Flutter, but integrating a Flutter view or two to an existing app still involves some significant hand-wiring. The good news is this is a significant focus area for the team and I expect it to get better.
Integrating a lot of native widgets has a memory/performance cost. While most widgets can likely be written with relatively low effort in Flutter, it’s not always feasible. For widgets like WebViews that are impossible (disallowed on iOS) or complex to rewrite the overhead of the integration is relatively low compared to the overhead of the component itself, but if you need vast quantities of platform views, I’d recommend looking at other frameworks. We’re working on improvements here, but I expect there’ll always be some overhead.
Flutter is really nice, at least for an inexperienced mobile developer as I am, but Dart the language is not so awesome. I understand Google wants to have full control over an ecosystem, especially after their adventures with Java and Oracle, but I just wish there would be something else than Dart for Flutter.
Dart promises strong type system, but some type errors are thrown in runtime step instead of compilation step, while in other languages, even older ones like C++, the same class or errors are caught in compilation step.
Types are optional instead of mandatory; it’s possible to just skip type annotations and use dynamic which is like void*, or it’s possible to just don’t specify the type at all, which has the same outcome I think (the ‘dynamic’ type).
Public/private fields are specified only as a naming convention instead of being supported by the language. I.e. private fields are named with an underscore before the name. I mean, if something has its own convention of doing things the right way, then maybe a new language should have support for it? I get that Dart is not really new, but it’s not old either.
(this is pretty subjective, but still) It uses <type> <variable_name> notation instead of <variable_name>: <type> (postfix) notation, which makes it feel that type inference was not a part of the original design document, but was hacked at some later stage (but I haven’t researched if that’s the case),
the arguments come all the way down to some pretty subjective and not very important things (like that I have to write void main :P, or when I declare int main and return error code, Dart silently ignores this and returns 0 to the shell instead), that bothers probably only me, so I’ll skip them.
Public/private fields are specified only as a naming convention instead of being supported by the language. I.e. private fields are named with an underscore before the name.
FWIW, Python also works this way, and I really like it. It’s what I call (or maybe I’ve heard it called) the “we’re all adults here” approach. Languages that strictly enforce private vs public have a problem sometimes where a library author makes something private that you want to use, and you can’t get at it. With a convention you can indicate something is supposed to be private, but users can still access it if they decide they need to.
I understand your point of view, but I respectfully disagree with it. Normally private parts of a library is not an API, and by using it you’re increasing the risk of your project not being compatible with future versions of the library, so you’re limiting yourself. If your project is massively popular, up to the point that its popularity surpasses the popularity of the library, using libraries private fields can limit the development of the library itself; the author will no longer be able to introduce all changes to its internal wiring because you’re depending on specific behavior of its internal wiring.
Reading about Microsoft’s adventures in providing backward compatibility in Windows is a good source of information why the “we’re all adults here” can be problematic in the long run. They have to emulate their own internal structures that were never APIs, because lots of “clever” application programmers of big and popular applications used parts of Windows that were basically private fields or methods.
Lots of languages do allow the user to use private fields if there’s absolutely no choice, i.e. Java allows to use reflection to use private fields. And by using reflection at least you’re forced to check if the thing you’re trying to use actually exists, because it very well might be removed in some new library version, without notice from the author.
Just to clarify, Dart’s language visibility (public vs library-private) is not simply a naming convention but enforced by the compiler toolchain, static analysis, vm runtime etc. Note that Dart’s concept of ‘private’ is library-private, not class-private. That is to say that private API is visible to all code within the same library: a source file plus any other source files making up that library via ‘part of’ directives.
For me it’s more the fact that there are several good options available already. I do not see any reasons to introduce yet another language into the current mix. Why didn’t they just go Typescript for example?
I suspect the oldest is circa mid-1990s: chunks of 3D CAD software used by naval architects/shipyards to design everything from yachts to tankers, compute the most efficient way to nest the parts on plate steel stock, and drive NC cutting machines. More recently, I suspect a decent whack of 2000s-era equities trade allocation software used in a big bank is still chugging along processing trades, specifically the bits relating to Japanese markets.
I’m an engineer on the Flutter team who spent three years working on Dart before that, so you should keep my potential biases in mind as you read my answer.
If your goal is to have fun, Dart is very quick to pick up for anyone familiar with Java or C++. Think Java without as much boilerplate. If your goal is fun, there are far flashier choices – Dart falls squarely on the ‘boring’ end of the language spectrum, but it’s simple and easy to get productive with. You can pick up the basics in an afternoon and be familiar with the bulk of the language and core libs within a week. Effective Dart is a decent resource for answering style/usage questions you might have.
As to whether you should try Flutter, I’d encourage you to give a couple codelabs a go and decide for yourself whether it fits your interests. Things I feel we do well today are the fast edit-refresh dev workflow, clean encapsulation of state, and UI-as-code. I realise that last point may be controversial – see Gilad Bracha’s A DOMain of Shadows for one take on this. Where Flutter still has some very rough edges are in our support for adding Flutter to existing apps, fully interoperating with existing Android and iOS tooling, and (to some degree) in the difficulties associated with compositing core UIKit/Android views within Flutter views. Given the goal is fun, I’d equally encourage you to play with other frameworks and see what best fits your personal preferences.
As to whether Dart/Flutter will be around in a few years, this is a question that developers have been asking since before Dart 1.0 in ~2013. I can’t read the future any better than anyone else, but I can say there are millions of lines of Dart checked in at Google powering many core revenue-generating apps (e.g. AdWords web and mobile), so I’d like to think that’s somewhat decent assurance we’ll be around for a bit.
Going to survival in the woods with my kids, cycling and cramming for JLPT N4.
がんばれ！I’ll also be doing some JLPT practice this weekend. I’ve been working on improving my reading speed in particular.
At work we use four random words a la correct-horse-battery-staple for buildbots. At home I have a couple themes. Japanese tree names (matsu, ume, kaede, momiji, etc.) for desktops. For laptops, I use names of islands on the west coast of British Columbia where I grew up (saltspring, denman, valdes, thetis, etc.). Both of those have a nice abundance of choices.
Does anyone know what he is referring to here? Or what a “snow job” is?
“Snow job” is an older term that simply means saying a whole bunch of stuff to try and persuade people to believe a lie. The image is of a constant barrage of arguements that eventually overwhelms the truth and buries it from view. Think big snowfall that will take a lot of work to dig the truth back out.
Similar to a “gish gallop”: https://en.wikipedia.org/wiki/Gish_gallop
Not too similar, one is an argumentative style to beat down the opposition, the other is a persuasive technique for an arbitrary audience.
Also the gish gallop has political ties and speaks to the speaker belonging to an in crowd. Snow job is neutral.
UD defines it either as
I think it’s that term, rather than the one offered below it (NSFW).
Ok, wierd term. But do you know what happened between him and Jobs that could be described that way? I always thought that Apple was more or less parallel to Free Software (with the exception of adopting some terminal tools).
Might have to do with Jobs asking Stallman to distribute GCC as two programs, so that NeXT doesn’t have to release the source code to the Objective-C frontend for GCC that they wrote[1].
Just a guess but perhaps he’s referring the the controversy around the original APSL or Eric Raymond’s participation in that announcement? Perhaps he had also been approached by Jobs?
I can’t find a video clip of the event and my memory is hazy (this is ~19 years ago at this point) but I remember Raymond being onstage at an early OS X event to announce that the (at the time) new APSL licence and state that it met the OSD definition. Raymond makes a reference to it in this comment, which elaborates on this line from the article it comments on:
I have no idea.
Reality distortion field
Still in Kyoto for vacation, so I might check out some local arcades. I’ve heard there’s a nice bridge over east, too, but Sunday’s supposed to get really hot, so maybe not yet.
Won’t get you out of the heat, but you could head up to Kurama station on the north side of the city, do some hiking in the forest, and have lunch/dinner on one of the platforms suspended over the river. Makes for a pretty fun day trip!
Working with architects on renovating a 150-year old Kyōmachiya and trying to imagine ways to move back to Kyoto while continuing working on engineering challenges I’m passionate about. Sadly, Kyoto’s not exactly a major tech hub.
I have written lot of scrapers too in Python (I also create my own basic framework based on BS4 + aiohttp in order to plumb my own scraping pipeline), but right now I think Golang is a lot faster and very easy (using colly+goquery). I am not using REPL for Python, then it’s not an issue me. Anyway you can use Go Playground in order to have something similar to REPL. Golang is less “battery included” comparing to Python, but concurrency is amazing
Canadian living in the US:
The most consistent difference I notice is that almost every Canadian or British person I know pronounces “char” as in “charred” but my American colleagues, almost without exception, pronounce it as “care”.
American here; I say “char” as in flame. But if I were going to make it short for “character” I’d pronounce it more like “carr”, i.e. “carry” without the final syllable.
I seem to recall switching from “datta” to “dayta” due to watching Star Trek: The Next Generation, but I still say “stattus”, not “staytus”.
I hadn’t previously heard of NanoGUI but the code examples look clean and readable and the dependencies look minimal. Curious if anyone here has experience using it, and if so what feedback you have on the pros and cons.
I’ve written a couple apps now with it (including a demo that was part of the release of flutter_web at I/O a couple days ago), and I’ve been a huge fan since I first worked with the alpha ~1.5 years ago.
Background: Been a mobile dev on both platforms since v1 on both platforms, I’m stronger on Android through.
Upsides:
flutter doctor- https://flutter.dev/docs/get-started/install/macos#run-flutter-doctor - which diagnoses problems not only with your flutter install but with the native build systems for both iOS and Android. And it outputs command line suggestions to fix them. This kind of thoughtfulness is everywhere.False downsides:
Real downsides:
Happy to answer any questions.
While I tend to agree for the most part, non-nullability/optionality and value types are a current gap, and I find both help significantly when reasoning about the code. For the most part though, Dart was designed to be familiar and productive. I think it’s been successful in those regards, despite its perceived blandness.
That said, it’s worth noting that the language team is dedicated to evolving the language. Over the years we’ve seen both large changes like the addition of a strong type system, as well as smaller improvements such as making the
newkeyword optional, driven in part by feedback from Flutter users.I work on the Flutter team; here are two more:
Flutter is really nice, at least for an inexperienced mobile developer as I am, but Dart the language is not so awesome. I understand Google wants to have full control over an ecosystem, especially after their adventures with Java and Oracle, but I just wish there would be something else than Dart for Flutter.
What is it that you don’t like about Dart?
Dart promises strong type system, but some type errors are thrown in runtime step instead of compilation step, while in other languages, even older ones like C++, the same class or errors are caught in compilation step.
Types are optional instead of mandatory; it’s possible to just skip type annotations and use
dynamicwhich is likevoid*, or it’s possible to just don’t specify the type at all, which has the same outcome I think (the ‘dynamic’ type).Public/private fields are specified only as a naming convention instead of being supported by the language. I.e. private fields are named with an underscore before the name. I mean, if something has its own convention of doing things the right way, then maybe a new language should have support for it? I get that Dart is not really new, but it’s not old either.
(this is pretty subjective, but still) It uses
<type> <variable_name>notation instead of<variable_name>: <type>(postfix) notation, which makes it feel that type inference was not a part of the original design document, but was hacked at some later stage (but I haven’t researched if that’s the case),the arguments come all the way down to some pretty subjective and not very important things (like that I have to write
void main:P, or when I declareint mainand return error code, Dart silently ignores this and returns0to the shell instead), that bothers probably only me, so I’ll skip them.FWIW, Python also works this way, and I really like it. It’s what I call (or maybe I’ve heard it called) the “we’re all adults here” approach. Languages that strictly enforce private vs public have a problem sometimes where a library author makes something private that you want to use, and you can’t get at it. With a convention you can indicate something is supposed to be private, but users can still access it if they decide they need to.
I understand your point of view, but I respectfully disagree with it. Normally private parts of a library is not an API, and by using it you’re increasing the risk of your project not being compatible with future versions of the library, so you’re limiting yourself. If your project is massively popular, up to the point that its popularity surpasses the popularity of the library, using libraries private fields can limit the development of the library itself; the author will no longer be able to introduce all changes to its internal wiring because you’re depending on specific behavior of its internal wiring.
Reading about Microsoft’s adventures in providing backward compatibility in Windows is a good source of information why the “we’re all adults here” can be problematic in the long run. They have to emulate their own internal structures that were never APIs, because lots of “clever” application programmers of big and popular applications used parts of Windows that were basically private fields or methods.
Lots of languages do allow the user to use private fields if there’s absolutely no choice, i.e. Java allows to use reflection to use private fields. And by using reflection at least you’re forced to check if the thing you’re trying to use actually exists, because it very well might be removed in some new library version, without notice from the author.
Just to clarify, Dart’s language visibility (public vs library-private) is not simply a naming convention but enforced by the compiler toolchain, static analysis, vm runtime etc. Note that Dart’s concept of ‘private’ is library-private, not class-private. That is to say that private API is visible to all code within the same library: a source file plus any other source files making up that library via ‘part of’ directives.
See section 6.2 of the spec for details.
For me it’s more the fact that there are several good options available already. I do not see any reasons to introduce yet another language into the current mix. Why didn’t they just go Typescript for example?
I suspect the oldest is circa mid-1990s: chunks of 3D CAD software used by naval architects/shipyards to design everything from yachts to tankers, compute the most efficient way to nest the parts on plate steel stock, and drive NC cutting machines. More recently, I suspect a decent whack of 2000s-era equities trade allocation software used in a big bank is still chugging along processing trades, specifically the bits relating to Japanese markets.
I’m an engineer on the Flutter team who spent three years working on Dart before that, so you should keep my potential biases in mind as you read my answer.
If your goal is to have fun, Dart is very quick to pick up for anyone familiar with Java or C++. Think Java without as much boilerplate. If your goal is fun, there are far flashier choices – Dart falls squarely on the ‘boring’ end of the language spectrum, but it’s simple and easy to get productive with. You can pick up the basics in an afternoon and be familiar with the bulk of the language and core libs within a week. Effective Dart is a decent resource for answering style/usage questions you might have.
As to whether you should try Flutter, I’d encourage you to give a couple codelabs a go and decide for yourself whether it fits your interests. Things I feel we do well today are the fast edit-refresh dev workflow, clean encapsulation of state, and UI-as-code. I realise that last point may be controversial – see Gilad Bracha’s A DOMain of Shadows for one take on this. Where Flutter still has some very rough edges are in our support for adding Flutter to existing apps, fully interoperating with existing Android and iOS tooling, and (to some degree) in the difficulties associated with compositing core UIKit/Android views within Flutter views. Given the goal is fun, I’d equally encourage you to play with other frameworks and see what best fits your personal preferences.
As to whether Dart/Flutter will be around in a few years, this is a question that developers have been asking since before Dart 1.0 in ~2013. I can’t read the future any better than anyone else, but I can say there are millions of lines of Dart checked in at Google powering many core revenue-generating apps (e.g. AdWords web and mobile), so I’d like to think that’s somewhat decent assurance we’ll be around for a bit.