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

351–360 of 432 posts

Re: Swift for TensorFlow Shuts Down

#351

Post by lmm »

6gvONxR4sf7o wrote: post #108
skohan wrote: post #88

Earlier quoted context omitted.

But to some extent isn't it always going to be bolted-on and dependent on library authors to which extent it's consistent?

The dependence on library authors is always a challenge in any language. You might have one author using `[a]` where another uses `PositiveNumeric a, Fin n => NonEmptyList n a` for the same thing. You can always just annotate whatever the library author used (e.g. they return a list of strings, so you use List[str]). There are some interesting further add ons that seem very python, allowing you to go further. For exa…

> You might have one author using `[a]` where another uses `PositiveNumeric a, Fin n => NonEmptyList n a` for the same thing. You can always just annotate whatever the library author used (e.g. they return a list of strings, so you use List[str]).

The difference between these two cases is that a function that returns [a] will always return [a] and if you convert it to `NonEmptyList n a` you will be nudged towards handling the case where it didn't actually return n elements, whereas if you annotate someone else's list as returning List[str] then it may well silently not do some of the time, and you won't get an error until a long way away.

Re: Swift for TensorFlow Shuts Down

#352

Post by max_ »

What is really needed in the ML industry is a code independent "neural net interpreter" with an api that binds to any programming language.

How hard is it to have a program that takes in neural network architectures & trained waits so as to do inference?

Re: Swift for TensorFlow Shuts Down

#354

Post by dragonwriter »

superbcarrot wrote: post #57
wendyshu wrote: post #50

Earlier quoted context omitted.

What are some ways in which Python's type system should improve?

It fundamentally can't be improved in a significant enough way and still be Python. The more realistic options are to be okay with Python's type system (I personally am) or to look at different languages if you really want something more robust.

> It fundamentally can't be improved in a significant enough way and still be Python.

Why not?

Static enforcement of invariants that doesn't change the space of what is possible in the language when you aren't asserting conflicting invariants doesn't make Python any less Python.

Re: Swift for TensorFlow Shuts Down

#355

Post by lmm »

bsaul wrote: post #322
cutler wrote: post #299

Earlier quoted context omitted.

I don't get the hype about Swift. There are at least 4 features in Swift I can think of that are just plain clunky: 1. Backslashed opening parens for string templating 2. Parameter labels and the use of _ when ignored 3. Splitting method names across opening parens eg. `move (to ....` 4. Verbose NSString Objective-C hangover in regular expressions

Those are really minor syntax details (except maybe the regex stuff, that’s more a library issue than a language one). Swift is safe (no null pointer exception), has predictable garbage collection performance through ARC, has a familiar C-style syntax (easier to get on-board), has compile-time type checking, good-enough generic programming support, algebraic data types with pattern matching, and will very soon get ac…

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 need to occasionally stop the world (ish) in a mark/sweep GC.

Re: Swift for TensorFlow Shuts Down

#356

Post by gurkendoktor »

mrtksn wrote: post #175
adevx wrote: post #149

Earlier quoted context omitted.

Could it be that you have more knowledge of Swift and don't care/want to invest in understanding Node.js/JavaScript? I really enjoy writing backend code in TypeScript for Node.js. But loath having to write Swift code for iOS. I know a big part is my unwillingness to invest time in Apple's ecosystem and properly learn Swift.

I used to work with web technologies but I got overwhelmed with the complexity of the tooling. For example, TypeScript is nice but it's not a "real" language in a sense that you can write something in it and expect it to work when it's fed into the compiler or interpreter. To use it, you need to set up an environment where all the moving parts are working in harmony and the code you write in Typescript is transcribed…

I agree about TypeScript, however this paragraph also describes Swift to a T:

> Sometime you have a library where someone a few years back tried to do something similar to your idea but never had a complete solution and stopped working on it and when you try to benefit from this work to build on top of it, you find out that you need to modify you working environment to support some spacial case of legacy code. You do that and it all falls apart, now you must choose to try to fix it or give up and restore your setup. It's just horrible.

So far Swift code has not aged well, although it's gotten better during the last two years. The perpetual brokenness has moved on to Swift's tooling (binary stability, SwiftPM etc.) which wouldn't affect serverless.

Re: Swift for TensorFlow Shuts Down

