Hacker News Reader

Hacker News

Comment by kortex | Hacker News Reader

Full thread

kortex

- promises far fewer bugs

- promises to replace entire stack

- ...and Excel

- "declarative languages have almost no bugs"

- built-in database

Yeah color me skeptical. I love experiments, but I prefer those that under-promise and over-deliver. People have been promising unification languages since there were only two languages. People have been promising cross-platform since there were two platforms. And people have been promising to replace Excel since...Excel

View on HN

The thing that really bothered me was the FizzBuzz example [0]. The core logic is:

  cell
  //  this routine will be called 100 times, and the implied block variable
  //  b will hold values, like the sequence number b.cell_seq
  var ss : str
  case mod(b.cell_seq, 15)
  | 0
   ss = "FizzBuzz"
   draw_rect(fill:LIGHT_SKY_BLUE)
  | 3, 6, 9, 12
   ss = "Fizz"
   draw_rect(fill:LIGHT_GREEN)  
  | 5, 10
   ss = "Buzz"
   draw_rect(fill:YELLOW)
  else
   ss = to_str(b.cell_seq)
   draw_rect(fill:ALICE_BLUE)

  //  we just set the string in the case statement above
  draw_str(ss, size:0.7, color:BLACK)  

  //  if this is the selected cell, highlight with a red frame
  if b.cell_seq == my_state.selected
   draw_rect(thick:3 pt, pos:0.7, color:CRIMSON, corner:2 pt)

The entire point of FizzBuzz, as a programming practice, is to ensure the programmer does not try to write this exact code: you check mod 3 and print Fizz, mod 5 and print Buzz. This "solution" makes me worry the language itself will impede the simple solutions.

0. https://github.com/magicmouse/beads-examples/blob/master/Exa...

I don't understand your objection.

A lot of the rosetta code examples show the simple and the more complex example or less use of built-in functions to show they can express it with the core language.

Sure, but I think that's a different objection?

I think he's saying that inside of the loop in FizzBuzz, it should look like something like this (Python-esque pseudocode, assuming for a second print() doesn't add a newline automatically):

    if x % 3 == 0:
        print("Fizz")

    if x % 5 == 0:
        print("Buzz")

    if x % 3 != 0 and x % 5 != 0:
        print(x)

    print("\n")

i.e. no special "FizzBuzz" case for when it's divisible by 15, it just naturally falls out of the first two if's. It's a bit of a silly objection though, the it's fine to write it as the author did.

as I learned above you can use the "end" kwarg to avoid the newline:

    print("Fizz", end="")

That doesn't work here, though, because then you don't get "FizzBuzz" for 15 -- you get "Fizz" and "Buzz" on separate lines.

In his defense: I think the logic of his programming language and the pattern match works just fine: it's a mod over bounded linear range checking a remainder. He's just showing off that he can check "mod 15" against a list of potential values, or at least that's my reading of it.

I agree that I hate this solution. However, are you saying that this is a bad FizzBuzz solution to you? (Python)

  nums = list(range(100))
  
  def fizzbuzz(n):
    if n % 15 == 0:
      return "FizzBuzz"
    elif n % 3 == 0:
      return "Fizz"
    elif n % 5 == 0:
      return "Buzz"
    else:
      return str(n)
  
  print(" ".join(map(fizzbuzz, nums)))

I think it's far better than:

  nums = list(range(100))
  
  for num in nums:
    if num % 3 == 0:
      print("Fizz", end="")
    if num % 5 == 0:
      print("Buzz", end="")
    if num % 3 != 0 and num % 5 != 0:
      print(num, end="")
    print(" ")

EDIT: Formatting, typo

At the risk of the classic "no here's the fizzbuzz code" while then getting it wrong, the typical case you're trying to draw out is like the second but:

Not printing in the middle, return a string and afterwards print it.

Each step adds to the string, and if it's still empty by the end you just put the number in.

