AMD Demos 7nm Vega GPU - <AUTHOR> https://www.anandtech.com/show/12910/amd-demos-7nm-vega-radeon-instinct-shipping-2018 <comment><USER2> If they get TensorFlow/Torch/MXNet running with no changes in the code, 32GB HBM2 for training models would be awesome! These days hitting memory limitations is biting more than general slowness of GPUs during Deep Learning training.

<comment><USER3> Hm? not close enough?

[https://github.com/ROCmSoftwarePlatform/tensorflow](https://github.com/ROCmSoftwarePlatform/tensorflow)

[https://github.com/ROCmSoftwarePlatform/cutorch_hip](https://github.com/ROCmSoftwarePlatform/cutorch_hip)

[https://github.com/ROCmSoftwarePlatform/mxnet](https://github.com/ROCmSoftwarePlatform/mxnet)

[https://github.com/ROCmSoftwarePlatform/hipCaffe](https://github.com/ROCmSoftwarePlatform/hipCaffe)

<comment><USER4> The problem is that it's TF 1.3. TF is up to v1.8, and if you want to use any recent model you really need 1.4+.

And even ignoring that, you still can't use PyTorch.

<comment><USER3> [https://github.com/ROCmSoftwarePlatform/tensorflow- upstream](https://github.com/ROCmSoftwarePlatform/tensorflow-upstream) is 1.8

<comment><USER4> Oh nice! What state is it in?

</comment></comment></comment></comment></comment><comment><USER5> I wonder if this will get the Crypto-mining people interested too? I am really looking forward to them having more specific hardware to waste their money on, so we can return to buying GPU's for gaming at a sensible price!

<comment><USER6> >> I am really looking forward to them having more specific hardware to waste their money on

That's not how it works. You won't make GPUs that suck up all the demand while you get good gaming GPUs. If it can process stuff fast - either in computation or in memory speeds - then cryptominers want it, and so do you. The card you wish to exist simply doesn't, and if the cards are good, then they are profitable, which means they buy more of everything.

Most intelligent GPU miners have a diversified farm of Nvidia and AMD cards in some proportion to cover the specific algos that are good on each platform.

Wouldn't hold your breath.

<comment><USER7> If anything, more money to chip makers means more incentive to build better chips. Gaming will benefit from these advances.

</comment></comment></comment><comment><USER8> Is anyone doing machine learning on AMD hardware right now? What's the preferred pipeline to go from Tensorflow to GPU?

<comment><USER9> AMD is scrambling to build a CUDA-esque thing called ROCm and get various frameworks including TF ported over, but it's not even in "early adopter" state yet, so i doubt anyone is using it. However they seem to be making progress.

<comment><USER10> It's not that far away. PyTorch merged a build script semi-recently, though I don't know if it's fully tested or supported.

[https://github.com/pytorch/pytorch/blob/master/tools/amd_bui...](https://github.com/pytorch/pytorch/blob/master/tools/amd_build/build_pytorch_amd.py)

<comment><USER4> That "disabled_feautures.json" file indicates it will be a while before it is useful though.

</comment></comment></comment></comment><comment><AUTHOR> Here's a benchmark comparing the latest ROCm software with Vega cards from 2017 (with tensorflow 1.3). TLDR; - Vega's are nearly as good as V100s for CIFAR-10!

[http://blog.gpueater.com/en/2018/04/23/00011_tech_cifar10_be...](http://blog.gpueater.com/en/2018/04/23/00011_tech_cifar10_bench_on_tf13/)

<comment><USER11> That post doesn't specify whether the training was fine with single or half precision floating point. Given that it's on the website of an AMD GPU cloud provider, I tend to think they probably used fp32 since it will make vega look better.

</comment></comment><comment><USER5> Being pedantic but shouldn't the graphic for the 'Roadmap' say "Next-Gen <7nm" or "7nm-"?

That looks like things will begin getting bigger again in a few years?

<comment><USER12> basically 7nm+ means tweaks to the process with improved speed and power consumption, stays 7nm from [0]

""" TSMC plans to introduce a second improved process called 7nm+ a year later, which will introduce some layers processed with EUVL. This will improve yields and reduce fab cycle times. The 7nm+ process will deliver improved power consumption and between 15-20% area scaling over their first generation 7nm process. """

[0] [https://en.wikichip.org/wiki/7_nm_lithography_process](https://en.wikichip.org/wiki/7_nm_lithography_process)

update: link

<comment><USER13> Where do wikichip get their info? Is it rumours since I don't see any sources listed?That's not what I heard about 7nm+.

</comment></comment></comment><comment><USER14> So, are gaming 7nm GPUs from AMD coming this year or next?

<comment><USER15> Odds are we will see overclocked 14nm Vegas with an X suffix before Christmas this year, and 7nm Vegas next year.</comment></comment>


Ask HN: Hosted CRM software for small businesses? - <AUTHOR>

I'm looking for a way to track my customer relationships -- not especially sales funnel. But you know, a place to track people I need to follow up with after I screwed up, touch base with super fans, etc. I would also love a link to some guidelines of best practices for this sort of thing - perhaps a book? <comment><USER2> From "Mreza" a Croatian IT magazine ( <http://www.bug.hr/mreza/travanj-2010/94275.aspx> ), translated and paraphrased:

The seven wisdoms of a successful CRM implementation:

1\. Solve specific business needs, don't just "implement CRM"

2\. Focus on small wins on the road to the big victory

3\. Understand the culture and motivation of the individuals and fit them in the design

4\. If you're ordering the CRM solution, don't specify the way it should be implemented, specify the desired business effect

5\. Don't be scared to make changes, even big ones, in the flow and way the solution is implemented

6\. Optimize the look & feel of the client's UI

7\. Establish processes for managing data

</comment><comment><USER3> Here is a link to an Open source ERP framework. <http://tntconcept.sourceforge.net/en/index.html>. Disclaimer: Haven't used it.

</comment><comment><USER4> intelecrm is a good tool to track your customer relationships, it is a web based CRM solution built by Intelestream. To learn more on how to select the right software for your company visit [http://www.intelestream.net/en/lp-10-considerations- before-p...](http://www.intelestream.net/en/lp-10-considerations-before- purchasing-a-CRM.html)

</comment><comment><AUTHOR> highrise is definitely one. I'll give it a whirl.

<comment><USER5> I second Highrise. Way better than the CRMs I've used in the corporate world, and cheaper too.</comment></comment>


Compile-Time DI vs. Run-Time DI - <AUTHOR> https://dimes.github.io/blog/compile-time-di-vs-run-time-di <comment><USER2> I don't understand why you need a framework for dependency injection in Go. I've written Go for years and I just use the `main` package to instantiate and wire up everything. It's really straightforward, easy to debug, and there's nothing to generate. It's all type checked at compile time.

I'm not trying to rain on the author's parade. I genuinely don't understand the benefit—especially in relation to the complexity of adding an extra dependency and layer to my application.

<comment><USER3> How many active contributors and lines of code does your projects have?

I've found that the advantages for DI frameworks (besides encouraging more unit tests and enabling them) to be more valuable for bigger and messier projects.

<comment><USER4> I find precisely the opposite, that as a project gains (and loses, and gains again) maintainers, the indirection and mental overhead that DI frameworks necessarily bring to the table vastly outweigh whatever perceived benefit there was in introducing them.

Conversely, a declarative, step-wise func main, with components manually constructed and passed to each other as dependencies where necessary, is sometimes tedious, but never confusing, and always refreshingly easy to maintain, no matter how much time you've spent with the project.

<comment><USER5> I've literally no idea what the second paragraph means but I suspect it's quite important. Could you point to an example of this being done? Thanks.

<comment><USER6> This sounds like the main methods i write (in Java, also not using a DI framework). Like this:

      var database = new DatabaseFacade(config.get("db.host"), config.get("db.port", Integer::parseInt));
      var users = new UserRepository(database);
      var catalogue = new ProductRepository(database);
      var cart = new ShoppingCartController(users, catalogue);

It's imperative code, of course, but it's sort of declarative in that all the code is doing is wiring things up. It's step-wise in that it does one simple thing after another; it might be quite long, as there are a lot of components to create, but it can be understood locally. Components are manually constructed, by calling constructors, rather than via reflection done by the framework. Components are passed to each other as parameters to establish dependencies, rather than there being some sort of rule-driven lookup, as a framework would do. It is indeed pretty tedious to read, as it's just lots of constructor calls, with no thrilling action. But it's so simple it's never confusing (and you get to use the full power of the IDE to navigate it, jumping to definitions and uses etc). And, as such, easy to maintain. Definitely refreshingly so if you've come from Spring or Guice.

<comment><USER7> Would you consider this viable in a monolith, though?

The primary application I work on has hundreds of classes that get dependencies injected through DI. Many can be and are singletons, but many - including some very commonly used ones - cannot.

If I manually wired dependencies it would add thousands of lines of code, and there are some where if I changed the constructor parameters I would have to modify 1000+ call sites.

And this isn't even a particularly massive or complex application.

<comment><USER6> The largest application where we use this pattern has 131737 lines of code (according to cloc), and four 'main' classes which do dependency injection, which create roughly 155, 145, 111, and 95 components. Those files total 8949 lines of code. They're doing more than just injection, though, there's quite a bit of code for other kinds of setup and configuration.

Remember that this setup code is just code, so if you find that adding a constructor parameter means modifying a thousand call sites, you should probably refactor it a bit first, so that it doesn't.

That being said, this approach to DI does take some tedious manual work to maintain. But by paying that cost, you get to take a magical DI framework out of the picture entirely.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> What this blog post does not address is the joy of configuring DI with XML files /s

Isn't it bizarre how software developers have taken runtime DI to such extremes that it was considered a good idea to configure services in XML or YAML -- basically another language, that has to be parsed, can be malformed, etc?

<comment><USER9> The creators of Guice mention how configuring the dependency graph in Java was a big advantage it offers over older XML-based frameworks like Spring.

<comment><USER10> Spring has allowed for java configuration for some time.

</comment></comment></comment><comment><USER11> Your point of breaking things as early in the process really is the winner.

Catching things early and often. Tooling that shifts things further left in the pipeline is my go-to default.

<comment><USER12> Do you think it is rust that popularized this?

<comment><USER13> Why Rust? Strongly typed languages had this capability for a long time.

<comment><USER14> I believe what he means is that Rust takes this a step further by ensuring memory safety at compile time.

<comment><USER15> Rust is merely the latest in a long line of efforts in that direction. It may have located a particularly nice point in the cost/benefits space, and the borrow semantics I believe are novel, but it's well inline with many efforts to make compile time errors out of as many things as possible, from a lot of C++ stuff, Ada, Eiffel, Haskell, a variety of proof methods, the list goes on, and even the things I list are themselves exemplars of entire streams of thought on the idea rather than a complete list, of course.

(This is not a criticism of Rust. It is not a criticism of a work to place it correctly in its historical context. Very few things consist entirely of novel ideas, and very few of those are any good, if any.)

<comment><USER13> Agreed. Rust is another step in the right direction but I don't think it invented a new paradigm.

</comment></comment></comment></comment></comment></comment><comment><USER16> DI is Dependency Injection.

</comment><comment><USER17> Java has a fairly nice compile time DI framework in Dagger. However, it feels like it is missing a compile time version of the rest of the web stack: compile time routing and compile time template compilation, for example. Does anyone have any suggestions to fill out this stack?

<comment><USER18> It's not perfect by any means, but there is Ktor as an example. Use kotlinx.html for your templates and everything is defined at compile time.</comment></comment>


Investigating the overhead cost of compiled ES2015 - <AUTHOR> https://github.com/samccone/The-cost-of-transpiling-es2015-in-2016 <comment><USER2> Rollup isn't linked anywhere in this article and I had only dimly heard of it, so here's a link: [http://rollupjs.org/](http://rollupjs.org/)

I guess it wouldn't be JavaScript without at least three choices, one of them still in its infancy but with features the others don't have, just to make those crucial decisions that little bit juicier.

<comment><USER3> Here's a good comparison table I found (not sure how up to date it is): [https://webpack.github.io/docs/comparison.html](https://webpack.github.io/docs/comparison.html)

</comment></comment><comment><USER4> I had no idea the Closure Compiler supported ES6 until I read this, but then again, it only arrived last May. Here's some more information about it: [https://github.com/google/closure- compiler/wiki/ECMAScript6](https://github.com/google/closure- compiler/wiki/ECMAScript6)

<comment><USER5> Me neither! Personally, I would either just use uglify for its speed, or use Closure Compiler since it does much more than just minimizing the source code, to me, Closure forms its own kind of JS compilers.

Due to the ES6 drama, I have to live with Babel for now which I really don't like, now I will have to reconsider this whole stack, shame on me that I missed it last May.

</comment></comment><comment><USER6> I was just going to comment that it would be interesting to see the size of a run-through with browserify+uglifyify+uglify but looks like there is already a PR for it.

[https://github.com/samccone/The-cost-of-transpiling- es2015-i...](https://github.com/samccone/The-cost-of-transpiling- es2015-in-2016/pull/12)

<comment><USER3> I'm new to the whole webpack / browserify / etc. stuff, but this seems like a supremely weird build pipeline to me.

> When using uglifyify you should generally also use Uglify, to achieve the > smallest output. Uglifyify provides an additional optimization when used > with Uglify, but does not provide all of the optimization that using Uglify > on its own does, so it's not a replacement.

Why doesn't Uglify just do all the work and not require a separate component to do extra optimisation? Or is the extra optimisation specifically tailored to browserify?

<comment><USER7> The current state of javascript is to employ 40 tools for build process and 2000 modules to build your product.

</comment></comment></comment><comment><USER8> The graph there is very misleading because it doesn't use 0 as a baseline. The browserify bundle is only 20% larger than the webpack, but the graph makes it look 5x or so.

</comment><comment><USER9> Hi, member of the TypeScript team here. A big reason for the file size increase seems to be the inclusion of an AMD module loader and AMD prologues themselves.

By targeting CommonJS and using Browserify, you see a nice decrease. I've sent out a pull request since finding this.

[https://github.com/samccone/The-cost-of-transpiling- es2015-i...](https://github.com/samccone/The-cost-of-transpiling- es2015-in-2016/pull/18)

<comment><USER3> I think this puts the TypeScript build 3rd smallest GZIP behind Webpack/Babel/Uglify and Closure.

Knowing barely anything about Typescript, does this include TS's ES6 features in the same way as the Babel build?

</comment></comment><comment><USER10> The Closure example failed to pass the compiler flags to minify the code, so the numbers are wrong. At a first glance, the Closure output is about half the size of the numbers published there.

[https://github.com/samccone/The-cost-of-transpiling- es2015-i...](https://github.com/samccone/The-cost-of-transpiling- es2015-in-2016/issues/22)

</comment><comment><USER11> Modules on the browser also benefit from being scoped appropriately by having a function wrapper. How does "topological sorting of dependencies (ordering the dependencies so that you do not have to worry about import wrapping code)" address that?</comment>


Ask HN: Should I pull the plug on my side project? - <AUTHOR>

Built holding page and mailing list. Posted to BetaList and received positive response. Collected 100s of emails. Some influential industry people mentioned it on social media.
Built an MVP. Posted about it on all of the industry sites (Hacker News, Product Hunt, etc.) and social media. Received very little response. Managed to convert single digit paying customers. Zero success from cold emailing.
Six months later and essentially no growth. Operating slightly below break even. Some very laborious but fairly successful marketing campaigns (100s to 1000s of daily visitors) did not result in the conversions I hoped for.
On one hand, it's possible the product is good and I suck at marketing and should continue learning and grinding. On the other hand, it's possible nobody wants the product and I should work on something else. Is it time to classify this project as a failure and move on? <comment><USER2> In general Marketing is a series of experiments to find what works and doesn't work. So marketing is always about learning and failing quickly to find the successful campaigns and channels.

As for your specific circumstances, it doesn't sound like your marketing outright blows as you are getting traffic, so I'd look more to one of the following:

1\. You don't have a good product market fit. Your product value proposition might even be spot on, but the product itself may fail to fulfill the need.

2\. You are marketing to the wrong group of people, so while you get traffic your conversions are horrid. I have seen this when people are using terms or a value proposition that a broad group cares about but only a small sub-group actually purchases or controls the funds.

Have you followed up with visitors and figured out why they aren't converting? Have you done trails to get feedback? Have you done 1 or more surveys to get feedback? Have you talked to people, called them? Offered them something small in return for honest feedback? Have you gone and sat with a potential client and walked them through the product to get feedback? etc

Not sure what your goals are, but I think you have to earn the right to quit so you can learn from the situation. If you haven't found out why it is failing then you haven't earned that right, as you haven't learned what not to do the next time.

</comment><comment><USER3> When to pull the plug is feels the hardest thing to figure out.

My feeling from the story is that you almost have the product the people want to buy – or your marketing wouldn't of worked as well as it did. You're just a little bit off of product market fit.

But you also sound a bit worn down and tired which is not a good place for a side project.

So that sounds like a hard place to be.

I can't really offer advice – but I will tell you that the thing that has paid my (and several other peoples) wage for the last decade spent the first year completely in the red sucking cash and paying zero while I worked full-time on it and my partner did it as a side gig. Completely self funded. Sometimes it takes quite a while to find your fit as a company.

But sometimes it's never going to happen and pulling the plug on doomed projects is the only way to get to the project that's actually going to work.

</comment><comment><USER4> What's the project? It's tough to guess whether it's worth putting more effort into without knowing anything about the project itself.

My gut feeling is that if it's been this hard to make even a tiny spark with the traction you've gotten so far, it might be smart to look for an easier hill to climb. I think the question to ask is, have enough people who would be ideal customers seen the product and understood how it could help them? If not, how could you get it in front of enough of those people to gauge whether there's some intrinsic attraction in your offering?

</comment><comment><USER5> > it's possible the product is good and I suck at marketing

You probably suck at marketing this product, but that's ok. No one is "good" at marketing something on the first try -- they're good at using trial-and- error and user data to improve their marketing. You weren't going to nail it on the first try, and neither would a veteran marketer.

You're going to need time and money before you can be sure that this has failed. You could try raising money, but investors will generally look for 1) a great team or 2) great access to a (niche) market.

"Slightly below break even" sounds like it might be worth continuing for a while. Use things like Lucky Orange to see how users are behaving and try to tweak your marketing.

Do you mind describing your product for us a little bit?</comment>


Scientifically Proven Places to Get Stuff Done - <AUTHOR> http://blog.scribblepost.com/scientifically-proven-places-to-get-stuff-done/ <comment><USER2> It's worth noting nowhere in this article does it say __the office __is a good place to accomplish anything.

<comment><AUTHOR> Well spotted :)</comment></comment>


Mono 3.6.0 is out - <AUTHOR> http://www.mono-project.com/Release_Notes_Mono_3.6

<comment><USER2> I really wish Mono would gain more traction. C# (3.0 onwards) is one of the nicest programming languages I have worked with (despite its warts). I also heard a lot of good things about F#.

<comment><USER3> F# is a phenomenal language. Not that C# is bad (it's fantastic!), but the more I use F# the more I feel it's a superior language for most tasks. First- class .NET support is the real kicker, since you can do anything from DB interaction to writing MVC controllers. Integration with existing C# projects is seamless too, so it's really just a joy to work with.

<comment><USER4> I disagree; C# is bad by comparison. I cannot think of a single reason to use C# over F#, can you? F# is essentially C# but with better defaults and much more easily extensible.

<comment><USER5> I trialed F# a while back. Something I certainly noticed was not having as much help from the IDE (no resharper). The lambda notation also annoyed me (by comparison to C#). Yeah, I know it's no big deal and I understand the trade- offs being made.. but it still annoyed me. Pattern matching is one of the draw cards - but I see that is coming in C# soon.

<comment><USER3> Did you give F# Power Tools a go? It gives you a lot of what is missing out of the box. It's still not as great as C# IDE support, but for most things it gets the job done.

</comment></comment></comment></comment></comment><comment><USER6> FYI, the current Mono website is pretty outdated right now and will soon be replaced by a new one built on Jekyll: check [http://mono.github.io/website/](http://mono.github.io/website/) for a preview.

<comment><USER7> Why mono website built on Jekyll instead of .net with mono itself?

<comment><USER8> I don't think there is anything dynamic happening on Mono website. Why use backend when there is no need in it?

</comment></comment></comment><comment><USER8> So the real important question is: Does it finally support MVC5?

<comment><USER6> Yes, it works: [https://twitter.com/mjhutchinson/status/479063888575881216](https://twitter.com/mjhutchinson/status/479063888575881216)

Anything complex may still hit some issues, though this might not matter much in the future as ASP.NET vNext will fully support Mono.

<comment><USER9> Unfortunately Web API 2 doesn't seem to work on it.

</comment></comment></comment><comment><USER10> _Our msbuild implementation can now build Project K and Roslyn_

Wow. Really impressive -- our MSBuild hackery is gut-wrenching.

</comment><comment><USER11> This is cool!

I got pretty far into building an MVC project that I have been working on for a long while in Windows.

I had to manually run the NuGet package restore command, as I couldn't see a way to enable package restore for the project. I set EnableNuGetPackageRestore=true preceding the command and it installed all the packages successfully.

I have run into a roadblock with a MSBuild TypeScript target however. The error message wasn't very telling but I'm assuming it's because it can't find the TypeScript compiler.

</comment><comment><USER12> Interesting, how about performances of mono? The thing that attracts me to it is F#, however as others stated I'm out of windows development since 98.

<comment><USER13> Mono performs "fine". That is, I've never really isolated Mono as the cause of performance issues. I'm running it in telecom applications, handling billions of transactions a week. Years ago I compared things, and the CLR was usually better. But generally speaking, the approach in algorithms/approaches is going to dominate the runtime.

The exception is when you're dealing with a very high transaction rate (say, doing 100K msg/sec, non-trivial processing per message, in a single process). Then the GC overhead is something to be aware of, and you'll go to extreme lengths just to remove a handful of allocations for each message. At that point, manual memory management (either via hacking up the runtime with unsafe code, allocating large arrays of structs, or using unmanaged code) is the right path. But from light reading, it seems the same is true in Java or other GC languages, so no difference for Mono there.

So the alternative is C, usually, which has its own set of tradeoffs. Rust looks far more promising, but in general, Mono's performance is just good enough that I'm more likely to keep my nice F# code and add a few boxes. Unless you're in a high-performance arena, and you'd know if you are, this likely holds true for your business.

Edit: Also, I'll note we're using Mono 2.10. So updating to 3 should get us the new GC which may make a difference, as well as allow LLVM code, which should help significantly for server apps.

<comment><USER14> Interesting information. Can you share a little more about your platform? Distro? Are you doing basic tcp/ip or pushing to/from some kind of dedicated hw?

<comment><USER13> CentOS and Windows, Xeon 5400 series CPUs - cheap used Dells. OpenSIPS, FreeSWITCH, RabbitMQ, SQL Server, VoltDB, and a custom DB. We have a few hundred million routes loaded at any given time and run up to 50,000 calls/sec. SQL Server is going to get phased out in favour of Postgres, due to SQL Server's increasing licensing costs. ElasticSearch also looks like it might be a good candidate for crunching up a bunch of records.

All critical code is F# on Mono and CLR. Each voice-handling machine makes an HTTP request to a CLR process to get routing instructions, then the results of the call are handed off to a Mono process, which protobufs stuff into a local RabbitMQ instance, which gets shoveled into billing, analysis, etc.

Lots of "XML", as that's FreeSWITCH's preferred format (it's not real XML, but a psuedo-XML with inane encoding rules, for some reason). This is the cause of at least 20% CPU time when handling call records.

In general, scaling out by adding a few more machines to the mix is so easy we're not really pressed hard to make things go faster. But it's certainly fun to do. I'd guess we can improve many pieces up over 100% without doing anything really tricky.

As a comparison, I know of at least one successful competitor that has everything in PHP. Every call creates multiple processes and multiple (10+ sometimes) DB queries. Their entire scale-out process is to throw hardware at things. At one point they had over 100(!) servers just to hold call records (maybe 100M a month?). Inefficient? Hilariously so. Did the primary owners get rich from it? Absolutely. Engineering quality counts for surprisingly little, when it really comes down to it.

</comment></comment></comment></comment><comment><USER15> Here it is a good business for the "new" "21 century" Microsoft.

To put their language into Mobile, OSX and Linux.

<comment><USER8> If they do succeed I seriously think it could be the end of Java.

<comment><USER16> Java has a massive foothold in the business community, especially in finance. I don't think Java is going away anytime soon.

<comment><USER17> Yes, Java is basically new COBOL. Ugly yet to stay in a lot of places for a while.

<comment><USER18> You should realize that Java (JVM and libraries) is completely open source (GPL). Oracle JDK is just another build of OpenJDK. This means the ecosystem is not tied to a vendor: if you build your systems on Java, you are your own master.

</comment></comment></comment></comment></comment><comment><USER19> Still... try to install any version higher than 2.10 on your linux distro and be ready for some suffering...

<comment><USER20> If that's the case it might be worth considering an Arch Linux install.

<comment><USER20> To the downvoters, what's wrong with suggesting someone use a Linux distribution that's generally quite quick to package new versions of software, as a solution to their stated problem of their Linux distribution(s) making it difficult for them to install recent versions of said software?

It's quite possible to have a new Linux distribution up and running on VirtualBox in under an hour, or in a chroot under an existing Linux installation.

<comment><USER21> I'm going through some pain with some Ubuntu based distros and packaged software. Really missing Arch with its rolling releases!

</comment></comment></comment></comment><comment><USER22> Any time I wanted to use mono it didn't work. It wasn't many times though. A couple of times to try a FPS game and also for some sites based on Silverlight. I'm wondering if it is usable now or what's the common use case for it for which it works fine.

<comment><USER23> If you want to run Windows .NET applications, in particular GUI applications you may have problems. But I have been using Mono for developing new software (libraries) for a decade and it works nicely. I often don't need a GUI and if I do, I just do that part on Windows later.

<comment><USER24> Do you use an IDE when developing on mono or just a text editor? If you do use an IDE what's it like?

</comment></comment></comment><comment><USER25> It looks like only the installer for OSX is up to date.

Is Ubuntu supported? Where do Linux users other than OpenSUSE users get packages? Do they build it themselves?

<comment><USER6> Packages for the major Linux distributions are being worked on, see [http://lists.ximian.com/pipermail/mono-devel- list/2014-June/...](http://lists.ximian.com/pipermail/mono-devel- list/2014-June/041658.html)

One of the early outcomes of this are CI packages built for each commit: [http://www.mono-project.com/DistroPackages/Jenkins](http://www.mono- project.com/DistroPackages/Jenkins)

<comment><USER25> Thanks for providing those links. I'm really excited to see Xamarin hiring a developer for Linux support issues.

</comment></comment></comment><comment><USER26> AND THE CROWD GOES....

"Yawn... what is out? Oh yeah, I think I heard of that..."

</comment><comment><USER27> It's sad to see VB.net being treated as a second class citizen on this platform and ironic to see little GAMBAS be a better option for BASIC programming on Linux, given the resources.

<comment><USER28> Why is this "sad"? VB.NET offers little (anything?) over C#. I've never seen a bit of VB.NET you couldn't transpile into perfectly readable C# outside of _really gross and bad_ implicit type conversions around Booleans.

If Xamarin should care about VB.NET, it should be better at things than C# is.

<comment><USER29> It offers the ability to run VB.NET codebases. Transpiling them into C# offers cost with little benefit (for stable code that is rarely updated), while running it on Mono allows for hosting infrastructure upgrades.

But if anyone cared, they would do it. No one cares, so it does not get done.

<comment><USER28> Right, so what's sad about that?

Use majority tools or deal.</comment></comment></comment></comment>


Squash the Bug, Then Close the Window - <AUTHOR> http://blogs.xobni.com/asmith/archives/62

<comment><USER2> Right now blogs.xobni.com is giving me the output from phpinfo()...

<comment><AUTHOR> We were moving servers. Sorry, should be working now.

</comment></comment><comment><USER3> Commenting out the exception throwing code would likely lead to even more difficult-to-understand bugs (something after the now-commented-out throw would probably fail, possibly corrupting data). It's better to fail early.

<comment><AUTHOR> Totally a joke -- sorry for confusion!

<comment><USER4> Uh huh. I'll just revert that last commit of yours, and we won't tell anyone.

... whoops, wrong window!

</comment></comment></comment><comment><USER5> I can't quite put into words how much I love your bug cost/time to find graph.</comment>


A survey of testing techniques we've found useful - <AUTHOR> https://vector.dev/blog/how-we-test-vector/ <comment><USER2> One thing that is rarely discussed (I think?) is how to test things which don't have a correct answer. It's not just "refactor until you can test" it's output that may be subjective. For example, suppose you write some code to do some image processing like a stereo matcher. How do you check your code works? Usually you have some ground truth which you can compare, but it's difficult because you'll never get 100% accuracy. At best you can declare a baseline, eg that your algo should be say 90% accurate (if you implemented it properly based on literature results) and if you don't get that, then error. In that case you can use a numerical metric, but other applications you might care about the result being aesthetically pleasing (eg a video ISP where you do colour correction on the stream coming from a low level camera).

Or hardware where the advice is usually to mock the device under test. But if you don't own the hardware the most you can do is try and emulate it, and maybe check that your simulated state machine works. In my experience its easier to run with hardware connected and just skip those tests otherwise. There are also extremely subtle bugs that can crop up with hardware interfaces like needing to insert delays into code (eg when sending serial) that will otherwise fail in the real world.

OpenCV has some interesting approaches to this, for example testing storing a video in a certain format, inserting a frame with a known shape (like a circle), then reading back the video and checking that the shape can be detected.

<comment><USER3> Testing with hardware is hard. You can emulate to some degree but that just helps making sure your tests are written correctly. In the end you have to run tests against the real thing. I deal with complex UIs that interact with hardware. If you are smart you can split things up so they are easier to test in isolation but the whole system has a ton of potential interactions that are hard to write test cases for.

The OpenCV example is a pretty easy one. You have clear inputs with clearly defined outputs. The only thing you have to do is to create sample data.

<comment><USER4> > Testing with hardware is hard.

Yup. I work in robotics.

I try to isolate the actual hardware interaction layer so that for testing you can mock the driver and hardware in one piece. Of course that does not test the driver. With any luck, the driver is pretty stable once it works, though. And the driver+hardware piece can have it's own (physical) test bench so that at least manual testing is, well maybe not efficient, but at least not painful.

Simulators are great but not always available. Or are too much work to get going.

One configuration often used for robots is the "boneless chicken". Take a bench, and bolt all the guts down to it in a configuration where they are easy to probe. Put the wheel motors someplace safe, with a synthetic load like a pony brake. Of course you can't test the nav stack that way. (I once interviewed a firmware engineer who was coming off of the Juicero shutdown -- say what you want about Juicero, but from the sounds of it their boneless chicken was outstanding, even integrated into the CI automation pipeline. Of course, they didn't have the nav problem).

Speaking of nav, I once saw a warehouse robot company's nav PR test micro- warehouse. Not the full test warehouse, just a 500 square foot or so area dedicated to testing nav PR's. It was integrated with CI automation. I could tell from the accumulated tire marks on the floor that they had nav pretty much nailed.

I have done several robot-to-elevator interfaces (probably more than anyone else). In the end, final testing always required something akin to a few midnight to 4 AM test blocks on the real elevator. And then of course as you point out:

> the whole system has a ton of potential interactions that are hard to write > test cases for.

They often don't show up until the system is under load.

<comment><USER5> Nice write up. Just wanted to add that the problem of using simulators or mock is that now you have one extra code base to maintain totalling: the code, the test, and the mock. For mock drivers this can be a quite big task. In the end I just preferred to run it in real hardware as much as possible and go for unit tests. This from a person that generally does not like unit tests, but there is not a very cheap way of going with simulations sometimes.

</comment></comment></comment></comment><comment><USER6> I think this is a fairly good summary of the most important testing styles and where / when to (not) use them.

One more category of tests I would add are meta tests (like mutation tests). These are tests which test the tests, seeing if they would actually catch any errors / bugs or just report everything to be alright always.

</comment><comment><USER7> "If something is difficult to unit test, refactor until it's easy."

This is often a good idea but if you only need the flexibility to enable unit testing then it may make your system more complex than it needs to be. Only introduce indirection where it's really needed. See also "test induced design damage" and "write tests, not too many, mostly integration".

<comment><USER8> Only if you want to minimize the total complexity, which is almost never a good idea. What is more important, is the minimum amount of complexity needed to be understood in order to make a change. If you are able to test a small subset of components in isolation, you can also understand them in isolation, and modify them without the need to understand the whole system. I'd rather read 20% of 110% code than 100% of 100%.

The advice to write mostly integration tests is a terrible one. Particularly when they test integrating of everything. When such tests catch bugs, they don't tell where the problem happened. They also take long time to execute.

<comment><USER9> The problem I have been exposed to is unit tests that have locked in what should be just an implementation detail. Can be fine, if it is an important detail. That said, your tests should not have to import all of the same pieces that your coffee does. I prefer, actually, to use alternatives in the tests, where possible.

For example, if you're code zips something, your test could use many zip engines to verify.

</comment></comment></comment><comment><USER10> When writing code, we often think "according to the design of our system, this condition must be true at this point of execution." Examples are:

1\. The argument x must not be 0.

2\. The variable x must smaller than the variable y.

3\. The list foo must be non-empty.

4\. The variable x should have value 'Success' if it had value 'Try' in the beginning of the function call.

These 'invariants', or assertions, can be extremely useful for testing the correctness of the code. Put simply, if an invariant is violated (during unit test, integration tests, or system tests), it indicates that either the design or the implementation is wrong. An article on testing methodology would be more appealing if it had some discussion on exploiting invariants/assertions.

<comment><USER11> I believe "Design by Contract"[0], or "DbC", is the concept you are describing. In the Wiki page Notes and External Links sections there are some good resources IMHO.

0 - [https://en.wikipedia.org/wiki/Design_by_contract](https://en.wikipedia.org/wiki/Design_by_contract)

<comment><USER10> Yes, closely related, but invariants can appear anywhere in the code (like loop invariants), and are less restrictive than pre-conditions and post- conditions which must appear in the beginning and end of methods. So, invariants are more about testing than design.

Arguably, invariants are especially powerful in testing distributed systems:

0 - [https://www.datamonad.com/post/2020-02-19-testing- mr3/](https://www.datamonad.com/post/2020-02-19-testing-mr3/)

</comment></comment></comment><comment><USER12> Very nice overview. I very much agree that all these techniques are very useful. But one thing still bothers me. How does one test with a notion of time? How do you test a cron or a calendar with alarm function?

<comment><USER5> Yeah, those are the hard ones. Worse, time is the essence of a good amount of issues from performance, to startup stabilization to the deadliest of all errors: the race condition.

</comment></comment><comment><USER13> I'm a complete newbie when it comes to writing tests. But I know that SQLite is tested to hell and back, and I believe Richard Hipp (the creator) has said he spends more time and lines of code on the testing suite, than on the SQLite code itself. I hope he shares some of his insights some day.

<comment><USER14> > I hope he shares some of his insights some day.

You didn't search much: [https://sqlite.org/testing.html](https://sqlite.org/testing.html)

<comment><USER15> I love this page! We (Vector) hope to post something similar in the future.</comment></comment></comment>


Harder to predict: economic change, or weather? - <AUTHOR> http://www.economist.com/blogs/freeexchange/2009/09/harder_to_predict_economic_cha.cfm

<comment><USER2> Since the article doesn't actually address that question, I'll just point out that the weather may be intractable, but it's not incentivized to change your predictions as soon as they're made.</comment>


Show HN: A missing command line client for Codewars - <AUTHOR> https://github.com/shime/codewars

<comment><USER2> I kinda like using the browser for my Codewars challenges (or should I say katas). But this is a good work!

<comment><AUTHOR> thanks. yeah, I'm a crazy Linux guy, so I always prefer terminal.</comment></comment>


The Man Behind 'Solarized' - <AUTHOR> http://observer.com/2015/02/meet-the-man-behind-solarized-the-most-important-color-scheme-in-computer-history/

<comment><USER2> Meet Konstantin Bulenkov, the man behind the most important color scheme in a shipping product.

[http://blog.jetbrains.com/blog/2013/06/11/inside-darcula- loo...](http://blog.jetbrains.com/blog/2013/06/11/inside-darcula-look-and- feel-an-interview-with-konstantin-bulenkov/)</comment>


When Will AWS Move Up the Stack to Real Applications? - <AUTHOR> https://www.nextplatform.com/2017/02/03/will-aws-move-stack-real-applications/ <comment><USER2> As a shareholder, hopefully never. Building infrastructure and platforms has three wonderful benefits:

* Good customers, where good is defined as smart and willing to spend money. Going up the stack means dealing making sacrifices on both of those dimensions.

* Less complex products that stay relevant longer. Amazon builds legos and leaves the task of putting them together to others. The assembly can create value, but also adds complexity that becomes difficult to manage over time. S3 was launched in 2006 (!) and I'd bet will outlast high-order products like Box and Dropbox.

* Scale. Building apps means targeting smaller sets of customers. At Amazon's size, it's not clear what kind of application software would be a better use of their resources than simply continuing to solve platform problems.

<comment><USER3> i don't think i agree. i think they're moving up the chain to plug weaknesses in their model.

1\. good customers - infrastructure customers are not good customers. they are fickle and extremely price sensitive, which is tough to do on a super capital intensive business like hosting, even on amazon cloud's insanely high cost.

2\. less complex products - i don't understand how there is there anything about amazon's cloud that says "less complex" to you. have you ever used it? it is automating thousands upon thousands of things you have to do by hand, and it breaks sometimes.

3\. scale - every single application anyone has had success with is a sitting duck.

i think amazon is the real new microsoft, with all of the anti-trust implications that insinuates. google only delivers information, amazon delivers nearly everything in the physical world (including hosting, the ultimate "physical good" that nobody thinks is.).

good thing jeff bezos owns the washington post.

<comment><USER4> > they are fickle and extremely price sensitive

Not at all. Most customers couldn't care less about money.

There are numerous people who are price sensitive, the amateurs who are running a test app and complaining that digital ocean is cheaper, then move to the weirdest hoster they could find because that's only $2 a month. These are NOT AWS customers.

<comment><USER3> > _Not at all. Most customers couldn 't care less about money._

you're out of your mind.

customers at the high end care MORE about money, not less. the company spending $1 million/month on AWS is desperately looking for ways out. DESPERATELY. their entire business is being held hostage by amazon. jeff bezos has them by the balls and is squeezing harder and harder by the day. they have hired consultants to do the analysis, they have hired operations VPs to get them out, but they are failing. they are failing, and shoveling even more money to AWS every week, or their business goes dark.

they are doing this because one side of their business (doing stuff) is outpacing their intelligence on the other side (paying for infrastructure to do stuff). this is the genius of amazon. this is why they are successful. amazon can arbitrage this opportunity better than anyone else currently.

how do i know? i compete with amazon and talk to customers on a weekly basis. they are _desperate_. they woke up one day and are are now sending their entire profit margin to jeff bezos. every single CFO is thinking about it. how panicked are they?

you could cut their bill in half and they still wouldn't do it. they're scared, like a deer in the headlights. they don't know what to do. what if they make a wrong decision? ohhhhh my goddddddddd but... let's do nothing and keep our jobs. that's the reality. meanwhile, s3 can go down for half a day, and amazon doesn't even really have to acknowledge it. becuase what are the customers going to do? MOVE? LOL! you might as well ask them to build a time machine.

that is real. people live in that reality. sometimes against their will. people care about costs, and try hard, and all of those nice things, but they will soon be losers because jeff bezos is just BETTER at business than they are. jeff bezos is literally being paid by the people he is about to put out of business at the application level, and they're happy to pay him to do it. it's amazing. it truly is.

here's the problem: more people know how to click a button on console.aws.amazon.com than to migrate and operate an entire site. people simply do not have the skills. they just don't. they don't know how the internet actually works, but they're operating a business on the internet. they're dumb. amazon capitalized on that, good for them.

maybe the era where needing to actually knowing how the internet works is over. i don't know.

<comment><USER5> I agree. This is definitely the impression I've gotten from people I've talked to.

In an ideal world, how would they solve this? Is it to move back to self- hosted infrastructure? Isn't that the same problem; they're just hostage to their own employees and capex instead of Amazon?

<comment><USER4> In the real world, you sell a product that is profitable enough to cover the costs.

Do you think a company that sells t-shirt for less than the fabric cost will live long? Nope.

Do you think a company can get equivalent service to AWS for much less money? Nope.

Well, actually, yes, there is google cloud that's half the price. [https://thehftguy.com/2016/11/18/google-cloud- is-50-cheaper-...](https://thehftguy.com/2016/11/18/google-cloud- is-50-cheaper-than-aws/)

</comment></comment></comment></comment></comment></comment><comment><USER6> The amount of denial in this thread is hilarious.

Any level at which profit is made, you can assume Amazon will reach. They already have several large offerings at the application level, and there's no reason for them not to build or acquire further applications.

You didn't think that "growth potential" of theirs' was going to stay in the corner selling books, did you?

<comment><USER7> I agree. They've already done it over and over and over again with AWS. The article is casting a premise that has never been the case: AWS has always been in the real application business. Practically every expansion of AWS has involved adding real applications. Even Prime storage is a 'real application,' that sits on top of AWS, that competes in part with Dropbox and others.

All tech platforms devour the surrounding territory if they can. The last 40 years of tech history is littered with the corpses of formerly successful niche products/companies/services that were wiped out by expansive platforms.

Just go down the list of AWS services:

CDN = real application

Database products = several real applications (just ask Oracle, who is spooked by AWS)

DNS service = real application

Analytics = several real applications

Chime, Workdocs, WorkMail = real applications

Messaging = several real applications

And on it goes.

So what, they won't get into CRM? Of course they will. Amazon will use AWS to push into high margin enterprise software, specifically designed to target Oracle, Salesforce, et al. Because why not, the margins are there to be attacked. Anything that AWS gets near is a target in the next decade.

</comment></comment><comment><USER8> I think - somewhat controversially - that business/productivity apps will make or break AWS. Assuming Google Cloud and Microsoft Azure can reach AWS feature parity and prices, most everyone will likely move their infra to where their apps are.

Two (of many) reasons:

1) Biz/productivity apps are _better_ when they connect directly to your infrastructure (eg query and viz features between Google Sheets + BigQuery, etc), and

2) Infrastructure is _better_ when already integrated into your biz apps (eg Google Analytics auto push to BigQuery, etc).

More here: [https://twitter.com/pavtalk/status/822539127568658436](https://twitter.com/pavtalk/status/822539127568658436)

<comment><USER9> That integration doesn't seem that hard... the reason we don't see more of it may just be that it's not that valuable? You're never going to move all your BigQuery data to a Google Sheet. You might very well move some transformation of it, but that would be nearly as easy to do across IaaS vendors as within one...

</comment></comment><comment><USER10> I think Amazon QuickSight is probably a good example of the types of "real" applications they'll be launching more of in the future.

Services slightly further up the stack that reinforce the value of their infrastructure services. For example, I could see them launching a competitor to ESP/Marketing automation services (reinforcing AWS SES).

<comment><USER11> Quicksight fell short for us in a number of ways. We ended up using Looker with their app hosted on our AWS account. Amazon wins either way. That being said, after this and equally disappointing WorkDocs it will be a while before I look at their products as a first choice.

</comment></comment><comment><USER12> Why would they want to? Levi Strauss didn't get rich prospecting. Let Amazon sell the jeans and pick axes (both digitally and physically in their case) to the modern day prospectors.

<comment><USER13> Because that's where 10x growth might be. For every company that uses directly uses AWS, there are countless companies that don't get or need AWS directly but really need a CMS, CRM, VOIP, groupware, Helpdesk, Callcenter, etc. If anyone can build on top of Amazon's platform, it's Amazon.

<comment><USER12> Sure, just as it was for the 49ers. Your keyword there is "might". But there's a huge failure rate. It's the same statistics that VCs face. Amazon is in a place to sell premium products to nearly 100% of the market, at really low risk.

<comment><USER6> If Amazon had governed its growth by deciding just to stay at where it "is", it'd still just be an online bookseller. And you'd be asking "why should they move into digital services? They're in a unique position to sell books online with low risk."

Amazon has the potential to distupt nearly any service it wants to. The "risk" analysis and assessment is something they can handle - besides, the "riskier" applications they can just bide their time on and see how/whether they pan out for competition.

Anything Amazon can undercut by having a wider service available on its platform, is just another bag of money they'd be leaving sitting on the table. And Amazon doesn't leave money on the table.

<comment><USER12> AWS was already low risk, since they started with idle platform capacity that they needed to have for holiday shopping bursts. You're proving my point. They go for very asymmetric return profiles. Selling books online is exactly the same. Using expensive retail space to sell goods that have few good substitutes between them is a really dumb proposition. The market for books was well established, so that wasn't risky.

Don't get me wrong, it's brilliant thinking and opportunity seeking. But it is not moonshot behavior.

<comment><USER14> "Real applications" (someone named off CMS, CRM, VoIP, groupware, helpdesk, and callcenter software above) hardly seem like moonshots.

<comment><USER15> Right, it's not like Amazon doesn't have big spend on all of these things for itself.

</comment></comment></comment></comment></comment></comment></comment><comment><USER16> Everybody wants what they don't have.

I was at an AWS Summit in NYC a few years ago and got the vibe that AMZN wanted to attract an executive audience but that they got more of a technical audience. I think for the kind of companies that are in NYC, technical people are the real champions of AWS and they are in a position to decide to use new AWS services.

Business-oriented talks were easy to get into, I avoided the "big data" kinds of technical talks because the line would be too long.

The audience really didn't care when they announced Zocalo; the audience was people looking for new services like the ones AWS already offers, not for new applications or new versions of old applications.

Salesforce.com really owned the CRM system (application) and then got users to write applications for their platform, then later got into IAAS. Amazon.com has tried to go the other direction, but so far they haven't offered anything all that special.

</comment><comment><USER17> Isn't amazon.com a real application?

It seems to be working quite well for them. I'm not sure why they want to write applications for other people.

<comment><USER6> Because if one works well, why stop there?

Amazon isn't some tech startup with only a few hackers to focus on supporting their core product. They can easily maintain support for their core offerings while building out/up.

As to why: why _not?_ In this day and age, why let anyone have a slice of something you have the recources and reach to do far better and cheaper than them?

<comment><USER18> One reason: Focus.

Anybody who has tried to launch a SAAS app knows that launching the software is not enough. The sales and support infrastructure has to be there as well.

I'm not saying they can't do it. They certainly have the money to throw at the problem. The question is if they really want to.

<comment><USER11> They are practically offering support-as-a-service now. It's a clear segment of their core business they are leveraging by creating services around it. They are giving it the same focus and support as they do logistics, an area where they are also an indisputable leader.

</comment></comment></comment></comment><comment><USER19> Haven't they already started with Chime?

[https://chime.aws/](https://chime.aws/)

EDIT: Looks like this article was written Feb 3rd, and Chime was announced 10 days later.

<comment><USER20> And before that, they had WorkDoc and WorkMail. I think the line can be hard to draw: is RDS application? What about RedShift? Quicksight? Echo?

<comment><USER21> WorkMail is DoA. Horrible product.

</comment></comment></comment><comment><USER22> Amazon.com isn't an application?

Less flippantly, why would Amazon want to expend more resources to make less money? They can comfortably keep pushing _down_ the stack for a good long time, swallowing up more and more *aaS segments until they're well bigger than both Google and Apple.

That's what the world needs from Amazon. Not Yet Another Productivity Suite. In the meantime they can do like Google, and disrupt segments where entrenched business interests are getting in their way.

</comment><comment><USER23> I'm guessing they won't move very far up the stack for the time being. It seems to me that once a process is able to be software-itized at least two things happen. One it comes under that old adage that any computing program/application can be done for half the resources/time every 18 months. The second is that producer surplus (profit) that emerges from an information asymmetry becomes consumer surplus when that asymmetry is able to be defined in software. All supply side economies of scale seem to be disappearing and what we're left with are companies that have a monopoly on some raw input or a demand side economy of scale (network effect).

</comment><comment><USER24> Yeah they could build a shopping platform on top of it or something.

<comment><USER25> I'll get on that right away. Great idea!

</comment></comment><comment><USER26> AWS created its partner network exactly for this.

They just supply their technology and consulting partners with building blocks so they can do the tailoring.

The author apparently didn't do proper due diligence before typing down this article.

<comment><USER27> Amazon retail has a reputation for allowing marketplace sellers onto their site then cloning things that sell well [1].

If they'll do it for their marketplace sellers, why shouldn't they do it with their technology partners?

[1] [https://www.bloomberg.com/news/articles/2016-04-20/got-a- hot...](https://www.bloomberg.com/news/articles/2016-04-20/got-a-hot-seller- on-amazon-prepare-for-e-tailer-to-make-one-too)

<comment><USER4> Buying a pair of shoes from another reseller doesn't make a difference.

It doesn't work for technologies. Changing systems is a huge cost and effort.

</comment></comment></comment><comment><USER28> I have wondered this too. Oracle sells their database, but they also sell ERP/CRM/other TLA applications built on top of it. Amazon could do the same thing. And I think every batch of new AWS announcements they creep a little further up and up. Their IoT platform seems like an almost-there example. It is targeting just one vertical (sort of---it depends on how big IoT becomes I guess), and it ties together other lower-level offerings. When I look at their IoT product I think "I can combine those services myself." But of course that is what programmers always think. :-)

<comment><USER29> Doesn't Amazon already "sell" DynamoDB?

<comment><USER30> Yes but parent's point was they could _also_ sell something that works on top of DynamoDB. For example a Salesforce clone (not saying that's a good example just an example). Oracle sells their own DB as well as software that runs on top of the very same database.

</comment></comment></comment><comment><USER31> > _" It would be interesting to see Amazon actually start producing algorithms > and application software on behalf of customers, moving itself even further > up the stack and deeper into IT departments."_

Sounds more like consulting than Amazon's current business model. Is consulting really all that great a business, as compared to what Amazon is currently doing? Writing personalised software offers extremely low customers:engineering-effort ratios, as compared to infrastructure level services which are more one-size-fits-all. I'm sure Amazon will make AWS more and more high level, in an effort to attract customers who want high level solutions as opposed to low level solutions. But I can't imagine Amazon going full throttle into the consulting business.

<comment><USER16> I think it is competition for "software product delivered as a service providers", such as Salesforce.com, Basecamp, etc.

</comment></comment><comment><USER32> This is a really weirdly-written post! I think it needs some serious editing before it's worth reading. This sentence jumped out at me:

"This is natural enough for all IT suppliers, which triple their revenues when they start going up the hockey stick curve, than then they double revenues for a while, then it cools down to maybe 80 percent growth and then 50 percent growth and then 25 percent growth and then the rate of change gradually slows until it matches the overall rate of spending in the IT sector overall."

All the stuff between "triple their revenue" and "gradually slows" is redundant waffle.

</comment><comment><USER33> Do video games count? Because this company[0] has been offering cloud gaming for a while now. If I'm not mistaken, some others here on HN have also tried the same technique with video editing software with some success.

[0]: [https://parsec.tv/](https://parsec.tv/)</comment>


Google in preliminary talks to buy Hulu - <AUTHOR> http://latimesblogs.latimes.com/entertainmentnewsbuzz/2011/06/google-in-preliminary-talks-to-buy-hulu-.html

<comment><USER2> In Levy's "In the Plex", he writes about Google's original idea getting into video- They wanted to lay down with the content industry in much the same way that Hulu is now. Have all syndicated content, ads, the works.

They tried it with Google Video, and had a hard time signing the deals, and getting things done. Youtube was kicking their ass. So they bought Youtube, and it's continued to explode.

In their hearts, I have to believe that Google still wants to make that work. They've flirted with this a few times; Startrek/etc are on Youtube, and Google Video still has premium content.

Adding Hulu into the mix would give them the content/partner deals to run 1st- run, major studio content on their platform.

They could segment; Leave Youtube for viral/crowd/user videos, and Hulu for more "professional" videos.

Google Video, and Google.com would shows results from both when you video search.

It'd be brilliant.

Edit- Clarified wording.

<comment><USER3> The issue is: Whenever you do a buy like this, all the customers of the service get to jump ship if they want to.

So you don't necessarily get the network contracts by buying them.

<comment><USER4> Depends on what contracts they've signed, what their termination clauses are, and when they expire.

Most likely, the networks do have contracts such that they can jump ship at will.

<comment><USER3> I'm guessing it's not "at will" with no penalty but "in the event of ownership changes, non-payment, or with X noticed for the payment of Y liquidated damages', with Y being really large (and you can tell from the announcements that have come out of hulu the contracts have terms).

</comment></comment></comment></comment><comment><USER5> This would basically amount to Google paying for Hulu to be shut down. Who would buy Hulu? We know that its backers - NBCU (Comcast/GE), Fox (News Corp), and Disney/ABC - are not making as nearly as much money off of it as they want to. As a result, if they sell it off they are unlikely to support their content being on there even with the fees, since the fees Hulu is able to generate are not adequate.

The only reason I can see that Google would be interested in Hulu would be because it competes with Youtube. Because as soon as Hulu loses its media backers it appears doomed to go straight into the ground.

<comment><USER6> You make a good point. However we do not know what is happening in the negotiations.

This is what I would do if I were Google. I would say to the media companies, that I need license deals for at least one or two more years in order to buy Hulu. The media companies would probably give those in order to be able to book a nice profit on Hulu. Then during those one or two years, I would work to cut the media companies out. I.e., I would make deals directly with producers to bring new TV shows to Hulu before they even get on TV.

Every year there are dozens or maybe even hundreds of shows that get pitched to the TV companies and most of them get rejected. I am sure there are plenty of good ones among them. Google has enough money to pick up some of those shows and to keep Hulu interesting.

Hulu is valuable not only because of their content deals (which are about to expire) but because it has trained millions of people to go there to watch TV. Google can take advantage of this and swoop in and cut out the middle man by making deals directly with the content producers. This is somewhat similar to what CD baby did for music.

<comment><USER7> Then after the shows run on Hulu they can be sold to networks to on television with the statistics behind each show that they are popular.

</comment></comment></comment><comment><USER8> I think it would be a very good fit with them. But they need to make sure they won't get screwed by the networks later, when they won't care what happens to Hulu once they've sold it. Their incentive might be to kill it so they keep making money from normal advertising, rather than Hulu's online advertising.

But this is also an opportunity to strengthen their relationship with them, and get them to support Google TV.

EDIT: They can also do a lot of cool stuff to it, like integrating Google+ with it, for social viewing. Imagine Hangouts with Hulu...

<comment><USER9> WRT your edit: This reminds me of a service idea I had a while back which I shelved for far too many reasons: A site/chatroom-esque thing where you can invite people to watch things with you over the net (inspired by my long- distance relationship at the time). I'd originally thought of Megavideo, but youtube movies was even better (read: more legal). Advertising would have been fairly well-targeted, judging by the video these people were watching. Free idea, anyone?

<comment><USER10> The Colbert Report (via colbertnation.com) had/has something like this. It prompted me to try it when I was watching an episode, basically you wait for a room to fill up with people, then it plays to all of you while you chat. Obviously you can't pause, which bothered me as I am usually doing two things at once while watching something online

</comment></comment></comment><comment><USER11> Remember Google Fiber for Communities when you read this. I would be very concerned if I was a cable company. Google would probably be happy enough to give a la carte TV via Hulu and high speed internet for little/no profit as another ad platform.

<comment><USER12> Assuming they can get the content. That's a big assumption to make just as the content companies are giving up on Hulu.

</comment></comment><comment><USER13> Don't most content deals have a clause that invalidates them in case the company gets sold? Don't the networks hate Google (see Google TV as an attempt to get their content on televisions for free)? Doesn't Google already own a video streaming company?

</comment><comment><USER14> "Two of the media companies behind the online video service, Walt Disney Co. and News Corp., recently renewed licensing agreements to make Hulu more attractive for a sale." Providing the other networks will follow suite this looks to be a great opportunity, though I do wonder how it will play in with their services

<comment><USER15> They already have the three major networks. NBC/Universal (Comcast) is obligated to provide the same thing as the other partners due to the Justice Dept's rules regarding the takeover.

[http://techcrunch.com/2011/01/18/comcast-nbc-merger-the- hulu...](http://techcrunch.com/2011/01/18/comcast-nbc-merger-the-hulu-rules/)

</comment></comment><comment><USER16> I guess the could transition Hulu into a pure subscription platform and use youtube as the ad supported platform. Move premium Youtube content over to Hulu and integrate search so Hulu results show in Google.

</comment><comment><USER17> I assume that if this is true, this would be evidence of them putting a lot of money on the "re-launch" of Google TV.

Google TV was a bomb for me when the cool unified streaming TV search feature didn't actually work in reality, because Hulu blocked it.

Buying them out and integrating it is one way to solve that problem.

</comment><comment><USER18> Well, it's certainly not for their crap content or the ads Hulu shows despite being a paid service.

Do they have enough customers to matter anymore? It's not like the goodwill of media companies is worth anything.

<comment><USER3> Lots of people still use it, are you sure adoption is going down?

Hulu+ is pretty popular in my circles.</comment></comment>


Replacing JavaScript Hot Path with WebAssembly - <AUTHOR> https://developers.google.com/web/updates/2019/02/hotpath-with-wasm <comment><USER2> My guess is that the JS implementation of the worst-performing browser is having trouble with the non-1 for-loop steps. Doing 90-degree image rotation with fixed steps and some index calculations should work better (0.18 sec vs 1.5 sec for their implementation in node.js):

        for (var y = 0; y < height; y++)
            for (var x = 0; x < width; x++)
                b[x + y*width] = a[y + (width - 1 - x)*height];

Although that's still far from the theoretical maximum throughput because the cache utilization is really bad. If you apply loop tiling, it should be even faster. This problem is closely related to matrix transpose, so there is a great deal of research you can build upon.

EDIT: 0.07 seconds with loop tiling:

        for (var y0 = 0; y0 < height; y0 += 64){
            for (var x0 = 0; x0 < width; x0 += 64){
                for (var y = y0; y < y0 + 64; y++){
                    for (var x = x0; x < x0 + 64; x++){
                        b[x + y*width] = a[y + (width - 1 - x)*height];

<comment><USER3> Your 0.18 sec result is (to use the units they used in the article) 180ms, and if I understand correctly their best webassembly compiled and executed result (?) is 300ms. Beautiful.

EDIT: But it could also be that your computer is somewhat faster than theirs? Do you happen to have some very fast CPU? Can you say which? When I run C-like C++ versions of your code I get the speeds you get with node.js. However, you made overall much better results than they were able, it's still great work!

        #include <stdio.h>
        int main(int argc, char* argv[]) {
            enum { height = 4096, width = 4096 };
            unsigned* a = new unsigned[ height*width ];
            unsigned* b = new unsigned[ height*width ];
            if ( argc < 2 ) { // call with no params
                // to measure overhead when just allocations
                // and no calculations are done
                printf( "%d %d\n", (int)a, (int)b );
                return 1;
            }
            if ( argv[1][0] == '1' ) // call with 1 the fastest
            for (unsigned y0 = 0; y0 < height; y0 += 64)
                for (unsigned x0 = 0; x0 < width; x0 += 64)
                    for (unsigned y = y0; y < y0 + 64; y++)
                        for (unsigned x = x0; x < x0 + 64; x++)
                            b[x + y*width] = a[y + (width - 1 - x)*height];
            else
            for (unsigned y = 0; y < height; y++)
                for (unsigned x = 0; x < width; x++)
                    b[x + y*width] = a[y + (width - 1 - x)*height];

            return 0;
        }

<comment><USER4> I think its fast because of the L1 cache or something like that. I dont understand fully but this is what i got

<comment><USER3> The fastest version is the fastest because it's the most cache-friendly one of all which were presented. See e.g.

[https://stackoverflow.com/questions/5200338/a-cache- efficien...](https://stackoverflow.com/questions/5200338/a-cache-efficient- matrix-transpose-program)

But note that robko made an improvement even before making that.

<comment><USER3> > made an improvement even before

Or maybe not: my short experiments with the simplified version based on their algorithm and his JavaScript versions gave some conflicting results. I haven't thoroughly verified them, this note is just to motivate the others to try.

</comment></comment></comment></comment></comment><comment><USER5> Did you see the benchmarks? There's almost no difference between javascript and wasm except for a single certain browser. So you're really going to take on the maintenance burden to get that better performance?

This is a cool technique but I can just imagine the looks on my team mates faces when I tell them it isn't react... :/

<comment><USER6> Weird that they didn't say which browser is which :/

<comment><USER7> Probably were worried it would look like they're trying to shame their business partners (Apple and Microsoft I guess).

<comment><USER3> Actually it seems that the second worst in JavaScript (when executing their example) is Chrome?

User robko here [https://news.ycombinator.com/item?id=19167078](https://news.ycombinator.com/item?id=19167078) measured the code on node.js, and node.js is based on Chrome's V8 and he measured 1.5 sec vs article author's of around 2.7s, so it would seem that robko has some almost twice as fast CPU, and the other two (fast) JavaScripts are under 500 ms, and the slowest is 8 seconds, so V8 of Chrome remains the only candidate for the second worst performing of their example.

<comment><USER8> I wish they had at east posted a browser-runnable version of their test so we could see for ourselves which browser is which, or compare JS vs WASM on our own systems. (On this type of code, I'd expect Safari to be the fastest, not Chrome.)

<comment><USER3> See my "minimal" C++ translation in my other post here. There's not much to add. For JavaScript start with their code, but add the allocation, just replace allocations with var a = new Uint32Array(height * width); and b the same. Add the timing (1), put in HTML and you're done. It's easy, just a few minutes for anybody who works with that (and this site should be filled with the competent developers AFAIK).

1) [https://developer.mozilla.org/en- US/docs/Web/API/Performance](https://developer.mozilla.org/en- US/docs/Web/API/Performance)

</comment></comment></comment></comment></comment></comment><comment><USER9> The "predictable performance" point applies not just to performance across browsers but also that you don't need to pay JIT warm-up costs. A while back, I ran some benchmarks on the same codebase in TypeScript and AssemblyScript and found that wasm was much faster than JS for short computations and often slower than JS when V8 is given multiple seconds to fully warm up the JIT:

[https://github.com/alangpierce/sucrase/issues/216](https://github.com/alangpierce/sucrase/issues/216)

So really, it depends a lot on the use case. In my case, it's often a short- lived node process that a user is directly waiting on, so compiling to wasm is probably useful. It also depends on what you're doing; some types of work (e.g. where you'd want careful memory management) are a lot harder for V8 to optimize from JS and can be expressed more nicely in AssemblyScript or another language that gives more memory flexibility.

<comment><USER10> For that, it looks like unless you're running the same js on a really huge dataset webassembly will win (going from the second speed test). Even when you're compiling 50MB of JS with that thing, Wasm is 5% slower than JS, and when you're compiling 500KB (more typical) it's 300% faster.

</comment></comment><comment><USER11> Wow all these numbers seem insanely bad. 500 milliseconds to transpose 16 million pixels (so 64mil bytes)? A modern CPU should able to do that at least 10x faster, if not 100x.

<comment><USER2> You are correct. The code is using an inefficient cache access pattern, so most of the time is spent waiting.

You probably won't get 100x faster without SIMD, but 10x is certainly doable. Unfortunately, SIMD.js support has been removed from Chrome and Firefox a while ago, even though it is not available in wasm to this day.

<comment><USER12> How would SIMD do anything to address the problem's fundamental anti-cache- friendly access patterns? You'd need to restructure the problem to be cache- friendly, but SIMD won't really be relevant to that.

<comment><USER2> You can use both at once. Usually, you'd have something like 64x64 tiles in cache and use 4x4 or 8x8 tiles for SIMD.

</comment></comment></comment></comment><comment><USER13> Can we expect a day when WASM will be first class citizen in browsers (i.e like JavaScript) and not just a sidekick?

<comment><USER14> Not anytime soon IMO because WASM still has to access browser APIs through the DOM, which is really built with JS in mind.

<comment><USER15> HTML DOM is described in terms of IDL interfaces, complete with types. I wouldn't say that it's optimized for JS - indeed, that's why jQuery and similar were introduced. When WHATWG took over, they improved it specifically for better JS interop, but it's still straightforward to map to most statically typed languages.

[https://dom.spec.whatwg.org/#infrastructure](https://dom.spec.whatwg.org/#infrastructure)

[https://heycam.github.io/webidl/](https://heycam.github.io/webidl/)

<comment><USER16> The problem isn't exposing the APIs, the problem is the wasm has what is essentially the C memory model, so you couldn't trust any point/object you get from wasm land.

That's why there so much work being put into giving wasm a more typical (for a vm) typed heap. Similar issues occur with lifetime of objects - if you get anything from the dom, you have to keep it live if wasm references it, but wasm has no idea of what memory or a handle is.

These are solvable problems, but you're not getting dom access until after they're solved.

<comment><USER15> Why can't wasm just use opaque handles for DOM objects? It doesn't need them to be in wasm-accessible memory, after all. It just needs to be able to invoke methods on them.

<comment><USER16> It's not "wasm just needs to be able to invoke them"

Because the wasm memory model doesn't have typed memory - if you call a dom api and get a handle back, you need to store it. Then you need to be able to pass it back to the host vm.

So now your wasm code needs to make sure the handle stays live - wasm by design doesn't interact with the host GC, so you have to manually keep the handle alive (refcounting apis or whatever), and the host VM has to have someway to deal with you trying to use the handle without having kept it alive.

Similarly because wasm is designed around storing raw memory in the heap the wasm code can treat the handles as integers. Eg an attacker can just generate spoof handles and try to create type-confusion bugs, or maybe manually over release things.

So the problem isn't "how do we let wasm make these calls" but rather "how do we do that without making it trivially exploitable".

<comment><USER15> But surely that is also fundamentally a solved problem? I mean, we've had distributed systems for a long time, and they had to deal with all the same issues - lifetime, security etc.

<comment><USER16> Distributed systems are designed (for better or worth) on the idea of non- malicious nodes.

Those that aren't have an extremely limited API - that would be logically not dissimilar from "untrusted wasm talks to more trusted JS".

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER17> I would have loved to see Go included in the comparison as well. It can compile to wasm since 1.11.

<comment><USER18> Go was pretty much a non-starter. They (currently) need a runtime which will make the file size non-competitive to the other ones. Also, since only Chrome has support for threads in WebAssembly (in Canary), we'd not be able to make any use of the concurrency.

</comment></comment><comment><USER19> I'd be tempted to hand-write the WAT for that. It's not that bad, much easier than dropping into a x86 asm block in C or something.

<comment><USER18> I did :D Turns out compilers are pretty good at generating WAT.

</comment></comment><comment><USER20> Hmm.. the Google article stipulates:

> WebAssembly on the other hand is built entirely around raw execution speed. > So if we want fast, predictable performance across browsers for code like > this, WebAssembly can help.

So i wanted to see how i could use WebAssembly in a React webapps. I found this SO question sees the opposite:

> When running this [ WebAssembly] code in Chrome, I observe "pauses" that > cause the app to be a bit jittery. Running the app in Firefox is a lot > faster and smoother.

[https://stackoverflow.com/questions/53584607/react-app- with-...](https://stackoverflow.com/questions/53584607/react-app-with- webassembly-is-slow-in-chrome-but-fast-in-firefox-why)

Same code, different browser, different performance. I'd love seeing a Google Developer answering that question in depth..

<comment><USER21> That looks like a bug, rather than an inherent characteristic of wasm.

</comment></comment><comment><USER22> I would try optimizing the JS before dropping down to webassembly. For example try replacing let and const with var as let and const in loops have to create a new variable for each iteration.

<comment><USER23> That's not how let and const work at all, where did you get that impression?

<comment><USER22> Have you ever made a for loop using var only to have the variable point to the last value in the iteration ? And had to make a closure using forEach, function or self calling function ? With let you do not have to do that as a new variable is created for each iteration. Instead or reassigned when you use var.

</comment></comment></comment><comment><USER24> WebAssembly is a bit underwhelming to be honest. It feels like every week there is a new language that can come close to C performance meanwhile they've been working on WebAssembly for years and years and it can barely beat JS.

Shouldn't WA as a greenfield project with it's extremely basic memory model and lack of runtime or standard library be super easy to optimize?

After all, there is no point in having the bad ergonomics of assembly together with the awful performance of JS, right?

</comment><comment><USER25> Those are runtimes in the second range. Are they doing that in a separate thread or do they block the UI? And how long does it take to transfer the data to that thread?

</comment><comment><USER26> The performance gain are so small , its not worth this setup overhead . The average user won't see the difference. Hence , the simplicity of'this module . Just do it in JS , chrome as 70% market share why would you ever bother ?

V8 has received decades of optimizations and it can easily compete with compiled languages in terms of speed.

I was hyped to death for WASM , but this is the tenth article I'm reading on this subject and I still ending on the same conclusion : there is no advantage for front end developers to use WASM.

Only Rendering Engine ( Unity , Adobe Products, Autodesk ) can really benefits from this.

<comment><USER27> > chrome [h]as 70% market share why would you ever bother ?

This view seriously needs to die. It's honestly not that hard to test in two or three browsers, and the differences are minor enough that it isn't a pain. But the only way that's possible is through Web standardization, which only happens when there are diverse options.

As web developers, it's our duty to keep the web healthy, and that means not only optimizing for a single browser.

<comment><USER28> Agreed. This is IE 6.0 all over again.

<comment><USER29> With the exception that Chrome is a good browser.

<comment><USER16> While msft did abuse their position to solidify an IE centric world, people need to realize that when ie4/5/6 were released they were dramatically better than the competitors. The problem is that post-domination they simply stagnated and so the design shortcomings start being a problem.

It needs to be repeated: at the time IE /was/ a good browser. Just like chrome today. And similar to chrome played fast and loose with web exposed features. Sometimes for the better (XHR was an IE invention), sometimes for worse (so was activeX).

<comment><USER30> > Sometimes for the better (XHR was an IE invention), sometimes for worse (so > was activeX).

Wasn't XMLHttpRequest an ActiveX object?

</comment></comment></comment></comment></comment></comment><comment><USER31> anyone like to take a guess what "Browser 4" is?

</comment><comment><USER32> Too bad no wasm on IE 11

Where it would be needed most

<comment><USER33> Depends on your use case... a lot of places are just plain deprecating IE altogether.

<comment><USER34> Isn't Microsoft one of the founding companies in the initiative? [0]

[0] [https://webassembly.org/](https://webassembly.org/)

<comment><USER35> Microsoft !== IE

The logo on the front page you linked it the logo of Microsoft's other browser, Edge. There is no other mention of Microsoft or Internet Explorer on it.

</comment></comment></comment></comment><comment><USER36> (overly ironic) tl;dr "let's rewrite something in this new browser feature because the other browser feature we added last week is not supported anywhere and buggy in chrome"</comment>


Fedora Cross-Platform Dist-Build Tool - <AUTHOR> https://github.com/tylermaginnis/fedora_systems_administration

<comment><AUTHOR> Over the weekend, I reviewed numerous sources of documentation for the subsystems in Fedora (past and present) that are responsible for building distributions. Some systems administrators may prefer to dynamically build their server distributions based on a script, the advantage being that the servers can be dynamically set IP addresses and PXE-network-enabled boot ISOs be spun, accessing kickstart files on a server.

However, the barrier for entry on these technologies is that the documentation is gappy, and spotty at best. Please post any suggestions you have to my script, bitbuild.sh. Currently, the kickstart file package manifest it builds is broken; however, I would like to make it so it can spin EPEL and Fedora ISOs successfully. I built this out on a Fedora 20 VPS, and next chance I get, I will be building kickstart files for each dist I wish to target -- and integrate functional dist-stubs into the existing codebase.

This system will also dynamically choose code repositories - however, some derivations of the standard URL form exist. I intend on building out a repo list for all dists I intend to target.

When EPEL and Fedora are covered, I will move onto complete tools for the other free Enterprise distributions. So methods will exist in this code for detecting on which dist of Linux this tool is operating.

Please give me a star or something on the repo and follow, any suggestions appreciated. The tool is currently based on Pungi, Kickstart, and Anaconda.</comment>


Using sshuttle in Daily Work - <AUTHOR> http://teohm.com/blog/using-sshuttle-in-daily-work/ <comment><USER2> sshuttle is very useful when accessing instances in a private AWS VPC through a bastion host.

Example:

      sshuttle -r user@bastion-host --dns 10.0.0.0/16</comment>


WARDuino: A dynamic WebAssembly virtual machine for programming microcontrollers [pdf] - <AUTHOR> https://science.beardhatcode.be/papers/2019-WARDuino-MPLR.pdf <comment><AUTHOR> > Our experiments lead to extending the standard WebAssembly VM with:

> 1) safe live code updates for functions and data

> 2) remote debugging support at the VM level

> 3) programmer configurable (Arduino) modules in order to keep the virtual > machine's footprint as small as possible.

> The resulting WARDuino VM enables the programmer to have better performance > than an interpreted approach while simultaneously increasing the ease of > development.

\---

Alse see:

WebAssembly Extended with Hot Reloading, Remote Debugging and Uniform Hardware Access

[https://www.infoq.com/news/2020/06/webassembly-debug- warduin...](https://www.infoq.com/news/2020/06/webassembly-debug-warduino/)</comment>


Ask HN: Any interest in a modern QBasic? - <AUTHOR> My son started playing with QBasic the other day. He's really getting a lot out of it.
It's really convenient to get started in. It's super helpful that it's an IDE with a built-in interpreter and comprehensive help section. The semantics aren't that hard to pick up. And it has a built-in basic graphics library.
But it's lacking in a few areas. The IDE's fixed screen resolution is really hard to work with. In general QBasic's syntax is confusing and inconsistent. The IDE is missing important features like undo/redo, which I totally forgot about.
So I was thinking, why not write a modern alternative? My plan was to build a very lightweight IDE (probably using Qt), that has a built-in interpreter, using a custom language (probably a stripped down version of Ruby without all the crazy). It would probably use something like SDL and export a basic graphics library too. And it would come with a comprehensive help section including a tutorial.
Is there any interest in using and/or helping with such a project?
(I've looked at a few existing options. Most of them seem to be more drag-n-drop "visual" languages, which I'm not interested in.) <comment><USER2> Before you go too far, have you checked out [http://racket- lang.org/](http://racket-lang.org/) ?

Dr. Racket is pretty darn good, and racket is a reasonable language. Plus, I think someone over there is still chipping away at [http://www.pyret.org/](http://www.pyret.org/)

<comment><USER3> An important part of QBasic is the built-in 2D graphics library. It's a big motivating factor for him. Does Dr. Racket come with one?

<comment><USER4> If you look at the racket quick start guide, the third example is drawing a circle. You make a checkerboard about a page later.

It's not as advanced as something like processing, but it's far easier than doing graphics with QBasic back in the 80's.

</comment></comment></comment><comment><USER5> I have also yearned for my simplistic old Basic days, but I think it's more nostalgia than an actual void in computing which needs to be filled.

I don't know how old your son is, but I think he'd be better served by learning something relevant and extensible, than some custom language intended to him from scary programming. The Python and editor idea was good, though it doesn't necessarily have to be Python.

He's got you there so if he wanders into some "dark corner" of the language it's not like he's screwed and without help. That was my major impediment to learning programming as a child, not having someone there to explain things. I was 6 years old and got stuck on the concept of an array and my progress ground a halt. Later on I found a friend who could explain harder things like structs and enums and this made programming much easier.

So, just show him tools and be there when he has questions is my best advice.

<comment><USER3> I get what you're saying, and I appreciate the good-will. But when I taught my brother Ruby last summer, I found myself apologizing for so much inconsistency and insanity. I think it ended up turning him off to programming. I want to avoid that with my son.

</comment></comment><comment><USER6> Have you looked at something like the iPad app codea? [http://twolivesleft.com/Codea](http://twolivesleft.com/Codea) It uses LUA for the scripting language, and a really nice IDE.

We also did something similar, except it is all visual programming (I know you said you are not interested in visual).. Its called GamePress ([http://www.gamepressapp.com](http://www.gamepressapp.com)), free iPad app check it out :)

</comment><comment><USER7> There's a "modern" qbasic called qb64. Have you looked at it?

I also second the recommendations on python (which has a built-in turtle and awesome libraries like pygame).

Racket is also a very good choice. DrRacket is a solid IDE and the language has plenty of good basic libraries. The book Realm of Racket might also be of interest: [http://realmofracket.com/](http://realmofracket.com/)

<comment><USER3> Yeah, we tried qb64 out a few days ago. Its IDE is a little broken in the latest release. Any time you press any key, you have to wait anywhere from 2-5 seconds before the computer reacts. It's apparently part of its syntax-check- as-you-type program, but there's no obvious way to turn it off.

I just tried DrRacket last night, and the IDE was pretty confusing to get started with for me. Plus I think it will be easier for him to get started with a non-Lisp language. (Disclaimer: my favorite language right now is Clojure.)

</comment></comment><comment><USER8> Couldn't you just wire up a graphics library in Python, and give him a Sublime Text editor configured so that CTRL+B runs his python script? I'm not sure reinventing the wheel on this one makes sense, considering the power and simplicity of some of the environments out there, PLUS, python would provide him with real-world skills.

<comment><USER3> I want to give him the most frictionless experience getting started. And Python has plenty of dark corners that he might run into pretty quickly. Plus I want to spare him from significant whitespace for a while (but significant newlines are fine). That's why I was envisioning something like Ruby but a little simpler.

<comment><USER9> (Note: I use Python a lot, so sort of biased, maybe ...)

>I want to spare him from significant whitespace for a while

Reasonably smart kids can understand a lot of things if one takes the time to explain it to them a bit, along with the reasons why a particular thing is the way it is.

I'd suggest you try to avoid dumbing things down too much, just because he's a kid. You might be surprised.

Logo (language) could be another option, and is pretty cool for kids (of all ages :) There are free versions available, just google for them or see the Wikipedia page for Logo.

<comment><USER3> It's not about understanding. I'm sure he can understand it just fine. But he's also learning how to use an editor. Throwing in significant whitespace is just going to add frustration.

<comment><USER9> IMO, that's not such a big deal - understanding what significant whitespace is, if you're prepared to have him deal with significant newlines, as you said. But it's your choice, of course ...

</comment></comment></comment></comment></comment><comment><USER10> Have you tried FreeBasic + FBide? [http://www.freebasic.net/](http://www.freebasic.net/)

It's almost compatible with QB, but it lacks some of the debugging facilities.

My favorite feature was stop-edit-and-continue. I still miss it, but it's very difficult to implement in a compiled language.

<comment><USER3> This takes me back 10 years. Yep, I switched to FB at one point. But it took the route of C++ (I mean literally, they just started copying lots of C++ features and syntax). That's something I want to spare my son from.

</comment></comment><comment><USER11> Rather than QBasic, I would like to suggest Monkey-x [http://monkey-x.com](http://monkey-x.com)

it has a great toolchain, built-in IDE, and supports many, many platforms (Desktop, iOS, android, HTML5, others). The syntax is more modern, and is being used in many commercial games.

</comment><comment><USER12> How old is he? I have a 11 year old niece, and she is learning Javacript (using code combat and codecademy) and Python at a good pace.

<comment><USER3> He turns 10 in a few weeks. But I'm really trying to avoid having to apologize to him the whole time he's learning, which is why I'm avoiding JS, Ruby and Python.

<comment><USER12> Why would you apologize?

<comment><USER3> I meant being apologetic for the language: "Remember how methods use parentheses to group arguments? Well anonymous functions use pipes for some reason. Yeah I know, it doesn't make sense to me either. It's just one of those things you have to memorize."

</comment></comment></comment></comment><comment><USER13> Why don't you make your IDE around python and pygame?

</comment><comment><USER14> You should use Python + PyGame.

<comment><USER3> I hope to spare my son from significant whitespace for a good while.

<comment><USER15> Don't. The (programming) world isn't perfect and trying to protect him from anything "confusing" or bad will not help him in the long run. Instead, explain. If you don't have a good answer, research the reasons. Getting to know and working around (or with) the quirks of the system is important. Don't take that away from your son.

<comment><USER3> I generally agree with that point. That's why I'm starting him off on QBasic. Actually if I can find a good graphics library for it, I might teach him Julia next.

</comment></comment></comment></comment><comment><USER16> Another one to check out: [http://smallbasic.com/](http://smallbasic.com/)

<comment><USER3> I found out about that a few days ago, and it looks neat. But we don't have Windows and can't afford it.</comment></comment>