EvanPlaice

Maybe/Nothing is a perfect example of the null object pattern. Either provide a sane default or a typed instance with empty values rather than checking for null/undefined. Ie the 'null object' in 'null object pattern' doesn't mean using null to indicate the absence of a value.

Null isn't used in JS to mark undefined variables, that's what 'undefined' is for. Unlike static/OOP languages, null is specifically reserved for use cases where a null value is necessary. Which was the point of my comment.

If you try to access an undefined variable in 'strict mode' it throws an undefined runtime error.

JSLint does, in fact, check for undefined variables and/or globals that are accessed before they're defined in the local source (ie unspecified external globals).

So... There's that...

-----

Did you happen to notice how I didn't even remotely mention Haskell or anything related to functional programming but, please, I'd love to hear for the thousandth time how Haskell's purity is going to cure the world of all it's ills. As if the Haskell community hasn't been over-promising and failing to deliver production-ready applications for the past decade.

Unlike Haskell, JS source can be actively linted while you write it rather than requiring a separate compile/build step.

With ES6 on the client-side, modules can be hot reloaded as changes are made for instant feedback. The obvious downside being, fewer coffe breaks that can blamed on the compiler.

Have fun implementing trampolines once Haskell's 'recursion all the things' default approach to lazy-loading inevitably overflows the stack and crashes your app in production. Static type checking can't save you from logic errors. See also 'memory profiling' the phrase that shall not be uttered.

Source: http://steve-yegge.blogspot.com/2010/12/haskell-researchers-...

I saw a comment on another post that captures the 'nature' of Medium quite nicely.

Medium, somewhere between half-baked and well-done.

Considering the sheer number of 'self-promotion disguised as content' and 'Dear whatever subject I feel like complaining about today', or 'Dear Dear response to complainer' posts, I wouldn't consider it a good Medium (pun intended) for any content that matters.

Unless, of course your business is shameless, thinly veiled native advertising.

Use the null object pattern.

If you're checking a value to see if it's set by testing for null/undefined, you're doing it wrong.

This is good advice for any language, not just JS.

Besides, using null as the default for an undefined value is a mistake. Null should indicate a non-value not the absence of a value. Maybe one day the static OOP languages will die so devs have a chance to learn the difference.

It's hard to extract value from the economy via short-term pump and dump campaigns when the majority defaults to diversified index funds.

Investors with heavy ingluence/ownership of media have a lot of potential to earn from manipulating market volatility.

See Poe's Law

"Without a clear indicator of the author's intent, parodies of extreme views will be mistaken by some readers or viewers for sincere expressions of the parodied views."

Thanks!

I wasn't aware of this approach. Looks like a reasonable single-pass solution.

The widespread dragnet of data collection currently used is a clear violation of the 4th Amendment of the Bill of Rights.

> "[t]he right of the people to be secure in their persons, houses, papers, and effects, against unreasonable searches and seizures, shall not be violated, and no Warrants shall issue, but upon probable cause, supported by Oath or affirmation, and particularly describing the place to be searched, and the persons or things to be seized."

This should be amended to include data but from a legal standpoint it should stand that information/communications that are stored/accessed locally on a personal computer fall under 'effects'.

Backdooring into your computer without prior authorization and/or the justification backed by a warrant is illegal and a violation of the rights of US citizens.

Bitcoin and other forms of non-standard currency depend on crypto.

1. The central banking system feels threatened by competition.

2. Government is afraid that people will use it to launder funds and dodge taxes.

3. Law enforcement, Homeland Security, and the NSA are afraid of losing the ability to effectively search and seize electronic assets; despite the fact that their current practices are a clear violation of the 4th Amendment.

Instead of using built-in method calls that come with a library, why look into the algorithms used to generate the different transforms?

I once worked on a UI where the users wanted to capture a screenshot of the current page.

Because color toner is more expensive they also wanted the option to print grey scale. I'm pretty terrible at working in 2D space but a quick Google search let me know that the conversion to grey scale involved averaging the RGB values for each pixel.

