4 ms·

I also dismissed Java for a long time until a few years ago when I developed a mobile project in Java and unfortunately did encounter over-architecting and lack

by blub 10y ago

I also dismissed Java for a long time until a few years ago when I developed a mobile project in Java and unfortunately did encounter over-architecting and lack of interest in performance as expected. On the other hand, I can't say I disliked using the language, even if I found it quite restrictive. Java is a pragmatic tool, it's not about fun or expressiveness but making a team of average or better engineers build something that works. And it does that very well. Now that I've had that experience, I know it's not for me, but I can understand when a tool like Java makes sense. JavaScript vs anything else is not the same as C++ vs Java, because JavaScript is not an effective technology to build software applications in. It never was and likely won't become one. It has a weak type system and non-existant standard library. Must be run in a packaged browser. Anything UI-related must be done by using a document markup language and style sheets. The fact that any app developed in it is guaranteed to be inefficient and sluggish is just the cherry on top.

pcwalton 10y ago
> It has a weak type system Dynamic typing is useful. The "native" Objective-C is dynamically typed, for example. Static typing is useful too. If history has shown anything, it's shown that both dynamic typing and static typing have their places, and trying to argue that one is superior to the other in all circumstances is one of the most boring arguments imaginable. > non-existant standard library This is more or less a deliberate design choice, because there are many implementations of JS and that multiplies the probability of incompatibility. Consider the headaches that have arisen between Microsoft's STL and GNU's STL... > Must be run in a packaged browser Node? This is obviously false. > Anything UI-related must be done by using a document markup language It's an effective retained mode tree of nodes, with a whole lot more optimizations than any native toolkit I know of. (Look at how the childNodes array is implemented sometime, for example; no native toolkit does the kind of caching that browsers do...) > style sheets Style sheets are a great idea. They're becoming increasingly popular for native development nowadays (Qt, GTK, etc.) > The fact that any app developed in it is guaranteed to be inefficient and sluggish is just the cherry on top. I'm as much of a critic of current browser design as anyone, but this is mostly the fault of old browser designs. The Web platform has a lot more potential for performance than things like the Win32 API, as I've elaborated on in many other posts.
- blub 10y ago
  It's useful, but when that's the only tool one has, it becomes a liability. I like using both JS and Python where it makes sense, but building a medium-sized or large app in such languages is asking for trouble. Some teams make enough of an effort that they are able to deliver such an app. That should not be encouraged, but rather criticized as encouraging development practices. To be clear: they can do whatever they want in their projects. I have a problem when they recommend such methods to others, without being honest about the pitfalls and effort involved. Re standard library: the STL is currently working great! JS would kill to have something as stable and high quality as the STL. Re node: I am not aware of any desktop or mobile apps using node. Isn't that a server-side technology? Re markup: does it matter how much optimized it is and how much caching it does when in the end it's still slow? Re style sheets: they're great when used for styling, like in Qt (not sure what GTK is doing). But that doesn't scale when building widgets and doing positioning. pcwalton, web apps have had the potential to do X, Y and Z better than native apps for the past decade. At one point web developers need to talk less and deliver.
  - pcwalton 10y ago
    > I like using both JS and Python where it makes sense, but building a medium-sized or large app in such languages is asking for trouble. There have been tons of reliable large apps written in dynamically typed languages. This is, again, a tiresome argument. > the STL is currently working great! JS would kill to have something as stable and high quality as the STL. The STL took nearly a decade to get hash tables. And for years, users suffered from Microsoft and other vendors taking very different approaches to template expansion, causing no end of ifdef hell. JS never had such issues. > But that doesn't scale when building widgets and doing positioning. Huh? How does flexbox "not scale"? Positioning is just one aspect of style. > At one point web developers need to talk less and deliver I've been working on browsers for 7 years, and on most of those weekends, thanks.
    - blub 10y ago
      The tide seems to be turning against dynamic languages because developers are getting tired of the poor performance, fragility and maintenance difficulty. We just needed to see some innovation in the static typing camp: the transition from Objective-C to Swift is a great example. A typical app can be made pretty reliable with enough testing effort and a good process, so I'm not surprised that large apps have been written in dynamically typed languages, although I am now curious which apps you had in mind. Can't think of anything the scale of e.g. Photoshop, Oracle or Linux. Re STL: Really? :) I'll take missing hash-tables (dictionaries are fine) any day over no library. I don't know which period you're referring to with the ifdef hell, but at least for the past decade I can't think of any STL compatibility issues. Perhaps you can be more specific here? In any case, JS never had such issues because back then it was being used to make text blink. Now that it's facing more challenges we start seeing the issues. Re working on browsers: you're not a web developer. I will say though that Mozilla pushing this web-everything agenda is disappointing. The FirefoxOS lesson has not been learned...

