11 ms·

The equivalent in C would then be replacing #include <math.h> and "-lm" with #include <sin.h> #include <cos.h> #include <tan.h> #include <sinh.h> … and "-

by drauh 11y ago

The equivalent in C would then be replacing #include <math.h> and "-lm" with #include <sin.h> #include <cos.h> #include <tan.h> #include <sinh.h> … and "-lsin -lcos -ltan -lsinh …" Which is nuts no matter what language you are coding in.

e12e 11y ago
Oh, but javascript is dynamically typed, so it doesn't matter if your sin-module works with a different kind of arbitrary-precision decimal number module than your geolocation module, your cosine module or your openg-draw-triangle or opengl-draw-circle modules... /sarcasm
- gaius 11y ago
  It's not sarcasm if it's true!
  - tfm 11y ago
    OT but apt to this community - That's what I thought, but after a lifetime of 'correcting' people, I looked up the definition of sarcasm. Turns out that the sarcastic-sounding truths I'd been deploying for decades were indeed by-the-book sarcasm rather than 'I can't believe it's not sarcasm'. Key quote from brilliant word-talking-guy Henry Fowler: "Sarcasm does not necessarily involve irony [but it often does] ... The essence of sarcasm is the intention of giving pain by (ironical or other) bitter words." So, we circle back to Node.js by way of pain and bitterness. Sounds about right.
imron 11y ago
The difference with C is that with a good linker, functions you don't call are removed from the resulting binary (or are maybe not even in the binary if you are dynamically linking to the c runtime). With javascript however, if you import a hypothetical "math.js" instead of just "sin.js", "cos.js" or "tan.js", then you'll need to download and evaluate a whole bunch of javascript that you might not need. I'm not defending javascript, because I dislike it and avoid it where possible, but I can understand some of the reasons why short, specific modules came about.
- TickleSteve 11y ago
  what you describe is the "-flto" option in GCC and I believe the equivalent in JS is donr by Google Closure compiler.
  - ansgri 11y ago
    He described not Link Time Optimization (-flto), but the very basic linker functionality: to only include required functions. C/C++ has a weird compilation model where each source file is translated to machine code separately, with placeholders for unknown function addresses. Thus it is trivial to take only required functions. -flto, on the other hand, allows to reverse this process to allow interprocedural optimization across different translation units.
    - TickleSteve 11y ago
      He's describing unused-function removal... which "-flto" is the correct option to use (on GCC). like you say, without this, removal is only performed within the compilation-unit, but my statement was quite correct. @majewsky: what you're describing is more akin to "-ffunction-sections" and "-gc-sections" which will split ewach function into a separate section and garbage-collect those sections.
    - majewsky 11y ago
      @TickleSteve below me: "without this, removal is only performed within the compilation-unit" Not quite. When you link to a static library (.a) with lots of .o object files in it, only those object files will be linked that are actually used by your program. I first learned about this when I looked at the source of dietlibc, and wondered about every function being in a separate file. That enables the aforementioned trivial optimization, even without -flto.
      - ansgri 11y ago
        Thanks for the correction. Didn't know that.
      - 11y ago
MaulingMonkey 11y ago
> #include <sin.h> #include <cos.h> #include <tan.h> #include <sinh.h> I've written worse - at least those cover multiple variations each (or overloads in C++ for float/double/std::complex?/...) While I'm not a fan of the enforced java route of 1 file = 1 class, I do trend towards 1 file ~ 1 (main, public) thing - which might be a single function with no overloads. #include <string_left_pad.h>? Better than #include <everything.h>, which I see far too often... I don't have to figure out which grouping of things my coworkers decided to throw something into if I can just #include by name - whereas aggregation headers more often than not will trigger a full project file-system search. Unnecessary #include s don't accumulate nearly so much when you don't have to audit 100 functions to see if any of them use features from said header. I don't trigger a rebuild of everything when the only things that #include stuff actually need it. Lots of benefits! > and "-lsin -lcos -ltan -lsinh …" Or sin.o, cos.o, tan.o, sinh.o... which suddenly sounds a lot more reasonable. I wouldn't bat an eye at string_left_pad.o either. Sure, I want to use tools to simplify the use of those micro-modules by aggregating them into libraries for convenience. But that's not a knock against micro-modules - just their packaging and tooling. Rewind time back far enough and I would've been manually specifying .o files on the command line and kvetching too...
- nradov 11y ago
  Java doesn't enforce 1 file = 1 class but rather 1 file = 1 public class, which is exactly what you asked for. You can put as many private classes in the file as you want.
  - brandon73 11y ago
    This isn't accurate either. Java does not enforce 1 file = 1 public class but rather 1 file = 1 public top-level class. For example this is totally legit: // ClassA.java public class ClassA { public static class ClassA_Inner_Public_Static { } public class ClassA_Inner_Public { } } // ClassB.java public class ClassB { ClassA classa = new ClassA(); ClassA_Inner_Public classA_Inner_Public = new ClassA().new ClassA_Inner_Public(); ClassA_Inner_Public_Static classA_Inner_Public_Static = new ClassA_Inner_Public_Static(); }