Unfortunately, the coloring of the UI was darker more than light so the resulting greyscale image was still black toner intensive. So we provided an additional option to invert black and white.

To make it work a second transform was applied to each pixel that reversed the pixel value from upper to lower bound (or vice versa depending on how you look at it).

The result was an output that trended toward white instead of black. The output looked surprisingly good and saved on toner so the users could print many screen captures without worrying about wasting resources.

For the business, it resulted in a cost and resource savings. For users, picking the resulting output provided better results that were easier to understand. From a development perspective, the implementation wasn't difficult at all to add. So, win-win-win.

What surprised me was how easy these transforms were to apply. It's a bit CPU intensive on high resolution images but it's not terribly difficult to come up with good results.

It would be awesome to see some more examples of algorithms used for image processing. So much material covers generic algorithms and data structures that come with the typical CS degree.

It would be much more interesting to see algorithms that can be used in practice. For example, how to scale images, implement blur, color correction, calculate HSL, etc...

Libraries are great but these concepts are simple enough that they don't require 'high science'.

The article mentions a curiosity related to how edge detection works. I'd assume that you select a color and exclude anything that falls outside a pre-determined or calculated threshold. For instance, take a color and do frequency analysis of colors above-below that value by a certain amount. Make multiple passes testing upper and lower bounds.

A full color image @ 24 bit (8R 8G 8B) will take a max of 24 passes and will likely have logarithmic runtime cost if implemented using a divide-conquer algorithm.

Things like blur and lossy compression sound a hell of a lot more interesting because they have to factor in adjacency.

But you can sure as hell discourage/demotivate them by standardizing all classes into a game of 'guess the question', all work into mechanical problem solving, and all tests into multiple-choice bubble filling.

The first class where I experienced true critical thinking was 10th grade English. By a teacher who was ejected the next semester for giving the school jocks a hard time when they acted up in class.

I had the luck and very good fortune to get out of public school and attend a boarding school on a fully funded scholarship.

In my earlier years I went from Minnesota where they were experimenting with teaching algebra to 4th grade students who tested high on intelligence assessments, and where we were practicing basic physics in Science class in 6th grade.

To Colorado, where my school didn't even teach Science and we spent most of the day screwing around and playing card games. Middle school was light on content and dominated by a culture of bullying/bullies. High school was all about 'getting into college' and bullying was replaced with popularity contests and jocks.

Ironically, I took all useful classes where I learned skills that I've used a lot since. Metal Shop, Wood Shop, Graphic Arts, and Computer Programming. All of the shop, graphics, architecture classes were on the chopping block despite the school having 5 baseball teams 3 softball teams, the 3 usual football teams, a state-winning marching band, and many teams for various other sports including tennis, volleyball, soccer, basketball, etc...

Isn't that what venture capital supposedly promises. Workers who are vested in the company are hyper-motivated to see it succeed.

In theory, it's a great idea. Who wouldn't love to be an early employee of the 'next Microsoft' and win the successful business lottery?

In practice there are some very serious caveats:

1. Non-preferred stock may be rendered worthless after multiple rounds of seed funding.

2. Some stock come with additional restrictions. Such as requiring the person to maintain employment for an extended period of time.

3. Many can't afford the tax costs that come with exercising their options when they get the chance.

4. In some cases you may end up with a net negative of stock earnings after paying the taxes.

5. Exercising early can help avoid some of the tax pain but then you're essentially betting on the future success of a company with a high risk of failure.

Basically, working for a startup at significantly below market salary is joining the game of high stakes poker for the rich. Except, unlike poker the game comes with a minefield of additional risks.

If the employees were 'true' stakeholders working as a partnership then everybody wins. Unfortunately, that very rarely happens and sometimes relationships go sour during the death march to potential success.

When money is involved, the only thing that guaranteed is that people will play fucky fuck games for an advantage if they think they can get away with it.

In the bigger picture of things 'expensive' is a highly relative. You have to also factor in risk and the other secondary costs.

Not sure if this applies to your company but I have some prior experience as one of those SME/consultant/contractor guys.

