Oh man, best game ever. I really wanted to learn it having putting it off for so long. I can see how I could use it in a framework of mine. Gives me an excuse to use open web technologies again.
I was revamping some old code of mine, removing outdated technologies of third parties like YUI... But I noticed that I needed them for layout. But flexbox can provide an alternative for me.
One advantage of Go is that more code is dependent on the network which is where Go shines at. Go looks like a hammer when the network looks like a nail. For example, Go was one of the first to start adding HTTP2 support. If Go is always there for network tools, it will creep into areas that perhaps many would not have foreseen like security systems that were previously done in C and C++.
I enjoyed the article. I think the general sentiment here is that one needs to take the good with the bad.
I also think that the ongoing changes have made for a different web that is less important on the mobile devices. In watching some videos about mobile we get that people are excited about new ways of interacting with computers, perhaps with the camera, perhaps with the microphone, or perhaps with the GPS... Sometimes the web just does not feature in those trends.
The web has changed a lot since Obama first won the Presidency. His site with donations, the network effect directing traffic to his campaign site and so on... Now there are these "Streams" on mobile, I'm not sure how those could be shared with a community that was sometimes anonymous and decentralized, like you say...
Now it's like people want to drink bottled water of a certain brand instead of sharing the water in the lake (web). It doesn't seem to scale. And companies and governments are just too forceful to avoid competition and so on to allow for a thousand flowers to bloom like it may have been possible in the past.
Indeed. That may mean fewer opportunities for "meta-programming" if by meta-programming we mean mutation of core structures. It could also be a good chance to turn around the default of declaring variables to declaring constants instead. Complex data structures would still have to be mutable by default I guess, but they would be the obvious next target to becoming immutable by default.
Feels like people will be urged to move to Python 3 due to the new features... And yet I'm thinking that Python 4 will happen before many have been able to move to Python 3. :-P
The cost also comes in the ignorance of that third world part who have poorer access to education and opportunities.
They are third world because they are ignorant. And they are ignorant because they are third world.
Sometimes small incentives go a long way toward getting people further ahead. Sometimes they may shine by means of sports. But not everyone can be saved by sports. :-)
The way that the Java platform evolved very slowly just seems rather unlikely nowadays. Sun didn't allow for Java extensions that made it too platform dependent. To this day Java's platform independence is perhaps its greatest legacy, since platforms have changed a lot and the Java code can still be used even for the latest hardware.
But the idea of a proprietary platform is just exotic nowadays. I doubt it that when they started the Java project that they imagined it that most of it would be free and Free. Everyone wants software to be a commodity. I don't know how they would fund a similar project knowing that it would compete against very much free and Free solid alternatives.
Also, browser plugins are dead. So something like Java applets would hardly take foot.
Like others have said, one of the big selling points for Java was Windows development. The interfaces sucked. But the need was there. Once Microsoft came up with .NET that profitable market was challenged.
A lot of Java alternatives nowadays can go a long way from just hosting web services on Linux. So Java's selling point of supporting many different platforms would not have been as interesting. Also, Apple restricts JIT on iOS, further compromising alternative platforms on that platform so even if a new Java wanted to support iOS it would have to settle for less.
Settling for less was in fact one of Java's goals. It helped it with platform independence. But it didn't make many platform dependent developers too happy either. :-)
In theory. In practice many of the mainstream languages make for bloated code. Yesterday I was seeing type casts and so on increasing the size of the code.
But developers can grow used to bloated code. Like they can get used to stepping the code with the debugger. I for one prefer to print debug info. On the browser I have custom code that helps with that. But I understand that many developers don't have anything like that and they have to use a standard debugger instead.
I grew used to debugging with print outs on Ruby. Before that I used to use IDEs like Delphi and Eclipse.
I also hear that one of the problems people may have on OCaml is that sometimes when they want to print some data structures they first have to make it printable. I like languages that make the structures printable by default like in Ruby.
Yes, TS is improved since it comes with the top IDE: VS. :-P
Seriously though. Watching how people use IDE to code on Twitch can be so boring. Everyone is quick to suggest to step the code with the debugger. When just printing stuff to the console would be better.
I hope that TypeScript never makes it into the browsers. I would take JavaScript without the types by default. It can even be more static than it is. But please, no types by default. Types make for bloated code.
Someone yesterday spent 2 hours on Twitch dabbling with the Eclipse IDE and could not get unstuck, since they weren't even referring to the documentations or making quick changes to test their code.
I think developers are still a little shy about using the Canvas for much. In my own toying with a text editor, I found the Canvas to be pretty nice. The advantage is that one needs to render just the visible lines.
With the way developers use the DOM for things like text editors, it's no wonder that they may reach the limit of the browser performance. If we add too much stuff to the DOM, the browser does not have the flexibility of just "rendering the visible lines" like we could with the Canvas. The browser has to calculate everything again.
I was recently surprised when I added 100k table rows with 2 columns in a sample, and when I clicked on a button to toggle the visibility of some list items next to the table, the browser would take a few seconds to finish processing it. Since it was a sample test using React, I thought I would try it without React to see whether the slowdown was because of React somehow. But I found out that even without React it was about the same difference.
If you notice, Atom has a hard limit on 2MBs buffers. I just created a test loading almost 2 MBs in an Atom text tab, and it indeed became unresponsive. It took forever to load and then had problem handling text editing at the end of the buffer.
I think Atom would be better with Canvas. But many JavaScript editors use the DOM and for 1,000 lines they tend to work very well. Which is generally enough for running samples and such. Another advantage of the DOM is that they could more easily embed images and have varied size text, I guess. So those WYSIWYG HTML Editors may be better served by some DOM Editor.
I guess in the future Atom could also add a Canvas editor and keep both.
I don't know Tcl much. But when I learned about Tk in Ruby I kind of expanded my knowledge of Tcl since Tk was the GUI toolkit of Tcl that was borrowed by many other scripting languages.
Tcl/Tk had features like distribution of a deployment binary. It could create an .exe file for Windows deployment for example.
Tk included a Domain Specific Language for layout/GUI controls which was useful, without requiring an additional form designer as in other languages.
Others have mentioned Expect above, it was a good reminder, imagine creating a GUI application to control a command-line tool, Expect allowed for that very easily, as it could keep open the output/input of the tool it was adding a GUI to.
Since it included so much by default, the community could easily contribute with some other tools that you could reuse in your solution. Before "RubyGems" even existed, people were already reusing libraries in Tcl/Tk. :-)
The problem of other languages is that they come with more abstractions than people needed. We can fight against "state" in modern programming languages, but it doesn't change the fact that the more complex we make it, the harder it is for people to just get something up and running quickly. That's why systems like Tcl/Tk cannot be retired.
I believe asm.js has been trying to counter concerns people might have when considering using it. Also, it could be that some companies may be trying to join efforts in trying to further the asm.js adoption, like Microsoft adding more support for asm.js. So it could be that they are planning ahead much more now. The asm.js effort could be seen as moving on from a prototype to an actual feature companies may depend on in the soon future.
Also, what makes people more cautious about performance concerns is that mobile network and hardware are still catching up to what people have on the desktop. And since about 8 years ago, mobile has been a big opportunity for many companies, which means that the desktop has been taken for a ride by the mobile devices and that is not going to stop.
The thing for now is that the asm.js "family" is riding on LLVM's back. More and more it's the LLVM that is becoming that VM people have longed for. It looks like LLVM is inching towards the JavaScript VM with every year that goes by. I read that Apple is using it for further JavaScript optimizations on the browser. LLVM already powers WebKit underneath right?
So as things stand right now we have 2 popular "VMs" people really use. One is JavaScript since it's going nowhere. And the other is LLVM that is "free as in beer" for companies all over. JavaScript was secluded to the client. And LLVM was secluded to the backend. Now they are going to be marrying and having lots of children. :-)
I think what they probably mean is just try to have fun in life. So be passionate about who you are, rather than about what you would be willing to achieve in life. Because it's simply impossible for everyone to be CEO of the world.
Bill Gates recently posted some graphics showing where most people live in the world. Needless to say, most were in China and India. If they all wanted to be CEO of the world, we'd have a problem. :-)
https://twitter.com/BillGates/status/566375184790462465
Scott Adams is a nobody in other cultures. I don't know why we would need more economists telling the world how the world is supposed to work. Maybe China and India need to be more capitalists or something. :-)
BTW, there is a VM for Dart that is experimenting with different concurrent modes to provide an alternative to async programming: https://github.com/dart-lang/fletch
I like Fletch's idea very much. Imagine not having to worry about Async all the time.
Not sure how everything is implemented in Fletch, but I think I heard that in Fletch they are able to share 1 thread per many processes if need be. And they have been trying hard to save memory while implementing those features.
When I was creating a UI library, I tried to pick up on the trend of data-binding, but I found it difficult to use. Now these discussions remind me of it.
I don't even know how the second option is better to be honest. I may research it further.
Sometimes people have good ideas that may be a little overkill for your project. Running a VM could help with creating test environments. Although there may be alternatives to that. So maybe they just want to test more. Maybe they are more QA types.
Try to understand where they are coming from and give them some guidance. :-)
I was revamping some old code of mine, removing outdated technologies of third parties like YUI... But I noticed that I needed them for layout. But flexbox can provide an alternative for me.
Thanks a bunch!