Learn Dart in 15 Minutes - <AUTHOR> http://learnxinyminutes.com/docs/dart/

<comment><USER2> This has got to be the worst learn x in y minutes that I've ever read. Whitespaces, anyone? Every example is compacted and very hard to read. Comments should document each line instead of a huge wall of text before the function.

Naming everything ExampleX is very difficult to see what is being talked about in this particular function.

I'm lucky to know enough about Dart already, because this is a very bad representation of it, IMO.

<comment><USER3> Perhaps you could contribute to the file via a PR instead of ranting at a post on a news aggregator? If people like you did then the open source community would be a better place.

<comment><USER4> "Make a pull request" is not a proper way to respond to valid criticism of open source projects. Is it not obvious how fallacious that argument is?

</comment></comment></comment><comment><USER5> There's an error in the section on literals. Literals used outside of classes do not have to be const. Not sure where that notion came from, but this is totally valid:

        var l = [];

Also, the example of looping over characters in a String using substring is very odd and expensive. Generally, if you want to iterate over a list of single-character Strings, you'd use String.split():

        for (var c in str.split('')) {}

split('') is necessary to be unicode safe. There's also String.codeUnits and String.runes (an iterable of code-points).

</comment><comment><USER6> I love Dart, I think it's a great language. I hope that Google will start supporting it natively in Chrome.

<comment><USER7> They are. Check "In Development" section.

