You can replace Python in Ruby or Lua for the most part and also Android with iOS. Dynamic languages aren't yet a big deal and I think it's because they don't bind well or give you a significantly better developer experience than Objective-C or Java on these platforms do.
RubyMotion is probably the closest I've seen to making a language like Ruby or Python a very compelling mobile developer experience while maintaining the end user experience.
That basically means you need to write a Python compiler for iOS or Android to make it compelling, which means adding type checking and at some point developers start asking why they aren't just using Java in the first place...
That's correct that the type system is the crucial attribute as a platform language. But that's not the only reason. It's also for correctness, safety, productivity and manageability.
That's because a platform is huge and complex monster. So all those properties are archive-able only by automated tools, and those tools need rich metadata for each word of code. Type information is crucial metadata, and it's mostly impossible to make high quality tools without those informations. That's why all the designed modern platform (=system) languages are all mostly typed. From C/C++/Objective-C, to Java, C#, Go, Rust, Dart, TypeScript…
In fact, it doesn't matter the language actually statically typed, dynamically typed, duck-typed, or completely untyped. The point is an ability to offer accurate metadata for automated tools, and type system is the best ever invented. So languages lacks the ability cannot be a platform's primary language.
Exactly. I've never understood why someone would prefer a untyped language. It's just a bad developing experience, code needs more debugging, it is harder to maintain and overall productivity is lower. Untyped languages are fine only for small scripting languages.
There's a difference between typed and statically typed. Python is a strongly typed language, but it is dynamic.
> bad developing experience, code needs more debugging, it is harder to maintain and overall productivity is lower
All of these observations are highly subjective.
> Developing experience:
I much prefer developing in python than java. If IDEs factor in, there are a number available for python, none of which I use, because I find a simple editor is usually enough.
> code needs more debugging
That's a function of the problem and the developer. The run, check, edit cycle in python is a lot quicker than using your IDE to run, check, edit, compile. There are debuggers available for nearly every language that allow you to step and inspect.
> harder to maintain
Disagree. When you have code 1/5th (number pulled from my ass) the size codebase, maintainability can be much better. Unit testing helps, regardless of the language.
> productivity
A developer proficient in language [X] should be just as productive as a different developer proficient in language [Y]. Creating a massive type hierarchy of classes and interfaces is a tonne of overhead when you are trying to express a simple idea. In a language like python, you might write a simple class (or two), and use dynamic typing appropriately. A java developer may use code generation and IDE shortcuts to lessen the amount of total code they have to write though.
The advantages and disadvantages of dynamic and statically typed languages are fairly well known. Neither is perfect all the time and for each person. Just because you don't like dynamic languages, it does not mean they don't have their virtues.
> I much prefer developing in python than java. If IDEs factor in, there are a number available for python, none of which I use, because I find a simple editor is usually enough.
What does it even mean? You can dump everything into one class hacky Python way if you want. You can use dynamic keyword if you don't care about type safety.
We're not talking about monolithic, do-everything, hacky classes. You could do the same thing in C#.
Static languages (usually) force you to use interfaces and sub-typing just so common code can be reused. Duck typing is a much nicer way of working - without having to jump through seemingly unnecessary hoops. The situation is even worse when you code for testability. Things that really shouldn't have an interface now require one, so you can mock out the object appropriately. This is all avoided in a language with duck typing.
This is actually where Go has a great impact. You get your static type checking without being forced to use explicit interfaces. It essentially uses duck typing for interface implementation.
You're free to enjoy static typing over dynamic typing all you like - but you shouldn't make the mistake of thinking dynamic typing is inferior in any way. It is different - just like imperative vs functional is different. You make a series of tradeoffs, that is all.
Yes, but it's not idiomatic C#. The point I've been trying to make is that both kinds of languages (dynamic and static) have their different virtues. You can drop down to dynamic in C#, but unless you have a very good reason, your co-workers will lynch you.
And .NET framework tend to overuse subclassing/overriding pattern where delegation is more appropriate. That frequently leads users also overuse subclassing/overriding.
If you're familiar with C#, Real World Functional Programming: With Examples in F# and C# [1] is an excellent resource for learning how and when to use composition over inheritance.
Functional programming usually leans towards composition, and OO programming towards inheritance. "Hybrid" functional languages, like F# and Scala, allow you to use both styles, mixing them in whatever way is most useful for the particular problem you're solving; "pure" functional languages, like Haskell don't offer OO-style inheritance, since composition is a better fit for combining side-effect free ("pure") functions.
tl;dr -- Composition is to functional programming as inheritance is to OO programming.
I doubt you really mean untyped languages. Untyped languages includes many assembly languages, BCPL and some Forths. It does not include typical scripting languages like Perl, Ruby or Python - all of which are strongly typed.
I don't know about Ruby but Perl certainly isn't strongly typed. You can run 'print "5.0" + 6' and get 11 as the answer. That's weak typing and types are implicitly converted to whatever.
Python is strongly typed only for the basic scalar types. With objects and classes there are just objects that may or may not have certain bound functions and attributes. Duck-typing is mostly perfectly sufficient since any errors do come out in practice, and there's no need for interfaces or classes as unique types, but what would be really helpful would be to have Clojure-like multimethods where dispatching of a function is itself a function of the arguments given in. That would be what would most alleviate the problems that arise from everything being a object() in Python.
Ruby is strongly typed. I am not sure that's static or dynamic, but regardless of how it is implemented, Ruby lacks ability to offer type information to code-writing level toolsets because it doesn't force retaining of type information on field and function parameters.
So regardless of whatever actually happens, to the tools, each Ruby function is just all dealing with unknown type parameter objects.
As a conclusion, Ruby has type, but has no way to utilize it. I think any other popular scripting language - such as Python, JS, Lua… are in same situation. V8 does speculative strong dynamic typing, but the those generated informations are completely useless to code-writing level tools.
And users of dynamically typed languages will sometimes argue that the need for code generation tools is less necessary. You lose the ability to have tools do a lot of the work, but you also lose the need to have tools do a lot of the work. It's a trade off.
Type [an]notations are also useful for compilers when generating performant code. But projects like pypy and V8 (javascript) show that a well written interpreter can do run-time analysis, and generate performant code, just like a static analysis.
Sorry, but what are the problems with everything being an object? That's a feature. Python 3.4 now has @singledispatch, though I don't know where I'd use that yet.
To be pedantic, assembly languages do generally have multiple types, if by 'type' we mean 'a set of values disjoint from other sets of values'. For example, x86 has the types integer, floating point, MMX, SSE, and registers of these types cannot be confused for each other. It's just that these classifications/types aren't so useful, and we can't make our own (and perhaps all we really wanted was a distinction between integer and pointer)
Historically they didnt, until hardware floating point wired up some registers to special hardware. Which is why C lets you cast; BCPL just has bit patterns.
I think you originally intended explicit type notation.
I recently discovered actual type doesn't matter that much, and the point is having an interface/protocol which enable compiler validation and tooling support. I learned this truth from Objective-C and Go. That's why I told actual typing system itself not important. Objective-C protocol is nothing about type, but defines nice interface for tooling support. Go interface defines set of promises, so actual object structure doesn't matter.
Furthermore, recent languages offer automatic type inference - Haskell, Go, C++11. They force to retain type information, but also permit to elide them where accurately inference-able/deduce-able.
This is completely different with not forcing type notion such as Python, Ruby, Lua, JS. In these languages, it is fundamentally impossible to track complete type information. But in explicitly type notated languages, it's possible to track complete type informations even they're elided.
I think those type-(notation)-less languages are making some efforts to offer type informations by adding annotations. But I don't think that's really meaningful, because that's not enforced, and community doesn't care much.
1. Dynamically strongly typed, but typing is limited to primitive types.
2. So actually it's untyped for objects which is really needs type information.
3. As it lacks class/interface concept at all, type (an)notation is fundamentally impossible, type tracking is also impossible.
4. So lacks ability to offer type information to toolset.
You don't have automated tooling support on Javascript about type, and it will degrade your productivity. So big companies interested on JS platform, are all offering JS with type notation -
1. Google = Dart,
2. MS = TypeScript,
3. Mozilla = Emscripten(in very unique way!)
I found one study[1] which concludes that unit tests are not enough to reveal all errors which would be revelead when using a statically typed language.
A small number of Python guys are trying to use more annotations for a sort of closer-to-staticly-typed Python. It's certainly not universal, or even a majority of developers.
I'm not just being purposefully obtuse here. When read in the context of his upstream comments, I don't think we can make any assumptions as to what he meant.
At least, what I mean was an ability to offer those type informations to automated tools - auto-completion system.
How actually Python type doesn't matter. Python lacks the ability by not forcing type (an)notation. This is fundamentally different with type-inferencing/deducing system such as Haskell, Go, C++11.
I think it's not "fundamentally different". Type info is there in the code, it's just much more implicit and requires much more work to extract and use. One thing which does just this is Jedi project (for python) and it's absolutely astonishing how much data you can get out of it!
Also I think that dynamic languages were meant to run inside a dynamic environment. For example in Pharo Smalltalk (probably all Smalltalks) every single piece of metadata is runtime data. Static analysis has no sense, because in Pharo there is no "static" at all - everything happens inside a living environment and (for example) as soon as you write a method it's turned into CompiledMethod object which has all the data about the method you would ever need for you to query easily. Good luck implementing better refactoring tools than those in Smalltalk for any other language.
Essentially the same approach is used in Emacs Lisp. For example, if you see a function you don't recognize, you can jump to it's definition. The thing here is that Emacs doesn't know where the definition is because of static analysis - it just has this compiled chunk of code in memory which happens to have a name you're looking for. This chunk of code knows a location of it's definition and many other pieces of metadata which are all available on runtime. It of course doesn't work if the function isn't already loaded into Emacs.
Most statically typed languages retain almost no type data in runtime. Most dynamically typed languages have almost no type data on compile time. I see this as largely equivalent.
So I guess what I want to say is that there is no fundamental difference in what the dynamic and static languages are, but there is (and should be) a very fundamental difference in how they are used. Choosing the between the two is I think almost exclusively a matter of preference. A good programmer should feel comfortable with both, though.
the irony is the use of javascript in solutions like Titanium,to code ANYTHING but the ui ( the business logic is in javacript , the ui is native ). I like the approach though, it's a better approach than phonegaps and likes. the only drawback : doesnt seem the engine they use is opensource.
RubyMotion is probably the closest I've seen to making a language like Ruby or Python a very compelling mobile developer experience while maintaining the end user experience.
That basically means you need to write a Python compiler for iOS or Android to make it compelling, which means adding type checking and at some point developers start asking why they aren't just using Java in the first place...