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

Swift Algorithms

swift.org

Post reply on HN
Print view View original

41–50 of 80 posts

Re: Swift Algorithms

#41

Post by mikkelam »

I would love to go and use swift at my work (working in robotics). But swift just doesn't feel mature enough for barely anything outside of iOS/macOS. I had a great time using it for that purpose. The community outside of that ecosystem is barely there.

I've picked rust instead, it feels like the exact opposite of the single large actor supporting swift, instead it's a huge community effort with lots of use cases already being seen in many spaces. AND rust just got AVR support which I suppose swift could get pretty quickly with llvm as well

Re: Swift Algorithms

#42

Post by Philip-J-Fry »

ironmagma wrote: post #40
hazz99 wrote: post #21

Earlier quoted context omitted.

"Good" is meaningless – there is no absolute measure of the relative value of one programming language over another. C is not "better" than Python, or vice versa, just different tradeoffs for different problems and programming styles. The same is for Go.

Kind of, but C and Python have undergone many iterations to try to become as good as they can be, while Go has lagged behind and almost prides itself on how uncomplex it is which is unfortunate only because people crave for it to be more complex. With languages like C and Python, the complexity and capability is there; it’s on you to decide when to use it. With Golang, you are just SOL.

The thing is, do you want so many iterations to get something close to being good. Or do you want people to work with the community and decide together what a feature should look like and then get it in a good shape at day 1.

Like, ask any python dev what dependency management is like. That's what iteration gets you. Take your time and you get in a much better shape.

Re: Swift Algorithms

#43

Post by Cthulhu_ »

mikkelam wrote: post #41

I would love to go and use swift at my work (working in robotics). But swift just doesn't feel mature enough for barely anything outside of iOS/macOS. I had a great time using it for that purpose. The community outside of that ecosystem is barely there. I've picked rust instead, it feels like the exact opposite of the single large actor supporting swift, instead it's a huge community effort with lots of use cases alr…

Yeah, back when we first started using it there was a lot of interest in using it to create back-ends as well, but there just wasn't a lot of support for it. For one, it needed to be developed and compiled on a not-Mac environment to be viable, and that has just never been much of a thing. Might be better now, it does just use LLVM in the back-end and IntelliJ has a good editor for it, but still.

I think C# had that problem for a long time, but Microsoft did a great job / made a great strategic decision with .NET Core I think.

Re: Swift Algorithms

#44

Post by Cthulhu_ »

mhh__ wrote: post #13
pmiller2 wrote: post #9

Earlier quoted context omitted.

Sounds to me like a job for a DSL that compiles down to Golang for the final output. That way, the repeated code only exists in the Golang output and not in the code that humans actually write.

If you do that you have no soul. Why complicate it when you can just have generics that work from the get go

Because generics is a nontrivial problem to solve in languages and compilers; a really great comment that I bookmarked is here: https://news.ycombinator.com/item?id=9622417. I read elsewhere (can't find it now) just how much lines of code and language spec is dedicated to generics in Java.

Right now, the Go spec + compiler chain are a lot simpler; adding generics would have made things a ton more complicated. Second, by first spending a lot of time perfecting the core language, understanding it, and resolving early issues, they have a much more stable base now to build generics on top of it. As the comment also implies, they take things slow and steady when it comes to Go; it's a language made to run core systems (e.g. at Google) for the next 30-50 years.

Re: Swift Algorithms

#45

Post by saagarjha »

wlib wrote: post #16
benhoyt wrote: post #15

Earlier quoted context omitted.

Yeah, though a solution is in the works, and looking pretty likely to happen. Here's the official draft design for generics or "type parameters" in Go: https://go.googlesource.com/proposal/+/refs/heads/master/des...

Dependently typed Golang when?? In all seriousness, it feels like go's reputation of simplicity is at odds with its design. Instead of making a simple and highly generalized core from which anything can be composed, it has a specialized, familiar core that engineers are comfortable with. When I take this question further, I begin to wonder why we even use text syntax for programming. What if we just had a graph struc…

Text is readily manipulated using a variety of tools.

Re: Swift Algorithms

#46

Post by bee_rider »

