HN user

Ironballs

135 karma
Posts1
Comments39
View on HN

Having a team member create production code in a language nobody else on the team understands is a risky decision. That applies for anything, software, systems, infrastructure... if one developer is allowed to sit on something, what happens when the dev leaves? Or dies? And the thing he or she worked on had a non-trivial learning curve?

Choosing something like Haskell or anything else niche should be a group decision. Even when it comes to prototyping! "Guys, I'm going to prototype this .NET code in F#. Who wants to join?", instead of a developer sitting in a corner applicating his functors while others around him do something arguably simpler. It's incredibly short-sighted!

This is not aimed at you though, since I'm not sure if this was your case, I'm only guessing based on your post.

The principal data structure of Lisp is a list which is written like this: (a b c d). Like the article mentions, when you see Lisp code you're in fact reading the same list syntax, only that, when the list itself is not quoted, the "a" is evaluated as a function, which is why (+ 1 2) behaves the way it does. If you quote the list by saying "'(a b c d)" then it is a list of symbols, so "'(+ 1 2)" does nothing.

Hence, Lisp code is made of nested lists. When you think further about it, it means that Lisp metaprogramming facilities may do things just with plain list manipulation functions! So it's not about metaprogramming itself, it's that it's incredibly easy. This is what people refer as "code as data" and "homoiconicity" and so on.

"If you know you will never change the implementation or configuration of some dependency, there is no benefit in using dependency injection.".

It all boils down to this.

Here's the catch, though: with dependencies, it is really, really hard to know you will never change the implementations. In most languages, implementing dependency injection is so trivial that it is always worth it. The work associated with changing implementations that aren't built with some form of loose coupling is in most cases, non-trivial.

From what I've seen, Clojure has a strong type system, but is dynamic. These terms aren't orthogonal. If I understand correctly (+ 'a' 1) is not allowed. Immutability only strengthens it.

I ask this because I've been eager to get my hands dirty with Clojure. I have experience with other functional languages (Haskell, OCaml, F# and some Emacs Lisp), so the paradigm isn't new.

I've looked at core.typed, but doesn't seem as neat as the syntax of Typed Racket. It's something, though. Is it checked at compile time?

What irks me is that static typing and type inference can make code feel really robust, and for the lack of a better word, safe. In Clojure I see a lot of nice things but the lack of typing, though common for Lisps, always bothers me a bit. I don't like runtime errors that happen because the compiler wasn't able to tell me that this object doesn't have that method. JavaScript's undefined is not a function or its kin in Python are examples of this behaviour, which I don't like.

Though, I see that Clojure's answer to this is rapid REPL development--which is great!--and unit testing, and what I've recently discovered, pre- and post-conditions. But it still feels somehow inferior.

I am torn between learning Scala or Clojure. Knowing OCaml and F#, Scala doesn't look that interesting, messy and multi-paradigm. Clojure appeals to me because its a Lisp and has one paradigm, but on the other hand I'm scared by runtime exceptions.

Should I just ignore my trepidations and proceed?

Code readability is the original intent behind striving for simplicity.

Though I find some of the design choices a bit frustrating, e.g., generics, lack of min/max; for each design choice I disagree with there are dozens of other choices I do agree with. Structural typing, built-in concurrency, a rich standard library, the syntax, the list goes on.

There is a certain brutal elegance to the way the Go standard library is designed, it is really easy to read and comprehend. It took me less than half an hour to make sense how the net/http server was implemented.

This doesn't only apply to the standard library: because the language style is standardized--there are no coding styles, there is just a coding style--other libraries or programs are very easy to understand. If the program architecture is easy to understand, it doesn't require any significant domain expertise to understand.

Languages aren't supposed to be cargo cults, though some culture can be nice, let's not kid ourselves: programming languages are means to to an end. Go is pragmatic, it gets things done, it is a tool, and most importantly, it doesn't get in the way of design or architecture. You are free to build programs in any style or way you want.

Ultimately, languages are just expressions of grander designs that are far more important than arguments for and against a particular syntax or language feature.

The Paperwhite isn't a backlit display.

The LEDs in the Paperwhite Kindles do not shine light directly in the eyes: the leds shine from below the screen towards the top end of the screen. As it exits the LEDs, light is reflected inside a light guide from which it exits towards the display from specific holes, much like a leaky fiberoptic cable[1].

