estavaro

I was a bit overwhelmed by the many samples that I clicked on.

Someone else posted a link to her GitHub repo and I was glad to check it out some. I chuckled at her using of Ruby/Rails. I was amazed at her using of jQuery.

It pains me to note that what the industry might consider sound software engineering is so detached from the creative tools that she has employed to get this going.

On one hand the industry demands greater quality from their tools. On the other hand the industry seems eager to provide the creative tools used by amateurs-alike to help to get people trained in the tools that the industry might need.

JavaScript really is a puzzle that the industry has been trying to solve. Because JavaScript is far away from what the industry might consider sound engineering principles. But users of JavaScript could make for great employees, so the industry has been trying to figure out a way to create a bridge between the two.

Keep up the great work! I liked playing the Hangman.

Cheers.

And that would be anti-social behavior by itself, right? :-)

Other people think that inmates are anti-social people. But were they always anti-social? Or just some of the time? And how is anti-social measured? Do extroverts make less anti-social people? And if so, does it matter that many inmates are also extroverts?

Bureaucracy seems to be incredibly painful in the Justice system. Decisions get made. To reverse those decisions it becomes a problem in itself. To err is human? To persist on it is stupid. Or is it just a bureaucratic mare?

The help of an IDE restricts the use of the language. It's the same for the TypeScript variant. If you say "you need a Visual Studio" or the like to use it comfortably, you're restricting the use-cases of the language.

I forgot to give the example of using "Enum-like" types instead of boolean parameters, because boolean parameters don't give enough information, so then you might need to pass something like MyClass.MYVALUE to a parameter rather than true or false.

So yes, there's much to like and dislike. Needless to say, there are those that need more type features from the language and toolset than it already offers, even if it's kind of hard because to come up with more if some of it needs to go into compiling down to JavaScript.

With more type features they would expect to have more features like real Enums or what-have-you.

Even "var" declaration starts to look awkward in a language where types are available. So things like "for (int i = 0; i < 10; i++) {}" are more natural than "for (var i = 0; i < 10; i++)". And that's only the tip of the iceberg.

When you start declaring things like "listenToMouseEvent(MouseEvent e, () {})" when using some event API, that's when it gets uglier still.

But yes, to each his own. JavaScript is still the leader in many ways, including some basic performance despite not the extra type declarations. They have really extracted nearly all of the performance allowed from JavaScript it seems. So performance alone is not what will differentiate these other languages from JavaScript.

The problem is that it makes people more concerned about getting the types right than about giving people shortcuts.

The API designers end up creating a multitude of APIs to deal with different type parameters and so on, to get their "generics" right and so on.

It makes the APIs look like Java APIs more than they jQuery ones.

Part of the problem is that the designers really want to get the types of classes and so on right on their parameters and return types. The types go beyond the primitives.

I've been able to watch it unfold and it's rather painful. The result looks less like a scripting language API and more like a C# collection of libraries, for better or for worse.

My confession on the matter: Working with OO in JS made me a "cargo cultist." I wasn't entirely aware of how it worked, but just glad that it did for as long as I had used it. The last JS library I used was PrototypeJS which had some custom support for classes.

I learned about non-OO JS code in the YUI framework. I didn't like what I saw as it precluded a lot of "private and hidden" code.

I've deposited a lot of goodwill on the Dart language that compiles to JS. My reward is that Dart has library and class support that "just works! (TM)" Then again, I abhor the using of types that Dart allows as I think people waste a lot of time giving types to APIs and obscure the intention of the code, ultimately making the platform less popular.

With eval language designers might have a delayed execution that could make compile-time optimizations less straightforward. Part of the toolset could have to be present during deployment time to be able to handle eval which happens at runtime. And yes, security concerns could also play a hand.

In Dart the code declaration is taken very seriously in many ways, and avoiding eval buys them more compile-time, loading-time and perhaps runtime optimization opportunities. I find that more than the language designers themselves, it's the end-users or developers that ask for more "bondage and discipline" from their tools. People who come from Java and C++ backgrounds, for example. They just can't have enough compile-time stuff aided by an IDE.

Ruby is said to be useful for text processing and such. In Japan they had a need for the language to deal with text files specified in a Japanese codeset. Some of the flexibility to support different codesets cost Ruby a little. For Ruby 1.9 and 2.0, Matz took a while in the transition to "Unicode" support in order to keep some flexibility, even though many people preferred the old way of UTF8 and so on.

