5 ms·

It’s a shame that people feel this way about Ruby. The thing about ruby and scripting languages like JavaScript is their nature make them very easy to dig in. T

It’s a shame that people feel this way about Ruby. The thing about ruby and scripting languages like JavaScript is their nature make them very easy to dig in. That’s why you see these scripting languages being used everywhere. The same problems mentioned here plagues JavaScript yet it’s the most used language on the web. I’ve personally built rails app that have been running for the last 5 years with clients using it to process millions of USD and I rarely have to touch it. And even now when I have to make changes it’s easy to fix and patch up because it was built right. Most founders who don’t understand development “need things done yesterday”. If your business doesn’t take into account technical debt you are going to skimp on things and cut corners. It’s not ruby’s fault. It’s the business owners job to understand development and the process of building risilient long lasting software and not put developers into impossible timeframes. From my experience business and marketing people who “need it now” don’t know what they are doing business wise too. Businesses take years to build. Nothing is ever needed “right now” if business is well planned and well executed. There is always enough time, and if there really isn’t technical debt is accounted for and fixed quickly. That said it’s also important that technical leadership constantly inform and communicate with business end regarding development time and the concept of technical debt. Don’t even get me started on business people who “need it now” based on “projections”, and then forget about everything they asked for the next day. Or “I need it now” “make it happen” to stroke their ego. When you find yourself blaming the tool look at yourself as an individual and look at your team.

gaius 9y ago
The same problems mentioned here plagues JavaScript yet it’s the most used language on the web. JS achieved popularity because it was the ONLY choice in its domain. That's a rarity in PLs, and can't be extrapolated to any other language that I can think of offhand.
- artellectual 9y ago
  NodeJS is a choice, not a compulsion like client side. Be sure to make that clear separation.
  - gaius 9y ago
    I can see the value in minimising the number of languages you need, and you're already constrained by the client, but I take your point. Node is an abomination, noone would choose it freely.
  - simias 9y ago
    Node is "Stockholm syndrome". Since you have to use JS for the web if you want to reduce code duplication and the number of languages you use you have to bring it on the backend.
    - mbrock 9y ago
      Out of all the dynamically typed scripting languages, I prefer JavaScript. Is there something horribly wrong with me? Linguistically, my second choice would be Scheme, but I still find JavaScript to be more ergonomic for most tasks. It's also way more familiar to more people, obviously, so I think it's a totally reasonable choice for a lot of tasks.
      - simias 9y ago
        I think Javascript is not as fundamentally unsound as, say, PHP. You can see that it was designed by people who had a clue about how languages are supposed to work. The big problem with Javascript is that conceptually it's closer to a functional language than C or Java, yet it opted for a C-style syntax with a bunch of hacks (semicolon insertion being arguably the biggest) so I find that its syntax doesn't really match the way it's used and you end up with rather clumsy looking code even for very idiomatic constructs. Not to mention the super weird type conversions. But that's rather subjective, IMO the biggest problem is simply the lack of a comprehensive standard library even for basic things. I'm not really a webdev but I have to maintain a web interface for one of our products, it uses JQuery, underscore.js and d3.js for various things. There's a significant overlap between these libraries when it comes to standards algorithms and DOM manipulation so you have to learn two or three ways to do the same thing depending on the situation. I shouldn't need external dependencies to have access to underscore.js's "map" or JQuery selectors. Coding in JS feels like coding in C if it was standardized without stdio.h and string.h. Have fun re-implementing strcat every time you need it.
