Hacker News new | past | comments | ask | show | jobs | submit login

Declarative is great, and I wish more people created clean declarative API with regular languages instead of writting yet another DSL.

But remember that the problem with a declarative syntax, is that it needs a runtime, which typically the end user doesn't touch. And if the runtime doesn't take into consideration one use case, the user is stuck. Don't forget to provide an escape hatch.




The other problem with declarative code on a runtime you didn't create is traditional forms of debugging go out the window. You can't set a breakpoint, or single step, or even printf debug declarative code directly, though you can peek behind the scenes a little if you control the runtime.


Yeah, you may debug the result of your declarations if introspection is ok, but god has mercy if the error is at the runtime level.


My impression of declarative programming is that it looks good in the "Hello, world" and other basic examples because you don't have to dip into the escape hatches. But when presented with real-world problems, you end up spending more time trying to get their framework to do what you want through the escape hatches than if you had just written your own program using a normal programming language and a well-designed library.


You can use a normal language to well design a declarative library. That's the point.


You're just throwing terms around here.

Something like Django or Rails, is no longer just a "declarative library" it's a framework. You're using their patterns, and you're limited to their escape hatches.


Never talked about frameworks.

Declarative is just a paradigm, you can use any language to design a declarative API.

Nox, pydantic and sqla are examples of it.


I'm not familiar enough with any of those tools to evaluate what you're saying. :shrug:


Declarative code doesn’t need a runtime if you have a compiler


Even if the language is compiled, you still need a runtime.

GHC compiles to native code, but there's still a runtime for instance to handle the garbage collection, to sort out the lazy evaluation, and to translate the blocking IO API at the haskell end into a non-blocking IO api at the kernel end.

I surely wouldn't want to be debugging my haskell code on a time budget by directly looking at the machine code that is running. I know some people do that and it can be quite illuminating, but the fact that I can debug haskell in its own terms is good.


You're conflating runtime with interpreter. Interpreter translates non-native code to native code, a runtime is what gives you garbage collection, the vm(ex: JVM), std libraries, etc.




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: