Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Swift for TensorFlow Shuts Down

github.com

Post reply on HN
Print view View original

421–430 of 432 posts

Re: Swift for TensorFlow Shuts Down

#421

Post by 6gvONxR4sf7o »

lmm wrote: post #413
6gvONxR4sf7o wrote: post #402

Earlier quoted context omitted.

I was unclear. I meant the other way around. In the case that the third party code does in fact always return no empty lists of positive numbers, the author might just type it as a list. A third party author in even a language like Haskell won’t necessarily use the bells and whistles of giving very specific types. And by the List[str] bit, I mean you can annotate it as doing whatever it in fact does. You aren’t prote…

> In the case that the third party code does in fact always return no empty lists of positive numbers, the author might just type it as a list. Yes - but as I said, you can be confident that the list type is accurate, and if you want to convert that list to a specific-length list type then you're nudged towards doing it in a way where you handle the case where the list isn't actually the length you specified. > And b…

> You aren’t protected if you get that wrong, of course, and that’s where things like stubs come in to help.

Re: Swift for TensorFlow Shuts Down

#422

Post by lmm »

6gvONxR4sf7o wrote: post #421
lmm wrote: post #413

Earlier quoted context omitted.

> In the case that the third party code does in fact always return no empty lists of positive numbers, the author might just type it as a list. Yes - but as I said, you can be confident that the list type is accurate, and if you want to convert that list to a specific-length list type then you're nudged towards doing it in a way where you handle the case where the list isn't actually the length you specified. > And b…

> You aren’t protected if you get that wrong, of course, and that’s where things like stubs come in to help.

They don't really though? Stubs are just as unchecked as writing the type signature yourself, so even if they're correct at a given point in time, they'll tend to become incorrect for subsequent releases of the libraries they cover.

Re: Swift for TensorFlow Shuts Down

#423

Post by jose_zap »

GregarianChild wrote: post #370
lmm wrote: post #355

Earlier quoted context omitted.

Swift just seemed like yet another OCaml-like language to me; there are certainly far worse languages to borrow from, but I don't see any compelling reason why I'd use it over OCaml. ARC has the same worst cases as mark/sweep GC AIUI; exiting any scope might cause an arbitrarily large amount of cleanup work in the general case, and it doesn't solve the memory fragmentation problem which is the main reason you still n…

I agree from a technical POV, but there is a social reason (network effect): Swift has Apple-backing, OCaml is not currently supported by any of the big, influential software companies. OCaml's main backer now is Jane Street who do a lot, but is too small, and Facebook's support (via ReasonML) is too half-hearted to be compelling. As a former OCaml programmer, I would not currently bank a career or startup on OCaml.…

You can also use Haskell with the Strict pragma enabled for your own code if laziness is a concern.

Re: Swift for TensorFlow Shuts Down

#424

Post by nsonha »

saagarjha wrote: post #230
coolspot wrote: post #46

Earlier quoted context omitted.

WebKit started as KDE’s KHTML/KJS and LLVM started as a research project at Univeristy of Illinois. Apple took the code and extended it, they had little choice for the source code license. https://en.wikipedia.org/wiki/Webkit https://en.wikipedia.org/wiki/LLVM

They could have just not taken the code, though…

yeah, they're doing the world a favour by taking the code and conform to its licence, as opposed to... developing a new browser engine which is... easier?

Re: Swift for TensorFlow Shuts Down

#425

Post by nsonha »

cutler wrote: post #303
stmw wrote: post #214

This is sad for the project itself, but I predict that the coming programming competition will be Rust vs. Go, not Swift -- as Swift was always a distant third among the "new" languages. And of course the more mature languages will continue to be popular and widely used for decades. In my opinion, Rust will end up winning this contest, but others have perfectly good arguments against that view. Unfortunately for serv…

I think Kotlin will become the dominant JVM language in time.

that's obvious to me, what sounds more like a prediction is kotlin to be a dominant application development language (fullstack/scripting) natively compiled or on the JVM

Re: Swift for TensorFlow Shuts Down

#426

Post by ckok »

raydev wrote: post #82
ChrisMarshallNY wrote: post #64

Earlier quoted context omitted.

I suspect that we'll be seeing ObjC for a long time, as the lower-level system language for Apple devices. I know that Apple still uses it for much of their system programming. No idea if that's by choice, or legacy (possibly both). I was looking at the upcoming async/await stuff for Swift, and it's still not comparable to some of the lower-level threading systems. That said, I have not done system programming for a…