[http://www.chromestatus.com/features/6682831673622528](http://www.chromestatus.com/features/6682831673622528)

So in a few months we will have Google's VbScript available in Chrome.

<comment><USER5> The VBScript comparison dig is as old as it is wrong.

VBScript was IE only, because VBScript didn't compile to JavaScript. Dart compiles to JavaScript and runs on IE, Safari, Chrome, Firefox and Opera. VBScript didn't have a specification accepted by any standards organizations, Dart is ratified as ECMA 408. VBScript is not open source, Dart is.

The fact that Dart has been used in production years before any VM in a browser should show how different they are.

<comment><USER7> > Dart compiles to JavaScript

Not all language features can be represented in JavaScript.

Besides, all the languages that compile to JavaScript just add complexity layers to the already complex model of HTML/CSS/JavaScript.

And I bet there is a VbScript to JavaScript somewhere out there.

> Dart is ratified as ECMA 408. VBScript is not open source, Dart is.

Standards by themselves don't foster adoption.

Eiffel, Ada, Modula-2, Extended Pascal, Common Lisp, Smalltalk, ... have ISO/ANSI standards.

In the 60 - 90's being open source wasn't a requirement for multiple implementations for programming languages.

<comment><USER8> Context: I'm using Dart for app development for two years now.

> Not all language features can be represented in JavaScript.

I could not name one (except the dart:io stuff, which is not supported in the JS world). Could you please elaborate?

> Besides, all the languages that compile to JavaScript just add complexity > layers to the already complex model of HTML/CSS/JavaScript.

I've found the same, but Dart is a surprising exception. If you are not using any fancy framework (e.g. Angular.Dart), you will be just fine with the close- to-the-browser approach of the language and APIs.

<comment><USER9> The main example is that Dart's basic numeric types can't be represented in JavaScript. Dart VM integers are bignums, while dart2js numbers are IEEE754 doubles.

<comment><USER10> That's for performance because I guess the majority of users would probably not notice the difference.

They _can_ be represented in JS, but not natively.

<comment><USER9> Yes, the decision to make numeric types incompatible between the VM and dart2js was due to speed concerns.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> One of the examples reminded me of some xml/html trivia I picked up a few years back -- attributes do not need to have double-quotes. (Yes, in practice you can leave out quotes altogether if the attribute has no spaces because browsers are tolerant, but the _spec_ allows for single or double quotes, so if you're going to parse markup you need to allow for both.)

It occurred to me that HTML5 might have tightened up this rule, but it remains as before:

[http://www.w3.org/TR/html- markup/syntax.html#attribute](http://www.w3.org/TR/html- markup/syntax.html#attribute)

<comment><USER12> Note that XML attribute values _do_ need to be quoted, so this is only true for HTML and not XHTML.

</comment></comment><comment><USER13> It seems to me that the majority of the time learning any new language is not the syntax itself, but memorizing function names and parameter order. Has there ever been an effort to design a family of languages which use the same function names and order of parameters for the same operation so that switching between them would be a matter of learning basic syntax?

</comment><comment><USER14> This seems rather odd from example 14:

        // Boolean expressions need to resolve to either true or false, as no
        // implicit conversions are supported.

I'm sure they have good reason for this, does anyone know of the rationale? I think I'd miss patterns like `if (arr.length) { ... }`

<comment><USER15> I think this is wrong or at least misleading. According to the Ecma standard:

      Boolean conversion maps any object o into a boolean. Boolean conversion is defined by the function application
      (bool v){
        assert(v != null);
        return identical(v, true);
      }(o)

<comment><USER16> Reading your quote from the ECMA standard, "no implicit conversions are supported" may be wrong but at the same time _not_ generally misleading. That is, that function errors on null values and returns false for anything that isn't identical to true, so while it _does_ provide a conversion to boolean from any non-null value, anything that isn't exactly a boolean "true" (unless I misunderstand what "identical" does) is going to return false on conversion. This is consistent with other writings on booleans in Dart [1]. So it appears that Dart _has_ implicit boolean conversions, but it converts everything that is not the single "true" value to false, so using an expression that never can evaluate exactly to boolean true in a conditional (unless you _mean_ it to be a wordy way to create unreachable code) is never something you want to do.

[1] [http://blog.sethladd.com/2012/02/booleans-in- dart.html](http://blog.sethladd.com/2012/02/booleans-in-dart.html) "The only value that is true is the boolean value true. [...] In a boolean context, everything that is not true is converted to false."

</comment></comment></comment><comment><USER17> I like Dart, but Polymer code converted to JavaScript doesn't work on IE11, just Chrome.

</comment><comment><USER18> looks cool!</comment>


2014 F1 explained: What is brake by wire? - <AUTHOR> http://www.racecar-engineering.com/articles/2014-f1-explained-what-is-brake-by-wire/ <comment><USER2> With the endless and quite arbitrary rules and limitations they impose on the F1 cars each year I sometimes wonder what would happen if they hadn't done that. What would the teams have built if it weren't for the weigh, power, and technology limitations shaping the development?

I see an analogy to evolution versus controlled genetic reproduction: what would the F1 cars look like and how would they behave if the only thing that mattered was being the fastest and winning races?

<comment><USER3> If you gave an F1 team their same budget with no restrictions, you would get an incomprehensibly fast car. I'd bet on them going with 6 wheels: 4 in front, two in back for more traction when turning and braking, similar to the Tyrrell P34.[1] They'd likely use ground effect with fans to provide active downforce, similar to the Brabham BT46B.[2] It would probably be driven by electric motors in each wheel. The power source would be a gas turbine attached to a generator.

It would be a death trap. If the suction fan malfunctioned, all downforce would be lost and the car would skid off the track. G forces when accelerating, braking, and turning would quickly injure even the toughest human being. Going around any track would require superhuman reaction times. Such a vehicle could only be controlled by a computer. Also, such a vehicle could only be painted plaid.

I'm not sure how profitable or safe this hypothetical series would be, but I'd certainly watch the first couple of races. Then again, I'd also watch cyborg kickboxing in some future version of the Paralympics.

1\. [https://en.wikipedia.org/wiki/Tyrrell_P34](https://en.wikipedia.org/wiki/Tyrrell_P34)

2\. [https://en.wikipedia.org/wiki/Brabham_BT46#Brabham_BT46B.C2....](https://en.wikipedia.org/wiki/Brabham_BT46#Brabham_BT46B.C2.A0.E2.80.93_the_.22fan_car.22)

<comment><USER4> You would probably end up with something like the Red Bull X2010.

[https://en.wikipedia.org/wiki/Red_Bull_X2010](https://en.wikipedia.org/wiki/Red_Bull_X2010)

The digital creation was a response to Kazunori Yamauchi's question: "If you built the fastest racing car on land, one that throws aside all rules and regulations, what would that car look like, how would it perform, and how would it feel to drive?"

<comment><USER5> > "If you built the fastest racing car on land, one that throws aside all > rules and regulations, what would that car look like, how would it perform, > and how would it feel to drive?"

The big question is whether it would qualify as a "car".

</comment></comment></comment></comment><comment><USER6> Hmm, why not simply always use the recovery system but just not store the energy in the battery if it's full already (or capacity reached or whatever)?

<comment><USER7> where do you suggest this energy should go? it's not like there's room for a bird burner on an f1 car.

<comment><USER8> Why not power up some tesla coil on the rear of the car that produces cool electric arcs all over the track.

Lets face it, some of the coolest parts of high power cars are dispersed excess energy, glowing brake discs or flaming exhausts and of course screaming engines.

<comment><USER7> yeah, that's the point. the brakes are smoking hot, so if you suddenly start to collect that energy it needs to go somewhere.

<comment><USER9> I think you missed the question/point: traditional brakes work by converting kinetic energy to thermal energy and dissipating it. The ERS base is to convert it to electric and store that.

ERS obviously can't store things when the battery is full, but if the issue here is the transition between ERS and traditional why not have ERS bypass the battery when it's full and dump energy in a radiator, ending up with the same result as traditional brakes (kinetic -> thermal) without having to switch braking system in the midst of braking?

<comment><USER10> I think you missed the first answer. There is no place for it. It's big, heavy and needs to be exposed.

</comment></comment></comment></comment></comment></comment><comment><USER11> I really wonder how this works. Is this some generator held by the rear brakes ? How do they enable/disable this generating system when braking to go back to normal braking ?

And why the hell did they set a maximum amount of recoverable energy ? Seems like a additional, unnecessary puzzle that seems to make things harder for pilots...

<comment> k-mcgrady >> "And why the hell did they set a maximum amount of recoverable energy"

One reason is that the energy is used for KERS, a boost system (press a button for increased speed). Each driver is limited to a certain amount of this boost per lap.

It's also possibly for safety reasons. Before a car pits or anyone can safely touch it all recovered energy must be discharged. If the car is in an accident and this isn't possible the less energy stored in the car the better.

<comment><USER12> Note that the "boost button" disappeared in 2014 [1]. (K)ERS usage is not controlled by the driver anymore [2]:

[1] [http://www.bbc.com/sport/0/formula1/25158104](http://www.bbc.com/sport/0/formula1/25158104)

[2] [http://www.formula1.com/inside_f1/understanding_the_sport/87...](http://www.formula1.com/inside_f1/understanding_the_sport/8763.html)

</comment></comment></comment><comment><USER13> I'm envisioning a lightning rod at various stages along the track to discharge the extra energy... :)

</comment><comment><USER3> I'm amused that F1 cars now have a computer mimic manual brakes. It seems schizophrenic to allow advanced technology such as kinetic energy recovery, but ban traction control, active aerodynamics, anti-lock brakes, and dozens of other technologies that are in consumer vehicles. The excuse I typically hear is that these restrictions make races depend more on driver skill instead of team budgets. Do people not realize that the teams with the biggest budgets are the ones who can afford the most talented drivers? And it shows: The teams with the most money are the ones that consistently win.

I think F1 would be much more exciting if they tweaked the aerodynamics and vehicle size to allow more passing. If race excitement can be boiled down to one metric, it's passing. If you've seen a MotoGP race, you'll probably concur.

<comment><USER14> Life is often not quite as simple as that!

There are various other reasons for why it is easier to overtake on a motorbike in MotoGP compared to F1. There has been many introductions to ease overtaking in F1 recently - DRS, KERs (now ERS), tyre compounds etc.

There is even a working group within the FIA dedicated to exactly this, one of it's most famous studies is the CDG wing (see [http://www.f1technical.net/articles/4577](http://www.f1technical.net/articles/4577)) - which ultimately was not adopted.

<comment><USER15> Thanks for the link on the CDG wing - I did not know that. Any ideas why it was not given a go? It seems vastly more in the spirit of racing than the 'push to pass' DRS that has not been exactly popular with the dedicated fan. I don't think the Pirelli tyres have been that popular with fans either. The CDG wing appears a lot more true to the spirit of what racing is about.

<comment><USER14> I think it was ultimately concluded that it wouldn't work in practice as well as the preliminary CFD results suggested. It was an interesting study none the less.

</comment></comment></comment></comment><comment><USER16> Rougly speaking, an electric motor acts as a generator when you turn it.

</comment><comment><USER15> I think it is shocking that after a century of motoring this idea of energy recovery from the brakes is 'new fangled'. It should have been made mandatory back in '73\. Even if lithium batteries weren't available then every car has a battery, usually of the lead acid variety, plus there are things like flywheels that can store potential energy.

<comment><USER12> Formula 1 is a sport. The game is about building the most performant machine within the constraints of the rules. There is a ton of technology that is prohibited in F1 (traction control, automatic gear shifting, ABS, etc) that has been part of road cars for decades. Rule changes tend to relax the constraints from time to time for some specific reason: such as better safety, better spectacle, or cost reduction. KERS (with its driver-controlled boost button) was introduced in 2009 mostly as an attempt to facilitate overtaking, since car aerodynamics had become so sophisticated that a car following another one would get a significant drop in downforce due to the turbulence of the car in front. On the other hand, the 2014 rules appear to have been enacted mostly to help teams lower their running costs.

<comment><USER17> I think it's time we have an F1 alternative with only unmanned cars where we aren't concerned by passenger safety and can focus on pure speed.

<comment><USER18> That's an intriguing thought, but I fear it would soon devolve into guided missiles ...

<comment><USER19> I'd watch that... F1 without drivers but with weapons... it'd be like a real live and super-expensive version of Mario Kart...</comment></comment></comment></comment></comment>


U.S. Navy Deploys Its First Laser Weapon in the Persian Gulf - <AUTHOR> http://www.bloomberg.com/news/2014-11-14/u-s-navy-deploys-its-first-laser-weapon-in-the-persian-gulf.html

<comment><USER2> I wonder if the Navy will run into issues with the international legalities of blinding people?

From what I understand it is legal to kill someone (under self-defence like conditions), but illegal to blind them. However the US has been skirting a lot of international law by declaring everyone they fight a non-soldier which counter-intuitively allows them to do more harm.

I just ask because they talk about a "warning shot that gets progressively more powerful" in the article. Which to me means at some stage it will be in the range to do eye-damage before it can set the boat on fire.

Also interesting that they could accidentally destroy a satellite while targeting a drone.</comment>


Tad – Free early stage BIM software for architects - <AUTHOR> I would appreciate if architects (of the building variety)use TAD free from www.teamtad.com  It is a very different approach from conventional BIM software; and it was in use since 1989. I would deeply appreciate any feedback. Thanks! <comment><USER2> Clicky: [http://www.teamtad.com](http://www.teamtad.com)

IANAA [I am not an architect.]

I always ask for screenshots. They are at the middle of the page, near the bottom.

> In order to use TAD, you must get a free registration.

I guess most people don't want to send their data. Can you make this completely free to use for 1 week or 1 month?

Can I export the files to more usual formats, like Autocad? (perhaps loosing some details)</comment>


Coding is Over - <AUTHOR> https://medium.com/@loorinm/coding-is-over-6d653abe8da8#.ixfq42smv <comment><USER2> > But is [coding] the most intuitive and productive approach?

Intuitive: no. Productive: Well, we haven't found anything better for building software. What would you like to compare it to?

> I used to make electronic music with a program called Reason. I loved it > because it let you drag and drop wires between different machines, showing > you exactly how everything was connected.

Ever seen a call graph of a non-trivial piece of software? It shows you how everything is connected, but it isn't usually useful on an intuitive level.

> But most of what we do is not engineering. Being an engineer is about > solving new problems, and about deep thinking. It's intellectual work.

Who's "we"? I write software when I can't find something suitable that's already been written. I design it, work out use-cases, come up with a set of requirements, and build it.

> Real engineers code, they say, and coding is what makes you a great > engineer.

"Real engineers" do a lot of things. "Code" is somewhere in the middle of the list, after a whole lot of analysis and design, and before a support cycle. Not all people that are called engineers are engineers.

> These are just a few examples of how engineers waste time duplicating the > same basic features over and over.

...but as meaningfully different implementations. Unless the author would like to adapt some C code. The stone wheel is heavy and hard to carve. The wood wheel is easier, but flimsier. The metal wheel is easier, stronger, and lighter, but it's still "reinventing the wheel". Doesn't mean that it isn't sometimes worthwhile.

> Software engineers are grossly overpaid

Define "overpaid". I'm paid roughly what the market will support in my area. If the market's broken, then it's ready for disruption, and you're in a position to become very rich when you figure out how to take advantage of it.

The author bounces around all over the place. I like the core idea of the article (which I take to be simplifying work where possible and avoiding duplicate effort), but there's so much slop and fluff around it that a basically good idea is just buried.

</comment><comment><USER3> This was painful to read.

Yes, writing code is inefficient. It's unfortunate it's the best way yet to create computer systems.

Yes, a lot of work in programming is line of business applications with slight customization and implementing specific business rules.

Yes, it'd be amazing if we achieved something smart enough that a set of data, business rules and requirements in human language could be used to generate an application. That would be amazing. So would flying cars and living on the moon.

Feels like the author has no context on how difficult their suggestions are to implement, and the point about how we're already there because of GraphQL (?!) and Algolia support it.

</comment><comment><USER4> Coding is not over. I too once thought as you did.

In a previous job, I worked extensively with LabView[1]. Like Reason, you hook up wires to little boxes. This enables graphical dataflow programming.

LabView enables a person with no knowledge of syntax to write a program. It's great! Until your program grows in size. Then, you have a very large and very difficult to understand system of boxes and wires. Debugging becomes increasingly difficult. Users can abstract the wires and boxes away into more boxes, but after more than a few layers of turtles, you start wondering why you're even using a system like this.

Later on I discovered that LabView was an instance of a "4GL" and that such things had been around for decades. Although some have been successful in certain niches, to my knowledge no 4GL has ever succeeded as a general purpose programming language.

Why is this? It's because textual programming languages are far more general and expressive. Programs written in text are far easier to change, version control, and understand. There is no silver bullet[2].

[1] [http://www.ni.com/labview/](http://www.ni.com/labview/) [2] [https://en.wikipedia.org/wiki/No_Silver_Bullet](https://en.wikipedia.org/wiki/No_Silver_Bullet)

</comment><comment><USER5> The author's twitter says that they just graduated from a coding bootcamp. I am not trying to silence anyone- but maybe its too soon to be making such claims.

</comment><comment><USER6> Unfortunately, I've had several idiot project managers like that, who just do not understand the "point" of coding, and don't understand why project development takes as much as it does, why there are bugs, etc.

These people are not fit to be project managers. You cannot manage what you don't have a basic understanding of and appreciate.

</comment><comment><USER7> I love this post. I think that when most apps look the same, you start to wonder why we can't just fill in some data and regenerate the UI again. A lot of UI builders work this way anyway: you drag and drop stuff, hook up events to functions, etc.

Why are we still building CRUD apps in 2016? Building that with any tech is just boring, whether it's COBOL, Java, Ruby, or node.

This is the way tool building works. You sharpen a rock so you can work with wood, you work with wood so you can build a trebuchet, you build a trebuchet so you can go to the moon.

I've said it before and I'll say it again. The next breakout programming platform probably won't be terminals and editors. It'll be something that sparks creativity, like the author's Reason example. Mobile apps allllllmost got there; can you imagine if even 1/1000th of Snapchat users had an easy way to program their phones?

Don't be so quick to dismiss someone based on their writing style or their "lack of" education. This is an optimistic, creative article, and it contains a lot of sophisticated insights like this:

> More than that, it allows for infinite "creativity", also knows as code > smells. Most code is pretty rank. Engineers spend countless hours dealing > with syntax, typos, indentation, linting, errors, arguing over style and > best practices, and making shortcuts to try to coax some of the code to type > itself. It's absurd. And it's a waste of time.

That's all 100% true.

<comment><AUTHOR> thanks camgunz. Like I said in my post, I knew this would be very unsettling for many people who have built their lives and identities on coding.

</comment></comment><comment><USER8> yeah okay... i feel like the author is way too simplistic in her thinking. "coding is over" is akin to house building is over. we know to build every part of a house so why re-invent the wheel? why not have some magical machine that just builds whatever we can dream of?? there are a lot of nuances and things to think about depending on what you're trying to accomplish.

i do think we need to be optimistic about a world where coding is something magical where you can build anything you imagine like some lego set, but there is a huge leap between making some example todo list or implementing a basic user auth system and a full fledged web app and i think she fails to understand that.

at it's core ever app is CRUD, just like a house is walls and a door or a car is wheels and whatever.

</comment><comment><USER9> Why can't we just throw data into a database and have it optimize it?

Well I suppose we could. We could probably build a set of tools that optimized a database of separate tables with connections between them. That's not a horrible idea, I'm reasonably sure we do some of that, though we can still reason about things better than algorithms can, much the same way that hand coded assembly can be more efficient for an embedded device then a JVM and byte code.

But the reason we can't just have such a server, graphql and the browser is because not everyone on the internet needs access to everything on a server. Users should have access to their data, not everyones. You need business logic.

I think they are right that rebuilding the same parts of crud apps is a waste of time, but often the parts we rebuild over and over are abstracted into libraries, modules, classes, packages, gems, etc. And you need to build a few crud apps before you see the commonalities that can be abstracted.

We aren't handcoding bytes on a wire with a telegraph key, we aren't writing a web app in assembly, and that's because we build tools and frameworks and languages. But those tools, etc. still need to get built, and are still being improved, and that means the crud app you built in 1990 with perl and CGI and apache running on slackware, while perfectly servicable, isn't as responsive or useful as the app you build today. And even that 1990 app had CPAN... and CPAN was an innovation. And even perl is still used today, in stuff I use everyday, like git on the command line.

I guess what I'm trying to say is that we stand on the rickety shoulders of giants, and being an engineer means both having the beautiful abstraction to build grander visions and see great vistas before us, as well as to cover over the framework with dry wall CRUD and make it look smooth, and also to climb down and into that framework, and write compilers, parsers, databases, machine learning code, virtualization software and software to manage concurrency between network nodes, to create all of the pieces that we create to make those heights scalable.

That said, I'm appreciative of them for sharing their vision, and think they deserve better than to be insulted ad hominem, instead of having what they wrote critiqued.

</comment><comment><USER10> To provide some actual constructive criticism (seriously, everyone?), yes, there is overlap in apps made today. As a result, if tech companies want to stand out when everyone has access to the same tools, they have to code, and code the best.

Game theory is fun like that.

</comment><comment><USER11> I'm sorry but the quality of this article is just too low for my taste.

</comment><comment><USER12> While the basic idea behind the article is very nice, its not really ready yet. People try all the time, and you end up with stuff like SAP (which still needs coding). I think the only way you can remove the coding (apart from basic: click button -> do: XY) is to advance AI to a point where you can just request an application with basic specs and its made. However, that looks like its still a few years away.

</comment><comment><USER13> So the future of software is basically PLC programming[1], which has been dying out and slowly getting replaced with cheap ICs or arm chips.

[1] [https://i.ytimg.com/vi/xfKXeLj84wY/maxresdefault.jpg](https://i.ytimg.com/vi/xfKXeLj84wY/maxresdefault.jpg)

Also some dbs already have a REST interface out of the box like Riak, though I dont see the far more popular databases going anywhere in the near future.

</comment><comment><USER14> Some good points buried in here (especially about the over-glorification of coding), but lots of wrong or irrelevant points:

> Have you ever wondered why we need a server acting as a middleman between > the client and the database?

Well, not recently; without it you have a two-tier architecture instead of three-tier. Two-tier architectures have been used a lot, are well-understood, and are suitable for some applications. Using them doesn't eliminate coding, though.

> Algolia makes a pile of data searchable. I'm not sure how they do it. But > what I do know is, a computer is cheaper and better at optimizing structured > data than a human is.

I'm going to make a wild guess that there's some coding going on to achieve that.

> We should be throwing data into a pile and databases should organize and > optimize themselves using machine learning and other buzzwords.

Building systems that use "machine learning and other buzzwords" to acheive, well, anything often requires a non-trivial amount of coding. So, really, this isn't just talking about a preference for a different locus of coding. Which isn't entirely invalid (though it seems to involve a lot of attribution of magic to tech that the author isn't familiar with the implementation of), but is a long shot from coding being dead.

> People should not be writing database schemas, because we inevitably get it > wrong. Database design is an optimization algorithm, not an area of > engineering.

To a certain extent, its an optimization problem. That doesn't take it out of the domain of engineering. And, yes, there may be tools that can be coded to take some of the gruntwork out of doing that. And, in fact, plenty that have: but mostly those end up being productivity multipliers for coders on specific applications, rather than eliminating coding for specific applications.

> Product Managers should be able to just make the app do what it's supposed > to do, without knowing how to code at all.

And everyone should have a pony.

> The only thing a company should be creating are the things that make their > product unique.

Unfortunately, everyone that's been there first hasn't necessarily released all their work as open source, so if you want "like X but with unique Y", you often need to build X and Y. Once the company that built X first -- when it was unique -- spent the effort, they may not want to give it away.

> My current undertaking is to build an easy-to-use drag-and-drop interface, > where anyone and everyone can construct fully-featured, full-stack apps, > with no coding.

Coding using a visual rather than textual language is still coding. And tools that replace some coding with visual drag-and-drop diagram manipulation have been used in lots of places, for ages. They definitely have their place, but they generally fail to succeed at being anything more than adjuncts to textual programming for most serious work.

</comment><comment><USER15> To put it mildly, I don't get the feeling that the author is much of a coder, and is suffering from Dunning Kruger.

</comment><comment><USER16> This author is crazy.

<comment><USER6> Not crazy, just stupid in software development.

</comment></comment><comment><USER17> here we go again</comment>


"I'm going to work for a few years and then start a company" - <AUTHOR> http://blog.lawnstarter.com/post/80945599254/im-going-to-work-for-a-few-years-then-start-a

<comment><USER2> While I do think there is some amount of maturing that goes on in a job with a big company, I agree with this for the most part. I improved my technical skills dramatically working as a software engineer, but I still could have easily started my company without that experience.</comment>


Craftsman's famous lifetime warranty in question after $900M sale - <AUTHOR> http://finance.yahoo.com/news/craftmans-famous-lifetime-warranty-in-question-after-900-million-sale-202603636.html <comment><USER2> Ace Hardware also has a lifetime warranty on ACE branded tools.

"Ace Brand hand tools are guaranteed for life. Our full lifetime warranty states that if any Ace Brand hand tool, used for its intended purpose, fails to fulfill your expectations, return it to any Ace store location for a free replacement of the same or similar item. This warranty provides you with the ultimate quality assurance."

I worked at one in high school and bought a ton of tools at discount. Customers regularly came in, bought a tool such as a drillbit, returned a few hours later after breaking it and were handed a new one on the spot no questions asked.

</comment><comment><USER3> I see this as a sad day for the once-great Sears. Even though the quality of Craftsman tools had been slipping as of late, to see Sears sell off the brand entirely is another step in picking clean the bones of the Sears Roebuck & Company.

</comment><comment><USER4> Possible crapola. I have a ton of modern Craftsman tools in addition to some heirloom Craftsman (wooden-handle screwdrivers), Snap-on, Mac and others. Let's hope Stanley B&D (ticker: SWK) honors Craftsman commitments as a "premium" brand.</comment>


How a WWII fighter pilot learned to love his enemy - <AUTHOR> http://www.mercurynews.com/2017/12/10/this-fighter-pilot-flew-the-last-mission-over-japan-in-wwii-then-he-learned-to-love-his-enemy/ <comment><USER2> _"You know the black guys, they had to do three times as much work just to be accepted because they were black," Yellin said. "And I had to be three times as good just to be accepted."_

The entire time I was growing up in the 70's and 80's, my Korean parents told me, again and again, that this was how it was going to be for me in this country. This is how in-group/out-group psychology works. That's how people are.

There is a huge difference between people who will make you work 3 times harder, but will accept you in the end on merit, and people who won't, no matter what you do. It's the same difference as between people who can listen to and learn from their enemies, and people who can't listen no matter what. Some people are subordinate to truth and beauty beyond themselves and their particular world view, and some are not. It's the former who ultimately move the world forward and the latter who unwittingly hold it back.

People who see you as a human being, regardless of your outward signifiers? Those people are rare. They are geniuses of one sort or another.

</comment><comment><USER3> The headline doesn't seem to fit the story but thank you for sharing anyway. Yellin never seemed particularly hateful of the Japanese so I'm not sure that he needed to "learn to love them". I guess the headline refers to his daughter in law?

Based on the headline I was expecting this to be the story of Charlie Brown and Franz Stigler [1].

[1]: [https://en.wikipedia.org/wiki/Charlie_Brown_and_Franz_Stigle...](https://en.wikipedia.org/wiki/Charlie_Brown_and_Franz_Stigler_incident)

<comment><USER4> I thought the same was preparing to humm Sabaton's no bullets fly....

</comment></comment><comment><USER5> What a great story!</comment>