For one particular multi-national company whom we did a lot of work, they had an entire dedicated team of (underutilized) engineers/technologists that should have been more than capable of doing the work we provided.

Aside from the hour or two of daily PM work, the entire staff would disappear for the rest of their shift and reappear just in time to check out. To this day, I still have no clue where everybody would go. I'm not talking about an isolated incident, I saw the same pattern take place over the course of months.

Why was this allowed? Why was the company willing to pay us a premium to do work that could have been handled internally?

It was a non-union shop. The company had established a very firm and well defined scope of work. Adding additional responsibilities could screw up the balance and put the company and it's daily operations at risk. In the bigger picture of things, paying contractors/consultants a premium + expenses to do the extra work is an order of magnitude less expensive than the possibility of unionization. Just the cost savings on HR overhead (ex managing disgruntled workers, hiring new people) alone probably made up for what we charged.

You should've seen the amount of hell raised when the coffee provided was downgraded from Starbucks to a cheaper blend.

The whole work environment felt a lot like some sort of bizarre Mexican standoff between worker and company interests. The company would have a very difficult time maintaining operations and hiring replacements if their workers were pissed off enough to leave. Meanwhile, as much as their workers liked to complain, they had been working under such limited responsibilities for so many years that -- in terms of engineering and/or raw technical skills -- most of them would be useless elsewhere.

This may in part explain why many large corporations show a strong preference for H1-B workers. Not only are they incapable of unionization but they keep the senior staff motivated by fear of their jobs being replaced/outsourced. Whatever the overhead cost/complexity, it pales in comparison to disrupting operations and/or being bent over a barrel on union/compensation negotiations.

It also explains the preference for hiring millenials. Millenials have been screwed since day one. Starting from ridiculous education loans/costs. Extending to being forced to work unpaid/underpaid internships to make up for lack of unrealistic industry experience requirements. The idea of a company/union providing any form of protection is so far from our reality that we don't even consider it as an option.

Tired of being screwed by your company? Pack up and move on to another company. Resume shows lots of movement? Too much ambition is bad for business. Can't deal with the stress/complexity of regularly changing jobs? Better learn to enjoy being screwed.

Engineering for many industries is a cost center and hell hath no fury like a team of bored senior engineers with an over-inflated sense of entitlement.

Outsourcing can be used to reduce risk, avoid management complications, and shift CapEx (ie permanent employees) to OpEx (ie disposable contractors). Offshoring sucks but there's virtually no legal risk involved with firing overseas workers en masse. H1-Bs cost the same as local workers but have so many legal limitations that they're essentially the modern equivalent of indentured servants.

Corporations have to answer to the board. The board acts in the interests of investors/stakeholders and will eventually have to deal with 'extracting value' from the company to meet short-term investor demands at the expense of long-term sustainability.

To make matters worse, the CEO/board can justify higher levels of compensation if they greatly expand the size/scope of the company. Whether or not the growth matches the market trends. Just look to all the comments of employees complaining how their job is to warm a seat and/or maintain excess/unnecessary administration overhead.

The exception are companies like Facebook that refuse to cede decision making to the board. It pisses off investors when the company fails to extract value at a rate matching investor expectations but I bet FB will fare much better in the long-term. Unlike companies like Yahoo/IBM that morphed into pump-and-dump chop shops of underutilized talent.

Since the US is increasing it's aid to India year over year to address the growing humanitarian crisis, I suggest a different alternative.

Use the H1-B fees to fund the foreign aid. Call it a 'ship jumper' tax.

In 2013 the government expenditure portion of foreign aid was 2.4BN USD. Divide that 65,000 ways and the fee equals roughly 37K USD per H1-B applicant.

Note: This only accounts for direct government spend. Which excludes NGO, organizational, and individual assistance.

With that in mind, 4K is practically a bargain.

----------

In all seriousness, how about we address the real issues.

1. Immigration is not a trade issue, period. Square peg, round hole. Different rules apply.

