mvindahl

Heh .. my bad, Stefan Molyneux of course.

This DaMore guy doesn't have a lot of political savvyness.

First off, I think his manifesto contained more nuance than has been attributed to it. I agreed with some points and disagreed with others. I think the length was a bit excessive but it's not the kind of thing that would make me raise an eyebrow. Still, by publishing to to the entire company, he was openly challenging the views of his employer and forcing them to respond in spades. It was a move with no real upside but plenty of potential downsides.

Now, with half of Twitter eager to write him off as an alt-right douchebag, what does he do? Yup, gives an interview on an alt-right YouTube channel. This is a brilliant coup for Peter Molyneux but for DaMore there is absolutely no upside to being associated with those guys.

Thing is, I don't think DaMore is a bad person. I think he is earnestly trying to understand the current diversity fad and to spark a debate around its causes and effects. But he has quickly turned himself into a pawn in everyone else's game.

Like it or not, I think speaking openly against defined corporate dogma will get you in trouble in most places. He should probably have realized that and adjusted his course accordingly. Outright being fired is a pretty harsh sanction, and in this case it probably only came to this after the story blew up and Google had to exert damage control in public. A more conventional response would be an uncomfortable talk with your manager and the implicit warning of your career being sidetracked. That alone is enough to keep most people in line.

I don't think the core of this matter is if he was right or wrong, or if he overstepped the red line of PC. I think it's about any culture or any company having things that you shouldn't say. You can challenge these but you do so at your own peril. I think if a Google employee wrote a ten-page, widely circulated, manifesto on the ickiness of ad trackers, he or she would get into similar trouble.

Going a bit off topic here but your remarks on religion makes me curious. I'm from a firmly -- albeit lazily -- protestant country and don't describe myself as religious in any meaningful sense, but still an interesting subject.

My reference to religious "singularities" was to the apocalypse, or however you want to name it. The End of Days. The Second Coming. Stuff like that. I thought these ideas played a similar role in all branches of Christianity, although ignored by most people for most of the time. Is Catholicism and Protestantism so different in that regard?

More on topic, I see the evolution of (better) AI as a logical extension to the computer revolution, and I see the computer revolution as equivalent in scope to the industrial revolution. So I'm not saying it's a small deal. I just don't believe a whole lot in self-improving AI as a concept all that different from what has been going on in, say, processor design, for decades, and I certainly don't believe in the idea of a runaway, self-improving AI.

To become rapidly and exponentially more intelligent, it would have to either work smarter or work harder (to use an overused phrase). Working smarter would imply that if you arranged your CPU instructions in increasingly clever ways, you could extract exponentially rising performance from your programs. That's not how I remember the assembler programming that I did as a kid; you could be clever but there were some pretty hard limits. The strategy of working harder, on the other hand, would imply that someone would be willing to supply exponentially rising amounts of energy. Again, even if some Zuckerberg or some shady government agency would be willing to play this game, you'd quickly run into hard limits.

So yeah, AI is not the first game changing phenomenon in the history of humankind but it will change stuff. Like did bronze, railroads, or nukes.

My main problem with the predictive power of exponential curves is externalities, usually some tradeoff or some limit to resources.

Try as I might, I probably couldn't put it better than it's done in this talk: http://idlewords.com/talks/web_design_first_100_years.htm

True. Making any exponential curve look like a hockey stick is mostly a matter of picking the scale. I could probably create a chart showing how the population of the earth went vertical during the reign of the Caesars. Of course, a logarithmic plot solves that issue.

As programmers we really like to automate away the mundane stuff, and we're not too fond of human interaction. I'm grossly exaggerating, of course, but for a lot of us, this was the push and pull that originally drove us to hack away at computers. Creating a big and shiny automated processes is almost a no brainer for us.

Yet, I believe that you are absolutely right. We should fight our inclination to see everything as a nail for the hammer that we master. The ROI on automating everything from the outset is not worth it, and if the business flops, it's just wasted effort. Worse yet, it's a missed opportunity for learning about the customers and about the domain.

So yes, do things that don't scale. If and when you get in the air, profile the business processes and only then automate the bottlenecks. It's the only sane way when you think about it.