by blub 10y ago

pcwalton 10y ago

> It has a weak type system Dynamic typing is useful. The "native" Objective-C is dynamically typed, for example. Static typing is useful too. If history has shown anything, it's shown that both dynamic typing and static typing have their places, and trying to argue that one is superior to the other in all circumstances is one of the most boring arguments imaginable. > non-existant standard library This is more or less a deliberate design choice, because there are many implementations of JS and that multiplies the probability of incompatibility. Consider the headaches that have arisen between Microsoft's STL and GNU's STL... > Must be run in a packaged browser Node? This is obviously false. > Anything UI-related must be done by using a document markup language It's an effective retained mode tree of nodes, with a whole lot more optimizations than any native toolkit I know of. (Look at how the childNodes array is implemented sometime, for example; no native toolkit does the kind of caching that browsers do...) > style sheets Style sheets are a great idea. They're becoming increasingly popular for native development nowadays (Qt, GTK, etc.) > The fact that any app developed in it is guaranteed to be inefficient and sluggish is just the cherry on top. I'm as much of a critic of current browser design as anyone, but this is mostly the fault of old browser designs. The Web platform has a lot more potential for performance than things like the Win32 API, as I've elaborated on in many other posts.

blub 10y ago
It's useful, but when that's the only tool one has, it becomes a liability. I like using both JS and Python where it makes sense, but building a medium-sized or large app in such languages is asking for trouble. Some teams make enough of an effort that they are able to deliver such an app. That should not be encouraged, but rather criticized as encouraging development practices. To be clear: they can do whatever they want in their projects. I have a problem when they recommend such methods to others, without being honest about the pitfalls and effort involved. Re standard library: the STL is currently working great! JS would kill to have something as stable and high quality as the STL. Re node: I am not aware of any desktop or mobile apps using node. Isn't that a server-side technology? Re markup: does it matter how much optimized it is and how much caching it does when in the end it's still slow? Re style sheets: they're great when used for styling, like in Qt (not sure what GTK is doing). But that doesn't scale when building widgets and doing positioning. pcwalton, web apps have had the potential to do X, Y and Z better than native apps for the past decade. At one point web developers need to talk less and deliver.
- pcwalton 10y ago
  > I like using both JS and Python where it makes sense, but building a medium-sized or large app in such languages is asking for trouble. There have been tons of reliable large apps written in dynamically typed languages. This is, again, a tiresome argument. > the STL is currently working great! JS would kill to have something as stable and high quality as the STL. The STL took nearly a decade to get hash tables. And for years, users suffered from Microsoft and other vendors taking very different approaches to template expansion, causing no end of ifdef hell. JS never had such issues. > But that doesn't scale when building widgets and doing positioning. Huh? How does flexbox "not scale"? Positioning is just one aspect of style. > At one point web developers need to talk less and deliver I've been working on browsers for 7 years, and on most of those weekends, thanks.
  - blub 10y ago
    The tide seems to be turning against dynamic languages because developers are getting tired of the poor performance, fragility and maintenance difficulty. We just needed to see some innovation in the static typing camp: the transition from Objective-C to Swift is a great example. A typical app can be made pretty reliable with enough testing effort and a good process, so I'm not surprised that large apps have been written in dynamically typed languages, although I am now curious which apps you had in mind. Can't think of anything the scale of e.g. Photoshop, Oracle or Linux. Re STL: Really? :) I'll take missing hash-tables (dictionaries are fine) any day over no library. I don't know which period you're referring to with the ifdef hell, but at least for the past decade I can't think of any STL compatibility issues. Perhaps you can be more specific here? In any case, JS never had such issues because back then it was being used to make text blink. Now that it's facing more challenges we start seeing the issues. Re working on browsers: you're not a web developer. I will say though that Mozilla pushing this web-everything agenda is disappointing. The FirefoxOS lesson has not been learned...