rdnetto

8 ms·

1.
by rdnetto 8y ago
Programming languages having rigid syntax is like English being limited to the Latin alphabet - the opportunities for creativity lie in the combinations of higher level structures.
2.
by rdnetto 8y ago
This is standard practice where I work due to SOX compliance. (No pushing directly to master, all PRs need at least one other person's approval). In practice it's not an issue, since PRs are good practice anyway.
3.
by rdnetto 9y ago
You know that OSX and Linux both use the same printer stack (CUPS) right?
4.
by rdnetto 9y ago
> C++ cannot be covered by package management in the same way interpreted languages are. The problem space is vastly more complex. It starts with optional language features that often get get disabled in projects (most often RTTI and exc
5.
by rdnetto 9y ago
A variation on this would be to put the database behind a service that abstracted over the schema, though that only works for basic CRUD queries and not complex aggregations. This service would probably evolve from the monolith.
6.
by rdnetto 9y ago
You can do that in Python by converting the list to a tuple before passing it in. The need for a defensive copy is unavoidable as long as you're using mutable data types though.
7.
by rdnetto 9y ago
You probably want to compress it as well - that can easily reduce the file size by an order of magnitude.
8.
by rdnetto 9y ago
Would be really great to see this make it's way into the language. Here are some ways I've found to work around its absence: * adding a match() function to a common base type. So if it could have subtypes Foo(x), Bar(y, z), then t
9.
by rdnetto 10y ago
I suspect the third function is the one for running the monad. It's different for each one, so it's not part of the type class, but you do need it to use a given monad. (Except IO, though even it has unsafePerformIO)
10.
by rdnetto 10y ago
I used it for a while, ended up switching to Haskell, which had a lot of similar benefits despite being so different. If you're going to use it, I highly recommend the D Programming Language (book). It's extremely well written, an
11.
by rdnetto 10y ago
It's worth noting you can implement something similar in OOP languages using Church encoding: http://blog.higher-order.com/blog/2009/08/21/structural-patt...
12.
by rdnetto 10y ago
> I can almost guarantee that code was not written by an inexperienced or low skill coder. > If it was, you'd have a large complex function that took large complex state as its input, and probably maintained some kind of hidden i
13.
by rdnetto 10y ago
A counter-point to this is that OOP languages lack support for ad-hoc polymorphism. i.e. the ability for third-party code to define an implementation of an interface for a pre-existing type. The two approaches used to work around this are t
14.
by rdnetto 10y ago
I have the same toaster and it is awesome. My favourite feature is that its Frozen button works perfectly, which is great if you don't have bread that often.
15.
by rdnetto 10y ago
IIRC, Panasonic owns the patent on inverters, but they definitely make a microwave with a simple knob interface, because I have one ( http://www.panasonic.com/au/consumer/household/microwave-ove... )
16.
by rdnetto 10y ago
That's not a bad answer though - it demonstrates you understand the value of those things we should have had years ago, and might include things which aren't being worked on yet (even though they should be).
17.
by rdnetto 10y ago
Haskell and Scala are pretty awesome at embedded DSLs, because of do-blocks. You can use them to bind some value to a symbol (i.e. assign a variable) inside the eDSL, which isn't possible in most languages. (Contrast this to, say, eD
18.
by rdnetto 10y ago
> I think you are confusing type errors with modeling errors, but that's very common. How would you distinguish between them? Strong/expressive type systems encode the modelling in a way which is mechanically verifiable. e.g. b
19.
by rdnetto 10y ago
> Static typing helps a lot to catch basic type errors but it is surely not the "Messiah" of code safety. I'd argue that type safety is only one benefit of strong types - the others being better documentation[1] and a desi