Even Bromium was pretty upfront about the use case for their product though (high-value targets like executives who travel to China). They were very honest about it being overkill for an entire enterprise.

I think securing endpoints is basically a lost cause though (I'm happy to consider that a minority opinion however). My company spent many years trying to get TPM's to be the solution to this problem, and I'm pretty sure that ship has now sailed; with the only 2 sectors of the industry that are continuing to grow being completely unsuited to TPMs (virtualization and mobile).

I think we'll eventually realize that much like networks, devices have to assumed to be untrustworthy, and we have to route accordingly.

A counterpoint is that mobile platforms often have some form of secure enclave, but sadly not standardized. Even AMD's low cost x86 CPUs are adding an ARM coprocessor, which could in theory be used for functionality similar to TPM, DRM, or AMT. Some of those are more useful than others. On the Intel side, SGX will add more enclave options, and complexity, but hopefully will be open and well documented.

There was a brief window in time when you had to go out of your way to buy an Intel laptop "without" a TPM (even Macs had them for a time, even if Apple never made use of them). The Trusted Computing Group failed to capitalize on that timeframe by providing both a "reason" and decent solutions to that problem.

There's a lot of reasons why that was, if I've been drinking I'd happily go into many of them.

On the mobile side, I agree, it's a hodgepodge. Apple has their secure enclave (which doesn't quite act like a TPM, even though it theoretically could), and there exist vendors who could theoretically include a TEE in their phones (right now they're almost entirely limited to special "government-specific" use cases).

And I'm ignoring Samsung's solution (which is basically snake oil).

Intel's SGX would be great, provided that the industry suddenly switches to X86 for mobile (which I don't think is going to happen).

The mobile industry is way too fragmented from a hardware perspective for any type of trusted computing platform to achieve even a modicum of install base. That might change in the future, but I wouldn't bet on it.

If modular mobile architectures succeed, there will be a better chance of combining one's preferred hardware TCB with one's preferred sensors. Sometimes, it only takes one counterexample to move entire markets, look at the time interval between the first Galaxy Note and Apple iPhone 6.

Just to clarify, in Haskell there is no issue with algorithms being contained inside functions.

Here's a naive implementation of quicksort:

  qsort [] = []
  qsort (x:xs) = qsort smaller ++ [x] ++ qsort larger
                 where
                 smaller = [a | a <- xs, a <= x]
                 larger = [b | b <- xs, b > x]

People may charitably point out that this is a pretty bad naive implementation, because it doesn't just mutate values in the list up and down, which is inefficient. People uncharitably will take issue with even calling it quicksort, as some people believe that the property of just mutating values in the list is an integral part of it being quicksort. I'm not smart enough to have an opinion about whether or not it's a "true" quicksort.

But the point is that you can absolutely have algorithms in Haskell that are not restricted to only run in a Monad.

Monads exist in Haskell as a way to reason about side-effects. Whether or not an algorithm (or any function) needs to be executed inside a monad is a function of its use of side-effects, it's not fundamental.

I do not "see" any clear algorithm in the code (no step-by-step procedure). I see recursion only.

¿Can you explain in words what this code is doing?

¿Can you implement this without using recursion?

  qsort [] = []

    qsort (x:xs) = qsort smaller ++ [x] ++ qsort larger

                  where
                  smaller = [a | a <- xs, a <= x]
                  larger = [b | b <- xs, b > x]

Using that example list above ([3, 5, 1, 4, 2]), here's if we did it by hand:

  qsort [3, 5, 1, 4, 2]
   = {applying qsort}
  qsort [1, 2] ++ [3] ++ [5, 4]
   = {applying qsort}
  (qsort [] ++ [1] ++ qsort [2]) ++ [3] ++ (qsort [4] ++ [5] ++ qsort[])
   = {applying qsort}
  ([] ++ [1] ++ [2]) ++ [3] ++ ([4] ++ [5] ++ [])
   = {applying ++}
  [1,2] ++ [3] ++ [4,5]
   = {applying ++}
  [1,2,3,4,5]

Is it that there are no loops that you don't see how it's an algorithm? It is definitely true that some algorithms are very obvious to implement using loops (quicksort is actually one such algorithm), and can in fact be a pain in the neck to implement in some functional languages.

Now I can see the mathematical elegance of the haskell code.

An explicit algorithm of the same (pseudo)code (using a mutable list) could be:

   function qsort(list)
     if list is [], return []
     let x = extract_first_element(list) // car 
     let smaller = [a | a <- list, a <= x]
     let larger = [b | b <- list, b > x]  
     return qsort(smaller) ++ x ++ qsort(larger)

And then, I'm enlightened. Thank you.

