Should Your Start Up Go Static or Dynamic?(mahdiyusuf.com)
mahdiyusuf.com
Should Your Start Up Go Static or Dynamic?
http://www.mahdiyusuf.com/post/16746798643/should-your-start-up-go-static-or-dynamic
12 comments
Not impressed either. It also repeats the misconception that statically typed languages make it harder to do exploratory development. But with type inference, not only do I not have to define my variable types up front, the type checking makes it very easy to explore and refactor code,
especially when the exploration involves changing the types.
Add in the ability of haskell to let you write your own control structures and do higher-level programming, and I find myself exploring and refactoring my code much more than I do when using a dynamic language.
Add in the ability of haskell to let you write your own control structures and do higher-level programming, and I find myself exploring and refactoring my code much more than I do when using a dynamic language.
I'm with you. His example of dynamic typing is really an example of inferred typing.
If you would have read the article; clearly states what you said in the first line of your comment. Also your professor maybe right, the distinct is less clear when stated in those terms.
It was never said that static typing is for robustness it does decrease the occurrence of runtime errors.
I think the overall point was just to give insight on what people don't consider when making a programming language choice.
It was never said that static typing is for robustness it does decrease the occurrence of runtime errors.
I think the overall point was just to give insight on what people don't consider when making a programming language choice.
"Now if you are raging to some serious dubstep, its easy enough to miss that small typo, you go screw it and do it live, and deploy to production. Python will simply create the new variable and not a single thing will be said."
Erm... Did the author test this code before making this assertion?
Erm... Did the author test this code before making this assertion?
>>> def get_first_problem(problems):
... for problem in problems:
... return problam
...
>>> get_first_problem([1,2,3])
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 3, in get_first_problem
NameError: global name 'problam' is not definedmaybe he updated it? now it shows is an additional line:
Edit: formatting
def get_first_problem(problems):
for problem in problems:
problam = problem + 1
return problam
Edit: formatting
Only you can prevent people from listening to dubstep.
I think it might be a typo; the return doesn't seem to like returning variables that aren't assigned values.
> Dynamic languages are languages that don’t necessarily need variables to be declared before they are used.
Not exactly true. You do need to declare variables in some dynamic languages (var in JavaScript, for example), but you don't need to declare their type.
Anyhow, the whole question is a little irrelevant. The language you pick for your startup is among the factors least important to its success. Just pick a reasonable language that you are productive with, that has library support for the stuff you need, and that works well on the operating systems you care about, and that will be fine.
Not exactly true. You do need to declare variables in some dynamic languages (var in JavaScript, for example), but you don't need to declare their type.
Anyhow, the whole question is a little irrelevant. The language you pick for your startup is among the factors least important to its success. Just pick a reasonable language that you are productive with, that has library support for the stuff you need, and that works well on the operating systems you care about, and that will be fine.
You do need to declare variables in some dynamic languages (var in JavaScript, for example)
You can declare variables in JavaScript, but you don't need to. JavaScript is bad example here, as the var keyword is not really used for declaring but for scoping the variable.
You can declare variables in JavaScript, but you don't need to. JavaScript is bad example here, as the var keyword is not really used for declaring but for scoping the variable.
This discussion is missing two key things: Go and Dart. They both combine the best of static and dynamic languages. There is no need to choose, you can have the best of both worlds, without the disadvantages.
I'm using Go right now, it is amazing, blowing both Python and C# out of the water, with speed of development, robustness and maintainability.
I'm using Go right now, it is amazing, blowing both Python and C# out of the water, with speed of development, robustness and maintainability.
I am all for strong, static typing, but in fairness I don't see how C++ can be considered weaker than C?
Or alternately how F# is less static than Haskell or weaker than Scala?
Or am I just reading too much into the chart?
Or alternately how F# is less static than Haskell or weaker than Scala?
Or am I just reading too much into the chart?
…Or that Haskell, with arguably the most sophisticated type system in the world is considered less strongly typed than Ruby!
The graph makes no sense to me.
The graph makes no sense to me.
"Standard ML, Objective Caml and Haskell have purely static type systems, in which the compiler automatically infers a precise type for all values. These languages (along with most functional languages) are considered to have stronger type systems than Java, as they permit no implicit type conversions"
http://en.wikipedia.org/wiki/Strong_typing
http://en.wikipedia.org/wiki/Strong_typing
Good discussion, but I am sure the developer proficiencies will out weight any of the affects of the language choice in early stage.
That, and presence of existing frameworks, libraries, support, etc...
If you're asking this question this early, you're doing it wrong. Just code in whatever language you like and can pick up quick, build a product, talk to users, and iterate.
Your startup should go with "what works." The exact definition of what works varies for each person/company, but here's a list of things that aren't in it:
* Languages that entirely lack the needed libraries to perform a library-intensive task. (e.g. a CRUD web app in C++) * Languages that you do not know * Langauges that you only want to use because they're "hip" right now
* Languages that entirely lack the needed libraries to perform a library-intensive task. (e.g. a CRUD web app in C++) * Languages that you do not know * Langauges that you only want to use because they're "hip" right now
Nitpicking, perhaps, but I really would like the author to motivate why Haskel (sic!) is more weakly typed than say Ruby, Java or C#? Not sure how Ruby is less dynamic than Python either (besides the fact that his definition doesn't really admit a sliding scale), but that might be my relative inexperience with the languages showing.
No, you're exactly right. The author defines "weakness" versus "strongness" as whether you can do something like "int + array" and get a result other than a type error. ECMAScript is very "weak". Haskell is ridiculously "strong" by this definition, since you get a type error for computing "(1 :: Int16) + (1 :: Int32)". As far as stricter languages go, there is perhaps only Ada.
There are two kinds of language comparisons I've seen:
1. Language comparisons posted by dabblers, which you could scrape together by reading Wikipedia. You see a lot of poor logic and unsatisfying definitions, because if the logic were sound and the definitions useful, a dabbler would never have enough expertise to write the post.
2. Language comparisons by experts, which restrict the discussion to history, the underlying logic of type theory, or empirical observations about a small set of languages.
There are two kinds of language comparisons I've seen:
1. Language comparisons posted by dabblers, which you could scrape together by reading Wikipedia. You see a lot of poor logic and unsatisfying definitions, because if the logic were sound and the definitions useful, a dabbler would never have enough expertise to write the post.
2. Language comparisons by experts, which restrict the discussion to history, the underlying logic of type theory, or empirical observations about a small set of languages.
You're doing it backwards. You didn't get to choose the language, you use whichever language has the best libraries/frameworks for your problem domain.
funny, I've been writing haskell for years and don't remember "declaring" any variables even though its static and strict. author needs to check his definitions.
If you have to do graphs, here's one with credibility (solid scala/haskeller/
http://james-iry.blogspot.com/2010/05/types-la-chart.html
http://james-iry.blogspot.com/2010/05/types-la-chart.html
+1 for disambiguating haskell98 and GHC haskell
I think the trend is definitely for startups to choose Dynamic languages as well as choosing frameworks to go along with these languages often times.
When you are cash strapped, speeding up time to market often becomes the number one priority.
When you are cash strapped, speeding up time to market often becomes the number one priority.
If time is important, then language proficiency is more important than the dynamic/static choice. You don't want to learn the in-and-out of a language in the crunch time of delivering a product.
Also, his graph of languages doesn't really make any sense at all. If he just kept it as a division into groups, it would make sense, but it really looks like he's trying to say that C++ has a "weaker" (whatever that means) type system than C or that Haskell has a "weaker" type system than Scala.
Also, static typing is not always for robustness; it can also increase performance. C is a perfect example of this--it is one of the easiest languages to write bugs in but is also really fast.
Overall, I was not terribly impressed with this article--it gave poor definitions and little new insight (as far as I could tell, it just reiterated the same old cliches about static vs dynamic types without any anecdotes, experience or advice).