HN user

taesis

89 karma
Posts2
Comments33
View on HN

Aah, thanks for the clarification :) the top voted comments on this article now indicate that as well, so hopefully no one else will have the same confusion.

Shell Style Guide 8 years ago

Aah, makes. I'm not a huge fan of it for similar reasons, but the appeal of a language that's quick, dirty, and relatively acceptable by coworkers is strong.

Shell Style Guide 8 years ago

Re. a recommended alternative to quick and dirty bash scripts, do you think golang would do? I've barely dabbled with the language, but its default packaging (a single, static binary) and build system (`go build x`) seem well suited to rapid setup, deployment and testing, which is presumably what you'd want in this scenario.

May I ask where you invested your time in learning Scala (e.g. reading the red book, studying type theory, syntax + stdlib + collections, etc.)? I found I could read simple Kotlin in a couple afternoons, and after a couple weekends, I felt pretty comfortable with it. The only difficult concepts to wrap your head around, I'd say, are type safe builders [1] and coroutines [2], but you certainly don't need to know those to be productive in the language.

To answer your specific question, however, if you're doing Android development it's worth it :) otherwise, it's up to you/your specific situation.

[1] https://kotlinlang.org/docs/reference/type-safe-builders.htm...

[2] https://kotlinlang.org/docs/reference/coroutines.html

AFAIK, it's popular on Android because it provides e.g. Java 8 stream-like functionality without needing support for that baked into ART, which is something. Additionally, it supports compilation to Javascript [3] and early support for JVM-less execution ("native") [4]. No new abstractions or ideas, though; the language designers were aiming to make something that formalized current best practices, not lay down new ones.

Beyond that, it's nothing that you couldn't cobble together without the standard Guava + Commons + Lombok + Quasar/EASync etc. libraries and plugins that you'd use on every project written in Java, as well as that terseness you mentioned that makes people excited (see Kotlin data classes [1] vs Lombok data classes [2], if/try returns values and destructuring [5], coroutine support for lightweight threading and generators [6], null safety w/o optionals and smart casting, etc. [7]).

In my opinion, it's hard to know what value those features provide without actually trying them out yourself. If you want to be certain that you're not missing something, I'd suggest writing up a little script to try out some of its features.

edit: Just noticed the other responses on this thread. It's also very useful for starting fights with Scala developers, apparently.

[1] https://kotlinlang.org/docs/reference/data-classes.html

[2] https://projectlombok.org/features/Data

[3] https://kotlinlang.org/docs/tutorials/javascript/kotlin-to-j...

[4] https://kotlinlang.org/docs/reference/native-overview.html

[5] https://kotlinlang.org/docs/reference/control-flow.html

[6] https://kotlinlang.org/docs/reference/coroutines.html

[7] https://kotlinlang.org/docs/reference/null-safety.html

To quote the page (emphasis is theirs):

"COMPATIBILITY

MacBook Google Chromebook Pixel MacBook Pro (2016) Dell XPS 13”

So those devices work and everything else is a bonus, I guess.

Not sure if it bothered anyone else enough to look, but I tracked down the missing source for the header image [1]. The U.S. Declaration of Independence [2] is another nice example of handwriting, but unlike a random, faded (and potential non-English?) recipe, it seems very legible and might not have helped the author's argument.

[1] https://www.flickr.com/photos/calliope/5094055919/in/gallery...

[2] https://upload.wikimedia.org/wikipedia/commons/8/8f/United_S...

edit: Phrasing

Edit: You don't really need monads any more than you need classes, interfaces, functions, procedures (just use goto!), etc. they just help bring a bunch of seemingly disparate functionality together into one standard (which is helpful in, e.g. Scala or Haskell where there's some syntactic sugar for dealing with monads). People complained for the longest time (amongst many, many other things) that Javascript lacked classes, even though you could totally hack it together with `new`, functions and prototypes. Similarly, FP people complain that everything else lacks monad support, even though they can hack it together with largely language independent features (typically without compile-time checking).

I don't have an intuitive grasp of the formal definition of monads, but some examples of things that I _think_ are monads (in Java ... sorry :/ it's all I work with these days):

* jOOQ [1]: you use it to build up a sequence of SQL statements with a pleasant chaining API, then execute the whole shebang * Promise/future chaining: you build up a sequence of promises that should apply in-order, then defer their execution until later (unless you use a language that performs a transformation at compile time which effectively does this for you). * Streams/optional mapping: you build up a sequence of functions that should apply in-order to every element in a potentially empty sequence (optional: a sequence of 0 or 1). * The builder pattern: you build up a sequence of property values, then (potentially) construct the entire object.

[1] https://www.jooq.org/

My workplace uses a rubric for determining when a developer qualifies for a promotion (+raise), which seems very similar to this. I'm not sure why both spur an immediate sense of revulsion in me, but they certainly do and the feeling is intense. Just wondering, but does the same happen to anyone else? Did you ever figure out its root cause?

shrug I wouldn't know, but as I understand it, people will sometimes spend a lot of money on hobbies. Also, I'd hope that most software developers don't need the best-of-the-best laptops to do their jobs -- perhaps this is targeted at video editors, or pro gamers?

I suppose I'm not arguing from the perspective of fairness, but moreso about incentives + experience. If we applied the author's argument against other fields and languages, e.g. machine learning and python, then the cpython maintainers would be right in including TensorFlow in the python stdlib (or whichever competitor dethrones in and sticks around for long enough).

That doesn't sit well with me, at least. I'd want the top ML developers looking at TensorFlow, and the best language implementers doing the same for cpython, not the latter trying desperately to improve code they have no expertise in. From that perspective, what matters is community: is there a knowledgable community supporting codebase 'x', where x could be the stdlib or some third party library. Some other commenters in this thread proposed better library curation/discovery tools in place of a formal commitment of long term support by the core team, which seems ideal! Using such an approach, you rely on the language for the core-language bits, and on third parties for the third-party bits, which seems on the surface to be healthier than arbitrarily choosing the only constant group (core language devs) as your supporters of everything.

It seems like the core thrust of this article is that someone isn't around to perpetually support the libraries the author would like to use; i.e., he/his company is unwilling to fork out the money for someone to keep the 'blessed' libraries fully up to date -- so now that's the implementer's problem! I can understand wanting stability and a promise of timely updates for all one's dependencies, but it doesn't seem like the core language team is the right group to foist that responsibility upon.

Since you have way more knowledge in this area than I do, would it ever make sense to use a radio frequency laser (if that's even possible) for point to point communication? Like, to cut down on signal loss and etc. in much the same way as visible light lasers perform better than LEDs. I'm completely unknowledgable about physics, so that may not have made any sense XD but I'm interested in the answer!