- pjmlp 9y ago
  Some examples. - UNIX and C. - Android and Java - Windows and .NET/C++ - JME feature phones - iOS and Objective-C/Swift Or to taking it down to memory lane, - Burroughs and ESPOL/NEWP - IBM RISC systems, IBM zOS and PL/8 - IBM 400 and PL/S - Lilith and Modula-2 - Native Oberon and Oberon - UCSD and Pascal - Lisa, Mac OS and Object Pascal - Lisp Machines - Smalltalk workstations - Xerox Star and Mesa - SpinOS and Modula-3 - .... (plenty more to list)
  - distances 9y ago
    I'm not familiar with the older examples, but only feature phones from the first list are as tightly coupled as Web is with JavaScript. On all others platforms you can either run native code, or code compiled for the platform's default VM, or both.
    - pjmlp 9y ago
      Then by that way of thinking the Web is not tightly coupled with JavaScript, because you can use JavaScript as a target language on a compiler backend. The alternatives to the languages I listed, don't enjoy the same support to 100% of plaform APIs, and respective SDK tooling. Going outside the eco-system means manually writting FFI bindings, not being able to use the GUI designers if available, lack of debugging and profiling support at the same level as the platform tools.
  - porfirium 9y ago
    >Windows and .NET/C++ Not true. .NET is VB, C#, which are completely different from C++, and you can write a Windows application in almost any language imaginable.
    - pjmlp 9y ago
      .NET is VB, C#, F# and C++/CLI. Sure you can write a Windows application in anything else, but be prepared for a 2nd class experience, writing FFI bindings on your own for the Windows API, without access to the tools provided by Visual Studio.
raverbashing 9y ago
I can't change how integer division works globally by requiring a module in JS (as per the example in the article) JS has its own problems, but Ruby makes it extra easy to shoot yourself in the foot
- Doctor_Fegg 9y ago
  But just because it's easy doesn't mean it actually happens. My time is pretty much 50% Ruby, 50% JavaScript. "stdlib can be patched to do random stuff" is a complaint I've often heard about Ruby, but in practice, I've encountered it precisely once in the last five years (extlib breaking with recent Ruby because of a to_h conflict, IIRC). I've lost way, way more time than that to JS idiosyncrasies.
  - lloeki 9y ago
    > "stdlib can be patched to do random stuff" is a complaint I've often heard about Ruby, but in practice, I've encountered it precisely once in the last five years We've had something like 20 of those in the last year alone. 70% of those come from Rails, and some have been quite severe. Maybe it's tied to what we do which is definitely not a simple app, for which Ruby is not entirely the right one for the job but it's definitely not obviously the wrong one either. With years of business logic, tuning and bug fixing there are things you should never do[0], but even coming to terms with what Ruby is and what its limitations are after all these years in the trenches doesn't mean we can with absolute certainty avoid getting hit by structural damage coming from idiomatic flaws which we have clearly identified through proper root cause analysis to be endemic to the Ruby way (which includes a complete disregard for backwards compatibility, even when it can trivially be made so[1]). [0]: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... [1]: https://bugs.ruby-lang.org/issues/10085 https://bugs.ruby-lang.org/issues/10085
    - Doctor_Fegg 9y ago
      That's interesting - I don't use Rails so don't see that so much. (A lot of Ruby hate traditionally seems to be misdirected Rails hate.) There's perhaps an argument for "Ruby - the Good Parts"... but you could argue that it exists and it's called Crystal.
skeletal88 9y ago
JavaScript yet it’s the most used language on the web. It's the ONLY language on the web. If there were alternatives with a useful standard library and a way to define functions and objects that programmers of other languages are used to then the alternative would be more popular.

gaius 9y ago

The same problems mentioned here plagues JavaScript yet it’s the most used language on the web. JS achieved popularity because it was the ONLY choice in its domain. That's a rarity in PLs, and can't be extrapolated to any other language that I can think of offhand.

artellectual 9y ago
NodeJS is a choice, not a compulsion like client side. Be sure to make that clear separation.
- gaius 9y ago
  I can see the value in minimising the number of languages you need, and you're already constrained by the client, but I take your point. Node is an abomination, noone would choose it freely.
- simias 9y ago
  Node is "Stockholm syndrome". Since you have to use JS for the web if you want to reduce code duplication and the number of languages you use you have to bring it on the backend.
  - mbrock 9y ago
    Out of all the dynamically typed scripting languages, I prefer JavaScript. Is there something horribly wrong with me? Linguistically, my second choice would be Scheme, but I still find JavaScript to be more ergonomic for most tasks. It's also way more familiar to more people, obviously, so I think it's a totally reasonable choice for a lot of tasks.
    - simias 9y ago
      I think Javascript is not as fundamentally unsound as, say, PHP. You can see that it was designed by people who had a clue about how languages are supposed to work. The big problem with Javascript is that conceptually it's closer to a functional language than C or Java, yet it opted for a C-style syntax with a bunch of hacks (semicolon insertion being arguably the biggest) so I find that its syntax doesn't really match the way it's used and you end up with rather clumsy looking code even for very idiomatic constructs. Not to mention the super weird type conversions. But that's rather subjective, IMO the biggest problem is simply the lack of a comprehensive standard library even for basic things. I'm not really a webdev but I have to maintain a web interface for one of our products, it uses JQuery, underscore.js and d3.js for various things. There's a significant overlap between these libraries when it comes to standards algorithms and DOM manipulation so you have to learn two or three ways to do the same thing depending on the situation. I shouldn't need external dependencies to have access to underscore.js's "map" or JQuery selectors. Coding in JS feels like coding in C if it was standardized without stdio.h and string.h. Have fun re-implementing strcat every time you need it.
