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.
That's a good way to put it. The ones who think it's an uncreative field are usually the ones who struggled through learning the syntax, and therefore assumed that's what the hard part of the job is.
Thinking that an unambiguous syntax implies it's not creative means something that is creative must have an ambiguous syntax. That's on its face absurd, yet a weirdly common belief.
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.
> 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 exceptions), continues with incompatible ABIs between compilers and even compiler revisions and does not stop with the presence of sometimes countless compiler flags for optional features and dependencies.
Haskell has most of the same problems and Stack handles them easily. Each source file in a project can use different language extensions, all transitive dependencies are compiled from source, and there's even CI to re run tests whenever a package is bumped.
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.
It sounds like you're describing ORM-as-API. Which, if you find you need it, great, but I wouldn't try to fool myself that introducing a mediating process like that is all that different from what the language/framework likely already provides (contemporary development frameworks are common). It's just ("just") abstracted to operate on network basis. Actually, what you describe sounds like a reduction in functionality from a non-API model.
Hopefully that parses as English, it's still morning for me.
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.
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 the signature would look like:
<T> T match(Function<X, T> foo, BiFunction<Y, Z, T> bar);
* in the cases where I don't have control over the common base type, I've written a builder pattern that constructs a sequence of predicate-function pairs and applies them appropriately. This looks like so:
new PatternMatchingHelper()
.append(Foo.class, foo -> doSomething(foo.x))
.append(Bar.class, bar -> doSomethingElse(bar.y, bar.z))
.otherwise(x -> fallbackValue())
.apply(objectOfUnknownType);
The main disadvantage here is that it doesn't work well with generics, because the class objects have raw types.
You could probably extend the second approach to get something close to the arbitrary predicates that pattern matching would provide, but the syntax wouldn't be nearly a clean as having it in the language.
You act as if what op described must be the entirety of their code base. What if pattern matching is just a small part of a larger problem better solved with Java?
It's not so easy to just choose another language; there might be hundreds of thousands of lines of Java already written. In that case it's better make the best of a bad situation by doing something like this, than not even trying.
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 written, and remains once of my favourite technical books.