Ruby is best when it's used for the things it was meant for, but that hasn't kept people from trying to use it for more stuff. That's how Ruby found a good use in servicing web apps, first with CGI and then with dedicated instances in Rails and the like.

Now with Dart I understand that people demand languages be architected in different ways to extract more performance from them. Dart doesn't have "eval", for example. Whereas Ruby and Javascript do.

The question though is one of a divide, between the people who would never use Ruby or JavaScript and those who do use and love those languages that come with a lot of flexibility from the core. Python is like Ruby and JavaScript, even if the Python syntax could be borrowed for different languages that are more restricted in what they offer.

Ruby is great in terms of allowing people to experiment with different algorithms pretty quickly. It's easy getting the code written and tested because the code tends to be so succinct, the standard library already includes a lot of shortcuts, it's synchronous, there's a lot of metaprogramming features readily available and the interpretation allows for quicker testing when you can get the basic syntax right after some experience without requiring the help of an IDE as most Ruby code is written in text editors.

Languages that demand IDEs tend to be more complicated in many ways. They can be faster, but also might demand more code obfuscation through more code that need to be written like types and longer names and importing of libraries and so on. My pet peeve is that I absolutely love Ruby, but it indeed is not meant for ultimate performance. On the other hand, languages like Dart might allow for some compromise if you can get stuff done with less power at your hands like less metaprogramming and fewer shortcuts... Except that Dart is trying to tackle asynchronous programming with the standard libraries which is itself quite complicated (Future what?)

Go and Dart are not themselves too tuned for performance yet, even though they tend to be very quick when compared to Ruby. They tend to solve different problems though.

Ruby has a couple of architects, Matz and SASADA for the VM. Go has a few. Dart has many, with some tending to the standard libraries.

Programming is unfortunately way too complicated. In my opinion, languages like Ruby are wonderful when you don't have a need to hide the source-code. On the other hand, languages like Go and Dart might be good when you do have a need to hide the source-code when deployment time comes.

Animations are fun. I recently created my first animated widget and it felt great. Going from "it works" to "it works and is animated" is a huge step. The animation really helps to tell the story of the switching in my widget. Think the animation of the Chrome tabs when you're switching them by dragging.

The main issue I have with "escaping from callback hell" is that it's a half-truth. Although I don't know much about how the Reactive Framework created by Microsoft works, I know they went well beyond the basics to try to make it all-encompassing coming closer to making it a full-truth.

Just transmitting data back and forth may play well to the strengths of your abstraction. But we have other uses with Timers that should also need such abstractions.

With Timers I have other needs like delaying the execution, resetting the delay countdown, stopping it before it executes it at all (like cancelling it), and finally with an Animation class I needed a way to finish executing a string of events in an instant in order to start a new animation. Also the Animation had other Animation versions at play that could need to be sped up before a new Animation started.

In .NET they seem to have a handy feature that waits the code to run before proceeding that comes into play with their .NET version of the Reactive Framework.

As far as I can tell, it's tough to really solve it. JavaScript doesn't have extra features like .NET does. We are more limited in what we can do. In Dart they have a version of this called Future that has been streamlined recently. As simple as it may seem to be, it comes with other related abstractions called Streams that altogether make it a bit daunting to escape from that hell only to land on the fire outright.

My own piece of feedback based on my experience. The slides were good. But like others, JIT is not all rosy. In V8 and Dart and .NET, code gets compiled to native code as soon as possible. I think that's the best case scenario in general. You then don't have to guess as much.

The author didn't mention method dispatching. I think it's an issue for many languages. In Dart, they tried to optimize it by the specification by mostly eliminating the need to change methods at runtime. In Ruby I watched a video by one of the core Ruby developers and he said that in Ruby method dispatching can be very complicated requiring up to 20 steps to resolve them.

As important as getting the best performance out of programs is to get the programs created in the first place. That's why I'm against shying away from larger codebases. I'm in favor of OO programming exactly because I think getting things done comes first, even if that could complicate the implementation of the toolset. And OO is all about layers of abstractions that bring more performance costs with them.

That said, I absolutely abhor type annotations. They make code hideous and decrease the opportunities for experimentations. Instead of reading a + b = c algorithms, you may need to parse A a + B b = C c source code.