We're also some who regard the whole concept of "the Singularity" as being a quasi-religious crackpot theory no matter how you slice it.

Mind you, it's a powerful meme. Religious tradition abounds with references to some future event that will forcibly clean up the mess and propel us back to Eden. Some of the most prominent -isms of the 20th century subscribed to similar ideas. I guess our brains are a willing host to that kind of stuff.

On top of that, the technological version of the end-of-history cult has the added attraction of whispering into our ears that maybe we .. as programmers and masters of the machine .. may just be able place ourselves on the right side of history and become immortal citizens in future tech utopia. A pantheon of gods, for all practical purposes. That's a seducing idea.

Having worked with plenty of frameworks and libraries over the years, I also find myself solidly in favor of libraries. In a sense, IMHO, you are a slave to the framework but a master of the library. (On a side note, pretty much the same dichotomy applies to cats vs. dogs).

That being said, I have several friends with the same level of programming experience who stringly disagree. So voicing my opinion on frameworks is always excellent fuel for discussion.

And even then I think that it's important to realize that you can only get that far in terms of predictability. First off, it's a complex system; your sampled data set is incomplete by definition. Secondly, your theory is part of the system that it's measuring, at least if it ever becomes popular enough to influence policy.

I think economics has some valuable insights into human nature -- not necessarily applicable to every human but applicable to enough of us to be of use -- but they should stop cargo culting mathematics. Or more accurately, everyone else should call their bluff.

I kinda dislike dealing with the configuration too but it's there for a reason; because one size doesn't fit all. Then again, it's not a major pain point for me as long as I stick to the defaults.

And deferring the transpiling to the browser won't really accomplish much, except increase load time for all users.

I'm currently working on a project with ~500KLOC of typescript, and transpiling it takes about 15 seconds on my devbox. It's still a bit too slow for my taste but I don't think there is a technical quick fix for this kind of stuff, rather it's a tale about a project which started small, organically grew larger over time, and would in many ways benefit from a clearer structure with clear dependencies.

As far as I recall, IE, since reaching adulthood some few years ago, has identified itself as Mozilla when asked. It's a very pragmatic solution to the problem of a lot of websites having code to check for IE and apply all kinds of hacks to make stuff work anyway. It's also a tacit concession that .. yeah .. our track record wan't too good.

I'm old enough to remember the days when IE was a dominant force and they could pretty much thrash around and invent their own quirks and standards, forcing everyone else to play to their tune. So I find great joy in seeing IE disguising itself as Mozilla in order to not be treated as a rotten egg.

<iframe> already does something like that, although admittedly in a clunky fashion

Not sure, but maybe Google is just using some readily available set of topological data? The hole, being man-made, would display as flat in the same ways that do the buildings of Mirny.

I know for a lot of places, Google use fancy algorithms for extracting information about buildings and trees, and those algorithms never cease to amaze me. Anyway, Mirny is clearly not one of these places.

The best person form the job is the person who will make the team perform at its best. Which in IT would probably mean a technically savvy, creative person with good social skills and some domain knowledge. Those would be the merits upon which to build our meritocracy.

So you can be a productive coder or a good presenter or whatever but by themselves, these are incomplete metrics. If you happen to also be an a*hole, you are probably an overall liability.

An even more useless metric, though, is your specific flavour of sexuality or your skin colour. None of these count as qualifications in any sense, and if management if measuring these things I'd be wary of their sense of judgement.

Take one day at a time. Do your best and trust that it's good enough. Every month that you continue to get a paycheck will prove that you are good enough to be where you are. (Or maybe your really are an imposter, and your superiors, being even greater imposters, are unable to spot this. But in the end it doesn't matter since you still get a nice and steady paycheck).

Don't put the weight of the world on your shoulders. Usually, when working on a team, your personal successes or failures don't make or break the project. Also keep in mind that your teammates also have their personal successes and failures. You'll carry each other.

There is a tradeoff between development speed and execution speed. For web apps, development speed is usually the most important of the two and the language ironing away the most technical details tends to be a strong choice.