pjmlp 9y ago
Some examples. - UNIX and C. - Android and Java - Windows and .NET/C++ - JME feature phones - iOS and Objective-C/Swift Or to taking it down to memory lane, - Burroughs and ESPOL/NEWP - IBM RISC systems, IBM zOS and PL/8 - IBM 400 and PL/S - Lilith and Modula-2 - Native Oberon and Oberon - UCSD and Pascal - Lisa, Mac OS and Object Pascal - Lisp Machines - Smalltalk workstations - Xerox Star and Mesa - SpinOS and Modula-3 - .... (plenty more to list)
- distances 9y ago
  I'm not familiar with the older examples, but only feature phones from the first list are as tightly coupled as Web is with JavaScript. On all others platforms you can either run native code, or code compiled for the platform's default VM, or both.
  - pjmlp 9y ago
    Then by that way of thinking the Web is not tightly coupled with JavaScript, because you can use JavaScript as a target language on a compiler backend. The alternatives to the languages I listed, don't enjoy the same support to 100% of plaform APIs, and respective SDK tooling. Going outside the eco-system means manually writting FFI bindings, not being able to use the GUI designers if available, lack of debugging and profiling support at the same level as the platform tools.
- porfirium 9y ago
  >Windows and .NET/C++ Not true. .NET is VB, C#, which are completely different from C++, and you can write a Windows application in almost any language imaginable.
  - pjmlp 9y ago
    .NET is VB, C#, F# and C++/CLI. Sure you can write a Windows application in anything else, but be prepared for a 2nd class experience, writing FFI bindings on your own for the Windows API, without access to the tools provided by Visual Studio.

raverbashing 9y ago

I can't change how integer division works globally by requiring a module in JS (as per the example in the article) JS has its own problems, but Ruby makes it extra easy to shoot yourself in the foot

Doctor_Fegg 9y ago
But just because it's easy doesn't mean it actually happens. My time is pretty much 50% Ruby, 50% JavaScript. "stdlib can be patched to do random stuff" is a complaint I've often heard about Ruby, but in practice, I've encountered it precisely once in the last five years (extlib breaking with recent Ruby because of a to_h conflict, IIRC). I've lost way, way more time than that to JS idiosyncrasies.
- lloeki 9y ago
  > "stdlib can be patched to do random stuff" is a complaint I've often heard about Ruby, but in practice, I've encountered it precisely once in the last five years We've had something like 20 of those in the last year alone. 70% of those come from Rails, and some have been quite severe. Maybe it's tied to what we do which is definitely not a simple app, for which Ruby is not entirely the right one for the job but it's definitely not obviously the wrong one either. With years of business logic, tuning and bug fixing there are things you should never do[0], but even coming to terms with what Ruby is and what its limitations are after all these years in the trenches doesn't mean we can with absolute certainty avoid getting hit by structural damage coming from idiomatic flaws which we have clearly identified through proper root cause analysis to be endemic to the Ruby way (which includes a complete disregard for backwards compatibility, even when it can trivially be made so[1]). [0]: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... [1]: https://bugs.ruby-lang.org/issues/10085 https://bugs.ruby-lang.org/issues/10085
  - Doctor_Fegg 9y ago
    That's interesting - I don't use Rails so don't see that so much. (A lot of Ruby hate traditionally seems to be misdirected Rails hate.) There's perhaps an argument for "Ruby - the Good Parts"... but you could argue that it exists and it's called Crystal.

skeletal88 9y ago

JavaScript yet it’s the most used language on the web. It's the ONLY language on the web. If there were alternatives with a useful standard library and a way to define functions and objects that programmers of other languages are used to then the alternative would be more popular.