The directionality and position of the LEDs, and the existence of the light guide, are precisely the differences which make the Paperwhite unlike a backlit display.

[1] http://www.nytimes.com/interactive/2012/12/26/technology/lig...

It's strange how appealing F# becomes once you realize you have the full power of the Visual Studio debugger and the .NET libraries. To someone who has mostly worked with Haskell (w.r.t. functional languages), that sounds great. Good debugging is absolutely essential - though with strongly typed functional languages, it's not often that necessary. But it's nice.

Then again, it's a very liberal language, if the end of the spectrum is Haskell. It allows side effects and mutable variables. While very convenient, nothing forces you to use these though. There are immutable data structures for everything. But it seems there are all the functional tools you'd want.

It's not Haskell, it's not pure and beautiful like it, but you still have computational expressions, which allow you to implement monads; metaprogramming, operator overloading, units of measure, and active patterns.

My only gripe is that the compiler doesn't translate functions that can return null to return an option value (i.e. Maybes), and null values in general! Would make interfacing the .NET library much cleaner. Right now I have to do something silly like this:

  let notNull a = if a <> null then Some a else None
So I have to pipe every function call that may return null to this function when I'm in the Maybe monad, which is frankly a bit bothersome.

Still. Even being able to use the Maybe monad when working with .NET is really cool.

D for the Win 12 years ago

Go hasn't been intended for "systems programming" for quite a while. It is a general purpose language.

The idea of continuations (which promises are) is to make an asynchronous control flow look like it is synchronous, but not become synchronous. More than anything, it is about readability and having a logical flow in the code.

Not really. They're still immense players in desktop and corporate IT. That alone accounts for an immense amount of revenue, a sizeable chunk in the whole world of computing.

On top of that, Azure is competitive and is gaining more and more traction, and the person who headed the Azure department is now the new CEO. Their gaming division (Xbox) is profitable, which is mostly a hardware field, and they're slowly getting a foothold in mobile and have purchased a big mobile hardware manufacturer.

Their development tools (Visual Studio and .NET) are immensely popular and they've managed to capitalize on the whole JavaScript thing by making it easy to develop with VS.

They're anything but dead.

Of course things like Bing aren't a success yet but if MSFT figures out what do with that they'll have something other than people just Google stuff on.

Greg Egan is a great visionary, his ideas and ingenuities are profound and intelligent. His works exude a kind of brilliance, a technological devotion to the big ideas, but at a cost: sometimes the ideas take the stage, and characters and plot are bystanders. Overall, they are still excellent, and they're big on the ideas. A warning: it's the hardest hard sci-fi out there, for example, the book Schild's Ladder is full of hardcore mathematics and physics.

Ah. So nice when science fiction actually happens.

“She lets go of the handle and goes into free fall.

At the same time, she jerks the manual release on her cervical collar and goes into full Michelin Man mode as tiny gas cartridges detonate in several strategic locations around her bod. The biggest one goes off like an M-80 at the nape of her neck, unfurling the coverall's collar into a cylindrical gasbag that shoots straight up and encases her entire head. Other airbags go off around her torso and pelvis, paying lots of attention to that spinal column.”

-- Neal Stephenson, Snow Crash

I... I don't understand. What's this mentality of offering free non-nutritious food for all employees, by the bucketload, for free? Why would you snack in the first place?

Either eat solid, whole meals on assigned lunch breaks, or drink something that isn't bad for you - tea, coffee come to mind - or why not, water?

In all frankness I find the whole concept of offering free crap for everyone harmful and eventually counterproductive - I can only imagine what copious amounts of free sugary soft drinks will do to people after a while.

Kari Enqvist, a professor of cosmology, said something very insightful in an interview about gambling in general:

"Insurances yield a peace of mind and lotteries yield dreams, the values of which cannot be measured in mere terms of probabilities or money."

In my view, lottery tickets are not meant to be rationally justifiable, nor should they be required to be. Yet, I don't fancy the idea of committing to such vain pursuits comfortable at all, but I can understand people who act upon their dreams, and will not berate those who do.

Evolutionary algorithms are very capable metaheurisitics with striking exploratory abilities. Exploratory in the sense that given a large search space, a well performing evolutionary algorithm can navigate this search space a lot faster than traditional metaheuristics. However, the problem of getting stuck into local optima is common still.

They definitely are a staple algorithm type in the field of optimization, especially combinatorial. Look it up.