Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JavaScript is Good, Actually

ashfurrow.com

Post reply on HN
Print view View original

271–280 of 369 posts

Re: JavaScript is Good, Actually

#271

Post by slikts »

cpburns2009 wrote: post #217
egeozcan wrote: post #154

Earlier quoted context omitted.

> So where I would normally tell people who boo php to use whatever language they prefer, and get over it, that's not possible with js. Maybe 5 years ago. For nowadays, I beg to differ: https://github.com/jashkenas/coffeescript/wiki/list-of-langu... A significant amount of the choices there produce generally better-performing code than the hand-written JS, there's also the WebAssembly.

While technically true, don't you still have to debug and diagnose issues from the generated JavaScript? I'd love to write front-end code in anything else, but if I have to know exactly how it gets converted to JavaScript it kind of defeats the point.

Elm stands out in this regard, as it gives fairly robust guarantees of no runtime errors, so the debugging you'll do when working with Elm will almost always be limited to its compiler or Elm Debugger. The price to pay for this is limited interoperability with JS, but it may be acceptable to trade interop for type safety, depending on the use case.

Generally, the alt-js languages provide 'source maps' so that developer tools know to map errors in the 'transpiled' code to their source, and it's possible to avoid JS to a practical degree.

Re: JavaScript is Good, Actually

#272

Post by muddyrivers »

cdelsolar wrote: post #247
yedava wrote: post #223

Code spends most of its time being in production and not in development. During that time in production, developers will leave the team, bugs will show up, major enhancements will be made. So it is important that the codebase is easy to reason about, easy to refactor and easy to debug. If you take a language like Java and an IDE like Eclipse or Intellij IDEA, it is trivial to find from where a particular piece of cod…

This is a giant overgeneralization. If you are using Redux, for example, you _can_ easily tell most of the time what functions get called and in what context, because data flow is unidirectional and easy to reason about. If you're using an old massive tangle of spaghetti code, it is much more difficult, yes.

You can have very messy code with an excellent language. You can also have beautiful code with a poorly designed language. Let's do a thought experiments. Have a pool of SWEs fresh out of school. Divide them into groups. Each group is given a language they are not familiar with. The pool of languages will include both commonly regarded good ones, OK ones, and bad ones. Ask the groups to do a middle-sized project for 3~6 months independently. Then we compile the projects, analyze their code quality. If the pool of SWEs are big enough, it will give us some insights.

Re: JavaScript is Good, Actually

#273

Post by rusk »

the_af wrote: post #263
CiPHPerCoder wrote: post #157

Earlier quoted context omitted.

The one thing that makes Haskell not great is that its understanding is not widely intuitive. People with mathy backgrounds that don't blink at the phrase "lambda calculus" won't consider this, but a lot of people struggle with math. If you can't put it in the hands of a 6th grader (in the public school system with no special tutoring) and have a reasonable chance of it being understood (n.b. I self-taught myself ear…

This is the one criticism of Haskell that in my opinion has no merit. Programming languages are not intuitive. They are a learned skill. You know the saying (sometimes said as a joke) "such-and-such language failed because it didn't have C-like syntax" -- but C-like syntax is NOT intuitive! Reading C code is a learned skill. Maybe it could be amended to "since many programmers learned to program using languages with…

There is no language that is innately understood. All computer languages are learned, so when they describe "intuitive" I don't think this is what is meant. However, a large portion of early programming education does take place amongst C-style curly-brackets.

It's this learned setting for our precepts that makes other languages intuitive or not. If we were all learning fortran or pascal in college it might be different, but we're not.

That said, having C-style syntax is clearly not a pre-requisite for the success of a language as is attested by the success of Python, Ruby, various flavours of BASIC and other less loved languages like COBOL ...

But "intuitive" is very important for getting traction. Once you can "intuitively" model a problem in a language such that somebody familiar with the problem can understand what's going on, then that's intuitive. I'm talking about a different kind of intuitive here.

Most people engage with computers on imperative terms, i.e. they want to tell it to do things. Imperative languages are "intuitive" because they allow you to map out a list of instructions in order.

So for instance, when you're writing a program to make a cup of tea you issue those steps one by one. You don't want to have refine the model into a functional space, do a handstand and flip the bag into a mug with your little toe while inducing a small raincloud and microwaving the drops on the way down.

