Gaming in HTML5: the future is now - <AUTHOR> http://www.scirra.com/blog/56/html5-gaming-the-future-is-now

<comment><USER2> We ported our 2D Android/iOS game, "Bouncy Mouse," to HTML5/WebGL. It's on the Chrome Web Store ([https://chrome.google.com/webstore/detail/cgdllcbmneiklcmbec...](https://chrome.google.com/webstore/detail/cgdllcbmneiklcmbeclfegccdjholomb)) and doing great.

With WebGL, the performance seems great, and the graphics and effects look sharp too. Audio was definitely an issue, and more work needs to be done there by browser makers. Using WebkitRequestAnimationFrame over setTimeout helps battery life and performance a lot.

If you're interested, you can check it out here – <http://chrome.bouncymousegame.com/> – I'm thinking about doing a post about our experiences making this game for mobile and for web, and some of the economics behind game-making as well.

<comment><USER3> Excellent stuff, my kids simply loved this game! Looking forward to the blog post.

<comment><USER2> Thanks! Guess we should work on a post, then. :)

</comment></comment></comment><comment><USER4> Google Chrome is available on almost all platforms, so if there is a good HTML5 game optimized for Chrome, people will install Chrome browser to play it.

<comment><USER5> Funny, that's pretty much what they said about Flash.

<comment><USER4> There are 3 competing browsers, which will press Chrome to be in shape, flesh was a monopoly.

</comment></comment></comment><comment><USER6> HTML and JavaScript are a real step backward for getting games into the browser. Instead of having a bytecode (or virtualisation of machine code) that is designed for efficiency we get big APIs to do specific things thrown into the browser. Then everyone gets excited because the browser can finally do what the desktop has been able to do for years (without all the ludicrous overhead). But what about the applications that need raw CPU power? There's an unimaginative attitude these days that says that because we can implement some obvious-in-retrospect demo (like all these games are) that there's no need for efficiency. The design of the browser does a real disservice to programming.

</comment><comment><USER7> I wouldn't say the entire industry is heading for HTML5. Yes, it is very capable, but, check out this demo: <http://molehill.zombietycoon.com/>

Flash's decision to drop mobile is probably because they're focusing more on Flash 11 and Molehill.

<comment><USER5> Agreed. And Molehill will be powering a majority of iOS games lonnnnng before WebGL games are playable in Safari.

</comment></comment><comment><USER8> and goodbye battery life. Even the simplest HTML5 game find a way to use 90% of my CPU.

<comment><AUTHOR> That's because many mobile browsers aren't optimised yet - I think that will be solved with time.

<comment><USER9> I question whether it's really a matter of optimization. Even on the best modern desktop browser with the most modern JS runtime, JavaScript is going to run 5-10x slower than C. On top of that, consider increases in memory usage.

Mobile hardware is likely to keep getting better, but it's not magically going to make HTML5 games run well on mobiles. For that to happen, a few things are needed:

Magical improvements in JS runtime performance to bring JavaScript closer to native languages. You can at least count on JavaScript to continue getting faster, but there may be a wall somewhere. You may also have to rewrite your JavaScript to use new features and libraries to approach native performance, which isn't free.

Reductions to the amount of work mobile JS runtimes need to do. Right now all the JS for your HTML5 game has to be loaded, parsed and compiled on every run, and doing that is pretty slow on a mobile CPU.

JavaScript and related libraries (like WebGL and Canvas) need to provide good support for concurrency so that you can utilize the multiple cores available on bleeding-edge mobile devices. Clock speeds on individual cores of mobile devices are not likely to reach desktop heights and if you look at desktop trends, even if they do, they won't ever get much higher. Right now, you've got web workers, but they're too limited to be of much use in games (especially if you care about power consumption).

Improvements to power consumption in mobile HTML5 implementations. Even if you can barely hit 60FPS with your pure-javascript algorithm in a mobile browser, it's going to drain your battery a lot faster than a native app that's running 5x faster and letting the CPU/GPU sit idle when they have no work to do.

<comment><AUTHOR> Yeah, some good points I guess. But the fact we make an engine lots of games use makes it a bit easier: if magical improvements in JS appear which require some tricky changes to take advantage of, we can do the hard work in our engine and all the games benefit from it. But yeah, probably will always be a bit slower. 2D games don't tend to have really complicated logic though.

<comment><USER10> > 2D games don't tend to have really complicated logic though.

Your demo asteroids game certainly doesn't, but what about a 2D game that's actually worth playing? Things like physics or flocking algorithms are going to be very expensive in JS.

<comment><AUTHOR> You're right physics uses a lot of CPU, but I don't think games not using physics are automatically not worth playing. Did you see this platformer? <http://news.ycombinator.com/item?id=3192719>

<comment><USER10> I don't think presenting a retro platformer (which, FWIW, crawls here in FF 8) really argues your case much. Why should developers go back to making simpler games to get adequate HTML5 performance when they could develop directly for the target platform and use the hardware to its full potential?

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> The article states that 'mobile browsers will catch up', but isn't this one of the areas where the OS creators are have a disincentive to improve the gaming ability of their browsers.

Unlike desktop where you have the option of just installing another browser, aren't you locked into the installed JS engine on both iOS and WP7? I'm not sure about Andriod.

</comment><comment><USER12> The problem with HTML5 games is that the game's source code is on your machine which means DRM is gone. Not only that but the problem for me is that my assets and my source is freely available to you to use in any way you want. You can take it and rehost it on your website and I lose any way of making a profit off my game.

<comment><USER13> I don't buy this to be honest, what's stopping you from stealing from any other game? Why have you singled out HTML5 as exclusively suffering from this problem?

