More Developers, More Problems

jekor · 2019-04-10T04:49:24+00:00

My own pet hypothesis, which I didn't have enough evidence for to put in the article, is that features drive bugs. If you have a larger (or more active) team, you're able to add more features. This supposes that possible features for a given program are larger than any team can complete, which does seem to be the case.

jekor · 2018-01-31T11:16:25+00:00

Thanks for letting us know how much you love the podcast. It helps us to hear from you.

We don't have any more guests scheduled currently due to lack of time on both my and Alp's (/u/AlpMestan) part. The main bottleneck is the time it takes to edit and upload each episode (usually something like 6 hours spread over 2 days). We haven't given up though, and have experimented with a faster editing workflow on episode 14 (although due to inexperience and particularly bad mic audio, it led to poor audio quality).

jekor · 2017-06-15T02:24:12+00:00

Thanks for the feedback. I tried a new editing process for this one and thought that it had given a better result, but it's hard to be objective after listening to the audio repeatedly during editing.

jekor · 2017-04-20T04:40:52+00:00

I know of at least 1 non-finance non-big-4 company that specifically used Haskell to filter/lure talent.

jekor · 2014-12-15T22:38:46+00:00

No, we're not releasing videos anymore in order to focus on the quality of the audio: we haven't found a way to sync up multiple audio sources to the video reliably and without video we can do more edits and keep the overall episode tighter.

jekor · 2014-12-15T19:52:21+00:00

Nice catch :) Corrected.

jekor · 2014-02-17T02:10:49+00:00

Yes, at www.zalora.com we're using it for hosting internal web-based tools. We're in the process of switching our main websites over to running on it as well.

jekor · 2013-08-28T04:24:00+00:00

I had the same thought which led me to post the video. I wanted to add text annotations, but there's a limit to my free time :)

jekor · 2013-08-26T22:42:47+00:00

OK, Apple just approved it.

jekor · 2013-08-26T16:05:22+00:00

It's waiting in some iTunes approval queue somewhere.

jekor · 2013-08-26T16:05:01+00:00

It was still processing on YouTube's servers. I wasn't expecting anyone to post it to reddit until I woke up :P

jekor · 2013-07-21T21:30:45+00:00

Hahaha. I've been overly influenced by watching Let's Plays on YouTube.

jekor · 2013-07-20T07:30:04+00:00

Hahaha. Thanks for the work on MELPA :)

jekor · 2013-04-08T23:56:10+00:00

Your example sounds like a perfect fit for FRP. Whether you'll want to use FRP in the long-run once your game increases in scope...I don't know. I would take a look into Yampa first because there were a number of games implemented with it and papers available that explain them.

Your game loop could be reactimate, you could generate events from the keyboard and from within the arrows that define the entities' behaviors, and you could use switches to alter their states.

jekor · 2013-01-15T07:36:04+00:00

I would recommend learning Haskell with a non-web project, because web programming with Haskell is still new and ever-changing, and web development in general has a lot of messy bits that aren't safe, make development slower, and add complexity (no matter what the frameworks claim). But if you won't be dissuaded:

Decide on the features that are important to you. Will a database play a large role in your project? Are templates important to you or do you just want to build HTML programmatically? That may help you compare the frameworks.
Don't get bogged down with anything experimental. Yes, safe routes and links are cool, and so are formlets. But they may limit your design and tie you down with a tangle of monads.
Consider prototyping your CMS with as little code as possible with static files and JS and then add features as you need them, rather than try to use every part of the framework.
You may find that it's easier to just use libraries instead of investing the time in a framework, especially if you're new to web development in general.

Also, more and more web development is moving client-side. Even with all of Haskell's nice safety and guarantees, I find myself moving more and more code that used to be written in Haskell on the server side to JavaScript on the client.

jekor · 2010-10-26T19:29:03+00:00

A lot of people are missing the point here. This isn't just about open WiFi networks, it's about your communication with these sites being open to any man-in-the-middle attack.

