Would have thought it was obvious I was talking about cars? Its reply was hilarious:
> A Renault Clio is much bigger than a giant panda. While a panda can be 4 to 6 feet long and 2 to 3 feet tall, a Clio is typically 4.053 meters long and 1.440 meters tall, making it significantly larger in all dimensions, according to Auto Express and CarsGuide.
Is this part of the reason why developer salaries are so much higher in the US? They're being used as tax write-offs, i.e essentially government subsided?
Could I suggest you take a look at my project, Perspex?https://github.com/Perspex/Perspex - it sounds like it ticks your boxes and we're always in need of contributors!
Flexbox seems to serve most HTML layouts. Are there any that it doesn't work so well for? What about CSS Grid Layout? I've not heard anything about that for a while. Does that have any advantages over Flexbox?
It seems the CSS Grid Layout needs far less divs to accomplish the same layout. With Flexbox you end up creating a lot of parent elements to layout the content elements correctly. With CSS Grid Layout you can express the layout more precisely in the CSS, so there is no need for a lot parent elements.
I'm always surprised by the people asking "bring VB6 back". I'd like to know why - is it because you're stuck maintaining VB6 applications that can't be/haven't been updated to VB.net or C#? I used VB6 extensively back in the day, and I am very glad indeed that it's now dead.
It is ridiculously easy to create simple GUI apps with it, its limitations force you to write straightforward code (otherwise it becomes too much of a hassle and you go to another language) and provides a very good debugging environment which allow you to inspect and modify a program as it is running in a graphical way.
It is basically an extremely simple scripting language attached to a GUI designer (literally, originally VB was supposed to allow different languages to be used with it, but the feature was dropped).
Also it is instant fast on modern hardware.
Most people who have a grudge against VB1-6 have it either because they have no idea what they were talking about and are just parroting others (to be honest, i did that at the past), or were exposed to it via a project that abused it in ways that it wasn't meant to be (ab)used.
A while ago i made this little sprite editor in VB5:
It isn't anything special but it is actually quite useful if you're making low-res pixelart 2D games and personally i had fun making it (the first version also took me only a weekend although i added a few features since then).
Having said that, i do not expect Microsoft to bring back VB6 nor release the source code since now they seem to focus away from the desktop and VB6 is a full 1005 desktop technology.
To my mind, all of the points you listed as an advantage you can also find with C#/VB.net using WinForms. I've also never found WinForms or even WPF (most of the time) to be sluggish on even reasonably modern hardware.
What specifically do you find easier in VB6 than VB.net/C# when writing desktop apps, in particular in relation to WinForms?
You say "inspect and modify a program as it is running in a graphical way" - do you mean that with VB6 you could alter the UI as the application was running? If so, that's something I don't remember but I agree it could be very handy!
I've mostly had coworkers that had fond memories of VB6. Personally, compared to what we have now, I think it sucks. I'm no parroting. I suppose there's no way for me to know whether I "have any idea what I'm talking about". The language itself is terribly constraining. No try/catch. No generics. Crazy 1-based collections. No type-safe lists, just fixed size arrays. No function references. And so on.
Fun trivia: The first version of UnrealEd, the editor for the Unreal Engine 1 (used in Unreal, Wheel of Time, Rune, Deus Ex, UT99, Clive Barker's Undying etc.), was written in VB (of course, it used the renderer via interop).
Not necessarily - in America yes that is the way things work at the moment, but not all over the world. There are may suburbs with good public transport where having a car is less necessary.
Some big Australian cities work reasonably well with 'cars optional' suburb. They have an overall feel and lifestyle that I imagine would be familiar and comfortable enough for most American suburb dwellers.
For a quick and dirty snapshot: Suburbs are considered similar to small 'urban towns.' They typically have a train station (some Sydney suburbs have cool ferry stations) at the centres and the suburb stretches for a 1-2 mile radius from there. They are usually denser and have a more town center feel near the center. Inner city suburbs feel more urban. The really distant suburbs are more car centric and often have a semi-rural feel. Suburbs on the Dandenong foothills in Melbourne are a cool example of this.
Basically the nearer the city centre and suburb centre you live, the less cars are necessary or convenient. It's not extreme though. Most people have cars everywhere but the level of use varies. I would estimate that >50% live someplace where car free living is possible without too many trade offs.
Realistically though, the way to prevent cars is to make them unaffordable. That's an option, but I don't think you can call it a victory for quality of life by itself if it's achieved by making something people want unaffordable.
You are talking about something that has very little to do with the population density and zoning of an American midwestern suburb: What we mean is something like this, where having no car makes you a second class citizen.
What you call a suburb is more like what in Spain are called 'ciudades dormitorio': Small towns with a much higher population density than the american suburb, and that have good communications with downtown. People live less than a mile away from a train station that drops them in a public transportation hub in downtown Madrid. It's still a suburb, but it has absolutely nothing to do with what an American describes.
What s sustainable and economical public transport? And what is that population density? Are US suburbs less dense than European ones? Or is there less Will to publicly finance public transport? Funding road construction with tax money but not having a public transport system on those roads with 50-100% tax funding is just asking for congestion, sprawl and pollution.
I live in a smallish suburb with mostly single family houses 30 minutes by bus from the city. Buses leave every 10 minutes, and every 2-3 minutes during commute hours. I would never commute by car, especially since the buses use bus lanes.
Not the OP, but in our product we have very large binaries that are the output of the product itself. Each time a change is made to the program, the output needs to be compared to the existing output first automatically and if the output isn't byte-by-byte identical then manually (visually).
So essentially, without large binaries in source control we'd lose testing.
Same use (albeit with less nice syntax) as the ruby symbols.
Many frameworks based on ruby (like Rails) make heavy use of symbols.
They are handy as they are immutable, very cheaply comparable for equality and (in ruby) very light on syntax and they can be made out of thin air whenever you need one.
some_array[:foo] = 'bar'
instead of
FOO=0
some_array[FOO] = 'bar';
(think how error prone it's going to be to add more keys like this. Forgotten declarations, duplication declarations and so on).
You could use strings, but they are often heap-allocated (slow) and sometimes (ruby) even mutable and thus way more expensive to compare for equality and require some kind of hashing to put them as keys into hash tables. Symbols don't. And never conflict.
My idea of them was, they are like string-identifiers, but instead of creating a new string for every string-literal the symbol-literal creates one global, immutable instance.
The main reason why Symbols were added AFAIK is to specify protocols / interfaces. Right now, duck typing is all we have in JS.
How do you check if an object is a Promise? You do `(typeof obj.then === 'function')`. Is this good? No, not really, especially not when the language reserves such a word - the problem is that they're global names and can easily conflict with existing methods.
In contrast, a symbol is used for the Iterator protocol [1]. You implement the protocol by adding a method to your object at the key "Symbol.iterator" that returns an iterator object. Unlike with string keys, its impossible for someone to have already used Symbol.iterator as a key before: the value didn't exist at all. As a result, this feature lets ES.next and libraries define new protocols without the need to come up with unique method names that aren't used in any library.
In addition to the other replies, Symbols were at one point meant to be used for implementing private visibility in classes - the idea being that the private fields of an object would only be visible inside the class closure, preventing external code from being able to access them. However, private has been backed off from ES6 now.
To be clear, "private" variables (including "methods", ie. variables bound to functions) can be implemented anywhere using lexical scope; whether you're pretending to have "classes" or not.
The feature which symbols offer is unforgeable contracts. These offer some benefits of type systems and module systems (AKA existential type systems). Any time we want to restrict access to some value, we can "seal" it by generating a new symbol and using that as its key in an object/mapping. We can pass the symbol to the code we want to "unseal" it, whilst the object itself can get passed around anywhere at all, without anyone being able to extract or replace the value until it reaches the "unsealer".
To see why this would be useful for "private visibility", the trick is not that we're hiding the values to everyone outside our lexical scope (which is trivial, since that's what lexical scope is); it's that we can allow access to these values, via functions which check that they're given the correct symbol. In other words, we can have our code "recognise" when some other code should be given access. If we limit ourselves to making "classes", where the symbol is in-scope in the "constructor" and doesn't leak out, then we have a primitive form of type-checking; if we're given the correct symbol, the other code must be of the same "class", so we might decide to let it see our "privates".
Of course, that's just a degenerate edge-case. There are all kinds of other uses, for example section XII of Harper's Practical Foundations for Programming Languages is dedicated to the topic http://www.cs.cmu.edu/~rwh/plbook/book.pdf
>To be clear, "private" variables (including "methods", ie. variables bound to functions) can be implemented anywhere using lexical scope; whether you're pretending to have "classes" or not.
Sure, as long as you declare all methods that require access to said private fields also within that same scope.
For example, TypeScript emits class methods (and getters-setters) as properties on the constructor's prototype. The reason for assigning methods to the prototype instead of each new instance is of course efficiency - you don't want to make new closures every time you create an instance. If the private fields were only available within the constructor body, the methods could not access them.
Reflect.ownKeys will list all keys (string or symbol or otherwise) of an object. It's not clear from the article if it can be excluded via an ES5 definition with `enumerable: false`; perhaps so? In that case, this is pretty cool.
I'm not sure of the JS implementation in particular, but it wouldn't surprise me. Keep in mind that the security/encapsulation features of many languages (private, final, const, etc.) can be bypassed using reflection, especially in "more dynamic" languages like Javascript.
At any rate, Symbol properties aren't meant to be a bullet-proof way to hide private properties. They just reduce the default public API surface of an object by suppressing its internals.
It seems they can be used as a little safer enums, like :keywords in clojure. It can come handy if you want to add method to object that nobody will overwrite by accident.
But clojure was designed around :keywords, while js was designed around strings as property names. Adding another possibility now complicates everything.
Seems like it could be used as a way to lazily copy objects; a solution like this could make a lot of sense if, say, a server had entire objects instantiated and the client only needs to know they exist, but not what each object contains.
> Is a panda or a Clio bigger
Would have thought it was obvious I was talking about cars? Its reply was hilarious:
> A Renault Clio is much bigger than a giant panda. While a panda can be 4 to 6 feet long and 2 to 3 feet tall, a Clio is typically 4.053 meters long and 1.440 meters tall, making it significantly larger in all dimensions, according to Auto Express and CarsGuide.