kvakvs 11y ago
You can get approximate feeling if you get rid of a library and don't use -lm but instead unpack it to separate .o files and link against each.
lmm 11y ago
So have libmath depend on libsin, libcos, libtan and libsinh. People who want the kitchen-sink version can get it. People who want just one specific submodule can depend on that. What's not to like?
- afandian 11y ago
  Having a full set of math functions isn't kitchen sink, it's the right level of granularity for a module. If I want math functions I really want them to all be written by the same author and kept in lock-step as a unit. Why don't you want the whole module? Because it's bloat? Surely it's far less bloat than one submodule per function?
  - shawabawa3 11y ago
    A lot of javascript is going to be deployed to a website. Every line of code that isn't used is bytes you're sending to every user unnecessarily > Surely it's far less bloat than one submodule per function? How is that bloat? It's the same LoC whether it's 1000 modules or 1 after it's been compiled/minified
    - afandian 11y ago
      Bloat in the source code, build system, dependency management, overheads per submodule, complexity. I'm not arguing that there shouldn't be a math module but that you shouldn't split it up into such (imho) crazy small parts. Closure Compiler can remove any unused functions.
      - lmm 11y ago
        It's not bloat in the source code - if you don't care which pieces you depend on you declare a dependency on math, if you do care you list the specific pieces. It shouldn't be (impactful) bloat or overhead in the build system or dependency management. That stuff should just handle it. Most of the time you don't care and can just declare the dependency on math and let the closure compiler handle it. But sometimes it might be really important that a project only used cos and not sinh, in which case you want to enforce that.

by drauh 11y ago

e12e 11y ago

Oh, but javascript is dynamically typed, so it doesn't matter if your sin-module works with a different kind of arbitrary-precision decimal number module than your geolocation module, your cosine module or your openg-draw-triangle or opengl-draw-circle modules... /sarcasm

gaius 11y ago
It's not sarcasm if it's true!
- tfm 11y ago
  OT but apt to this community - That's what I thought, but after a lifetime of 'correcting' people, I looked up the definition of sarcasm. Turns out that the sarcastic-sounding truths I'd been deploying for decades were indeed by-the-book sarcasm rather than 'I can't believe it's not sarcasm'. Key quote from brilliant word-talking-guy Henry Fowler: "Sarcasm does not necessarily involve irony [but it often does] ... The essence of sarcasm is the intention of giving pain by (ironical or other) bitter words." So, we circle back to Node.js by way of pain and bitterness. Sounds about right.

imron 11y ago

The difference with C is that with a good linker, functions you don't call are removed from the resulting binary (or are maybe not even in the binary if you are dynamically linking to the c runtime). With javascript however, if you import a hypothetical "math.js" instead of just "sin.js", "cos.js" or "tan.js", then you'll need to download and evaluate a whole bunch of javascript that you might not need. I'm not defending javascript, because I dislike it and avoid it where possible, but I can understand some of the reasons why short, specific modules came about.

