3 ms·
No, you can’t “skip” them. If you skip them, the code is broken. The lines may well be noise, and arguably that’s even worse, but you certainly can’t skip them
by mstade 8y ago
No, you can’t “skip” them. If you skip them, the code is broken. The lines may well be noise, and arguably that’s even worse, but you certainly can’t skip them – counting or otherwise.
- tomtheelder 8y agoYou can skip them if you want by various means, and you can also not put them on their own line. You don't even have to use JSX, which is what is taking up most of the space. A shortened, yet still totally readable (if you are used to not using JSX) version that is shorter in LOC than the Qt example might look like: import React, { Component, createElement as e } from 'react'; import { render, Window, App, Button } from 'proton-native'; function Example() { return ( e(app, {}, e(Window, {title:"Example", size:{{w: 300, h: 300}}, menuBar={false}}, e(Button, {stretch=false}, onClick={() => console.log('Hello)}, 'Button') ) ) ); } render(<Example />); If you really hate the brackets and parens you could certainly use a dialect of JS that doesn't have them, and you could cut it down to like half the length of the Qt example. But this whole discussion is silly. "Shortness" in code terms has much more to do with the number and complexity of statements, not LOC or characters. The JSX in there adds "noise" and characters, but the whole purpose is to simplify understanding code and make it readable. It's not adding any fundamental length. The Proton example is doing a bit less than the Qt example, and for me that's a much more useful definition of shorter.
- mstade 8y agoThis seems like as much of a non sequitur as "skipping" syntactic elements. The comparison is clearly syntactic, and thus factually incorrect – the second example is in fact longer than the first. Sure, if you swap in another example that is in fact shorter, then it'd not longer be an incorrect statement. Maybe I am indeed being silly, but it seems getting the hook-line-sinker arguments as right as possible is a worthwhile goal, particularly when at least one of them can be objectively verified. If by "shorter" you mean "less complex" than stop saying "shorter" and start saying "less complex" instead – just as you say they aren't the same thing. It'd mostly be redundant I guess, given "easier to read" and "easier to edit" implies "less complex", but at least it'd be harder to immediately refute.
- jcelerier 8y agoHere's an equivalent Qt example though, shortened like yours: import QtQuick 2.7 import QtQuick.Controls 2.2 ApplicationWindow { title: "Example" Button { height: 300; width: 300; onClicked: console.log("Hello") } } look ma, 6 LOC !