Live data from Hacker News

Have Static Languages Won?

pointersgonewild.com

91–100 of 120 posts

Re: Have Static Languages Won?

#91
post #88

Earlier quoted context omitted.

Go, Swift and Rust come to mind. Some alternative JVM languages aren't doing too badly either.

Swift is very much an Apple language, replacing Objective-C. You won't see it replacing JavaScript, PHP, Python, or Ruby. Same for Rust, which mostly replaces C++ and a bit of C. Maybe some Java, too, for people using Java for the safety despite really wanting something lower level. IMHO Go isn't much competition to most popular dynamic languages, but some people disagree.

It's anecdotal, but in the absence of anything more concrete... I think every blog post I've read about Go (bar one) that has mentioned the author's previous language mentioned a dynamically typed language. That may just indicate that switching to Go from a dynamically typed language makes you more zealous and likely to blog about it something. Or it could be that lots of Go users were previously writing Python/Ruby/etc.

Re: Have Static Languages Won?

#92
post #50

Earlier quoted context omitted.

OpenStack is the perfect example of how Python doesn't work well for larger projects. It's only because of an absolutely massive investment in testing that OpenStack works at all. I think it's more accurate to say that OpenStack works despite an unsuitable choice for implementation language.

I assure you that even if you wrote it in Haskell you'd have a few unit tests and integration tests in there.

I don't think he claimed otherwise. There's a difference between a code base that makes judicious use of tests to validate business logic and one that relies on the test suite just to keep it from falling apart. I've worked on the latter, so I know ;)

I'm not making any representations as to whether or not this is true of OpenStack. I honestly wouldn't know.

Re: Have Static Languages Won?

#93

Earlier quoted context omitted.

I mean every language has a baked in sort function, so maybe that is a bad place to start :) Java collection signatures are not super complex but they have fundamental bugs fixed in the slightly more complex scala collections type signatures.

No I mean using the sort framework of Go. It takes several steps to set up a comparator function. compared to list.sort(function(a,b){return comparisonResult}) that was very demotivating to me.

It seems like quite a few people have found that the simplicity of Go's type system just winds up transferring the complexity to your code base, instead of in the language implementation. I find it interesting how divided the opinions are on this.

Re: Have Static Languages Won?

#94
post #63

Article points to http://wtfjs.com/ to show "glaring flaws" of JS. JavaScript is not perfect, but almost all what is presented on sites similar to wtfjs.com are non-issues to me. It may be stupid or surprising that API behaves in some ways, but as long as it behaves exactly as in documentation it is not much of a problem. I always check available documentation even for basic APIs in every language that I use. i.e. I…

Two things: a) Maxime works on a compiler for JS, so even if something is documented to death, it usually makes analyses less precise and/or more complex. b) Many statically-typed languages have a REPL (OCaml, Haskell, Scala); this is not an issue with the typing discipline, but with the tools available to the developers.

With type inference, a REPL can even tell you things about code that can't run yet!

    Prelude> :t mapM undefined [5,6,7]
    mapM undefined [5,6,7] :: Monad m => m [b]
This can get even more informative with Typed Holes:

    Prelude> mapM _whatFunc [5,6,7]
    
    :14:6:
        Found hole ‘_whatFunc’ with type: Integer -> m b
        Where: ‘m’ is a rigid type variable bound by
                   the inferred type of it :: m [b] at :14:1
               ‘b’ is a rigid type variable bound by
                   the inferred type of it :: m [b] at :14:1
        Relevant bindings include it :: m [b] (bound at :14:1)
        In the first argument of ‘mapM’, namely ‘_whatFunc’
        In the expression: mapM _whatFunc [5, 6, 7]
        In an equation for ‘it’: it = mapM _whatFunc [5, 6, 7]

Re: Have Static Languages Won?

#95
post #4