austinl wrote: post #25
typon wrote: post #19

Is Swift worth learning if you're not going to be doing Apple development?

As an iOS engineer, I'm a bit biased, but I'd still say it's currently not practical to learn it if you're not doing Apple development. That said, I love the language, and it's a big part of what motivates me to continue being an iOS engineer (I'm not sure I'd still be at if we had kept on with Objective-C). I would love to see server-side Swift take off, but the ecosystem is still fairly new, so any large project wo…

That github differentiable programming link was an interesting read. It reminded me of interval arithmetic in the same sort of "But wait, why can't we just jam math into this program" vibe. Very neat.

Re: Swift Algorithms

#47

Post by fauigerzigerk »

fiddlerwoaroof wrote: post #31
ironmagma wrote: post #29

Earlier quoted context omitted.

You can do that but the cognitive overhead of understanding what code is represented becomes more of a burden than the burden of producing logic that is correct and fulfills requirements. You can see part of this in lisps where the arguments of many functions form their own de-facto languages. Then you are not only writing code, but writing it in a variety of different languages that share only a common syntax.

The thing is, I've never found this to be a huge issues in lisps: partly because plenty of languages have libraries that are essentially the same sort of thing, but less ergonomic: Spring/Hibernate in Java, Spark and the various FP stuff in Scala, Ruby on Rails, React. Any sufficiently complex library is essentially an embedded language that must be learned in addition to the base language: the cost of learning a lan…

Here's the dilemma as I see it:

A carefully designed library that introduces a small set of coherent concepts can make good use of powerful syntactic abstractions and result in readable and succinct code.

But application code that implements a large number of one-off requirements is far harder to read if you cannot rely on fixed semantics of basic syntactical elements.

The usual response to that is to say that we shouldn't restrict the features available to good developers just because bad developers might abuse them.

But this argument is flawed. If you read syntax that can be overloaded then you have to account for the possibility that it actually is. It's the possibility that creates the mental burden, not the fact.

I think the solution is for languages to provide a basic set of syntactical elements that cannot be overloaded and are sufficient to write all code. Additionally, there should be optional syntactical elements that can be overloaded even to the point of creating DSLs.

The important point is, there has to be a local cue that tells you whether or not you have to watch out for redefined semantics.

Re: Swift Algorithms

#48

Post by vips7L »

hazz99 wrote: post #21
vips7L wrote: post #18

Earlier quoted context omitted.

Instead of just using an actual good language?! Go is the problem!

"Good" is meaningless – there is no absolute measure of the relative value of one programming language over another. C is not "better" than Python, or vice versa, just different tradeoffs for different problems and programming styles. The same is for Go.

I think there is some measure of value to not having to use a whole different language to generate go because it's incapable of making maintainable code without it.

This is stockholm syndrome.

Re: Swift Algorithms

#49

Post by zapnuk »

Looks great. But I wonder why there are platform requirements for what seems to me like pretty basic functions.

In RandomSample.swift:

  // For log(_:) and exp(_:)
  #if canImport(Glibc)
  @_implementationOnly
  import Glibc
  #elseif canImport(Darwin)
  @_implementationOnly
  import Darwin
  #endif
1. Why aren't those 'basic' functions already implemented in swift, and part of a math package (or in numerics)?

2. Why release a package that does not support windows now that windows is officially supported?

Re: Swift Algorithms

#50

Post by hazz99 »

vips7L wrote: post #48
hazz99 wrote: post #21

Earlier quoted context omitted.

"Good" is meaningless – there is no absolute measure of the relative value of one programming language over another. C is not "better" than Python, or vice versa, just different tradeoffs for different problems and programming styles. The same is for Go.

I think there is some measure of value to not having to use a whole different language to generate go because it's incapable of making maintainable code without it. This is stockholm syndrome.

Part of Go’s tradeoff is managing that extra effort (or delay in waiting for the features to hit the main branch) in return for an extremely stable, simple language.

You might find that to be a terrible idea, but others ostensibly think differently (Go is quite popular)

Personally, I prefer more advanced type systems. But I understand Go can be a good choice in other situations.

Post reply on HN