HN user

gdp

848 karma

Programming languages and formal methods geek.

http://plsadventures.blogspot.com/

Posts21
Comments305
View on HN
www.plsadventures.com 15y ago

"It's a hardware problem" is a programmer problem

gdp
2pts0
www.plsadventures.com 16y ago

What are the semantics of your favourite programming language?

gdp
17pts20
www.plsadventures.com 16y ago

The state of the world (and why I still think it's a bad idea)

gdp
1pts0
www.plsadventures.com 16y ago

The bug-free myth: Why we trust verified software

gdp
1pts0
www.plsadventures.com 16y ago

Insecure software is your fault

gdp
2pts0
www.plsadventures.com 16y ago

Two (programming language) features that would improve my life

gdp
14pts6
www.guardian.co.uk 16y ago

Peter Landin Obituary

gdp
13pts0
www.plsadventures.com 16y ago

Pigeons and Programming: Superstitious behaviour

gdp
1pts0
www.impredicative.com 16y ago

Ur/Web: The Ur Programming Language Family

gdp
16pts1
www.plsadventures.com 16y ago

Why programming language design is hard (and a few ways it can be made easier)

gdp
31pts8
www.plsadventures.com 16y ago

On the semantics of pseudo-code

gdp
2pts2
www.plsadventures.com 16y ago

Making money from programming language design

gdp
2pts4
blog.notdot.net 16y ago

Netboot.me - Turning netboot into internetboot

gdp
37pts7
plsadventures.blogspot.com 16y ago

I laugh at your puny human 'objects'

gdp
30pts53
plsadventures.blogspot.com 16y ago

Worrying trends in programming languages: Javascript

gdp
5pts10
plsadventures.blogspot.com 16y ago

A prototype static analysis tool for observable effects

gdp
1pts0
plsadventures.blogspot.com 16y ago

Hardware/Software Co-design

gdp
1pts0
plsadventures.blogspot.com 16y ago

Simple patterns for better arguments about programming languages

gdp
11pts2
plsadventures.blogspot.com 16y ago

Sources of inspiration and interesting directions for programming languages

gdp
9pts3
plsadventures.blogspot.com 16y ago

If concurrency is easy, you're either absurdly smart or you're kidding yourself

gdp
14pts20
plsadventures.blogspot.com 16y ago

When are we going to stop writing code?

gdp
7pts33
The Blink Protocol 14 years ago

Could be useful for some things. I feel like it's a missed opportunity to employ somethings like session types, given the existence of a quasi-typed human-readable "schema" definition. It seems like one could (and should!) go further and make it an unambiguous protocol specification against which implementing programs could eventually be checked.

Consistent with the complaint leveled against my previous comment, I should think that this is really consistent with the DBMS syntax of the Opa language</pedantry>

You're quite right. I think my complaint was that it reduces the definition of "database" to "anything that is used to store data", rather than the database being the json file(s) themselves, at which point we have degenerated to about the same terminological point where it would be reasonable to call saving CSV or MS-Access files into a Dropbox folder "Dropbox-as-a-Database", which seems an unhelpful label, if nothing else.

It seems rather generous to call this a database. It's files on a filesystem. The lack of any kind of transactional consistency guarantees (Dropbox is notoriously awful at this), and the lack of any sane mechanism for querying this "database" means that it's just "data", not a "database".

Or we could question whether attempting to come up with problems to solve in order to create a business is a good idea at all. Perhaps we should build businesses because that's the best context in which to execute a solution to an actual problem?

Breaking news: Companies attempt to maximise profit and charge for perceived value, not direct cost incurred. More news at 10.

Makes a fairly interesting point that seems obvious once you've read it, but which we actually don't have embedded as an assumption - that the level of user trust placed in us as developers is not matched by the level of care and responsibility which we actually feel when that trust is placed in us. Definitely some food for thought, and I think we need to take the entire issue much more seriously rather than just slapping anything together and forgetting about it.

The advantage of any programming language, framework, or library is that you know it already and it allows you to achieve things. I wouldn't personally advocate learning PHP today, but the idea that any language has intrinsic value divorced from its ability to achieve your purposes is mostly untrue.

A curious value proposition. Is it for encrypted communications between people who know about encryption? Why not then just use encrypted email through pre-established trust mechanisms?

Or is it for non-technical users who are paranoid about Facebook privacy, having ready something about it once? In which case, wouldn't some kind of encrypted privacy overlay for Facebook be more helpful?

It just seems painfully, painfully niche. I can't see how it could overcome both the traction problem that all social networks face (i.e., reaching critical mass - people are only on social networks because other people are there), as well as convincing people that this is something they need (existing social networks will try hard to convince people they do not need anything like this, because their privacy is already safe). Seems a very hard sell to me.

Genuinely good advice, but the prose wrapped around it is tedious and over-wrought. I think a lot of people will tl;dr this, so (spoiler alert!) the advice is basically to use Twitter to validate ideas by seeing if you get a follow-back rate of more than 10% from people in your target audience.

In fact, having re-read my own post from 2 years ago and found myself still agreeing with it, I find myself wanting to travel back in time to paste that link to the author of the linked article before he wrote it.

I'm sure many have tried, but language comparisons actually devolve into uselessness very quickly, because the things we can quantitatively measure and compare about languages are mostly not the things that people care about in practice. For example, I can tell you what classes of errors are possible in Javascript programs versus what errors are possible in Python programs versus what errors are possible in Haskell programs, but it doesn't really seem to affect peoples' language choices. Language comparisons tend to devolve very quickly into arguments about personal taste and little else. I wrote some thoughts on this subject a while ago: http://plsadventures.blogspot.com/2009/08/simple-patterns-fo...

I feel like this is what would happen if you took every language under the sun and asked people who had never used them to offer commentary. It's just full of strange gaps and claims about differences between languages that just aren't even really true any more, and yet misses issues like "memory safety" from the discussion of C vs. JVM-languages, for example.

[dead] 15 years ago

"Man with life-threatening health problems looks ill in photos. More news at 10".

OK, so I went back and re-read that paragraph twice more. I'm not sure if the claim is about abstract interpretation, model checking, or the particular problem domain, but I'm quite certain that Microsoft's tool can't claim novelty in implementing any of those, or even all three together.