Roughly speaking, C is further from the metal than assembly (and WASM) for obvious reasons; Java is further from the metal than C (or Rust) due to having garbage collection, and Javascript is slightly further from the metal than Java due to abstracting away threads (the gap was far wider before Java got lambdas). LISP, of course is off the scale due to abstracting away readability ;)

On a serious note, though, I don't see the advantage that Java or Flash or Silverlight would bring to web apps unless they bring greater development speed.

But I do see WASM as an excellent future supplement to JS-based apps, for optimizing time consuming parts of the code.

Word. I have also worked on projects where existing tests were treated like holy cows. Deleting a test wasn't disallowed as such but it really required a convincing justification. Ironically, this made it especially hard to touch the inevitable subset of tests which had grown unreadable and which were not tracable to specs. Hence, they were often left alone, smelling riper with each passing year.

I like to think of production code as being inherently a liability, not an asset, and the same goes for test code. That's not to say that code, or tests, cannot be valuable; it's just that every line of code carries a cost to the business just by adding complexity to the development process and by taking up disk space and CPU cycles. Not all code offsets this cost, and a lot of tests certainly don't.

We should stop viewing tests like holy scriptures. Some add long term value, some add value during initial development, some should never have been written in the first place.

And on a side note, our tests should test the business requirements, i.e. they should be tracable to specs. There are a lot of tests out there which amount to little more than to "test" some arbitrary decisions which we made when someone initially fleshed out a class diagram.

The question is if WASM is really meant to be a compile target for anything resembling Javascript, or indeed of any language implementing garbage collection. And yeah, I know that there are proposals to include GC in WASM. And yeah, I know that a lot of people would love to program at the high abstraction level of JavaScript, only faster. Thing is, Javascript runtimes are already highly optimized at running Javascript type code. I think to really get faster, we'd have to face the tradeoffs.

The main tradeoff, IMHO, is memory management. If you go full OO with a lot of object allocations, and with a garbage collector picking up the litter in the background, then you will be freed to focus upon business logic and your development will move faster. If you manage memory yourself, C style, then you are in for a world of pitfalls and potential pain, but you can make your algorithms tighter and faster. What to pick depends upon your priorites. Postgres is written in C, for speed. A lot of modern web apps are written in full stack Javascript, for agility.

I envision the future of web assembly not as a compile target for your entire codebase, but as a way to optimize the tight loops and algorithms that do the heavy lifting, but leave the rest of the web application as Javascript. Also I think that once you go down that road, you have deliberately picked speed over convenience with respect to the methods in question.

The way that it's going to work, I think, is not by having a Javascript-type language compile into WASM, but by having a more low level language which easily compiles to WASM, but which also compiles to (slower) Javascript to support older browsers.

But what do I know ..

Reminds me of an anecdote that I read about the admirable society of Dubai. Apparently, the law requires that once the officially measured temperature exceed 50C/122F, the slaves (or whatever the official term is) are given the day off from the construction sites.

Anyway, the officially measured temperature tends to never exceed 49C, even when anyone could measure with their own thermometer that it's really hotter.

Mostly

- Reply All

- Planet Money

- Hanselminutes

Reply All is about the internet and planet money is about money, but in both cases it's as much about people and the interesting things that we do.

Hanselminutes is Scott Hanselman interviewing interesting guests about aspects of software development. It has a laid back and friendly pace. Scott is always well prepared and a very nice host.

I've had similar experiences. It's not enough to scare me away from using TS but it comes with a price, and I wouldn't apply it to a project until it reached a certain size.

First off, I really like the language design. It's typing but without the red tape or the ceremony that makes languages like Java so bloated and painful. Duck typing works nicely. Not having to name every little type is a breath of fresh air. Typing is optional and easy to add when needed. It works well with both VSCode and IDEA.

On the flip side, I've found myself spending far too much time trying to find the right typings to match the libraries that I use. It's very easy to end up with odd conflicts. Reminds me of the (hypothetical, of course) experience of finding subtitle files to match a bootleg movie. More often than not, they are off by five seconds, or jump out of sync midway due to been for the director's cut or whatever. Typescript typings are a bit like that; they get you 98% of the way but the last 2% can be surprisingly frustrating. That being said, after it has become possible to install typings from npm, it has become somewhat more manageable.