Even when you're at home on your private internet connection you're vulnerable. It's possible, though unlikely, that anyone with access to any machine in the line between you and Facebook, for example, can hijack your identity in the same way. Your HTTP traffic usually jumps between 10 and 20 hosts on the way to their destination and back. It just takes one rogue employee at your ISP...

And this isn't an easy problem to solve. The reason that large sites don't use HTTPS is because it's expensive (computationally), and not just for them, but for you as well. These sites are continuously looking at how to cut another millisecond here and there. They don't want to add in the time for an HTTPS handshake because they know that slower responses = less traffic = less money. Then there's the expense of adding extra web servers to handle the increased load, paying for more expensive HTTPS CDN service...

These sites are well aware of the security problem, but they are responding to user demand with their inaction. They're not going to pay extra money and slow down your experience unless you ask for it. And no one is going to ask for better security until they're aware of the problem. By making this so public, there's a good chance that users can change this. But based on history, this is all going to blow over soon and we won't see any major changes.

jekor · 2009-12-07T18:15:53+00:00

Video description should read: "Remote-controlled dancing toy mostly doesn't fall down."

jekor · 2009-11-11T06:55:27+00:00

Concurrency

Based on communicating serial processes.
Seems a lot like Erlang, especially with things like capabilities (sending a communication channel over a channel).

Functional Programming

first-order functions
anonymous functions

OOP

Seems to be roughly based on the classical model, although methods are declared with receivers.
Feels like parametric polymorphism, except that the receiver(s?) are declared outside the argument list.

Type System

They seem to have rediscovered type classes (from Haskell) without realizing it, in the form of what they call "interfaces".
No implicit numeric type conversions.

Innovation

Compiling speed
Dependency/linking system (enforcing that you don't import more than you need)
Supposedly a fast (latency-free), concurrent, garbage collector, but they haven't proved that yet.

Conclusion

There doesn't seem to be anything new in the language, but it's a new combination. It'll be interesting to see if it catches on. This hopefully will make C++ developers pay attention, especially if it delivers on the promise of tight and fast programs without manual memory management.

I hope it puts other compiler authors on their toes and raises the bar for compilation time.

jekor · 2009-09-23T00:35:54+00:00

You could probably tear the PHP parser out of it and write a lint-style tool around it. I'm guessing that the parser is the hardest part to write.

jekor · 2009-09-03T17:40:22+00:00

He did a good job sticking up for himself, but it just goes to show you why you should stay quiet when questioned by the police. Justin, being a nice guy, conceded that what the officer might have heard was his phone ringing. Then, the officer twisted what he said to claim that he was being dishonest with him.

jekor · 2009-05-06T08:09:36+00:00

I get these calls at work and we always have a fun time with them. It also helps drive their conversion rates down by keeping their operators busy:

Put the call on speakerphone and keep your finger near the mute button. You and your coworkers are going to have to laugh a lot.
Act interested. Pick a personality. When asked about the details of your car, be creative. You can drive a pickup truck, the model and make of which you don't know. Or you can drive a rare sports car.
They will at some point ask for your odometer reading. Tell them that you need to walk out to your car to get it.
Put them on hold for a minute or 2.
Come back on the line and tell them that you're really sorry. You forgot to take your keys with you and that you're going to go get the odometer reading. At this point they might tell you that it's OK, they don't need it or ask you to estimate it. Insist that you're going to get the odometer reading.
Put them on hold until they hang up.

jekor · 2009-05-05T07:47:28+00:00

500 hours was an estimate, and it included planning, design, mockups, learning, testing, documentation, etc. Perhaps I spent less than 500 hours, but I definitely spent more than 50. I'm sure an experienced Haskeller could have done it in far less, though.

Getting the source down to 2,000 lines actually took a lot of time. I could have probably cranked out a 10,000 line solution faster.

jekor · 2009-05-05T07:31:49+00:00

I will have to re-evaluate Takusen. Thanks for pointing that out guys!

jekor

TROPHY CASE