#357

Post by dragonwriter »

simias wrote: post #70
superbcarrot wrote: post #57

Earlier quoted context omitted.

It fundamentally can't be improved in a significant enough way and still be Python. The more realistic options are to be okay with Python's type system (I personally am) or to look at different languages if you really want something more robust.

I agree with you, although I must say that as an occasional Python user the way type hints are implemented absolutely baffles me. In particular the fact that they are completely ignored by the standard implementation. They're glorified comments. Given how opinionated the Python maintainers can be, it baffles me that they accepted to get these optional, noisy, half backed type hints into the core language. In my exper…

> Given how opinionated the Python maintainers can be, it baffles me that they accepted to get these optional, noisy, half backed type hints into the core language

Guido joined the Mypy team while he was Python’s BDFL.

Also, there’s nothing half baked about either Python’s type hints or Python’s type system, or it's major type checkers. It's not Haskell, sure, but it's an expressive to system, the typecheckers are reasonably smart, and the annotations are readable and sensible if somewhat verbose; there were some infelicities regarding alternate names for core types in annotations, but that's been improved recently.

> In my experience given that they're optional and you'll almost never get 100% of your code and its dependencies with correct and up to date signatures it's just a nuisance

In my experience they start to provide value in preventing bugs and easing development because of tooling support way below 100% coverage.

> If at least it triggered an assertion at runtime when the type doesn't match it would be massively more useful.

Python’s type annotations are annotations, and are used by some libraries for runtime (validation, serialization/deserialization, etc ) as well as static checking purposes (e.g., pydantic.)

> And even then, if you're so thorough with your typing, why not just use a proper statically typed language?

All a “proper statically typed” language is is a language with a static type checker run ahead of time, which Python is of you choose it to be. There's a lot of code in the ecosystem that is more broadly types than it needs to be, because no annotated code which checkers can't infer anything better for use Any, but that's evolving over time as it is more common for popular libraries to be typed, or at least have typings available.

Re: Swift for TensorFlow Shuts Down

#358

Post by threatofrain »

viktorcode wrote: post #337
sida wrote: post #316

Earlier quoted context omitted.

As weird as it sounds, the only thing that stops me from trying Julia is 1 indexing

0-based indexing is an artefact of pointer math. Modern languages don't treat arrays as a pointers to their first element. So, it is still with us only because almost no language designer decided to challenge existing convention.

I see 1-indexing as an artifact of a lot of linear algebra texts, whereas 0-indexing is more popular in analysis. Julia just wants it to be easier to directly copy formulas from publications.

I also think it’s blurry as to whether mathematicians and programmers see indexing numbers as merely indices or richer numbers.

Re: Swift for TensorFlow Shuts Down

#359

Post by dragonwriter »

ambicapter wrote: post #302
skohan wrote: post #199

Earlier quoted context omitted.

I disagree that it's "a lot " more readable. I have read a lot of camelCase code in my lifetime, and I can count on zero hands the number of times I ever had an issue parsing code due to the use of camelCase. Keyboard remapping seems like an extreme solution, and I don't want to train my fingers in such a way that when I sit down at a different workstation that doesn't have my .vimrc I can't type rust anymore. You do…

CamelCase is terrible as soon as you have an abbreviation in your function (like "DB"). I run into this extremely frequently at my place of work.

> CamelCase is terrible as soon as you have an abbreviation in your function (like "DB").

Yeah someone always wants to capitalize abbreviations/acronyms weirdly, or treat camel case like it was title case in handling short words or...

Getting people to be consistent with snake case is much easier, for some reason.

Re: Swift for TensorFlow Shuts Down

#360

Post by dragonwriter »

dagmx wrote: post #135
adsharma wrote: post #104

Earlier quoted context omitted.

Python type system is improving. Another point in this ease of use vs type safety spectrum is python -> type safe language static compilation. I don't know which one is the best. So I've been experimenting with several. https://github.com/adsharma/py2many

Is the Python type system improving or is it the type annotation system that's improving? Big difference between the two.

> Is the Python type system improving or is it the type annotation system that's improving?

Both. (The type annotation system is deeply tied to the type system, since the latter is what is statically verified, but there are improvements both in what can be checked—the type system—and how that is expressed/annotated.)

Post reply on HN