<comment><USER10> Well, because the web, by nature, is _open_. Javascript is source, not some kind of bytecode. You can easily look at the source of any web page and do whatever you want with it (granted there are obfuscators available, but run it through a tidier and it's at least easier to work with than assembler would be).

It's not that you can't steal games from other platforms, it's just that targeting HTML5 makes it ridiculously easy. I think the web being "open" is a great thing, but obviously it's a genuine concern for people who distribute games. There's already a big problem in the Flash circles of strange Chinese portals stealing a game and sticking their logo on it.

It's not just about the code, either - all the assets (images, sound) pretty much have to be readily available in an unobfuscated format.

<comment><USER13> I think you can argue that this is largely offset by the opportunity the web as a platform can offer you and your games.

Theft of assets is definitely an issue. We've actually been targeted ourselves by someone stealing and reselling our product. It's a pretty upsetting and difficult situation so we sympathise with the concerns.

What we learnt from our experience however is the thief was largely incompetent and didn't actually pose as much of a risk as we thought he would to our operations.

I think often the same can apply for theft of assets, it's upsetting that someone steals in in one swoop without any thought and appears to be making money from it, but most of the time they are struggling to make anything at all from your work. If someone more successfully is stealing from you there are a lot of options to take it further if it becomes economically viable. For the majority of developers though I don't think it's as big a concern as many people think it is. Although I'm sure there are some good counter examples and arguments against this.

</comment></comment></comment></comment><comment><USER14> Is it just me or are we now basically at the stage we were with java applets about 12 years ago?

<comment><USER6> Yes, but no UDP sockets, which are absolutely essential for multiplayer games. It's ludicrous that a modern networking platform can forgo this essential component.

</comment></comment><comment><USER9> Google sure is good at guiding the conversation on these APIs. It used to be that everyone complained about Chrome's piss-poor audio implementation, but now people are complaining that Microsoft and Mozilla are 'slow to support' the Web Audio API 'standard' even though it looks like Google documenting their NIH mixer library after the fact instead of an actual market-driven standards effort.

<comment><AUTHOR> You're right, Web Audio API isn't standard yet - edited the post to clarify.

</comment></comment><comment><USER5> To summarize: Here's a game that doesn't work on mobiles, doesn't work in IE or Firefox or any version of Chrome less than 15. Now that Adobe has caved to the various walled-garden app stores and given up hope for a share of the casual games mobile market, game developers will be stuck with our spaghetti Javascript and browser idiosyncrasies for the next decade or until the standards agency manages to raise Jesus and tie its shoes at the same time. So suck it up and deal with the fact that OO code and multi-platform development are dead, and we're so cool because we made a game in 3D that can almost be played at 2 FPS on a phone browser (but we'll let someone else figure out how to make phones 15x faster... it's right around the corner!)

<comment><USER15> And even when phones are 15x faster, people will expect games to be 15x prettier. Mobile browser games may one day carve out a low-tech niche of sorts, similar to how Flash games have carved a niche on the desktop, but they are never going to be in the same category as native games.

<comment><USER5> Of course. By definition, they can't be. But JS games also will always be a class below Flash games, because the language is sloppy and completely interpreted at runtime. The fact that people think it'll be a replacement just shows how much money computer-illiterate business school graduates living with their parents in Bel Air still have to throw around, taking power lunches and acting like they have a freakin clue what they're talking about. I've been working for these types of people since "Bel Air" was "Oakland Hills", "HTML5" was "E-commerce", and IE 3 didn't play nicely with Netscape. But the smell of bullshit hype stay the same.</comment></comment></comment>


What I Expect From a Programming Language - <AUTHOR> http://eiffelroom.org/node/653 <comment><USER3> Interestingly, these qualities all apply to Go:

\- easier to read than write : it has been said a lot that go (esp. its error handling) was somewhat verbose, though very readable.

\- Not tricking the programmer : this one is a bit subjective, go does use the equal sign as assign operator, but the required braces for if-else, gofmt tool and strict compiler help in not tricking you.

\- one way to do things : go (its community) is very actively promoting the _idiomatic_ way of doing things. Also consider, no while/do loops, only for.

\- as much static typing as possible : maybe not as much as rust, but yeah, very static typing (array length is part of the type, for example)

\- no warnings : exactly that! Unused variables and imports are errors.

\- coding conventions part of the language : the gofmt tool does that. Don't publish code that is not gofmt'ed!

<comment><USER4> I read the article and then came to the comments looking to make this exact point.

Gofmt is my favorite example of why coding conventions can, and _should_ be part of the language.

</comment></comment><comment><USER5> I think "one way to do it" Java and Python philosophy is overrated. Sure, when it's presented that way, it sounds great! Why wouldn't we want one way to do things?

I like to think about it differently: instead of trying to coerce my problem to fit the language, I want to mold my language to fit the problem. It's easier to think about the problem in its own terms--the terms of its domain-- than in those terms filtered through a "one-size-fits-all" language design.

I want code that is declarative and closely reflects its underlying logic. And this means there will be more than one way to do things--while many problems are similar mechanically, their actual meaning is vastly different.

So there really _is_ a benefit to having more than one way to do things: you can choose a way that's appropriate for the problem you're solving. Of course, this puts a bit of trust into programmers to have good taste: while it allows you to write far _better_ code than a one-size-fits-all language, it also allows you to write far _worse_ code. I personally think this is a worthy compromise.

Another interesting thing I've found is that having more than one way to do things naturally emerges when you have a distinct set of powerful primitives. This is most evident in math: for any given problem, there are often _a ton_ of different ways to arrive at the same solution. Each of these ways emerges naturally from the fundamental building blocks of math.

Coincidentally, these different ways of looking at the same thing are not only natural but actively useful: they give you different perspectives on the same idea. An example I recently encountered was with lattices. There are two different ways to define a lattice--one in terms of partial orders and one in terms of algebras. The former gives you an intuition on the structure of a lattice; in a sense, it tells you what a lattice "looks like". The latter makes it easy to see relationships between lattices and other algebraic structures: for example, Boolean algebras are just a special kind of lattice. You can then even combine the two and start thinking about Boolean algebras in terms of orders.

So to me, having multiple different but equivalent ways to do things is both useful and natural, especially if these different ways emerge naturally. I much prefer this approach to something more prescriptive and monolithic, where the language designer has tried to guess exactly what and how I will be doing and explicitly provided a way to do it.

<comment><USER6> Sure there are corner cases such as lattices where having more than one way of expressing a problem is beneficial, I think what the op is getting at are things like:

if/else vs. the ternary operator in C. Blocks/Procs/Lambdas in Ruby. etc.

The concepts are so close that the language might as well pick one way of doing it and just do that. I don't need 18 kinds of for/for- in/while/do/do/while loops each broken in it's own way, I need one that works.

For myself in the above cases I'd make if/else an expression, and get rid of blocks/procs.

Most of what is in today's languages shouldn't be spec'd as part of the language, but rather provided by the standard library. What is the point of async/await in C# but not monads? It does not empower programmers, it subjugates them to the will of Anders, these tasks are blessed, these are not.

<comment><USER7> Even if you made if/else an expression, the ternary is still useful for brevity.

Compare:

      foo(a ? b : c)

Versus:

      foo(if a then b else c end)

Which do you think reads more clearly?

<comment><USER8> The slightly less terse:

         if(a)
            foo(b)
          else
            foo(c)

<comment> qu4z-2 My only complaint with that version is that foo() is repeated now. It's not clear at a glance that you're definitely calling foo, and only deciding which argument to pass. (Well, in this simple case it's quite obvious, but...)

<comment><USER9> If that's really a concern:

        if (a):
            arg = b
        else:
            arg = c
        foo(arg)

In my experience, trying to optimize for brevity at the expense of clarity is almost always a bad idea.

<comment><USER10> I like this - idiomatic, brief and clear:

        arg = a and b or c
        foo(arg)

<comment><USER11> Personally I don't really see what's unclear about foo(a ? b : c)

In fact, I'd say your "trick" with using boolean operators on non-booleans that way is less readable.

<comment><USER10> I don't think there is anything at all unclear about (a ? b : c). I use it all the time when programming in C and its derivatives.

The (a and b or c) idiom is used in Lua, Ruby and Python (in descending order of idiomaticness). Since the person I was responding to seemed to be using syntax reminiscent of these languages, I thought I'd offer up this expression form as an alternative to resorting to statements.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> Making unused variables and code formatting issues into errors was considered and rejected for Rust. The reason is that much of debugging consists of commenting out pieces of code and rebuilding. Often this results in variables becoming unused and formatting becoming messed up. I've worked with systems that threw errors here (FxCop), and it was terribly inconvenient in practice.

I think the optimum is just a loud set of warnings, a community expectation that all code be warning-free, and a pretty printer included with the language to get the ecosystem to standardize on a style.

</comment><comment><USER13> tl;dr: OP likes Eiffel.

A perfectly reasonable post, but not a very interesting one. I could probably write something similar:

      - <USER2>
      - tail-call elimination
      - s-expressions

Can you tell what my first language was?

<comment><USER14> Scheme?

<comment><USER15> Nope. Must be XML.

<comment><USER13> XML used to be a very easy way for my coworkers to get a rise out of me. Thankfully, I haven't had to think about it since I left Apple.

</comment></comment></comment></comment><comment><USER16> it's interesting how his entire _class_ of expectations is different from mine. my focus is mostly on what facilities for abstraction and safety the language gives me; i hold that if you have powerful enough abstraction facilities to factor out boilerplate, your code can be made to be way more readable than the "only one way to do it" class of languages, and if you have safety features built into the language (static typing, abstract datatypes, contracts, linear types) it will be _forced_ to be more reliable.

</comment><comment><USER17> He wrote: "As much static checking as possible: Static checking is good. Did you ever write a larger piece of code in one go, compiled it and it produced tons of errors? All these error would still be there, if you would not have static checking. You err much more than you think."

I think _he_ errors much more than he really thinks. If errors are what he's truly trying to avoid, he'd be more focused on unit testing and TDD than passing syntax.

Descriptions like his make me wonder how many static typing proponents have actually spent any legitimate amount coding in a dynamic language for a production application. It seems all scary to code applications without a big IDE, but I promise that it's possible and a lot of people make it work.

<comment><USER18> Java developer: "How can you code without an IDE?"

non-Java developers: "How can you code in fucking Java?"

<comment><USER19> I write Java in Vim on occasion.

I think I'm broken.

</comment></comment></comment><comment><USER20> I think this is off base with regards to warnings. Warnings are the sign of a language that has been widely used. There is something that is now known to be bad (i.e. error prone), but previously was not known to be bad.

If you make it an error you break lots and lots of code. If you totally ignore it, you allow more preventable bugs to be introduced. Thus the warning is born.

</comment><comment><USER21> I don't understand how he can want static checking, but no warnings. "x is declared but never used" has saved me so many times. Maybe he's used to languages where warnings cannot be locally disabled? In Common Lisp I can (declare (ignore x)) to "shut up the compiler", and it works really well.

<comment><USER22> He wants "x is declared but never used" to be an error that halts compilation. Go's philosophy on this[1] is "if it's worth complaining about, it's worth fixing in the code."

1: [http://golang.org/doc/go_faq.html#unused_variables_and_impor...](http://golang.org/doc/go_faq.html#unused_variables_and_imports)

</comment></comment><comment><USER23> Programs should be easy to write and easy to read

Formatting should delineate structure wherever useful

Syntactical noise should be avoided

Should provide powerful tools for expressing ideas succinctly

Static checking should be available but not required

Should provide a rich set of built-in tools

Should support runtime program manipulation

</comment><comment><USER24> I agree with most of the post, but this:

> _Programs have to be easier to read than write_

I think is impossible.

<comment><USER25> It was one the main motto of Ada. Ada is very easy to read (to be honest, it is less true since Ada95) but when I do not use it during a long time, I forget how to write in Ada.</comment></comment>


Doing Five Research Problems Before Lunch - <AUTHOR> http://lightstep.com/blog/doing-five-research-problems-before-lunch <comment><USER2> Interesting way to work on things. Effectively, I think the author is trying to get people to spend a lot of time self-studying in an organized fashion and then ask for help.</comment>


Tying Health Care Executive Pay to Patient Health - <AUTHOR> http://fortune.com/2017/02/13/brainstorm-health-02-13-intro/ <comment><USER2> No thank you, my healthcare is my responsibility. It's like washing your car after a snow. If you don't the chemicals that keep the roads ice free will rust your car away, insurance doesn't cover that and it shouldn't, it's your own responsibility.

Likewise health insurance should only involve itself with emergency care, I am perfectly capable of seeing to my own daily health care by not smoking and not drinking and not eating unhealthy things, or not sitting in front of a screen all day and getting up and getting exercise.

Tying these things to corporate pay will only incentivise those who are greedy to manipulate the facts to puff up their own coffers.

<comment><AUTHOR> Overall health of a population is more than education on the diet and other habits. The overall quality of care can be seen as a conflict of interest to traditional executive pay metrics such as financial performance.</comment></comment>


The Phisher Kings - <AUTHOR> https://www.cylance.com/en_us/blog/the-phisher-kings.html <comment><USER2> wow, that site is slow, unable to load.</comment>


Microsoft releases F# under Apache 2.0 license - <AUTHOR> http://blogs.msdn.com/b/dsyme/archive/2010/11/04/announcing-the-f-compiler-library-source-code-drop.aspx <comment><USER4> This is a good move. With Java under Oracle's control, Microsoft has a lot to gain by embracing open source licensing.

<comment><USER5> Does the Apache license include patent licensing? Java is open source too.

<comment><USER6> Yes.

<comment><USER7> Remember this only applies to the F# compiler and not to the .Net runtime which you need to run the compiled code. Microsoft is friendly with Mono currently, but so was Sun with Android.

</comment></comment></comment></comment><comment><USER6> It's interesting how the F# team is pushing F# to be the language for data- rich programming. Their Type Provider concept looks promising, but some of their demos still are comically difficult coming from a R/Matlab/Python style of data-rich programming. Of course coming from C#/Java it all looks amazing.

But I don't quite see how F# replaces R or Matlab, even with library support. Performance alone seems dubious value proposition, since packages like Jacket for Matlab make most computations extremely fast.

Anybody have experience where demand for strongly typed language is really needed for data analysis tasks?

<comment><USER8> "Anybody have experience where demand for strongly typed language is really needed for data analysis tasks?"

Strong-typing is not really about performance, though it does help. It's about discovering more errors at compile-time rather than run-time.

<comment><USER9> s/strong/static/g

[http://blogs.perl.org/users/ovid/2010/08/what-to-know- before...](http://blogs.perl.org/users/ovid/2010/08/what-to-know-before- debating-type-systems.html)

</comment></comment></comment><comment><USER10> "After some discussion, we've decided to do this via a "code drop" model..."

They lost me here.

<comment><USER11> They can't afford to do otherwise. Accepting community contributions will increase the MS surface area for copyright/patent infringements. The F# team is mostly a research outfit - they aren't going to vet patches.

<comment><USER10> Sorry, I just don't buy this. From Google, to Yahoo, to other teams in Microsoft, to small startups, to IBM, to single-person freelance developers-- each one of these groups have open source projects that accept community contributions.

If that increased the "surface area for copyright/patent infringements" were so great, or were such a dramatic burden, then the above would not be true. But it is true.

Let's look at Cassandra as an absolute prime example of what I'm talking about. The original version of Cassandra was a code drop by Facebook. It made some news in tech blogs, and then mostly everyone forgot about it. A few months later, another version was dropped, but this time nobody really noticed.

Then Jonathan Ellis found the codebase, imported it into GitHub, and started doing development on it in the open, and accepting patches. Sure enough, more people started to take notice and watch as development happened, and started to contribute back. A community started forming. Facebook then donated the project to the Apache Software Foundation, where it's continued to be developed in the open and thrive. Now it's supported by many companies; in fact new companies have sprung up specifically on the premise of providing support for it.

Empirically speaking, the software has had much more development since it switched to being developed in the open. Subjectively speaking, it's simply a vastly improved piece of software from when it was handled as a "code drop", it's boosted Facebook's credibility in the eyes of developers for having started the project, and it's gained much more popularity.

So, going back to F#, what are the goals that Microsoft is trying to further with its platform? I'll posit three (of which there are certainly more): to increase the reach of the .NET platform, to boost Microsoft mindshare, and to increase developer productivity.

Each one of those goals are served better by moving to an open development model, for fairly obvious reasons.

I didn't mean for this response to become so long, but it just seems to me that this is such an obvious and unfortunate blunder that it renders the whole open sourcing of the language nearly worthless.

<comment><USER12>
         From Google, to Yahoo, to other teams in Microsoft, to small startups, to
         IBM, to single-person freelance developers--each one of these groups have
         open source projects that accept community contributions.

The difference is that Microsoft is selling these products to companies that have idiots in charge and that won't touch anything related to open-source; although it's Microsoft's fault really.

EDIT: This is their excuse, that their customers prefer to be safe in regards to the IP they buy from Microsoft.

<comment><USER10> Are those people the same ones who would buy into an early-stage _functional_ programming language like F#?

<comment><USER13> Both sets of people can be present in the same company. There have been postings in the F# forums of devs wanting to use F# because they know it's good, but being very clear that corporate policy is going to restrict them unless certain conditions are met. Whether IP concerns from open source contribs is one of these, I dunno.

Nitpick: F# is really a multi-paradigm language. It truly does provide OO, functional, scripting and interactive styles.

<comment><USER14> > _There have been postings in the F# forums of devs wanting to use F# because > they know it's good, but being very clear that corporate policy is going to > restrict them unless certain conditions are met._

Maybe the F# people should rename it "C# Functional", then the devs can write code in it and if the managers say anything, just tell them it's part of C#, and they'll be none the wiser.

<comment><USER15> Someone here had a good way to do this (sorry, my google-fu is not strong enough to find the link):

"What language do you use?"

".Net"

"Oh, OK"

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER16> First IronPython & IronRuby (<http://news.ycombinator.com/item?id=1833772> ) and now this. I have to say, Microsoft is (or seems to be, depending on your philosophical disposition) increasingly embracing FOSS, and that's a very good move not only for them, but also the community.

<comment><USER17> Or using the dumping of stuff they don't care about to gain positive press from people who will never use them.

<comment><USER16> You're not implying that nobody uses F# or IronPython, right? That aside, I'm not in a position to know their motivation behind it, I can only say it's a good move for the FOSS community.

<comment><USER17> No, I'm not implying that at all. I don't doubt they are good products.

</comment></comment></comment></comment><comment><USER18> Java is Oracle stack, C# is MS stack, objective-C is Apple stack.

Is there an opportunity for an open language with similar VM ease-of- use/performance tradeoffs - or is hardware now fast enough for the ease/speed of dynamic languages to fill that gap (Python, Ruby, Javascript, ...)?

<comment><USER19> Haskell, Ocaml, and Scala? All are open languages, cross platform, and first two at least are Free. And Scala runs on both the JVM and .NET, covering all three platforms. Is that what you meant?

<comment><USER20> I believe by "haskell" you may mean "ghc"

<comment><USER21> Why? "Haskell" also works on hugs,yhc,uhc,... <http://www.haskell.org/haskellwiki/Implementations> Most implementations are BSD/GPL Licensed. Haskell itself (thinking of Haskell Prime, Haskell98) is a research/community driven project and, as such, open/transparent. For GHC there is even an intermediate format allowing you to run your code on stuff like llvm.

<comment><USER20> the original message was talking of specific "stacks", which in my understanding includes an abstract language and a concrete implementation (I'd say also some accompanying development tools: if not an ide, at least a repl, debugger, build system). "haskell" as such would not qualify, while ocaml, scala and ghc would.

</comment></comment></comment></comment></comment><comment><USER22> Great News! Mono here we come...

<comment><USER23> Just got through installing Ubuntu.

I expect to see some really good software come out of this. I think Microsoft bought a lot of goodwill with the community with this move.

<comment><USER24> Any ideas why the compilation is so slow? Compiling a simple "Hello World!" takes a noticeable amount of time on my reasonably well endowed laptop(i5, 4GB ram).

Is it slow just on linux/mono or that's the case on windows as well?

Other than the compilation time, all else seems well. I was following "Programming F#" and didn't run in any blockers on selective examples I tried. Once compiled, the performance is reasonable.

<comment><USER25> The compiler and interpreter aren't pre-compiled. Use the --resident flag - <USER2> will keep the F# compiler running as a service.

<comment><USER26> Thanks for the tip, the slowness of the F# compiler under mono was bugging me too.

</comment></comment></comment></comment></comment><comment><USER13> Does it mean anything in particular that they chose the Apache 2.0 license? Their previously public plans were to use MS-Pl.

<comment><USER11> The newer projects on the MS backed OuterCurve.org (formerly Codeplex.org) all use either an Apache or BSD license.

I suspect two reasons for MS accepting the Apache, BSD, and MIT licenses:

1) the terms of those license are not very onerous and let the end user pretty much do as they will. This is very important to a company like MS that has a lot of code and needs to be paranoid about subjecting themselves to patent suits.

2) Joe Briefcase has no idea what-so-ever what the "MS-PL" license is - <USER3> name recognition at all. The Apache/BSD/MIT licenses have been around so long and are so commonplace that they are generally acceptable to most everyone, and most developers shouldn't have a problem using one of those licenses.

<comment><USER12> Apache2 is not in the same league as BSD and MIT. It includes an explicit patents grant, versus GPL v2 which doesn't.

It's a strong license overall.

<comment><USER27> > Apache2 is not in the same league as BSD and MIT

From the point of view of a company looking to release proprietary products utilizing the licensed code, though, it's similar to BSD/MIT in a good way: you can do it without problems.

<comment><USER28> Plus, as it was pointed out, the patent grant prevents them from coming after you later.

</comment></comment></comment></comment></comment><comment><USER29> I wonder what it would take to remove the dependency on the .NET runtime. Could anyone with relevant experience and knowledge comment?

<comment><USER30> It could be done but it would be quite the undertaking.

The compiler generates il. The basic container types wrap .net types. Alot of the built in methods and power pack methods call out to .net methods. Many of the new features rely on new clr features, such as async.

Other platforms, jdk, probably offer similar functionality but to port it would be a case of having everything broken for some time until you could get the compiler and built in methods and containers ported over.

</comment></comment><comment><USER31> Are we getting any closer of developing .NET / WPF apps on Mac? (Wishful thinking, shameless cry)

<comment><USER6> I think you're looking for the MonoMac project. It's doubtful that you want to develop actual UI using WPF. Binding to native widget will give your app a much more integrated feel.

<http://www.mono-project.com/MonoMac>

</comment></comment><comment><USER28> That makes me believe there is no protection against contributor patents in the Apache 2.0 license...

At least they won't sue you if you use it under Windows.

<comment><USER32> You post uninformed crap like this, then complain about being downvoted for anything "negative against Microsoft": <http://news.ycombinator.com/item?id=1800507>

<comment><USER28> I complain when I am not wrong. This time I was _very_ wrong.

And now I know Apache has an explicit patent grant, something I didn't just 7 hours ago.

BTW, I upvoted equark's comment. And thanks for pointing me to my previous comment: I forgot to add the "but, karma, burn" part...

<comment><USER12> <http://lmgtfy.com/?q=apache+license+patents+grant></comment></comment></comment></comment>


Tesla Remotely Expands S & X Battery Pack Range in Florida from 60kWh to 75kWh - <AUTHOR> https://electrek.co/2017/09/09/tesla-extends-range-vehicles-for-free-in-florida-escape-hurricane-irma/ <comment><USER2> >The option would result in a less expensive vehicle with a shorter range, but the option to pay to remotely enable the longer range at a later stage.

DLC for Cars®

<comment><USER3> Also basically the way high cost digital lab equipment works. The high-spec and low-spec versions are identical, but the low spec ones have features turned off, using methods from easily by-passable resistors to cryptographic keys stored in a bit of flash

<comment><USER4> Has a market been made for people buying low-spec, modifying to be the same as high-spec, and selling for lower than retail high-spec price?

</comment></comment></comment><comment><USER3> Thinking about the recent leak/hack, the amount of data and control Tesla has of their cars is worrying. And they truly are TESLA's cars. Does Tesla lose access to the car once it has been fully paid off? How do I disconnect it from their network? How do I verify that they no longer have my place of residence after the car is paid off?

</comment><comment><AUTHOR> Posting this because this article seems to be the most information-dense and non-biased source on this Tesla remote update topic available. Other stories about this are either more fear-mongering or overly Tesla-praising and don't give as much technical detail.

</comment><comment><USER5> i like software-defined shit. but this is an example of dystopia any reasonable person should reject.</comment>


Elon Musk accuses the UAW of paying an employee to unionize Tesla – The Verge - <AUTHOR> http://www.theverge.com/2017/2/9/14570666/elon-musk-tesla-response-poor-working-conditions <comment><USER2> Color me shocked. This is nothing but an encore of the age old union m.o.: identify success and prey on it, siphoning off those sweet, sweet dues.</comment>


Ask HN: Can someone explain User lifetime analytics and stats - <AUTHOR>

I work in the gaming sector where we have many user who login to our app daily.  I am familiar with MAU and DAU but I would like better info on other interesting stat's or indicies that will help me read into the app usage itself. <comment><AUTHOR> Well our company is really interested in retention and trying to encourage users who download the app to keep the app on their phone and to open the app more regularly. I have been reading a lot about retention and there doesn't seem to be a definitive formula, what would you guys use?

</comment><comment><USER2> Yes, it really depends on your goals. Maybe this can help? [http://thinkvitamin.com/business/how-to-track-six-key- metric...](http://thinkvitamin.com/business/how-to-track-six-key-metrics-for- your-web-app/)

</comment><comment><USER3> It completely depends on what your company's goals are.

As an example, my company's goals revolve around getting users to come back at least once a month.

Have a talk with a more biz oriented person at your company.</comment>


Show HN: My small poll project - <AUTHOR> http://smallpoll.net/

<comment><AUTHOR> Of course, nothing fancy. Basic funcionality with few extra options, no clutter and unnecessary things.</comment>


Designing better file organization around tags, not hierarchies (2017) - <AUTHOR> https://www.nayuki.io/page/designing-better-file-organization-around-tags-not-hierarchies <comment><USER2> The article describes a schema extremely similar to what's implemented by [https://photostructure.com](https://photostructure.com)</comment>


Bitcoin Global, Bitcoin hardfork, launched - <AUTHOR> https://bitcoin-global.io <comment><AUTHOR> Bitcoin Global - the Bitcoin hard fork, featuring smaller blocks of 400KB is finally active.

Check [https://github.com/bitcoin-global/global- plane](https://github.com/bitcoin-global/global-plane) for references on how to join the community.

[https://bitcoin-global.io](https://bitcoin-global.io)

What is Bitcoin Global and why was it created?

Due to the fact that high barriers for entry into Bitcoin mining ultimately act as a centralizing factor, as only those with lots of resources to deploy are able to join, we have introduced smaller blocks in Bitcoin Global.

By introducing smaller blocks of 400KB, Bitcoin Global implements a sustainable economic model for all chain participants, ensuring at the same time that decentralization and profitability are maintained. Most importantly, smaller blocks translate to a higher total number of nodes due to lesser computational power requirements and more nodes on the other side ensure an increased degree of decentralization.</comment>


Pirate Bay Co-Founder Plotting E-Book Plunder? - <AUTHOR> http://feeds.wired.com/~r/wired/index/~3/403851231/pirate-bay-co-f.html

<comment><USER2> I can sort of agree.

I got in early on O'Reilly's Safari bookshelf. For work, it's great. It's like a privatized library of great technical material. But reading it can be a little bit of a pain since it's on on the computer screen. The kindle display is too small for most technical material (diagrams and code listings are impossible). I got a Sony reader and found it to be great for novels. However, recent developments with 8.5x11 inch e-ink displays would be great for what I need for work. Even better if it could have a few pages.

For college textbooks it can be different. I wonder if they might become obsolete sooner or later anyways.</comment>


API - <AUTHOR> http://xkcd.com/1481/

<comment><USER2> Joke aside, I highly recommend watching this talk about Comcast's HTML based APIs: [http://www.infoq.com/presentations/web-api- html](http://www.infoq.com/presentations/web-api-html) .

<comment><USER3> In my interactions with them, I would say that Comcast has some very smart, very capable people working for them who really get technology in the HN sense. They care about doing things the right way, because everything they build has to be instantly scalable. They understand that the world doesn't revolve around them, and they need to use open standards where they exist. They even contribute back to a great many open source projects.

Unfortunately, the customer support part of the company does not share this quality. But don't punish the developers for it.

But should you ever meet a Comcast employee at a technical conference, realize that they hate the evil Comcast machine as much as you do. But they're working from the inside to try to make things better -- at least as much as they can as a developer.

<comment><USER4> What are the merits of Comcast that one would work there to try to make things better?

<comment><USER3> The same as any other programming job? Well, except the pay and benefits are pretty good from what I hear.

</comment></comment></comment></comment><comment><USER5> Aren't all those Microdata and Microformats things API's over HTML? Maybe those things could get another look by normal developers.

That said, the people at the IndieWeb[1] movement are makign heavy use of microformats2[2] to create beautiful HTML decentralized social networks.

[1]: [http://indiewebcamp.com/](http://indiewebcamp.com/)

[2]: [http://microformats.org/wiki/microformats2](http://microformats.org/wiki/microformats2)

<comment><USER5> Interesting read: [http://indiewebcamp.com/API](http://indiewebcamp.com/API)

<comment><USER6> Following your breadcrumbs. I found another winner: [https://tommorris.org/posts/8070](https://tommorris.org/posts/8070)

Thanks for this.

</comment></comment></comment><comment><USER7> Shouldnt the url have used httpS:// ?

</comment><comment><USER8> sort of reminds me of that airtime challenge I took. [http://challenge2.airtime.com:2324/instructions](http://challenge2.airtime.com:2324/instructions)</comment>


Show HN: IonMag – a new open source WordPress theme for blogs and news sites - <AUTHOR> https://www.wpion.com/ionmag-theme/ <comment><AUTHOR> For the last eight months, we worked on a challenging new project. Our plan was to create an open source, responsive WordPress theme dedicated to blogs, news and magazine websites. We wanted to craft a solution that will change the way users build and manage their sites. The development period is over, and we are proudly introducing ionMag.

We welcome any feedback and if you have any questions please ask here.</comment>


Digg for startup pitches - <AUTHOR> http://pitchups.com/

<comment><USER2> Interesting, it says on the About page that the site was inspired by Robert Scoble's question on Quora..

<comment><USER3> That Robert guy is everywhere..:-)

</comment></comment><comment><USER4> Good platform for start ups & new ideas and also the networking part is cool..

</comment><comment><USER5> good idea - need a site like that!</comment>


Is it a good sign that everyone thinks my ideas are crazy? - <AUTHOR> Compostable servers, smart pens, ternary computing, mass spectrometers in every home etc.. etc... <comment><USER2> You might want to put ASK HN: in the title.

And you probably want more information in your post.

What is a compostable server, and why is that a good idea, and how would it work?</comment>


Ask HN: Want to sell my Mac app to a new developer - <AUTHOR>

Howdy, gang; I've got a mildly successful Mac app that I just don't have time to keep up with. It brings in a few hundred dollars of passive income every month, but I feel bad for not having the time to devote to it.<p>I'd like to sell it to a new developer, but I have no idea how to go about it. Does anyone here have any advice on how to go about such a thing? <comment><USER2> \- Depends on the app & its nicheness & audience.

\- I think a common upper end of the range for web apps is something like 10x yearly revenue.

</comment><comment><USER3> Check out Flippa maybe. You won't get much for it.

</comment><comment><USER4> mentioning the genre would be good.</comment>


A Java old timer reminisces - Oak, 0XCAFEBABE, Green Threads, RuntimeException - <AUTHOR> http://suprgeek.wordpress.com/2009/07/29/a-java-old-timer/

<comment><USER2> "What is the meaning of the name 'RuntimeException' ? Why is the class so named? Think about this for a minute ... ALL exceptions are thrown at runtime right?"

That has been bothering me subconsciously for years! It is very nice to have the explanation for the name:

"Recall that Java has a class called as the "Runtime" class – an abstracted representation of the underlying Java Virtual Machine that allows us to add hooks and get information. So the simple answer to "What is the meaning of the name RuntimeException" is "It is an exception thrown by the Runtime itself" rather than any particular piece of code."

</comment><comment><USER3> While I'm not a Java developer, I was trained on Java in the late 90s and knew about Oak, Green Threads, and the RuntimeException class. 0xCAFEBABE caught me off-guard, though, because I have always known that as the magic number designating Mach binaries on OS X. Anyone know what the connection might be?

<comment><USER4> It's quite possible there is none, and they're independent "inventions". There aren't that many four-letter words composed of hex digits (by my reckoning, the only common ones are BABE, BEAD, BEEF, CAFE, DADA, DEAD, DEAF, DEED, FACE, FADE and FEED), and stringing two together to get a magic number must be a popular pastime. In fact, Wikipedia has a list of them at <http://en.wikipedia.org/wiki/Magic_number_%28programming%29> under "magic debug values", which demonstrates that 1337 can get you some more.

<comment><USER5> In the late 90s, I cracked a shareware but didn't do it too well, it was a quick and dirty jump flip; the developer was testing for cracking attempts, and as soon as I left the debugger and stepped back into ring-3 I notice my Windows start button now read "0xDEADBEEF".

<comment><USER6> It takes some courage to admit that on a site populated by software entrepreneurs.

(I'm not condemning you -- but I do think that cracking shareware is the computer equivalent of meticulously planning how to steal coins from the collection plate at a slum church.)</comment></comment></comment></comment>


Hacker culture and the fear of wysiwyg - <AUTHOR> http://i.liketightpants.net/and/hackers-culture-and-the-fear-of-wysiwyg <comment><USER2> First off, WYSIWYG HTML editors exist and have existed for years.

The author is glossing over the biggest issue. Nobody writes web pages like they use word. Nobody just types up an html page from <html> to </html> and then moves on to the next page—WYSIWYG editors would be great at that.

The author mentions "static site generators", and that is the crux of the issue. Nowadays HTML is usually built by templates, sometimes even transpiled from something else entirely (HAML, etc). There's still markup but it's surrounded by template directives which can be fairly complicated turing complete languages in and of themselves (Template::Toolkit and HAML both will let you drop down to the parent language if you need to).

Even if there were some sort of nice, usable, visual programming language, WYSIWYG would still be problematic since you would have to show the loops and conditionals and such superimposed with the HTML (otherwise how can you edit something that isn't shown) and as soon as you see the structure of it all, it isn't WYSIWYG any more (by definition).

The fact is, we in the hacker culture don't embrace WYSIWYG and hang on to our terminals because we're stubborn old codgers, it's just that we've experienced both and we know which one is better.

<comment><USER3> I think the author is rather talking about <textarea> vs rich text editor widgets for user supplied content, and not really about things like Dreamweaver.

<comment><USER4> Ten years ago I worked for a web dev company that embraced rich text editor widgets for user supplied content. It was great. We charged them an arm and a leg for the ability to edit their content, then we charged them more to fix it when they broke it or couldn't do what they wanted, which was always.

Subsequently, when I'm doing websites for myself or for people who I like, I don't use rich text editor widgets.

It's possible I'm stuck in the past, but it's not an ideological issue.

<comment><USER3> I have the opposite experience. Clients love WYSIWYG for two reasons:

1\. They don't need to train their data entry employees in markdown or similar.

2\. They can copy paste rich text from MS Word, rather than having to pay somebody to transliterate it into markdown.

The number of support requests for WYSIWYG is vastly lower than for markdown.

</comment></comment></comment></comment><comment><USER5> The author is ignoring the elephant in the room: WYSIWYG is for static, single format output. It doesn't define _behavior_.

Even after so many years, MS Word is still only suited for print and static digital facsimiles of print documents. It fails miserably at anything else it tries to do.

Fuck, WYSIWYG is not even suitable for creating good multiple resolution purely static output on nearly identical devices. For the simple reason that if you want to get that right, What _You_ See Is Not What _Everybody Else_ Gets.

WYSIWYG only has value in tight, never changing constraints, and those are actually disappearing more and more in favor of interactive, fluid forms of output.

WYSIWYG is not the future, it's a relic from the age of print.

If there is a way to make the power of raw code more user friendly and accessible, WYSIWYG isn't it. The whole acronym suggest something that doesn't exist and/or is utterly undesirable in a digital world.

What _you_ see is not what _I_ want to consume.

<comment><USER6> HTML doesn't define behavior either, but it can be combined with tools that do (scripting languages), in the same way that WYSIWYG tools can. That's not a valid argument to prefer textual over visual representation.

</comment></comment><comment><USER7> I picked up an allergy for WYSIWYG while reading through the works of Engelbart. It's not flexible enough and locks you down to a way of think which does not properly leverage the advantages of our new medium; related:

>Our approach was very different from what they called "office automation," which was about automating the paperwork of secretaries. That became the focus of Xerox PARC in the '70s. They were quite amazed that they could actually get text on the screen to appear the way it would when printed by a laser printer. Sure, that was an enormous accomplishment, and understandably it swayed their thinking. They called it "what you see is what you get" editing, or WYSIWYG. _I say, yeah, but that 's all you get_. Once people have experienced the more flexible manipulation of text that NLS allows, they find the paper model restrictive.

 _We weren 't interested in "automation" but in "augmentation." We were not just building a tool, we were designing an entire system for working with knowledge_

\- Douglas Engelbart; [http://archive.wired.com/wired/archive/12.01/mouse_pr.html](http://archive.wired.com/wired/archive/12.01/mouse_pr.html)

> Question: Isn't it great the we now have WYSIWYG technology so what you see > is what yo get. You can print it out, you have wonderful, good looking > documents with all kinds of typefaces?

Answer: That really is nice for the people who want to stay where they like used to be... That ignoring hugely all the other options you have...

[http://www.invisiblerevolution.net/engelbart/glossary/wysiwy...](http://www.invisiblerevolution.net/engelbart/glossary/wysiwyg.html)

<comment><USER8> Here is the way I look at it.

If one is capable of holding the entire conceptual abstract ephemera relating to the concrete problem you are solving, then WYSIWYG is mentally jarring as it often takes away from proper semantic representations of concepts. Indeed very often WYSIWYG attempts to hide semantic meaning from users in an attempt to make it seem easier. Of course for the simpler case this is true. But for complex cases where structure and uniformity and restructuring are important use cases then WYSIWYG is destructive compared with a much simpler markup.

I'd also argue with little evidence that there is something mentally jarring for the competent about self expression when having to await moving your arm to do something with a mouse in the midst of the flow of editing.

</comment></comment><comment><USER9> I think hackers (in any field) like "productive" user interfaces, everything else is irrelevant. There are productive WYSIWYGs and GUIs, look at e.g. Blender, but they are usually hard to learn and/or they look really ugly, so they are not appreciated by commoners or designers.

For the UI to be productive, it has to have a couple of features:

\- Highly configurable, possibility of presets

\- Accessible only by keyboard

\- Available for scripting

You can combine those with smooth learning curve and nice design, but it's _very_ hard thing to do. That's why application builders (on either side) usually don't bother.

<comment><USER10> > _very hard thing to do_

That's pretty much the entire reason. Plain text is easy and maps 1-to-1 with the keyboard you have right in front of you. And even when you start binding commands to keys, there isn't too much choice to be made.

Making good complex GUIs is really hard and it seems to have the same kind of inherent complexity like programming - you can't simplify it past giving the developer a really shiny tool with which to put buttons in widgets really easily, which doesn't at all mitigate the hardship of designing exactly where the buttons go, what they say and how they act.

</comment></comment><comment><USER11> I strongly disagree. The author is ignorant of the issue, but instead of realizing what he does not know about, he creates an entire narrative with the elements he has.

The problem about web interfaces is not programmers, it is that: You have absolutely NO CONTROL on the ending display.

That's it. You have not control on aspect ratio, on resolution, on how fast the computer is and even in the link velocity.

So if you are a designer and something WYSIWYG works so well in your retina display screen and fiber optic Internet connection does not mean that works out there on a myriad of different user choices.

WSYIWYG is a terrible solution when you have different alternatives. E.g If you have 6 displays aspect ratios(4/3 16/9 the new surface pro 3/2 and the portrait version of those), 4 main resolutions, 3 main Internet velocities, and 4 computer power(based on how old the computer is), you have: 6x4x3x4 = 288 possibilities.

Now, have fun testing at least 288 different versions of everything you do (there are other possibilities like people with disabilities that in some jobs like gobertment work you have to do), while the Unix Hackers, and children eaters Gatekeepers just do it once.

I for one want to improve the system, but text(code) is one of the best solutions we have so far. The reason there is no something better is because people are able to spend a significant amount of time ranting about others instead of doing something about it(and facing lots of problems that ranting does not have like the possibility of failure as we underestimated those while on our arm chair).

</comment><comment><USER12> As I see it, WYSIWYG works great if you create a non-interactive thing, like a document, image or video. As soon as you want to present the same information in several formats, or show headlines of articles in several places you need to abstract those things. None of this is impossible with WYSIWYG, but it is usually much more work than just having some kind of plain-text at the core.

On the other hand, a well-executed WYSIWYG editor with a well-defined abstract document model would be a great thing. The abstract document model is really essential (and probably plain-text based). The minute you let people WYSIWYG edit, they start doing formatting oriented things such as add spacing using actual spaces. It looks the same on their screen, but might break other formats of the same information. If you tell them to stop doing "that kind of thing", then very soon they are essentially doing plain text-editing with a WYSIWYG tool.

<comment><USER10> > _they start doing formatting oriented things such as add spacing using > actual spaces_

Then perhaps the space key on the keyboard should be tied to adding spacing, rather than space characters. That's really a failing of the WYSIWYG editor to take into account normal computer peripherals. The user wants space. The user has a large board with keys on it with a huge "space" key. The user presses the large space key and gets space. A good WYSIWYG editor should account for the fact that my keyboard has keys on it that aren't letters.

<comment><USER13> Let's continue with that approach.

Then maybe hitting a letter should only render the letter at the same size and font as the one printed on the keyboard.

And if you want to change the font, well it's just a drawing, so you can't. It would make the keyboard non-WYSIWYG.

<comment><USER10> I was advocating the exact opposite.

</comment></comment></comment></comment><comment> workhere-io Once you leave design and layout to non-designers/non-layouters, they will ruin everything, and you will get angry calls from the companies' designers, complaining about how their beautiful design was ruined by someone using Comic Sans on a header. I've seen it happen. _This_ is why CMS makers know that editors / article writers should not be allowed to design/layout pages.

Ideally, a WYSIWYG editor in a CMS should only allow users to use bold, italics, links, and perhaps insert small images. Anything more than that, and your web pages end up looking like MySpace/GeoCities.

<comment><USER6> There's no reason why designers and ''layouters'' couldn't use WYSIWYG tools nor should be forced to use plain text in order to design the visuals of the site. Your argument is against letting end-users control the whole process, but it's not an argument against WYSIWYG per se.

<comment> workhere-io I see what you mean. However, given the large number of different CMSes, I'm not sure designers would appreciate having to re-learn how to design every time they use a new CMS. Right now they use a relatively small "default" set of tools, with PhotoShop being the chief one.

I'm not a designer, but my feeling here is that designers wouldn't appreciate the workflow you're suggesting. Any designers here who'd like to weigh in?

<comment><USER6> That's why design tools in visual CMS should be integrated with the current methods that designers use in specialized apps :-)

Who says you can't merely reuse the same basic workflows that have been refined by professional designers, augmented with general-purpose mixed visual-textual scripting? That sounds like a winning strategy to me.

Designers ''do'' learn ad-hoc batch processing tools for image transformation and publication of the final work; having those standardized would be a net win.

</comment></comment></comment></comment><comment><USER14> > a programmer-driven choice for Markdown forces the Unix love of editing > plain text onto everybody.

If you really want revolutionary WYSIWYG interfaces that much then learn programming and develop them yourself. But by then you probably will have recognized the superiority of plain text anyway.

<comment><USER6> Plain text is not superior, merely more well-supported because the libraries for it have been around longer, and standards for it had been created. If adequate standards for WYSIWYIG were created, it would be definitely better than plain text from an end-user point of view.

In fact, there are numerous cognitive drawbacks that can by corrected by using secondary notation (available either in WYSIWYG and markup), so unadorned plain text is objectively _worse_ than rich text - if only good tools existed for the latter; the author is right in wanting hackers to make those ubiquitous.

<comment><USER15> _Plain text is not superior, merely more well-supported..._

That's a very important fact.

 _If adequate standards for WYSIWYIG were created..._

I wouldn't say "standard", but more like "paradigm" (nice, first time I've actually used that word).

There's that "war on trees" thing that I hope gets abandoned as soon as possible.

</comment></comment></comment><comment><USER16> The problem with WYSIWYG is that it is hard to automate (and is not composable). I have already worked with a "WYSIWIG tool chain" : you can't build something without someone hitting some button on a graphical interface multiple times at periodical time. It is a real pain when you want to set up a CI server. Or simply if you want to execute a build during your lunch... I have no issue with WYSIWIG _per se_ , but you have to provide me with an alternate path to complete the same task automatically/remotly/with a cron job, etc. So the original poster might have relevant points regarding visual design, but there are reason why developers tend to favor scripts, shell, terminal, it is not purely a cultural issue.

<comment><USER6> That's not an inherent property of WYSIWIG. You could equally say that _" The problem with building code is that it is hard to automate (and is not composable)"_, which is true of most programming languages, but then there are IDEs that largely automate tedious programming tasks and there are languages designed for meta-programming; what is lacking is good support from dedicated tools, and a design for automation.

I have some ideas of my own on such system could be built, but fortunately many other independent initiatives have emerged lately in that direction (mainly thanks to the ideas by Bret Victor, and all the recent advances in the intersection between Reactive Programming and user interfaces).

<comment><USER16> I wholeheartedly agree it is more an ecosystem issue, but like I said I have no issue with the concept of WYSIWIG itself, just that as of today, they are lacking some characteristics for being efficient. And it is true that the lack of innovation in that area might be a result of habits or culture.

</comment></comment></comment><comment><USER17> I believe, contrary to almost all programmers, that this is in fact fundamentally a cultural problem, as the author points, out, and NOT a practical or technical problem. I think the problem is more fundamental than the author suggests though.

Fundamentally programming (or software engineering, web development, etc.) is defined by editing textual source code. That's the definition. WYSIWYG is not, by definition, programming. By definition, WYSIWYG is sort of the opposite of programming. Programmers are proud of their ability to create textual source code that is processed to create programs or output.

Think about a specific programming activity. For example, creating a web application. If, rather than using code, I use a GUI tool to define the fields in my database, create links between tables, define and style forms for entering and displaying the data, am I programming? If that's the way I build web applications, am I a programmer? What if instead I find a Go-based Object- Relational-Mapper, write some SQL scripts to create the database schema, use SASS to define the styles for my web-based forms, etc. Now, did I do some programming? I created the exact same web application with two completely different approaches. Using the first method, I cannot call myself a programmer (some may argue this, but the general impression most programmers will get, perhaps unfortunately, is that I did not do programming and am not a programmer). In the second method, I used much more effort and achieved the same effect, but I did it by writing textual source code. Therefore in the second case I am a programmer. The difference is simply that I wrote textual source code.

Now, I am not saying that WYSIWYG editors cannot produce complex computer programs, even ones that are exactly the same as those created in text editors, or that I believe that WYSIWYG should NOT be considered programming. I think actually we should update our definition of programming to include WYSIWYG, and I believe that old definition is the main thing holding back software engineering.

Its really as simple as that. Text = programming. Not text = not programming. That means we are stuck in the 70s forever. Its a cultural failure.

<comment><USER2> > Programmers are proud of their ability to create textual source code that is > processed to create programs or output.

I fundamentally disagree with this. You're acting like programmers/hackers do things in a textual way just to justify their existence.

Those GUI tools you posit exist—my Dad (who is technical but not a programmer by trade) used FileMaker to develop a little app for his church sometime in the early '90s and still to this day uses it. Does it matter that he didn't write any code? No. He produced a useful app and it's that end result that matters.

The problem is not that those tools don't exist, and it's not that "real" programmers look down on them just because they aren't textual. The problem is that those kind of tools are just fine, _as long as you don 't do anything complicated_. Once you stray a little off the path of their standard use case then they crumble into a pile of leaky abstractions.

When you're dealing with textual programming languages it's generally much easier to stray from the beaten path since they are usually much less constrained. If you're writing a web app in Ruby, or Node, or Java, or whatever, you can do _anything_. It's more flexible, but at the cost of being more complicated. And the more complicated things get, the harder they are to shoehorn into a gui.

I'd love to see a gui programming language that was as open ended, as easy/quick to edit, and as easy to visualize as textual code in a text editor is, but they don't exist. And I fear they never will.

<comment><USER17> > —my Dad (who is technical but not a programmer by trade)

If he wrote it in a 'real' programming (textual) computer language you might have written that differently. You might have written "technical but not really a programmer" or something.

> Does it matter that he didn't write any code? No.

Yes, it does, because if he had you would have given him credit for being a programmer and acknowledged that his application is complicated.

I wonder how long it took your father to create that application with FileMaker. I would like to see how long it would take you to code it "from scratch" using your favorite "real" programming system.

<comment><USER2> > If he wrote it in a 'real' programming (textual) computer language you might > have written that differently. You might have written "technical but not > really a programmer" or something.

I wrote it the way I did because it's more nuanced than that. My dad can program. He's written assembly and knows some C. But he's not a programmer by trade—he's a hardware guy.

</comment></comment></comment></comment><comment><USER18> The main reason I prefer to work in a text editor, is it limits the number of tools I have to learn to use.

When I used to work as a 3D designer, I became an expert at Cinema 4D. But there were times I had to switch to another application due to the limits of C4D, and I would become lost in the UI of Maya or Max, unable to perform the simplest of actions without the assistance of Google.

My preferred text editor is Emacs, and I rarely need to use another application other than Firefox. With my text editor I can code, write markup, keep a calendar and todo list, open a shell, chat on IRC.

In a WYSIWYG world, you have a dozen different applications to perform a dozen different tasks, and each requiring an in depth knowledge of that application. Yet in reality, each application is simply editing plain text.

<comment><USER19> Your argument seems to be that switching between WYSIWYG applications can be confusing whereas not switching between text based tools is not. Presumably if you were continually switching between multiple text-based editors, each with their own abstruse command key combinations, you would find that even _more_ difficult than switching between graphical tools.

<comment><USER18> Switching between WYSIWYG applications is confusing and it would be if I was switching between multiple text editors as well. It would be a nightmare if I had to use Vim to code, Emacs for my calendar and Sublime for markdown.

I don't have to though, as I can do pretty much everything I want from a single text editor. Yes, there are different 'modes' to master, but most of the underlying commands are shared between modes so the learning curve is shallower.

</comment></comment></comment><comment><USER20> I remember RMS wanting WYSIWYG feature for Emacs recently:

[http://lists.gnu.org/archive/html/emacs- devel/2013-11/msg005...](http://lists.gnu.org/archive/html/emacs- devel/2013-11/msg00515.html)

</comment><comment><USER21> Not sure his argument stands up very well. Not even MS Word can make something looks good on multiple sizes of paper.

<comment><USER6> A single poorly implemented tool doesn't invalidate a whole style of interaction :-)

<comment><USER21> Accepted, but when your argument uses it as the example to follow it's very hard not to criticise on that basis. I think a more appropriate tool would be Microsoft Visual Studio.

Talking about visual tools, many moons ago I worked with NetObjects Fusion ([http://netobjects.com/html/website-design- software.html](http://netobjects.com/html/website-design-software.html)). It actually dumbed down development and did not help you understand the underlying technology.

I honestly think in this domain tools that 'hide' implementation from you are not healthy. I do think frameworks have a major role to play, but they 'enable' you to do things better and in a more consistent way.

<comment><USER6> I agree that hiding the underlying technology is not the way to go; though I believe that highly automated "dumbed down" generators like NetObjects may be problematic mainly because of an impedance mistmatch between the interface and the underlying implementation; not because that creation style is essentially wrong.

But what if the underlying technology itself were made consistent with that style of development? Things like the Smallest Federated Wiki [1] make content closer to the metal, so that there's just a thin layer between presentation and storage (just like there's one in plain text editors).

Also Wikipedia shows how a mostly-visual environment can be the basis for complex categorization and building semi-automatic processes. Most semantic tasks there are handled purely with wiki markup, including the triggering of automatic bot edits against vandalism or for cleanup, or building ; and that markup is susceptible of being made visual (as the new Visual Editor shows, although that's a bit _too_ visual for my tastes).

Sure, building new templates and bots on the MediaWiki platform still requires classic development, and there will always be tasks that are better handled with textual descriptions, but there are still huge possibilities to move general development towards a mixed visual/textual environment, keeping the best of each.

[1] [http://fed.wiki.org/view/welcome- visitors](http://fed.wiki.org/view/welcome-visitors)

</comment></comment></comment></comment><comment><USER22> "What you see is what you get". Great! - however it assumes that your audience is using the same media presenter, e.g. use Word to depict an A4 and you print an A4. What if I want it as a webpage as well, do I have to type it twice now? Does someone remember how horrible this even is when you export a webpage from Word. This stuff is not solved, and is only getting more difficult in the age of 3" up to 70" screens

</comment><comment><USER23> One of the goals the VPRI team had in the STEPS project was to put together a WYSIWYG document editor. They did so within their 20,000 total lines of code limit.

Which isn't to say that doing it is easy just because the amount of code needed is small - it's more a statement about the industrialized model of coding that we've chained ourselves to. Nobody can afford the pure-research grade of time and dedication to build and iterate towards a beautiful design that is not just engineered well, but aspires to a mathematical grade of implementation with not a character wasted.

So we build ungainly things to meet our hair-on-fire needs, and copy things out of them when happenstance allows them to be reused. And so in all likelihood we're constantly, invisibly shortchanging the future because we have to focus on shipping our shovelware instead.

And I think the text files end up being part of that, because they're precisely the protocol that makes it so easy for stuff to be copied _inelegantly_. We bend everything around whether it's easy to copy from text and whether the editor we already use can read it.

</comment><comment><USER24> Doing a WYSIWYG tool which doesn't get in the way of advanced users is extremely hard. Look at 3D content creation tools like Maya, this has been built from the ground up to be programmable and extensible over nearly 20 years, while still being an intuitve "WYSIWYG" tool. Someone completely new to 3D modelling and animation would still be completely lost, but that's not the target audience (that's where I lost the author, does he want to empower 'noobs' by giving them the illusion that they can accomplish great things without learning, or does he really care about productivity for power users). In my experience, good tools can have complex (UI) interfaces as long as the interface is discoverable, and they should be automatabable/customizable through programming interfaces. I see myself drifting back to the command line in the recent years, just because many things don't require the overhead of an UI.

</comment><comment><USER15> There's no rule as to how good a WYSIWYG interface can be. Make one that's more productive than the corresponding text interface and we'll use it. Hackers aren't holding back anything.

<comment><USER6> Are you sure of that? Object orientation _was_ a visual programming environment at first (see Smalltalk), and look at what hackers "from the Unix tradition" have made of it. ;-)

<comment><USER15> Some problems and their evolution is better understood if you focus on what's wrong instead of what's right. Either you have every requirement covered or you're going to fail.

There ain't no justice here. You may have created some brilliant architecture, object system, whatever. But if --let's say-- it's too slow, people won't use it.

</comment></comment></comment><comment><USER25> I think wysiwyg editors are also only useful in certain cases - CMSs, blogs, DTPs - the sort of systems where the data entered is the information you will see. There are large categories of applications, however, where the data entered is first aggregated/manipulated before it is useful for any sort of output - in these cases, wysiwyg is just not the way forward.

</comment><comment><USER26> This reminds me a lot of Naviedge ([http://naviedge.com](http://naviedge.com)), something I made for hotel concierges a couple years ago. A huge part of the technical burden was making the itinerary editor WYSIWYG in a cross-browser, mobile-friendly way. Much harder than it looks.

</comment><comment><USER27> It is not fear, when I design for me I don't do a WYSIWYG unless it has some benefit or trade off for me. Now that benefit can be monetary i.e. I get paid to do WYSIWYG. I'm a selfish git I know... but that is the way it is. I'm not afraid of it, I'm just being me.

</comment><comment><USER28> LaTeX was the first that came to my mind when reading it. Very interesting.

</comment><comment><USER13> Uhmm.

Ok, let's say you're Tour de France competitor, and you're told to use this:

[http://www.christydena.com/blog/wp- content/uploads/2010/02/t...](http://www.christydena.com/blog/wp- content/uploads/2010/02/trainingwheels.jpg)

Is "fear" the correct word for your reaction?

WYSIWYG is a good thing in predominantly visual programs (photo editing, vector illustrations, animation tools).

WYSIWYG becomes a problem when the content being entered has semantics without explicit visual cues. By definition you can't have a "WYSIWYG" for semantical information, and if you give people a WYSIWYG HTML editor to enter content, they'll just tweak the code until it "looks" right, which will bomb when said content has to be transferred to a new medium (say, non-HTML).

People may be liking Word, but the majority don't use it semantically, they just mash the font settings until the document looks approximately correct, never mind the document outline is a mess, because half their headlines are not headlines, but paragraphs with enlarged text.

<comment><USER29> You're right, I think the author has a point but putting it all under the umbrella of "WYSIWYG" is not helping it.

For instance, I agree that the current mostly text-based interface to programming could be improved dramatically by abstracting ourselves away from the source files towards a more visual representation of the code, showing dependencies between functions etc... Syntax highlighting doesn't quite cut it. I wouldn't call that "WYSIWYG" at all though.

In essence most source code is a graph of function calls and it's very hard to represent that in plain text. There have been some efforts in that direction (lately I remember the light table editor for instance) but at the end of the day I'm still editing ASCII files in emacs...

What we need isn't WYSIWYG, it's better visual representation of the data we're manipulating.

<comment><USER30> I notice your response was in the form of a few paragraphs of text, rather than a photo or diagram. Most conversation are "text-based". Our human brains have hardware acceleration for text processing and we're quite good at it. Since programming environments exist to make the best impedance match between programmer and machine, they use text. Language uses incredible composability to encode great complexity.

Flowcharts are one implementation of what you propose. Or LabView: [http://www.ni.com/cms/images/devzone/pub/nrjsxmfm91216399872...](http://www.ni.com/cms/images/devzone/pub/nrjsxmfm912163998723206173.jpg)

<comment><USER29> You'll also notice that while the comments are all plaintext, they're presented hierarchically as nested trees. There's also a hyperlink in your comment that I can follow easily, that's not plaintext.

I'm not saying plaintext is bad, I'm just saying that we're not stuck with 80x25 green-on-black terminals anymore, there's room for improvement using our modern display capabilities.

<comment><USER13> Why yes, we're not stuck with 80x25 green on black terminals.

Why even mention it? By the way that nested hierarchical tree is also written in text (HTML and CSS). So is the hyperlink. URLs? Text.

Check any modern IDE and you'll see similar visualizations over text based source code. I can explore my project in a tree-based outline in my IDE. I can open my classes as an UML diagram.

Turns out we're already in the future. Celebrate?</comment></comment></comment></comment></comment>


Comix-35 Home Computer - <AUTHOR> https://github.com/schlae/comix-35 <comment><USER2> Going a bit off topic here, but I love that it's called a "Home Computer."

Computers used to be a family thing. Back then it was a bit of a status symbol to have a "computer room" for the family "home computer," and many a den or library or spare bedroom in middle America was converted to being The Computer Room. The ads on TV and in magazines showed families gathered around this new wonder machine, and even in my dysfunctional household that really happened. Family members who wouldn't normally speak to one another would come together at the home computer.

Today, we have "personal computers." A term which evokes a more "me and mine" vibe, rather than an "ours" ethos. We picked up the "PC" term from the business world, where it was an important distinction that each person could have a computer, rather than rely on the company's shared resources. But that term should have stayed in the office.

There's a reason that early video game machines, and even some computers, had four controllers — because people would come over to your house and you did things as a group with other human beings. That's why everyone had candy dishes in the living room and guest towels in the bathroom — in case "company" came over.

Now, the state-of-the-art is being locked alone in the dark in a "media room" with goggles and headphones in your own cocoon, shutting out the real world, and the human beings in it.

<comment><USER3> I'm of two minds about this. On the one hand, it all sounds nice on the surface. On the other hand, I definitely wouldn't be a developer today if other members of my family were in any way interested in computers as I was. Learning is a personal activity, and computers were a scarce resource back then.

Competing for computer time is one of those childhood memories I'm least fond of.

<comment><USER2> _Competing for computer time is one of those childhood memories I 'm least fond of._

I understand competing for computer time. I had to sneak in computer time at school because boys weren't allowed to use the computers. You were required to take typing classes before you could get into the computer classes, and only girls were allowed to take typing.

</comment></comment></comment><comment><USER4> Oddly enough, the CDP1802 CPU appears to still be an active product via Rochester Electronics, although the peripheral chips aren't.

<comment><USER5> It is one of the few radiation hardened processors available and still finds use in defense and aerospace applications.

<comment><USER6> Gee, it sounds like tinkering with the Comix-35 could be a path to a career that you couldn't talk about!

<comment><USER5> Eek, talking of legacy code! Legacy code determining life or death at times..

</comment></comment></comment></comment><comment><USER5> Ah, the venerable 1802, the stackless wonder! My first computer was an 1802 based project published in a dutch radio amateur magazine called the "The Cosmicos" mostly build using "engineering samples" I begged of of manufacturers. Good times!

<comment><USER7> Yeah, back in the day it was sneeringly called a "nanoprocessor" rather than a microprocessor by fans of the competition.

For a few years in the early 1980s I had a kit based on the 1802 with a whole 2 kB of RAM and a hexadecimal keypad. Fun times.

<comment><USER5> I started out with binary switches and led's. A hex keypad was an improvement... Later I got a loud surplus mechanical tty, my mother was not happy!

</comment></comment></comment><comment><USER8> I'm impressed that he could find keycaps:

[https://www.amazon.com/gp/product/B083L6FVPN/](https://www.amazon.com/gp/product/B083L6FVPN/)

</comment><comment><USER9> Am I crazy or is there no enter key on that keyboard?

<comment><USER10> As the text explains, the tab key is enter.</comment></comment>


Your server is not a pet - <AUTHOR> https://www.madetech.com/news/your-server-is-not-a-pet

<comment><USER2> Screw that. My servers are pets and I loe them. Each and every one.</comment>


Apply HN: Dribblr – app to organize pickup sports - <AUTHOR> Dribblr will allow players to create games, invite FB friends and saved groups of friends, view RSVPs,  and split costs through RSVPs. Invites can be sent to contacts regardless of if they have Dribblr or not. Players looking for a game can search a map view or a chronological view with the sports they like, get invited to games, or set up subscription alerts.
The novel part of the app is the SUBSCRIPTION PREFERENCES: Knowing when a player is free, his preferred sports, competitive level, and geographical range will notify him of the best games for him being created by friends and other users.
I hope to eventually build an AI to take everyone's preferences and create perfect games for them to save everyone even more time and frustration.
Demo: https://youtu.be/6JipGzUHMJE <comment><USER2> I would be pretty reluctant to use a name that already has a strong connotation. I think most people are going to jump to thoughts of Dribbble.

<comment><AUTHOR> Have thought about this. Other names I considered included Sportify, which is undeniably worse in this respect haha

<comment><USER2> That's hilarious.

</comment></comment></comment><comment><USER3> How big is this market? How much could you actually make from this?

<comment><AUTHOR> The biggest potential streams of revenue would be taking a cut of payments split through the app, charging local governments (parks and recs)/businesses for analyzed data, and helping indoor sports facilities gain leads, schedule bookings, and receive payments. Indoor sports facilities are a growing billion dollar business in America and they could definitely use help streamlining their processes.</comment></comment>


No place for passionate students? - <AUTHOR>

I saw a post earlier today where a guy was looking for a job in another state.  I have a much simpler request of HN. How can I become more appealing to a company?  I understand OO concepts, TDD, and have been taught C#, C++, CB.NET, Java, XHTML, CSS, in class, and outside of class I've used C#, Java, JSP, Servlets, and Hibernate on my own for self-study and trivial software contracts.  I'm approaching the end of my degree though and I've been applying at places but I get similar responses everywhere.
Nearly all of the positions I'm applying for are entry level, with some of them outright stating "No Experience Required!".  Yet I'm getting passed over despite being told that my drive is great, or that the code samples I submit are good, or that I seem qualified. Often they'll suggest an internship with them at a later time, but all are turning me away for what reason I cannot divine.  It's very discouraging when I note how I have a (much) higher proficiency and love for the craft than others in any of my classes and often end up tutoring them.  Some of them are so incapable in fact that it ASSURES me that I'll have a job.
Advice? (I'd really love to be a web application developer, JSP, ASP, or Python I don't care, although I do enjoy Java) <comment><AUTHOR> My apologies, I also understand and utilize the importance of regular builds, prototyping (and being willing to throw away prototypes/codes based on analysis of work needed to reuse it), I push myself to learn the toolchain for everything I know so that I can write in Notepad++ and use G++/Make and work my way up into an IDE, and I love learning new technologies. I also use versioning software (mercurial right now), and am familiar with design patterns such as the facade, builder and others.

<comment><AUTHOR> I'm applying at out of state and area places right now, in the meantime which development stack do you think it'd be easier for a student to get into a decent position with?

</comment></comment><comment><USER2> Try to learn one of the hot techs(JavaScript, Ruby) and write a small app in one of those. I've noticed that despite having serious knowledge of Java, C#, C++, my JavaScript skills are what people go after.

Secondly, what do you have to show for your skills? Github? Profile? Blog?

</comment><comment><USER3> search for user groups in your area on the tech you are interested in/good at and go to them. it's a good way to make contacts. and be open about that fact that you are looking for a job. you will probably have more luck finding something through a contact than through an ad.

</comment><comment><USER4> Are you limiting your job search to specific locales? Are you applying at top companies only?

<comment><AUTHOR> I'm applying where ever there are openings, and the only restriction is that it's in the Saint Louis area. I live in Fenton, MO.

<comment><USER4> Location often determines how quickly you can expect to find a job. I don't know what the St. Louis job market is like, though, but probably not fantastic? You can consider determining whether the bug is with St. Louis or with some (improvable) aspect of your employability.

<comment><AUTHOR> Would you suggest testing this theory by just applying at extended locations?

<comment><USER5> Why not? Seems like a natural step. If you get an offer and your wife still won't budge, at least you know you're employable and that it could very well be a geographic issue.

You could also check hiring freelancers or remote work ok jobs.

<comment><AUTHOR> I would be ok with both of those but I was hoping to rely a little on the development culture of the work area to help me get settled into how professional development works.

If I take a freelance job, they'll likely expect me to do frontend work or GUI work which in all honesty I am terrible with.</comment></comment></comment></comment></comment></comment>


User level threads – with threads - <AUTHOR> https://www.youtube.com/watch?v=KXuZi9aeGTw

<comment><AUTHOR> Summary for those who want a quick abstract before deciding to watch a 34-minute video:

This describes work being done by Google on the Linux Kernel scheduler that adds a couple new syscalls that, when taken together, allow cooperative multithreading of kernel threads from user-space. Basically, they let user- mode libraries bypass the kernel scheduler and explicitly yield to another thread or process.

This work is important because:

It brings Erlang-style processes or Go-style goroutines to C/C++, and by extension, any scripting language built on the UNIX/C infrastructure. Instead of needing your whole language to be aware of concurrency, you can use the standard C stack for concurrent processes, and switch between them in user- space _without_ the full overhead of a context switch. Moreover, this cooperative scheduling is aware of kernel-level blocking, so you don't need to worry about a wayward blocking call wedging the whole machine.

It lets interpreters with a GIL - notably Python and V8 - use process-based concurrency while still enjoying the efficiency of event-based concurrency models.

It enables fast RPCs between same-server processes, even when the processes are written in different languages. Combined with a serialization format like Cap'n Proto, where all languages share the same memory layout, you can get zero-copy IPC between languages with a cost not much more than a standard method call.

It introduces some of the ideas of exokernels - namely, that the kernel's job is just to securely multiplex the hardware, and policy decisions should be made in user-space - to the modern Linux kernel.</comment>