But yeah, there is a premium to Typescript, like there is to unit tests. It's not a premium that I want to pay for a project unless I'm pretty sure that there is a payoff down the road.

Fortunately, some telcos didn't. My wife made the switch from Telmore to Oister due to being annoyed with Telmore's price hike. It was the proverbial straw I guess ..

Nice idea. A bit simplistic in its current form, though.

One thing that would be really nice would be some kind of discussion thread for each topic. What does the customer really need? If there are ten interested customers, do they want the same thing? Which alternatives were considered? Which tradeoffs would be acceptable?

Also, IMHO, it would be cool if the site could handle the mundane details of hosting and billing. But I guess that there are probably other sites that do that kind of thing already?

There as several affordable and easy-to-use Photoshop alternatives around these days. My personal favourites (on MacOS) are Affinity Designer and Pixelmator. I'm sure that there are others which save you the price tag of Photoshop and the learning curve of Gimp.

Dane here as well. We own a Peugeot iOn which we bought for $15,000 a few years back. At the time it was about two years old but hadn't driven very far. The price and size is about the same that you'd pay for very low-end gasoline driven cars in Denmark. I don't regret buying it as it's very fun to drive. On the flip side, the range isn't that far, only about 60 miles, so it's nice for commuting and short trips, but we need our MPV as a fallback for longer trips.

Anyway, I guess the point I was trying to make was that there are electrical cars in a lot of different price ranges these days. The old car manufacturers are trying to board the train as well, with varying commercial success. It's not all Tesla.

Thanks for your feedback. I agree with your point that past failures, however many, does not guarantee future failure. Aviation is a good example from history.

And we should definitely keep researching stuff, even things which seem like a long shot. We'll almost always learn something useful in the process.

The future will tell I guess.. :)

That's actually very interesting. Never heard of that before.

A few remarks off the the top off my head:

1) Visually, it reminds me of electrical diagrams, perhaps taking it one or two steps up the ladder of abstraction. I can see how it might be an appealing notation for someone trained in electrical engineering, which may explain its usage in cars. It's really interesting how different "cultures" find different solutions to similar problems.

2) Still, and this may be unfair since I only glanced over it for a few minutes, it strikes me as more of a niche thing than as something that I'd describe as a general purpose language. It seems fixed at a certain level of abstraction. Probably just the right level of abstraction for configuring your car firmware, but impractical for authoring a complex piece of desktop software.

Maybe the future will prove me wrong :)

I think visual programming is one of those ideas that intuitively seems like a good idea but never is. Thus, it never really dies, it just gets picked up as a kind of rite-of-passage by new generations of developers. Managers also tend to like the concept as it would allow them to bypass the pesky code monkeys and just feed their drawings to the computer.

For my master's thesis, some 15 years ago, I programmed a system for visually composing and executing Java programs. The UI looked a bit like UML, and it worked nicely for anything resembling "Hello world" complexity (anything more complex literally became hairy to look at). Since then I've twice found myself on projects where we had to work with visual programming tools (caused by skilled salesmen and inept managers). In both cases the only sensible action was to pound the "eject" button until we were catapulted away from the monster. All in all I consider myself vaccinated at this point.

As for my reply to the question of the OP, I'm not sure that it differs much from everyone else. The main reason that it will never catch on, IMHO, is that the text editor is far better for managing complexity. It's easy to search for stuff, and it's easy to move or copy it. Also, every serious text based programming languages offers plenty of ways to hide complexity away, allowing you to focus your thinking at the desired level of abstraction. Visual programming tools -- or at least those that I have met -- instead force you to deal with stuff that doesn't matter (such as aligning boxes and arrows), and views very quickly become cluttered when you start connecting things.

That being said, I think visual tools can be a good fit for tasks whose output is UI. There are applications and frameworks that allow you to drag'n'drop to compose the UI, but the code is still written in a text editor. This can work reasonably well.

They'd place the conservatives on one planet and the liberals on the other. With filter bubbles being fully separated, they can shard the database :-P