2. India is already heavily overrepresented in H1-B issuings. Immigration shouldn't be limited to just those countries who spam the most applications. The US is a 'melting pot' not a 'life raft'.

3. It's not realistic to expect the US to import the entirety of India's upper-caste.

What about using observables? Unlike promises, they can be cancelled at any time.

Rxjs provides the observable data type. The extensions are functional reactive operators. There are operators used to retry, throttle, filter, debounce, etc.

Angular2's http module is already based on Rxjs observables for this exact reason.

Can't forget the declarative regular and context-free languages.

XLST and other template syntaxes are another interesting case. They look mysteriously like a declarative context-free language but have imperative characteristics of a turing complete syntax.

JVM may not be able to be combined with compiled languages but there are a number of languages that, at a bytecode level are compatible with Java. For example IronPython, Rhino, etc. The same can be said for the .NET environment and languages like VB.NET, managed C++, C#, F#, etc.

Don't even get me started on languages that can output output Javascript. Last I heard, there's over 100 of them now and the list keeps growing.

I'm not sure about GLSL/HLSL because I haven't used them but they sound like they're declarative DSLs (Domain Specific Languages).

Maybe it's about time somebody created an update to the Chomsky hierarchy. Instead of the traditional subset-superset classifications, some other system is used to compose the characteristics of languages.

In the bigger picture of things, it's all very incestuous. Like every language is trying to be like every other language. The winners of the pack are those that everything else compiles/transpiles down to.

The application layer is decoupled from the rendering layer specifically for reuse across multiple platforms. That means the data layer that handles data fetching and change propagation works everywhere.

The view rendering layer is the part that is specific to each platform and the React community provides web components that work natively on each platform making the development process between mobile/web more consistent. Mobile provides an escape hatch to write platform specific code in the native language.

"As for web/ios/android/desktop - this is a rare bird"

Targeting all, will remain very unlikely. Targeting more than one is pretty common. React and Angular2 are pushing hard to enter the mobile development ecosystem. Microsoft has been pushing for Typescript usage on the desktop and just picked up Xamarin so we'll likely see desktop or web or mobile hybrid applications at some point in the future.

If the barrier-of-entry to support another platform is low enough, it'll make sense to do so. In the current ecosystem, supporting even 2 platforms is a massive undertaking.

You're right, I was thinking of platforms more like Cordova.

I did a little reading and it appears that React Native, Appcelerator, and Xamarin are pretty close to feature parity.

I was specifically referring to statically typed OOP.

You're right, I haven't tried OCaml or Haskell so I can't make a qualitative judgement on how easy/hard type coercion is in either.

Awesome write up.

While I agree that dynamically typed languages -- by their loosely defined API requirements -- are more difficult to scale, it's not difficult to add type checking and/or provide a well structured public API where necessary.

I think statically typed languages go too far in the other direction. Tyr type and API definitions are too strict leading in a ton of unnecessary effort (ie boilerplate), increased surface area for potential bugs, and overly restrictive limits that require 'creative' workarounds to effectively write code.

I think there's a 'happy medium' to be found where type checks are required for certain inputs and a clearly defined API can be established without the need for private/internal/public syntax artifacts.

I've been playing with this a bit in JS lately. Using model definitions to specify the structure and enforce validation. As well as defining facades with the ES6 module import/export syntax to define public APIs. Finer grained control (ie private vs internal) can be defined using closures that provide internal interactions while hiding the private implementation details.

React Native doesn't use embedded webviews and provides an escape hatch to write native code when Reactive Native's capabilities fall short.

There are two fundamental issues with the mobile first approach.

Duplicate effort does incur a real cost in terms of time to delivery. Duplication is a clear sign of inefficiency. A platform that provides native support for multiple platforms reduces such duplication.

The maintainance cost of providing multiple platform-specific implementations compounds over time. For every feature added there's a chance that subtle differences will be introduced. In a perfect world one platform developer will have an equal level of skill and understanding as a developer for another platform. In practice, there's no guarantees that both versions will be kept in sync. The differences and abstraction leaks become technical debt and accumulate as the platform grows/changes over time.

