7 ms·

This is the old "use the right tool for the job" cop-out. The original post went deeper than that. I would summarize it like this: can modern complex, large-sca

by blub 11y ago

This is the old "use the right tool for the job" cop-out. The original post went deeper than that. I would summarize it like this: can modern complex, large-scale web apps be built with the tools we have today, be they Python, Ruby or Javascript? Or do we need an entire new class of tools which have traditionally been used to build large scale systems in the past? It's a multi-faceted question of type systems, tooling, packaging, dependency resolution and others. And as web apps continue to evolve, my guess is that the current tools will be considered lacking. It used to be that picking "the right tool" meant choosing between Ruby, Python, PHP, JS. In the future it might mean using (gulp) Java + WebAssembly or a combination of other unusual tools. This would be quite game-changing for most web developers. ;)

emodendroket 11y ago
> The original post went deeper than that. I would summarize it like this: can modern complex, large-scale web apps be built with the tools we have today, be they Python, Ruby or Javascript? Well, clearly they can, because lots of people are doing it. Maybe some other tools would make it easier than it is now but it is certainly possible now.
- blub 11y ago
  With a wide interpretation of "can", the answer will be yes. But that's not a particularly interesting question to ask, as you've said it yourself. If X makes it 50% easier to create a complex product than LAMP, that's a huge difference.
mbell 11y ago
> The original post went deeper than that. If there was depth, I missed it. The only two points I got from it were 'I prefer static typing over duck typing' and 'avoid dependency hell'. The original post didn't add anything new to either argument and both have existed and been rehashed over and over again for decades.
- blub 11y ago
  The trick is to ignore everything until the "duck typing" picture including the picture. Then to pay attention to the last four paragraps.
  - mbell 11y ago
    There still isn't much there, and some of it is just unfounded. For example, while the author claims there are 'crazy levels of duck typing' in Ruby / Rails he provides no such evidence of it and as noted by recent work from Aaron Patterson the vast majority of calls sites even in a very large rails app are actually monomorhpic (https://www.youtube.com/watch?v=6Dkjus07d9Y https://www.youtube.com/watch?v=6Dkjus07d9Y). But more important than this cherry picked example is the complete lack of this type of technical discussion, which is why I find the post very shallow.
- collyw 11y ago
  And he didn't point out how any of his "todays languages" are any better at avoiding dependency hell.
  - weberc2 11y ago
    Go statically compiles everything into a single binary. I'm not sure what is meant by "dependency hell", but this at least simplifies the runtime story.
    - collyw 11y ago
      Fair enough. He would have done well to explain that. Java does the same. Is it considered tomorrows language? At the end of the day its another trade off between compiled and interpreted languages, and one thats been around for years.
      - weberc2 11y ago
        Java doesn't do this. There are tools that let you bundle all of your jar files, but even then, you typically have the JVM as a runtime dependency.
gavinpc 11y ago
The original post (not this OP) was clearly a response to Rich Hickey's talk "Simplicity Matters," which was given at a Ruby conference.[0] Particularly the part about "1,000 gems," which Hickey calls "hairballs" in the talk. I've started calling all packages hairballs since watching that. [1] https://www.youtube.com/watch?v=rI8tNMsozo0&t=15m39s https://www.youtube.com/watch?v=rI8tNMsozo0&t=15m39s
- askyourmother 11y ago
  To be fair, given the quality of the code from most Rails developers, the gems are more like turds than hairballs.
askyourmother 11y ago
Rails codebases do not age well, and are always unpleasant to work on. I never saw the same issue with django codebases of a similar age. Nor even ones from Perl or PHP frameworks either. No. It is a special combination of the shiny insecure magic of Rails, mixed with the happy meal mentality and abilities of most Rails developers.
- collyw 11y ago
  The last two codebases I have inherited in Python have been fairly poor. And the Java ones before that. I don't think its a language specific thing.
- ionforce 11y ago
  You've never seen a Perl or PHP codebase age poorly? That's unbelievable.
- goldbrick 11y ago
  Oh, you again. Never mind my earlier question. I see that you have some special, irrational vendetta against Rails.
