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.
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.
You know that OSX and Linux both use the same printer stack (CUPS) right?
> 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…
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…
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.
You probably want to compress it as well - that can easily reduce the file size by an order of magnitude.
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,…
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)
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…
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...
> 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…
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…
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.
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...)
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).
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…
> 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…
> 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…
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.
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.
You know that OSX and Linux both use the same printer stack (CUPS) right?
> 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…
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…
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.
You probably want to compress it as well - that can easily reduce the file size by an order of magnitude.
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,…
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)
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…
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...
> 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…
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…
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.
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...)
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).
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…
> 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…
> 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…