4 ms·

"'90s: an in-joke for the rest of us." -- Or maybe you are the VB equivalent of the 90s? Easy to use, and fast, but try to do anything large scale and it bec

by ardit33 19y ago

"'90s: an in-joke for the rest of us." -- Or maybe you are the VB equivalent of the 90s? Easy to use, and fast, but try to do anything large scale and it becomes a kludge. I am using both scripting (Lua), and Java for mobile development, and I can tell you that in large programs scripting languages start becoming a burden. If you are working on a small thing, or on something when only few people are involved (4 or less), scripting languages are great, but when it comes to larger applications it takes a very high level of disipline in the team, and higher calibre developers to produce bug free code. -- unfortunately not every company can afford high calibre developers, and have to settle with average programmers. In scripting languages, team member X, and modify a shared component, and team member Y sudenly sees his part of the code doing wierd things, or even failing silently. It is easy to break things appart and introduce bugs in scripting langauges. In java, if a method's signature get changed, you are going to see compilation errors allover the place that will force you to fix them. Plus, there is the dynamic languages performance penalty, that will always be there. I am not advocating Java, as I sweared my next job has to be "Java free", but as a static language (together with C#) it has good place. It allows average programmers to be somehow productive in large systems, where there are many people working at a code at the same time, something that is actually value creating.