The next stages are often to add another number, then something more complex (if it's a prime number). As you do this, the concatenation version grows slowly while the first approach explodes in combinations.

I don’t want to argue in favour of the Beads solution but I think the right way to describe the logic is as follows:

  input is n
  | 3 divides n | 5 divides n | result     |
  |—————————————|—————————————|————————————|
  | Yes         | Yes         | “FizzBuzz” |
  | Yes         | No          | “Fizz”     |
  | No          | Yes         | “Buzz”     |
  | No          | No          | n.toString |
  print result

The key points are:

1. The logic is declarative: the order of the rows in the table doesn’t matter.

2. It tests for divisibility in words rather than a potentially confusing idiom (how does % behave for negative numbers? Is it defined for floats in this language?)

3. The structure allows you (or a compiler) to check that no case is missed.

4. It should be easier to convince oneself that modifications to the code do what they are supposed to.

The funny thing is that looking things up in tables is much more common in excel.

I agree, I think that's close to isomorphic to my first solution! There's a "mapping" from numbers to strings, and this is the mapping.

There are about 3 slightly different methods for doing FizzBuzz, in any language, and this was but one of them.

You could express it also as an empty string, then concatenating as necessary: ''' // to those objecting to using a modulo-15 test, // we could have done the above code as follows: var ss = "" if mod(b.cell_seq, 3) == 0 "Fizz" &=> ss if mod(b.cell_seq, 5) == 0 "Buzz" &=> ss if ss == "" ss = to_str(b.cell_seq) '''

The problem with FizzBuzz as a programming language exploration is that it is far too short of a program to reveal the totality of a language, since it only consists of using the if/pattern match capability, modulo function, concatenating strings, and converting an integer to a string. The Stock market ticker program is a much better demo of the language, because it shows how to do client/server programming in a very easy way.

I think that is a better FizzBuzz example. You are right that it isn't meant to showcase the whole language, but lacking a composable solution (mod N1 || mod N2... for N prime factors) makes me immediately think the language does not lend itself well to that kind of composition.

And as others mentioned, Fizzbuzz is merely a "can you program anything test." But I do prefer the "general" fizzbuzzjazz, which accepts a list of numbers and a list of words [fizz, buzz, jazz,...] and emits the strings for appropriate prime factors.

> The entire point of FizzBuzz, as a programming practice, is to ensure the programmer does not try to write this exact code

No, the point of FizzBuzz, which is an interview practice is to make sure that the candidate has literally the minimum ability to translate a natural-language problem description into code.

There is no point using it for anything else. Not demos of languages or tools, not looking for a particular shape of solution, you don't even really need to let them finish writing a bug-free version of it. It is only to filter out the people who "learned a language" but cannot actually write a program. Which is unfortunately a ton of people.

https://imranontech.com/2007/01/24/using-fizzbuzz-to-find-de...

> is to ensure the programmer does not try to write this exact code

I agree with your thoughts around the language constraints, but I see more room for what you once could have gotten from using FizzBuzz as a minimum-skill filter. It depends on the level you're hiring at.

From a novice engineer I would be content if they're demonstrating awareness that multiples of 15 represent an edge case without it being included in the instructions.

If I'm hiring someone more senior, I'd expect them to provide (or iterate to) a more optimized solution to FizzBuzz.

But in a further tangent - I think this using this type of question as a minimum-talent filter stopped becoming viable as soon as it became commonly used. In the time since, it's become more a minimum-knowledge filter -- and that doesn't tell you anything about the candidate's methods in solving a problem with derivable requirements.

Depends on your definition of 'simple', I guess.

My preference is to have all behaviours be explicit in the declared code, rather than implicit or as a side-effect. Much simpler to read and reason about the program.

Clarity over cleverness. To that end, I prefer this version over 'hiding' the mod 15 case for the sake of saving a line of code.

I also appreciate languages that warn (or better, require) that all cases are covered.

This solution looks ugly, but i don't think its "wrong". The point of fizzbuzz is to check they can write any trivial program. It works, its a pass.

Beads does not replace Excel, but it can close the gap between Excel and the popular programming languages, which have a great deal of unnecessary complexity in them. For example, in HTML/CSS/JS, the comment syntax varies between the 3 languages. Why are there 3 distinct languages in one source file? When in history was this ever done? I can remember mixing 2 languages, but 3? that's just ridiculous.

Code which doesn't execute has very few bugs in it in my experience. And those bugs tend to be easier to fix, than say a register clobberation bug in assembly language which i have had to wrestle with before. Telling the computer what to do, but not telling it how, does cut out a lot of effort (and potential errors).

You have every right to be skeptical, but i hope you can overcome your initial skepticism to at least take it for a test drive.

> declarative languages have almost no bugs"

Is this even a declaritave language? Doesn't look like it to me at a glance.

The layout system is declarative (with escape hatch to looping and conditionals), and so is the finite state machine syntax DSL inside, and the regular expression syntax (a novel reformulation).

But the nicest feature, invisible in the syntax because it is a property of the runtime under the hood, is that when you change your mutable state, any layout that used those variables is automatically scheduled for refresh. You thus declare what is on the screen, and how it is arrange, and the system knows what to do. In this sense it more like SQL, where you give it a goal, and don't specify the ordering of how to achieve the task.

There are also mini-solvers built into the language for the common tasks of solving for rectangles and points, which are quite handy.

Please take it for a spin, you might like it!

MobX does this for JS, in a more generalized way that can be paired with any DOM-update strategy (or other arbitrary side-effects)

"Reactivity" is a common paradigm in the javascript world. There are many libraries to essentially do this or variations on this theme.

There are two key elements in this case:

1) Changes are triggered through regular mutation, not special API calls

2) Reactive dependencies are automatically determined

The combination of these two traits is somewhat unique, and is offered by MobX and (apparently) Beads.

I don't think having an embedded DSL for defining layouts makes it a declaritive language. By that definition, almost every language is declarative as its a somewhat common way to define layouts (certainly not universal, but common enough that i suspect every language has at least one library that supports it).

If the main facilities for writing logic in the language are procedural, than i'd call that a procedural language.

> declarative languages have almost no bugs

That one piqued my attention. It's one thing to say "fewer bugs" and quite another to say "almost none". Rust is a declarative language with one of the more rigorous static analysis checkers (for pedants: among mainstream languages) and I still write buggy code.

In what way is Rust declarative? When I think of a declarative language, I think of Prolog or SQL. Rust to me would seem to be explicitly imperative.

I guess I was confusing expression based or functional with declarative.

Point still stands. I've made plenty of bugs writing both sql and prolog (although i've only written a small amount of prolog)

Certain classes might be more or less likely, but no paradigm is magic and stops all bugs.

Reply on news.ycombinator.com