As a 13 year old programmer learning to code in 2005, transferring money online seemed impossible, this was pre-stripe after all. A 13 year old getting a bank partnership or a payment processor deal seemed a bit out of reach as well. These days though, sending money online via stable coins like $USDC over a fast and cheap block chain like Solana, Polygon, avalanche, etc is not only possible but flat out inevitable.
As a 14 year old programmer and tinkerer in 2004, I had no problem buying a Helium-Neon laser for an experiment and paying via PayPal.
As an 18 year old tinkerer and hacker in 2008, I had no problem signing up to take payments via PayPal and running a little side thing selling home-assembled widgets out of my bedroom.
And as horrible as PayPal is, cryptocurrencies have even more friction and risk.
> And as horrible as PayPal is, cryptocurrencies have even more friction and risk.
This comparison with PayPal is perfect. The way I see it, ACH and wire transfers are to PayPal what cryptocurrencies are to startups and tech that is being built right now. The reasons why cryptos have more friction at this point of time is because the PayPals of crypto are being built and distributed. I see a future where creating a wallet and accepting crypto payment will be faster, easier and cheaper than signing up for Venmo or Square Cash.
Stripe fees are higher than Solana $USDC transaction fees.
You also don’t have to worry about getting your account shut down or funds frozen. I once worked for a YC company, LendUp, and we started off using Stripe for accepting payment but had to stop because the policies of their partner bank at the time disallowed servicing of our types of transactions. We spent a large chunk of time integrating with many different payments processors on and off, it was rough.
In summary, web3 has the potential to be and already is, cheaper, faster, and permissionless.
Good point, the author clearly misses the point that tests themselves are code and thus can have errors in them as well. Code coverage is just a vanity metric if you're tests don't actually test the correct thing.
>The pendulum is quickly swinging towards dynamic typing. Programmers are leaving the statically typed languages like C++, Java, and C# in favor of the dynamically typed languages like Ruby and Python. And yet, the new languages that are appearing, languages like go and swift appear to be reasserting static typing?
The author makes the claim that the pendulum is swinging back towards dynamic typing but then follows up immediately with the contradictory evidence that the new hip languages showing up are strongly typed.
I'm curious what if any evidence can be presented that this pendulum is swinging in any direction as oppose to just pulling at opposite ends as it has been for quite some time.
Yeah, this appears to be a bit misleading. It sounds as if they're just running the compiled jar as the /sbin/init process. IMO, thats a very lightweight distro but not a unikernel. #NotAnExpert.
I've been approached by a couple people like this for a technical co-founder position. I got scared off when i actually met them and discovered i had more product experience then them and they had no significant connections or marketing experience to bring to the table.
Wouldn't you lose one of the advantages of PHP which is that every request is stateless and that when it fails it doesn't fail hard killing the application?
Not any more nowadays. I am the original author of Photon and today PHP is extremely robust and you can catch all the exceptions/errors (outside the ones which are making your code invalid, but hey, do your homework). The current PHP 5.3 is also wonderful at not leaking memory. So you get the speed of bare PHP with a framework (because nothing is reloaded, the framework can really load once, reuse many times).
On a small system, a standard HTTP request through Mongrel2, to the framework and back is about 2ms (including 1ms of network latency between the hosts, data from my production monitoring). This is the "hello world" latency. It makes using PHP very fun and very fast. Also, a single PHP process running in the background uses about 12MB, it means that with 12MBx3 + 10MB Mongrel2, you can serve 1000's of users with nearly no load on your system (if you push the load only when needed at the DB level). Tracing a PHP process, you can run it without system calls at all (only gettimeoftheday for logging).
But, this is cutting edge, so, you need to be open minded and ready to dig in the code (less than 25k SLOC anyway I think).
Current PHP is 5.4. Did you perform any test or benchmark with the new version? Do you gain anything from it? By the way, your project looks very interesting!
Very limited tests, one PECL extension for my projects was updated to support 5.4 only recently. The biggest win will most likely be for the POST payload (multipart) parsing because 5.4 is faster on array/strings. The good point is that with PHP farm, you can run both 5.3 and 5.4 in parallel to compare :)
The final method uses a really common programming idiom for optimizing the removal of elements in a std::vector known as "swap and pop". Swap and pop works by taking advantage of the facts that the most efficient element you can remove from an array/vector is the last one by `pop`ing it off and that the preserved order of the given set isn't important.
// swap and pop in C++11
int offset = 2; // remove the second element from the vector
int end = vec.size() - 1;
auto tmp = vec[offset];
vec[offset] = vec[end];
vec.pop();
// `tmp` now contains the value removed from the std::vector
Yeah, aside from the swap trick, there's very little to the Fisher-Yates-Knuth shuffle. It's just following the standard recursive recipe for generating permutations: to generate all permutations on n distinct elements, try every element in the first place concatenated with every permutation of the n-1 remaining elements.
You can implement this directly with hash sets in O(n) time, assuming you're willing to treat hash set insertion and deletion as O(1) operations:
# O(n) time
def shuffle(elems):
elems = set(elems) # O(n) time
xs = []
while elems:
x = choose(elems) # O(1) time (expected)
xs.append(x)
elems.remove(x) # O(1) time
return xs
This whole approach is obvious when you stop thinking of the problem as shuffling an array in place and start thinking of it as randomly generating a permutation of elements drawn from a set. In the final analysis, the optimized in-place implementation of the algorithm with the swap trick does provide in-place shuffling; the way the two halves of the array are used to contain respectively the partial result and an auxiliary set of remaining elements is very much like heap sort.
Not coincidentally, if you interpret the algorithm as I wrote it above monadically, then it can be used to generate either a random permutation or all permutations, depending on whether choose() is interpreted in the probability monad or the list (non-determinism) monad. This shows conclusively that the shuffling algorithm is really just the standard combinatorial generation algorithm for permutations adapted to random sampling. If so, you'd also expect the swap trick to be useful for generating all permutations in place. Well, of course:
void perms(int *xs, int n, int i)
{
if (i == n) {
for (int j = 0; j < n; j++)
printf("%d ", xs[j]);
puts("");
return;
}
for (int j = i; j < n; j++) {
swap(xs + i, xs + j);
perms(xs, n, i + 1);
swap(xs + i, xs + j);
}
}
It seems pretty obvious to me, so I'm not sure what is confusing you.
class Monad m => ChoiceMonad m where
choice :: [a] -> m a
For the list monad, choice is just the identity function. For the probability monad, choice picks a random element from the list. (Ideally choice would take a random access structure like a set as its argument, but I'm doing it the simplest way here.)
To implement shuffle, you more or less just transliterate the Python code as you'd expect.
Before you tackle this, make you sure completely understand how the same situation plays out for the simpler case of subsets:
subset :: ChoiceMonad m => [a] -> m [a]
subset [] = return []
subset (x:xs) = do b <- choice [True, False]
xs' <- subset xs
return (if b then x:xs' else xs')
Over the list monad, this generates a list of all subsets. Over the probability monad, it generates a random subset.
I wish i could agree. However, my experiences in getting jobs as a software engineer have been vastly different. I've never spent longer then a week seeking a job in the software industry. This might be some what biased because i haven't been working in the industry all that long (just 2 years now). I'm a self educated hacker/programmer that has been writing hobbyist code for myself for 8 years and have never attended a day of college in my life. My average salary for the past 2 years i've been programming has been 90k-100k and my first job was a full time employee for a multi-million dollar corporation in Pleasanton CA and now i work for a startup in San Francisco thats in the alexa top 300 sites.
When i set out to get my first job as a software engineer i was currently working as a system administrator for a conference center in Redwood City. It was the first job i landed when i got back from my first tour of duty in Iraq as a light infantryman. I was still young at the time, 20 years old, still not legally able to consume alcohol yet old enough where most of my friends were already halfway through college. Discontent with going back to college to study computer science with a bunch of people younger then me and knowing that my work as a systems administrator is not what i'd need to be doing on my path to achieve happiness in life i set out to apply to companies seeking software engineers on craigslist.
I spent maybe an entire day sending my resume out over email directly to companies seeking software engineers. I remember being somewhat selective, i'd say i had to have sent my resume out to less then 10 companies that entire day. Although i don't precisely recall the amount of responses i got, i did get a decent amount of responses and almost all of them came in the next day (yes this was 2 years ago). This shocked the crap out of me, i had no previous software experience on my resume, my only previous work experiences were as follows: a warehouse clerk, light infantry and systems administrator. Never the less, i was doing phone screens (and killing them btw) and setting up in person interviews. The very first interview i went to lasted 2 hours and was the first time in my life where i was ever asked to write code on a white board (idk, maybe this is an academia thing). It was a group of engineers interviewing me so that also spiked up the intensity a bit. However, when the interview ended and the HR person came in, she extended me an offer right then and there and said that this is something she's never had to do before. So i went back to my systems administrator gig the next day, turned in my two weeks notice and two weeks later i was officially a software engineer.
My second job seeking experience was very different and also very recent. Having put up enough with the offshore teams crappy code and a horde of rushed employment contractors that couldn't code their way through fizz buzz, it was time for me to look for a new job.
So instead of doing any direct applies immediately i just put my resume up on dice.com. That same day my phone was getting barraged with voicemails from technical recruiters. This was going on during work too so i had to turn my phone off for the day. When i got home that night i did do one direct apply and that was to Yelp. I responded to one of the technical recruiters and she set me up with some options and some phone interviews. The next day i got a call from the technical recruiter at yelp to do a quick prescreen and to set me up with a more in depth phone screen with an engineer so i did that. At the same time the contacts from the recruiter were all doing the same thing, calling me and setting up phone screenings that is. The current company i work for right now was moving slightly faster then everyone else though. I did both phone screenings with Yelp and where i work and they both sent me programming challenges to complete and send in. I did them but where i work got back to me faster and set up an in person interview first. So i went and it was a 3 hour interview this time. This time i left without a job offer after the interview but the technical recruiter ensured me that things were looking good. He called me back later that day and gave me an offer over the phone. That was that.
NodePHP anyone? heh, afraid that would be a little more then just a SAPI implementation though, we'd have to throw out a good chunk of the standard library and very few if any extensions were coded for asynchronous execution.