We'll see it in legacy code for a long time, sure, but there's every indication that all new Apple frameworks are being written in Swift. Anyone starting a new project in Objective-C is in the minority.

The annoying thing is that all these new libraries can only be used from swift. As interop with swift is a pain from any other language.

Re: Swift for TensorFlow Shuts Down

#427

Post by adsharma »

dagmx wrote: post #213
adsharma wrote: post #201

Earlier quoted context omitted.

The lack of algebraic data types is what python gets criticisms about. That situation is improving, but I would have preferred match to be an expression rather than a statement. What else is missing in the python3 type system?

Actual static typing and forced type checking.

I get that you're not particularly excited about gradual typing and the fact that type checkers are optional and live in a separate ecosystem from the interpreter/language runtime.

I actually like the fact that python code without type annotations continues to work as before and allows for easy transcription of ideas into testable code.

If a certain use case requires "forced" type checking, it shouldn't be hard to write a lint rule that disallows code from being committed if there are type checking errors, including missing type annotations.

Re: Swift for TensorFlow Shuts Down

#428

Post by codethief »

kortex wrote: post #373
codethief wrote: post #350

Earlier quoted context omitted.

My view is completely opposite to yours. I find type hints extremely useful and every new line of Python code I write uses them. I finally no longer have to do type checking / duck typing in my head but can simply write the types down. Moreover, an IDE like PyCharm will then do the type checking for me, notifying me of potential errors. (Even if I decide not to use Mypy.) Third, I finally only need to look at the sig…

Bingo. I think a big explanation of the wide variance on opinion about type hints is due to reliance on tooling, or lack thereof. Writing type hinted python in Pycharm or Ipython feels like racing in a sports car. Without it, feels like stop and go traffic with the occasional car accident. I can see how if you are using a WYSIWYG editor, type hints feel like more text for little gain. But even then, it really helps d…

> Writing type hinted python in Pycharm or Ipython feels like racing in a sports car. Without it, feels like stop and go traffic with the occasional car accident.

This is a beautiful analogy!

As for the second part, though, I would say that even if your IDE does not provide automatic type checking, type hints will still add some benefit because:

- without type hints you have to do all type checking in your head (across all stack frames).

- whereas with type hints you only need to do type checking down to the first level of the stack.

To illustrate what I mean, consider the following code:

  def bar(param1, param2):
      ...  # Some complicated code from which it is not immediately clear what values are allowed for param1 and param2, nor what the return type of the function is.

  def foo(param):
      return bar(param, param2="some default value")

  foo("something something")
Now, in order to verify that `foo("something something")` is correct, you have to manually look at foo() and then at bar(). Needless to say, this adds a lot of mental overhead to the game. If we added type hints to both foo() and bar(), however, you would only have to check the signature foo() – which, even in IDEs without type checking, usually amounts to hovering over `foo("something something")`.

Re: Swift for TensorFlow Shuts Down

#429

Post by dagmx »

adsharma wrote: post #427
dagmx wrote: post #213

Earlier quoted context omitted.

Actual static typing and forced type checking.

I get that you're not particularly excited about gradual typing and the fact that type checkers are optional and live in a separate ecosystem from the interpreter/language runtime. I actually like the fact that python code without type annotations continues to work as before and allows for easy transcription of ideas into testable code. If a certain use case requires "forced" type checking, it shouldn't be hard to wr…

The issue though is that Python's type annotation is not a substitute for type checking. Annotations are optional and can be inaccurate.

That's fine, this is part of the design of Python. However strict type systems are a benefit of other languages, that may not fit Python. Type annotation shouldn't be considered an alternative to a type system.

Re: Swift for TensorFlow Shuts Down

#430

Post by potiuper »

GregarianChild wrote: post #392
pjmlp wrote: post #390

Earlier quoted context omitted.

> ...F#/C# being JIT'ed... Nope, NGEN exists since .NET 1.0, .NET Native since Windows 8, Mono aot since ages, and then there are the third party tooling like IL2CPP.

Thanks. I was not aware of this, since I've not worked on a Microsoft stack for a long time. Are those F# AOT compilers mature and support all features, including libraries? In this case F# would be a viable alternative to OCaml for Jane-Street-like tasks.

Yes, but GC is usually seen as the major .NET performance concern not AOT vs. JIT, which may be faster in some instances.
Post reply on HN