carsongross 11y ago
can modern complex, large-scale web apps be built with the tools we have today, be they Python, Ruby or Javascript? They absolutely can be built using just Rails (or python) and HTML. I won't shill any harder about how, but it's not only possible, it's enjoyable and easy. I've done it.
- blub 11y ago
  Why not? I would be curious to see how people tackle large, complex web software in an efficient way - that is with tools support, not by fighting against them and working around inadequacies. Example: if the unit tests represent 50%+ of the code base, one is probably working around dynamic typing. And here's some examples of complex software for comparison: image editor, digital audio workstation, CAD, video conferencing, computer vision & imaging, office suite, large games (think DeusEx, not minesweeper). Not complex: almost anything CRUD
  - forgotpwtomain 11y ago
    > Example: if the unit tests represent 50%+ of the code base, one is probably working around dynamic typing Unit tests are checking a lot more than argument type.. I have no idea what environment you worked in, but the comment comes across as rather clueless.
    - lmm 11y ago
      Unit tests check a lot more than whether the argument is Int or String, but so do good type systems. I'd say your comment comes across as more clueless.
    - MustardTiger 11y ago
      A huge portion of unit tests are doing exactly that. Many people simply don't realize how many problems are actually type problems. Like null/nil/whatever as the most trivial example. It is more likely that your comment is made out of ignorance than the one you replied to.
    - blub 11y ago
collyw 11y ago
Actually I would put Ruby, Python and PHP and server side JS into the same category. Need something more performant, look at C or Java. JS has it's own niche on the front end, so you don't really have a choice there. Need concurrency, look at Erlang or GO.
- spdionis 11y ago
  This. For backend applications the difference between ruby/pyhon/php is negligible. Maybe node.js is a bit different. Don't forget about .NET along Java.
criddell 11y ago
> In the future it might mean using (gulp) Java + WebAssembly You know, after being out of the Java world for about ten years now, I'm starting to get the itch to use it again. I was one of those people that used to joke about programming in XML, but that's really just a layer of indirection which is often a good solution to a problem. It's a very nice language, is fast, and has so far not been destroyed by Oracle. Plus JavaFX may be ugly, gut it is a cross platform GUI toolkit that works.
- lmm 11y ago
  Let me take the opportunity to plug Scala, which gives you (better than) the expressiveness of Python or Ruby but with (better than) the safety of Java. (OCaml, F# or Haskell are other options in a similar quadrant).
  - criddell 11y ago
    Scala and Clojure are both on my list of things to investigate.
  - neverminder 11y ago
    Scala + Play Framework, which incidentally was inspired by Rails, however in my opinion is much more consistent amongst other things.
    - lmm 11y ago
      I don't actually like Play (its routing in particular is very ad-hoc and doesn't make good use of Scala's capabilities). I use Spray for JSON APIs and Wicket for HTML UIs.
    - narrator 11y ago
      I'd like to add that ScalaJS on top of Scala + Play is really a pleasure to work with for web applications. The integration with existing Javascript libraries is very smooth and Play/SBT transparently handles the transpiling when you reload a page.
  - 11y ago
deleted 11y ago
[deleted]
pjmlp 11y ago
> can modern complex, large-scale web apps be built with the tools we have today, be they Python, Ruby or Javascript? For me, after the experience working on a startup that used TCL using an approach similar to AOLserver back in the first .com wave, web apps are always built with JVM, .NET or any other JIT/AOT enabled language toolchain with JavaScript kept for its indisputable place on the browser.
smacktoward 11y ago
Has Rails ever been for "complex, large-scale web apps" though? My understanding of it has always been that it was for the vast majority of web apps, which are neither particularly complex nor particularly large-scale. Rails was there to help those projects get started easily and iterate rapidly. If your Rails app turned out to be a hit you'd probably need to rewrite it, but that was OK because (1) very few apps qualify as "hits" and (2) only apps that actually get written can become hits, and with Rails it was much easier to turn ideas into functioning code. Large-scale web apps have their own unique types of problems. New tools may be needed to cope with them, but that's a whole different thing than the problems Rails was created to solve.
matwood 11y ago
Is Java really that unusual of tool? Java 8 + Spring boot + Jooq is a simple and powerful tool to build backend services. There is already great tooling, libraries, and a wealth of information around solved problems. Dare I say, it is almost boring to build backend services with the above stack because it is so straight forward. Maybe that is why it is not used, I mean talked about :)