Similarly true object oriented langauges (I'm not talking about C or Java here, where classes are glorified structs) model how we think of information in terms of object-relations.

Functional languages to me as an experienced programmer are "intuitive", but even I sometimes flinch when I'm exposed to a stack of lisp ellipses ...

Re: JavaScript is Good, Actually

#274

Post by peterbraden »

macspoofing wrote: post #168
peterbraden wrote: post #147

Earlier quoted context omitted.

Transpilation is the number one reason I've seen that makes maintenance of older projects hard. The fact that JS didn't standardize on a module syntax until far too late means that we're forced into a transpilation cycle to build bigger projects. I can call that a mistake without denying it's reality. If you want to build a web application, at some point, until we have true web assembly, you will have to use javascri…

>Transpilation is the number one reason I've seen that makes maintenance of older projects hard. The fact that JS didn't standardize on a module syntax until far too late means that we're forced into a transpilation cycle to build bigger projects. I can call that a mistake without denying it's reality. You answered your own objection. The language is deficient so alternatives are sought (lack of standard modules is o…

>No. You can build it in TypeScript or Dart or any number of more sane language and transpile to JavaScript. Which is what people are doing.

Exactly, you can't avoid javascript. Transpilation is at best a level of indirection.

I'm not answering my own objections, rather I'm pointing out that transpilation is a necessary evil, but it _was_ a mistake compared to the alternative, namely fixing modules.

Re: JavaScript is Good, Actually

#275

Post by rusk »

the_af wrote: post #269
rusk wrote: post #226

Earlier quoted context omitted.

Interesting but again, short of contributing to these projects what am I going to do with Haskell?

Haskell is used in the industry, see: https://wiki.haskell.org/Haskell_in_industry You could start your own project. You could contribute to an existing project. You could evangelize Haskell at your job, if possible. All of these are hard, of course. It'll be easier to use a more mainstream language. But if Haskell strikes your fancy, maybe it's worth the effort?

> maybe it's worth the effort?

Yep. Sure. Just as soon as I get done shaving this Yak ;-)

Re: JavaScript is Good, Actually

#276

Post by sixstringtheory »

muddyrivers wrote: post #272
cdelsolar wrote: post #247

Earlier quoted context omitted.

This is a giant overgeneralization. If you are using Redux, for example, you _can_ easily tell most of the time what functions get called and in what context, because data flow is unidirectional and easy to reason about. If you're using an old massive tangle of spaghetti code, it is much more difficult, yes.

You can have very messy code with an excellent language. You can also have beautiful code with a poorly designed language. Let's do a thought experiments. Have a pool of SWEs fresh out of school. Divide them into groups. Each group is given a language they are not familiar with. The pool of languages will include both commonly regarded good ones, OK ones, and bad ones. Ask the groups to do a middle-sized project for…

Forget code complexity. Have each team develop the exact same product in their assigned language, measure how long that takes.

Then play musical chairs and have each team develop a new feature in one of the other teams' project/language. Measure how long that takes.

Re: JavaScript is Good, Actually

#277

Post by imtringued »

Vinnl wrote: post #52
Scarblac wrote: post #32

Earlier quoted context omitted.

It seems you're not talking about JSON (the serialization format) but rather about Javascript's object literal syntax that inspired JSON. They're really different things.

An advantage, however, is that you can directly encode Javascript data objects to JSON without having to annotate its fields or anything. I don't recall you being able to do that with Java.

You can't do that with javascript either unless your data objects are acyclic and if they are then using a JSON parser for Java is equally trivial.

Re: JavaScript is Good, Actually

#278

Post by lghh »

proginthebox wrote: post #219
snarfy wrote: post #213

What's old is new again. Electron feels very much like the old gui systems like ToolBook, VB6, and other 'RAD' tools. It's not so much about the language as all the 'batteries included' toys that come with it.

except that the old gui system ran on 650Mhz processors and 256MB RAM.

And took forever to write and were hard to change.

Re: JavaScript is Good, Actually

#279

Post by cm2187 »

hajile wrote: post #237
pjmlp wrote: post #129

Earlier quoted context omitted.

> Web Assembly is not supposed to remove javascript, it is supposed to be used in addition to it when you need high performance. If people try to promote it as a way to not have to use javascript, it will just result in a more fragmented client-side programming situation, where libraries are not available for particular languages, etc. I guess you have been missing the news what is being done in Go, Java, .NET, Rust,…

There's currently zero support for efficient garbage collectors and no Dom API access. Until a few more primitives are added, wasm is a pipe dream. Even once support exists, there's a payload issue. Nobody wants to spend loads of bandwidth downloading runtimes.

The runtime is probably still be a fraction of the bandwidth consumed by all the photos and videos on modern websites.

But the web is only one aspect. Web apps are likely going to take over a huge part of client development.

Re: JavaScript is Good, Actually

#280

Post by imtringued »

osrec wrote: post #80
tim333 wrote: post #36

Earlier quoted context omitted.

I'm slightly puzzled. Array = [[1,2,3],[4,5,6]] seems valid json and I'm not sure what's inefficient or where the keys come in?

I was thinking of arrays of objects, where the keys are repeated for each object in the array.

Then use compression. gzipped json is highly efficient over the wire.

https://blog.octo.com/en/protocol-buffers-benchmark-and-mobi...

The primary purpose of binary data formats is that they can be parsed quickly and some even allow direct access without a parsing step.

Post reply on HN