fleshweasel

Ask Apple, who hide it from you in Xcode and riddle it with human-unreadable generated IDs and noise elements, in addition to needless reshuffling of elements after editing which overcomplicate your diffs and obscure the meaning of changes. Interface Builder in all its forms is indefensibly bad in execution.

Idempotency is a good example of a trivia term that would be unreasonable to expect most recent CS graduates to know. Not to say that it's not a valuable property for a service or library or whatever to have under certain circumstances-- but it's not a reasonable way to decide whether a candidate for a junior position is a good fit.

I'm a little confused as it looks like an image in the article labels a string literal as being a comment. Am I misunderstanding something?

so..not Go :P

They're promoting this as a new dev environment for .NET Core, but there's still ZERO tooling for Razor. I tried starting a simple example project and the .cshtml files didn't even have any syntax highlighting, let alone syntax/type checking.

I don't know how you work on cross-platform ASP.NET for this long and still not have the tooling for your templating engine ported.

It seems like the "ASCII puke" concrete syntax for regex patterns doesn't scale that well. Regular expressions have binary operators, parenthesization, named groups, lookaheads, etc.-- if you're building a sophisticated regex of more than 10 characters or so, why not have some kind of an object model for this stuff so you can have reasonable forms of composition, naming of intermediate values in construction of a larger pattern, and the ability to attach modifiers to things without needing to pack more @#$%&*!^ un-Googleable junk into string literals?

I don't see why there can't be React-like libraries written and used in languages that compile to native. I'm not expecting to have JSX but I should be able to write component classes and implement their render methods, returning view trees written with some kind of object/array literal syntax.

To get as good of a development experience as React, it would require some work by the compiler and runtime people to basically let you do something like hot loading--Android has something like this now, and maybe Apple will get it too, though I'm not holding my breath.

I think it's a no-brainer for web development these days to do React because 1. you can opt out of it for parts of the page it's not going to work with for whatever reason and 2. the performance is pretty damn good compared to lots of alternatives, including writing all the UI state management logic yourself. However, I've not been convinced that the buy-in is worth it for native mobile development. Can someone who knows more tell me: is it fairly easy to do something like say "I can't/don't want to use React Native for this view controller--I'm going to implement it in code and use it and everything will just work."

I'm pretty sure this is why the Apple online store needs to be taken down for them to add new products.

Do you mean Visual Studio?

The file changing just from being looked at is one of the basic reasons that IB is bad. Apple made a grievous mistake in designing UI markup that is intended to be hidden from developers. Un-organizable, un-diffable toxic sludge.

It's absurd to have to beg the wealthiest software company in the world for what should be considered really basic stuff. Xcode is consistently unstable, slow, missing simple essential functionality (like refactoring), and Apple's interface builder is something that most experienced Apple devs know to run for the hills from.

Every tool for its job. If you have serious dynamic behavior and you try to handroll it yourself, you risk either low maintainability and bugs in your bespoken optimized DOM manipulation algorithm or doing things in fundamentally inefficient ways. That said, people should be cautious about taking on new dependencies, and definitely need to take an evidence-based approach to performance optimization.

Haven't had the chance to try it myself but I have read quite a bit and I like what I see, particularly the high quality error messages in the compiler. However, I think I'd have a hard time getting my team on board with it as we use Visual Studio for the bulk of our development, and we would need to learn to work with the JavaScript interop APIs to do things like try Elm out for a single new feature on a page.

I know what you mean with regard to event handlers being passed down to children and children of children and so on and the complexity that can bring. I haven't used redux, but I understand it as being an attempt to simplify that kind of problem.

I haven't written any higher order components myself, unless you consider parameterizing event handlers in props to be higher order.

One of the biggest reasons I favor React is that it's much easier to add a templating language to a programming language (i.e. JSX) than the other way around. Every construct for making decisions based on your data, traversing your data, etc. is more cumbersome and harder to validate in handlebars or whatever identical looking templating language the community came up with this week.

I also am strongly against string references to model properties in your template. Again, it's much better to use tools that provide some static validation of what you're doing.

Give me React with TypeScript to help me make sure I'm passing around what I said I'm expecting to receive at each point as features are changed and added, and I'll be in business.

Honestly, I use React in spite of my opinion of Facebook.

Server is responding pretty slowly (maybe not used to this much traffic?) so here's a Google cache for it: http://webcache.googleusercontent.com/search?q=cache:lxQe4zC...

They should start paying Tim Cook in dongles.

Get rid of most of the padding and headgear so the players don't feel like they have the ability to take such hard hits--because as far as their brains go, they don't have that ability.

The wait for the new MacBook Pro is agonizing but I am convinced it will sell like hotcakes when it finally comes out.

Do you have any examples you care to share of Swift that needs cleaning up?

Beyond being a little more explicit about the generator semantics, it's just noisier. "Self.Iterator.Element" is a lot of noise compared to "T".

At the moment, I feel these sequence extensions are just allowing people to write toy programs with slightly less boilerplate, and are accomplishing little as far as improving our ability to produce useful software.

Honestly, comparing the choice of mucking with code signing on OS X and having to deploy, run, and debug my app through Docker, I would just learn to sign code.

I do think it's weird that more debuggers don't come as signed binaries--gdb requires you do similar things and it all goes back to OS X's requirement that processes which take control of other processes have to be running signed binaries.

This is great. Seems less cumbersome than TypeScript's user defined type guards for distinguishing cases of a union. The sentinel value concept is something you could at least steal when creating user defined type guards to make them simpler, at least.

Thanks for elaborating on the distinction. User defined type guards can get you some of the way there to distinguishing "int | int", but you don't get it for free-- the reality of being a superset of JavaScript. https://gist.github.com/RikkiGibson/74fa3dbfdb1b2d7ab86d

I strongly disagree about TypeScript-- I think it's a huge boon to productivity. TypeScript has has union types i.e. "number | string" which are similar to algebraic data types. TypeScript also has optional interface members and function parameters by putting ? at the end of the name, i.e. "foo?: number".

Static types allow for much, much better tooling, particularly autocomplete and the ability to check whether your code is valid on some basic levels. I consider avoiding it to be a big waste of time. I've had a good experience getting the definitions files going for the libraries I use.

I also disagree with the statement that TypeScript is making JavaScript "like C# or Java". TypeScript lets you opt out of type checking all you want with minimal difficulty. It also will by default always emit JavaScript even if it detects type errors.

He participated in WW1, which by any reasonable standard was a truly modern war.

I'm basically glad to see the Type suffix removed from the standard library protocols. I'm hoping that they'll have a solution to make it so writing a function over a generic sequence isn't such a mouthful.

I'm a little flummoxed by the new effort for first argument labels. Function names often imply the meaning of their first arguments very effectively and the new splits in function names seem arbitrary at times. Labeling subsequent arguments is an excellent feature of Swift but first argument labels often seem to complicate the syntax, especially labels like of: which don't always imply much about the meaning of the argument by themselves.

Oops. You're right. Sorry.

goto fail was in OpenSSL which many organizations use, but your point still stands.

They were eventually able to get into the phone without the backdoor. The shooter's employer was able to change the iCloud password on it because they issued the phone in the first place.

The FBI initially wanted to get in by having Apple build a backdoor that could be used to defeat the security on ANY iPhone-- that's the bad thing, and it's still a bad thing.

And re: "thanks for the downvote"-- stop digging when you're in a hole.