by blub 11y ago

emodendroket 11y ago

> The original post went deeper than that. I would summarize it like this: can modern complex, large-scale web apps be built with the tools we have today, be they Python, Ruby or Javascript? Well, clearly they can, because lots of people are doing it. Maybe some other tools would make it easier than it is now but it is certainly possible now.

blub 11y ago
With a wide interpretation of "can", the answer will be yes. But that's not a particularly interesting question to ask, as you've said it yourself. If X makes it 50% easier to create a complex product than LAMP, that's a huge difference.

mbell 11y ago

> The original post went deeper than that. If there was depth, I missed it. The only two points I got from it were 'I prefer static typing over duck typing' and 'avoid dependency hell'. The original post didn't add anything new to either argument and both have existed and been rehashed over and over again for decades.

blub 11y ago
The trick is to ignore everything until the "duck typing" picture including the picture. Then to pay attention to the last four paragraps.
- mbell 11y ago
  There still isn't much there, and some of it is just unfounded. For example, while the author claims there are 'crazy levels of duck typing' in Ruby / Rails he provides no such evidence of it and as noted by recent work from Aaron Patterson the vast majority of calls sites even in a very large rails app are actually monomorhpic (https://www.youtube.com/watch?v=6Dkjus07d9Y https://www.youtube.com/watch?v=6Dkjus07d9Y). But more important than this cherry picked example is the complete lack of this type of technical discussion, which is why I find the post very shallow.
collyw 11y ago
And he didn't point out how any of his "todays languages" are any better at avoiding dependency hell.
- weberc2 11y ago
  Go statically compiles everything into a single binary. I'm not sure what is meant by "dependency hell", but this at least simplifies the runtime story.
  - collyw 11y ago
    Fair enough. He would have done well to explain that. Java does the same. Is it considered tomorrows language? At the end of the day its another trade off between compiled and interpreted languages, and one thats been around for years.
    - weberc2 11y ago
      Java doesn't do this. There are tools that let you bundle all of your jar files, but even then, you typically have the JVM as a runtime dependency.

gavinpc 11y ago

The original post (not this OP) was clearly a response to Rich Hickey's talk "Simplicity Matters," which was given at a Ruby conference.[0] Particularly the part about "1,000 gems," which Hickey calls "hairballs" in the talk. I've started calling all packages hairballs since watching that. [1] https://www.youtube.com/watch?v=rI8tNMsozo0&t=15m39s https://www.youtube.com/watch?v=rI8tNMsozo0&t=15m39s

askyourmother 11y ago
To be fair, given the quality of the code from most Rails developers, the gems are more like turds than hairballs.

askyourmother 11y ago

Rails codebases do not age well, and are always unpleasant to work on. I never saw the same issue with django codebases of a similar age. Nor even ones from Perl or PHP frameworks either. No. It is a special combination of the shiny insecure magic of Rails, mixed with the happy meal mentality and abilities of most Rails developers.

collyw 11y ago
The last two codebases I have inherited in Python have been fairly poor. And the Java ones before that. I don't think its a language specific thing.
ionforce 11y ago
You've never seen a Perl or PHP codebase age poorly? That's unbelievable.
goldbrick 11y ago
Oh, you again. Never mind my earlier question. I see that you have some special, irrational vendetta against Rails.

carsongross 11y ago

can modern complex, large-scale web apps be built with the tools we have today, be they Python, Ruby or Javascript? They absolutely can be built using just Rails (or python) and HTML. I won't shill any harder about how, but it's not only possible, it's enjoyable and easy. I've done it.