Now, lets say you want to provide a web, iOS, Android, and Desktop interface for a platform. Would you choose to do 4 independent implementations in 4 different languages. Or 1 in a single language with platform-soecific differences?

Platform duplication is a violation of DRY at the system level and incurs the same problems of diplicating code, at a much larger scale.

The Russian Facebook is basically a independent fork. It's not required to remain feature-complete and in sync with the official Facebook platform.

Lazy evaluation is no longer exclusive to Haskell and other functional languages.

C# has had Linq for lazy evaluation of data collections for many years.

Javascript supports observables now and ot's only a matter of time before they're included in the official spec.

Reactive Extensions has been extended to many different languages now.

Lisp macros are essentially higher order function definitions. They can be trivially applied using decorators in Python and closures in Javascript (JS decorators will be supported in ES7).

The C category.

A 4th category is probably needed for statically compiled, garbage collected, OOP languages.

The reality is, most/all of the most popular languages blur the lines.

Javascript is getting official support for OOP as well as better support for functional programming.

C# has good support for dynamic typing as well as many functional characteristics.

High performance Python has always had the ability to delegate to C extensions.

Etc

Thank you for all your hard work on Mono and bringing .NET to the OSS ecosystem.

Hopefully, the regulatory approval stuff works out without issue.

Microsoft needs better representation in OSS and I can't think of anybody better equipped to assist them in that direction.

V8 is a runtime.

Cygwin is an entire OS ecosystem of dependencies, tools, libraries. POSIX utilities are so tightly coupled to the OS, it's virtually impossible to use them with any degree of confidence without importing the entire universe. There's nothing 'perfectly normal' about such a poorly structured architecture.

JS dependencies are explicitly defined in a package's package.json so it's trivial to track a package's dependencies.

Likewise, one could create a powershell implementation in JS and -- barring windows-specific features -- Powershell scripts would 'just work' in a nix environment as well.

This package makes it trivial to port POSIX tools to Windows. What about greenfield development of utilities that need to work in both nix and Windows? Instead of building for one platform first then porting it to another (incl all the maintenance issues involved in maintaining separate forks in sync) why not use a truly cross-platform language from the start?

The Javascript ecosystem comes with it's own package management system.

Apt-get attempts to be 'everything to everybody'. It requires a monumental effort from the OSS community to maintain the different sources. Outdated packages are the norm making it harder for software maintainers to resolve bugs. Submitting new packages or publishing new versions of existing packages is a PITA. Etc...

NPM's source is centralized and provides a very useful online portal for: searching for packages by keyword and/or tags; publishing the Readme ad human-readable HTML (ie via Markdown); finding related links to the source control, issues, project pages; tracking downloads and development progress stats.

If you prefer not to publish to NPM the NPM directory, packages can be installed directly from GitHub, Bitbucket, etc.

Tapping the broader exosystem is easy for both users and developers.

Porting existig software to JS is advantageous for a few reasons.

NPM makes cross-platform installation simple, easy, and scriptable by default.

Dependency management. The package manager supports both local and global installations, as well as the ability to manage multiple versions of a dependency where necessary. Not by convention, by default. Dependency hell simply isn't an issue in the JS ecosystem.

More secure. Scipt installation/management doesn't require root privileges. The runtime uses it's own sandbox. No matter how safe the underlying OS is, it's virtually impossible for a malicious script to break out and mutate memory/data outside of it's context. PwnToOwn competitions are frequently held to test, identify, and harden security.

Project hosting is trivial to setup. Package installation, upgrade, removal is supported by default.

Scripts aren't tightly coupled to the OS. So you don't have to import the entire universe to use them. For example, Cygwin or MiniGW not required.

Scripts don't require compilation. If you run into problems, it's trivial to open up the source and correct the issue yourself. Shorter iteration/feedback loops on OSS projects means more users are capable of contributing fixes and/or new features.

In short, all of the pain points that suck about native application development have been solved in the JS ecosystem.

