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

31–40 of 80 posts

Re: Swift Algorithms

#31

Post by fiddlerwoaroof »

ironmagma wrote: post #29
wlib wrote: post #16

Earlier quoted context omitted.

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…

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 language made out of macros isn't much different from learning a library with a large API surface area.

In fact, since macros reduce the noise in the "language" a library implements, I've generally found that macro-based libraries are somewhat easier to learn than libraries in other languages.

Re: Swift Algorithms

#32

Post by pjmlp »

bee_rider wrote: post #14
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.

Googling about this (I assumed the actual 'solution' would be a to use C-style awful macro kludges) eventually lead me to: https://blog.golang.org/generate Now I'm wondering if you joke was not actually a joke.

This is how C++ compilers used to work before templates came into the picture.

For example Borland's BIDS 1.0 in Borland C++ for MS-DOS, it was based on the C pre-processor, as you would define a set of macros and then include the desired type, something like

    #define LIST_T int
    #include 

    #define LIST_T float
    #include
and so on, however when BIDS 2.0 was released, there was already primitive support for the ongoing ISO discussions and it was rewritten to use templates.

To be fair, Go generics seem to be finally on their way to be adopted into the language.

Re: Swift Algorithms

#33

Post by xmprt »

bee_rider wrote: post #14
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.

Googling about this (I assumed the actual 'solution' would be a to use C-style awful macro kludges) eventually lead me to: https://blog.golang.org/generate Now I'm wondering if you joke was not actually a joke.

We have a lot of codegen in our codebase right now and I can't wait for the day that generics are finally added.

Re: Swift Algorithms

#34

Post by pjmlp »

setr wrote: post #10
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.

the solution is... to not use Golang! more specifically, fairly basic operations on a list of data does not seem like it should call for the complexity of a DSL. IMO unless you need to do this quite a bit on random datatypes, copy & paste would probably be the better alternative. Unless you're referring to a DSL that looks exactly like Golang but with generics & monomorphism.... in which case ok I guess

When that solution is possible, sometimes project requirements make us use tools that we rather not, but have to.

Re: Swift Algorithms

#35

Post by pjmlp »

typon wrote: post #19

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

Only if you are a language geek, and want to open you mind that C and C++ aren't the only game in town for systems programming.

Other than that, outside Apple platforms is still in a worse state than clang Objective-C + GNUStep.

Re: Swift Algorithms

#36

Post by eecc »

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…

Like Jetbrains MPS? https://www.jetbrains.com/mps/concepts/

Re: Swift Algorithms

#37

Post by pjmlp »

moksly wrote: post #30
austinl wrote: post #25

Earlier quoted context omitted.

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…

As a developer in non-tech enterprise, my biggest dream is probably swift being capable of targeting web and android. We don’t have the resources to currently target all three platforms, and we don’t have much hope for google frameworks as they tend to be changed/abandoned faster than we can afford to adopt them, and we can’t really rely on Facebook tech too much because of corporate ethics (I know it don’t make much…

Then try to see how much of it is possible as mobile Web, specially if it is just a CRUD application at heart.

Android's NDK is quite limited, its main purpose is to implement native methods for Android Java/Kotlin, outside games, there is very little you can achieve without going through JNI or Android IPC into Java land.

Re: Swift Algorithms

#40

Post by ironmagma »

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.

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.
Post reply on HN