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

Why we built Vade Studio in Clojure

bytes.vadelabs.com

Post reply on HN
Print view View original

81–90 of 151 posts

Re: Why we built Vade Studio in Clojure

#81

Post by j45 »

andrewstuart wrote: post #29

Look these folks can do whatever the heck they want, use whatever language they want. However my criteria for selecting a language for use in a professional context : 0: fit to task - obviously the language has to be able to do the job - to take this seriously you must define the job and what its requirements are and map those against the candidate languages 1: hiring and recruiting - there must be a mainstream sized…

Hiring and recruiting would have valid points if IT recruiting and hiring wasn't so hopelessly broken.

An example: When existing technology team members can run an interview and decide if someone could learn what they're working with.

Re: Why we built Vade Studio in Clojure

#82

Post by j45 »

bitwize wrote: post #42
andrewstuart wrote: post #29

Look these folks can do whatever the heck they want, use whatever language they want. However my criteria for selecting a language for use in a professional context : 0: fit to task - obviously the language has to be able to do the job - to take this seriously you must define the job and what its requirements are and map those against the candidate languages 1: hiring and recruiting - there must be a mainstream sized…

> talent shortages are not acceptable - and I don't buy the argument that "smart people are attracted to non mainstream languages which is how we find smart people", it is simply not true that "most smart people program with Scala/Haskell/Elixir/whatever" - there's smart and smarter working on the mainstream languages. Smart people can be trained in any language and become effective in a reasonably short period of ti…

Well said, languages are largely syntax and can be picked up with time. Clear thinking through a process is the valuable skill.

Re: Why we built Vade Studio in Clojure

#83

Post by lispm »

bsder wrote: post #45
lispm wrote: post #35

Earlier quoted context omitted.

> Lisp would have been really good relative to BASIC interpreters at the time I see no evidence for that. Lisp was a pain on tiny machines with bad user interface. > 64K is solid for a Lisp if you own the whole machine. I had a Lisp on an Apple II. It was a useless toy. I was using UCSD Pascal and Modula 2 on it. Much better. I had Cambridge Lisp on an Atari with 68k CPU. It was next to unusable due to frequent crash…

> There were articles for example in the Byte magazine. And they were stupid. Even "good" Lisp references didn't cover the important things like hashes and arrays. Everybody covered the recursive crap over and over and over ad nauseam while people who actually used Lisp almost always sidestepped those parts of the language. > I had a Lisp on an Apple II. It was a useless toy. I was using UCSD Pascal and Modula 2 on i…

> And yet UCSD Pascal was using a P-machine. So, the problem was the implementation and not the concept. Which was exactly my point.

My point is that implementations don't come from nothing. You can't just demand them to be there. They have to be invented/implemented/improved/... Companies at that time did not invest any money in micro implementations of Lisp. I also believe that there was a reason for that: it would have been mostly useless.

> Temporarily. But then it died when the big money went away and left Lisp all but dead. All the while all the people using languages on those "toys" kept right on going.

Lot's of toys and languages for them died.

Re: Why we built Vade Studio in Clojure

#84

Post by iLemming »

SerCe wrote: post #56
low_tech_punk wrote: post #53

Because Clojure treats data as first-class citizens, we could build our own lightweight conflict resolution system using pure functions that operate on these transactions. What does it mean to say Clojure "treat data a first-class citizen"? I understand FP would treat function as first-class citizen, but the statement seems to mean something different.

They most likely refer to homoiconicity [1], as Clojure is a dialect of Lisp. However, it's hard to say for sure, and maybe they were simply referring to the built-in syntax for maps, lists, etc. [1]: https://en.wikipedia.org/wiki/Homoiconicity