An alternative is optional static languages like Groovy or alternatives like python Type Hints ( https://www.python.org/dev/peps/pep-0484/ ) are better than pure dynamic languages.

A dynamic language with optional static typing is still a dynamic language that offers its own syntax for dispatching to statically typed code. Python originally offered easy dispatch to C++ code, and Groovy to Java code. The typing guarantees aren't really in the dynamic language there if it's optional.

There's also the commercial aspects of static typing in a dynamic language. After 10 years, Groovy introduced the annotations to optionally statically compile code in order to compete with Java instead of complementing Java, which changed the business purpose of the language and their relationship with Oracle.

Re: Have Static Languages Won?

#96
post #21

Earlier quoted context omitted.

Anecdotally, on my year around 75% of students were there just because CS was supposed to bring money. They've started CS studies while not knowing how to program, knowing nothing about operating systems or caring. For them it was a 9-17 future job, nothing more.

First time I've ever heard a 9-5 job called a "9-17" job. Decided to Google it to see how common it was, and all the results are for the Bible verse Job 9:17 - > He would crush me with a storm and multiply my wounds for no reason. Seems appropriate for some "9-17" jobs.

Far more appropriate than Job 9:5:

> He moves mountains without their knowing it and overturns them in his anger.

Re: Have Static Languages Won?

#97
post #21

Earlier quoted context omitted.

Anecdotally, on my year around 75% of students were there just because CS was supposed to bring money. They've started CS studies while not knowing how to program, knowing nothing about operating systems or caring. For them it was a 9-17 future job, nothing more.

Well people come from different backgrounds. I went to UIUC having taken the only programming class my High School had, QBasic. I was in wayyyy over my head in my first C class slinging pointers all over (and then LISP - whoah). Other people came in after programming as a part time job for a few years. I think it's a little quick to say someone came in for the money because I came in not knowing a ton of programming.…

I don't have any idea which side of the divide you'd fall on, but when I was in school there was definitely a group of people more likely to say "I'm taking X because it sounds really interesting" and a group of people more likely to say "I'm taking Y because I heard it's an easy A".

Given the timing (tail end of the last bubble), I always thought of the second group as "there for the money".

As with any generalization, it breaks down in plenty of specific cases.

Re: Have Static Languages Won?

#98
post #29
post #8

> You can have statically compiled languages that use type inference to realize what is effectively dynamic typing. Just because you don't have to explicitly write out the type does not make it any less static. I believe that the usual arguments against languages with static typing such as verbosity and lack of flexibility are largely eliminated by the more modern languages such as Scala, Kotlin or Typescript (though…

> Just because you don't have to explicitly write out the type does not make it any less static. No, but not having to write the type was one of the biggest attractions of dynamic languages -- a lot of us didn't care that much for being fully dynamic, but just enjoyed the less ceremony of dynamic languages. As for not having to commit to types for some cases, STL languages can also have a "void *" or "variant" or "dy…

'As for not having to commit to types for some cases, STL languages can also have a "void " or "variant" or "dynamic" type (a la C#).'*

Even Haskell has Data.Dynamic, though it's not often used.

Re: Have Static Languages Won?

#99

Earlier quoted context omitted.

There is one other undeniable advantage to dynamic languages: you can express things in a dynamic language that you can't in a static one. Static languages try to be as sound as possible, at the cost of some completeness. Dynamic languages are less concerned with soundness and can be more complete. As an example, duck typing is usually not possible to achieve in a static language - it's really hard to allow duck typi…

Question is, how many real-world cases there are where duck typing is super beneficial. Usually if you need a bunch of differently-typed objects to fulfill the same contract, you can just make them implement an interface (said interface can also be documented, etc., it makes the intent very explicit). I do believe there are cases where dynamic typing is genuinely useful, but those make up a very small portion of real…

One place where I ran into this was when I was building an ETL framework in Scala. The scenario was that I wanted to be able to move data from one database system to another and not have the end user of the DSL have to care about the types. The use case was essentially that you should be able to show up to an arbitrary database, run a query, and then pump that output somewhere else (e.g. another DB, flat file, transformation function, etc...)

I went around in circles and ultimately concluded no amount of type inference or other things in Scala's bag of tricks would let a user of the API avoid the dreaded type cast.

I have often seen this situation whenever I have tried to write generic code in a static language that needs to interact with a database.

Re: Have Static Languages Won?

#100

Earlier quoted context omitted.

I agree, I think optional or gradual typing is the future for dynamic languages.

So a big project with optional typing. How do you handle it? Each person picks a level? Or make rules that all services are strongly typed but within a method is loosy goosy? I see the project going one of two ways. One all loosy goosy. One all statically typed. At which point what did optional typing add? Pick a side and go for it.

I see it as a gradual thing. Early in the project loosey and then as the software matures add in more typing. But yeah, everyone needs to agree on the right level for that stage in the project.
Post reply on HN