Also, quicksort is a pretty bad example of an pure algorithm, since it loses a lot of its performance benefits when not done in place.

I went over the issues with this version of quicksort in the original comment, but I still think it was a good example because most people are familiar with quicksort, and I was trying to address the original posters claim that algorithms in Haskell could only be used in Monads.

Also, quicksort is one of the few I can do from memory.

But for the past year or so, I find that I program best by actually writing out my program in a notebook (in my case a quad-ruled lab notebook). I don't even start typing until I have it laid out pretty much in it's entirety on paper.

This sounds ridiculous (and I can imagine it's not practical for all types of programming), but I've found that it's been tremendously helpful in getting me to understand what all the code that I'm writing does.

Most of the code I've written this past year has been in Haskell, so that helps somewhat by not having a lot of syntax to write down, but I'm sure I'd be doing the same thing even if I was writing in Java.

"Draw some pictures. Make some notes. Write a function that you suspect will be tricky. Make a flowchart. List the methods that will have to be in that class. Write out how the user will interact with it. Try to list all the pain points for the user. You can write it any way that helps you think. Make up a notation if you want."

Yes, the assignment is due and they need to get code on the screen. But one of these days I'm going to give them a programming assignment and tell them that I only want to see their notes.

I had to add a new feature to a decades old user facing codebase with had to interact with all of the existing system. The implementation of the core of the new feature took only a few hundreds of lines of code since it was just a bunch of graph operations basically. Interfacing with the rest of the system was hell.

I began by just investigating the requirements and designing on paper. I realized on my paper designs quickly that a few graph operations would be sufficient. Understanding how it fit with the rest of the system was only achievable to me by documenting for myself on paper how the bits and pieces worked I had to touch.

Took half a year to get the sucker ready.

Worked just like it was supposed to and my colleague praised how easy the codebase was to extend later on.

Paper and carefull design. It just rules.

I had this false expectation in my head that when programmers tackle a new problem (be either writing a small program or solving a challenge) they're able to think about it for a few minutes then straight up write code and if I can't it's because I suck and this job isn't for me.

Then I realized that what I expected was unrealistic and the "no pen and paper" stage only occurs to people who already met the same or similar challenge before and can recall even the slightest hint of what they did back then.

On the non-mathy side, I find it useful to take the concept of "rubber duck" debugging (which is totally applicable to original design and creation, and not just debugging) but write a "duck" document rather than talk out loud. Aside from not looking crazy, I find writing easier for thought organization.

Sometimes preparing slides can also be a nice way to really force your thoughts into simplest and clearest form. And hey, when you're done, you can present it to your co-workers.

This gets right back to the design thing.

With paper, I can draw graphs of relationships, write tables, add notes to things I drew earlier, etc. It's far more expressive, and far faster, than any computer tool I've tried.

My best work I do while half-napping with a notebook by my side.

One advantage, I think, is that we can type faster than we can write with pen and paper. Thus paper is a more deliberate medium than a keyboard is.

The lectures are basically laid out 1:1 with Hutton's Programming in Haskell book, so if you're familiar with that book, you're familiar with the way the course is structured. I find the actual experience of doing all the homework questions very helpful, even if so far nothing has been particularly difficult.

It's great that electric cars exist now (and maybe someday in the future I'd even be interesting in buying one once there existed infrastructure that made it feasible), but I think your timeline for the obsolescence of internal combustion engines is laughable.

   PROBABILITY FEMALE: 0.997 
   PROBABILITY MALE: 0.569 

Go Engineers!

I could see the vestiges of the previous burst of hacking in the DEC-20's student written software library.

The popularity of the messaging programs should have been a big hint to us..

What used to be the heart of a microcomputer.

A Serious Business Micro, that is, not a glorified game system like a Commodore-64.

> xtank

There's documentation of a work to port it to modern systems:

http://documentation.wikia.com/wiki/Xtank

Also something on Freecode:

http://freecode.com/projects/xtank

This is actually one of the reasons that doing business with the government is less lucrative than the commercial industry (for products and services which are comparable, many are things only sold to the government, so there is no hesitation about pricing them through the roof).

As you can imagine, one of the ways that duplicitous federal contractors get around the idea of having to sell to the government for less than their normal prices is to structure their products/services as different (and therefore not apples to apples comparable).

I still would bet that the price that they charge Goldman Sachs (just as an example, I don't actually know which investment banks are using their product) is higher than what they charge for any individual government client.

Also, I think it's probably worth noting that the maximum addressable customer base for their products for federal agencies is way smaller than the equivalent number of financial customers. There's really only a handful of agencies that have this capability (I'd guess more than a handful, but probably less than a dozen).