18 ms·

I agree with the author that abstractions should be optional, whenever possible. However, just because something is heavily abstracted doesn't mean it's a bad

I agree with the author that abstractions should be optional, whenever possible. However, just because something is heavily abstracted doesn't mean it's a bad approach, at least from a productivity standpoint. Without certain things being heavily abstracted, we'd go insane. Just as User.create(params[:user]) gets translated to thousands of lines of Ruby, so also CoolClass.new('foo', 3) gets translated to thousands of lines of C, and printf("It's %d degrees today in %s.\n", temperature, city); gets translated to thousands of lines of assembly. Are they all heavy abstractions? Yes. Is it oftentimes very nice to be able to use heavy abstractions? Also yes.

narag 10y ago
There was a recent article about Julia that discussed how a printf in C translate to very few instructions in assembler. Also I would like to point that "translates" is a little misleading word. There are two ways of implementing an abstraction from a higher level system to a lower level one. You can generate code or you can write a runtime framework that does the work dynamically. Although from the higher place both may seem the same, there's a huge difference between them that has consequences.
- smitherfield 10y ago
  >There was a recent article about Julia that discussed how a printf in C translate to very few instructions in assembler. I wouldn't doubt it; compilers have become amazing at optimizing. But printf is hundreds of lines of C, at very least: http://opensource.apple.com//source/Libc/Libc-1082.20.4/stdio/FreeBSD/vfprintf.c http://opensource.apple.com//source/Libc/Libc-1082.20.4/stdi...
  - narag 10y ago
    Well, hundreds is not the same as thousands ;-) And most important, a call is not the same as the implementation of the called function, my point to begin with, please see my comment in the context of yours.
    - smitherfield 10y ago
      Per cloc it's actually 1093 lines of C (plus some more in the printf.c file), and generally speaking hundreds of lines of C is the equivalent of thousands of lines of assembly. In any case, the complexity of the called function is exactly what we're discussing — it's why the author objects to "User.create(params[:user])"
      - deleted 10y ago
        [deleted]
- MegaDeKay 10y ago
  The link to that article is below. printf in C tranlates to a few lines of assembly in preparation for a call to sprintf. That in turn will have a lot more instructions in assembler. http://zverovich.net/2016/05/13/giving-up-on-julia.html http://zverovich.net/2016/05/13/giving-up-on-julia.html
  - hackerboos 10y ago
    Indeed and OP is mixing up language implementation and standard libs with a framework.
phamilton 10y ago
To me the point isn't so much separation of concerns as it is separation of side-effects. printf has a well design side effect (printing to stdout). Coolclass.new has an expectation of an instantiation of object in memory. If Coolclass.new also called an external service, then that would be a violation in my opinion. Thankfully, we generally don't do that. User.create is not only capable of tons of side effects (just like Coolclass.new) but it is encouraged to do so (via callbacks and such).

narag 10y ago

There was a recent article about Julia that discussed how a printf in C translate to very few instructions in assembler. Also I would like to point that "translates" is a little misleading word. There are two ways of implementing an abstraction from a higher level system to a lower level one. You can generate code or you can write a runtime framework that does the work dynamically. Although from the higher place both may seem the same, there's a huge difference between them that has consequences.

smitherfield 10y ago
>There was a recent article about Julia that discussed how a printf in C translate to very few instructions in assembler. I wouldn't doubt it; compilers have become amazing at optimizing. But printf is hundreds of lines of C, at very least: http://opensource.apple.com//source/Libc/Libc-1082.20.4/stdio/FreeBSD/vfprintf.c http://opensource.apple.com//source/Libc/Libc-1082.20.4/stdi...
- narag 10y ago
  Well, hundreds is not the same as thousands ;-) And most important, a call is not the same as the implementation of the called function, my point to begin with, please see my comment in the context of yours.
  - smitherfield 10y ago
    Per cloc it's actually 1093 lines of C (plus some more in the printf.c file), and generally speaking hundreds of lines of C is the equivalent of thousands of lines of assembly. In any case, the complexity of the called function is exactly what we're discussing — it's why the author objects to "User.create(params[:user])"
    - deleted 10y ago
      [deleted]
MegaDeKay 10y ago
The link to that article is below. printf in C tranlates to a few lines of assembly in preparation for a call to sprintf. That in turn will have a lot more instructions in assembler. http://zverovich.net/2016/05/13/giving-up-on-julia.html http://zverovich.net/2016/05/13/giving-up-on-julia.html
- hackerboos 10y ago
  Indeed and OP is mixing up language implementation and standard libs with a framework.

phamilton 10y ago

To me the point isn't so much separation of concerns as it is separation of side-effects. printf has a well design side effect (printing to stdout). Coolclass.new has an expectation of an instantiation of object in memory. If Coolclass.new also called an external service, then that would be a violation in my opinion. Thankfully, we generally don't do that. User.create is not only capable of tons of side effects (just like Coolclass.new) but it is encouraged to do so (via callbacks and such).