Just the 'import the universe' point alone is enough to deter any dane dev from porting a *nix binary to Windows. Disk space isn't the concern, surface area for potential security issues, bugs, and the maintenance overhead of keeping an OS emulation layer updated are.

Javascript is a truly cross-platform solution.

Kinda funny how things work out.

Back when MS broadcasted OSX/nix compatibility for Visual Studio I felt it necessary to comment that .NET development has been supported in OSX/nix for over a decade.

In short, Miguel De Icaza should be awarded a medal from MS for his heroic effort in developing the Mono platform and tooling; in spite of the constant threat of legal action from Microsoft for 'patent infringement' of their supposedly 'open' (ie ECMA) standard languages and VM.

Hopefully, he finally receives public recognition and reward for all his hard work.

Not hard to parse this one out.

Government doesn't like encryption because it limits their ability to track/monitor people. Tracking is only supposed to apply to foreign actors but in a nation of immigrants everybody is essentially treated as a threat. compared to traditional ineffective methods (ie investigation, witness testimony, etc) of law enforcement tracking provides objective evidence of wrongdoing and removes human error from the equation.

Unfortunately, in such an overly litigious society where it's nearly impossible for people to live their day-to-day lives without knowingly/unknowingly breaking the law, tracking becomes just another government funded system of subversion.

Industry hates encryption because of crypto currencies. The banking industry has worked very hard to centralize it's power and eliminate competition. Fortunately, for them there's no alternative. So there's no way for people to objectively measure whether or not using one standard, centralized, and strictly controlled/manipulated currency is a good thing. By default, we delegate an unbelievable amount of power/control to a very small and centralized group of individuals on the basis of 'trust us'. Previously, there was no alternative so people quit asking whether or not that's a really bad idea.

Crypto currencies aren't a threat to the current system of currency control. Rather they're an existential threat to the concept of central currency control as a whole.

When the driving influence of government need is combined with the financial backing of industry, laws get passed. Whether or not they're detrimental to the individual rights of the people.

Guns have no such problems. They're guaranteed by the constitution. A ton of government influence/resources comes directly from special interest groups that focus on gun rights.

Industry is making a killing from all of the panic caused by the threat of removing gun ownership rights.

Even if gun ownership magically became illegal overnight it would be impossible to enforce. They couldn't get the people to give up drinking alcohol during prohibition despite overwhelming support from the majority conservative Christians community at the time. What do you expect will happen when they go up against the 'you can take my guns, when you can pry them from my cold dead hands' crowd.

Attempting to outlaw guns in the US is the equivalent of the government declaring war on the people. No matter how you spin the moral imperative, it'll never happen.

So why do people bother debating it? Because there's an unbelievable amount of money, power, influence that can be made from stirring up panic over morally contentious issues.

Politicians get a ton of exercise by grandstanding on their personal moral/liberty driven platforms. Industry rakes in a ton of money by capitalizing on the uncertainty caused by the panic. The media has a hey day over all the controversy and publishes endless streams of analysis, reactions, counter reactions, speculation, etc. It's a modern day bonanza for everybody involved.

Except the people suffer because all the chaos creates and perpetuates a general culture of anger and mistrust between people divided on arbitrary lines. Cultural beliefs are very difficult to objectively measure because they last an entire generation. Without a central figurehead to influence the direction of a culture, individuals very rarely if ever change their position once it's established.

I can't think of a better strategy to divide, subvert, and conquer an entire population of people. Divide people's moral identity in enough ways that suddenly they have nothing in common. All it takes is a few morally ambiguous issues and the backing of the media. The effects last a generation so a minor investment pays dividends for many decades.

It's basically a thought virus for entire populations of people. Only those who are capable of thinking/acting independently of their personal moral beliefs are immune to it's effects.

It's much easier when you can see all of the staged/unstaged files and drill down to staging/unstaging individual lines within those files.

It also highlights whitespace nastiness (ie trailing spaces, missing newline at end of file, inconsistent newline chars, etc).

The CLI is the ideal too for a lot of things. Preparing commits is not one of them.