Live data from Hacker News

Electron considered harmful

drewdevault.com

241–250 of 256 posts

Re: Electron considered harmful

#241

Earlier quoted context omitted.

I couldn't agree more with this. Just the fact that functions are a first class type in JS already makes it better than many other languages. Another thing that JS is great at is the flexibility it provides: objects are very general and you can do almost anything with them. Anyone would care to explain why does JS take so much hate?

I can handle that. First off, it gets a lot of (undeserved) hate from the Java-type people who think they know what OO is, but don't (because Java isn't OO, or so says Kay, and even if it is, there's a whole lot of rubbish mixed in. For that matter, I don't think JS qualifies either, by Kay's definition, but it's closer). These are the people who say things like, "How can it be OO if it doesn't have classes?" and, "w…

One of the main benefits of OOP is of course "polymorphism" (abstract base classes, interfaces), so naming any concrete class a "strategy" does seem a bit redundant.

From what I have read by/about Kay, it sounds like his vision of OOP was very much about the actor (message queue) model, rather than (just?) a Simula 67 interface/protocol method table structure.

As for the goofy "nonsense evaluation" in JS, it is a bit unfortunate, but I guess I must just write less nonsense than some others, as this doesn't seem to be a real problem for me :-)

In fairness, the JS I write is client side, and it usually doesn't take very long to get to a state to test new code, as opposed to a long batch process.

Re: Electron considered harmful

#242

Earlier quoted context omitted.

I couldn't agree more with this. Just the fact that functions are a first class type in JS already makes it better than many other languages. Another thing that JS is great at is the flexibility it provides: objects are very general and you can do almost anything with them. Anyone would care to explain why does JS take so much hate?

http://softwareengineering.stackexchange.com/questions/22161... The answer doesn't really end up being static vs dynamic, but rather how dynamic languages often lack the other facilities that make programming in the large easier, and Eric Lippert uses js as an example. Companies with a lot of money at stake have spent a lot of money and effort on things that transpile to js. The people making these decisions are almo…

Part of the problem is education. Back in the day (70s, early 80s), many people were tackling hard computer problems (formerly known as "AI") with languages like Lisp (Scheme, et al), rather than Simula 67 (C++, Delphi, Java, et al). Not me, I was a student, but I did see that stuff.

Enter the microcomputer in the mid 80s, with its 16 bit memory model and single wimpy core. (ignoring 8 bit toys). Running a garbage collector on such meager machines wasn't practical, so malloc/new and free/destroy it is, then! (yes, the irony is precious when Java appears a decade later)

After the early 90s, the Simula programming model has been pretty much the only thing taught to developers - a few self-taught people perhaps aside - so it's the only way they think.

Trying to convince these people that large chunks of their logic should be immutable data, processed in a "one way path" (directed acyclic graph) through functions, some of which are built of or build other functions, and that input and output types (which can be traced backwards and often inferred rather easily) can be assembled "on the fly" makes no sense to them.

It's almost like standing on a box on the street corner and trying to preach at people in Greek. They don't understand a word you are saying. "Get these freaky cultists out of here!" :-)

Re: Electron considered harmful

#243

Earlier quoted context omitted.

I can handle that. First off, it gets a lot of (undeserved) hate from the Java-type people who think they know what OO is, but don't (because Java isn't OO, or so says Kay, and even if it is, there's a whole lot of rubbish mixed in. For that matter, I don't think JS qualifies either, by Kay's definition, but it's closer). These are the people who say things like, "How can it be OO if it doesn't have classes?" and, "w…

One of the main benefits of OOP is of course "polymorphism" (abstract base classes, interfaces), so naming any concrete class a "strategy" does seem a bit redundant. From what I have read by/about Kay, it sounds like his vision of OOP was very much about the actor (message queue) model, rather than (just?) a Simula 67 interface/protocol method table structure. As for the goofy "nonsense evaluation" in JS, it is a bit…

>One of the main benefits of OOP is of course "polymorphism" (abstract base classes, interfaces), so naming any concrete class a "strategy" does seem a bit redundant.

There are no abstract classes in JS: there doesn't need to be.

Anyways, that's not what I mean: I was talking about the Strategy design pattern, which is actually a way of implementing higher order functions in languages that don't have them: thus, implementing classes for it in JS would be very silly indeed.

As for Kay's vision of OO, it involves not only everything being an object, but extreme late binding. Java has neither.

Re: Electron considered harmful

#244

Earlier quoted context omitted.

http://softwareengineering.stackexchange.com/questions/22161... The answer doesn't really end up being static vs dynamic, but rather how dynamic languages often lack the other facilities that make programming in the large easier, and Eric Lippert uses js as an example. Companies with a lot of money at stake have spent a lot of money and effort on things that transpile to js. The people making these decisions are almo…

Part of the problem is education. Back in the day (70s, early 80s), many people were tackling hard computer problems (formerly known as "AI") with languages like Lisp (Scheme, et al), rather than Simula 67 (C++, Delphi, Java, et al). Not me, I was a student, but I did see that stuff. Enter the microcomputer in the mid 80s, with its 16 bit memory model and single wimpy core. (ignoring 8 bit toys). Running a garbage co…

Oh, yes.

By the way, there is nothing like Scheme + Emacs for interactive development. You can write functions, execute a buffer, and perform your data manipulations in real time, patching your functions as you go.

It's freaking magic.

Re: Electron considered harmful

#245