tptacek 19y ago
I won't rehearse my "large system" credentials here, but I have them, and this meme that C++ and Java are somehow safer for large teams to work in is a joke. I've done large projects in Tcl (!) and in C++ (!$&#) and there are more ways to shoot your teammates in the feet with C++ than in Tcl; they just aren't first-class elements of the language. And C++ is universally regarded as a language for large system development. I won't rehearse my "high performance systems" credentials here, but I have them, and this meme that the speed penalty for dynamic languages is a problem is a joke. Reread my previous comment: I'm getting in between the processor and the native instruction pipeline in Ruby, and it is, I believe I said, the greatest thing ever. Belaboring the sentiment: the problem with the "fast systems language meme" is that it leaves you with the impression that the language is where speed comes from. No. It is trivially easy to write slow systems code in C: do everything off an interrupt, do 3 system calls per byte, demand-spawn a thread. The answer to fast systems is to find the bottlenecks and fastpath them. It is much easier to fastpath a bottleneck when a hash table of digraph structures is 2 lines of code instead of a 1.5mb compiled library with template headers that take 3 minutes just to parse. None of this is heresy. You can read it in "Expert C Programming: Deep C Secrets", which is the first C book lots of people ever read. Your design is where speed comes from. If method dispatch is a bottleneck, please don't waste time moving to C++: your design is fucked, and you are doing it wrong. Do it right. My heresy is that static type checking is white elephant. I've been doing this kind of work for going on 15 years now, and I can count on 1 hand the number of head-scratching bugs I've had due to type safety, and that includes 100kloc+ components built entirely around void* closures. The things that really fuck you in large systems are object lifecycle and concurrency.
- wanorris 19y ago
  > C++ is universally regarded as a language for large system development. Actually, C++ is a terrible language for large system development. Far worse than Ruby. Then again, I'm not entirely convinced that Ruby is a great language for large system development, either: monkeypatching in a 50-developer project = teh evil. Of course, you can at least solve the worst problems with Ruby with coding standards. C++ problems are more fundamental. > My heresy is that static type checking is white elephant. I've been doing this kind of work for going on 15 years now, and I can count on 1 hand the number of head-scratching bugs I've had due to type safety, and that includes 100kloc+ components built entirely around void* closures. The things that really fuck you in large systems are object lifecycle and concurrency. If you use a powerful static type system (i.e. neither Java's nor C#'s) intelligently, you can sidestep whole categories of problems simply with proper type declarations -- for example, by using different types for escaped and unescaped string data from users. In any case, the real reason that enterprises are more comfortable with Java and .Net than dynamic languages for major projects isn't speed, it's that the deployment and monitoring infrastructure is mature and well-understood. Obviously, many enormous websites have been deployed on dynamic languages, but enterprises have a much higher comfort level with the tools available for Java and .Net than the tools for doing this with Ruby, et alia. That's why you see a lot more enterprise traction for solutions like JRuby -- problem solved, as far as they're concerned.
  - tptacek 19y ago
    So, the answer to our problems is neither C++, nor Java, nor C#, but rather an unnammed (let me guess: Haskell) statically typed language that no large system has ever been built in.
    - wanorris 19y ago
      Actually, I think Scala and F# are good incremental solutions that can use existing infrastructure and approaches to scaling. The risks of moving to a language that can perform better static checks but retain the rest of an existing deployment stack are actually quite low. They also have the advantage of interoperating with dynamic languages such as JRuby, IronPython, and others to allow you to deploy a mixed static/dynamic solution and optimize for which language style is the best fit for particular parts of the solution.

by ardit33 19y ago

tptacek 19y ago

I won't rehearse my "large system" credentials here, but I have them, and this meme that C++ and Java are somehow safer for large teams to work in is a joke. I've done large projects in Tcl (!) and in C++ (!$&#) and there are more ways to shoot your teammates in the feet with C++ than in Tcl; they just aren't first-class elements of the language. And C++ is universally regarded as a language for large system development. I won't rehearse my "high performance systems" credentials here, but I have them, and this meme that the speed penalty for dynamic languages is a problem is a joke. Reread my previous comment: I'm getting in between the processor and the native instruction pipeline in Ruby, and it is, I believe I said, the greatest thing ever. Belaboring the sentiment: the problem with the "fast systems language meme" is that it leaves you with the impression that the language is where speed comes from. No. It is trivially easy to write slow systems code in C: do everything off an interrupt, do 3 system calls per byte, demand-spawn a thread. The answer to fast systems is to find the bottlenecks and fastpath them. It is much easier to fastpath a bottleneck when a hash table of digraph structures is 2 lines of code instead of a 1.5mb compiled library with template headers that take 3 minutes just to parse. None of this is heresy. You can read it in "Expert C Programming: Deep C Secrets", which is the first C book lots of people ever read. Your design is where speed comes from. If method dispatch is a bottleneck, please don't waste time moving to C++: your design is fucked, and you are doing it wrong. Do it right. My heresy is that static type checking is white elephant. I've been doing this kind of work for going on 15 years now, and I can count on 1 hand the number of head-scratching bugs I've had due to type safety, and that includes 100kloc+ components built entirely around void* closures. The things that really fuck you in large systems are object lifecycle and concurrency.

wanorris 19y ago
> C++ is universally regarded as a language for large system development. Actually, C++ is a terrible language for large system development. Far worse than Ruby. Then again, I'm not entirely convinced that Ruby is a great language for large system development, either: monkeypatching in a 50-developer project = teh evil. Of course, you can at least solve the worst problems with Ruby with coding standards. C++ problems are more fundamental. > My heresy is that static type checking is white elephant. I've been doing this kind of work for going on 15 years now, and I can count on 1 hand the number of head-scratching bugs I've had due to type safety, and that includes 100kloc+ components built entirely around void* closures. The things that really fuck you in large systems are object lifecycle and concurrency. If you use a powerful static type system (i.e. neither Java's nor C#'s) intelligently, you can sidestep whole categories of problems simply with proper type declarations -- for example, by using different types for escaped and unescaped string data from users. In any case, the real reason that enterprises are more comfortable with Java and .Net than dynamic languages for major projects isn't speed, it's that the deployment and monitoring infrastructure is mature and well-understood. Obviously, many enormous websites have been deployed on dynamic languages, but enterprises have a much higher comfort level with the tools available for Java and .Net than the tools for doing this with Ruby, et alia. That's why you see a lot more enterprise traction for solutions like JRuby -- problem solved, as far as they're concerned.
- tptacek 19y ago
  So, the answer to our problems is neither C++, nor Java, nor C#, but rather an unnammed (let me guess: Haskell) statically typed language that no large system has ever been built in.
  - wanorris 19y ago
    Actually, I think Scala and F# are good incremental solutions that can use existing infrastructure and approaches to scaling. The risks of moving to a language that can perform better static checks but retain the rest of an existing deployment stack are actually quite low. They also have the advantage of interoperating with dynamic languages such as JRuby, IronPython, and others to allow you to deploy a mixed static/dynamic solution and optimize for which language style is the best fit for particular parts of the solution.