blub 11y ago
Why not? I would be curious to see how people tackle large, complex web software in an efficient way - that is with tools support, not by fighting against them and working around inadequacies. Example: if the unit tests represent 50%+ of the code base, one is probably working around dynamic typing. And here's some examples of complex software for comparison: image editor, digital audio workstation, CAD, video conferencing, computer vision & imaging, office suite, large games (think DeusEx, not minesweeper). Not complex: almost anything CRUD
- forgotpwtomain 11y ago
  > Example: if the unit tests represent 50%+ of the code base, one is probably working around dynamic typing Unit tests are checking a lot more than argument type.. I have no idea what environment you worked in, but the comment comes across as rather clueless.
  - lmm 11y ago
    Unit tests check a lot more than whether the argument is Int or String, but so do good type systems. I'd say your comment comes across as more clueless.
  - MustardTiger 11y ago
    A huge portion of unit tests are doing exactly that. Many people simply don't realize how many problems are actually type problems. Like null/nil/whatever as the most trivial example. It is more likely that your comment is made out of ignorance than the one you replied to.
  - blub 11y ago

collyw 11y ago

Actually I would put Ruby, Python and PHP and server side JS into the same category. Need something more performant, look at C or Java. JS has it's own niche on the front end, so you don't really have a choice there. Need concurrency, look at Erlang or GO.

spdionis 11y ago
This. For backend applications the difference between ruby/pyhon/php is negligible. Maybe node.js is a bit different. Don't forget about .NET along Java.

criddell 11y ago

> In the future it might mean using (gulp) Java + WebAssembly You know, after being out of the Java world for about ten years now, I'm starting to get the itch to use it again. I was one of those people that used to joke about programming in XML, but that's really just a layer of indirection which is often a good solution to a problem. It's a very nice language, is fast, and has so far not been destroyed by Oracle. Plus JavaFX may be ugly, gut it is a cross platform GUI toolkit that works.

lmm 11y ago
Let me take the opportunity to plug Scala, which gives you (better than) the expressiveness of Python or Ruby but with (better than) the safety of Java. (OCaml, F# or Haskell are other options in a similar quadrant).
- criddell 11y ago
  Scala and Clojure are both on my list of things to investigate.
- neverminder 11y ago
  Scala + Play Framework, which incidentally was inspired by Rails, however in my opinion is much more consistent amongst other things.
  - lmm 11y ago
    I don't actually like Play (its routing in particular is very ad-hoc and doesn't make good use of Scala's capabilities). I use Spray for JSON APIs and Wicket for HTML UIs.
  - narrator 11y ago
    I'd like to add that ScalaJS on top of Scala + Play is really a pleasure to work with for web applications. The integration with existing Javascript libraries is very smooth and Play/SBT transparently handles the transpiling when you reload a page.
- 11y ago

deleted 11y ago

[deleted]

pjmlp 11y ago

> can modern complex, large-scale web apps be built with the tools we have today, be they Python, Ruby or Javascript? For me, after the experience working on a startup that used TCL using an approach similar to AOLserver back in the first .com wave, web apps are always built with JVM, .NET or any other JIT/AOT enabled language toolchain with JavaScript kept for its indisputable place on the browser.

smacktoward 11y ago

Has Rails ever been for "complex, large-scale web apps" though? My understanding of it has always been that it was for the vast majority of web apps, which are neither particularly complex nor particularly large-scale. Rails was there to help those projects get started easily and iterate rapidly. If your Rails app turned out to be a hit you'd probably need to rewrite it, but that was OK because (1) very few apps qualify as "hits" and (2) only apps that actually get written can become hits, and with Rails it was much easier to turn ideas into functioning code. Large-scale web apps have their own unique types of problems. New tools may be needed to cope with them, but that's a whole different thing than the problems Rails was created to solve.

matwood 11y ago

Is Java really that unusual of tool? Java 8 + Spring boot + Jooq is a simple and powerful tool to build backend services. There is already great tooling, libraries, and a wealth of information around solved problems. Dare I say, it is almost boring to build backend services with the above stack because it is so straight forward. Maybe that is why it is not used, I mean talked about :)