In Dart we have Optional Types. But the core developers are fond of type annotations, so most samples they post come with them. I take relief in being able to omit type annotations while experimenting, researching and ultimately prototyping. Although in a way I feel like a rebel in the community for this disregard. Thankfully there is this chance to share a community with them.

Reading the part that you don't like adding heuristics to help programs to go faster reminded of adding types to them even if they are mostly disregarded as in Dart.

Then again, not all "dynamic languages" are the same. Some are truly dynamic with eval and runtime method changes. Others, not so much. Sometimes the tradeoffs allow for other kinds of gains that could come into play like when deploying. So there is a lot more to it than just getting the algorithms correct.

Exactly. In Python you still pass "self" to the method. In Ruby and Dart it's not needed.

In Python I've seen Python users discourage the use of classes. I haven't seen the same distrust of classes in Ruby for instance. It's as though Python has unresolved OO issues. Python could take pride in being "multi-paradigm", whereas languages like Ruby and Dart could take pride in being more OO.

Regarding the C extensions of Ruby, I think the bottomline is that from int, to booleans, to null, to classes, everything is considered OO even in the C code. So common functions can be applied to them even from C, say like Polymorphism would in other languages. From the primitives on up everything is like a high level Ruby. As Python is more "multi-paradigm" perhaps some of its C extension features aren't as OO as Ruby's are.

Funny though that those C extensions that make Python and Ruby so popular end up making other implementations of those languages that target other runtimes incompatible as they don't have access to those C extensions. So even in that regard they are similar.

Say we can't find anywhere in Python where Objects don't exist. Then welcome on board of true OO. Now show OO some love and stop discouraging the using of classes. Maybe drop the "multi-paradigm" approach. I know though that like JavaScript, sometimes you have to live with the shortcomings of the programming language in its support of OO. So while JavaScript could be said to have Objects everywhere, and it truly does, writing classes in JavaScript is not a settled issue. That's why I like Dart instead:

  class A {
    var aList = ['a', 'aa'];
    get length => aList.length; 
  }
  
  class B {
    var aList = ['b', 'bb', 'bbb'];
    get length => aList.length; 
  }
  
  class C extends A {
    var aList = ['c', 'cc', 'ccc', 'cccc'];
  }
  
  printIt(o) {
    print("${o.aList}: ${o.length}");
  }
  
  void main() {
    printIt(new A());
    printIt(new B());
    printIt(new C());
  }

  [a, aa]: 2
  [b, bb, bbb]: 3
  [c, cc, ccc, cccc]: 4

You see, you wrote a bunch about how len is so cool in Python. But in the face of dynamic typing and polymorphism I didn't expect it to be any different really. Languages like Go that are statically typed make more of an issue about interfaces. Even in Dart they dropped explicit Interface usage in favor of implicit interfaces, considering that Dart is more explicit about matters than Ruby is.

Switching those function calls around reminds me of Delphi. When I first learned about Python, those calls reminded me of Delphi which I had used more. But once I learned Java, my frame of mind went from function(object) to object.function. With Ruby I found it quite intuitive. Now all languages work better if they approach things the way Java and Ruby do because of familiarity. That's why I like Dart for what it's worth.

Regarding C extensions of Ruby, they are like OO in C. Not sure how Python does it by default. But in Ruby all C extensions have a OO flavor. The first major book about Ruby writes about them: http://www.ruby-doc.org/docs/ProgrammingRuby/html/ext_ruby.h...

I think if you're counting references in the GC perhaps your C extensions are not very OO yet. In Ruby as in Java, the GC is an abstraction over reference counting. I think reference counting is often said to lead to more predictable performance at the cost of increasing the maintenance burden.

So again, not sure where Python is not "Objects all the way down." But Ruby has had the OO philosophy from early on. I think the Ruby OO approach started with the OO of the C extensions and went from there. Unlike Python that had a stronger procedural influence. The gap has closed since, but in Python a class is not written like this yet:

  class InRuby
  def aMethod
  end
  end

  class InDart {
  aMethod() {}
  }

Trying to guess how Python works is quite hard if you're used to Ruby and other languages closer to Java.

As I don't know much Python myself, it's hard to tell where Python fails the "everything is an Object" check. But in Python some legacy calls were more procedural than OO, like "len(o)" rather than "o.len". I think eventually Python got to support both approaches.

I think Ruby is all objects even in its C abstractions. In Ruby, people create classes and so on in the RubyC abstractions that are visible to the Ruby language too. Not sure how Python does those.