TickleSteve 11y ago
what you describe is the "-flto" option in GCC and I believe the equivalent in JS is donr by Google Closure compiler.
- ansgri 11y ago
  He described not Link Time Optimization (-flto), but the very basic linker functionality: to only include required functions. C/C++ has a weird compilation model where each source file is translated to machine code separately, with placeholders for unknown function addresses. Thus it is trivial to take only required functions. -flto, on the other hand, allows to reverse this process to allow interprocedural optimization across different translation units.
  - TickleSteve 11y ago
    He's describing unused-function removal... which "-flto" is the correct option to use (on GCC). like you say, without this, removal is only performed within the compilation-unit, but my statement was quite correct. @majewsky: what you're describing is more akin to "-ffunction-sections" and "-gc-sections" which will split ewach function into a separate section and garbage-collect those sections.
  - majewsky 11y ago
    @TickleSteve below me: "without this, removal is only performed within the compilation-unit" Not quite. When you link to a static library (.a) with lots of .o object files in it, only those object files will be linked that are actually used by your program. I first learned about this when I looked at the source of dietlibc, and wondered about every function being in a separate file. That enables the aforementioned trivial optimization, even without -flto.
    - ansgri 11y ago
      Thanks for the correction. Didn't know that.
    - 11y ago

MaulingMonkey 11y ago

> #include <sin.h> #include <cos.h> #include <tan.h> #include <sinh.h> I've written worse - at least those cover multiple variations each (or overloads in C++ for float/double/std::complex?/...) While I'm not a fan of the enforced java route of 1 file = 1 class, I do trend towards 1 file ~ 1 (main, public) thing - which might be a single function with no overloads. #include <string_left_pad.h>? Better than #include <everything.h>, which I see far too often... I don't have to figure out which grouping of things my coworkers decided to throw something into if I can just #include by name - whereas aggregation headers more often than not will trigger a full project file-system search. Unnecessary #include s don't accumulate nearly so much when you don't have to audit 100 functions to see if any of them use features from said header. I don't trigger a rebuild of everything when the only things that #include stuff actually need it. Lots of benefits! > and "-lsin -lcos -ltan -lsinh …" Or sin.o, cos.o, tan.o, sinh.o... which suddenly sounds a lot more reasonable. I wouldn't bat an eye at string_left_pad.o either. Sure, I want to use tools to simplify the use of those micro-modules by aggregating them into libraries for convenience. But that's not a knock against micro-modules - just their packaging and tooling. Rewind time back far enough and I would've been manually specifying .o files on the command line and kvetching too...

nradov 11y ago
Java doesn't enforce 1 file = 1 class but rather 1 file = 1 public class, which is exactly what you asked for. You can put as many private classes in the file as you want.
- brandon73 11y ago
  This isn't accurate either. Java does not enforce 1 file = 1 public class but rather 1 file = 1 public top-level class. For example this is totally legit: // ClassA.java public class ClassA { public static class ClassA_Inner_Public_Static { } public class ClassA_Inner_Public { } } // ClassB.java public class ClassB { ClassA classa = new ClassA(); ClassA_Inner_Public classA_Inner_Public = new ClassA().new ClassA_Inner_Public(); ClassA_Inner_Public_Static classA_Inner_Public_Static = new ClassA_Inner_Public_Static(); }

kvakvs 11y ago

You can get approximate feeling if you get rid of a library and don't use -lm but instead unpack it to separate .o files and link against each.

lmm 11y ago

So have libmath depend on libsin, libcos, libtan and libsinh. People who want the kitchen-sink version can get it. People who want just one specific submodule can depend on that. What's not to like?

afandian 11y ago
Having a full set of math functions isn't kitchen sink, it's the right level of granularity for a module. If I want math functions I really want them to all be written by the same author and kept in lock-step as a unit. Why don't you want the whole module? Because it's bloat? Surely it's far less bloat than one submodule per function?
- shawabawa3 11y ago
  A lot of javascript is going to be deployed to a website. Every line of code that isn't used is bytes you're sending to every user unnecessarily > Surely it's far less bloat than one submodule per function? How is that bloat? It's the same LoC whether it's 1000 modules or 1 after it's been compiled/minified
  - afandian 11y ago
    Bloat in the source code, build system, dependency management, overheads per submodule, complexity. I'm not arguing that there shouldn't be a math module but that you shouldn't split it up into such (imho) crazy small parts. Closure Compiler can remove any unused functions.
    - lmm 11y ago
      It's not bloat in the source code - if you don't care which pieces you depend on you declare a dependency on math, if you do care you list the specific pieces. It shouldn't be (impactful) bloat or overhead in the build system or dependency management. That stuff should just handle it. Most of the time you don't care and can just declare the dependency on math and let the closure compiler handle it. But sometimes it might be really important that a project only used cos and not sinh, in which case you want to enforce that.