Earlier quoted context omitted.

Sooo... people don't like JS because 1) it's dynamically typed, and 2) they don't like JS? >They don't care if first class functions are sexy. It's not about being sexy (and believe me: first class functions aren't): it's about getting a very useful feature right, something many languages seem to have trouble with, despite the fact that Lisp (and ALGOL, IIRC) got it right in the 50s.

Algol (1960s) had no garbage collection (that I know of), so any "closure-like" data captured by a function/procedure reference had to still be on the call stack. Otherwise, you certainly had first class functions, just not always with any external state captured. https://en.wikipedia.org/wiki/Man_or_boy_test I suspect TurboPascal was in the "boy" camp, in that a reference to a function (or procedure) would not have…

Ah. I don't know all that much about ALGOL. Dijkstra said it was great, but I don't trust his opinion.

Re: Electron considered harmful

#246

Earlier quoted context omitted.

One of the main benefits of OOP is of course "polymorphism" (abstract base classes, interfaces), so naming any concrete class a "strategy" does seem a bit redundant. From what I have read by/about Kay, it sounds like his vision of OOP was very much about the actor (message queue) model, rather than (just?) a Simula 67 interface/protocol method table structure. As for the goofy "nonsense evaluation" in JS, it is a bit…

>One of the main benefits of OOP is of course "polymorphism" (abstract base classes, interfaces), so naming any concrete class a "strategy" does seem a bit redundant. There are no abstract classes in JS: there doesn't need to be. Anyways, that's not what I mean: I was talking about the Strategy design pattern, which is actually a way of implementing higher order functions in languages that don't have them: thus, impl…

OK, gotcha. Somehow, I thought "strategy" was more general than just a single method/function to plug in. (confession: I have the GoF book, but don't remember every section)

I think one of the best points PG (of YC) ever made was about programmers thinking in a particular language. "If Blub doesn't do it, you don't need it" (paraphrasing). Convincing the C++/Java/C# fans they need other features sometimes is quite hard.

Re: Electron considered harmful

#247

Earlier quoted context omitted.

http://softwareengineering.stackexchange.com/questions/22161... The answer doesn't really end up being static vs dynamic, but rather how dynamic languages often lack the other facilities that make programming in the large easier, and Eric Lippert uses js as an example. Companies with a lot of money at stake have spent a lot of money and effort on things that transpile to js. The people making these decisions are almo…

Sooo... people don't like JS because 1) it's dynamically typed, and 2) they don't like JS? >They don't care if first class functions are sexy. It's not about being sexy (and believe me: first class functions aren't): it's about getting a very useful feature right, something many languages seem to have trouble with, despite the fact that Lisp (and ALGOL, IIRC) got it right in the 50s.

Sorry but this reply is just kind of vacuous given the link I posted. Eric Lippert gives a pretty detailed, neutral, blow by blow summary of the issues working with js at scale. And he quite specifically says that dynamic typing is not intrinsically the problem, just that dynamic typing tends to be correlated with other things that are a problem. He specifically mentions things like error handling. Did you even read the link?

I think your attitude is more that nothing is really bad with js relative to other languages, more so than actually trying to understand why it draws a lot of criticism, which is what you claimed and what I tried to link to.

Re: Electron considered harmful

#248
post #236

Earlier quoted context omitted.

Building an app once for each platform is not economically viable for a lot of teams, 'serious' or otherwise.

Yes, but it's not Cocoa's problem.

It's Cocoa's problem because people stop using it for that reason. A toolkit no-one uses is a failure.

Re: Electron considered harmful

#249

Earlier quoted context omitted.

You are missing this part: nor are types associated with properties. Ruby and Python do not fit it.

You can assign values of different types to the same property in those languages, no?

Types dictate¹ what properties are available.

1 - Or, in the case of Python, mostly dictate.

Re: Electron considered harmful

#250

Earlier quoted context omitted.

Sooo... people don't like JS because 1) it's dynamically typed, and 2) they don't like JS? >They don't care if first class functions are sexy. It's not about being sexy (and believe me: first class functions aren't): it's about getting a very useful feature right, something many languages seem to have trouble with, despite the fact that Lisp (and ALGOL, IIRC) got it right in the 50s.

Sorry but this reply is just kind of vacuous given the link I posted. Eric Lippert gives a pretty detailed, neutral, blow by blow summary of the issues working with js at scale. And he quite specifically says that dynamic typing is not intrinsically the problem, just that dynamic typing tends to be correlated with other things that are a problem. He specifically mentions things like error handling. Did you even read…

I read it. It assumes mutable OOP. Yes, "those people" need a safe place to play so they don't hurt themselves :-)

(I'm ignoring the error handling thing, as I have not done enough server side JS to have a good feel for how the Node API handles things like I/O failures)

IDEs are starting to have better support for Javascript (or similar dynamic/functional languages). In the near future, the IDEs should effectively have type inference. Once you relegate (mutable) OOP to a tool of last resort, and embrace immutable value objects plus (higher order) functions as your primary methodology, you get the automated error checking and much less drivel to read through during maintenance.

OTOH, I suppose this means the dynamic/FP languages will remain a productivity lever for motivated "experts" only, sadly. At least until there is enough butt-kicking in the market that Java (and its ilk) will be displaced as was COBOL before it. COBOL was "safe" and fast, but we finally reached a tipping point were it was too painfully obvious that it simply wasted too much time writing and reading it.

Post reply on HN