I know Python has reference counting for Garbage Collection, so there are differences to their approaches in that regard and more.

Like Guido Van Rossum said, from 10,000 feet both Ruby and Python are more alike than different. He was saying that people should appreciate them more even if they belong to the community of the other one. That the real enemy is languages like Java that switch around the priority by making code that compilers prefer rather than programmers prefer.

I think Python has a Functions legacy that could not be as OO as they would be in Ruby.

Right now I'm more "in love" with Dart than with Ruby. Ruby was my first real love though.

I have quite a bit of Ruby for the server-side. But on the client-side I've been using Dart instead.

While Dart could be good for the server-side too, as it's VM will be as fast as any other dynamic language VM out there and the language is still quite cool, on the server-side we get to choose the tools more freely so there are many options.

Then again, why would people use Dart or Ruby on the server-side if they could use Go instead?

Go and languages like it are more lower level and sometimes more demanding, making mixing and matching while programming harder.

Mixing and matching is a way of programming for today rather than for the future. Say, dealing with the issues as they present themselves rather than trying to go around them. Say, dealing with the UI as they are popular rather than doing things in an unusual way while trying to guess the future.

I really liked watching an Intel guy say that if your approach to parallelism isn't about sharing the load to over a hundred threads, then forget about guessing the future.

For now as in the past, people have been successfully using threads for doing what they were originally meant for as Guido Van Rossum explained in a recent video. Threads were meant for concurrent I/O work. Now people want to push them to doing more parallelism. Not sure how we are going to get there.

Because like supporting many GUI front-ends has taught us, getting the most out of GUI often means that you need to target them on a one-to-one basis. Creating programs that support 1 thread or 100 threads from the same codebase will be quite a challenge going forward. Because if you want most performance from just 1 thread, it could be that the program needed to be written one way. Whereas to make it better for 100+ threads, it could need to be written a different way.

So, why would people write Ruby? Because it works. The Internet is unreliable anyways. Depending on a central server is too all-eggs-in-the-same-basket for the Internet.

Also Ruby is getting more stable. Depending on new tech can lead you to unstable nightmares.

If you were worried about bigger codebases and still wanted a language like Ruby, I'd first recommend Dart than Go. But for its current stability concerns. It will hit 1.0 soon though.

It's an OK choice. I'd rather they picked Dart instead. Dart has a better OO support and a cleaned up core language. But it's early days for Dart still.

Dart has a VM by the same folks who created the JavaScript V8 Engine and they say that they expect Dart to be faster than JavaScript in a number of ways. Part because Dart's code is less dynamic than JavaScript's. Part because loading Dart files could use a pre-parsed file.

You can work on documenting Dart code by adding types to the APIs as it's optionally typed. Dart on the browser gets translated into JavaScript for deployment making the issue of not having a Dart VM everywhere less important.

One of the niceties of Dart is that before deploying, code gets reduced by removing unused code with a tree-shaking algorithm based on Dart's less dynamic features.

  class Dart extends JavaScript {
    var points;
    Dart(this.points = 10);
  }

You need to be commended for defending Go.

I don't think the Go developers hide the fact that they mean go as a Systems level programming language. It has higher level features, but the developers don't really mind the fact that Go isn't going to be delivering a whole lot of high level features. Maybe if they come in the form of libraries...

Funny thing about Go is that as a compiled language, folks often need to send the source-code to the deployment servers to compile on them too. I seem to recall that deployment servers shouldn't need to have development tools which were themselves exposing the servers to bad intention by bad folks. It's just hard to keep the separation I guess.

Go error handling is not to be taken lightly just because you can ignore error codes or just print the error and be done with it. I seem to recall that the core developers of Go demanding that Go users try harder to handle errors. Something the compiler doesn't really "enforce".

I prefer Dart to Go because Dart starts from a higher level of abstraction already. Also Dart has been the result of two years of development even if many of the Dart developers also had plenty of experience with developing past languages and tools.

OOP already gives us a lot of bondage and discipline. No need for more incentive by the compiler. Sometimes a couple of extra tools can help our hands without it being forced by the compiler with every run. Say a tool that helps to tell us which methods or variables aren't being used. Go forces us to deal with that on every compiler run. (Even if it can be disabled, but the Go developers prefer to avoid proliferation of config options.)

It's good to have Go and Dart around. So it's not just legacy (Java) and Microsoft (C#) dictating the standards.