zapov

Those are problems in MS Sql, certainly not in object relational DBs such as Postgres or Oracle. And its rather sad that instead of embracing that we ended up with Json as poor man replacement for such advanced usages. I guess non portability across DBs certainly doesnt help. I tried showing that 10 years ago: https://github.com/ngs-doo/revenj/ but it just resulted in confusion.

Its not just you: https://www.youtube.com/watch?v=lu4mH3Hmw2o

A much better description would be "distributing usage to others" instead of just "using". Which is much better analogy for what is going on here.

The impedance mismatch is not about having to translate, but being unable to translate. An yes, that problem exist with relational-only database, but not with PG where you can create composite types, can have arrays of composite types as a column and all other goodies which come with that.

I personally do not find useful to execute .NET code in PG, but technically you could do that.

As long as you can translate LINQ expressions to PG as you can most of them with Revenj you can avoid the pitfalls of mainstream ORMs.

Postgres is object-relational database, so it can certainly be used in such a way (and I use it like that most of the time).

But this is quite a niche usage of PG and there are little to zero tools supporting it.

I’m glad to see that binding data with document templates is slowly becoming used more often. I always saw it as a killer feature, and actually built one of my products around that idea way in 2011 [1].

Once you leave the simple use cases of just replacing tags it gets quite complicated, but you can build really complex documents that way [2].

  [1] http://templater.info
  [2] https://github.com/ngs-doo/templaterexamples

Here is an old post of mine about that: https://blog.dsl-platform.com/multiple-result-sets-alternati...

You can do even more advanced stuff in Postgres, but they've changed the rules to dissalow it since it much more faster than the the current best ones. Something about being fair to other frameworks...

But it's not. It's just the default/most popular one.

It's up from 2x slower than fastest Java one, as clearly shown in the links.

Gson best of the breed? Oh my :(

https://github.com/eishay/jvm-serializers/wiki

https://github.com/fabienrenaud/java-json-benchmark

https://github.com/kostya/benchmarks

well there is also https://www.techempower.com/benchmarks/#section=data-r13&hw=...

Point being when someone says something is faster without providing verifiable numbers... it should not really be taken seriously

fwiw https://www.enterprisedb.com/postgres-plus-edb-blog/marc-lin...

The great thing with LISTEN/NOTIFY is they work inside transaction boundry. This way you can get correct cache invalidation inside inside multiple table changes really easy. But if you cant use transactions that doesnt seem helpful.

Boon is not that fast. It only appears fast on some poorly constructed benchmarks due to some lazy benchmarketing optimizations.

https://github.com/fabienrenaud/java-json-benchmark

Well thats kind of to the point. DDD is all about investing into your core domain since that gives you a business advantage.

In reality domain experts are not available (if existant at all). You implement features in shortest path possible and most of the time never really refactor. Gap between domain and implementation widens... and if you are lucky at one point decide on rewrite which only works if your devs became domain experts themselves.

My solution to that problem is to write software with tools which make refactoring cheap and it's kind of working for me.

While I like DDD very much (created much tooling over last 10 years to help develop software in such a way), but if you move outside of useful implementations, you don't end up with much. Talking to domain experts, analyzing your domain... that's just a straw man arguments to sell DDD. Ubiquitous language is a good argument for DDD, but I don't see that practised a lot. There is often a noticeable disconnect between how experts talk about the system and the abstractions in the system which represent them.

Also, on technical level, while there are a lot of useful things in DDD (aggregate roots, value objects, repositories, ...) there is also a cargo-cult like notion what is a good way to develop software. And when you listen to "the experts" you often get a feeling they can fake the talk, but surely don't know how to walk.

My single question to see if someone is practicing DDD is: do you refactor your codebase on deeper insights? I'm yet to see someone say yes to that. Often you get excuses not to touch code which is working since refactoring large codebase is impractical/risky.

Abstractions and libraries are surely not the problem. The higher the abstraction the more opportunity for high level optimizations. And they always trump low level optimizations.

The problems are that people dont know how to optimize things or are blocked by imposed architecture.

For JVM most popular benchmark is https://github.com/eishay/jvm-serializers/wiki

They are probably dissatisfied with developer stance toward their RAD framework.

I'm sure various business apps can be built successfully on top of their Visual programming IDE, but even Microsoft has mostly abandoned that route.

But I dislike that even they propagate the lie that systems are slow when built on top of "High level language". That is mostly an optimization problem and you can often optimize well beyond what people would be willing to do in lower level language.

Too bad they didnt use DSL JSON instead of Jackson for JSON test. They would probably edge top C ones then.

Easy there tiger ;)