Not only due to homoiconic nature. All (well, technically not all, let's say most) Lisp dialects are homoiconic. Yet, there are some other aspects that make Clojure specifically well-suited for data manipulation:

- immutability and persistent data structures (makes code easier to reason about [the data]; enables efficient concurrency - no locks; some algorithmic tricks that makes it very performant despite having to create copies of collections),

- seq abstraction - unlike other Lisp where sequence functions are often specialized for different types, Clojure simplifies things by making baked-in abstraction central to the language - all core functions work with seqs by default. it emphasizes lazy sequences as a unified way to process data, i.e., memory efficiency and infinite sequences, etc.

- rich standard library of functions for data transformation

- destructuring - makes code both cleaner and more declarative

- emphasis on pure functions working on simple data structures

The combination of these features makes data processing in Clojure particularly elegant and efficient.

Re: Why we built Vade Studio in Clojure

#85

Post by iLemming »

lispm wrote: post #75
iLemming wrote: post #73

Earlier quoted context omitted.

> myriad reasons why Common Lisp is far superior to Clojure Some narrow view. Have you tried thinking that maybe Clojure intentionally chose not to include type declarations because they can lead to a messy middle ground? After all, maybe not every feature from Common Lisp needs to be replicated in every Lisp dialect? Besides, Clojure's Spec and Malli can be far more powerful for validation as they can define complex…

> not to include type declarations because they can lead to a messy middle ground? What? Type declarations in CL (which came from prior Lisp dialects) were added, so that optimizing Lisp compilers can use those to create fast machine code on typical CPUs (various CISC and RISC processors). Several optimizing compilers have been written, taking advantage of that feature. The compiler of SBCL would be an example. SBCL…

I didn't say "type declarations can lead to a messy middle ground in Common Lisp" - obviously they exist there for a reason, but, maybe they DON'T exist in Clojure, also for good reasons, no?

ABCL does exist, sure, and there's also LCL for Lua. Yet, 8 out of 10 developers today, for whatever reasons would probably use Fennel to write Lispy-code to target Lua and probably more devs would choose Clojure (not ABCL) to target JVM. That doesn't make either Fennel nor Clojure "far superior" than Common Lisp and vice-versa.

Re: Why we built Vade Studio in Clojure

#87

Post by iLemming »

j45 wrote: post #78
e12e wrote: post #44

> Today, we're building Vade Studio with just three developers – myself and two developers who joined as interns when in college. (...) Here's what we've accomplished: (...) In how many man-hours/days? It's hard to know if the list is long or short only knowing that calendar time should be multiplied by three for calculating people time spent...

If it took fewer lines of code that's something to consider too.

Yes, Clojure can be very terse without being extremely cryptic. Even simple data representation, if you compare JSON and EDN - the latter would be almost twice as compact yet remain more readable than JSON. Clojure is not as terse as e.g., Haskell, but I think it wins by being more pragmatic. Of course, some seasoned Haskelites may disagree, in some rare cases, Haskell can prove to be fantastically pragmatic, but let's agree not to go down that rabbit hole of argumentation.

Re: Why we built Vade Studio in Clojure

#89

Post by troad »

christophilus wrote: post #37

Clojure is a lot of fun to tinker with, but man… I love my static types. I think I’d hate to work on a large codebase in Clojure and constantly be wondering what exactly “m” is.

As a programmer with almost exclusively statically-typed compiled language experience, I used to strongly believe this too. In the last year, though, I've seriously toyed around with a number of dynamic languages, really trying to grok the dynamic mindset, and it's been very eye-opening. I never expected quite the degree of productivity boost that I have felt in these languages, and I must admit that I've also found many of them quite joyful to work with. Dynamic languages are profoundly creative, in all the senses of creative. I've found myself thinking about my programs in a totally different way, which has been really lovely (and honestly a timely reminder of what I loved about programming in the first place).

To be fair, I will readily say that the lack of static analysis really does bite when refactoring, though I think that good design principles and the overall productivity multiplier may offset that cost (also unique, descriptive, grep-able names!). I guess I've also seen enough C++ template spaghetti to know that static typing is no panacea either.

I don't know to what extent I'll use dynamic languages going forward, though for now I'm kind of in love with opening up a window into the computer and building up my digital sandcastles. Many of these languages also have a great FFI story, which is making me dream up cool bilingual projects that play on the strengths of both approaches.

All in all, no regrets about my adventures in dynamic-land.

Re: Why we built Vade Studio in Clojure

#90

Post by thih9 »

> When conflicts occur, our system can merge changes intelligently because we're working with pure data structures rather than complex objects. This would have been significantly more complex in an object-oriented language.

Not really, in an OO language state could have been stored in some data structure as well, with a way to serialize and deserialize. E.g. React made this very popular.

Post reply on HN