What does it even mean that something is string based?

Here: https://github.com/eishay/jvm-serializers/wiki a JVM bench where JSON is pretty competitive with binary formats [and results would be event better if project owners actually merged PRs ;( ]

But I find it highly valuable to have a single model representation as a source of truth. You can see how it works in practice here: https://github.com/ngs-doo/revenj

Also, there are no tools for describing DB schemas that way (except if you consider DB DDL such a schema). So my DSL is used as uniform data format. And it's not a problem of mapping between formats, but within the logic required to do such a mapping. It can't be expressed as a simple transformation, compiler is required to analyze and transform it appropriately in various scenarios. And if you want optimizations, good luck with "simple mapping".

So yeah, it's complicated, but it needs to be complicated to support simple modeling DSL. Otherwise you are better off with having several DB schemas, various POOs, Protobuf/Flatbuffer IDL etc...

When I say DSL I mean external DSL, not a fluent interface.

So an example of the problem I deal with is a database migration. Let's say we have an entity with a value

entity SqlTable { List<TableColumn> nestedTuple; }

value TableColumn { int i; }

and if I change column type in value object to long I want my compilers to prepare a DB migration with the appropriate SQL statements for the specific DB I use. Of course, there is nothing too complex about it, but it's not trivial either (in this case you have to prepare a second field, unnest the whole hierarchy to get to the nested field, copy it to new type and compact the hierarchy back again).

I find it costly since there are gazillion of such features. And when they start interacting with each other things gets messy.

I actually find compilers for transformation of DSL AST to target languages much more costly then designing the DSL syntax.

But that's probably because I don't think using templates for code generation is good enough. At least if you want to do something interesting with it.

Language workbenches cut down the cost of DSL design to minimum, but more interesting problem is providing valuable output from it.

Do you plan on improving Protobuf speed in Java? People don't expect it to be slower than JSON ;)

http://hperadin.github.io/jvm-serializers-report/report.html

You can use JSON only as codec, which can give you performance of Protobuf with much better debugability.

As someone with a "similar" platform, I too am rather surprised this end up on HN frontpage ;(

Few questions:

* how is your editor different from MPS (except being browser based)?

* how does your project compares to an implementation on top of language workbenches?

* do you think your assumption about time spent on a project is mostly Haskell related or is that for some specific types of projects?

* are you thinking about implementing some framework of your own or do you have some other in mind?

* do you plan on integrating with existing libraries or write your own implementation?

And comments:

* for me good IDE feels like semantic editor. I'm inclined to believe that text based editor can have all the good features of semantic editor and avoid most of the bad ones.

* while writing simple structures one time and reusing them vertically in a project is useful, it's doubtful that it's worth while. It becomes worth while only if you have project in multiple languages/technologies. But mostly if you can do refactoring automatically (even database schema migrations).

* try to explain your project better, this should help you with narrowing it's scope. Most of the people will try to fit it into some category they are familiar with so emphasize the distinctions.

Good luck! ;)

Well, you said that Postgres had data consistency errors (referencing Aphyr articles). This is not true (at least regarding that article).

Aphyr article about Postgres could be renamed to call-me-maybe-acid-db-over-the-network and could remain the same.

I read your post as FUD regarding Postgres.

That article has various issues, for example, calling Postgres commit protocol as a special case of two phase commit is not really correct. Postgres has 2pc: http://www.postgresql.org/docs/9.2/static/sql-prepare-transa... but that was not tested.

The described behavior is "expected" and "understood". Saying that "you should assume worst from your database" is not something I would ever use for describing DB with ACID semantics.